Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1693976 > unrolled thread

Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update bindings

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update  bindings Stephen Boyd <sboyd@codeaurora.org> - 2017-07-21 22:50 +0200
    Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update  bindings Neil Armstrong <narmstrong@baylibre.com> - 2017-07-24 13:50 +0200
      Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update  bindings Jerome Brunet <jbrunet@baylibre.com> - 2017-07-24 14:10 +0200
        Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update  bindings Stephen Boyd <sboyd@codeaurora.org> - 2017-07-26 02:50 +0200
          Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update  bindings Jerome Brunet <jbrunet@baylibre.com> - 2017-07-26 22:10 +0200

#1693976 — Re: [PATCH 3/3] dt-bindings: clock: amlogic,gxbb-aoclkc: Update bindings

On 07/09, Rob Herring wrote:
> On Thu, Jul 06, 2017 at 12:24:23PM +0200, Neil Armstrong wrote:
> > On the first revision of the bindings, only the gates + resets were known
> > in the AO Clock HW, but more registers used to configures AO clock are known
> > to be spread among the AO register space.
> > This patch adds these registers to the Ao Clock bindings with direct access
> > and shared extcon access.
> > 
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> >  .../devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt         | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> This looks like the binding might be too specific with a reg list of 
> single registers, and you should define a system controller node 
> instead. Depends on what else is in the "A0" block.
> 

Agreed. Why can't we expand the size in DT and then access the
registers directly in the driver. Hopefully it keeps working to
apply the dts patch without the driver patch too (and
vice-versa), because the kernel can only make a mapping as small
as a page which would cover these newly added reg properties
anyway.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [next] | [standalone]

#1694659

On 07/21/2017 10:44 PM, Stephen Boyd wrote:
> On 07/09, Rob Herring wrote:
>> On Thu, Jul 06, 2017 at 12:24:23PM +0200, Neil Armstrong wrote:
>>> On the first revision of the bindings, only the gates + resets were known
>>> in the AO Clock HW, but more registers used to configures AO clock are known
>>> to be spread among the AO register space.
>>> This patch adds these registers to the Ao Clock bindings with direct access
>>> and shared extcon access.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>>  .../devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt         | 11 +++++++++--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> This looks like the binding might be too specific with a reg list of 
>> single registers, and you should define a system controller node 
>> instead. Depends on what else is in the "A0" block.
>>
> 
> Agreed. Why can't we expand the size in DT and then access the
> registers directly in the driver. Hopefully it keeps working to
> apply the dts patch without the driver patch too (and
> vice-versa), because the kernel can only make a mapping as small
> as a page which would cover these newly added reg properties
> anyway.
> 

Hi Rob, Stephen,

Thanks for your feedback, but on these Amlogic platforms, the AO register bank is
filled with interleaved registers used for various purposes.

For instance, the first 1k of registers are :

0-c RTI_STATUS
c-14 RTI_PWR_CNTL
14-1c PIN_MUX
1c RTI_STATUS
24-30 GPIO
30 JTAG_CONFIG
34 WD
38-40 CPU_CTRL
40 RTI_GEN_CTRL
44 CPU_CTRL
4c-58 TIMER
58 OSCIN
60 AHB2DDR
...


And so on, and the clock related registers are split among this space.

For sure, this could be declared as an system controller node, but this would imply completely
re-designing the actual clock driver and drop the actual bindings.
(and with re-writting the clock gate code to use regmap registers access)

Anyway, I'm open to suggestions...

Neil

[toc] | [prev] | [next] | [standalone]

#1694665

