On Fri, Sep 13, 2019 at 1:47 AM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: > On 12.09.2019 16:18, Matt Redfearn wrote: > > On 12/09/2019 14:21, Andrzej Hajda wrote: > >> On 12.09.2019 04:38, John Stultz wrote: > >>> Should I resubmit the kirin fix for the adv7511 regression here? > >>> Or do we revert the adv7511 patch? I believe db410c still needs a fix. > >>> > >>> I'd just like to keep the HiKey board from breaking, so let me know so > >>> I can get the fix submitted if needed. > >> > >> Since there is no response from Matt, we can perform revert, since there > >> are no other ideas. I will apply it tomorrow, if there are no objections. > > Hi, > > > > Sorry - yeah I think reverting is probably best at this point to avoid > > breaking in-tree platforms. > > It's a shame though that there is a built-in incompatibility within the > > tree between drivers. > > > Quite common in development - some issues becomes visible after some time. > > > The way that the generic Synopsys DSI host driver > > probes is currently incompatible with the ADV7533 (hence the patch), > > other DSI host drivers are now compatible with the ADV7533 but break > > when we change it to probe in a similar way to panel drivers. > > > 1. The behavior should be consistent between all hosts/device drivers. > Yea, I worry about this as well, as I know there is also the lt9611 bridge chip driver pending for the db845c which works against the current msm dsi code. So changing the msm driver for the adv7533 may break other drivers (in the case of lt9611, out of tree - so wouldn't be a regression, but there may be others) written against the current expectations. > 2. DSI controlled devices can expose drm objects (drm_bridge/drm_panel) > only when they can probe, ie DSI bus they sit on must be created 1st. > > 1 and 2 enforces policy that all host drivers should 1st create control > bus (DSI in this case) then look for higher level objects > (drm_bridge/drm_panel). > > As a consequence all bridges and panels should 1st gather the resources > they depends on, and then they can expose higher level objects. > > > > > >> And for the future: I guess it is not possible to make adv work with old > >> and new approach, but simple workaround for adv could be added later: > >> > >> if (source is msm or kirin) > >> > >> do_the_old_way > >> > >> else > >> > >> do_correctly. > > Maybe this would work, but how do we know that the list "msm or kirin" > > is exhaustive to cope with all platforms? > > > By checking dts/config files. > A temporary clearly-marked-deprecated config option might also a reasonable approach while we transition drivers over? > > It seems to me the built in > > incompatibility between DSI hosts needs to be resolved really rather > > than trying to work around it in the ADV7533 driver (and any other DSI > > bus device that falls into this trap). > > > If you know how, please describe. Atm the only real solution I see is > explicit workaround to allow new adv7511, then fixing controllers, > together with workaround-removal. > > OK, it could be possible to change msm, kirin and adv in one patch, > however I am not sure if this is the best solution. Matt: I'm happy to help you test and validate things. Let me know how I can help! thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
