- 26 Sep, 2013 39 commits
-
-
Lee Jones authored
MSP no longer requires clock-name bindings, so we need to move them to a more appropriate header indicating that we're still passing DMA related platform data to them. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
The ux500 platform will soon be converted to Device Tree only. When that happens the old clock initialisation will be ripped out. In the meantime however, we have to make a decision and call the appropriate initialisation code manually. Signed-off-by:
-
Lee Jones authored
If we supply a con_id then the clock framework will search for that name in MUSB's Device Tree node for the 'clock-names' property. If it's absent the clock request will fail. However, if we don't supply the con_id then clk_get() will call into clk_sys() which will use the device name to search for the appropriate clock, which is much more natural than forcing 'usb'. Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Lee Jones authored
This patch enables the TWD fixed factor clock to be specified from Device Tree via phandles to the "smp-twd-clock" node. Acked-by:
Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Lee Jones authored
This patch enables the RTC fixed frequency clock to be specified from Device Tree via phandles to the "rtc32k-clock" node. Acked-by:
-
Lee Jones authored
This patch enables clocks to be specified from Device Tree via phandles to the "prcc-kernel-clock" node. Acked-by:
-
Lee Jones authored
This patch enables clocks to be specified from Device Tree via phandles to the "prcc-periph-clock" node. Acked-by:
-
Lee Jones authored
This patch enables clocks to be specified from Device Tree via phandles to the "prcmu-clock" node. Acked-by:
-
Lee Jones authored
PRCC (peripheral and kernel) clocks are specified using a property tuple <&phandle base bit>, where 'base' is the peripheral (1, 2, 3, 5 or 6), and bit is read-in value into that peripheral stipulated by the hardware specification. Acked-by:
-
Lee Jones authored
The functional components will be added on a per-clock basis. Acked-by:
-
Lee Jones authored
Here we're using the old clock initialisation function as a template. It's necessary to remove all of the clk_register_clkdev() calls as they don't make sense when booting with Device Tree. Cc: Mike Turquette <mturquette@linaro.org> Signed-off-by:
-
Lee Jones authored
There is no mention of the PRCMU_BML8580CLK in any of the Design Specifications for the chips supported in Mainline. In fact, where it is incorrectly used in the u8540 clock definition driver it would have the side effect of using the incorrect clock management address ([PRCM_BML8580CLK_MGT] 0x108 instead of the correct value 0x04C). Acked-by:
-
Lee Jones authored
When booting with DT enabled we already call clocksource_of_init(), which in turn calls the OF version of nmdk_timer_init(). Signed-off-by:
-
Lee Jones authored
The MTU0 is required for full booting of the system. The driver has been previously DT:ed and is in use on the Nomadik platform, but we also need to enable it on ux500 based systems. Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
Signed-off-by:
-
Lee Jones authored
The platform which it pertains to is no longer supported and is actually causing some confusion in the new common clock implementation. A recent patch removed its use in the clock driver, let's take out the definitions too. Acked-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Lee Jones authored
These are required to request DBx500 PRCMU clocks from Device Tree. The numbers used are taken directly from the Hardware Specification document. We're moving them from the DBx500 PRCMU include file into the DT include directory and referencing them from the former via a #include. Acked-by:
-
Lee Jones authored
... as stipulated by the Hardware Specification document. Acked-by:
-
Sebastian Andrzej Siewior authored
The "mentor,musb" binding isn't documented so I was about to document it. The node is missing a few properties for configuration like "multipoint", "dyn_fifo", "num_eps" or "ram_bits". However I am not sure "missing" is the right word here because some of those informations might be obtained from the chip itself but it is not done (yet). Further the ePARP 2.3.1 says the matching goes from left to right taking the fist match. Right now there is jus a driver for "stericsson,db8500-musb" and none for "mentor,musb". I'm not 100% that it is simply possible to have a generic since even for DMA we have ifdefs in the driver between "generic mentor dma" and "ux500 dma" and I mean within musb and not the dma code. For that reason (that I am not sure a generic musb binding is possible and how its binding / required properties will look like) and the reason that we have here a minor binding without a driver to look at I suggest to remove that binding. If the majority of people prefer to keep this binding I'm curious how the documentation of the binding should look like. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Linus Walleij authored
These regulator rail names are already set in the ste-href.dtsi file included by this file, this is just redoing the naming for no benefit, so delete it. Signed-off-by: -
Linus Walleij authored
The Ux500 boards are layered like this: ste-snowball.dts includes ste-href.dtsi that includes ste-dbx500.dtsi. The dbx500.dtsi defines the PRCMU SoC regulators so the SoC will probe and you can use ampersand references where need be. However the HREF common dtsi and these two boards redefine the same PRCMU SoC regulators with the very same names and properties for no reason. This is like filling in the same line three times instead of drawing it once. Just delete the surplus references and have the PRCMU regulators defines in the SoC files ste-dbx500.dtsi, this is enough. Signed-off-by: -
Lee Jones authored
Turns out that they're actually not required and the driver probes just fine without them. The ID is incorrect at the moment anyway. They actually currently specify the stn8815. Signed-off-by:
-
- 16 Sep, 2013 1 commit
-
-
Linus Torvalds authored
-
