[Letux-kernel] Long-Term kernels
David Shah
dave at ds0.me
Mon Dec 21 19:59:23 CET 2020
I am just repeating
xset dpms force off
xset dpms force on
until it fails - once it's failed you can get it to come back by
running the sequence of commands again a few times.
Note that this is with the OMAP5 X11 driver -
https://dev.pyra-handheld.com/packages/xserver-xorg-video-armsoc-omap5
I can't see a particularly concerning difference between our disable
function (which is where the problems seem to start) and other panel
drivers. I half wonder if the problem might be in the OMAP DSI stuff
rather than the panel driver.
Best
David
On Mon, 2020-12-21 at 19:56 +0100, H. Nikolaus Schaller wrote:
>
> > Am 21.12.2020 um 19:51 schrieb David Shah <dave at ds0.me>:
> >
> > And... seems I spoke to soon about DPMS working ;) - but at least
> > it
> > does now work sometimes.
> >
> > There's now a new, intermittent DSI related failure going on that I
> > think is unrelated to the last problem:
> >
> > [ 53.141659] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_disable
> > [ 53.451626] DSI: omapdss DSI error: DSI error, irqstatus 4000
> > [ 53.460384] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_unprepare
> > [ 53.468136] panel-btl507212-w677l 58004000.encoder.0:
> > power_off()
> > [ 53.486342] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_reset(active)
> > [ 53.503567] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_regulator(off)
> > [ 53.531918] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_unprepare finished
> > [ 53.541620] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_prepare
> > [ 53.549286] panel-btl507212-w677l 58004000.encoder.0: power_on()
> > [ 53.555619] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_reset(active)
> > [ 53.563112] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_regulator(on)
> > [ 53.636501] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_reset(inactive)
> > [ 53.666897] panel-btl507212-w677l 58004000.encoder.0: dsi:
> > w677l_write(dcs 11) [0]
> > [ 53.684628] DSI: omapdss DSI error: Error while sending BTA:
> > 4000
> > [ 53.691461] DSI: omapdss DSI error: bta sync failed
> > [ 53.697731] panel-btl507212-w677l 58004000.encoder.0: write
> > cmd/reg(11) failed: -5
> > [ 53.708303] panel-btl507212-w677l 58004000.encoder.0: sequence
> > failed: 0
> > [ 53.732510] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_enable
> > [ 53.739193] panel-btl507212-w677l 58004000.encoder.0:
> > w677l_enable()
> > powered on()
> >
> >
> > it's possible that the panel is being disabled at the wrong point
> > and
> > messing up the DSI state.
>
> Indeed. Tomi was not very sure about properly sequencing these
> things.
> (Note: he has a new e-mail address).
>
> Is there a method or specific command sequence to trigger or
> reproduce this problem?
>
> BR and thanks,
> Nikolaus
>
>
> >
> >
> > On Mon, 2020-12-21 at 18:40 +0000, David Shah wrote:
> > > It was just another pyra_defconfig problem in the end, sent a
> > > patch.
> > >
> > > And the DPMS issue now seems to be resolved :)
> > >
> > > Next problem I've noticed is that pvr init is failing, I think I
> > > saw
> > > some conversation between you and Tony about that back in
> > > November
> > > that
> > > I'll look into.
> > >
> > > Best
> > >
> > > David
> > >
> > > On Mon, 2020-12-21 at 19:32 +0100, H. Nikolaus Schaller wrote:
> > > >
> > > > > Am 21.12.2020 um 19:21 schrieb David Shah <dave at ds0.me>:
> > > > >
> > > > > Trying letux-5.10.y and the annoying display-not-being-loaded
> > > > > issue
> > > > > has
> > > > > come back to bite again, even though we are now baking
> > > > > omapdrm
> > > > > into
> > > > > the
> > > > > kernel in the Pyra config.
> > > >
> > > > Strangely I haven't seen that recently. And it is questionable
> > > > if
> > > > it
> > > > is solved by the new panel driver architecture.
> > > >
> > > > But you could do a test by merging letux/boe-w677-dsi-panel-v4.
> > > > This
> > > > should include the new omapdrm and the new panel driver.
> > > >
> > > > If not someone has to dig into it and search for the
> > > > initialization
> > > > race.
> > > >
> > > > BR,
> > > > Nikolaus
> > > >
> > > > >
> > > > > On Mon, 2020-12-21 at 18:14 +0100, H. Nikolaus Schaller
> > > > > wrote:
> > > > > >
> > > > > > > Am 21.12.2020 um 18:00 schrieb David Shah <dave at ds0.me>:
> > > > > > >
> > > > > > > It would be nice to get 5.10 up and running on the Pyra,
> > > > > >
> > > > > > Well, for me it is running and I am not aware of bigger
> > > > > > issues.
> > > > > > But I
> > > > > > am not using it daily so that I may miss some problems.
> > > > > >
> > > > > > > despite not containing
> > > > > > > the new panel driver yet (afaik).
> > > > > >
> > > > > > Yes, the new panel driver will not come before v5.12. But
> > > > > > IMHO
> > > > > > it
> > > > > > has
> > > > > > no functional difference. Is just much cleaner and
> > > > > > upstreamable
> > > > > > code.
> > > > > > So no need to wait for it.
> > > > > >
> > > > > > >
> > > > > > > Though I haven't tested, I suspect the biggest issue is
> > > > > > > going
> > > > > > > to be
> > > > > > > the
> > > > > > > DPMS/stuck atomic update issue that is somewhere in the
> > > > > > > display/DRM
> > > > > > > code
> > > > > > > discussed previously and has likely been present since
> > > > > > > 5.7
> > > > > > > ish.
> > > > > >
> > > > > > I think there was some fix a while ago which may also be in
> > > > > > 5.9.
> > > > > > But I currently don't have the Pyra in operation to check.
> > > > > >
> > > > > > Generally I think the best strategy for PyraOS would be to
> > > > > > use
> > > > > > and
> > > > > > maintain
> > > > > > 5.10.y as the next long-term kernel.
> > > > > >
> > > > > > BR,
> > > > > > Nikolaus
> > > > > >
> > > > > > >
> > > > > > > David
> > > > > > >
> > > > > > > On Mon, 2020-12-21 at 16:12 +0100, H. Nikolaus Schaller
> > > > > > > wrote:
> > > > > > > > v5.9.16 was just tagged [EOL].
> > > > > > > >
> > > > > > > > According to
> > > > > > > > https://www.kernel.org/category/releases.html the
> > > > > > > > long-term
> > > > > > > > kernels will be:
> > > > > > > >
> > > > > > > > - 5.10
> > > > > > > > - 5.4
> > > > > > > > - 4.19
> > > > > > > > - 4.14
> > > > > > > > - 4.9
> > > > > > > > - 4.4 (maintenance ends in 2 months - but we anyways
> > > > > > > > have
> > > > > > > > no
> > > > > > > > letux-4.4)
> > > > > > > >
> > > > > > > > For Letux-Kernels we will follow this scheme.
> > > > > > > >
> > > > > > > > BR,
> > > > > > > > Nikolaus
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > https://projects.goldelico.com/p/gta04-kernel/
> > > > > > > > Letux-kernel mailing list
> > > > > > > > Letux-kernel at openphoenux.org
> > > > > > > > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > https://projects.goldelico.com/p/gta04-kernel/
> > > > > > > Letux-kernel mailing list
> > > > > > > Letux-kernel at openphoenux.org
> > > > > > > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> > > > > >
> > > > > > _______________________________________________
> > > > > > Kernel mailing list
> > > > > > Kernel at pyra-handheld.com
> > > > > > http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
> > > > >
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > https://projects.goldelico.com/p/gta04-kernel/
> > > Letux-kernel mailing list
> > > Letux-kernel at openphoenux.org
> > > http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
> >
> >
>
More information about the Letux-kernel
mailing list