RE: [PATCH 2/3] clk: renesas: rcar-usb2-clock-sel: Add multiple clocks management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert-san,

> From: Geert Uytterhoeven, Sent: Friday, October 25, 2019 4:47 PM
> 
> Hi Shimoda-san,
> 
> On Fri, Oct 25, 2019 at 3:36 AM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> > > From: Geert Uytterhoeven, Sent: Thursday, October 24, 2019 8:35 PM
> > <snip>
> > > > --- a/drivers/clk/renesas/rcar-usb2-clock-sel.c
> > > > +++ b/drivers/clk/renesas/rcar-usb2-clock-sel.c
> 
> > > > @@ -131,6 +156,14 @@ static int rcar_usb2_clock_sel_probe(struct platform_device *pdev)
> > > >         pm_runtime_enable(dev);
> > > >         pm_runtime_get_sync(dev);
> > >
> > > pm_runtime_get_sync() will have already enabled the first module clock listed in
> > > the DT "clocks" property.
> > >
> > > If you want the driver to manage all clocks itself, perhaps the PM Runtime
> > > calls should be dropped?
> >
> > I'm thinking PM Runtime calls are related to power domain control so that we cannot
> > drop it. Or, since the hardware is the Always-on domain, can we drop it anyway?
> 
> That's right: if the hardware block ever ends up in a non-always-on
> power domain,
> you won't have a choice but to use PM Runtime.

So, should I keep the PM Runtime calls?
# In such the case, I should add to describe power-domains property into
# the dt-binding doc though :)

Best regards,
Yoshihiro Shimoda





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux