On 08/08/2011 05:38 PM, Robin Holt wrote: > On Mon, Aug 08, 2011 at 05:22:41PM +0200, Wolfgang Grandegger wrote: >> On 08/08/2011 05:18 PM, Wolfgang Grandegger wrote: >>> On 08/08/2011 05:09 PM, Robin Holt wrote: >>>> On Mon, Aug 08, 2011 at 04:59:54PM +0200, Wolfgang Grandegger wrote: >>>>> On 08/08/2011 04:44 PM, Robin Holt wrote: >>>>>> On Mon, Aug 08, 2011 at 04:37:44PM +0200, Wolfgang Grandegger wrote: >>>>>>> On 08/08/2011 04:21 PM, Robin Holt wrote: >>>>>>>> On Mon, Aug 08, 2011 at 04:16:27PM +0200, Wolfgang Grandegger wrote: >>>>>>>>> On 08/08/2011 03:56 PM, Robin Holt wrote: >>>>>>>>>>> commit 65bb8b060a873fa4f5188f2951081f6011259614 >>>>>>>>>>> Author: Bhaskar Upadhaya <bhaskar.upadh...@freescale.com> >>>>>>>>>>> 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). >>>>> >>>>> >>>>>> 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? >> >> To be clear. I mean we do not need the extra "fsl," properties for the >> clock source and divider and frequency. > > I agree with that. The can definition in the .dts file, however, > should be can0@... "fsl,flexcan" in an ideal world, correct? If that
No, it's normally <device-type>@<address>. > is correct, then I will make the of_match string match fsl,flexcan and > update the .dts file accordingly. As I said. For the P1010 the clock get function just needs to return "fsl_get_sys_freq()". No need to inspect the device tree. And I would provide the clk implementation in http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/platforms/85xx/clock.c or even: http://lxr.linux.no/#linux+v3.0.1/arch/powerpc/sysdev/fsl_soc.c Wolfgang. _______________________________________________ Socketcan-core mailing list Socketcan-core@lists.berlios.de https://lists.berlios.de/mailman/listinfo/socketcan-core
