[coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Julius Werner]

>
> While this might be closer to the optimum for 60Hz, it would still try
> to pump data at around 136MHz. DP doesn't use a variable pixel clock on
> the physical layer. It's using either 1.62GHz (reduced bit-rate, RBR) or
> 2.7GHz (high bit-rate, HBR). Or (not supported by this code and likely
> not by the SoC) 5.4GHz (HBR2) or 8.1GHz (HBR3). Data is encoded with 10
> bits per 8 bits of payload, so for a single lane at HBR you can only get
> up to 2.7GHz / 10 * 8 / 18 = 120MHz.


Okay, you clearly know more than me. ;) All I know is that the pixel clock
is supposed to match the value in the EDID descriptor, and that we had
problems with jitter on it (although that might have just been HDMI). But
I'm not sure how exactly it is used... if you say the eDP clock is
constant, maybe it's just being used internally on the SoC (in the
connection between Video Output Processor and the eDP block)?


> If it relates to what I know from Intel graphics, M/N gives the ratio
> how much of the bandwidth on the lanes is used for actual picture data.


I think I found it now. We're passing CALCULATED_M to that function, so
it's using the second path (which only initializes N to 0x8000). It clears
the FIX_M_VID bit which I think means that M is being calculated
automatically by the controller.


> > The other lanes aren't routed on the board. This isn't going to help.
>
> To be clear, I meant to override it with 1. As far as I understand the
> code, this should configure both sink and source to use only a single
> lane.


Oh, okay, yes, I guess that could help. Although it sounds(?) like at that
point you're essentially ignoring the EDID and just trying to make up your
own video mode, so it seems more like a shot in the dark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180306/63b82c3f/attachment.html>