Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

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: Tue, 21 May 2019 17:47:03 +0200	[thread overview]
Message-ID: <a142b72b828a798610d885d81189dd21b1870d78.camel@suse.de> (raw)
In-Reply-To: <6383b357-3f7e-f031-f59f-61c598e44763@i2se.com>

[-- Attachment #1.1: Type: text/plain, Size: 2427 bytes --]

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.

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? 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.

Regards,
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