Re: [PATCH v5 1/4] dt-bindings: media: imx258: add bindings for IMX258 sensor

From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: devicetree@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-clk@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	NXP Linux Team <linux-imx@nxp.com>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Fabio Estevam <festevam@gmail.com>,
	Michael Turquette <mturquette@baylibre.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v5 1/4] dt-bindings: media: imx258: add bindings for IMX258 sensor
Date: Tue, 20 Oct 2020 15:46:54 +0300	[thread overview]
Message-ID: <20201020124654.GX13341@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20201020122621.GA126891@kozik-lap>

On Tue, Oct 20, 2020 at 02:26:21PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 20, 2020 at 03:00:58PM +0300, Sakari Ailus wrote:
> > Hi Krzysztof,
> > 
> > On Tue, Oct 20, 2020 at 12:54:09PM +0200, Krzysztof Kozlowski wrote:
> > > On Tue, 20 Oct 2020 at 12:38, Sakari Ailus <sakari.ailus@linux.intel.com> wrote:
> > > >
> > > > Hi Krzysztof,
> > > >
> > > > On Mon, Oct 19, 2020 at 07:02:44PM +0200, Krzysztof Kozlowski wrote:
> > > > > Add bindings for the IMX258 camera sensor.  The bindings, just like the
> > > > > driver, are quite limited, e.g. do not support regulator supplies.
> > > > >
> > > > > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes since v4:
> > > > > 1. Add clock-lanes,
> > > > > 2. Add Rob's review,
> > > > > 3. Add one more example and extend existing one,
> > > > > 4. Add common clock properties (assigned-*).
> > > >
> > > > Using the assigned-* clock properties may be workable for this driver at
> > > > the moment. But using these properties does not guarantee the external
> > > > clock frequency intended to be used on the hardware.
> > > 
> > > It guarantees it. The clock frequency will be as expected (except if
> > > someone misconfigures the DTS).
> > 
> > Is that guaranteed?
> > 
> > I'm not saying no to the approach, but if we change how camera sensor DT
> > bindings are defined, I'd prefer an informed decision is made on the
> > matter.
> > 
> > > 
> > > > Using other
> > > > frequencies *is not* expected to work. That applies to this driver as well.
> > > 
> > > This is the binding which is HW description. According to HW datasheet
> > > other frequencies from described range are accepted and expected to
> > > work.
> > 
> > As per datasheet, yes, different external clock frequencies can be used.
> > But the link frequency is still not independent of the external clock
> > frequency.
> > 
> > The properties of the sensor's PLL tree determines what can be achieved
> > given a certain external clock frequency. So picking a wrong external clock
> > frequency quite possibly means that none of the designated link frequencies
> > are available, rendering the sensor inoperable.
> 
> The driver then controls the HW and knows exactly what is needed. If
> link frequency (which has its own DT property) requires some clock
> frequency, the driver will configure the clock to that value. The same

Well it doesn't if it doesn't get that information from DT.

The frequency is usually a range, and looking at these bindings, it's from
6 MHz to 27 MHz. That'd be a lot of frequencies for a driver to try.

> going other direction. Driver has the knowledge about both its input
> clock and link frequency, therefore it can make the best decision.

Again you're assuming a particular driver implementation.

Typically only a few frequencies are really available on platforms, so a in
practice a driver would not be able to get any requested frequency. I
wouldn't start hard-coding every possible frequency to camera sensor
drivers.

> > > > This, instead of the clock-frequency property, effectively removes the
> > > > ability to set the correct frequency from the driver, at least with current
> > > > set of the used APIs.
> > > 
> > > It seems you confuse DT bindings with some specific driver
> > > implementation. Bindings do not describe the driver behavior but the
> > > HW. The ability to set the correct frequency from the driver is not
> > > removed. It was never part of the bindings and never should. It is
> > > part of the driver.
> > > 
> > > >
> > > > I suppose you could add a function to set the assigned clock frequency and
> > > > keep it, just as clk_set_rate_exclusive does?
> 
> I did not reply to this comment, so let me know. Of course, one could
> add such functions. It's not a job for DT bindings, though.

I'm not suggesting to add it to DT binding patch. What I'm saying that with
this approach is looks like it may well be needed.

-- 
Regards,

Sakari Ailus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel