Thread (1 message) 1 message, 1 author, 2011-08-08

Re: [RFC 5/5] [powerpc] Implement a p1010rdb clock source.

From: Wolfgang Grandegger <hidden>
Date: 2011-08-08 15:18:57

On 08/08/2011 05:09 PM, Robin Holt wrote:
On Mon, Aug 08, 2011 at 04:59:54PM +0200, Wolfgang Grandegger wrote:
quoted
On 08/08/2011 04:44 PM, Robin Holt wrote:
quoted
On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote:
quoted
On 08/08/2011 04:21 PM, Robin Holt wrote:
quoted
On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote:
quoted
On 08/08/2011 03:56 PM, Robin Holt wrote:
quoted
quoted
commit 65bb8b060a873fa4f5188f2951081f6011259614
Author: Bhaskar Upadhaya [off-list ref]
Date:   Fri Mar 4 20:27:58 2011 +0530
On a side note, that commit fixes up "fsl,flexcan-v1.0"
...
+       do_fixup_by_compat_u32(blob, "fsl,flexcan-v1.0",
+                       "clock_freq", gd->bus_clk, 1);

Should I go back to flexcan-v1.0 in my patches?
Well, no. Let's wait. I don't think we need it. Also, it sets
"clock_freq" while

 http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt

documents "clock-frequencies"... :-(.
You answered a different question that I was asking.  I was asking if
I should change fsl,flexcan back to fsl,flexcan-v1.0 as documented on
line 5.  The clock_freq looks like a uboot change will need to be made
as well.
Well, I wrote above: "Well, no. Let's wait. I don't think we need it."

For the P1010 we can sinmply derive the clock frequency from
"fsl_get_sys_freq()", which is fine for the time being. No extra
properties, etc. The clk implemetation might go into

 http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c

or

 http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c

And may depend on HAVE_CAN_FLEXCAN

BTW, I have not found HAVE_CAN_FLEXCAN in your patch. What kernel are
you using?
I am starting with the v3.0 kernel, apply one patch from the freescale BSP
we receive under NDA which introduces the P1010RDB board into the QorIQ
platform, and then work from there for the flexcan stuff.  That patch
introduces the HAVE_CAN_FLEXCAN.  I do not like how freescale structured
that Kconfig bit, so I have tweaked it to be selected automatically
when P1010RDB, NET, and CAN are selected.  That allows the CAN_FLEXCAN
selection to determine is we are going to build the flexcan.c file.
ARM boards select HAVE_CAN_FLEXCAN and I do not see a good reason why
we should do it differently for PowerPC. 

For mainline inclusion, you should provide your patches against the
David Millers "net-next-2.6" tree, which already seems to have support
for the P1010RDB:

  config P1010_RDB
        bool "Freescale P1010RDB"
        select DEFAULT_UIMAGE
        help
          This option enables support for the MPC85xx RDB (P1010 RDB) board

          P1010RDB contains P1010Si, which provides CPU performance up to 800
          MHz and 1600 DMIPS, additional functionality and faster interfaces
          (DDR3/3L, SATA II, and PCI  Express).

quoted
Our contact with Freescale would prefer that I not post that patch until
we get the OK from freescale to do so since we received it under NDA.
I don't think we currently need it. I prefer dropping and cleaning up
the device tree stuff as it is not needed for the P1010 anyway. If a
new processor shows up with enhanced capabilities requiring
configuration via device tree, we or somebody else can provide a patch.
Marc, what do you think?
I will rebase shortly and provide a newer set of patches.

I do think powerpc does need the device tree support.  That is how the flexcan_probe
is getting called.  How would you suggest I do it otherwise?
Why do you think that?

Wolfgang.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help