From: Robert Foss <robert.foss@linaro.org> To: Marco Felsch <m.felsch@pengutronix.de> Cc: Sakari Ailus <sakari.ailus@iki.fi>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Maxime Ripard <maxime@cerno.tech>, 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>, Dongchun Zhu <dongchun.zhu@mediatek.com>, Fabio Estevam <festevam@gmail.com>, Tomasz Figa <tfiga@chromium.org> Subject: Re: [PATCH v6 2/3] media: ov8856: Add devicetree support Date: Thu, 30 Apr 2020 18:11:14 +0200 [thread overview] Message-ID: <CAG3jFytP9=pL=9Qh64BKqQchs7J7E45USfirK_SnGn3NMeCdcg@mail.gmail.com> (raw) In-Reply-To: <20200430120740.GG2188@pengutronix.de> Hey Marco, On Thu, 30 Apr 2020 at 14:07, Marco Felsch <m.felsch@pengutronix.de> wrote: > > On 20-04-30 13:20, Sakari Ailus wrote: > > On Thu, Apr 30, 2020 at 12:11:57PM +0200, Marco Felsch wrote: > > > On 20-04-30 12:59, Sakari Ailus wrote: > > > > Hi Marco, > > > > > > > > On Thu, Apr 30, 2020 at 11:53:32AM +0200, Marco Felsch wrote: > > > > > Hi Sakari, > > > > > > > > > > On 20-04-30 12:45, Sakari Ailus wrote: > > > > > > Hi Marco, > > > > > > > > > > > > On Thu, Apr 30, 2020 at 11:35:24AM +0200, Marco Felsch wrote: > > > > > > ... > > > > > > > > > > > - if (mclk != OV8856_MCLK) { > > > > > > > > - dev_err(dev, "external clock %d is not supported", mclk); > > > > > > > > - return -EINVAL; > > > > > > > > + if (!is_acpi_node(fwnode)) { > > > > > > > > + ov8856->xvclk = devm_clk_get(dev, "xvclk"); > > > > > > > > + if (IS_ERR(ov8856->xvclk)) { > > > > > > > > + dev_err(dev, "could not get xvclk clock (%pe)\n", > > > > > > > > + ov8856->xvclk); > > > > > > > > + return PTR_ERR(ov8856->xvclk); > > > > > > > > + } > > > > > > > > + > > > > > > > > + clk_set_rate(ov8856->xvclk, xvclk_rate); > > > > > > > > + xvclk_rate = clk_get_rate(ov8856->xvclk); > > > > > > > > } > > > > > > > > > > > > > > Why do we handle the clock only in DT case? Is there a problem with the > > > > > > > clock handling and ACPI? > > > > > > > > > > > > Not really, it's just that ACPI does not provide an interface to the clocks > > > > > > as such. > > > > > > > > > > But you will get a clk by devm_clk_get()? > > > > > > > > No, because ACPI does not expose one to drivers. Effectively the entire > > > > power sequences are implemented in ACPI, not in the driver. > > > > > > > > > > Ah okay, thanks for the explanation. I'm really not into the ACPI > > > stuff.. So this means the __power_off / power_on should only be done if > > > we are using DT's? > > > > Correct. That's why it bails out early. It could be yet earlier though, > > without doing anything. > > Yes I see. For easier and error less prone handling I would prefer: > > if (is_acpi_node()) > return 0; > > as first instruction for __power_off/on(). __ov8856_power_on() does make a check like that, albeit only after having run clk_prepare_enable() which won't do anything due to ov8856->xvclk==NULL. So this should be fixed and be moved to after the ACPI check. __ov8856_power_off() has no ACPI check, but all of the calls it makes are going to do nothing due to v8856->reset_gpio / v8856->reset_gpio / ov8856->xvclk all being NULL or dummies. For the sake of clarity an early ACPI check+return could be added, but if clarity is the goal a comment would work too. > > Also I would refactor the ov8856_check_hwcfg() so the common part can be > used by this function and by a ov8856_parse_of() function. But thats > only my opinion. I'm trying to grok the above paragraph. You'd like to see something in the style of tc358743_probe_of()? > > Regards, > Marco
WARNING: multiple messages have this Message-ID (diff)
From: Robert Foss <robert.foss@linaro.org> To: Marco Felsch <m.felsch@pengutronix.de> Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Dongchun Zhu <dongchun.zhu@mediatek.com>, linux-kernel <linux-kernel@vger.kernel.org>, Tomasz Figa <tfiga@chromium.org>, Sakari Ailus <sakari.ailus@iki.fi>, Maxime Ripard <maxime@cerno.tech>, 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 2/3] media: ov8856: Add devicetree support Date: Thu, 30 Apr 2020 18:11:14 +0200 [thread overview] Message-ID: <CAG3jFytP9=pL=9Qh64BKqQchs7J7E45USfirK_SnGn3NMeCdcg@mail.gmail.com> (raw) In-Reply-To: <20200430120740.GG2188@pengutronix.de> Hey Marco, On Thu, 30 Apr 2020 at 14:07, Marco Felsch <m.felsch@pengutronix.de> wrote: > > On 20-04-30 13:20, Sakari Ailus wrote: > > On Thu, Apr 30, 2020 at 12:11:57PM +0200, Marco Felsch wrote: > > > On 20-04-30 12:59, Sakari Ailus wrote: > > > > Hi Marco, > > > > > > > > On Thu, Apr 30, 2020 at 11:53:32AM +0200, Marco Felsch wrote: > > > > > Hi Sakari, > > > > > > > > > > On 20-04-30 12:45, Sakari Ailus wrote: > > > > > > Hi Marco, > > > > > > > > > > > > On Thu, Apr 30, 2020 at 11:35:24AM +0200, Marco Felsch wrote: > > > > > > ... > > > > > > > > > > > - if (mclk != OV8856_MCLK) { > > > > > > > > - dev_err(dev, "external clock %d is not supported", mclk); > > > > > > > > - return -EINVAL; > > > > > > > > + if (!is_acpi_node(fwnode)) { > > > > > > > > + ov8856->xvclk = devm_clk_get(dev, "xvclk"); > > > > > > > > + if (IS_ERR(ov8856->xvclk)) { > > > > > > > > + dev_err(dev, "could not get xvclk clock (%pe)\n", > > > > > > > > + ov8856->xvclk); > > > > > > > > + return PTR_ERR(ov8856->xvclk); > > > > > > > > + } > > > > > > > > + > > > > > > > > + clk_set_rate(ov8856->xvclk, xvclk_rate); > > > > > > > > + xvclk_rate = clk_get_rate(ov8856->xvclk); > > > > > > > > } > > > > > > > > > > > > > > Why do we handle the clock only in DT case? Is there a problem with the > > > > > > > clock handling and ACPI? > > > > > > > > > > > > Not really, it's just that ACPI does not provide an interface to the clocks > > > > > > as such. > > > > > > > > > > But you will get a clk by devm_clk_get()? > > > > > > > > No, because ACPI does not expose one to drivers. Effectively the entire > > > > power sequences are implemented in ACPI, not in the driver. > > > > > > > > > > Ah okay, thanks for the explanation. I'm really not into the ACPI > > > stuff.. So this means the __power_off / power_on should only be done if > > > we are using DT's? > > > > Correct. That's why it bails out early. It could be yet earlier though, > > without doing anything. > > Yes I see. For easier and error less prone handling I would prefer: > > if (is_acpi_node()) > return 0; > > as first instruction for __power_off/on(). __ov8856_power_on() does make a check like that, albeit only after having run clk_prepare_enable() which won't do anything due to ov8856->xvclk==NULL. So this should be fixed and be moved to after the ACPI check. __ov8856_power_off() has no ACPI check, but all of the calls it makes are going to do nothing due to v8856->reset_gpio / v8856->reset_gpio / ov8856->xvclk all being NULL or dummies. For the sake of clarity an early ACPI check+return could be added, but if clarity is the goal a comment would work too. > > Also I would refactor the ov8856_check_hwcfg() so the common part can be > used by this function and by a ov8856_parse_of() function. But thats > only my opinion. I'm trying to grok the above paragraph. You'd like to see something in the style of tc358743_probe_of()? > > Regards, > Marco _______________________________________________ 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-30 16:11 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-29 16:24 [PATCH v6 v6 0/3] media: ov8856: Add devicetree support Robert Foss 2020-04-29 16:24 ` Robert Foss 2020-04-29 16:24 ` [PATCH v9 1/3] media: dt-bindings: ov8856: Document YAML bindings Robert Foss 2020-04-29 16:24 ` Robert Foss 2020-04-29 16:24 ` [PATCH v6 2/3] media: ov8856: Add devicetree support Robert Foss 2020-04-29 16:24 ` Robert Foss 2020-04-30 9:35 ` Marco Felsch 2020-04-30 9:35 ` Marco Felsch 2020-04-30 9:45 ` Sakari Ailus 2020-04-30 9:45 ` Sakari Ailus 2020-04-30 9:53 ` Marco Felsch 2020-04-30 9:53 ` Marco Felsch 2020-04-30 9:59 ` Sakari Ailus 2020-04-30 9:59 ` Sakari Ailus 2020-04-30 10:11 ` Marco Felsch 2020-04-30 10:11 ` Marco Felsch 2020-04-30 10:20 ` Sakari Ailus 2020-04-30 10:20 ` Sakari Ailus 2020-04-30 12:07 ` Marco Felsch 2020-04-30 12:07 ` Marco Felsch 2020-04-30 13:32 ` Sakari Ailus 2020-04-30 13:32 ` Sakari Ailus 2020-04-30 16:11 ` Robert Foss [this message] 2020-04-30 16:11 ` Robert Foss 2020-05-04 6:24 ` Marco Felsch 2020-05-04 6:24 ` Marco Felsch 2020-04-29 16:24 ` [PATCH v6 3/3] media: ov8856: Implement sensor module revision identification Robert Foss 2020-04-29 16:24 ` 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='CAG3jFytP9=pL=9Qh64BKqQchs7J7E45USfirK_SnGn3NMeCdcg@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=m.felsch@pengutronix.de \ --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.