On Mon, 2017-07-24 at 13:47 +0200, Neil Armstrong wrote:
> On 07/21/2017 10:44 PM, Stephen Boyd wrote:
> > On 07/09, Rob Herring wrote:
> > > On Thu, Jul 06, 2017 at 12:24:23PM +0200, Neil Armstrong wrote:
> > > > On the first revision of the bindings, only the gates + resets were
> > > > known
> > > > in the AO Clock HW, but more registers used to configures AO clock are
> > > > known
> > > > to be spread among the AO register space.
> > > > This patch adds these registers to the Ao Clock bindings with direct
> > > > access
> > > > and shared extcon access.
> > > > 
> > > > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > > > ---
> > > >  .../devicetree/bindings/clock/amlogic,gxbb-aoclkc.txt         | 11
> > > > +++++++++--
> > > >  1 file changed, 9 insertions(+), 2 deletions(-)
> > > 
> > > This looks like the binding might be too specific with a reg list of 
> > > single registers, and you should define a system controller node 
> > > instead. Depends on what else is in the "A0" block.
> > > 
> > 
> > Agreed. Why can't we expand the size in DT and then access the
> > registers directly in the driver. Hopefully it keeps working to
> > apply the dts patch without the driver patch too (and
> > vice-versa), because the kernel can only make a mapping as small
> > as a page which would cover these newly added reg properties
> > anyway.
> > 
> 
> Hi Rob, Stephen,
> 
> Thanks for your feedback, but on these Amlogic platforms, the AO register bank
> is
> filled with interleaved registers used for various purposes.
> 
> For instance, the first 1k of registers are :
> 
> 0-c RTI_STATUS
> c-14 RTI_PWR_CNTL
> 14-1c PIN_MUX
> 1c RTI_STATUS
> 24-30 GPIO
> 30 JTAG_CONFIG
> 34 WD
> 38-40 CPU_CTRL
> 40 RTI_GEN_CTRL
> 44 CPU_CTRL
> 4c-58 TIMER
> 58 OSCIN
> 60 AHB2DDR
> ...
> 
> 
> And so on, and the clock related registers are split among this space.
> 
> For sure, this could be declared as an system controller node, but this would
> imply completely
> re-designing the actual clock driver and drop the actual bindings.
> (and with re-writting the clock gate code to use regmap registers access)

Maybe it is time to investigate having the regmap clock from qcom available to
every other platform ?

> 
> Anyway, I'm open to suggestions...
> 
> Neil

[toc] | [prev] | [next] | [standalone]

#1696702

On 07/24, Jerome Brunet wrote:
> On Mon, 2017-07-24 at 13:47 +0200, Neil Armstrong wrote:
> > 
> > Hi Rob, Stephen,
> > 
> > Thanks for your feedback, but on these Amlogic platforms, the AO register bank
> > is
> > filled with interleaved registers used for various purposes.
> > 
> > For instance, the first 1k of registers are :
> > 
> > 0-c RTI_STATUS
> > c-14 RTI_PWR_CNTL
> > 14-1c PIN_MUX
> > 1c RTI_STATUS
> > 24-30 GPIO
> > 30 JTAG_CONFIG
> > 34 WD
> > 38-40 CPU_CTRL
> > 40 RTI_GEN_CTRL
> > 44 CPU_CTRL
> > 4c-58 TIMER
> > 58 OSCIN
> > 60 AHB2DDR
> > ...
> > 
> > 
> > And so on, and the clock related registers are split among this space.
> > 
> > For sure, this could be declared as an system controller node, but this would
> > imply completely
> > re-designing the actual clock driver and drop the actual bindings.
> > (and with re-writting the clock gate code to use regmap registers access)

I'm not suggesting a sycon node or binding usage here. There's an
"always on" hw block here that could be implemented as an MFD
driver that binds and creates a clk subdevice and whatever else
is sitting in here. Those subdevices could be informed of the
register base by knowing their parent driver is an MFD with a
certain driver data structure inside and then get at an __iomem
pointer through the parent's driver data. Or they could use a
regmap approach and rewrite a bunch of code. Or there could be
just a clk driver that binds to this node for now until a later
time that other features are needed.

> 
> Maybe it is time to investigate having the regmap clock from qcom available to
> every other platform ?

I think we have regmap clk duplicated a couple times in the
drivers/clk/ directory now. Not sure how this is related, except
for that there looks to be a desire to use a syscon binding here
and that forces regmap on drivers?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[toc] | [prev] | [next] | [standalone]

#1697540

On Tue, 2017-07-25 at 17:48 -0700, Stephen Boyd wrote:
> > 
> > Maybe it is time to investigate having the regmap clock from qcom available
> > to
> > every other platform ?
> 
> I think we have regmap clk duplicated a couple times in the
> drivers/clk/ directory now.

Which is why we may start thinking of common and generic "regmap" compatible
solution in the CCF, at least for things like gates, dividers and muxes

The approach used in qcom with regmap clocks could be a candidate for this,
don't you think ?

> Not sure how this is related, except
> for that there looks to be a desire to use a syscon binding here
> and that forces regmap on drivers?

Syscon has been created exactly for this case where you want to create an mfd
just for sharing a register region between several, otherwise well separated,
devices, isn't it ?

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web