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

[Nico Huber]

On 06.03.2018 22:13, Julius Werner wrote:
>> Although even if they did have the lane exposes it looks like your
> helpful advice on the coreboot function would be a bit out of my depth.
>
> It's pretty simple... try this patch (untested) which should implement what
> I suggested. I think there's a decent chance this might make your other
> panel work as well. (Note that this is *only* for the exact panel you
> originally posted log output for. Also: I think this should work, but
> there's a slim chance wrong pixel clocks may damage a panel, no warranty,
> yada yada.)
>
> diff --git a/src/soc/rockchip/rk3288/clock.c b/src/soc/rockchip/rk3288/clock
> .c
> index 74151e85cb..4474ff81aa 100644
> --- a/src/soc/rockchip/rk3288/clock.c
> +++ b/src/soc/rockchip/rk3288/clock.c
> @@ -539,6 +539,11 @@ static int pll_para_config(u32 freq_hz, struct pll_div
> *div, u32 *ext_div)
>                 return -1;
>         }
>
> +       div->no = 4;
> +       div->nf = 91;
> +       div->nr = 4;
> +       return 0;
> +
>         div->no = no;
>
>         best_diff_khz = vco_khz;
>

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.

>
> I'm not sure if the coreboot source is prepared for that, though. There
>> are some pieces in the code that confuse me (e.g. the zeros passed to
>> rk_edp_set_video_cr_mn(), Julius, do you happen to know something about
>> that? is there public documentation for Rockchip's display engine?).
>>
>
> Sorry, I gotta admit I'm not a display guy at all. We mostly just took what
> they gave us. The reference manuals were all shared with us under NDA...
> you could try asking them directly, but I doubt you'll have much luck. The
> document you're looking for is called "Rockchip EDP TX IP Interface". It
> has lots of nice explanations including about M and N, but I don't really
> understand them without background.

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 would, however, give the following one shot:
>>
>> 1.  in soc/rockchip/common/edp.c line 615 override the lane count:
>>
>>     edp->link_train.lane_count = 1;
>>
>
> 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.

Nico