All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>
Subject: Re: [RFC] media DT bindings
Date: Tue, 31 Jul 2012 11:26:27 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.1207311058140.27888@axis700.grange> (raw)
In-Reply-To: <1537713.eFPuk01afu@avalon>

On Fri, 27 Jul 2012, Laurent Pinchart wrote:

> Hi Sylwester,
> 
> On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
> > On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:

[snip]

> > >>> An sh-mobile CEU DT node could look like
> > >>> 
> > >>> 	ceu0@0xfe910000 = {
> > >>> 	
> > >>> 		compatible = "renesas,sh-mobile-ceu";
> > >>> 		reg =<0xfe910000 0xa0>;
> > >>> 		interrupts =<0x880>;
> > >>> 		bus-width =<16>;		/* #lines routed on the board */
> > >>> 		clock-frequency =<50000000>;	/* max clock */
> > >>> 		#address-cells =<1>;
> > >>> 		#size-cells =<0>;
> > >>> 		...
> > >>> 		ov772x-1 = {
> > >>> 		
> > >>> 			reg =<0>;
> > 
> > This property might be redundant, we already have the "client" phandle
> > pointing to "ov772x@0x21-0", which has all interesting properties inside
> > it. Other than there is probably no reasonable usage for it under
> > "ceu0@0xfe910000" node ?
> > 
> > >>> 			client =<&ov772x@0x21-0>;
> > >>> 			local-pad = "parallel-sink";
> > >>> 			remote-pad = "parallel-source";
> > >> 
> > >> I'm not sure I like that. Is it really needed when we already have
> > >> the child/parent properties around ?
> > > 
> > > I think it is. Both the host and the client can have multiple pads (e.g.,
> > > parallel / serial). These properties specify which pads are used and make
> > > the translation between DT data and our subdev / pad APIs simpler.
> > 
> > OK, sorry, but isn't it all about just specifying what sort of data bus
> > is used ? :-)
> 
> In some (many/most ?) cases probably, but not in all of them.
> 
> What about merging the client and remote-pad properties ? The resulting 
> property would then reference a pad with <&ov772x@0x21-0 0>.

What would the "0" parameter mean then? Pad #0? But aren't these numbers 
device specific? Maybe not a huge deal, but these numbers are defind by 
the driver, right? Not the DT itself. So, drivers then will have to take 
care not to change their pad numbering. Whereas using strings, we can fix 
strings in the common V4L DT spec and keep them standard across devices 
and drivers. Then drivers might be less likely to change these assignments 
randomly;-)

[snip]

> > I'd like just to point one detail here, as sensor subdev drivers control
> > their voltage regulators and RESET/STANDBY (gpio) signals, they should
> > also be able to control the master clock. In order to ensure proper power
> > up/down sequences. It is a bad practice to enable clocks before voltage
> > supplies are switched on and we shouldn't have that as a general
> > assumption at the kernel frameworks.
> > 
> > One possible solution would be to have host/bridge drivers to register
> > a clkdev entry for I2C client device, so it can acquire the clock through
> > just clk_get(). We would have to ensure the clock is not tried to be
> > accessed before it is registered by a bridge. This would require to add
> > clock handling code to all sensor/encoder subdev drivers though..
> 
> I thik it's a good practice to add clock management to subdevs anyway, and the 
> common clock framework should make that easy (or at least not too difficult). 
> We can migrate subdevs one by one as we add DT support for them.

Yes, this would be good.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

  reply	other threads:[~2012-07-31  9:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11 14:27 [RFC] media DT bindings Guennadi Liakhovetski
2012-07-13 14:57 ` Sylwester Nawrocki
2012-07-16 11:41   ` Guennadi Liakhovetski
2012-07-18 17:00     ` Sylwester Nawrocki
2012-07-23 12:14       ` Mark Brown
2012-07-30 21:02         ` Sylwester Nawrocki
2012-07-27 11:25       ` Laurent Pinchart
2012-07-31  9:26         ` Guennadi Liakhovetski [this message]
2012-07-31 12:08           ` Laurent Pinchart
2012-07-31 12:39             ` Guennadi Liakhovetski
2012-07-31 21:22               ` Laurent Pinchart
2012-07-31 23:29                 ` Stephen Warren
2012-08-01  5:59                   ` Laurent Pinchart
2012-08-01 15:57                     ` Stephen Warren
2012-08-01 15:57                       ` Stephen Warren
2012-08-01  6:47                 ` Guennadi Liakhovetski
2012-08-01  7:19                   ` Laurent Pinchart
2012-08-04  9:27                     ` Guennadi Liakhovetski
2012-07-17 19:37 ` Hans Verkuil
2012-07-27 11:26   ` Laurent Pinchart
2012-07-27 11:38     ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.1207311058140.27888@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=sylvester.nawrocki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.