lkml.org 
[lkml]   [2018]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31
    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

    \
     
     \ /
      Last update: 2018-02-16 13:35    [W:4.597 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site