From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Geert Uytterhoeven <geert+renesas@glider.be>, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lad Prabhakar <prabhakar.csengg@gmail.com>, Maxime Ripard <maxime@cerno.tech> Subject: Re: [PATCH v5 2/5] media: i2c: ov5645: Drop reading clock-frequency dt-property Date: Tue, 14 Apr 2020 23:55:52 +0300 [thread overview] Message-ID: <20200414205552.GN19819@pendragon.ideasonboard.com> (raw) In-Reply-To: <20200407151401.GA5206@paasikivi.fi.intel.com> Hi Sakari, On Tue, Apr 07, 2020 at 06:14:01PM +0300, Sakari Ailus wrote: > On Tue, Apr 07, 2020 at 03:21:06PM +0300, Laurent Pinchart wrote: > > On Tue, Apr 07, 2020 at 09:22:41AM +0300, Sakari Ailus wrote: > >> On Mon, Apr 06, 2020 at 08:32:34PM +0300, Laurent Pinchart wrote: > >>> On Mon, Apr 06, 2020 at 07:51:08PM +0300, Sakari Ailus wrote: > >>>> On Mon, Apr 06, 2020 at 05:42:38PM +0100, Lad Prabhakar wrote: > >>>>> Modes in the driver are based on xvclk frequency fixed to 24MHz, but where > >>>>> as the OV5645 sensor can support the xvclk frequency ranging from 6MHz to > >>>>> 24MHz. So instead making clock-frequency as dt-property just let the > >>>>> driver enforce the required clock frequency. > >>>> > >>>> Even if some current systems where the driver is used are using 24 MHz > >>>> clock, that doesn't mean there wouldn't be systems using another frequency > >>>> that the driver does not support right now. > >>>> > >>>> The driver really should not set the frequency unless it gets it from DT, > >>>> but I think the preferred means is to use assigned-clock-rates instead, and > >>>> not to involve the driver with setting the frequency. > >>>> > >>>> Otherwise we'll make it impossible to support other frequencies, at least > >>>> without more or less random defaults. > >>> > >>> We're running in circles here. > >>> > >>> As the driver only supports 24MHz at the moment, the frequency should be > >>> set by the driver, as it's a driver limitation. We can then work on > >>> supporting additional frequencies, which will require DT to provide a > >>> list of supported frequencies for the system, but that can be done on > >>> top. > >> > >> I guess it would be possible to use different external clock frequencies on > >> a sensor in a given system but that seems to be a bit far fetched, to the > >> extent I've never seen anyone doing that in practice. > >> > >> Originally, the driver set the frequency based on the clock-frequency > >> property. If we're removing that but use a fixed frequency instead, then > >> how is that going to work going forward when someone adds support for other > >> frequencies in the driver and has a system requiring that, while there are > >> some other platforms relying on the driver setting a particular frequency? > > > > The standard property for this is link-frequencies, not clock-frequency. > > Deprecating clock-frequency now paves the way to use the standard > > property later when/if someone implements support for additional > > frequencies. > > The external clock frequency and link frequency are different indeed, but > they are related. The link frequency has been selected in a way that it is > possible to generate that exact frequency using the chosen external clock > frequency. If you change the external clock frequency, chances are good > there is no PLL configuration to generate that link frequency. But aren't we supposed to pick the clock frequency based on the link frequency specified in DT ? In any case, this policy needs to be carefully documented. > >> Although, if you're saying that this driver only needs to work with DT that > >> comes with the kernel and you don't care about DT binary compatibility, > >> this would be fine. > > > > I believe this series to not break backward compatibility, as the driver > > only works with a 24MHz clock, so I expect all DTs to specify that. > > What you're still doing here is defining the DT bindings based on the > current driver implementation, not the device properties. Quite the contrary, the device doesn't require any particular input clock frequency, so we're removing that from DT :-) Specifying the clock frequency in DT is in my opinion a manual workaround for not computing it at runtime based on the desired link frequency, while the link frequency is a property of the system as it specifies the range of link frequencies that are safe to use from an EMC point of view. -- Regards, Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Geert Uytterhoeven <geert+renesas@glider.be>, Fabio Estevam <festevam@gmail.com>, Sascha Hauer <s.hauer@pengutronix.de>, Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>, Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>, linux-kernel@vger.kernel.org, Lad Prabhakar <prabhakar.csengg@gmail.com>, Rob Herring <robh+dt@kernel.org>, NXP Linux Team <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Maxime Ripard <maxime@cerno.tech>, Mauro Carvalho Chehab <mchehab@kernel.org>, Shawn Guo <shawnguo@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Subject: Re: [PATCH v5 2/5] media: i2c: ov5645: Drop reading clock-frequency dt-property Date: Tue, 14 Apr 2020 23:55:52 +0300 [thread overview] Message-ID: <20200414205552.GN19819@pendragon.ideasonboard.com> (raw) In-Reply-To: <20200407151401.GA5206@paasikivi.fi.intel.com> Hi Sakari, On Tue, Apr 07, 2020 at 06:14:01PM +0300, Sakari Ailus wrote: > On Tue, Apr 07, 2020 at 03:21:06PM +0300, Laurent Pinchart wrote: > > On Tue, Apr 07, 2020 at 09:22:41AM +0300, Sakari Ailus wrote: > >> On Mon, Apr 06, 2020 at 08:32:34PM +0300, Laurent Pinchart wrote: > >>> On Mon, Apr 06, 2020 at 07:51:08PM +0300, Sakari Ailus wrote: > >>>> On Mon, Apr 06, 2020 at 05:42:38PM +0100, Lad Prabhakar wrote: > >>>>> Modes in the driver are based on xvclk frequency fixed to 24MHz, but where > >>>>> as the OV5645 sensor can support the xvclk frequency ranging from 6MHz to > >>>>> 24MHz. So instead making clock-frequency as dt-property just let the > >>>>> driver enforce the required clock frequency. > >>>> > >>>> Even if some current systems where the driver is used are using 24 MHz > >>>> clock, that doesn't mean there wouldn't be systems using another frequency > >>>> that the driver does not support right now. > >>>> > >>>> The driver really should not set the frequency unless it gets it from DT, > >>>> but I think the preferred means is to use assigned-clock-rates instead, and > >>>> not to involve the driver with setting the frequency. > >>>> > >>>> Otherwise we'll make it impossible to support other frequencies, at least > >>>> without more or less random defaults. > >>> > >>> We're running in circles here. > >>> > >>> As the driver only supports 24MHz at the moment, the frequency should be > >>> set by the driver, as it's a driver limitation. We can then work on > >>> supporting additional frequencies, which will require DT to provide a > >>> list of supported frequencies for the system, but that can be done on > >>> top. > >> > >> I guess it would be possible to use different external clock frequencies on > >> a sensor in a given system but that seems to be a bit far fetched, to the > >> extent I've never seen anyone doing that in practice. > >> > >> Originally, the driver set the frequency based on the clock-frequency > >> property. If we're removing that but use a fixed frequency instead, then > >> how is that going to work going forward when someone adds support for other > >> frequencies in the driver and has a system requiring that, while there are > >> some other platforms relying on the driver setting a particular frequency? > > > > The standard property for this is link-frequencies, not clock-frequency. > > Deprecating clock-frequency now paves the way to use the standard > > property later when/if someone implements support for additional > > frequencies. > > The external clock frequency and link frequency are different indeed, but > they are related. The link frequency has been selected in a way that it is > possible to generate that exact frequency using the chosen external clock > frequency. If you change the external clock frequency, chances are good > there is no PLL configuration to generate that link frequency. But aren't we supposed to pick the clock frequency based on the link frequency specified in DT ? In any case, this policy needs to be carefully documented. > >> Although, if you're saying that this driver only needs to work with DT that > >> comes with the kernel and you don't care about DT binary compatibility, > >> this would be fine. > > > > I believe this series to not break backward compatibility, as the driver > > only works with a 24MHz clock, so I expect all DTs to specify that. > > What you're still doing here is defining the DT bindings based on the > current driver implementation, not the device properties. Quite the contrary, the device doesn't require any particular input clock frequency, so we're removing that from DT :-) Specifying the clock frequency in DT is in my opinion a manual workaround for not computing it at runtime based on the desired link frequency, while the link frequency is a property of the system as it specifies the range of link frequencies that are safe to use from an EMC point of view. -- Regards, Laurent Pinchart _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-14 20:56 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-06 16:42 [PATCH v5 0/5] ov5645: Deprecate usage of the clock-frequency Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 16:42 ` [PATCH v5 1/5] media: dt-bindings: media: i2c: Deprecate usage of the clock-frequency property Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 17:30 ` Laurent Pinchart 2020-04-06 17:30 ` Laurent Pinchart 2020-04-07 7:35 ` Lad, Prabhakar 2020-04-07 7:35 ` Lad, Prabhakar 2020-04-07 7:14 ` Geert Uytterhoeven 2020-04-07 7:14 ` Geert Uytterhoeven 2020-04-14 13:55 ` Rob Herring 2020-04-14 13:55 ` Rob Herring 2020-04-06 16:42 ` [PATCH v5 2/5] media: i2c: ov5645: Drop reading clock-frequency dt-property Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 16:51 ` Sakari Ailus 2020-04-06 16:51 ` Sakari Ailus 2020-04-06 17:11 ` Lad, Prabhakar 2020-04-06 17:11 ` Lad, Prabhakar 2020-04-06 17:32 ` Laurent Pinchart 2020-04-06 17:32 ` Laurent Pinchart 2020-04-07 6:22 ` Sakari Ailus 2020-04-07 6:22 ` Sakari Ailus 2020-04-07 12:21 ` Laurent Pinchart 2020-04-07 12:21 ` Laurent Pinchart 2020-04-07 15:14 ` Sakari Ailus 2020-04-07 15:14 ` Sakari Ailus 2020-04-14 20:55 ` Laurent Pinchart [this message] 2020-04-14 20:55 ` Laurent Pinchart 2020-04-14 20:56 ` Laurent Pinchart 2020-04-14 20:56 ` Laurent Pinchart 2020-04-15 8:19 ` Maxime Ripard 2020-04-15 8:19 ` Maxime Ripard 2020-04-15 16:27 ` Sakari Ailus 2020-04-15 16:27 ` Sakari Ailus 2020-04-17 2:09 ` Laurent Pinchart 2020-04-17 2:09 ` Laurent Pinchart 2020-04-06 17:34 ` Laurent Pinchart 2020-04-06 17:34 ` Laurent Pinchart 2020-04-07 7:36 ` Lad, Prabhakar 2020-04-07 7:36 ` Lad, Prabhakar 2020-04-07 7:16 ` Geert Uytterhoeven 2020-04-07 7:16 ` Geert Uytterhoeven 2020-04-07 7:40 ` Lad, Prabhakar 2020-04-07 7:40 ` Lad, Prabhakar 2020-04-07 12:18 ` Laurent Pinchart 2020-04-07 12:18 ` Laurent Pinchart 2020-04-06 16:42 ` [PATCH v5 3/5] media: i2c: ov5645: Turn probe error into warning for xvclk frequency mismatch Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 17:35 ` Laurent Pinchart 2020-04-06 17:35 ` Laurent Pinchart 2020-04-07 7:19 ` Geert Uytterhoeven 2020-04-07 7:19 ` Geert Uytterhoeven 2020-04-07 7:43 ` Lad, Prabhakar 2020-04-07 7:43 ` Lad, Prabhakar 2020-04-06 16:42 ` [PATCH v5 4/5] ARM: dts: imx6qdl-wandboard: Drop clock-frequency property from ov5645 node Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 17:36 ` Laurent Pinchart 2020-04-06 17:36 ` Laurent Pinchart 2020-04-06 16:42 ` [PATCH v5 5/5] media: dt-bindings: media: i2c: convert ov5645 bindings to json-schema Lad Prabhakar 2020-04-06 16:42 ` Lad Prabhakar 2020-04-06 17:43 ` Laurent Pinchart 2020-04-06 17:43 ` Laurent Pinchart 2020-04-07 7:46 ` Lad, Prabhakar 2020-04-07 7:46 ` Lad, Prabhakar 2020-04-15 14:43 ` Rob Herring 2020-04-15 14:43 ` Rob Herring
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=20200414205552.GN19819@pendragon.ideasonboard.com \ --to=laurent.pinchart@ideasonboard.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=geert+renesas@glider.be \ --cc=kernel@pengutronix.de \ --cc=kieran.bingham+renesas@ideasonboard.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime@cerno.tech \ --cc=mchehab@kernel.org \ --cc=prabhakar.csengg@gmail.com \ --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=sakari.ailus@linux.intel.com \ --cc=shawnguo@kernel.org \ /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: linkBe 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.