PXA 2xx devictree port and clock infrastructure

PXA 2xx devictree port and clock infrastructure

[Robert Jarzmik]

Hi guys,

I'm playing with devicetree to port the mioa701 machine code to devicetree (or
rather to eliminate the mioa701 machine code).

While porting the pxa2xx device drivers, I came to a question about the clock
infrastructure, and I'd need a bit of guidance.

Many drivers, in their probe code are doing something like :
	1) regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	2) irq = platform_get_irq(pdev, 0);
	3) clk = clk_get(&pdev->dev, NULL);

Points 1 and 2 are straightforward with DT. Point 3 is not so obvious to me.

As there is no platform data anymore, the clock infrastructure wants to match
the OF device (in my case udc at 40600000) with the registered
clocks. Unfortunately, the registered clock is named "pxa27x-udc", which works
well in "platform data" devices, but not in devicetree populated devices.

Therefore, I'd like to know what to do, and an example in another platform would
be great. Should I create a clkdev driver in drivers/clk, or is there another
... faster way ? And Daniel, you probably solved it already for
arch/arm/mach-pxa/pxa-dt.c, didn't you ?

Thanks for your insights.

Cheers.

-- 
Robert

PXA 2xx devictree port and clock infrastructure

[Arnd Bergmann]

On Tuesday 27 May 2014, Robert Jarzmik wrote:
> I'm playing with devicetree to port the mioa701 machine code to devicetree (or
> rather to eliminate the mioa701 machine code).
> 
> While porting the pxa2xx device drivers, I came to a question about the clock
> infrastructure, and I'd need a bit of guidance.
> 
> Many drivers, in their probe code are doing something like :
>         1) regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         2) irq = platform_get_irq(pdev, 0);
>         3) clk = clk_get(&pdev->dev, NULL);
> 
> Points 1 and 2 are straightforward with DT. Point 3 is not so obvious to me.
> 
> As there is no platform data anymore, the clock infrastructure wants to match
> the OF device (in my case udc at 40600000) with the registered
> clocks. Unfortunately, the registered clock is named "pxa27x-udc", which works
> well in "platform data" devices, but not in devicetree populated devices.
> 
> Therefore, I'd like to know what to do, and an example in another platform would
> be great. Should I create a clkdev driver in drivers/clk, or is there another
> ... faster way ? And Daniel, you probably solved it already for
> arch/arm/mach-pxa/pxa-dt.c, didn't you ?

There are generally three ways of doing this:

a) use an auxdata table to reassign the device names to what they
   used to be
b) change the clkdev lookup to also include the new names (e.g. "40600000.udc")
c) write a DT-aware clock driver and list all clocks in DT

	Arnd

PXA 2xx devictree port and clock infrastructure

[Mark Rutland]

On Tue, May 27, 2014 at 04:17:48PM +0100, Arnd Bergmann wrote:
> On Tuesday 27 May 2014, Robert Jarzmik wrote:
> > I'm playing with devicetree to port the mioa701 machine code to devicetree (or
> > rather to eliminate the mioa701 machine code).
> > 
> > While porting the pxa2xx device drivers, I came to a question about the clock
> > infrastructure, and I'd need a bit of guidance.
> > 
> > Many drivers, in their probe code are doing something like :
> >         1) regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >         2) irq = platform_get_irq(pdev, 0);
> >         3) clk = clk_get(&pdev->dev, NULL);
> > 
> > Points 1 and 2 are straightforward with DT. Point 3 is not so obvious to me.
> > 
> > As there is no platform data anymore, the clock infrastructure wants to match
> > the OF device (in my case udc at 40600000) with the registered
> > clocks. Unfortunately, the registered clock is named "pxa27x-udc", which works
> > well in "platform data" devices, but not in devicetree populated devices.
> > 
> > Therefore, I'd like to know what to do, and an example in another platform would
> > be great. Should I create a clkdev driver in drivers/clk, or is there another
> > ... faster way ? And Daniel, you probably solved it already for
> > arch/arm/mach-pxa/pxa-dt.c, didn't you ?
> 
> There are generally three ways of doing this:
> 
> a) use an auxdata table to reassign the device names to what they
>    used to be
> b) change the clkdev lookup to also include the new names (e.g. "40600000.udc")
> c) write a DT-aware clock driver and list all clocks in DT

