Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic

[Matt Redfearn]

On 12/09/2019 14:21, Andrzej Hajda wrote:
> On 12.09.2019 04:38, John Stultz wrote:
>> On Wed, Sep 4, 2019 at 3:26 AM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote:
>>> On 03.09.2019 18:18, John Stultz wrote:
>>>> On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote:
>>>>> On 30.08.2019 19:00, Rob Clark wrote:
>>>>>> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote:
>>>>>>> Of course it seems you have different opinion what is the right thing in
>>>>>>> this case, so if you convince us that your approach is better one can
>>>>>>> revert the patch.
>>>>>> I guess my strongest / most immediate opinion is to not break other
>>>>>> existing adv75xx bridge users.
>>>>> It is pity that breakage happened, and next time we should be more
>>>>> strict about testing other platforms, before patch acceptance.
>>>>>
>>>>> But reverting it now will break also platform which depend on it.
>>>> I'm really of no opinion of which approach is better here, but I will
>>>> say that when a patch breaks previously working boards, that's a
>>>> regression and justifying that some other board is now enabled that
>>>> would be broken by the revert (of a patch that is not yet upstream)
>>>> isn't really a strong argument.
>>>>
>>>> I'm happy to work with folks to try to fixup the kirin driver if this
>>>> patch really is the right approach, but we need someone to do the same
>>>> for the db410c, and I don't think its fair to just dump that work onto
>>>> folks under the threat of the board breaking.
>>>
>>> These drivers should be fixed anyway - assumption that
>>> drm_bridge/drm_panel will be registered before the bus it is attached to
>>> is just incorrect.
>>>
>>> So instead of reverting, fixing and then re-applying the patch I have
>>> gently proposed shorter path. If you prefer long path we can try to go
>>> this way.
>>>
>>> Matt, is the pure revert OK for you or is it possible to prepare some
>>> workaround allowing cooperation with both approaches?
>> Rob/Andrzej: What's the call here?
>>
>> 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. 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.

> 
> 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? 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).

Anyway, my platform is out of tree so better to revert my patch and keep 
the in-tree platforms working.

Thanks everyone.
Matt

> 
> 
> And remove it after fixing both dsi masters.
> 
> 
> Regards
> 
> Andrzej
> 
> 
>>
>> thanks
>> -john
>>
>>
>