mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Chris Packham]

Hi,

One of the first problems I encountered looking at the Marvell Packet 
Processor with integrated CPU (I'll refer to that as 'the PP' throughout 
the rest of this email) was that it has a different TCLK to the armada-xp.

It appears that for both the PP and the armada-xp the TCLK is hard-coded 
(to 200MHz and 250MHz respectively) and cannot be detected as far as I 
can see from the various data-sheets. I was hoping to re-use 
drivers/clk/mvebu/armada-xp.c but I need to figure out how to make 
axp_get_tclk_freq() give me an appropriate answer depending on the SoC. 
If this were in the mach-mvebu code I could just use mvebu_get_soc_id() 
to fetch the device id. Is there an equivalent I could use in generic code?

One option would be to use a different compatible string in the dts. 
That would also give me a way of handling other differences (the 
clock-gating is a subset of what's available on the armada-xp). How 
different would things have to be before it's worth spinning the PP code 
out into a file of it's own?

Thanks,
Chris

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Thomas Petazzoni]

Dear Chris Packham,

On Mon, 17 Nov 2014 02:12:51 +0000, Chris Packham wrote:

> One of the first problems I encountered looking at the Marvell Packet 
> Processor with integrated CPU (I'll refer to that as 'the PP' throughout 
> the rest of this email) was that it has a different TCLK to the armada-xp.
> 
> It appears that for both the PP and the armada-xp the TCLK is hard-coded 
> (to 200MHz and 250MHz respectively) and cannot be detected as far as I 
> can see from the various data-sheets. I was hoping to re-use 
> drivers/clk/mvebu/armada-xp.c but I need to figure out how to make 
> axp_get_tclk_freq() give me an appropriate answer depending on the SoC. 
> If this were in the mach-mvebu code I could just use mvebu_get_soc_id() 
> to fetch the device id. Is there an equivalent I could use in generic code?
> 
> One option would be to use a different compatible string in the dts. 
> That would also give me a way of handling other differences (the 
> clock-gating is a subset of what's available on the armada-xp). How 
> different would things have to be before it's worth spinning the PP code 
> out into a file of it's own?

To me, it indeed seems like you need a different compatible string
here. Whether a separate file from drivers/clk/mvebu/armada-xp.c is
needed or not will depend on whether only the tclk frequency differs,
or whether also the ratios with other clocks differ.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Andrew Lunn]

On Mon, Nov 17, 2014 at 09:34:37AM +0100, Thomas Petazzoni wrote:
> Dear Chris Packham,
> 
> On Mon, 17 Nov 2014 02:12:51 +0000, Chris Packham wrote:
> 
> > One of the first problems I encountered looking at the Marvell Packet 
> > Processor with integrated CPU (I'll refer to that as 'the PP' throughout 
> > the rest of this email) was that it has a different TCLK to the armada-xp.
> > 
> > It appears that for both the PP and the armada-xp the TCLK is hard-coded 
> > (to 200MHz and 250MHz respectively) and cannot be detected as far as I 
> > can see from the various data-sheets. I was hoping to re-use 
> > drivers/clk/mvebu/armada-xp.c but I need to figure out how to make 
> > axp_get_tclk_freq() give me an appropriate answer depending on the SoC. 
> > If this were in the mach-mvebu code I could just use mvebu_get_soc_id() 
> > to fetch the device id. Is there an equivalent I could use in generic code?
> > 
> > One option would be to use a different compatible string in the dts. 
> > That would also give me a way of handling other differences (the 
> > clock-gating is a subset of what's available on the armada-xp). How 
> > different would things have to be before it's worth spinning the PP code 
> > out into a file of it's own?
> 
> To me, it indeed seems like you need a different compatible string
> here. Whether a separate file from drivers/clk/mvebu/armada-xp.c is
> needed or not will depend on whether only the tclk frequency differs,
> or whether also the ratios with other clocks differ.

I agree here about the compatibility string. The Kirkwood PP also has
a different compat string for some drivers and an .dtsi file.

kirkwood-98dx4122.dtsi

	Andrew

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Chris Packham]

Hi Andrew,

On 11/18/2014 03:18 AM, Andrew Lunn wrote:
> On Mon, Nov 17, 2014 at 09:34:37AM +0100, Thomas Petazzoni wrote:
>> Dear Chris Packham,
>>
>> On Mon, 17 Nov 2014 02:12:51 +0000, Chris Packham wrote:
>>
>>> One of the first problems I encountered looking at the Marvell Packet
>>> Processor with integrated CPU (I'll refer to that as 'the PP' throughout
>>> the rest of this email) was that it has a different TCLK to the armada-xp.
>>>
>>> It appears that for both the PP and the armada-xp the TCLK is hard-coded
>>> (to 200MHz and 250MHz respectively) and cannot be detected as far as I
>>> can see from the various data-sheets. I was hoping to re-use
>>> drivers/clk/mvebu/armada-xp.c but I need to figure out how to make
>>> axp_get_tclk_freq() give me an appropriate answer depending on the SoC.
>>> If this were in the mach-mvebu code I could just use mvebu_get_soc_id()
>>> to fetch the device id. Is there an equivalent I could use in generic code?
>>>
>>> One option would be to use a different compatible string in the dts.
>>> That would also give me a way of handling other differences (the
>>> clock-gating is a subset of what's available on the armada-xp). How
>>> different would things have to be before it's worth spinning the PP code
>>> out into a file of it's own?
>>
>> To me, it indeed seems like you need a different compatible string
>> here. Whether a separate file from drivers/clk/mvebu/armada-xp.c is
>> needed or not will depend on whether only the tclk frequency differs,
>> or whether also the ratios with other clocks differ.
>
> I agree here about the compatibility string. The Kirkwood PP also has
> a different compat string for some drivers and an .dtsi file.
>
> kirkwood-98dx4122.dtsi

Off topic but, cool bobcat1 support (err, I mean I recognize that 
official part number).

We have existing products using this and others with a proper kirkwood. 
Unfortunately they all have fdt unaware bootloaders. Is there an arm 
equivalent to the cuboot support that powerpc has?

>
> 	Andrew
>

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Andrew Lunn]

