Re: [PATCH 0/5] rcar-vin: Support suspend and resume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Oct 16, 2020 at 2:23 PM Niklas Söderlund
<niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> On 2020-10-16 13:26:25 +0200, Geert Uytterhoeven wrote:
> > On Fri, Oct 16, 2020 at 12:46 PM Niklas Söderlund
> > <niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> > > On 2020-10-16 09:06:20 +0200, Geert Uytterhoeven wrote:
> > > > On Fri, Oct 16, 2020 at 4:01 AM Niklas Söderlund
> > > > <niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> > > > > This series add suspend and resume support directly to R-Car VIN and
> > > > > indirectly to R-Car CSI-2 and other subdevices in the VIN capture
> > > > > pipeline. The capture pipeline is stopped when suspending and started
> > > > > when resuming, all while retaining the buffers provided from user-space.
> > > > > This makes the start and stop of the pipeline transparent from an
> > > > > application point of view.
> > > > >
> > > > > As the pipeline is switched off subdevices that poweroff themself when
> > > > > not in use (such as R-Car CSI-2) are also switched off and are
> > > > > indirectly serviced by the suspend support in VIN.
> > > >
> > > > Thanks for your series!
> > > >
> > > > > This work is based on-top of the media-tree and is tested on both R-Car
> > > > > Gen2 and Gen3 without any regressions.
> > > >
> > > > FTR: did you test on Gen3 with both s2idle and s2ram, the latter powering
> > > > off the SoC?
> > >
> > > I have only been able to test it with s2idle. My issue is that s2ram
> > > fails to reconnect the Ethernet (ravb) and I use nfsroot. If I instead
> > > use a initramfs I can resume from s2ram but I don't have the setup to
> > > test capture in that environment.
> >
> > >     [  347.775223] libphy: ravb_mii: probed
> > >     [  347.782808] mdio_bus e6800000.ethernet-ffffffff: MDIO device at address 0 is missing.
> > >     [  347.794508] ravb e6800000.ethernet eth0: failed to connect PHY
> > >     [  347.802223] PM: dpm_run_callback(): ravb_resume+0x0/0x190 returns -2
> > >     [  347.808739] PM: Device e6800000.ethernet failed to resume: error -2
> > >     [  347.929701] ata1: link resume succeeded after 1 retries
> > >     [  347.989934] OOM killer enabled.
> > >     [  347.993184] Restarting tasks ... done.
> > >     [  348.004321] PM: suspend exit
> > >     [  348.039400] ata1: SATA link down (SStatus 0 SControl 300)
> > >     [  529.376515] nfs: server 10.0.1.1 not responding, still trying
> > >     [  529.376702] nfs: server 10.0.1.1 not responding, still trying
> > >     [  529.385628] nfs: server 10.0.1.1 not responding, still trying
> > >     ** Board never reaches user-space **
> > >
> > > Is there a known fix for this?
> >
> > Please try cherry-picking commit 77972b55fb9d35d4 ("Revert "ravb: Fixed
> > to be able to unload modules"") from v5.9.
>
> Thanks that did the trick!

Glad to hear that!

> Unfortunately it revealed a new problem related to capturing after a
> s2ram, the ADV7482 does not support s2ram and when it gets reset it no
> longer is possible to communicate to it over i2c. This in turn breaks
> the VIN s2ram test as of course it can not resume capture if it can't
> talk to the ADV7482.
>
> I reproduced this issue directly on top of v5.9. I'm not streaming at
> the time of s2ram. The test is to read the video standard reported by
> the AFE subdevice provided by the ADV7482 before and after s2ram. As
> shown it does not respond after a s2ram but unbind/bind it forcing it to
> reinit itself solves the issue.

I guess the pesky adv7482 needs its secondary addresses to be reprogrammed
in its resume handler?

> I think this issue needs to be resolved before I can truly verify the
> operation of this series post s2ram. Do you think this series should be
> held until then or does it bring enough value (s2idle) while not
> introducing any regressions? s2ram is just as broken before as after :-)

Well, my main worry is that it would hide a so far unknown s2ram resume
issue in the rcar-vin driver.  I've seen too many  "Add suspend/resume"
commits yielding drivers where suspend/resume still didn't work
afterwards.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux