[linux-sunxi] Re: [PATCH v3] clk_mux: Fix set_parent doing the wrong thing when INDEX_BIT index = 3
Quoting Hans de Goede (2014-11-19 05:48:59)
If CLK_MUX_INDEX_BIT is set, then each bit turns on / off a single parent,
so theoretically multiple parents could be enabled at the same time, but in
practice only one bit should ever be 1. So to select parent 0, set
the register (*) to 0x01, to select parent 1 set it 0x02, parent 2, 0x04,
parent 3, 0x08, etc.
But the current code does:
if (mux-flags CLK_MUX_INDEX_BIT)
index = (1 ffs(index));
Which means that:
For an input index of 0, ffs returns 0, so we set the register
to 0x01, ok.
For an input index of 1, ffs returns 1, so we set the register
to 0x02, ok.
For an input index of 2, ffs returns 2, so we set the register
to 0x04, ok.
For an input index of 3, ffs returns 1, so we set the register
to 0x02, not good!
The code should simply be:
if (mux-flags CLK_MUX_INDEX_BIT)
index = 1 index;
Which always does the right thing, this commit fixes this.
Signed-off-by: Hans de Goede hdego...@redhat.com
Applied to clk-next towards 3.19. I don't think any merged platforms are
hitting this bug in the field so I've not put it into -fixes.
Thanks,
Mike
---
drivers/clk/clk-mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4f96ff3..6e1ecf9 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -77,7 +77,7 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
else {
if (mux-flags CLK_MUX_INDEX_BIT)
- index = (1 ffs(index));
+ index = 1 index;
if (mux-flags CLK_MUX_INDEX_ONE)
index++;
--
2.1.0
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Fixing boot-time hiccups in your display
Quoting jonsm...@gmail.com (2014-10-05 10:09:52) I edited the subject line to something more appropriate. This impacts a lot of platforms and we should be getting more replies from people on the ARM kernel list. This is likely something that deserves a Kernel Summit discussion. ELC-E and LPC are just around the corner as well. I am attending both. I suppose some of the others interested in this topic will be present? To summarize the problem The BIOS (uboot, etc) may have set various devices up into a working state before handing off to the kernel. The most obvious example of this is the boot display. So how do we transition onto the kernel provided device specific drivers without interrupting these functioning devices? This used to be simple, just build everything into the kernel. But then along came multi-architecture kernels where most drivers are not built in. Those kernels clean up everything (ie turn off unused clocks, regulators, etc) right before user space starts. That's done as a power saving measure. Unfortunately that code turns off the clocks and regulators providing the display on your screen. Which then promptly gets turned back on a half second later when the boot scripts load the display driver. Let's all hope the boot doesn't fail while the display is turned off. I would say this is one half of the discussion. How do you ever really know when it is safe to disable these things? In a world with loadable modules the kernel cannot know that everything that is going to be loaded has been loaded. There really is no boundary that makes it easy to say, OK, now it is truly safe for me to disable these things because I know every possible piece of code that might claim these resources has probed. Somebody (Geert?) proposed an ioctl for userspace to send such an all clear signal, but I dislike that idea. We're talking about managing fairly low-level hardware bits (clocks, regulators) and getting userspace involved feels wrong. Additionally clocks and regulators should be managed by PM Runtime implementations (via generic power domains and friends), so any solution that we come up with today that is specific for the clock and regulator frameworks would need to scale up to other abstraction layers, because those layers would probably like to know that they are not really idle/gated in hardware because the ioctl/garbage collector has not yet happened. The second half of the discussion is specific to simple framebuffer and the desire to keep it extremely simple and narrowly focused. I can understand both sides of the argument and I hope to stay well out of the flame zone. Even if we do leave simple framebuffer alone, the *idea* behind a very simple, entirely data-driven driver implementation that is meant to be compiled into the kernel image, claim resources early, ensure they stay enabled and then hand-off to a real driver that may be a loadable module is very interesting. It doesn't have to be simplefb. It could be something new. Additionally if this design pattern becomes common across more than just displays then we might want to consider ways of Doing It Right. Regards, Mike Below is part of the discussion on how to fix this, but so far no really good solution has been discovered. For the whole history search for the simple-framebuffer threads. There have been about 1,000 messages. On Sun, Oct 5, 2014 at 12:34 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Sun, Oct 5, 2014 at 11:36 AM, Chen-Yu Tsai w...@csie.org wrote: On Sun, Oct 5, 2014 at 11:29 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Sun, Oct 5, 2014 at 11:17 AM, Chen-Yu Tsai w...@csie.org wrote: On Sun, Oct 5, 2014 at 11:07 PM, jonsm...@gmail.com jonsm...@gmail.com wrote: On Sun, Oct 5, 2014 at 10:27 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 10/05/2014 02:52 PM, jonsm...@gmail.com wrote: On Sun, Oct 5, 2014 at 5:03 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 10/04/2014 02:38 PM, jonsm...@gmail.com wrote: On Sat, Oct 4, 2014 at 5:50 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 10/04/2014 12:56 AM, jonsm...@gmail.com wrote: On Fri, Oct 3, 2014 at 4:08 PM, Rob Herring robherri...@gmail.com wrote: On Fri, Oct 3, 2014 at 12:34 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 10/03/2014 05:57 PM, Rob Herring wrote: On Fri, Oct 3, 2014 at 9:05 AM, Hans de Goede hdego...@redhat.com wrote: A simple-framebuffer node represents a framebuffer setup by the firmware / bootloader. Such a framebuffer may have a number of clocks in use, add a property to communicate this to the OS. Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org -- Changes in v2: -Added Reviewed-by: Mike Turquette mturque...@linaro.org Changes in v3: -Updated description to make clear simplefb deals with more then just memory NAK. Fixing
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
On Wed, Oct 1, 2014 at 12:30 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, Sep 30, 2014 at 02:37:53PM -0700, Mike Turquette wrote: Quoting Thierry Reding (2014-09-29 06:54:00) On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote: Plus, speaking more specifically about the clocks, that won't prevent your clock to be shut down as a side effect of a later clk_disable call from another driver. Furthermore isn't it a bug for a driver to call clk_disable() before a preceding clk_enable()? There are patches being worked on that will enable per-user clocks and as I understand it they will specifically disallow drivers to disable the hardware clock if other drivers are still keeping them on via their own referenc. Calling clk_disable() preceding clk_enable() is a bug. Calling clk_disable() after clk_enable() will disable the clock (and its parents) if the clock subsystem thinks there are no other users, which is what will happen here. Right. I'm not sure this is really applicable to this situation, though. It's actually very easy to do. Have a driver that probes, enables its clock, fails to probe for any reason, call clk_disable in its exit path. If there's no other user at that time of this particular clock tree, it will be shut down. Bam. You just lost your framebuffer. Really, it's just that simple, and relying on the fact that some other user of the same clock tree will always be their is beyond fragile. Perhaps the meaning clk_ignore_unused should be revised, then. What you describe isn't at all what I'd expect from such an option. And it does not match the description in Documentation/kernel-parameters.txt either. From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001 From: Mike Turquette mturque...@linaro.org Date: Tue, 30 Sep 2014 14:24:38 -0700 Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused Refine the definition around clk_ignore_unused, which caused some confusion recently on the linux-fbdev and linux-arm-kernel mailing lists[0]. [0] http://lkml.kernel.org/r/20140929135358.GC30998@ulmo Signed-off-by: Mike Turquette mturque...@linaro.org --- Thierry, Please let me know if this wording makes the feature more clear. I think that's better than before, but I don't think it's accurate yet. As pointed out by Maxime unused clock may still be disabled if it's part of a tree and that tree is being disabled because there are no users left. It is entirely accurate. This feature does in fact prevent the clock framework from *automatically* gating clock And it was merged by Olof so that he could use simplefb with the Chromebook! What I had argued is that it's unexpected behavior, because the clock is still unused (or becomes unused again), therefore shouldn't be disabled at that point either. Leaving clocks enabled because nobody claimed them is not an option. So if you want to keep the current behaviour where an unused clock can still be disabled depending on what other users do, then I think it'd be good to mention that as a potential caveat. Do you have a suggestion on the wording? Thanks, Mike Thierry -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Quoting Thierry Reding (2014-09-29 06:54:00) On Mon, Sep 29, 2014 at 01:34:36PM +0200, Maxime Ripard wrote: On Mon, Sep 29, 2014 at 12:44:57PM +0200, Thierry Reding wrote: Plus, speaking more specifically about the clocks, that won't prevent your clock to be shut down as a side effect of a later clk_disable call from another driver. Furthermore isn't it a bug for a driver to call clk_disable() before a preceding clk_enable()? There are patches being worked on that will enable per-user clocks and as I understand it they will specifically disallow drivers to disable the hardware clock if other drivers are still keeping them on via their own referenc. Calling clk_disable() preceding clk_enable() is a bug. Calling clk_disable() after clk_enable() will disable the clock (and its parents) if the clock subsystem thinks there are no other users, which is what will happen here. Right. I'm not sure this is really applicable to this situation, though. It's actually very easy to do. Have a driver that probes, enables its clock, fails to probe for any reason, call clk_disable in its exit path. If there's no other user at that time of this particular clock tree, it will be shut down. Bam. You just lost your framebuffer. Really, it's just that simple, and relying on the fact that some other user of the same clock tree will always be their is beyond fragile. Perhaps the meaning clk_ignore_unused should be revised, then. What you describe isn't at all what I'd expect from such an option. And it does not match the description in Documentation/kernel-parameters.txt either. From e156ee56cbe26c9e8df6619dac1a993245afc1d5 Mon Sep 17 00:00:00 2001 From: Mike Turquette mturque...@linaro.org Date: Tue, 30 Sep 2014 14:24:38 -0700 Subject: [PATCH] doc/kernel-parameters.txt: clarify clk_ignore_unused Refine the definition around clk_ignore_unused, which caused some confusion recently on the linux-fbdev and linux-arm-kernel mailing lists[0]. [0] http://lkml.kernel.org/r/20140929135358.GC30998@ulmo Signed-off-by: Mike Turquette mturque...@linaro.org --- Thierry, Please let me know if this wording makes the feature more clear. Documentation/kernel-parameters.txt | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 10d51c2..0ce01fb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -605,11 +605,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See Documentation/s390/CommonIO for details. clk_ignore_unused [CLK] - Keep all clocks already enabled by bootloader on, - even if no driver has claimed them. This is useful - for debug and development, but should not be - needed on a platform with proper driver support. - For more information, see Documentation/clk.txt. + Prevents the clock framework from automatically gating + clocks that have not been explicitly enabled by a Linux + device driver but are enabled in hardware at reset or + by the bootloader/firmware. Note that this does not + force such clocks to be always-on nor does it reserve + those clocks in any way. This parameter is useful for + debug and development, but should not be needed on a + platform with proper driver support. For more + information, see Documentation/clk.txt. clock= [BUGS=X86-32, HW] gettimeofday clocksource override. [Deprecated] -- 1.8.3.2 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/4] dt-bindings: Add a clocks property to the simple-framebuffer binding
On Sun, Sep 28, 2014 at 5:43 AM, Hans de Goede hdego...@redhat.com wrote:
A simple-framebuffer node represents a framebuffer setup by the firmware /
bootloader. Such a framebuffer may have a number of clocks in use, add a
property to communicate this to the OS.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Mike Turquette mturque...@linaro.org
or
Reviewed-by: Mike Turquette mturque...@linaro.org
I don't know what is the right thing with these binding definitions...
Also I have one suggestion below:
---
Documentation/devicetree/bindings/video/simple-framebuffer.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 70c26f3..e75478e 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -14,6 +14,9 @@ Required properties:
- r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
+Optional properties:
+- clocks : List of clocks used by the framebuffer
+
Example:
framebuffer {
It might be nice to add the clocks property to the example. Something like:
clocks = osc 1, ref 0;
Regards,
Mike
--
2.1.0
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code
Quoting Maxime Ripard (2014-09-02 02:25:08) On Fri, Aug 29, 2014 at 04:38:14PM +0200, Thierry Reding wrote: On Fri, Aug 29, 2014 at 04:12:44PM +0200, Maxime Ripard wrote: On Fri, Aug 29, 2014 at 09:01:17AM +0200, Thierry Reding wrote: I would think the memory should still be reserved anyway to make sure nothing else is writing over it. And it's in the device tree anyway because the driver needs to know where to put framebuffer content. So the point I was trying to make is that we can't treat the memory in the same way as clocks because it needs to be explicitly managed. Whereas clocks don't. The driver is simply too generic to know what to do with the clocks. You agreed on the fact that the only thing we need to do with the clocks is claim them. Really, I don't find what's complicated there (or not generic). That's not what I agreed on. What I said is that the only thing we need to do with the clocks is nothing. They are already in the state that they need to be. Claim was probably a poor choice of words, but still. We have to keep the clock running, and both the solution you've been giving and this patch do so in a generic way. It doesn't know what frequency they should be running at We don't care about that. Just like we don't care about which frequency is the memory bus running at. It will just run at whatever frequency is appropriate. Exactly. And you shouldn't have to care about them at all. Firmware has already configured the clocks to run at the correct frequencies, and it has made sure that they are enabled. or what they're used for And we don't care about that either. You're not interested in what output the framebuffer is setup to use, which is pretty much the same here, this is the same thing here. That's precisely what I've been saying. The only thing that simplefb cares about is the memory it should be using and the format of the pixels (and how many of them) it writes into that memory. Everything else is assumed to have been set up. Including clocks. We're really discussing in circles here. Mike? -EHIGHLATENCYRESPONSE I forgot about this thread. Sorry. In an attempt to provide the least helpful answer possible, I will stay clear of all of the stuff relating to how simple should simplefb be and the related reserved memory discussion. A few times in this thread it is stated that we can't prevent unused clocks from being disabled. That is only partially true. The clock framework DOES provide a flag to prevent UNUSED clocks from being disabled at late_initcall-time by a clock garbage collector mechanism. Maxime and others familiar with the clock framework are aware of this. What the framework doesn't do is to allow for a magic flag in DT, in platform_data or elsewhere that says, don't let me get turned off until the right driver claims me. That would be an external or alternative method for preventing a clock from being disabled. We have a method for preventing clocks from being disabled. It is as follows: struct clk *my_clk = clk_get(...); clk_prepare_enable(my_clk); That is how it should be done. Period. With that said I think that Luc's approach is very sensible. I'm not sure what purpose in the universe DT is supposed to serve if not for _this_exact_case_. We have a nice abstracted driver, usable by many people. The hardware details of how it is hooked up at the board level can all be hidden behind stable DT bindings that everyone already uses. What more could you want? Regards, Mike Your opinion would be very valuable. so by any definition of what DT should describe they're useless for this virtual device. Furthermore it's fairly likely that as your kernel support progresses you'll find that the driver all of a sudden needs to manage some other type of resource that you just haven't needed until now because it may default to being always on. Then you'll have a hard time keeping backwards-compatibility and will have to resort to the kinds of hacks that you don't want to see in the kernel. Not such a hard time. An older DT wouldn't define the new requirements anyway, so they wouldn't be used, and we would end up in pretty much the current case. Except that you have firmware in the wild that sets up an incomplete simplefb node and if you don't want to break compatibility you need to provide fallbacks for the resources that aren't listed in the DT node. And given that those fallbacks are all very board specific you'll need to find ways to keep them enabled if you want to keep existing setups working. How would an *optional* property break those users? If you don't need any clock to be kept running (or are hiding them under the carpet), of course you don't need such a property. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering
[linux-sunxi] Re: [PATCH 0/7] clk: sun6i: Unify AHB1 clock and fix rate calculation
Quoting Chen-Yu Tsai (2014-09-25 17:55:27) On Fri, Sep 26, 2014 at 8:25 AM, Mike Turquette mturque...@linaro.org wrote: Quoting Maxime Ripard (2014-09-11 13:36:23) Hi Chen-Yu, On Sat, Sep 06, 2014 at 06:47:21PM +0800, Chen-Yu Tsai wrote: Hi everyone, This series unifies the mux and divider parts of the AHB1 clock found on sun6i and sun8i, while also adding support for the pre-divider on the PLL6 input. The rate calculation logic must factor in which parent it is using to calculate the rate, to decide whether to use the pre-divider or not. This is beyond the original factors clk design in sunxi. To avoid feature bloat, this is implemented as a seperate composite clk. The new clock driver is registered with a separate OF_CLK_DECLARE. This is done so that assigned-clocks* properties on the clk provider node can actually work. The clock framework arranges the clock setup order by checking whether all clock parents are available, by checking the node matching OF_CLK_DECLARE. However, the sunxi clk driver is based on the root node compatible, has no defined dependencies (parents), and is setup before the fixed-rate clocks. Thus when the ahb1 clock is added, all parents have rate = 0. There is no way to calculate the required clock factors to set a default clock rate under these circumstances. This happens when we set the defaults in the clock node (provider), rather than a clock consumer. I can think of 2 ways to solve the dependency issue, but neither is pretty. One would be to move the root fixed-rate clocks into the sunxi clk driver. The other would be separating all the clocks into individual OF_CLK_DECLARE statements, which adds a lot of boilerplate code. I don't know what Mike thinks of this, but I'd prefer the second. I do not fully understand the problem. Ideally the clock driver should have some way to fail with EPROBE_DEFER until the fixed-rate clocks are registered. Those fixed-rate parents are enumerated in your dts, right? Why isn't this enough? This is due to the way the sunxi clock driver is setup. The clock driver's OF_CLK_DECLARE matches against the soc node, not the individual clock nodes. When the setup function is called, it just registers all the supported clocks. There are no dependencies listed. Unfortunately, the fixed-factor clock is in the middle of the whole clock tree. The sunxi clock driver provides its parents _and_ its children. Naturally the clock framework then probes the fixed-factor clock after the sunxi ones. Any attempts to change the state of clocks under the unavailable fixed-factor clock, such as done by of_clk_set_defaults(), would get an incomplete clock, likely with no parents and parent_rate = 0. That is until of_clk_init() finishes and all clocks are properly hooked up. Anyway, this problem only occurred when I added clk-assigned-* defaults to the clock provider node, which is not the case anymore. Makes sense. I guess you could ignore the problem until you need to use the assigned defaults. The second method i proposed is to have OF_CLK_DECLAREs for each individual clock. An example can be found here: https://github.com/wens/linux/commit/1276898da02a93da4af163ed5bdc88cdead565dc This does add a lot of boilerplate code. Not really happy about it. But it seems the proper way to split up the driver. Yeah, this is OK. Ugly, but OK. Regards, Mike Cheers ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider
Quoting Maxime Ripard (2014-09-13 03:26:03) On Fri, Sep 12, 2014 at 11:16:26AM +0800, Chen-Yu Tsai wrote: Hi, On Fri, Sep 12, 2014 at 5:02 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Sat, Sep 06, 2014 at 06:47:24PM +0800, Chen-Yu Tsai wrote: This patch unifies the sun6i AHB1 clock, originally supported with separate mux and divider clks. It also adds support for the pre-divider on the PLL6 input, thus allowing the clock to be muxed to PLL6 with proper clock rate calculation. Signed-off-by: Chen-Yu Tsai w...@csie.org It looks fine, but I'd rather see this in a separate file, especially since we don't seem to have any order dependency. Sorry, just to be clear, separate file under clk/sunxi? Yes This cannot be in a separate file, as it shares a spinlock with apb1 divider. They share the same register. We could move apb1 out though. But i would prefer to do that when we split out all the clocks into individual OF_CLK_DECLAREs. Ah right, my bad :) My plan on the long term is to kill clk-sunxi as a place where all the clocks are defined, and only leave the policy there, for example the clock protection code (even if that should probably be removed too, together with clkdev), the various rates / parenting enforcements, etc. Interesting! Where are you planning to store the clock data? Regards, Mike Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/6] clk: sunxi: fixes, cleanups and A23 basic clocks
Quoting Chen-Yu Tsai (2014-06-26 08:55:38) Hi everyone, This is v4 of the sun8i clock series, which adds basic clock support for the A23 SoC. It is based on my initial sun8i bring up series [1]. This series was split up from the original A23 series [2]. Yet to come are more clocks, reset controllers, prcm, pinctrl, and mmc. Hello Chen-Yu, This series looks good to me. Maxime, I see that you Acked it already. Are you planning to roll this into a pull request later on? Regards, Mike The first patch fixes the reworked clock protection code merged in 3.16-rc1, which unintentionally made clock gates unprotectable. The second patch moves the remaining ahb_sdram clock to the protected clock list, now that it works. The third patch adds support for factor clocks that have an N factor not starting from 0. This is found on some PLLs in A31/A23. The fourth patch adds table-based dividers for div clocks, as some clocks, such as apb0 divider on sun4/5/7i, apb1 on sun6/8i and axi on sun8i. The fifth patch adds support for the basic clocks in the A23, just PLL1 for cpus, and the system bus clocks and gates. The last patch adds the DT nodes for the newly added clocks, and updates clock phandles for existing peripherals, the uarts. Originally I intended for patch 1 to be merged as a fix for 3.16. However, the only user of the affected code, sun6i's ahb1_sdram clock, doesn't seem to result in any runtime issues. So this whole series can go into 3.17. Related changes since v3: - Dropped fields with default values from sun8i_a23_axi_div_data - Added Maxime's Acked-by - Fixed incorrect compatible string for axi clock node - Updated clock phandles for uarts in dtsi Related changes since v2: - Rewrote factor clocks to support any (0~255) N factor starting value Related changes since v1: - Added clk: sunxi: Add support for table-based divider clocks - Added table-based divider axi clock - Fixed incorrectly squashed fixups Cheers ChenYu [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/265211.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/259097.html Chen-Yu Tsai (6): clk: sunxi: register clock gates with clkdev clk: sunxi: move ahb_sdram to protected clock list clk: sunxi: Support factor clocks with N factor starting not from 0 clk: sunxi: Add support for table-based divider clocks clk: sunxi: Add A23 clocks support ARM: sun8i: Add basic clock nodes to the DTSI Documentation/devicetree/bindings/clock/sunxi.txt | 5 + arch/arm/boot/dts/sun8i-a23.dtsi | 125 +- drivers/clk/sunxi/clk-factors.c | 2 +- drivers/clk/sunxi/clk-factors.h | 1 + drivers/clk/sunxi/clk-sunxi.c | 119 ++-- 5 files changed, 237 insertions(+), 15 deletions(-) -- 2.0.0 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support
Quoting Boris BREZILLON (2014-05-14 00:30:59)
Hello Mike,
On 14/05/2014 02:51, Mike Turquette wrote:
Quoting Boris BREZILLON (2014-05-09 04:11:49)
+struct clk_ops ar100_ops = {
+ .recalc_rate = ar100_recalc_rate,
+ .determine_rate = ar100_determine_rate,
+ .set_parent = ar100_set_parent,
+ .get_parent = ar100_get_parent,
+ .set_rate = ar100_set_rate,
+};
I might be having a brain fart, but is there a valid case for having
both a .recalc_rate and a .determine_rate? I believe that the former
will never be used and the latter will always be used by the clock
framework core.
I think you're mistaking recalc_rate for round_rate.
AFAIK, recalc_rate is mandatory for a clk that implement either
round_rate or determine_rate.
I *was* having a brain fart. You're right of course. Too many .r*_rate()
callbacks...
Thanks,
Mike
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 0/6] sunxi: clk: Various cleanup and rework
Quoting Emilio López (2014-05-10 10:22:15) Hi Maxime, El 10/05/14 00:33, Maxime Ripard escribió: Hi everyone, This patchset fixes a few things that have been pending for quite a while in the clock driver. First, it removes the clk_put calls in the clock protection part. Since it's not really something that should be done, I guess this patch is not very controversial. Then, it starts splitting the huge clock driver file into separate, smaller drivers when it makes sense. Finally, it reworks the clock protection mechanism to handle differences between SoC in a better way. This has been pretty controversial because the first approach has been to move this to the machine code. This is another attempt that leaves all the modifications in the driver itself. Thanks, Maxime Overall the series looks good to me, other than the comment about clkdev on patches 2 and 3. @Mike, do you want me to take them in a pull as usual after you have a look? Please let me know as we still haven't clarified the situation with the two patches Hans sent. A pull request would be great. Feel free to add my Acked-by to all of the patches here (#1 already has it) since I looked at all of them and the changes seem good. Regards, Mike Cheers, and thanks Maxime for working on cleaning this :) Emilio -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 3/8] ARM: sunxi: Move the clock protection to machine hooks
Quoting Arnd Bergmann (2014-04-23 06:31:06)
On Wednesday 23 April 2014 15:17:20 Maxime Ripard wrote:
+#include linux/clk.h
#include linux/init.h
#include linux/of_platform.h
@@ -19,9 +20,17 @@
static void __init sun4i_dt_init(void)
{
+ struct clk *clk;
+
sunxi_setup_restart();
of_platform_populate(NULL, of_default_bus_match_table, NULL,
NULL);
+
+ /* Make sure the clocks we absolutely need are enabled */
+ /* DDR clock */
+ clk = clk_get(NULL, pll5_ddr);
+ if (!IS_ERR(clk))
+ clk_prepare_enable(clk);
}
Isn't there already DT syntax to do the same? If not, should there be?
I don't think there is, and I gave some thought about it too. But
something a la regulator-always-on wouldn't work with clocks with
multiple outputs (like pll5), because you might need to leave only one
of the output enabled, but not the others, and I couldn't think of a
nice way to do so.
If you have one, I'd be happy to implement it.
We had a discussion a while ago about encoding default settings for clock
providers in the clock provider nodes. I don't remember the details
unfortunately.
Mike, can you explain how this should be done?
The default clock settings are still in discussion. My perspective is
that the default settings are best used by the consuming device. E.g. an
MMC controller that consumes a clock signal should specify in DT the
clock that it consumes (already does this) and the preferred rate that
it wants that clock, as well as the preferred parent if that clock is a
mux.
Of course clock providers themselves are devices and could specify such
defaults for the clocks that they create. This approach is a minor
bastardization of the default clock settings since the clock provider
device isn't really consuming the clock, but it is helpful when no such
driver or DT node exists to do the same.
It is worth pointing out that the above approach amounts to the exact
same hard coding of clk_enable requirements as is done in Maxime's
patch, but with the added problem that the default are hidden away in DT
somewhere which is a debugging nightmare for someone trying to figure
out why a clock is set at a certain rate.
Finally, to answer the question more directly, I completely oppose
having something analogous to a regulator-always-on for a clock that can
gate. Please always use the clk.h API for this in Linux kernel driver C
code:
clk_get()
clk_prepare()
clk_enable()
In Maxime's case he is doing the right thing (using the clk.h API) but
he has no memory driver to do it, so he is putting that stuff in the clk
provider driver. I'm fine with that solution, until the day that he does
have a memory driver and then it needs to migrate out to that code.
Regards,
Mike
Arnd
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 1/8] clk: sunxi: Implement A31 USB clock
Quoting Maxime Ripard (2014-05-12 12:34:27)
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate
for
all the phy.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by: Hans de Goede hdego...@redhat.com
Acked-by: Mike Turquette mturque...@linaro.org
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index bd7dc733c1ca..d9bab75f128b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -972,6 +972,11 @@ static const struct gates_data sun5i_a13_usb_gates_data
__initconst = {
.reset_mask = 0x03,
};
+static const struct gates_data sun6i_a31_usb_gates_data __initconst = {
+ .mask = { BIT(18) | BIT(17) | BIT(16) | BIT(10) | BIT(9) | BIT(8) },
+ .reset_mask = BIT(2) | BIT(1) | BIT(0),
+};
+
static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
@@ -1267,6 +1272,7 @@ static const struct of_device_id clk_gates_match[]
__initconst = {
{.compatible = allwinner,sun6i-a31-apb2-gates-clk, .data =
sun6i_a31_apb2_gates_data,},
{.compatible = allwinner,sun4i-a10-usb-clk, .data =
sun4i_a10_usb_gates_data,},
{.compatible = allwinner,sun5i-a13-usb-clk, .data =
sun5i_a13_usb_gates_data,},
+ {.compatible = allwinner,sun6i-a31-usb-clk, .data =
sun6i_a31_usb_gates_data,},
{}
};
--
1.9.3
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v10 00/15] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
Quoting Hans de Goede (2014-05-02 08:57:14) The first 2 patches are depenencies which should go in through the clk tree, Mike can you pick these 2 up please ? : Taken into clk-next. clk: sunxi: factors: automatic reparenting support Is uncontroversial and has been favorably reviewed by various people. clk: sunxi: Implement MMC phase control Is somewhat more controversial as there has been lots of discussion about adding a generic phase control method to the clk framework. The problem is that there has been a lot of talk about such a generic phase control method but not a single patch. Therefor I would like to move forwards with using a platform specific method for now. I hereby promise that once we've a generic method I'll write patches to convert the sunxi code to that method. Thanks for the promise. I will hold you to it once the set_phase api is sorted ;-) Also thanks for the clear and concise cover letter. It is very helpful when going through the tenth iteration of a series. Regards, Mike -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 1/7] clk: sunxi: Remove calls to clk_put
Quoting Maxime Ripard (2014-03-13 08:14:13)
Callers of clk_put must disable the clock first. This also means that as long
as the clock is enabled the driver should hold a reference to that clock.
Hence, the call to clk_put here are bogus and should be removed.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Looks good to me. There is a balanced clk_put in the module remove
function?
Regards,
Mike
---
drivers/clk/sunxi/clk-sunxi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 23baad9d934a..7119c02c9fa8 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1290,17 +1290,13 @@ static void __init sunxi_clock_protect(void)
/* memory bus clock - sun5i+ */
clk = clk_get(NULL, mbus);
- if (!IS_ERR(clk)) {
+ if (!IS_ERR(clk))
clk_prepare_enable(clk);
- clk_put(clk);
- }
/* DDR clock - sun4i+ */
clk = clk_get(NULL, pll5_ddr);
- if (!IS_ERR(clk)) {
+ if (!IS_ERR(clk))
clk_prepare_enable(clk);
- clk_put(clk);
- }
}
static void __init sunxi_init_clocks(void)
--
1.9.0
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v7 2/8] clk: sunxi: Implement MMC phase control
Quoting Maxime Ripard (2014-02-19 00:36:06)
Hi Mike,
On Tue, Feb 18, 2014 at 09:21:25PM -0800, Mike Turquette wrote:
Quoting Maxime Ripard (2014-02-18 06:15:32)
Hi,
On Mon, Feb 17, 2014 at 11:02:21AM +0100, David Lanzendörfer wrote:
From: Emilio López emi...@elopez.com.ar
Signed-off-by: Emilio López emi...@elopez.com.ar
You're missing your Signed-off-by here too. Remember, for every patch
you send, your Signed-off-by must be there, regardless wether you're
the author or not.
A commit log would be very much welcome too.
Now, down to the patch itself, I remember Mike saying that he would
prefer adding a function in the framework instead of hardcoding
it. Mike, what's your feeling on this? Would merging this seem
reasonnable to you as is, or do you want to take this to the
framework?
Hi Maxime Emilio,
Maybe something like the following RFC? If it seems sufficient for this
case then I will post to the wider list with an eye towards merging it
for 3.15. I've Cc'd Dinh since this came up on the socfpga thread as
well.
Regards,
Mike
From 56fa297591be5c5e22df6d2ca43fccf285a45636 Mon Sep 17 00:00:00 2001
From: Mike Turquette mturque...@linaro.org
Date: Tue, 18 Feb 2014 20:33:50 -0800
Subject: [PATCH] clk: introduce clk_set_phase function callback
A common operation for a clock signal generator is to shift the phase of
that signal. This patch introduces a new function to the clk.h API to
dynamically adjust the phase of a clock signal. Additionally this patch
introduces support for the new function in the common clock framework
via the .set_phase call back in struct clk_ops.
Signed-off-by: Mike Turquette mturque...@linaro.org
---
This patch is totally untested. It may make your board burst into
flames.
drivers/clk/clk.c| 84
+---
include/linux/clk-private.h | 1 +
include/linux/clk-provider.h | 5 +++
include/linux/clk.h | 29 +++
4 files changed, 115 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ea2ca9f..635170a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -106,11 +106,11 @@ static void clk_summary_show_one(struct seq_file *s,
struct clk *c, int level)
if (!c)
return;
- seq_printf(s, %*s%-*s %-11d %-12d %-10lu %-11lu,
+ seq_printf(s, %*s%-*s %-11d %-12d %-10lu %-11lu %-3d,
level * 3 + 1, ,
30 - level * 3, c-name,
c-enable_count, c-prepare_count, clk_get_rate(c),
-clk_get_accuracy(c));
+clk_get_accuracy(c), clk_get_phase(c));
seq_printf(s, \n);
}
@@ -132,8 +132,8 @@ static int clk_summary_show(struct seq_file *s, void
*data)
{
struct clk *c;
- seq_printf(s,clockenable_cnt
prepare_cnt rateaccuracy\n);
- seq_printf(s,
-\n);
+ seq_printf(s,clockenable_cnt
prepare_cnt rateaccuracy phase\n);
+ seq_printf(s,
-\n);
clk_prepare_lock();
@@ -171,6 +171,7 @@ static void clk_dump_one(struct seq_file *s, struct clk
*c, int level)
seq_printf(s, \prepare_count\: %d,, c-prepare_count);
seq_printf(s, \rate\: %lu, clk_get_rate(c));
seq_printf(s, \accuracy\: %lu, clk_get_accuracy(c));
+ seq_printf(s, \phase\: %d, clk_get_phase(c));
}
static void clk_dump_subtree(struct seq_file *s, struct clk *c, int level)
@@ -257,6 +258,11 @@ static int clk_debug_create_one(struct clk *clk,
struct dentry *pdentry)
if (!d)
goto err_out;
+ d = debugfs_create_u32(clk_phase, S_IRUGO, clk-dentry,
+ (u32 *)clk-phase);
+ if (!d)
+ goto err_out;
+
d = debugfs_create_x32(clk_flags, S_IRUGO, clk-dentry,
(u32 *)clk-flags);
if (!d)
@@ -1766,6 +1772,76 @@ out:
EXPORT_SYMBOL_GPL(clk_set_parent);
/**
+ * clk_set_phase - adjust the phase shift of a clock signal
+ * @clk: clock signal source
+ * @degrees: number of degrees the signal is shifted
+ *
+ * Shifts the phase of a clock signal by the specified degrees. Returns 0
on
+ * success, -EERROR otherwise.
+ *
+ * This function makes no distiction about the input or reference signal
that
+ * we adjust the clock signal phase against. For example phase locked-loop
+ * clock signal generators we may shift phase with respect to feedback
clock
+ * signal input, but for other cases the clock phase may be shifted with
+ * respect to some other, unspecified signal
[linux-sunxi] Re: [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
Quoting Chen-Yu Tsai (2014-02-10 02:35:47)
The Allwinner A20/A31 clock module controls the transmit clock source
and interface type of the GMAC ethernet controller. Model this as
a single clock for GMAC drivers to use.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Looks good to me.
Regards,
Mike
---
Documentation/devicetree/bindings/clock/sunxi.txt | 30 +++
drivers/clk/sunxi/clk-sunxi.c | 97
+++
2 files changed, 127 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0cf679b..28421d2 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -37,6 +37,7 @@ Required properties:
allwinner,sun6i-a31-apb2-gates-clk - for the APB2 gates on A31
allwinner,sun4i-mod0-clk - for the module 0 family of clocks
allwinner,sun7i-a20-out-clk - for the external output clocks
+ allwinner,sun7i-a20-gmac-clk - for the GMAC clock module on A20/A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -50,6 +51,9 @@ Required properties for all clocks:
If the clock module only has one output, the name shall be the
module name.
+For allwinner,sun7i-a20-gmac-clk, the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+
Clock consumers should specify the desired clocks they use with a
clocks phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
@@ -96,3 +100,29 @@ mmc0_clk: clk@01c20088 {
clocks = osc24M, pll6 1, pll5 1;
clock-output-names = mmc0;
};
+
+mii_phy_tx_clk: clk@2 {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2500;
+ clock-output-names = mii_phy_tx;
+};
+
+gmac_int_tx_clk: clk@3 {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 12500;
+ clock-output-names = gmac_int_tx;
+};
+
+gmac_clk: clk@01c20164 {
+ #clock-cells = 0;
+ compatible = allwinner,sun7i-a20-gmac-clk;
+ reg = 0x01c20164 0x4;
+ /*
+* The first clock must be fixed at 25MHz;
+* the second clock must be fixed at 125MHz
+*/
+ clocks = mii_phy_tx_clk, gmac_int_tx_clk;
+ clock-output-names = gmac;
+};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 736fb60..da1d5cc 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -379,6 +379,103 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32
parent_rate,
/**
+ * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
+ *
+ * This clock looks something like this
+ *
+ * MII TX clock from PHY -|____| to GMAC core
+ * GMAC Int. RGMII TX clk |___\__/__gate---| to PHY
+ * Ext. 125MHz RGMII TX clk --|__divider__/|
+ * ||
+ *
+ * The external 125 MHz reference is optional, i.e. GMAC can use its
+ * internal TX clock just fine. The A31 GMAC clock module does not have
+ * the divider controls for the external reference.
+ *
+ * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
+ * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
+ * select the appropriate source and gate/ungate the output to the PHY.
+ *
+ * Only the GMAC should use this clock. Altering the clock so that it doesn't
+ * match the GMAC's operation parameters will result in the GMAC not being
+ * able to send traffic out. The GMAC driver should set the clock rate and
+ * enable/disable this clock to configure the required state. The clock
+ * driver then responds by auto-reparenting the clock.
+ */
+
+#define SUN7I_A20_GMAC_GPIT2
+#define SUN7I_A20_GMAC_MASK0x3
+#define SUN7I_A20_GMAC_PARENTS 2
+
+static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_mux *mux;
+ struct clk_gate *gate;
+ const char *clk_name = node-name;
+ const char *parents[SUN7I_A20_GMAC_PARENTS];
+ void *reg;
+ int i = 0;
+
+ if (of_property_read_string(node, clock-output-names, clk_name))
+ return;
+
+ /* allocate mux and gate clock structs */
+ mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+ if (!mux)
+ return;
+
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ if (!gate)
+ goto free_mux;
+
+ /* gmac clock requires exactly 2 parents */
+ parents[0] = of_clk_get_parent_name(node, 0);
+
[linux-sunxi] Re: [PATCH v4 1/5] clk: sunxi: Add support for PLL6 on the A31
Quoting Maxime Ripard (2014-02-05 05:05:03)
The A31 has a slightly different PLL6 clock. Add support for this new clock in
our driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Looks good to me.
Regards,
Mike
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 45
+++
2 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index c2cb762..954845c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -11,6 +11,7 @@ Required properties:
allwinner,sun6i-a31-pll1-clk - for the main PLL clock on A31
allwinner,sun4i-pll5-clk - for the PLL5 clock
allwinner,sun4i-pll6-clk - for the PLL6 clock
+ allwinner,sun6i-a31-pll6-clk - for the PLL6 clock on A31
allwinner,sun4i-cpu-clk - for the CPU multiplexer clock
allwinner,sun4i-axi-clk - for the AXI clock
allwinner,sun4i-axi-gates-clk - for the AXI gates
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index abb6c5a..0c05c2d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32
parent_rate,
*n = DIV_ROUND_UP(div, (*k+1));
}
+/**
+ * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
+ * PLL6 rate is calculated as follows
+ * rate = parent_rate * n * (k + 1) / 2
+ * parent_rate is always 24Mhz
+ */
+
+static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
+ u8 *n, u8 *k, u8 *m, u8 *p)
+{
+ u8 div;
+
+ /*
+* We always have 24MHz / 2, so we can just say that our
+* parent clock is 12MHz.
+*/
+ parent_rate = parent_rate / 2;
+
+ /* Normalize value to a parent_rate multiple (24M / 2) */
+ div = *freq / parent_rate;
+ *freq = parent_rate * div;
+
+ /* we were called to round the frequency, we can now return */
+ if (n == NULL)
+ return;
+
+ *k = div / 32;
+ if (*k 3)
+ *k = 3;
+ *n = DIV_ROUND_UP(div, (*k+1));
+}
/**
* sun4i_get_apb1_factors() - calculates m, p factors for APB1
@@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
.kwidth = 2,
};
+static struct clk_factors_config sun6i_a31_pll6_config = {
+ .nshift = 8,
+ .nwidth = 5,
+ .kshift = 4,
+ .kwidth = 2,
+};
+
static struct clk_factors_config sun4i_apb1_config = {
.mshift = 0,
.mwidth = 5,
@@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data
__initconst = {
.getter = sun4i_get_pll5_factors,
};
+static const struct factors_data sun6i_a31_pll6_data __initconst = {
+ .enable = 31,
+ .table = sun6i_a31_pll6_config,
+ .getter = sun6i_a31_get_pll6_factors,
+};
+
static const struct factors_data sun4i_apb1_data __initconst = {
.table = sun4i_apb1_config,
.getter = sun4i_get_apb1_factors,
@@ -972,6 +1016,7 @@ free_clkdata:
static const struct of_device_id clk_factors_match[] __initconst = {
{.compatible = allwinner,sun4i-pll1-clk, .data = sun4i_pll1_data,},
{.compatible = allwinner,sun6i-a31-pll1-clk, .data =
sun6i_a31_pll1_data,},
+ {.compatible = allwinner,sun6i-a31-pll6-clk, .data =
sun6i_a31_pll6_data,},
{.compatible = allwinner,sun4i-apb1-clk, .data = sun4i_apb1_data,},
{.compatible = allwinner,sun4i-mod0-clk, .data = sun4i_mod0_data,},
{.compatible = allwinner,sun7i-a20-out-clk, .data =
sun7i_a20_out_data,},
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi: Allwinner A20 output clock support
Quoting Chen-Yu Tsai (2013-12-24 05:26:17)
This patch adds support for the external clock outputs on the
Allwinner A20 SoC. The clock outputs are similar to module 0
type clocks, with different offsets and widths for clock factors.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Looks good to me.
Regards,
Mike
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 57
+++
2 files changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 46d8433..c2cb762 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -36,6 +36,7 @@ Required properties:
allwinner,sun6i-a31-apb2-div-clk - for the APB2 gates on A31
allwinner,sun6i-a31-apb2-gates-clk - for the APB2 gates on A31
allwinner,sun4i-mod0-clk - for the module 0 family of clocks
+ allwinner,sun7i-a20-out-clk - for the external output clocks
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 25d99b6..19d9e9e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -330,6 +330,47 @@ static void sun4i_get_mod0_factors(u32 *freq, u32
parent_rate,
/**
+ * sun7i_a20_get_out_factors() - calculates m, p factors for CLK_OUT_A/B
+ * CLK_OUT rate is calculated as follows
+ * rate = (parent_rate p) / (m + 1);
+ */
+
+static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
+ u8 *n, u8 *k, u8 *m, u8 *p)
+{
+ u8 div, calcm, calcp;
+
+ /* These clocks can only divide, so we will never be able to achieve
+* frequencies higher than the parent frequency */
+ if (*freq parent_rate)
+ *freq = parent_rate;
+
+ div = parent_rate / *freq;
+
+ if (div 32)
+ calcp = 0;
+ else if (div / 2 32)
+ calcp = 1;
+ else if (div / 4 32)
+ calcp = 2;
+ else
+ calcp = 3;
+
+ calcm = DIV_ROUND_UP(div, 1 calcp);
+
+ *freq = (parent_rate calcp) / calcm;
+
+ /* we were called to round the frequency, we can now return */
+ if (n == NULL)
+ return;
+
+ *m = calcm - 1;
+ *p = calcp;
+}
+
+
+
+/**
* sunxi_factors_clk_setup() - Setup function for factor clocks
*/
@@ -384,6 +425,14 @@ static struct clk_factors_config sun4i_mod0_config = {
.pwidth = 2,
};
+/* user manual says n but it's really p */
+static struct clk_factors_config sun7i_a20_out_config = {
+ .mshift = 8,
+ .mwidth = 5,
+ .pshift = 20,
+ .pwidth = 2,
+};
+
static const struct factors_data sun4i_pll1_data __initconst = {
.enable = 31,
.table = sun4i_pll1_config,
@@ -414,6 +463,13 @@ static const struct factors_data sun4i_mod0_data
__initconst = {
.getter = sun4i_get_mod0_factors,
};
+static const struct factors_data sun7i_a20_out_data __initconst = {
+ .enable = 31,
+ .mux = 24,
+ .table = sun7i_a20_out_config,
+ .getter = sun7i_a20_get_out_factors,
+};
+
static struct clk * __init sunxi_factors_clk_setup(struct device_node *node,
const struct factors_data
*data)
{
@@ -912,6 +968,7 @@ static const struct of_device_id clk_factors_match[]
__initconst = {
{.compatible = allwinner,sun6i-a31-pll1-clk, .data =
sun6i_a31_pll1_data,},
{.compatible = allwinner,sun4i-apb1-clk, .data = sun4i_apb1_data,},
{.compatible = allwinner,sun4i-mod0-clk, .data = sun4i_mod0_data,},
+ {.compatible = allwinner,sun7i-a20-out-clk, .data =
sun7i_a20_out_data,},
{}
};
--
1.8.5.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi: Allwinner A20 output clock support
Quoting Emilio López (2013-12-23 08:23:47) Hi again, El 23/12/13 13:13, Emilio López escribió: Hi, El 23/12/13 05:37, Chen-Yu Tsai escribió: This patch adds support for the external clock outputs on the Allwinner A20 SoC. The clock outputs are similar to module 0 type clocks, with different offsets and widths for clock factors. Signed-off-by: Chen-Yu Tsai w...@csie.org This patch looks good to me, Acked-by: Emilio López emi...@elopez.com.ar --- drivers/clk/sunxi/clk-sunxi.c | 57 +++ 1 file changed, 57 insertions(+) Please add the new binding to the binding document; I just noticed it was missing. You can keep the Ack once you do so. Feel free to add this to your [PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support pull request. Regards, Mike Cheers, Emilio -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
