Messages in this thread | | | From | Doug Anderson <> | Date | Wed, 10 Mar 2021 15:47:15 -0800 | Subject | Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 |
| |
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
| |