From: Robert Foss <robert.foss@linaro.org> To: Maxime Ripard <maxime@cerno.tech> Cc: Sakari Ailus <sakari.ailus@iki.fi>, Dongchun Zhu <dongchun.zhu@mediatek.com>, Fabio Estevam <festevam@gmail.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Tomasz Figa <tfiga@chromium.org>, linux-media <linux-media@vger.kernel.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v6 1/3] media: dt-bindings: ov8856: Document YAML bindings Date: Tue, 7 Apr 2020 13:29:05 +0200 [thread overview] Message-ID: <CAG3jFyvd32pWppubMoOoyH9eO2XLjwUXMC7p4xtv8m+JkPv6vw@mail.gmail.com> (raw) In-Reply-To: <20200407083647.4mocdl7aqa3x737q@gilmour.lan> Hey Maixme & Sakari, On Tue, 7 Apr 2020 at 10:36, Maxime Ripard <maxime@cerno.tech> wrote: > > Hi Sakari, > > On Mon, Apr 06, 2020 at 11:35:07AM +0300, Sakari Ailus wrote: > > > But that 19.2MHz is not a limitation of the device itself, it's a > > > limitation of our implementation, so we can instead implement > > > something equivalent in Linux using a clk_set_rate to 19.2MHz (to make > > > sure that our parent clock is configured at the right rate) and the > > > clk_get_rate and compare that to 19.2MHz (to make sure that it's not > > > been rounded too far apart from the frequency we expect). > > > > > > This is doing exactly the same thing, except that we don't encode our > > > implementation limitations in the DT, but in the driver instead. > > > > What I really wanted to say that a driver that doesn't get the clock > > frequency from DT but still sets that frequency is broken. > > > > This frequency is highly system specific, and in many cases only a certain > > frequency is usable, for a few reasons: On many SoCs, not all common > > frequencies can be used (e.g. 9,6 MHz, 19,2 MHz and 24 MHz; while others > > are being used as well), and then that frequency affects the usable CSI-2 > > bus frequencies directly --- and of those, only safe, known-good ones > > should be used. IOW, getting the external clock frequency wrong typically > > has an effect that that none of the known-good CSI-2 bus clock frequencies > > are available. > > So clock-frequency is not about the "Frequency of the xvclk clock in > Hertz", but the frequency at which that clock must run on this > particular SoC / board to be functional? > > If so, then yeah, we should definitely keep it, but the documentation > of the binding should be made clearer as well. > Alright so, let me summarise the desired approach then. ACPI: - Fetch the "clock-frequency" property - Verify it to be 19.2Mhz DT: - Fetch the "clock-frequency" property - Verify it to be 19.2Mhz - Get xvclk clock - Get xvclk clock rate - Verify xvclk clock rate to be 19.2Mhz Since the xvclk clock isn't available under ACPI, this is how the two cases would be distinguished between. Does this sound about right? > assigned-clock-rates should still go away though. Ack. > > Maxime
WARNING: multiple messages have this Message-ID (diff)
From: Robert Foss <robert.foss@linaro.org> To: Maxime Ripard <maxime@cerno.tech> Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Tomasz Figa <tfiga@chromium.org>, Sakari Ailus <sakari.ailus@iki.fi>, Dongchun Zhu <dongchun.zhu@mediatek.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Fabio Estevam <festevam@gmail.com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, linux-media <linux-media@vger.kernel.org> Subject: Re: [PATCH v6 1/3] media: dt-bindings: ov8856: Document YAML bindings Date: Tue, 7 Apr 2020 13:29:05 +0200 [thread overview] Message-ID: <CAG3jFyvd32pWppubMoOoyH9eO2XLjwUXMC7p4xtv8m+JkPv6vw@mail.gmail.com> (raw) In-Reply-To: <20200407083647.4mocdl7aqa3x737q@gilmour.lan> Hey Maixme & Sakari, On Tue, 7 Apr 2020 at 10:36, Maxime Ripard <maxime@cerno.tech> wrote: > > Hi Sakari, > > On Mon, Apr 06, 2020 at 11:35:07AM +0300, Sakari Ailus wrote: > > > But that 19.2MHz is not a limitation of the device itself, it's a > > > limitation of our implementation, so we can instead implement > > > something equivalent in Linux using a clk_set_rate to 19.2MHz (to make > > > sure that our parent clock is configured at the right rate) and the > > > clk_get_rate and compare that to 19.2MHz (to make sure that it's not > > > been rounded too far apart from the frequency we expect). > > > > > > This is doing exactly the same thing, except that we don't encode our > > > implementation limitations in the DT, but in the driver instead. > > > > What I really wanted to say that a driver that doesn't get the clock > > frequency from DT but still sets that frequency is broken. > > > > This frequency is highly system specific, and in many cases only a certain > > frequency is usable, for a few reasons: On many SoCs, not all common > > frequencies can be used (e.g. 9,6 MHz, 19,2 MHz and 24 MHz; while others > > are being used as well), and then that frequency affects the usable CSI-2 > > bus frequencies directly --- and of those, only safe, known-good ones > > should be used. IOW, getting the external clock frequency wrong typically > > has an effect that that none of the known-good CSI-2 bus clock frequencies > > are available. > > So clock-frequency is not about the "Frequency of the xvclk clock in > Hertz", but the frequency at which that clock must run on this > particular SoC / board to be functional? > > If so, then yeah, we should definitely keep it, but the documentation > of the binding should be made clearer as well. > Alright so, let me summarise the desired approach then. ACPI: - Fetch the "clock-frequency" property - Verify it to be 19.2Mhz DT: - Fetch the "clock-frequency" property - Verify it to be 19.2Mhz - Get xvclk clock - Get xvclk clock rate - Verify xvclk clock rate to be 19.2Mhz Since the xvclk clock isn't available under ACPI, this is how the two cases would be distinguished between. Does this sound about right? > assigned-clock-rates should still go away though. Ack. > > Maxime _______________________________________________ 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-07 11:29 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-31 13:33 [PATCH v3 0/3] media: ov8856: Add devicetree support Robert Foss 2020-03-31 13:33 ` Robert Foss 2020-03-31 13:33 ` [PATCH v6 1/3] media: dt-bindings: ov8856: Document YAML bindings Robert Foss 2020-03-31 13:33 ` Robert Foss 2020-03-31 15:12 ` Marco Felsch 2020-03-31 15:12 ` Marco Felsch 2020-04-02 9:57 ` Robert Foss 2020-04-02 9:57 ` Robert Foss 2020-04-03 19:21 ` Marco Felsch 2020-04-03 19:21 ` Marco Felsch 2020-04-01 8:07 ` Maxime Ripard 2020-04-01 8:07 ` Maxime Ripard 2020-04-02 10:10 ` Robert Foss 2020-04-02 10:10 ` Robert Foss 2020-04-03 23:27 ` Sakari Ailus 2020-04-03 23:27 ` Sakari Ailus 2020-04-04 9:34 ` Maxime Ripard 2020-04-04 9:34 ` Maxime Ripard 2020-04-06 8:25 ` Robert Foss 2020-04-06 8:25 ` Robert Foss 2020-04-06 8:35 ` Sakari Ailus 2020-04-06 8:35 ` Sakari Ailus 2020-04-07 8:36 ` Maxime Ripard 2020-04-07 8:36 ` Maxime Ripard 2020-04-07 11:29 ` Robert Foss [this message] 2020-04-07 11:29 ` Robert Foss 2020-04-07 12:32 ` Maxime Ripard 2020-04-07 12:32 ` Maxime Ripard 2020-04-07 15:47 ` Robert Foss 2020-04-07 15:47 ` Robert Foss 2020-04-07 16:39 ` Sakari Ailus 2020-04-07 16:39 ` Sakari Ailus 2020-04-07 16:46 ` Tomasz Figa 2020-04-07 16:46 ` Tomasz Figa 2020-04-07 17:20 ` Sakari Ailus 2020-04-07 17:20 ` Sakari Ailus 2020-04-08 12:21 ` Maxime Ripard 2020-04-08 12:21 ` Maxime Ripard 2020-04-08 12:35 ` Tomasz Figa 2020-04-08 12:35 ` Tomasz Figa 2020-04-08 13:43 ` Maxime Ripard 2020-04-08 13:43 ` Maxime Ripard 2020-04-08 15:28 ` Sakari Ailus 2020-04-08 15:28 ` Sakari Ailus 2020-04-08 15:30 ` Sakari Ailus 2020-04-08 15:30 ` Sakari Ailus 2020-04-08 16:34 ` Andy Shevchenko 2020-04-08 16:34 ` Andy Shevchenko 2020-04-15 10:18 ` Maxime Ripard 2020-04-15 10:18 ` Maxime Ripard 2020-04-15 11:10 ` Robert Foss 2020-04-15 11:10 ` Robert Foss 2020-04-15 16:16 ` Sakari Ailus 2020-04-15 16:16 ` Sakari Ailus 2020-04-20 15:02 ` Maxime Ripard 2020-04-20 15:02 ` Maxime Ripard 2020-04-09 8:32 ` Robert Foss 2020-04-09 8:32 ` Robert Foss 2020-04-07 16:20 ` Sakari Ailus 2020-04-07 16:20 ` Sakari Ailus 2020-04-04 9:23 ` Maxime Ripard 2020-04-04 9:23 ` Maxime Ripard 2020-03-31 13:33 ` [PATCH v3 2/3] media: ov8856: Add devicetree support Robert Foss 2020-03-31 13:33 ` Robert Foss 2020-03-31 14:01 ` Andy Shevchenko 2020-03-31 14:01 ` Andy Shevchenko 2020-04-06 13:37 ` Robert Foss 2020-04-06 13:37 ` Robert Foss 2020-04-06 15:06 ` Andy Shevchenko 2020-04-06 15:06 ` Andy Shevchenko 2020-04-06 15:25 ` Robert Foss 2020-04-06 15:25 ` Robert Foss 2020-04-03 23:33 ` Sakari Ailus 2020-04-03 23:33 ` Sakari Ailus 2020-03-31 13:33 ` [PATCH v3 3/3] media: ov8856: Implement sensor module revision identification Robert Foss 2020-03-31 13:33 ` Robert Foss
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=CAG3jFyvd32pWppubMoOoyH9eO2XLjwUXMC7p4xtv8m+JkPv6vw@mail.gmail.com \ --to=robert.foss@linaro.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dongchun.zhu@mediatek.com \ --cc=festevam@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=maxime@cerno.tech \ --cc=sakari.ailus@iki.fi \ --cc=tfiga@chromium.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.