Hi,
2018-01-31 17:52 GMT+01:00 Doug Anderson dianders@chromium.org:
Hi,
On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul seanpaul@chromium.org wrote:
On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach l.stach@pengutronix.de wrote:
Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
From: Sean Paul seanpaul@chromium.org
Change the mode for Sharp lq123p1jx31 panel to something more rockchip-friendly such that we can use the fixed PLLs to generate the pixel clock
This should really switch to a display timing instead of exposing a single mode. The display timing has min, typical, max tuples for all the timings values, which would allow the attached driver to vary the timings inside the allowed bounds if it makes sense.
Trying to hit a specific pixel clock to free up a PLL is exactly one of the use cases envisioned for the display timings stuff.
Agreed, I think we had this discussion the first time around. We should drop this patch.
Thanks for catching this!
Are you sure we should drop this? In order for things to work properly (not generate noise on the digitizer or other EMI), this needs to run at a very specific pixel clock with very specific blanking times. I know that earlier we had slightly different blanking times and Samsung came back and said that there was noise on the digitizer. I could be wrong, but I don't think there's any way currently to be able to specify exactly what timings should be used on a particular board.
Don't get be wrong--I think a patch such as this one that claims a single board's timings as the "right" ones for a generic panel is a bit of a hack. ...but at the same time there are no other users of this panel (that I know of) in mainline and the timings presented here are certainly sane timings for this panel.
In any case, previous discussion at: https://patchwork.kernel.org/patch/9614603/
...oh, and looking at the previous discussion reminds me that the timings presented in this here patch are actually not the right ones (they have the right PLL, but the wrong blankings to avoid the noise issues). See <//chromium-review.googlesource.com/381015>
As Thierry no longer has the hardware to test these patch series, I'll take care of these and follow the upstreaming process. I think that doesn't make sense send a v4 version of all 43 patches for this change. Right now, only this patch received comments so I'll wait a bit more for if we can get the other patches reviewed. If the others are fine just and I don't need to send a new version just don't apply this one and I will send a second version of that specific patch. Or even better, is really trivial what needs to be changed, so maybe the maintainer can do it? ;)
Regards, Enric
-Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel