From: Doug Anderson <dianders@chromium.org> To: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com>, Sam Ravnborg <sam@ravnborg.org>, Rob Clark <robdclark@chromium.org>, Stephen Boyd <swboyd@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Date: Wed, 10 Mar 2021 15:47:15 -0800 [thread overview] Message-ID: <CAD=FV=WDVAj+OcVXaTJRUu8tvdDzySW0KOfiGqZHi5YvP42BTA@mail.gmail.com> (raw) In-Reply-To: <CACRpkdYUs2W3b_u8YrmYwq_kcUCf0DhZ-o2o6O2EmU5rdtv=BA@mail.gmail.com> Hi, On Wed, Mar 10, 2021 at 3:25 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson <dianders@chromium.org> wrote: > > > - ("drm/panel-simple: Don't wait longer for HPD...") new for v2. > > - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2. > > I couldn't find these patches in my inbox Doh! Sorry about that. I think get_maintainer tagged you only on the patches that had the explicit "fixes" in them on something you were involved in. I tend to rely on get_maintainer heavily unless I think someone is particularly interested in the whole series. I will make sure to CC you on the whole series if I post it again. In the meantime the whole series is on lore: https://lore.kernel.org/lkml/20210115224420.1635017-1-dianders@chromium.org/ > but my concern would > be that at some point panel-simple will turn from simple into > panel-rube-goldberg-machine. Yes, it's definitely something to watch out for. I guess you're commenting on the general number of changes I've made to simple-panel in the last year or two? I guess my comment on those: * Many of the changes I made were around HPD handling and supporting a GPIO (and also supporting the "hpd absent delay"). The fact that we use a GPIO for HPD is actually an attribute of our board design, though, so if I had forked panel drivers for each of the panels that needed it then it would have required copying the code lots of places (or implementing some code sharing). I was specifically asked to do the HPD handling code at the panel layer. * The other big change I made recently was around allowing for relative rather than absolute timings (instead of a fixed delay at a given stage adding a constraint that enough time had passed since a previous event). When I proposed that the feedback I got back was that it was a good improvement for all panels and something that had been on a TODO list for a while. ...so while it feels like I keep piling crap onto simple-panel, I _think_ they've been good general improvements that many people will be able to benefit from and I don't think they've uglified things lots. > Given that the talk with the manufacturer may result > in even more quirks... maybe this should just be a separate > panel driver? I don't _think_ this will end up with more quirks. At least I sure hope not. So far it seems like pure luck that I even noticed it because only one other device in the whole batch produced had similar problems. That leads me to believe that there could be other panels with a similar need. > (I expect pushback because I see how handy it is, but > I am the guy writing new panel drivers all the time rather than > using simple.) I guess what I'd say in summary is: * If you object to the retries in simple panel, I still hope the rest of the series can land. * If somehow this panel gets out into real users hands and we find that the retries are necessary and people still don't want the retries in simple panel, I can fork a special panel driver just for it then. -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Clark <robdclark@chromium.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, David Airlie <airlied@linux.ie>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Stephen Boyd <swboyd@chromium.org>, Thierry Reding <thierry.reding@gmail.com>, "open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>, Sam Ravnborg <sam@ravnborg.org> Subject: Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Date: Wed, 10 Mar 2021 15:47:15 -0800 [thread overview] Message-ID: <CAD=FV=WDVAj+OcVXaTJRUu8tvdDzySW0KOfiGqZHi5YvP42BTA@mail.gmail.com> (raw) In-Reply-To: <CACRpkdYUs2W3b_u8YrmYwq_kcUCf0DhZ-o2o6O2EmU5rdtv=BA@mail.gmail.com> Hi, On Wed, Mar 10, 2021 at 3:25 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson <dianders@chromium.org> wrote: > > > - ("drm/panel-simple: Don't wait longer for HPD...") new for v2. > > - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2. > > I couldn't find these patches in my inbox Doh! Sorry about that. I think get_maintainer tagged you only on the patches that had the explicit "fixes" in them on something you were involved in. I tend to rely on get_maintainer heavily unless I think someone is particularly interested in the whole series. I will make sure to CC you on the whole series if I post it again. In the meantime the whole series is on lore: https://lore.kernel.org/lkml/20210115224420.1635017-1-dianders@chromium.org/ > but my concern would > be that at some point panel-simple will turn from simple into > panel-rube-goldberg-machine. Yes, it's definitely something to watch out for. I guess you're commenting on the general number of changes I've made to simple-panel in the last year or two? I guess my comment on those: * Many of the changes I made were around HPD handling and supporting a GPIO (and also supporting the "hpd absent delay"). The fact that we use a GPIO for HPD is actually an attribute of our board design, though, so if I had forked panel drivers for each of the panels that needed it then it would have required copying the code lots of places (or implementing some code sharing). I was specifically asked to do the HPD handling code at the panel layer. * The other big change I made recently was around allowing for relative rather than absolute timings (instead of a fixed delay at a given stage adding a constraint that enough time had passed since a previous event). When I proposed that the feedback I got back was that it was a good improvement for all panels and something that had been on a TODO list for a while. ...so while it feels like I keep piling crap onto simple-panel, I _think_ they've been good general improvements that many people will be able to benefit from and I don't think they've uglified things lots. > Given that the talk with the manufacturer may result > in even more quirks... maybe this should just be a separate > panel driver? I don't _think_ this will end up with more quirks. At least I sure hope not. So far it seems like pure luck that I even noticed it because only one other device in the whole batch produced had similar problems. That leads me to believe that there could be other panels with a similar need. > (I expect pushback because I see how handy it is, but > I am the guy writing new panel drivers all the time rather than > using simple.) I guess what I'd say in summary is: * If you object to the retries in simple panel, I still hope the rest of the series can land. * If somehow this panel gets out into real users hands and we find that the retries are necessary and people still don't want the retries in simple panel, I can fork a special panel driver just for it then. -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-10 23:48 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-15 22:44 [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-15 22:44 ` [PATCH v2 1/5] drm/panel-simple: Undo enable if HPD never asserts Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-15 22:49 ` Stephen Boyd 2021-01-15 22:49 ` Stephen Boyd 2021-01-15 22:44 ` [PATCH v2 2/5] drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-25 20:26 ` Stephen Boyd 2021-01-25 20:26 ` Stephen Boyd 2021-01-15 22:44 ` [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-25 20:28 ` Stephen Boyd 2021-01-25 20:28 ` Stephen Boyd 2021-01-27 21:11 ` Doug Anderson 2021-01-27 21:11 ` Doug Anderson 2021-01-15 22:44 ` [PATCH v2 4/5] dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1 Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-15 22:59 ` Doug Anderson 2021-01-15 22:59 ` Doug Anderson 2021-01-25 20:29 ` Stephen Boyd 2021-01-25 20:29 ` Stephen Boyd 2021-02-08 21:50 ` Rob Herring 2021-02-08 21:50 ` Rob Herring 2021-01-15 22:44 ` [PATCH v2 5/5] drm/panel-simple: " Douglas Anderson 2021-01-15 22:44 ` Douglas Anderson 2021-01-25 20:29 ` Stephen Boyd 2021-01-25 20:29 ` Stephen Boyd 2021-03-05 15:42 ` [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Doug Anderson 2021-03-05 15:42 ` Doug Anderson 2021-03-10 23:25 ` Linus Walleij 2021-03-10 23:25 ` Linus Walleij 2021-03-10 23:47 ` Doug Anderson [this message] 2021-03-10 23:47 ` Doug Anderson 2021-03-11 0:57 ` Linus Walleij 2021-03-11 0:57 ` Linus Walleij 2021-03-11 1:01 ` Doug Anderson 2021-03-11 1:01 ` Doug Anderson 2021-03-11 16:20 ` Linus Walleij 2021-03-11 16:20 ` Linus Walleij 2021-03-11 16:15 ` Linus Walleij 2021-03-11 16:15 ` Linus Walleij
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD=FV=WDVAj+OcVXaTJRUu8tvdDzySW0KOfiGqZHi5YvP42BTA@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=airlied@linux.ie \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=linus.walleij@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=robdclark@chromium.org \ --cc=robh+dt@kernel.org \ --cc=sam@ravnborg.org \ --cc=swboyd@chromium.org \ --cc=thierry.reding@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.