Re: [PATCH v3] pinctrl: qcom: Handle broken/missing PDC dual edge IRQs on sc7180
From: John Stultz
Date: Mon Aug 03 2020 - 20:48:51 EST
On Mon, Aug 3, 2020 at 2:58 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> On Mon, Aug 3, 2020 at 2:06 PM John Stultz <john.stultz@xxxxxxxxxx> wrote:
> > On Tue, Jul 14, 2020 at 8:08 AM Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
> > >
> > > Depending on how you look at it, you can either say that:
> > > a) There is a PDC hardware issue (with the specific IP rev that exists
> > > on sc7180) that causes the PDC not to work properly when configured
> > > to handle dual edges.
> > > b) The dual edge feature of the PDC hardware was only added in later
> > > HW revisions and thus isn't in all hardware.
> > >
> > > Regardless of how you look at it, let's work around the lack of dual
> > > edge support by only ever letting our parent see requests for single
> > > edge interrupts on affected hardware.
> > >
> > > NOTE: it's possible that a driver requesting a dual edge interrupt
> > > might get several edges coalesced into a single IRQ. For instance if
> > > a line starts low and then goes high and low again, the driver that
> > > requested the IRQ is not guaranteed to be called twice. However, it
> > > is guaranteed that once the driver's interrupt handler starts running
> > > its first instruction that any new edges coming in will cause the
> > > interrupt to fire again. This is relatively commonplace for dual-edge
> > > gpio interrupts (many gpio controllers require software to emulate
> > > dual edge with single edge) so client drivers should be setup to
> > > handle it.
> > >
> > > Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
> > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> > Just as a heads up. I started seeing boot failures (crashes really
> > early before we get serial output) with db845c when testing with the
> > android-mainline tree that pulled v5.8 in.
> Even before earlycon? Ick. For me earlycon comes up way before
> pinctrl and I thought that, by design, earlycon came up so dang early
> that you could debug almost anything with it.
> To confirm, I could even drop into earlycon_kgdb (which starts later
> than earlycon), then set a breakpoint on msm_pinctrl_probe() and I'd
> hit my breakpoint. Enabling earlycon should be super easy these
> days--just add the "earlycon" command line parameter and the kernel
> seems to do the rest of the magic based on the "stdout-path". I guess
> if your bootloader doesn't cooperate and leave the system in an OK
> state then you'll be in bad shape, but otherwise it should be nice...
> NOTE: if you have earlycon and this is still causing crashes before
> earlycon starts, the only things I can think of are side effects of
> this patch. Could it have made your kernel just a little too big and
> now you're overflowing some hard limit of the bootloader? Maybe
> you're hitting a ccache bug and using some stale garbage (don't laugh,
> this happened to me the other year)? Maybe there's a pointer bug and
> this moves addresses just enough to make it cause havoc?
Sorry! False positive on this one. The android-mainline tree has
serial drivers as modules, so earlycon doesn't help right off.
I reworked the config so I could use earlycon and realized the trouble
was with the new selected configs in this patch which need to also be
selected in the GKI kernel.
Apologies for the noise.