[Letux-kernel] [PATCH letux] panel-boe-w667l: hack-fix disapble oopses

H. Nikolaus Schaller hns at goldelico.com
Sat Dec 1 13:59:14 CET 2018


> Am 01.12.2018 um 13:54 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Sat, 1 Dec 2018 12:46:24 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>>> Am 01.12.2018 um 12:38 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> On Sat, 1 Dec 2018 09:36:43 +0100
>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> 
>>>> Hi Andreas,
>>>> 
>>>>> Am 01.12.2018 um 09:04 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> panel-dsi-cm also seems not to do in->opes->disable(),
>>>>> so maybe it should really be removed.
>>>> 
>>>> Yes, that should be right.
>>>> 
>>>> There are two aspects:
>>>> 1. calling in->ops->disable is (was?) needed when chaining the panel behind the ssd2258 rotator chip so that it is informed about panel disable
>>>> 2. there was a big change in 4.20-rc1 how in and in->ops are set up and passed down to panel drivers
>>>> 
>>>> The panel-dsi-cm is not prepared for such encoder chaining.
>>>> 
>>>> So it might or might not be necessary to keep it. All this is something which I wasn't able to debug so far.
>>>> 
>>>> Of course we should not call in->ops->disable if in->ops == NULL :)
>>>> 
>>> well, being able to enable something and then not being able to disable
>>> it is highly counter-intuitive.
>> 
>> Of course. But all this is the result of trying to fix all problems introduced
>> by upstream changes in the core...
>> 
>> Up to 4.19 there was no in-ops bot a different struct pointer sequence that never was NULL.
>> 
> Well, time to get that panel driver upstream.

Hm. Tomi is quite reluctant to take panel drivers without
platforms that really use it...

And we have to get more than prototypes before we can expect
that any Pyra DT is accepted upstream.

> BTW it is not in->ops == NULL but in->ops->disable
> 
> I have uploaded my stuff to a branch
> pyra-display-4.20-rc4
> on
> https://github.com/akemnade/linux
> 
> so you can sort it in and we have a good base for debugging.

Ok. I'll take a look at it and compare with my local patches.

BR and thanks,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181201/b7756b7f/attachment-0001.asc>


More information about the Letux-kernel mailing list