From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guennadi Liakhovetski Subject: Re: [ANN] Meeting minutes of the Cambourne meeting Date: Tue, 30 Aug 2011 00:20:09 +0200 (CEST) Message-ID: References: <201107261647.19235.laurent.pinchart@ideasonboard.com> <201108081750.07000.laurent.pinchart@ideasonboard.com> <4E5A2657.7030605@gmail.com> <201108291508.59649.laurent.pinchart@ideasonboard.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <201108291508.59649.laurent.pinchart@ideasonboard.com> Sender: linux-media-owner@vger.kernel.org To: Laurent Pinchart Cc: Sylwester Nawrocki , linux-media , Hans Verkuil , Sakari Ailus , Tuukka Toivonen , Sylwester Nawrocki , Tomasz Stanislawski , Marek Szyprowski , devicetree-discuss@lists.ozlabs.org, Mauro Carvalho Chehab List-Id: devicetree@vger.kernel.org On Mon, 29 Aug 2011, Laurent Pinchart wrote: [snip] > My idea was to let the kernel register all devices based on the DT or board > code. When the V4L2 host/bridge driver gets registered, it will then call a > V4L2 core function with a list of subdevs it needs. The V4L2 core would store > that information and react to bus notifier events to notify the V4L2 > host/bridge driver when all subdevs are present. At that point the host/bridge > driver will get hold of all the subdevs and call (probably through the V4L2 > core) their .registered operation. That's where the subdevs will get access to > their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access the hardware? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/