From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> To: Stefan Wahren <stefan.wahren@i2se.com>, Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>, bcm-kernel-feedback-list@broadcom.com, Eric Anholt <eric@anholt.net> Cc: linux-arm-kernel@lists.infradead.org, ptesarik@suse.com, sboyd@kernel.org, viresh.kumar@linaro.org, mturquette@baylibre.com, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org, mbrugger@suse.de, ssuloev@orpaltech.com Subject: Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Date: Thu, 23 May 2019 10:51:07 +0200 [thread overview] Message-ID: <c756c54d5e924d61b8ec6eccecf9bfdce7c2b543.camel@suse.de> (raw) In-Reply-To: <1599901940.259900.1558475026379@email.ionos.de> [-- Attachment #1: Type: text/plain, Size: 3390 bytes --] On Tue, 2019-05-21 at 23:43 +0200, Stefan Wahren wrote: > > Nicolas Saenz Julienne <nsaenzjulienne@suse.de> hat am 21. Mai 2019 um 17:47 > > geschrieben: > > > > > > Hi Stefan, thanks for your comments! > > > > On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote: > > > Hi Nicolas, > > > > > > On 20.05.19 14:11, Stefan Wahren wrote: > > > > Hi Nicolas, > > > > > > > > the following comments applies only in case Eric is fine with the whole > > > > approach. > > > > > > > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > > > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps > > > > maybe we should clarify that the firmware is running in the VPU > > > > > track of the board's temperature and voltage. It's resposible for > > > > > scaling the CPU frequency whenever it deems the device reached an > > > > > unsafe > > > > > state. On top of that the firmware provides an interface which allows > > > > > Linux to to query the clock's state or change it's frequency. > > > > I think this requires a separate update of the devicetree binding. > > > > > Being the sole user of the bcm2835 clock driver, this integrates the > > > > > firmware interface into the clock driver and adds a first user: the > > > > > CPU > > > > > pll, also known as 'pllb'. > > > > Please verify that the kernel still works (and this clock driver probe) > > > > under the following conditions: > > > > > > > > - CONFIG_RASPBERRYPI_FIRMWARE=n > > > > - CONFIG_RASPBERRYPI_FIRMWARE=m > > > > - older DTBs without patch #1 > > > i thought about this and the case this driver would return > > > -EPROBE_DEFER. The clock driver is too essential for doing such a thing. > > > So i think the best solution would be to move these changes into a > > > separate driver which should be register by the clock driver (similiar > > > to vchiq). This also avoid the need of a new device tree binding. > > > > I understand your concerns. > > > > Wouldn't you prefer registering the device trough the device tree? I'd go > > with > > the same approach as the firmware touchscreen driver, which is registered > > after > > the firmware's probe trough dt's 'simple-bus'. That said, it's not a > > strongly > > held opinion, I'm happy with whatever solution as long as it works. > > A devicetree binding always introduce some kind of inflexibility. In case > someone finds a better solution later things can get really messy. A recent > example is the clock handling for i2c-bcm2835. Fair enough. > > I get from your comments that you'd like the register based version of > > 'pllb' > > and 'pllb_arm' to be loaded if for some reason the firmware isn't available. > > Is > > that right? > > This wasn't my intention. I would prefer a simple approch here (no handover). > > > The main problem I see with this is the duplication of 'pllb' and > > 'pllb_arm'. Both drivers will create the same clock device through different > > interfaces. Any suggestions on how to deal with that? If not I can simply > > remove 'pllb' and 'pllb_arm' from clk-bcm2835.c. > > Yes. So even if this driver is disabled, there shouldn't be a regression. Or > did i miss something? No, there shoudn't be any regressions as these clocks are not being used at the moment. I'll send a follow-up series soon :) Regrads, Nicolas [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> To: Stefan Wahren <stefan.wahren@i2se.com>, Florian Fainelli <f.fainelli@gmail.com>, Ray Jui <rjui@broadcom.com>, Scott Branden <sbranden@broadcom.com>, bcm-kernel-feedback-list@broadcom.com, Eric Anholt <eric@anholt.net> Cc: linux-pm@vger.kernel.org, sboyd@kernel.org, viresh.kumar@linaro.org, mturquette@baylibre.com, ptesarik@suse.com, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, mbrugger@suse.de, linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, ssuloev@orpaltech.com Subject: Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Date: Thu, 23 May 2019 10:51:07 +0200 [thread overview] Message-ID: <c756c54d5e924d61b8ec6eccecf9bfdce7c2b543.camel@suse.de> (raw) In-Reply-To: <1599901940.259900.1558475026379@email.ionos.de> [-- Attachment #1.1: Type: text/plain, Size: 3390 bytes --] On Tue, 2019-05-21 at 23:43 +0200, Stefan Wahren wrote: > > Nicolas Saenz Julienne <nsaenzjulienne@suse.de> hat am 21. Mai 2019 um 17:47 > > geschrieben: > > > > > > Hi Stefan, thanks for your comments! > > > > On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote: > > > Hi Nicolas, > > > > > > On 20.05.19 14:11, Stefan Wahren wrote: > > > > Hi Nicolas, > > > > > > > > the following comments applies only in case Eric is fine with the whole > > > > approach. > > > > > > > > On 20.05.19 12:47, Nicolas Saenz Julienne wrote: > > > > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps > > > > maybe we should clarify that the firmware is running in the VPU > > > > > track of the board's temperature and voltage. It's resposible for > > > > > scaling the CPU frequency whenever it deems the device reached an > > > > > unsafe > > > > > state. On top of that the firmware provides an interface which allows > > > > > Linux to to query the clock's state or change it's frequency. > > > > I think this requires a separate update of the devicetree binding. > > > > > Being the sole user of the bcm2835 clock driver, this integrates the > > > > > firmware interface into the clock driver and adds a first user: the > > > > > CPU > > > > > pll, also known as 'pllb'. > > > > Please verify that the kernel still works (and this clock driver probe) > > > > under the following conditions: > > > > > > > > - CONFIG_RASPBERRYPI_FIRMWARE=n > > > > - CONFIG_RASPBERRYPI_FIRMWARE=m > > > > - older DTBs without patch #1 > > > i thought about this and the case this driver would return > > > -EPROBE_DEFER. The clock driver is too essential for doing such a thing. > > > So i think the best solution would be to move these changes into a > > > separate driver which should be register by the clock driver (similiar > > > to vchiq). This also avoid the need of a new device tree binding. > > > > I understand your concerns. > > > > Wouldn't you prefer registering the device trough the device tree? I'd go > > with > > the same approach as the firmware touchscreen driver, which is registered > > after > > the firmware's probe trough dt's 'simple-bus'. That said, it's not a > > strongly > > held opinion, I'm happy with whatever solution as long as it works. > > A devicetree binding always introduce some kind of inflexibility. In case > someone finds a better solution later things can get really messy. A recent > example is the clock handling for i2c-bcm2835. Fair enough. > > I get from your comments that you'd like the register based version of > > 'pllb' > > and 'pllb_arm' to be loaded if for some reason the firmware isn't available. > > Is > > that right? > > This wasn't my intention. I would prefer a simple approch here (no handover). > > > The main problem I see with this is the duplication of 'pllb' and > > 'pllb_arm'. Both drivers will create the same clock device through different > > interfaces. Any suggestions on how to deal with that? If not I can simply > > remove 'pllb' and 'pllb_arm' from clk-bcm2835.c. > > Yes. So even if this driver is disabled, there shouldn't be a regression. Or > did i miss something? No, there shoudn't be any regressions as these clocks are not being used at the moment. I'll send a follow-up series soon :) Regrads, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ 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:[~2019-05-23 8:51 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-20 10:47 [RFC v2 0/5] cpufreq support for the Raspberry Pi Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 1/5] clk: bcm2835: set CLK_GET_RATE_NOCACHE on CPU clocks Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 11:42 ` Stefan Wahren 2019-05-20 11:42 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 2/5] clk: bcm2835: set pllb_arm divisor as readonly Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 11:43 ` Stefan Wahren 2019-05-20 11:43 ` Stefan Wahren 2019-05-20 10:47 ` [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:11 ` Stefan Wahren 2019-05-20 12:14 ` Stefan Wahren 2019-05-20 12:14 ` Stefan Wahren 2019-05-21 12:40 ` Stefan Wahren 2019-05-21 12:40 ` Stefan Wahren 2019-05-21 15:47 ` Nicolas Saenz Julienne 2019-05-21 15:47 ` Nicolas Saenz Julienne 2019-05-21 21:43 ` Stefan Wahren 2019-05-21 21:43 ` Stefan Wahren 2019-05-23 8:51 ` Nicolas Saenz Julienne [this message] 2019-05-23 8:51 ` Nicolas Saenz Julienne 2019-05-20 12:43 ` Oliver Neukum 2019-05-20 12:43 ` Oliver Neukum 2019-05-21 11:39 ` Nicolas Saenz Julienne 2019-05-21 11:39 ` Nicolas Saenz Julienne 2019-05-21 12:14 ` Petr Tesarik 2019-05-21 12:14 ` Petr Tesarik 2019-05-21 12:18 ` Nicolas Saenz Julienne 2019-05-21 12:18 ` Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 4/5] dts: bcm2837: add per-cpu clock devices Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 12:19 ` Stefan Wahren 2019-05-20 12:19 ` Stefan Wahren 2019-05-20 12:19 ` Stefan Wahren 2019-05-21 11:40 ` Nicolas Saenz Julienne 2019-05-21 11:40 ` Nicolas Saenz Julienne 2019-05-20 10:47 ` [RFC v2 5/5] cpufreq: add driver for Raspbery Pi Nicolas Saenz Julienne 2019-05-20 10:47 ` Nicolas Saenz Julienne 2019-05-20 10:51 ` Viresh Kumar 2019-05-20 10:51 ` Viresh Kumar 2019-05-20 12:30 ` Stefan Wahren 2019-05-20 12:30 ` Stefan Wahren 2019-05-20 10:51 ` [RFC v2 0/5] cpufreq support for the Raspberry Pi Viresh Kumar 2019-05-20 10:51 ` Viresh Kumar 2019-05-21 12:02 ` Nicolas Saenz Julienne 2019-05-21 12:02 ` Nicolas Saenz Julienne
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=c756c54d5e924d61b8ec6eccecf9bfdce7c2b543.camel@suse.de \ --to=nsaenzjulienne@suse.de \ --cc=bcm-kernel-feedback-list@broadcom.com \ --cc=eric@anholt.net \ --cc=f.fainelli@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-rpi-kernel@lists.infradead.org \ --cc=mbrugger@suse.de \ --cc=mturquette@baylibre.com \ --cc=ptesarik@suse.com \ --cc=rjui@broadcom.com \ --cc=rjw@rjwysocki.net \ --cc=sboyd@kernel.org \ --cc=sbranden@broadcom.com \ --cc=ssuloev@orpaltech.com \ --cc=stefan.wahren@i2se.com \ --cc=viresh.kumar@linaro.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.