[RFC] i.MX: drop secondary clocks
Lothar Waßmann
LW at KARO-electronics.de
Fri Mar 9 09:44:31 EST 2012
Hi,
Sascha Hauer writes:
> On Fri, Mar 09, 2012 at 12:47:58PM +0100, Lothar Waßmann wrote:
> > Hi,
> >
> > Sascha Hauer writes:
> > > On Fri, Mar 09, 2012 at 10:32:30AM +0100, Lothar Waßmann wrote:
> > > > Hi,
> > > >
> > > > Sascha Hauer writes:
> > > > > Hi All,
> > > > >
> > [...]
> > > > I think that's a bad idea! Drivers should not have to know intimate
> > > > details about the clock logic of the CPU core they are running on!
> > >
> > > They don't have to. There really are different clocks connected to the
> > > devices. If for example you have a look eSDHC Block diagram in the
> > > reference Manual you'll see that this has three clock inputs. All
> > > we do is to tell the driver about these three clocks which are device
> > > specific and not SoC specific. Which of these clocks are actually
> > > gatetable varies from SoC to SoC. Also on some SoCs two of the three
> > > clocks may be actually the same.
> > >
> > At least this should be done in a way that is independent from the
> > name of the clock on a specific SoC, but is related to the function of
> > the clock for the driver. Thus instead of e.g. CLK_IPG and CLK_PER use
> > CLK_REG and CLK_BITRATE.
>
> 'per', 'ipg' and 'ahb' seems to be a common pattern with all i.MXs. Only
> ahb is sometimes refered to as hclk. Do you also have a name for
> ahb/hclk? I don't insist on specific names, in the end they are just
> names and the pattern I used at least seems mostly consistent.
>
CLK_BUS?
> I assume that any given device has a set of clocks as inputs which
> should get device specific names. It's the job of the clock tree
> to know which SoC clocks map to which device clocks. If now a newer
> UART block has an additional clock, then we would depending on the
> device id (fsl,imx7-uart) know that it requires the additional clock
> and request it.
>
It's also not the business of a device driver to know any details
about clock dependencies on a specific SoC.
We probably really need a bus layer that can hide the details of the
bus architecture and their corresponding clocks from the device
drivers.
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
More information about the linux-arm-kernel
mailing list