On Mon, Aug 08, 2011 at 03:44:36PM +0200, Marc Kleine-Budde wrote: > On 08/08/2011 03:08 PM, Wolfgang Grandegger wrote: > > On 08/08/2011 01:31 PM, Robin Holt wrote: > >> On Mon, Aug 08, 2011 at 10:37:58AM +0200, Wolfgang Grandegger wrote: > >>> On 08/06/2011 04:34 PM, Robin Holt wrote: > >>>> flexcan driver needs the clk_get, clk_get_rate, etc functions > >>>> to work. This patch provides the minimum functionality. > >>> > >>> This needs some more general thoughts... apart from the question where > >>> the code should go. > >>> > >>> Like for the MSCAN on the MPC5200, the user should be *able* to select > >>> an appropriate clock source and divider via DTS node properties. > >>> Currently it seems, that the DTS properties must match some > >>> pre-configured values, most likely set by the boot loader. Please > >>> correct me if I'm wrong. For me this is generic and should go into the > >>> Flexcan driver. From there, a platform specific function, e.g. > >>> flexcan_set_clock() might be called. > >> > >> OK. Dug a bit more. The p1010 built-in clocksource seems to be the > >> periphereal clock frequency which is system bus frequency divided > >> by 2. The clock source can not be changed, but the clock divider can > >> by freezing the interface and setting the CTRL register. This appears > >> to only be done by the boot loader. I do not see why we can not leave > > > > And likely Freescale's bootloader does also fixup the DTS Flexcan node. > > Ah, oh, there's already someting in the mainline U-BOOT: > > > > commit 65bb8b060a873fa4f5188f2951081f6011259614 > > Author: Bhaskar Upadhaya <[email protected]> > > Date: Fri Mar 4 20:27:58 2011 +0530 > > > > powerpc/85xx: Fix up clock_freq property in CAN node of dts > > > > Fix up the device tree property associated with the Flexcan clock > > frequency. This property is used to calculate the bit timing parameters > > for Flexcan. > > > > Signed-off-by: Bhaskar Upadhaya <[email protected]> > > Signed-off-by: Kumar Gala <[email protected]> > > > > > >> that functionality in the boot loader and then go back to a variation > >> on my earlier flexcan_clk_* patch. Is that close to the direction you > >> think we should go or have I completely misunderstood your wishes? > > > > The boot loader might not chose the optimum clock source and frequency, > > which might even be application dependent. Therefore it would be nice to > > allow the user to change it if necessary. Some CAN interfaces do even > > allow to use an external clock source. The main question is where we add > > that functionality. As more as I think of it, the clock interface would > > not be that bad, especially if it's available. > > > > Furthermore, if the bootloader sets the clock source and divider, we do > > not need device tree properties for it. A simply register lookup would > > reveal what values are used. We may just need the input clock source. > > If the bootloader touches the divider _in_ the flexcan core, that would > make absolutely no sense. The clock divider in the flexcan core (in the > CTRL register) is the bitrate pre-scaler calculated by the bit-timing > algorithm. > > What we need in the device tree is, from my point of view. > a) the used clock source (bus clock or xtal clock) > b) the frequency of that clock > > These problems are solved on arm via: > a) bus clock is hard coded [1] > b) get that clock frequency via clk_get_rate().
Just to make sure I understand correctly, the clk_get_rate() return value comes from the device tree and a mach specific handler, right? And 'mach-specific' really means what, a processor family? Thanks, Robin _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
