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

Andreas Kemnade andreas at kemnade.info
Sat Dec 1 15:37:58 CET 2018


On Sat, 1 Dec 2018 13:59:14 +0100
"H. Nikolaus Schaller" <hns at goldelico.com> wrote:

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

I touched the nub, and one stripe appeared. First list light at the
horizon.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181201/8fab4656/attachment.asc>


More information about the Letux-kernel mailing list