Out of these, c would be my preferred solution. It would match the
solutions for problems 1 and 2, and it's almost inevitable that later
we'll want DT clocks anyway...

Cheers,
Mark.

PXA 2xx devictree port and clock infrastructure

[Arnd Bergmann]

On Tuesday 27 May 2014 16:43:03 Mark Rutland wrote:
> On Tue, May 27, 2014 at 04:17:48PM +0100, Arnd Bergmann wrote:
> > On Tuesday 27 May 2014, Robert Jarzmik wrote:
> > > I'm playing with devicetree to port the mioa701 machine code to devicetree (or
> > > rather to eliminate the mioa701 machine code).
> > > 
> > > While porting the pxa2xx device drivers, I came to a question about the clock
> > > infrastructure, and I'd need a bit of guidance.
> > > 
> > > Many drivers, in their probe code are doing something like :
> > >         1) regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >         2) irq = platform_get_irq(pdev, 0);
> > >         3) clk = clk_get(&pdev->dev, NULL);
> > > 
> > > Points 1 and 2 are straightforward with DT. Point 3 is not so obvious to me.
> > > 
> > > As there is no platform data anymore, the clock infrastructure wants to match
> > > the OF device (in my case udc at 40600000) with the registered
> > > clocks. Unfortunately, the registered clock is named "pxa27x-udc", which works
> > > well in "platform data" devices, but not in devicetree populated devices.
> > > 
> > > Therefore, I'd like to know what to do, and an example in another platform would
> > > be great. Should I create a clkdev driver in drivers/clk, or is there another
> > > ... faster way ? And Daniel, you probably solved it already for
> > > arch/arm/mach-pxa/pxa-dt.c, didn't you ?
> > 
> > There are generally three ways of doing this:
> > 
> > a) use an auxdata table to reassign the device names to what they
> >    used to be
> > b) change the clkdev lookup to also include the new names (e.g. "40600000.udc")
> > c) write a DT-aware clock driver and list all clocks in DT
> 
> Out of these, c would be my preferred solution. It would match the
> solutions for problems 1 and 2, and it's almost inevitable that later
> we'll want DT clocks anyway...

Right, that is the general recommendation at least. I'm always a bit cautious
when it comes to PXA because I don't expect that platform to fully get
converted to DT in the long run, and very little new work is going on there.

OTOH, if people like Robert and Daniel do this for fun, it's definitely
great to see the full solution.

Note that the more modern version of PXA is MMP, which currently uses a)
and I definitely want that converted to c) eventually, independent of what
happens with PXA.

	Arnd

PXA 2xx devictree port and clock infrastructure

[Robert Jarzmik]

Arnd Bergmann <arnd@arndb.de> writes:

> Right, that is the general recommendation at least. I'm always a bit cautious
> when it comes to PXA because I don't expect that platform to fully get
> converted to DT in the long run, and very little new work is going on there.
>
> OTOH, if people like Robert and Daniel do this for fun, it's definitely
> great to see the full solution.

OK, so let's suppose I go for (c), and :
 - create drivers/clk/clk-pxa2xx.c
   => OF clock driver
 - amend the mach-pxa accordingly to move all clock stuff to this driver

Is there a clean way for the transition phase, where devicetree pxa-dt machine
will have to exist with non-DT machine code ? ie. is there around a clock driver
I can look at where both OF *and* non-OF are working ?

Ah, and given that PXA clocks are very simple :
 - their rate is almost always constant, and not changeable
 - only one register exists to enable/disable all the clocks (bitmask of 32
 possible clock enables)

Isn't there already a skeleton to handle this type of clocks ? It looks to me
pretty generic, yet I haven't found it in drivers/clk. Maybe I missed something
?

Cheers.

--
Robert

PXA 2xx devictree port and clock infrastructure

[Mike Turquette]

