Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: ksummit-discuss@lists.linuxfoundation.org,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	"vegard.nossum@gmail.com" <vegard.nossum@gmail.com>,
	"rafael.j.wysocki" <rafael.j.wysocki@intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Valentin Rothberg <valentinrothberg@gmail.com>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)
Date: Wed, 3 Aug 2016 16:17:05 +0200	[thread overview]
Message-ID: <20160803141705.GD23113@piout.net> (raw)
In-Reply-To: <2023901.fskbspMbmh@avalon>

Hi,

On 28/07/2016 at 19:00:36 +0300, Laurent Pinchart wrote :
> > So I'm complete outsider to media drivers so maybe my question is stupid
> > but I cannot resist: So how is the device bringup supposed to work for
> > devices where you have these cycles in the dependency graph? Do you just
> > bring up the controller and then the sensor and it works because the
> > controller doesn't need the clock from the sensor for startup?
> 
> That's pretty much the idea, yes. We first probe the controller, and register 
> a notifier to react to sensors being probed. The controller registers at probe 
> time the clocks it provides, so the sensor can get hold of them when it gets 
> probed. The controller is then notified that the sensor is available and 
> proceeds normally.
> 
> We also have a suspend/resume ordering issue, where we have to stop the 
> controller first (the hardware doesn't like when it loses the incoming video 
> stream while running), but we can't stop the clock just yet before the sensor 
> driver has a chance to suspend the sensor. We thus use the PM prepare and 
> complete callbacks to stop/restart the controller, and the PM suspend and 
> resume callbacks to stop/restart the clock. This is a hack that assumes that 
> the sensor gets probed after the controller (which is guaranteed by the fact 
> that the sensor needs a clock provided by the controller and thus probe will 
> be deferred if the controller hasn't been probed yet) and that the sensor 
> driver will use the PM suspend/resume callbacks, not the prepare/complete 
> callbacks. Ugly, but for now it works.
> 
> In the case of the Atmel device I mentioned we just don't reset the hardware 
> at probe time. We can still access the hardware registers we need without 
> getting a pixel clock, so it's not such a big deal. It would have been worse 
> if the hardware designers had decided to clock all registers with the pixel 
> clock.
> 

Well, I'm starting to be more and more interested in that thread as I'm
currently working on getting the Atmel "Backup mode" (CPU/SoC off and
DDR in self refresh) working and this is a device (re)initialization
hell.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com