[lkml]   [2019]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb
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:
> >
> > - 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.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2019-05-21 17:47    [W:0.085 / U:4.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site