Need to avoid hardcoding the panel in rk3399-nefario dts |
|||
Issue descriptionRight now most ARM Chromebooks hardcode the exact panel model in the device tree. As an example: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dtsi#99 You can see: edp_panel: edp-panel { compatible = "sharp,lq123p1jx31", "simple-panel"; backlight = <&backlight>; power-supply = <&pp3300_disp>; ports { panel_in_edp: endpoint { remote-endpoint = <&edp_out_panel>; }; }; }; --- This is a problem from a manufacturability point of view. We'd like to have 2nd (or 3rd) sources for panels and those panels will be different models. --- In theory we ought to be able to probe using the EDID to figure out which panel is connected. This was discussed upstream at <https://patchwork.kernel.org/patch/9170137/> ([v2,1/2] dt-bindings: add Starry KR122EA0SRA panel binding) and various folks upstream indicated that there was no completely generic way to just use the EDID. ...but even though upstream seems to indicate that this can't be solved in a completely generic way, it seems like there ought to be some way to use the EDID to help with second sourcing by constraining ourselves. If we constrain ourselves to only needing to work on a certain family of boards and we constrain which panels are attached to that board it seems like we could write a driver that used the EDID to properly identify the panel. For instance, if all of the panels that might be stuffed on a given board can at least respond with an EDID w/out a full power sequence then we could read the EDID and then pick a power sequence depending on the EDID. ...or if all the panels that might be stuffed on a given board have a compatible enough power sequence we can just do the normal power sequence and then get the rest of panel timings from the EDID. Basically as long as we constrain ourselves a little bit it's clear that we can solve this problem. --- This bug is about: 1. First and foremost getting something landable in the Chrome OS tree in a reasonable timeframe that will allow nefario to use all the panels that might be attached to it. 2. Come up with a solution that we can land upstream to let the rest of the Linux community benefit from this (and also to avoid having to carry this code in our next kernel rebase). --- One other note is that on rk3399-nefario we probably can't use the exact timings obtained from the EDID of the panel. Historically we've relied on hacks like crosreview.com/585384 to do this so we'll have to figure out what that means in the context of the above.
,
Jul 28 2017
I'd also note that my current 75 MHz pixel clock almost works for all 3 panels plus one more (BOE-NT116WHM-N21-TN). Currently I have: refresh rate: 60 Hz clock: 75 MHz htotal: 1497 vtotal: 835 Min refresh rate for all 4 panels: 55 Hz, n/a, n/a, n/a Max refresh rate for all 4 panels: 65 Hz, n/a, n/a, n/a Min clock for all 4 panels: 62 MHz, 61 MHz, 69.3 MHz, 66.4 MHz Max clock for all 4 panels: 82 MHz, 80.04 MHz, 78.5 MHz, 80 MHz Min htotal for all 4 panels: 1420, 1590, 1456, 1426 Max htotal for all 4 panels: 2047, 1692, n/a, 2000 Min vtotal for all 4 panels: 771, 780, 793, 776 Max vtotal for all 4 panels: 1023, 840, n/a, 1000 --- So my current timings would work for all but one panel I think. Ideally we might want to customize more, though.
,
Jul 28 2017
Kristian has volunteered to own. :)
,
Jul 31 2017
One more panel in the mix, so now:
Panels: KD116N9-30NH-D3, BOE NT116WHM-N21, BT116HDAN001, AUO B116XTN02.5, KD116N5-30NV-A6
---
Min refresh rate for all 5 panels: 55 Hz, n/a, n/a, n/a, 50 Hz,
Max refresh rate for all 5 panels: 65 Hz, n/a, n/a, n/a, 65 Hz,
Min clock for all 5 panels: 62 MHz, 61 MHz, 69.3 MHz, 66.4 MHz, 50 MHz
Max clock for all 5 panels: 82 MHz, 80.04 MHz, 78.5 MHz, 80 MHz, 80 MHz
Min htotal for all 5 panels: 1420, 1590, 1456, 1426, 1520
Max htotal for all 5 panels: 2047, 1692, n/a, 2000, 1620
Min vtotal for all 5 panels: 771, 780, 793, 776, 778
Max vtotal for all 5 panels: 1023, 840, n/a, 1000, 830
---
Running a little bit of python to pick timings that could sorta work for all of those:
freq = 75000000
ideal_hz = 60.0
best_delta = 99999
min_v = max([771, 780, 793, 776, 778])
max_v = min([1023, 840, 1000, 830])
min_h = max([1420, 1590, 1456, 1426, 1520])
max_h = min([2047, 1692, 2000, 1620])
for vperiod in xrange(min_v, max_v + 1):
for hperiod in xrange(min_h, max_h + 1):
hz = float(freq) / (vperiod * hperiod)
delta = abs(hz - ideal_hz)
if delta < best_delta:
best_delta = delta
best_vperiod = vperiod
best_hperiod = hperiod
best_hz = hz
print best_hz, best_vperiod, best_hperiod
---
I end up with:
59.4827381094 793 1590
---
So my thought is to make a bogus panel entry in Simple Panel for now that uses that timing and then it should be OK no matter which of the above 5 panels gets stuffed. It's not ideal (not super close to 60 Hz, doesn't optimize timings, and awfully close to the margins on some panels) but it should boot.
Kristian will work on a more long term solution.
That patch is:
* https://chromium-review.googlesource.com/594428
CHROMIUM: HACK: drm/panel: simple: Fake compromise timings for nefario
,
Jul 31 2017
See also b/64145688
,
Aug 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/89501bc2db4b8be67c34a70080ddfc74c61252cc commit 89501bc2db4b8be67c34a70080ddfc74c61252cc Author: Douglas Anderson <dianders@chromium.org> Date: Tue Aug 01 17:15:42 2017 CHROMIUM: HACK: drm/panel: simple: Fake compromise timings for nefario This imaginary panel was conceived of to provide timings that will work no matter which of the 5 possible panels gets stuffed on the -rev0 nefarios that will be built. This patch is intended to be reverted once crbug.com/750354 is fixed. This patch should not be sent upstream. --- These timings were generated with: freq = 75000000 ideal_hz = 59.0 best_delta = 99999 min_v = max([771, 780, 793, 776, 778]) max_v = min([1023, 840, 1000, 830]) min_h = max([1420, 1590, 1456, 1426, 1520]) max_h = min([2047, 1692, 2000, 1620]) for vperiod in xrange(min_v, max_v + 1): for hperiod in xrange(min_h, max_h + 1): hz = float(freq) / (vperiod * hperiod) delta = abs(hz - ideal_hz) if delta < best_delta: best_delta = delta best_vperiod = vperiod best_hperiod = hperiod best_hz = hz print best_hz, best_vperiod, best_hperiod --- That gives us: 59.0003453487 793 1603 --- Note that the 75 MHz was picked because it is one of the few clock rates that can be achieved via an integral divide of 600 MHz (GPLL) or 800 MHz (CPLL) due to the fact that we want to save VPLL for the external display. Basically the only reasonable pixel clocks we can use for this sized panel are: 800 / 10. = 80 MHz 800 / 11. = 72.727 MHz 600 / 8. = 75.0 MHz 600 / 9. = 66.67 MHz Picking 75.0 is the fastest pixel clock that all panels can handle. We picked to aim for 59 Hz exactly since the refresh rate needs to be an integral number of Hz and we couldn't make 60 Hz w/ all of our compromises. --- Note that the above timings only give us about 342 us of vblank timing (if I'm doing my math right). Currently DMC_MIN_VBLANK_NS is set to 300 us, so we're fairly close to the margin there. Hopefully that should be OK, but we should keep our eyes out for any possible flickering. --- BUG=chromium:750354, b:63537905 TEST=Compile Change-Id: I50ce712220a4d3bab1a544f44254c2b43aae0145 Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/594428 Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> [modify] https://crrev.com/89501bc2db4b8be67c34a70080ddfc74c61252cc/drivers/gpu/drm/panel/panel-simple.c
,
Aug 1 2017
In case it's not obvious, above change is just the stopgap. This bug will stay open for a prettier solution. |
|||
►
Sign in to add a comment |
|||
Comment 1 by diand...@chromium.org
, Jul 28 2017