Quoting Robert Jarzmik (2014-05-27 16:20:00)
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > Right, that is the general recommendation at least. I'm always a bit cautious
> > when it comes to PXA because I don't expect that platform to fully get
> > converted to DT in the long run, and very little new work is going on there.
> >
> > OTOH, if people like Robert and Daniel do this for fun, it's definitely
> > great to see the full solution.
> 
> OK, so let's suppose I go for (c), and :
>  - create drivers/clk/clk-pxa2xx.c
>    => OF clock driver
>  - amend the mach-pxa accordingly to move all clock stuff to this driver
> 
> Is there a clean way for the transition phase, where devicetree pxa-dt machine
> will have to exist with non-DT machine code ? ie. is there around a clock driver
> I can look at where both OF *and* non-OF are working ?
> 
> Ah, and given that PXA clocks are very simple :
>  - their rate is almost always constant, and not changeable
>  - only one register exists to enable/disable all the clocks (bitmask of 32
>  possible clock enables)
> 
> Isn't there already a skeleton to handle this type of clocks ? It looks to me
> pretty generic, yet I haven't found it in drivers/clk. Maybe I missed something
> ?

There is a fixed-rate clock type already and a fixed-factor (e.g.
fixed-divider) clock type. DT bindings exist for these types already.
See,

drivers/clk/clk-fixed-rate.c
drivers/clk/clk-fixed-factor.c
Documentation/devicetree/bindings/clock/fixed-clock.txt
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

For the gate clocks we have a gate-clock type:

drivers/clk/clk-gate.c

No DT binding exists for this type, as it it usually parsed by a
platform- or controller-specific compatible string. For an example of a
32-bit register where each bit toggles a clock gate, please see:

Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt

There might be simpler examples that don't use the clock-indices stuff,
but that was just from a quick grep.

Regards,
Mike

> 
> Cheers.
> 
> --
> Robert

PXA 2xx devictree port and clock infrastructure

[Andrew Ruder]

On Tue, May 27, 2014 at 03:02:14PM +0200, Robert Jarzmik wrote:
> I'm playing with devicetree to port the mioa701 machine code to devicetree (or
> rather to eliminate the mioa701 machine code).

Sorry for the late response, but for what its worth I have an entire
line of boards running on device-tree for PXA270.  Even better, they are
FIT booted out of U-Boot so I can use the same kernel on at least 4 (and
growing) different pieces of hardware.  Some of the patches are in
really sorry shape, but I'm just now trying to get them cleaned up for
inclusion (just sent the first wave to netdev today).

Unfortunately the few major issues I have is:

  a.) I simply changed the names of the clocks to match to get past that
  part (didn't create the clock driver stuff).

  b.) I'm currently using a hacky patch to pxamci.c to set the DMA
  channel since I'm not yet using the DMA patches that have been posted
  here.

  c.) Several other little things in mach-pxa/ to get the thing going
  that I haven't totally figured out yet.

I've gone ahead and pushed everything up to my personal github
repository in the meantime - it will probably be rebased frequently
while I get things cleaned up.

http://github.com/aeruder/linux

elecsys-v3.14/master - merges all of below
elecsys-v3.14/dm9000 - several patches for dm9000 network against v3.14
elecsys-v3.14/dt-dma-hack - the aforementioned pxamci.c patch
elecsys-v3.14/hwirq-vs-irq - issue regarding ISA interrupts
elecsys-v3.14/misc - this is where some of the changes get really bad
and still lots of cleanup to do
elecsys-v3.14/trivial - lots of small cleanups - several to device-tree
                        stuff
elecsys-v3.14/zx-support - stuff to support my specific boards (the
                           device trees and configs)

- Andy

PXA 2xx devictree port and clock infrastructure

[Robert Jarzmik]

Andrew Ruder <andy@aeruder.net> writes:

> On Tue, May 27, 2014 at 03:02:14PM +0200, Robert Jarzmik wrote:
>> I'm playing with devicetree to port the mioa701 machine code to devicetree (or
>> rather to eliminate the mioa701 machine code).
>
> Sorry for the late response, but for what its worth I have an entire
> line of boards running on device-tree for PXA270.  Even better, they are
> FIT booted out of U-Boot so I can use the same kernel on at least 4 (and
> growing) different pieces of hardware.  Some of the patches are in
> really sorry shape, but I'm just now trying to get them cleaned up for
> inclusion (just sent the first wave to netdev today).

This would Arnd's solution (a).
I will attempt solution (c), and send today what I've got so far.

> I've gone ahead and pushed everything up to my personal github
> repository in the meantime - it will probably be rebased frequently
> while I get things cleaned up.
Thanks.

--
Robert