[PATCH v11 4/5] powerpc: Add flexcan device support for p1010rdb.

[Wolfgang Grandegger]

On 08/10/2011 07:01 PM, Kumar Gala wrote:
> 
> On Aug 10, 2011, at 11:27 AM, Robin Holt wrote:
> 
>> I added a simple clock source for the p1010rdb so the flexcan driver
>> could determine a clock frequency.  The p1010 flexcan device only has
>> an oscillator of system bus frequency divided by 2.
>>
>> Signed-off-by: Robin Holt <holt at sgi.com>
>> Acked-by: Marc Kleine-Budde <mkl at pengutronix.de>,
>> Acked-by: Wolfgang Grandegger <wg at grandegger.com>,
>> Cc: U Bhaskar-B22300 <B22300 at freescale.com>
>> Cc: socketcan-core at lists.berlios.de,
>> Cc: netdev at vger.kernel.org,
>> Cc: PPC list <linuxppc-dev at lists.ozlabs.org>
>> Cc: Kumar Gala <galak at kernel.crashing.org>
>> ---
>> arch/powerpc/platforms/85xx/Kconfig    |    2 +
>> arch/powerpc/platforms/85xx/Makefile   |    2 +
>> arch/powerpc/platforms/85xx/clock.c    |   52 ++++++++++++++++++++++++++++++++
>> arch/powerpc/platforms/85xx/p1010rdb.c |    8 +++++
>> 4 files changed, 64 insertions(+), 0 deletions(-)
>> create mode 100644 arch/powerpc/platforms/85xx/clock.c
> 
> I dont understand how mpc85xx_clk_functions() ends up being associated with the frequency the flexcan is running at.

The function mpc85xx_clk_get_rate() returns "fsl_get_sys_freq() / 2" for
Flexcan devices.

> This either seems to global or I'm missing something.

This patch extends the existing Flexcan platform driver for ARM for the
PowerPC using the device tree. Due to the nice integration of the device
tree (of-platform) into the platform driver and devices, the difference
are quite small (see patches 1..3). Apart from the endianess issue, only
the clock needs to be handled in a common way. As ARM already uses the
clk interface, we found it straight-forward to implement it for the
P1010, or more general for the 85xx, as well, instead of using an
additional helper function.

> I still think the clk / freq info should be in the device tree and handled in the driver and NOT arch/powerpc platform code.

If I understand you correctly, you want the boot-loader to provide the
relevant information by fixing up the device tree, which then can be
handled arch-independently by the driver, right?

Wolfgang.