> > kirkwood-98dx4122.dtsi
> 
> Off topic but, cool bobcat1 support (err, I mean I recognize that 
> official part number).

It is very minimal support. I wish there was more, and i would love to
play with this chip, or the one you have, but the datasheets is not
available.
 
> We have existing products using this and others with a proper kirkwood. 
> Unfortunately they all have fdt unaware bootloaders.

You can use appended dt. Put the blob on the end of the kernel, and
with the right options turn on, it will find it. Also, keymile, how
did most of the 98dx4122 work contributed to uboot. So you can
probably use a mainline uboot.

	 Andrew

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Chris Packham]

Hi Thomas,

On 11/17/2014 09:34 PM, Thomas Petazzoni wrote:
> Dear Chris Packham,
>
> On Mon, 17 Nov 2014 02:12:51 +0000, Chris Packham wrote:
>
>> One of the first problems I encountered looking at the Marvell Packet
>> Processor with integrated CPU (I'll refer to that as 'the PP' throughout
>> the rest of this email) was that it has a different TCLK to the armada-xp.
>>
>> It appears that for both the PP and the armada-xp the TCLK is hard-coded
>> (to 200MHz and 250MHz respectively) and cannot be detected as far as I
>> can see from the various data-sheets. I was hoping to re-use
>> drivers/clk/mvebu/armada-xp.c but I need to figure out how to make
>> axp_get_tclk_freq() give me an appropriate answer depending on the SoC.
>> If this were in the mach-mvebu code I could just use mvebu_get_soc_id()
>> to fetch the device id. Is there an equivalent I could use in generic code?
>>
>> One option would be to use a different compatible string in the dts.
>> That would also give me a way of handling other differences (the
>> clock-gating is a subset of what's available on the armada-xp). How
>> different would things have to be before it's worth spinning the PP code
>> out into a file of it's own?
>
> To me, it indeed seems like you need a different compatible string
> here.

That's what I've done so far (patch to follow).

> Whether a separate file from drivers/clk/mvebu/armada-xp.c is
> needed or not will depend on whether only the tclk frequency differs,
> or whether also the ratios with other clocks differ.

Yeah I'm still trying to wrestle that information out of Marvell. What I 
do know is for the eval board I've got the armada register SAR (offset 
0x18230) is all zeros. I'm not sure if this is because everything really 
strapped low or because this register is unused on the PP.

The PP datasheet does have a table of differences with the armada. One 
of the major ones is the CPU frequency. The armada runs at up to 1.6GHz 
but the PP runs at up to 800MHz which probably does mean that 
axp_get_cpu_freq isn't giving the right answer.

I'm not sure how much this matters. For a packet processor with embedded 
CPU it's not like we need to support power management. The CPU is always 
on because it's always got something to do. We're not powering CPU 
peripherals to reduce power consumption, even if we did the power 
consumed by the packet processing side would eclipse any savings made by 
the CPU.

>
> Best regards,
>
> Thomas
>

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Andrew Lunn]

> Yeah I'm still trying to wrestle that information out of Marvell. What I 
> do know is for the eval board I've got the armada register SAR (offset 
> 0x18230) is all zeros. I'm not sure if this is because everything really 
> strapped low or because this register is unused on the PP.

Do the CPU SAR pins even make it out of the package? It could be when
the synthesised the CPU they hard coded it all and throw away the SAR.

    Andrew

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Chris Packham]

On 11/18/2014 10:55 AM, Andrew Lunn wrote:
>> Yeah I'm still trying to wrestle that information out of Marvell. What I
>> do know is for the eval board I've got the armada register SAR (offset
>> 0x18230) is all zeros. I'm not sure if this is because everything really
>> strapped low or because this register is unused on the PP.
>
> Do the CPU SAR pins even make it out of the package? It could be when
> the synthesised the CPU they hard coded it all and throw away the SAR.
>

That's a possibility. The other thing that they may have done is 
incorporated the SAR pins for the CPU with the SAR pins for the packet 
processor. That could be a little tricky because then I'd have to start 
opening up windows for the PP registers early in the kernel init.

mvebu: tclk detection for armada-xp and marvell packet processor with integrated CPU

[Marcin Wojtas]

Hello Chris,

2014-11-17 23:07 GMT+01:00 Chris Packham <Chris.Packham@alliedtelesis.co.nz>:
>
>
> On 11/18/2014 10:55 AM, Andrew Lunn wrote:
>>> Yeah I'm still trying to wrestle that information out of Marvell. What I
>>> do know is for the eval board I've got the armada register SAR (offset
>>> 0x18230) is all zeros. I'm not sure if this is because everything really
>>> strapped low or because this register is unused on the PP.
>>
>> Do the CPU SAR pins even make it out of the package? It could be when
>> the synthesised the CPU they hard coded it all and throw away the SAR.
>>
>
> That's a possibility. The other thing that they may have done is
> incorporated the SAR pins for the CPU with the SAR pins for the packet
> processor. That could be a little tricky because then I'd have to start
> opening up windows for the PP registers early in the kernel init.

Sorry to interfere, but is it possible to know what SoC (BobCat2 or
AlleyCat3? Afair, those are the two dual-core pj4b-based ones.) and
board model you exactly work on? I have some experience with this
family, so I there is a chance I may help.

Best regards,
Marcin