* [PATCH] clk: Make the generic clock API available by default
From: Mark Brown @ 2012-10-23 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJhJPsV0rnE+K-9bWFy85T36H+PfbibrsGQ_mN_miqttyQJNhw@mail.gmail.com>
On Tue, Oct 23, 2012 at 10:10:09AM +0800, Kelvin Cheung wrote:
> Hi Mark,
Don't top post!
> But the common clock infrastructure of Loongson1 has been implemented and
> enabled in previous patches.
> http://patchwork.linux-mips.org/patch/4268/
> Please remove this arch from your patch.
Done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/c711ae19/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-23 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981706.20938.7.camel@gitbox>
On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> On Mon, 2012-10-22 at 10:04 +0200, Thierry Reding wrote:
> > On Mon, Oct 22, 2012 at 08:36:22PM +1300, Tony Prisk wrote:
> > > On Mon, 2012-10-22 at 09:24 +0200, Thierry Reding wrote:
> > > > On Mon, Oct 22, 2012 at 08:09:07PM +1300, Tony Prisk wrote:
> > > > > On Mon, 2012-10-22 at 19:51 +1300, Tony Prisk wrote:
> > > > > > >
> > > > > > > > chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
> > > > > > > > if (chip == NULL) {
> > > > > > > > dev_err(&pdev->dev, "failed to allocate memory\n");
> > > > > > > > @@ -123,26 +144,32 @@ static int __devinit pwm_probe(struct platform_device *pdev)
> > > > > > > > chip->chip.ops = &vt8500_pwm_ops;
> > > > > > > > chip->chip.base = -1;
> > > > > > > > chip->chip.npwm = VT8500_NR_PWMS;
> > > > > > > > + chip->clk = of_clk_get(np, 0);
> > > > > > >
> > > > > > > I thought this was supposed to work transparently across OF and !OF
> > > > > > > configurations by using just clk_get() or devm_clk_get()? I guess that
> > > > > > > if the driver depends on OF, then this would be moot, but we should
> > > > > > > probably stick to the standard usage anyway.
> > > > > > >
> > > > > > > Furthermore, of_clk_get() doesn't seem to be managed, so you'd need to
> > > > > > > add explicit clk_put() in the error cleanup paths. One more argument in
> > > > > > > favour of using devm_clk_get() instead.
> > > > > >
> > > > > > Hmm good point. I stuck with of_ functions because its an OF only driver
> > > > > > and it seemed 'backward' to mix old code with new. It does pose the
> > > > > > question of 'why have of_clk_get() if existing functions work better'.
> > > > >
> > > > > Was about to fix this but noticed why it wasn't like this to start
> > > > > with :)
> > > > >
> > > > > struct clk *devm_clk_get(struct device *dev, const char *id);
> > > > > struct clk *of_clk_get(struct device_node *np, int index);
> > > > >
> > > > > devm_clk_get requires me to 'get' the clock by name. arch-vt8500 (and I
> > > > > believe a lot of other arch's) don't enforce names for clocks defined in
> > > > > devicetree, therefore there is no way for me to know what name the clk
> > > > > has unless I include in the binding that the clock must be named 'xxx'.
> > > >
> > > > I thought clk_get() was supposed to return the first clock specified in
> > > > DT if you pass NULL as the consumer name. I haven't tested this though.
> > > > And I haven't looked at the code.
> > > >
> > > > > of_clk_get retrieves it by the dt-node + index, so it doesn't care as
> > > > > long as its the 1st clock listed.
> > > >
> > > > So the usual way to do this, I believe, is:
> > > >
> > > > clocks = <&clk_foo>;
> > > > clock-names = "foo";
> > > >
> > > > Then use:
> > > >
> > > > clk = devm_clk_get(&pdev->dev, "foo");
> > > >
> > > > And as I said above, I was under the impression that the default would
> > > > be to use the first clock if NULL was specified instead of "foo".
> > > >
> > > > Thierry
> > >
> > > clock-names is an optional property (as defined in
> > > bindings/clock/clock-bindings.txt) so relying on it is .. well,
> > > unreliable.
> > >
> > > What you say makes sense, but it means the binding document has to make
> > > an optional property into a required property simply to use an 'old'
> > > function when a new function would 'work' (granted not as well, as you
> > > pointed out) without requiring the optional property.
> >
> > Okay, I've just checked the core clock code, and indeed if you run
> > clk_get() with con_id set to NULL, you'll eventually call of_clk_get()
> > with index == 0. That's exactly what you want, right? The only setup
> > where this won't work out is if you need to handle multiple clocks, in
> > which case I think it would make sense to make the clock-names property
> > mandatory. But for this driver that won't be necessary, since it will
> > never use a second clock, right?
> >
> > > Your subsystem - your rules. Let me know if I've managed to sway you or
> > > not :)
> >
> > I'd rather persuade you than force the issue. =)
> >
> > Thierry
>
> Further to the discussion, my preference is still for of_clk_get()
> (although I've changed the patch anyway as you saw because it makes no
> difference in this case) :)
>
> clk_get(x, NULL) and devm_clk_get(x, NULL) both seems like 'hacks' to
> allow platforms to convert to DT without having to update all their
> drivers first. It only allows the first (default) clock, as your pointed
> out. Getting a 2nd... clock relies on an optional property in DT (which
> again, seems like it is there to support 'old' drivers) which allows you
> to request clocks by name.
>
> of_clk_get() on the other hand seems like a properly native DT function.
> You don't need to know anything about the clock, as long as the correct
> clock is specified in the correct order as documented by the binding.
> Relying on 'pre-OF' code for a OF-only driver also seems
> counter-intuitive.
I do agree with those arguments. What I was saying is that for drivers
which aren't DT only, of_clk_get() is not an option and that maybe
others would be encouraged by the example to not use the generic APIs
even if their driver could be used in non-DT setups. But maybe I'm
worrying needlessly.
That said, maybe somebody with a broader view of things like Arnd
(Cc'ed) could share his thoughts.
> Granted of_clk_get() doesn't provide the 'garbage-collection' of
> devm_get_clk() but I think that is just an arguement to needing
> of_devm_clk_get().
That can be remedied by adding a corresponding function, so the argument
doesn't really count.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/cecc2bf5/attachment-0001.sig>
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Linus Walleij @ 2012-10-23 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085AC06.8070508@wwwdotorg.org>
On Mon, Oct 22, 2012 at 10:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/22/2012 02:45 AM, Linus Walleij wrote:
>> For the Ux500 drivers we have found that all of those that have pin
>> resources actually have to be handled by the driver. The reason is
>> that all of them have idle and/or sleep states that need to be
>> handled at runtime.
>
> Well, presumably the pinctrl driver itself could have both default/idle
> states, and system sleep could engage the appropriate system-wide setting.
I thought about that, but it does not allow us to control the
resource activation/deactivation order.
In some drivers the suspend() path could be:
- pins to sleep
- clk_disable
- disable external regulator
- release power domain
In others:
- clk_disable()
- disable external regulator
- pins to sleep()
- release power domain
Ulf Hansson ran into this a while back.
Just like with the notifier approach, this approach assumes that either
the ordering above doesn't matter, or that it is the same for all drivers.
>> As an additional complication our drivers are used also by
>> the Versatile and SPEAr family of platforms, so the control
>> need to be tolerant (accept missing pinctrl handles and states)
>> as well. (I can see that other drivers take shortcuts by being less
>> elaborate since there is a 1:1 driver<->platform mapping.)
>
> Isn't the driver (or DT binding) supposed to define what pinctrl states
> must exist, and those state must always exist? There's no requirement
> for a pinctrl state definition to always actually contain content that
> changes the state. That's exactly why PIN_MAP_TYPE_DUMMY_STATE exists.
Well, it could also define that e.g. the "sleep" state is optional.
I'm sort of scared about imposing too strict usage patterns as
it may cause more problems than it solves even if the code
does look simpler.
>> An alternative to embedding the pin handling code into
>> the drivers is to use bus notifiers as is done with the
>> shmobile clocking by drivers/base/power/clock_ops.c
>> I could easily imagine pinctrl_ops.c like that for some
>> platforms. This mandates still binding the pin table entries
>> to a device but avoids adding any code to the drivers.
>>
>> However this latter approach does not work for us (Ux500) -
>> the three resources we have: clocks, pins and power domains
>> are dependent on state switch ordering (sometimes you need
>> to switch off the clock then set pin state, sometimes the
>> other way around) and it is not even
>> the same for all drivers - the notifier approach mandates
>> that all drivers do the clock, power domain and pin handling
>> uniformly.
>
> That certainly does imply that individual drivers do need to handle this
> explicitly. Although I still think that only specific drivers actually
> affected by this should end up actively managing pinctrl; shouldn't
> anything that can get away with relying on system hogs do so?
I don't know. Having say regulator, clock and pin handling in the
driver itself also gives a nice encapsulated view and sense of
control when just reading that one driver.
As one developer put it he does not really like that bus notifiers
are doing things behind his back. The debugging of the
driver can become very hairy, as you trace through bus
notifiers etc to find out what is wrong with your pins/clock/voltage.
We don't have hogs, bus notifiers and the like for regulators,
and IIRC Mark disliked the idea. Basically I think it's better if
all resources are atleast handled the same way.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/5] arm: mvebu: Added SMP support for Armada XP
From: Andrew Lunn @ 2012-10-23 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50865F59.8000507@free-electrons.com>
On Tue, Oct 23, 2012 at 11:11:53AM +0200, Gregory CLEMENT wrote:
> On 10/22/2012 08:45 PM, Andrew Lunn wrote:
> > Hi Gregory
> >
> >> +void __init set_secondary_cpus_clock(void)
> >> +{
> >> + int cpu;
> >> + unsigned long rate;
> >> + struct clk *cpu_clk = NULL;
> >> + struct device_node *np = NULL;
> >> +
> >> + cpu = smp_processor_id();
> >> + np = of_find_node_by_type(np, "cpu");
> >> + np = NULL;
> >> + while ((np = of_find_node_by_type(np, "cpu"))) {
> >> + const u32 *reg;
> >> + int len;
> >> + reg = of_get_property(np, "reg", &len);
> >> + if (!reg || len != 4) {
> >> + pr_err("%s missing reg property\n", np->full_name);
> >> + continue;
> >> + }
> >> + if (be32_to_cpup(reg) == cpu) {
> >> + cpu_clk = of_clk_get(np, 0);
> >> + break;
> >> + }
> >> + }
> >> + WARN_ON(IS_ERR(cpu_clk));
> >> + rate = clk_get_rate(cpu_clk);
> >> +
> >> + /* set all the other CPU clk to the same rate than the boot CPU */
> >> + np = NULL;
> >> + while ((np = of_find_node_by_type(np, "cpu"))) {
> >> + const u32 *reg;
> >> + int len;
> >> + reg = of_get_property(np, "reg", &len);
> >> + if (!reg || len != 4) {
> >> + pr_err("%s missing reg property\n", np->full_name);
> >> + continue;
> >> + }
> >> + if (be32_to_cpup(reg) != cpu) {
> >> + cpu_clk = of_clk_get(np, 0);
> >> + clk_set_rate(cpu_clk, rate);
> >> + }
> >
> > Maybe its hiding somewhere, but where is the clk_prepare_enable() for
> > this cpu_clk clock?
> >
>
> Well the clocks are always enable. In the clock framework, the cpu clocks
> don't provide an enable function.
Is it possible in the hardware to disable them? Turning them off might
save some power. If these chips end up in some data center server, it
might be that CPU hotplugging is used.
> But maybe it is cleaner to call clk_prepare_enable() even if it does
> nothing except update the usage count.
You also have to watch out for the late_initcall which will disable
all clocks which are running but nobody has claimed. This will become
an issue if you do have enable/disable function in later versions of
the clock functions.
Andrew
^ permalink raw reply
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Linus Walleij @ 2012-10-23 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085ACCD.3040203@wwwdotorg.org>
On Mon, Oct 22, 2012 at 10:30 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/22/2012 02:21 AM, Linus Walleij wrote:
>> If this turns out to be a severe performance bottleneck, I
>> suggest to add some additional constraint API, like
>> pinctrl_set_pinmux_homegeneous_pinsets(true) that will
>> at runtime select whether the pin allocation is done when
>> getting the pinctrl handle instead.
>
> That API sounds like something system-wide, which seems like it would be
> rather presumptuous (CPU/SoC support code couldn't execute it, since
> that would presume a facet of all board designs that could change in the
> future). Even a driver shouldn't be assuming this; it can't know what
> boards it gets used in ahead of time.
Well, yeah. It should rather be part of the pinctrl descriptor
then, so it becomes a per-controller runpath simplification.
> Instead, it seems like the map registration code could easily look at
> all states defined for a device, and determine if the set of pins/groups
> used by those states was identical, and switch between up-front or
> dynamic registration as needed by the specific map entries.
That kind of constraint-resolution in the kernel scares me,
soon we will have a prolog runtime ... (but hm maybe that is not
such a bad idea considering some other constraint things I've
seen around)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Russell King - ARM Linux @ 2012-10-23 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023092247.GA13220@avionic-0098.mockup.avionic-design.de>
On Tue, Oct 23, 2012 at 11:22:47AM +0200, Thierry Reding wrote:
> On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> > Further to the discussion, my preference is still for of_clk_get()
> > (although I've changed the patch anyway as you saw because it makes no
> > difference in this case) :)
> >
> > clk_get(x, NULL) and devm_clk_get(x, NULL) both seems like 'hacks' to
> > allow platforms to convert to DT without having to update all their
> > drivers first. It only allows the first (default) clock, as your pointed
> > out. Getting a 2nd... clock relies on an optional property in DT (which
> > again, seems like it is there to support 'old' drivers) which allows you
> > to request clocks by name.
> >
> > of_clk_get() on the other hand seems like a properly native DT function.
> > You don't need to know anything about the clock, as long as the correct
> > clock is specified in the correct order as documented by the binding.
> > Relying on 'pre-OF' code for a OF-only driver also seems
> > counter-intuitive.
>
> I do agree with those arguments. What I was saying is that for drivers
> which aren't DT only, of_clk_get() is not an option and that maybe
> others would be encouraged by the example to not use the generic APIs
> even if their driver could be used in non-DT setups. But maybe I'm
> worrying needlessly.
>
> That said, maybe somebody with a broader view of things like Arnd
> (Cc'ed) could share his thoughts.
As I have already said, the way the DT bindings were done for the clk
stuff was wrong. A little thought put into it would've come up with
a much better solution which wouldn't have needed of_clk_get() at all.
How?
The arguments for clk_get() are:
1. the struct device, which you can get the OF-node from.
2. a _device_ _specific_ _clock_ _input_ _name_ (or NULL if there's only
one.)
So, we have something that defines a hardware clock input name, which
can be used to generate a property name for OF. So, what _could_ have
been done is this:
clock-<input-name> = <&provider-node clk-output-index>;
where the property name is generated by:
snprintf(prop, sizeof(prop), "clk-%s", name ? name : "default");
So I continue to assert that our current design is wrong - and it will
cause driver authors to pointlessly have to make a choice at every stage
between DT and non-DT based systems.
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Benoit Cousson @ 2012-10-23 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaQ1WfRWrx=RXMVkeFtwdERJsOpVa3DaXBTU2KZdgqhRQ@mail.gmail.com>
Hi Linus,
On 10/23/2012 11:13 AM, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>> Hi Sourav,
>>
>> On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
>>> Adapt keypad to use pinctrl framework.
>>>
>>> Tested on omap4430 sdp with 3.7-rc1 kernel.
>>
>> I do not see anything in the driver that would directly use pinctrl. Is
>> there a better place to select default pin configuration; maybe when
>> instantiating platform device?
>
> The option is to use pinctrl hogs. Then the pins will be taken,
> muxed and configured by the pin controller itself.
>
> Another option (not implemented) is to use bus notifiers.
>
> (I wrote about this in some other thread but can't find it now.)
>
> Each approach above come with its own set of problems.
>
> If the driver need to handle multiple states like default/idle/sleep
> it is IMO better to put the handling into the driver, so if that
> is what is going to happen also to this driver it could be a good
> idea to actually implement that code upfront and include in
> this submission so as to show that this driver is really going
> to exercise its pins.
>
> But it's also a question of conformity: if other drivers in the
> system is using different states and this is the only one
> using a single "default" state, then it doesn't make sense
> to have just one driver get its pins using hogs, it's just
> inconsistent.
>
> So Sourav, please tell us a bit about your plans for this
> and other drivers!
Yeah, this idea is to handle pinctrl from all the drivers, and
potentially change the mode during suspend when it is relevant.
Regards,
Benoit
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Mark Brown @ 2012-10-23 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY-XyagxGU_ya_FZirzbqStTirOC5nuBBwwFY3f4bBTYA@mail.gmail.com>
On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
> I thought about that, but it does not allow us to control the
> resource activation/deactivation order.
> In some drivers the suspend() path could be:
> - pins to sleep
> - clk_disable
> - disable external regulator
> - release power domain
> In others:
> - clk_disable()
> - disable external regulator
> - pins to sleep()
> - release power domain
> Ulf Hansson ran into this a while back.
> Just like with the notifier approach, this approach assumes that either
> the ordering above doesn't matter, or that it is the same for all drivers.
Can we handle this with power domains - if different devices require
different orderings they can be placed in power domains which implement
the appropriate orderings for them?
> We don't have hogs, bus notifiers and the like for regulators,
> and IIRC Mark disliked the idea. Basically I think it's better if
> all resources are atleast handled the same way.
It'd be OK to have something that was manually activated for specific
regulators but it's not sane to try and do something generic as you'll
end up powering off all your wakeup sources which tends not to work so
well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/18171929/attachment.sig>
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Gregory CLEMENT @ 2012-10-23 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023090154.GP21164@n2100.arm.linux.org.uk>
On 10/23/2012 11:01 AM, Russell King - ARM Linux wrote:
> On Thu, Sep 27, 2012 at 11:35:23AM +0200, Gregory CLEMENT wrote:
>> Aurora Cache Controller was designed to be compatible with the ARM L2
>> Cache Controller. It comes with some difference or improvement such
>> as:
>> - no cache id part number available through hardware (need to get it
>> by the DT).
>> - always write through mode available.
>> - two flavors of the controller outer cache and system cache (meaning
>> maintenance operations on L1 are broadcasted to the L2 and L2
>> performs the same operation).
>> - in outer cache mode, the cache maintenance operations are improved and
>> can be done on a range inside a page and are not limited to a cache
>> line.
>
> This adds new build warnings:
>
> arch/arm/mm/cache-l2x0.c:328:13: warning: 'aurora_inv_range' defined but not used
> arch/arm/mm/cache-l2x0.c:347:13: warning: 'aurora_clean_range' defined but not used
> arch/arm/mm/cache-l2x0.c:365:13: warning: 'aurora_flush_range' defined but not used
>
> to the realview build (non-DT). Please investigate, thanks.
OK I found the problem: aurora cache support is new so it is only
enable with device tree support. I moved all this functions in the
under OF_CONFIG (see the patch below). Do you want I submit it on the
patch system, or can you get it directly from this email?
Regards,
Gregory
---
diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 5f2c7b4..3b2c40b 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -102,6 +102,10 @@
#define L2X0_ADDR_FILTER_EN 1
+#define L2X0_CTRL_EN 1
+
+#define L2X0_WAY_SIZE_SHIFT 3
+
#ifndef __ASSEMBLY__
extern void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask);
#if defined(CONFIG_CACHE_L2X0) && defined(CONFIG_OF)
diff --git a/arch/arm/mm/cache-aurora-l2.h b/arch/arm/mm/cache-aurora-l2.h
new file mode 100644
index 0000000..c861247
--- /dev/null
+++ b/arch/arm/mm/cache-aurora-l2.h
@@ -0,0 +1,55 @@
+/*
+ * AURORA shared L2 cache controller support
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Yehuda Yitschak <yehuday@marvell.com>
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __ASM_ARM_HARDWARE_AURORA_L2_H
+#define __ASM_ARM_HARDWARE_AURORA_L2_H
+
+#define AURORA_SYNC_REG 0x700
+#define AURORA_RANGE_BASE_ADDR_REG 0x720
+#define AURORA_FLUSH_PHY_ADDR_REG 0x7f0
+#define AURORA_INVAL_RANGE_REG 0x774
+#define AURORA_CLEAN_RANGE_REG 0x7b4
+#define AURORA_FLUSH_RANGE_REG 0x7f4
+
+#define AURORA_ACR_REPLACEMENT_OFFSET 27
+#define AURORA_ACR_REPLACEMENT_MASK \
+ (0x3 << AURORA_ACR_REPLACEMENT_OFFSET)
+#define AURORA_ACR_REPLACEMENT_TYPE_WAYRR \
+ (0 << AURORA_ACR_REPLACEMENT_OFFSET)
+#define AURORA_ACR_REPLACEMENT_TYPE_LFSR \
+ (1 << AURORA_ACR_REPLACEMENT_OFFSET)
+#define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
+ (3 << AURORA_ACR_REPLACEMENT_OFFSET)
+
+#define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET 0
+#define AURORA_ACR_FORCE_WRITE_POLICY_MASK \
+ (0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
+#define AURORA_ACR_FORCE_WRITE_POLICY_DIS \
+ (0 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
+#define AURORA_ACR_FORCE_WRITE_BACK_POLICY \
+ (1 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
+#define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
+ (2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
+
+#define MAX_RANGE_SIZE 1024
+
+#define AURORA_WAY_SIZE_SHIFT 2
+
+#define AURORA_CTRL_FW 0x100
+
+/* chose a number outside L2X0_CACHE_ID_PART_MASK to be sure to make
+ * the distinction between a number coming from hardware and a number
+ * coming from the device tree */
+#define AURORA_CACHE_ID 0x100
+
+#endif /* __ASM_ARM_HARDWARE_AURORA_L2_H */
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 5e82433..1bc1920 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -25,6 +25,7 @@
#include <asm/cacheflush.h>
#include <asm/hardware/cache-l2x0.h>
+#include "cache-aurora-l2.h"
#define CACHE_LINE_SIZE 32
@@ -33,6 +34,11 @@ static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
static unsigned long sync_reg_offset = L2X0_CACHE_SYNC;
+static int l2_wt_override;
+
+/* Aurora don't have the cache ID register available, so we have to
+ * pass it though the device tree */
+static u32 cache_id_part_number_from_dt;
struct l2x0_regs l2x0_saved_regs;
@@ -169,7 +175,7 @@ static void l2x0_inv_all(void)
/* invalidate all ways */
raw_spin_lock_irqsave(&l2x0_lock, flags);
/* Invalidating when L2 is enabled is a nono */
- BUG_ON(readl(l2x0_base + L2X0_CTRL) & 1);
+ BUG_ON(readl(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_INV_WAY);
cache_wait_way(l2x0_base + L2X0_INV_WAY, l2x0_way_mask);
cache_sync();
@@ -293,11 +299,18 @@ static void l2x0_unlock(u32 cache_id)
int lockregs;
int i;
- if (cache_id == L2X0_CACHE_ID_PART_L310)
+ switch (cache_id) {
+ case L2X0_CACHE_ID_PART_L310:
lockregs = 8;
- else
+ break;
+ case AURORA_CACHE_ID:
+ lockregs = 4;
+ break;
+ default:
/* L210 and unknown types */
lockregs = 1;
+ break;
+ }
for (i = 0; i < lockregs; i++) {
writel_relaxed(0x0, l2x0_base + L2X0_LOCKDOWN_WAY_D_BASE +
@@ -313,18 +326,22 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
u32 cache_id;
u32 way_size = 0;
int ways;
+ int way_size_shift = L2X0_WAY_SIZE_SHIFT;
const char *type;
l2x0_base = base;
-
- cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
+ if (cache_id_part_number_from_dt)
+ cache_id = cache_id_part_number_from_dt;
+ else
+ cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID)
+ & L2X0_CACHE_ID_PART_MASK;
aux = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
aux &= aux_mask;
aux |= aux_val;
/* Determine the number of ways */
- switch (cache_id & L2X0_CACHE_ID_PART_MASK) {
+ switch (cache_id) {
case L2X0_CACHE_ID_PART_L310:
if (aux & (1 << 16))
ways = 16;
@@ -341,6 +358,14 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
ways = (aux >> 13) & 0xf;
type = "L210";
break;
+
+ case AURORA_CACHE_ID:
+ sync_reg_offset = AURORA_SYNC_REG;
+ ways = (aux >> 13) & 0xf;
+ ways = 2 << ((ways + 1) >> 2);
+ way_size_shift = AURORA_WAY_SIZE_SHIFT;
+ type = "Aurora";
+ break;
default:
/* Assume unknown chips have 8 ways */
ways = 8;
@@ -354,7 +379,8 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
* L2 cache Size = Way size * Number of ways
*/
way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
- way_size = 1 << (way_size + 3);
+ way_size = 1 << (way_size + way_size_shift);
+
l2x0_size = ways * way_size * SZ_1K;
/*
@@ -362,7 +388,7 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
* If you are booting from non-secure mode
* accessing the below registers will fault.
*/
- if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
/* Make sure that I&D is not locked down when starting */
l2x0_unlock(cache_id);
@@ -372,7 +398,7 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
l2x0_inv_all();
/* enable L2X0 */
- writel_relaxed(1, l2x0_base + L2X0_CTRL);
+ writel_relaxed(L2X0_CTRL_EN, l2x0_base + L2X0_CTRL);
}
/* Re-read it in case some bits are reserved. */
@@ -397,6 +423,98 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
}
#ifdef CONFIG_OF
+/*
+ * Note that the end addresses passed to Linux primitives are
+ * noninclusive, while the hardware cache range operations use
+ * inclusive start and end addresses.
+ */
+static unsigned long calc_range_end(unsigned long start, unsigned long end)
+{
+ /*
+ * Limit the number of cache lines processed@once,
+ * since cache range operations stall the CPU pipeline
+ * until completion.
+ */
+ if (end > start + MAX_RANGE_SIZE)
+ end = start + MAX_RANGE_SIZE;
+
+ /*
+ * Cache range operations can't straddle a page boundary.
+ */
+ if (end > PAGE_ALIGN(start+1))
+ end = PAGE_ALIGN(start+1);
+
+ return end;
+}
+
+/*
+ * Make sure 'start' and 'end' reference the same page, as L2 is PIPT
+ * and range operations only do a TLB lookup on the start address.
+ */
+static void aurora_pa_range(unsigned long start, unsigned long end,
+ unsigned long offset)
+{
+ unsigned long flags;
+
+ raw_spin_lock_irqsave(&l2x0_lock, flags);
+ writel(start, l2x0_base + AURORA_RANGE_BASE_ADDR_REG);
+ writel(end, l2x0_base + offset);
+ raw_spin_unlock_irqrestore(&l2x0_lock, flags);
+
+ cache_sync();
+}
+
+static void aurora_inv_range(unsigned long start, unsigned long end)
+{
+ /*
+ * round start and end adresses up to cache line size
+ */
+ start &= ~(CACHE_LINE_SIZE - 1);
+ end = ALIGN(end, CACHE_LINE_SIZE);
+
+ /*
+ * Invalidate all full cache lines between 'start' and 'end'.
+ */
+ while (start < end) {
+ unsigned long range_end = calc_range_end(start, end);
+ aurora_pa_range(start, range_end - CACHE_LINE_SIZE,
+ AURORA_INVAL_RANGE_REG);
+ start = range_end;
+ }
+}
+
+static void aurora_clean_range(unsigned long start, unsigned long end)
+{
+ /*
+ * If L2 is forced to WT, the L2 will always be clean and we
+ * don't need to do anything here.
+ */
+ if (!l2_wt_override) {
+ start &= ~(CACHE_LINE_SIZE - 1);
+ end = ALIGN(end, CACHE_LINE_SIZE);
+ while (start != end) {
+ unsigned long range_end = calc_range_end(start, end);
+ aurora_pa_range(start, range_end - CACHE_LINE_SIZE,
+ AURORA_CLEAN_RANGE_REG);
+ start = range_end;
+ }
+ }
+}
+
+static void aurora_flush_range(unsigned long start, unsigned long end)
+{
+ if (!l2_wt_override) {
+ start &= ~(CACHE_LINE_SIZE - 1);
+ end = ALIGN(end, CACHE_LINE_SIZE);
+ while (start != end) {
+ unsigned long range_end = calc_range_end(start, end);
+ aurora_pa_range(start, range_end - CACHE_LINE_SIZE,
+ AURORA_FLUSH_RANGE_REG);
+ start = range_end;
+ }
+ }
+}
+
static void __init l2x0_of_setup(const struct device_node *np,
u32 *aux_val, u32 *aux_mask)
{
@@ -494,9 +612,15 @@ static void __init pl310_save(void)
}
}
+static void aurora_save(void)
+{
+ l2x0_saved_regs.ctrl = readl_relaxed(l2x0_base + L2X0_CTRL);
+ l2x0_saved_regs.aux_ctrl = readl_relaxed(l2x0_base + L2X0_AUX_CTRL);
+}
+
static void l2x0_resume(void)
{
- if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
/* restore aux ctrl and enable l2 */
l2x0_unlock(readl_relaxed(l2x0_base + L2X0_CACHE_ID));
@@ -505,7 +629,7 @@ static void l2x0_resume(void)
l2x0_inv_all();
- writel_relaxed(1, l2x0_base + L2X0_CTRL);
+ writel_relaxed(L2X0_CTRL_EN, l2x0_base + L2X0_CTRL);
}
}
@@ -513,7 +637,7 @@ static void pl310_resume(void)
{
u32 l2x0_revision;
- if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
/* restore pl310 setup */
writel_relaxed(l2x0_saved_regs.tag_latency,
l2x0_base + L2X0_TAG_LATENCY_CTRL);
@@ -539,6 +663,46 @@ static void pl310_resume(void)
l2x0_resume();
}
+static void aurora_resume(void)
+{
+ if (!(readl(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
+ writel(l2x0_saved_regs.aux_ctrl, l2x0_base + L2X0_AUX_CTRL);
+ writel(l2x0_saved_regs.ctrl, l2x0_base + L2X0_CTRL);
+ }
+}
+
+static void __init aurora_broadcast_l2_commands(void)
+{
+ __u32 u;
+ /* Enable Broadcasting of cache commands to L2*/
+ __asm__ __volatile__("mrc p15, 1, %0, c15, c2, 0" : "=r"(u));
+ u |= AURORA_CTRL_FW; /* Set the FW bit */
+ __asm__ __volatile__("mcr p15, 1, %0, c15, c2, 0\n" : : "r"(u));
+ isb();
+}
+
+static void __init aurora_of_setup(const struct device_node *np,
+ u32 *aux_val, u32 *aux_mask)
+{
+ u32 val = AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU;
+ u32 mask = AURORA_ACR_REPLACEMENT_MASK;
+
+ of_property_read_u32(np, "cache-id-part",
+ &cache_id_part_number_from_dt);
+
+ /* Determine and save the write policy */
+ l2_wt_override = of_property_read_bool(np, "wt-override");
+
+ if (l2_wt_override) {
+ val |= AURORA_ACR_FORCE_WRITE_THRO_POLICY;
+ mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
+ }
+
+ *aux_val &= ~mask;
+ *aux_val |= val;
+ *aux_mask &= ~mask;
+}
+
static const struct l2x0_of_data pl310_data = {
.setup = pl310_of_setup,
.save = pl310_save,
@@ -570,10 +734,37 @@ static const struct l2x0_of_data l2x0_data = {
},
};
+static const struct l2x0_of_data aurora_with_outer_data = {
+ .setup = aurora_of_setup,
+ .save = aurora_save,
+ .outer_cache = {
+ .resume = aurora_resume,
+ .inv_range = aurora_inv_range,
+ .clean_range = aurora_clean_range,
+ .flush_range = aurora_flush_range,
+ .sync = l2x0_cache_sync,
+ .flush_all = l2x0_flush_all,
+ .inv_all = l2x0_inv_all,
+ .disable = l2x0_disable,
+ },
+};
+
+static const struct l2x0_of_data aurora_no_outer_data = {
+ .setup = aurora_of_setup,
+ .save = aurora_save,
+ .outer_cache = {
+ .resume = aurora_resume,
+ },
+};
+
static const struct of_device_id l2x0_ids[] __initconst = {
{ .compatible = "arm,pl310-cache", .data = (void *)&pl310_data },
{ .compatible = "arm,l220-cache", .data = (void *)&l2x0_data },
{ .compatible = "arm,l210-cache", .data = (void *)&l2x0_data },
+ { .compatible = "marvell,aurora-system-cache",
+ .data = (void *)&aurora_no_outer_data},
+ { .compatible = "marvell,aurora-outer-cache",
+ .data = (void *)&aurora_with_outer_data},
{}
};
@@ -599,9 +790,14 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
data = of_match_node(l2x0_ids, np)->data;
/* L2 configuration can only be changed if the cache is disabled */
- if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & 1)) {
+ if (!(readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)) {
if (data->setup)
data->setup(np, &aux_val, &aux_mask);
+
+ /* For aurora cache in no outer mode select the
+ * correct mode using the coprocessor*/
+ if (data == &aurora_no_outer_data)
+ aurora_broadcast_l2_commands();
}
if (data->save)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Mark Brown @ 2012-10-23 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350307020-5910-2-git-send-email-lee.jones@linaro.org>
On Mon, Oct 15, 2012 at 02:17:00PM +0100, Lee Jones wrote:
> Here we specify all non-standard bindings which can be used when
> requesting the use of an GPIO controlled regulator from Device Tree.
>
> Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
The reason I didn't get this patch is that you didn't CC me on it...
notice what you've done above.
^ permalink raw reply
* [PATCH] pinctrl/nomadik: pass DT node to the irqdomain
From: Linus Walleij @ 2012-10-23 9:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
When creating the simple irqdomain, pass the DT node pointer along,
as is apropriate.
Cc: Lee Jones <lee.jones@linaro.org>
Reported-by: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 8bfbad6..cf82d9c 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1387,7 +1387,7 @@ static int __devinit nmk_gpio_probe(struct platform_device *dev)
if (!np)
irq_start = NOMADIK_GPIO_TO_IRQ(pdata->first_gpio);
- nmk_chip->domain = irq_domain_add_simple(NULL,
+ nmk_chip->domain = irq_domain_add_simple(np,
NMK_GPIO_PER_CHIP, irq_start,
&nmk_gpio_irq_simple_ops, nmk_chip);
if (!nmk_chip->domain) {
--
1.7.11.3
^ permalink raw reply related
* [PATCH] clk: Make the generic clock API available by default
From: Mark Brown @ 2012-10-23 9:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50856CC6.7010403@wwwdotorg.org>
On Mon, Oct 22, 2012 at 09:56:54AM -0600, Stephen Warren wrote:
> Since v3.7-rc1, Tegra uses common clock, so I don't think the change
> above is right is it?
No, updated. It really shouldn't take multiple kernel releases to get
something like this done...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/51d93a8f/attachment.sig>
^ permalink raw reply
* [PATCH RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Sergei Shtylyov @ 2012-10-23 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350907972-11256-1-git-send-email-prabhakar.lad@ti.com>
Hello.
On 22-10-2012 16:12, Prabhakar Lad wrote:
> From: Lad, Prabhakar <prabhakar.lad@ti.com>
> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
> out.
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Cc: Sekhar Nori <nsekhar@ti.com>
> ---
> Resending the patch since, it didn't reach the DLOS mailing list.
> This patch is based on the following patch series,
> ARM: davinci: dm365 EVM: add support for VPBE display
> (https://patchwork.kernel.org/patch/1295071/)
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
> index 2924d61..771abb5 100644
> --- a/arch/arm/mach-davinci/board-dm365-evm.c
> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
> @@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
> .index = 1,
> .name = "Component",
> .type = V4L2_OUTPUT_TYPE_ANALOG,
> - .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
> + .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
Why this extra space after '='?
WBR, Sergei
^ permalink raw reply
* [PATCH] clk: Make the generic clock API available by default
From: Mark Brown @ 2012-10-23 9:54 UTC (permalink / raw)
To: linux-arm-kernel
Rather than requiring platforms to select the generic clock API to make
it available make the API available as a user selectable option unless the
user either selects HAVE_CUSTOM_CLK (if they have their own implementation)
or selects COMMON_CLK (if they depend on the generic implementation).
All current architectures that HAVE_CLK but don't use the common clock
framework have selects of HAVE_CUSTOM_CLK added.
This allows drivers to use the generic API on platforms which have no need
for the clock API at platform level.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/Kconfig | 12 ++++++++++++
arch/avr32/Kconfig | 1 +
arch/mips/Kconfig | 4 ++++
arch/mips/loongson/Kconfig | 1 +
arch/mips/txx9/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/unicore32/Kconfig | 1 +
drivers/clk/Kconfig | 13 ++++++++++---
8 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe90e60..ec7baca 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -314,6 +314,7 @@ config ARCH_VERSATILE
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select HAVE_MACH_CLKDEV
+ select HAVE_CUSTOM_CLK
select ICST
select PLAT_VERSATILE
select PLAT_VERSATILE_CLCD
@@ -327,6 +328,7 @@ config ARCH_AT91
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select IRQ_DOMAIN
select NEED_MACH_GPIO_H
select NEED_MACH_IO_H if PCCARD
@@ -666,6 +668,7 @@ config ARCH_MSM
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
help
Support for Qualcomm MSM/QSD based systems. This runs on the
apps processor of the MSM/QSD and depends on a shared memory
@@ -678,6 +681,7 @@ config ARCH_SHMOBILE
select CLKDEV_LOOKUP
select GENERIC_CLOCKEVENTS
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_MACH_CLKDEV
select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
@@ -728,10 +732,12 @@ config ARCH_SA1100
config ARCH_S3C24XX
bool "Samsung S3C24XX SoCs"
select ARCH_HAS_CPUFREQ
+ select CLKDEV_LOOKUP
select ARCH_USES_GETTIMEOFFSET
select CLKDEV_LOOKUP
select GENERIC_GPIO
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
@@ -752,6 +758,7 @@ config ARCH_S3C64XX
select CLKDEV_LOOKUP
select CPU_V6
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_TCM
@@ -775,6 +782,7 @@ config ARCH_S5P64X0
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
@@ -790,6 +798,7 @@ config ARCH_S5PC100
select CPU_V7
select GENERIC_GPIO
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
@@ -808,6 +817,7 @@ config ARCH_S5PV210
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
@@ -826,6 +836,7 @@ config ARCH_EXYNOS
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select HAVE_S3C_RTC if RTC_CLASS
@@ -928,6 +939,7 @@ config ARCH_OMAP
select CLKSRC_MMIO
select GENERIC_CLOCKEVENTS
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select NEED_MACH_GPIO_H
help
Support for TI's OMAP platform (OMAP1/2/3/4).
diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig
index 06e73bf..bfeb9cc 100644
--- a/arch/avr32/Kconfig
+++ b/arch/avr32/Kconfig
@@ -4,6 +4,7 @@ config AVR32
# that we usually don't need on AVR32.
select EXPERT
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_GENERIC_HARDIRQS
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ce6c9a6..e0be02f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -85,6 +85,7 @@ config AR7
select ARCH_REQUIRE_GPIOLIB
select VLYNQ
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
help
Support for the Texas Instruments AR7 System-on-a-Chip
family: TNETD7100, 7200 and 7300.
@@ -97,6 +98,7 @@ config ATH79
select CSRC_R4K
select DMA_NONCOHERENT
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select IRQ_CPU
select MIPS_MACHINE
select SYS_HAS_CPU_MIPS32_R2
@@ -134,6 +136,7 @@ config BCM63XX
select SWAP_IO_SPACE
select ARCH_REQUIRE_GPIOLIB
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
help
Support for BCM63XX based boards
@@ -229,6 +232,7 @@ config MACH_JZ4740
select SYS_HAS_EARLY_PRINTK
select HAVE_PWM
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select GENERIC_IRQ_CHIP
config LANTIQ
diff --git a/arch/mips/loongson/Kconfig b/arch/mips/loongson/Kconfig
index 263beb9..ed42be1 100644
--- a/arch/mips/loongson/Kconfig
+++ b/arch/mips/loongson/Kconfig
@@ -42,6 +42,7 @@ config LEMOTE_MACH2F
select DMA_NONCOHERENT
select GENERIC_ISA_DMA_SUPPORT_BROKEN
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select HW_HAS_PCI
select I8259
select IRQ_CPU
diff --git a/arch/mips/txx9/Kconfig b/arch/mips/txx9/Kconfig
index 6d40bc7..04e3cdb 100644
--- a/arch/mips/txx9/Kconfig
+++ b/arch/mips/txx9/Kconfig
@@ -21,6 +21,7 @@ config MACH_TXX9
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_BIG_ENDIAN
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
config TOSHIBA_JMR3927
bool "Toshiba JMR-TX3927 board"
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5af5aa7..da4ea6c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1028,6 +1028,7 @@ config PPC_CLOCK
bool
default n
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
config PPC_LIB_RHEAP
bool
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index fda37c9..8247d69 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -89,6 +89,7 @@ config ARCH_PUV3
select CPU_UCV2
select GENERIC_CLOCKEVENTS
select HAVE_CLK
+ select HAVE_CUSTOM_CLK
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index bace9e9..8dc8391 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -9,16 +9,23 @@ config HAVE_CLK_PREPARE
config HAVE_MACH_CLKDEV
bool
-config COMMON_CLK
+config HAVE_CUSTOM_CLK
bool
+ ---help---
+ Architectures which provide a custom clk API should select
+ this to disable the common clock API.
+
+config COMMON_CLK
+ bool "Common clock framework"
+ depends on !HAVE_CUSTOM_CLK
select HAVE_CLK_PREPARE
select CLKDEV_LOOKUP
---help---
The common clock framework is a single definition of struct
clk, useful across many platforms, as well as an
implementation of the clock API in include/linux/clk.h.
- Architectures utilizing the common struct clk should select
- this option.
+ This provides a generic way for drivers to provide and use
+ clocks without hard coded relationships in the drivers.
menu "Common Clock Framework"
depends on COMMON_CLK
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Lee Jones @ 2012-10-23 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023094536.GA6576@sirena.org.uk>
On Tue, 23 Oct 2012, Mark Brown wrote:
> On Mon, Oct 15, 2012 at 02:17:00PM +0100, Lee Jones wrote:
> > Here we specify all non-standard bindings which can be used when
> > requesting the use of an GPIO controlled regulator from Device Tree.
> >
> > Mark Brown <broonie@opensource.wolfsonmicro.com>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> The reason I didn't get this patch is that you didn't CC me on it...
> notice what you've done above.
Yes, I saw it and corrected it in the end, hence why you received
it when I resent - my bad.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-23 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023093128.GR21164@n2100.arm.linux.org.uk>
On Tue, Oct 23, 2012 at 10:31:28AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 23, 2012 at 11:22:47AM +0200, Thierry Reding wrote:
> > On Tue, Oct 23, 2012 at 09:41:46PM +1300, Tony Prisk wrote:
> > > Further to the discussion, my preference is still for of_clk_get()
> > > (although I've changed the patch anyway as you saw because it makes no
> > > difference in this case) :)
> > >
> > > clk_get(x, NULL) and devm_clk_get(x, NULL) both seems like 'hacks' to
> > > allow platforms to convert to DT without having to update all their
> > > drivers first. It only allows the first (default) clock, as your pointed
> > > out. Getting a 2nd... clock relies on an optional property in DT (which
> > > again, seems like it is there to support 'old' drivers) which allows you
> > > to request clocks by name.
> > >
> > > of_clk_get() on the other hand seems like a properly native DT function.
> > > You don't need to know anything about the clock, as long as the correct
> > > clock is specified in the correct order as documented by the binding.
> > > Relying on 'pre-OF' code for a OF-only driver also seems
> > > counter-intuitive.
> >
> > I do agree with those arguments. What I was saying is that for drivers
> > which aren't DT only, of_clk_get() is not an option and that maybe
> > others would be encouraged by the example to not use the generic APIs
> > even if their driver could be used in non-DT setups. But maybe I'm
> > worrying needlessly.
> >
> > That said, maybe somebody with a broader view of things like Arnd
> > (Cc'ed) could share his thoughts.
>
> As I have already said, the way the DT bindings were done for the clk
> stuff was wrong. A little thought put into it would've come up with
> a much better solution which wouldn't have needed of_clk_get() at all.
>
> How?
>
> The arguments for clk_get() are:
> 1. the struct device, which you can get the OF-node from.
> 2. a _device_ _specific_ _clock_ _input_ _name_ (or NULL if there's only
> one.)
>
> So, we have something that defines a hardware clock input name, which
> can be used to generate a property name for OF. So, what _could_ have
> been done is this:
>
> clock-<input-name> = <&provider-node clk-output-index>;
>
> where the property name is generated by:
>
> snprintf(prop, sizeof(prop), "clk-%s", name ? name : "default");
But we already have this, only with slightly different syntax:
clocks = <&provider foo-index>, <&provider bar-index>;
clock-names = "foo", "bar";
> So I continue to assert that our current design is wrong - and it will
> cause driver authors to pointlessly have to make a choice at every stage
> between DT and non-DT based systems.
I think the reason that Tony brought this up is that with this API, the
clock-names property becomes mandatory if you have more than one input
clock.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/49c2972a/attachment-0001.sig>
^ permalink raw reply
* [PATCH RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS
From: Prabhakar Lad @ 2012-10-23 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508667E3.4000509@mvista.com>
Hi Sergei,
On Tue, Oct 23, 2012 at 3:18 PM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
>
>
> On 22-10-2012 16:12, Prabhakar Lad wrote:
>
>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>
>
>> This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with
>> V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased
>> out.
>
>
>> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
>> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> ---
>> Resending the patch since, it didn't reach the DLOS mailing list.
>
>
>> This patch is based on the following patch series,
>> ARM: davinci: dm365 EVM: add support for VPBE display
>> (https://patchwork.kernel.org/patch/1295071/)
>
>
>> arch/arm/mach-davinci/board-dm365-evm.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
>> b/arch/arm/mach-davinci/board-dm365-evm.c
>> index 2924d61..771abb5 100644
>> --- a/arch/arm/mach-davinci/board-dm365-evm.c
>> +++ b/arch/arm/mach-davinci/board-dm365-evm.c
>> @@ -514,7 +514,7 @@ static struct vpbe_output dm365evm_vpbe_outputs[] = {
>> .index = 1,
>> .name = "Component",
>> .type = V4L2_OUTPUT_TYPE_ANALOG,
>> - .capabilities = V4L2_OUT_CAP_CUSTOM_TIMINGS,
>> + .capabilities = V4L2_OUT_CAP_DV_TIMINGS,
>
>
> Why this extra space after '='?
>
My Bad, I'll post a v2 fixing it.
Regards,
--Prabhakar
> WBR, Sergei
>
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Linus Walleij @ 2012-10-23 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023093711.GS4477@opensource.wolfsonmicro.com>
On Tue, Oct 23, 2012 at 11:37 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Oct 23, 2012 at 11:26:40AM +0200, Linus Walleij wrote:
>> I thought about that, but it does not allow us to control the
>> resource activation/deactivation order.
>
>> In some drivers the suspend() path could be:
>
>> - pins to sleep
>> - clk_disable
>> - disable external regulator
>> - release power domain
>
>> In others:
>
>> - clk_disable()
>> - disable external regulator
>> - pins to sleep()
>> - release power domain
>
>> Ulf Hansson ran into this a while back.
>
>> Just like with the notifier approach, this approach assumes that either
>> the ordering above doesn't matter, or that it is the same for all drivers.
>
> Can we handle this with power domains - if different devices require
> different orderings they can be placed in power domains which implement
> the appropriate orderings for them?
clocks, regulators, pins and all in power domains?
Then we should rename them "device resource domains" or
something...
I have a strong sense of system-wide all-or-nothing approaches
to this problem.
- Either we use "power" domains to handle every resource the
device has.
- Or the device driver manages it's own resources.
I find it pretty hard to build consensus around either idea.
The problem is that the latter approach (devices drivers themselves
take clocks, domain power, etc) is already quite widespread
in the kernel so to get the entire world consistent to the former
approach would be pretty painful I think. Especially in the case
where a device driver is used on more than one SoC.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: at91: dt: evk-pro3: enable uart0 and uart2
From: Fabio Porcedda @ 2012-10-23 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
arch/arm/boot/dts/evk-pro3.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/evk-pro3.dts b/arch/arm/boot/dts/evk-pro3.dts
index ce959ee..96e50f5 100644
--- a/arch/arm/boot/dts/evk-pro3.dts
+++ b/arch/arm/boot/dts/evk-pro3.dts
@@ -22,6 +22,14 @@
status = "okay";
};
+ usart0: serial at fffb0000 {
+ status = "okay";
+ };
+
+ usart2: serial at fffb8000 {
+ status = "okay";
+ };
+
usb1: gadget at fffa4000 {
atmel,vbus-gpio = <&pioC 5 0>;
status = "okay";
--
1.7.11.3
^ permalink raw reply related
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Russell King - ARM Linux @ 2012-10-23 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508666A6.9040701@free-electrons.com>
On Tue, Oct 23, 2012 at 11:43:02AM +0200, Gregory CLEMENT wrote:
> On 10/23/2012 11:01 AM, Russell King - ARM Linux wrote:
> > On Thu, Sep 27, 2012 at 11:35:23AM +0200, Gregory CLEMENT wrote:
> >> Aurora Cache Controller was designed to be compatible with the ARM L2
> >> Cache Controller. It comes with some difference or improvement such
> >> as:
> >> - no cache id part number available through hardware (need to get it
> >> by the DT).
> >> - always write through mode available.
> >> - two flavors of the controller outer cache and system cache (meaning
> >> maintenance operations on L1 are broadcasted to the L2 and L2
> >> performs the same operation).
> >> - in outer cache mode, the cache maintenance operations are improved and
> >> can be done on a range inside a page and are not limited to a cache
> >> line.
> >
> > This adds new build warnings:
> >
> > arch/arm/mm/cache-l2x0.c:328:13: warning: 'aurora_inv_range' defined but not used
> > arch/arm/mm/cache-l2x0.c:347:13: warning: 'aurora_clean_range' defined but not used
> > arch/arm/mm/cache-l2x0.c:365:13: warning: 'aurora_flush_range' defined but not used
> >
> > to the realview build (non-DT). Please investigate, thanks.
>
> OK I found the problem: aurora cache support is new so it is only
> enable with device tree support. I moved all this functions in the
> under OF_CONFIG (see the patch below). Do you want I submit it on the
> patch system, or can you get it directly from this email?
Easier by the patch system, and much less likely to get buried and lost
between now and when I do the update, thanks.
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-23 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbhCS-Vb0DtbTZQ_Zw_8SOh3Bqutme3Y2-QrxNqvMiNNw@mail.gmail.com>
Hi,
On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
> On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson <b-cousson@ti.com> wrote:
> > On 10/23/2012 11:13 AM, Linus Walleij wrote:
>
> >> So Sourav, please tell us a bit about your plans for this
> >> and other drivers!
> >
> > Yeah, this idea is to handle pinctrl from all the drivers, and
> > potentially change the mode during suspend when it is relevant.
>
> I'm leaning toward the same approach for ux500.
>
> But it appears that shmobile prefer to get all resources using
> bus notifiers.
>
> So we need to form some kind of consensus ... or live with
> the fact that different systems do it different ways. Which will
> explode the day we need to use a driver on two systems,
> each using the other approach :-)
I much prefer having drivers explicitly manage all their resources,
which would mean that pinctrl calls need to be done on probe() and, if
necessary, during suspend()/resume().
Using bus notifiers for that is quite a hack IMHO.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121023/339bb2ed/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-23 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508664CA.7000601@ti.com>
On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson <b-cousson@ti.com> wrote:
> On 10/23/2012 11:13 AM, Linus Walleij wrote:
>> So Sourav, please tell us a bit about your plans for this
>> and other drivers!
>
> Yeah, this idea is to handle pinctrl from all the drivers, and
> potentially change the mode during suspend when it is relevant.
I'm leaning toward the same approach for ux500.
But it appears that shmobile prefer to get all resources using
bus notifiers.
So we need to form some kind of consensus ... or live with
the fact that different systems do it different ways. Which will
explode the day we need to use a driver on two systems,
each using the other approach :-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/9] ARM: mmp: select pinctrl driver
From: Linus Walleij @ 2012-10-23 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-2-git-send-email-haojian.zhuang@gmail.com>
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> Pinctrl driver is necessary for MMP DT & MMP2 DT platforms.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 6/9] tty: pxa: configure pin
From: Linus Walleij @ 2012-10-23 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-7-git-send-email-haojian.zhuang@gmail.com>
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> Configure pins by pinctrl driver.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
So as I think the distributed approach to this is OK:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 8/9] i2c: pxa: configure pinmux
From: Linus Walleij @ 2012-10-23 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-9-git-send-email-haojian.zhuang@gmail.com>
On Mon, Oct 22, 2012 at 6:08 PM, Haojian Zhuang
<haojian.zhuang@gmail.com> wrote:
> Configure pins by pinctrl driver.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
So as I think the distributed approach to this is OK:
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox