* [PATCH] arm: mvebu: add LED support in defconfig
From: Thomas Petazzoni @ 2012-10-23 8:19 UTC (permalink / raw)
To: linux-arm-kernel
The recently added support for the PlatHome Openblocks AX3 platform
requires the LED framework, so let's add it to mvebu_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
This is 3.8 material
---
arch/arm/configs/mvebu_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 3458752..b7ca617 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -26,6 +26,11 @@ CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/4] net/macb: fix truncate warnings
From: David Laight @ 2012-10-23 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350931534-8416-2-git-send-email-manabian@gmail.com>
> When building macb on x86_64 the following warnings show up:
> drivers/net/ethernet/cadence/macb.c: In function macb_interrupt:
> drivers/net/ethernet/cadence/macb.c:556:4: warning: large integer implicitly truncated to unsigned type [-Woverflow]
...
> - macb_writel(bp, IDR, ~0UL);
> + macb_writel(bp, IDR, -1);
Seems wrong to fix an error with an unsigned value
by using -1.
David
^ permalink raw reply
* [PATCH] pinctrl/nomadik: use irq_create_mapping()
From: Linus Walleij @ 2012-10-23 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5085A7CA.3070001@wwwdotorg.org>
On Mon, Oct 22, 2012 at 10:08 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/22/2012 02:14 AM, Linus Walleij wrote:
>> It's an IRQ handler so it should be robust to spurious IRQs due to
>> transient hardware states etc I believe.
>>
>> So if there is a transient IRQ before gpio_to_irq() is called -> boom.
>
> I wonder though (a) why it would be unmasked in HW, and (b) why the
> software would even look at the status bit if no handler were registered?
That's true of course ... OK I'll update the patch.
Still I'm not feeling good about the irq_create_mapping/irq_find_mapping
separation, I think a lot of drivers just get this wrong and it's causing
bugs... it'd be way better if there was just one of them and we could
count on descriptors being allocated after adding any kind of irqdomain
but I have no clue how hard it would be to achieve this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] pinctrl/nomadik: use irq_create_mapping()
From: Linus Walleij @ 2012-10-23 8:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
Since in the DT case, the linear domain path will not allocate
descriptors for the IRQs, we need to use irq_create_mapping()
for mapping hwirqs to Linux IRQs, so these descriptors get
created on-the-fly in this case.
ChangeLog v1->v2:
- Just use irq_create_mapping() in the .to_irq function since
this is called before unmasking or enabling any interrupt
lines, so irq_find_mapping() should be sufficient for the
IRQ handler function.
Cc: Lee Jones <lee.jones@linaro.org>
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 01aea1c..db5e0b3 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -1056,7 +1056,7 @@ static int nmk_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
struct nmk_gpio_chip *nmk_chip =
container_of(chip, struct nmk_gpio_chip, chip);
- return irq_find_mapping(nmk_chip->domain, offset);
+ return irq_create_mapping(nmk_chip->domain, offset);
}
#ifdef CONFIG_DEBUG_FS
--
1.7.11.3
^ permalink raw reply related
* [PATCH v2 0/4] ARM: dts: Update OMAP5 with address space and interrupts
From: Sebastien Guiriec @ 2012-10-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space
and interrupt line description inside dtsi file for OMAP5. This serie is updating the
current OMAP5 IP with missing entry.
It has been tested on OMAP5 with 3.7-audio-display feature tree.
- MMC is probing and functional
- TWL6041 probing (GPIO/I2C)
- booting (UART)
Update since v1:
- Add Ack and review
- Fix up commit messages.
Sebastien Guiriec (4):
ARM: dts: omap5: Update GPIO with address space and interrupts
ARM: dts: omap5: Update I2C with address space and interrupts
ARM: dts: omap5: Update UART with address space and interrupts
ARM: dts: omap5: Update MMC with address space and interrupts
arch/arm/boot/dts/omap5.dtsi | 56 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 52 insertions(+), 4 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts
From: Sebastien Guiriec @ 2012-10-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981432-6750-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@
gpio1: gpio at 4ae10000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4ae10000 0x200>;
+ interrupts = <0 29 0x4>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -113,6 +115,8 @@
gpio2: gpio at 48055000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48055000 0x200>;
+ interrupts = <0 30 0x4>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -122,6 +126,8 @@
gpio3: gpio at 48057000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48057000 0x200>;
+ interrupts = <0 31 0x4>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -131,6 +137,8 @@
gpio4: gpio at 48059000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48059000 0x200>;
+ interrupts = <0 32 0x4>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -140,6 +148,8 @@
gpio5: gpio at 4805b000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805b000 0x200>;
+ interrupts = <0 33 0x4>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -149,6 +159,8 @@
gpio6: gpio at 4805d000 {
compatible = "ti,omap4-gpio";
+ reg = <0x4805d000 0x200>;
+ interrupts = <0 34 0x4>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -158,6 +170,8 @@
gpio7: gpio at 48051000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48051000 0x200>;
+ interrupts = <0 35 0x4>;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -167,6 +181,8 @@
gpio8: gpio at 48053000 {
compatible = "ti,omap4-gpio";
+ reg = <0x48053000 0x200>;
+ interrupts = <0 121 0x4>;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 2/4] ARM: dts: omap5: Update I2C with address space and interrupts
From: Sebastien Guiriec @ 2012-10-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981432-6750-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9e39f9f..6c22e1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -192,6 +192,8 @@
i2c1: i2c at 48070000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48070000 0x100>;
+ interrupts = <0 56 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -199,6 +201,8 @@
i2c2: i2c at 48072000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48072000 0x100>;
+ interrupts = <0 57 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
@@ -206,20 +210,26 @@
i2c3: i2c at 48060000 {
compatible = "ti,omap4-i2c";
+ reg = <0x48060000 0x100>;
+ interrupts = <0 61 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
};
- i2c4: i2c at 4807A000 {
+ i2c4: i2c at 4807a000 {
compatible = "ti,omap4-i2c";
+ reg = <0x4807a000 0x100>;
+ interrupts = <0 62 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
};
- i2c5: i2c at 4807C000 {
+ i2c5: i2c at 4807c000 {
compatible = "ti,omap4-i2c";
+ reg = <0x4807c000 0x100>;
+ interrupts = <0 60 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c5";
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: omap5: Update UART with address space and interrupts
From: Sebastien Guiriec @ 2012-10-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981432-6750-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413df94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -237,36 +237,48 @@
uart1: serial at 4806a000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806a000 0x100>;
+ interrupts = <0 72 0x4>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
uart2: serial at 4806c000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806c000 0x100>;
+ interrupts = <0 73 0x4>;
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
uart3: serial at 48020000 {
compatible = "ti,omap4-uart";
+ reg = <0x48020000 0x100>;
+ interrupts = <0 74 0x4>;
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
uart4: serial at 4806e000 {
compatible = "ti,omap4-uart";
+ reg = <0x4806e000 0x100>;
+ interrupts = <0 70 0x4>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
uart5: serial at 48066000 {
- compatible = "ti,omap5-uart";
+ compatible = "ti,omap4-uart";
+ reg = <0x48066000 0x100>;
+ interrupts = <0 105 0x4>;
ti,hwmods = "uart5";
clock-frequency = <48000000>;
};
uart6: serial at 48068000 {
- compatible = "ti,omap6-uart";
+ compatible = "ti,omap4-uart";
+ reg = <0x48068000 0x100>;
+ interrupts = <0 106 0x4>;
ti,hwmods = "uart6";
clock-frequency = <48000000>;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: omap5: Update MMC with address space and interrupts
From: Sebastien Guiriec @ 2012-10-23 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350981432-6750-1-git-send-email-s-guiriec@ti.com>
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 413df94..b643cd3 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -285,6 +285,8 @@
mmc1: mmc at 4809c000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x4809c000 0x400>;
+ interrupts = <0 83 0x4>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
@@ -292,24 +294,32 @@
mmc2: mmc at 480b4000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480b4000 0x400>;
+ interrupts = <0 86 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
};
mmc3: mmc at 480ad000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480ad000 0x400>;
+ interrupts = <0 94 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
};
mmc4: mmc at 480d1000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480d1000 0x400>;
+ interrupts = <0 96 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
};
mmc5: mmc at 480d5000 {
compatible = "ti,omap4-hsmmc";
+ reg = <0x480d5000 0x400>;
+ interrupts = <0 59 0x4>;
ti,hwmods = "mmc5";
ti,needs-special-reset;
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-23 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022080414.GB4931@avionic-0098.mockup.avionic-design.de>
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.
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().
Just my two cents.
Regards
Tony P
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Andrew Lunn @ 2012-10-23 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350980365-6698-1-git-send-email-thomas.petazzoni@free-electrons.com>
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 49d7915..cd2717b 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
> static const char * const armada_370_xp_dt_board_dt_compat[] = {
> "marvell,a370-db",
> "marvell,axp-db",
> + "plathome,openblocks-ax3",
> NULL,
> };
Hi Thomas
You will get less merge conflicts with new boards if you keep this
list sorted.
Andrew
^ permalink raw reply
* [PATCH] arm: mvebu: support for the PlatHome OpenBlocks AX3 board
From: Thomas Petazzoni @ 2012-10-23 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023084241.GV11837@lunn.ch>
Dear Andrew Lunn,
On Tue, 23 Oct 2012 10:42:41 +0200, Andrew Lunn wrote:
> > diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> > index 49d7915..cd2717b 100644
> > --- a/arch/arm/mach-mvebu/armada-370-xp.c
> > +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> > @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
> > static const char * const armada_370_xp_dt_board_dt_compat[] = {
> > "marvell,a370-db",
> > "marvell,axp-db",
> > + "plathome,openblocks-ax3",
> > NULL,
> > };
>
> Hi Thomas
>
> You will get less merge conflicts with new boards if you keep this
> list sorted.
Hum, right, but isn't "plathome" after "marvell" when sorted
alphabetically? Or maybe I don't get which kind of sorting you are
referring to?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/4] net/macb: fix truncate warnings
From: David Miller @ 2012-10-23 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B705B@saturn3.aculab.com>
From: "David Laight" <David.Laight@ACULAB.COM>
Date: Tue, 23 Oct 2012 09:21:11 +0100
>> When building macb on x86_64 the following warnings show up:
>> drivers/net/ethernet/cadence/macb.c: In function macb_interrupt:
>> drivers/net/ethernet/cadence/macb.c:556:4: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> ...
>> - macb_writel(bp, IDR, ~0UL);
>> + macb_writel(bp, IDR, -1);
>
> Seems wrong to fix an error with an unsigned value
> by using -1.
-1 is equally an unsigned value of all 1's and completely legitimate.
The correction being made here is one of size not signedness.
^ permalink raw reply
* i.MX28 die temperature
From: Peter Turczak @ 2012-10-23 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201206271400.11727.marex@denx.de>
Hi Marek,
hi Jonathan,
while trying to implement a battery charger driver for the mx28 platform I came across your posts. Sorry to stir up an old thread but it was running the same way.
On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
Dear Jonathan Cameron,
>
>> On 6/26/2012 8:02 PM, Marek Vasut wrote:
>>> Dear Juergen Beisert,
>>>> I tried a little bit with your driver. The disadvantage I see is, its
>>>> claims all the free AD channels. But a few of them can also act as a
>>>> touchscreen controller. Shouldn't be the driver handle the channel usage
>>>> dynamically?
>>>
>>> I wonder, I'd rather see this driver behave as a composite driver, what
>>> do you think?
>>
>> Alternative (though it's still in development) would be to use IIO
>> as the ADC layer and sit the other parts on top.
I am currently trying to go this route, the idea is to use the consumer api to get the required battery management data to the battery driver. As a foundation I used the driver provided by Freescale which uses the lradc directly which I found rather bad in the system context.
Maybe one could map all the driver muxing and use specific parameters in explicitly named iio channels? But this could lead to permanent reconfiguring of the LRADC and maybe quite difficult handling of the measurements that arrive asynchronously.
Also I don't seem to quite get the usage of iio_map_array_register() which seems to enable the consumer api access to the device. I found only one use of it in an example in
max1363.c which confused me even more. How do I correctly provide the iio_map struct? What is the consumer_dev_name used for and which "namespace" should used there, is it the name used in a platform_driver struct or the instances name (given there can only be one internal mxs battery charger at a time)?
Best regards,
Peter
^ permalink raw reply
* i.MX28 die temperature
From: Marek Vasut @ 2012-10-23 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6E339FB7-3B7F-4D90-A472-D375F36755F1@netconsequence.de>
Dear Peter Turczak,
> Hi Marek,
> hi Jonathan,
>
> while trying to implement a battery charger driver for the mx28 platform I
> came across your posts. Sorry to stir up an old thread but it was running
> the same way.
>
> On Jun 27, 2012, at 2:00 PM, Marek Vasut wrote:
> Dear Jonathan Cameron,
>
> >> On 6/26/2012 8:02 PM, Marek Vasut wrote:
> >>> Dear Juergen Beisert,
> >>>
> >>>> I tried a little bit with your driver. The disadvantage I see is, its
> >>>> claims all the free AD channels. But a few of them can also act as a
> >>>> touchscreen controller. Shouldn't be the driver handle the channel
> >>>> usage dynamically?
> >>>
> >>> I wonder, I'd rather see this driver behave as a composite driver, what
> >>> do you think?
> >>
> >> Alternative (though it's still in development) would be to use IIO
> >> as the ADC layer and sit the other parts on top.
>
> I am currently trying to go this route, the idea is to use the consumer api
> to get the required battery management data to the battery driver. As a
> foundation I used the driver provided by Freescale which uses the lradc
> directly which I found rather bad in the system context.
We have some basic LRADC driver in upstream already, you should use that.
See drivers/staging/iio/adc/mxs-lradc.c
> Maybe one could map all the driver muxing and use specific parameters in
> explicitly named iio channels? But this could lead to permanent
> reconfiguring of the LRADC and maybe quite difficult handling of the
> measurements that arrive asynchronously.
>
> Also I don't seem to quite get the usage of iio_map_array_register() which
> seems to enable the consumer api access to the device. I found only one
> use of it in an example in max1363.c which confused me even more. How do I
> correctly provide the iio_map struct? What is the consumer_dev_name used
> for and which "namespace" should used there, is it the name used in a
> platform_driver struct or the instances name (given there can only be one
> internal mxs battery charger at a time)?
>
> Best regards,
> Peter
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Linus Walleij @ 2012-10-23 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022190743.GE4730@atomide.com>
On Mon, Oct 22, 2012 at 9:07 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Linus Walleij <linus.walleij@linaro.org> [121022 01:22]:
>> 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.
>
> Or maybe you could release + reserve the pins only if the
> pins change?
Umm... not quite following but show me the code :-D
In the code as it stands currently we only detect
if a state changes and then it assumes the old state need
to be deactivated before activating a new one.
I think that in order to do that for a state A->B transition
we need to:
1. Get the pins for mux setting A
2. Get the pins for mux setting B
3. Loop over the pin array and compare
4. If all are the same, goto 7
5. Release pins for setting A
6. Acquire pins for setting B
7. Update all pin descs to point to setting B
8. Done
Hm, I can see a patch like that...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/5] clk: ux500: Add clock lookups for u8500
From: Linus Walleij @ 2012-10-23 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>
On Mon, Oct 22, 2012 at 3:57 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> Step by step, clock lookups for u8500 are being added in this set
> of patches.
>
> These patches will require additional patches for sound/soc/ux500/
> driver as well as drivers/i2c/busses/i2c-nomadik driver to prevent
> the boot for ux500 from break. Those patches are being merged through
> separate trees.
All of these look good to me.
Acked-by: Linus Walleij <linus.walleij@linaro.org> for all.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V6 3/6] arm: cache-l2x0: add support for Aurora L2 cache ctrl
From: Russell King - ARM Linux @ 2012-10-23 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348738523-28609-2-git-send-email-gregory.clement@free-electrons.com>
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.
^ permalink raw reply
* IMX breaking Versatile Express build
From: Russell King - ARM Linux @ 2012-10-23 9:08 UTC (permalink / raw)
To: linux-arm-kernel
The latest Versatile Express specific build is failing due to:
arch/arm/mach-imx/built-in.o: In function `imx_cpu_die':
platform-imx-dma.c:(.text+0x1624): undefined reference to `imx_enable_cpu'
arch/arm/mach-imx/built-in.o: In function `imx_boot_secondary':
platform-imx-dma.c:(.cpuinit.text+0x14): undefined reference to `imx_set_cpu_jump'
platform-imx-dma.c:(.cpuinit.text+0x20): undefined reference to `imx_enable_cpu'
Config:
http://www.home.arm.linux.org.uk/developer/build/file.php?type=config&idx=2464
This does not seem to have any IMX support selected.
Thanks to the reduced default configuration files, Kconfig is deciding to
select the new MULTI_* options on these target specific Kconfigs, which
may have some reason as to the above.
However, even so, we should _not_ be seeing such build failures. It looks
to me like platform-imx-dma is missing some kind of dependency.
^ permalink raw reply
* [PATCH 5/5] arm: mvebu: Added SMP support for Armada XP
From: Gregory CLEMENT @ 2012-10-23 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022184537.GN21046@lunn.ch>
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.
But maybe it is cleaner to call clk_prepare_enable() even if it does
nothing except update the usage count.
Thanks,
Gregory
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-23 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022155028.GA13791@core.coreip.homeip.net>
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!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Benoit Cousson @ 2012-10-23 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022155028.GA13791@core.coreip.homeip.net>
Hi Dimitry,
On 10/22/2012 05:50 PM, Dmitry Torokhov 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?
Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named "get_select_default" and not "get" only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.
There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.
But, maybe I'm missing your point.
Regards,
Benoit
>
> Thanks.
>
>>
>> Cc: Felipe Balbi <balbi@ti.com>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>> ---
>> v1->v2
>> - Added "PROBE_DEFER" check
>> drivers/input/keyboard/omap4-keypad.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
>> index c05f98c..502b832 100644
>> --- a/drivers/input/keyboard/omap4-keypad.c
>> +++ b/drivers/input/keyboard/omap4-keypad.c
>> @@ -31,6 +31,7 @@
>> #include <linux/input.h>
>> #include <linux/slab.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/pinctrl/consumer.h>
>>
>> #include <linux/platform_data/omap4-keypad.h>
>>
>> @@ -76,6 +77,7 @@ enum {
>>
>> struct omap4_keypad {
>> struct input_dev *input;
>> + struct pinctrl *pins;
>>
>> void __iomem *base;
>> unsigned int irq;
>> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev)
>> goto err_release_mem;
>> }
>>
>> + keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
>> + if (IS_ERR(keypad_data->pins)) {
>> + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> +
>> + dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
>> + PTR_ERR(keypad_data->pins));
>> + keypad_data->pins = NULL;
>> + }
>>
>> /*
>> * Enable clocks for the keypad module so that we can read
>> --
>> 1.7.1
>>
>
^ permalink raw reply
* RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support")
From: Russell King - ARM Linux @ 2012-10-23 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ehkqihdh.fsf@deeprootsystems.com>
On Mon, Oct 22, 2012 at 09:47:06AM -0700, Kevin Hilman wrote:
> Peter Zijlstra <peterz@infradead.org> writes:
>
> > On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
> >
> >> So I did the same thing for my ARM SoC, and it definitley stops the RT
> >> throttling.
> >>
> >> However, it has the undesriable (IMO) side effect of making timed printk
> >> output rather unhelpful for debugging suspend/resume since printk time
> >> stays constant throughout suspend/resume no matter how long you
> >> sleep. :(
> >>
> >> So does that mean we have to choose between useful printk times during
> >> suspend/resume or functioning IRQ threads during suspend/resume ?
> >
> > Urgh.. this was not something I considered. This being primarily the
> > sched_clock infrastructure and such.
> >
> > So what exactly is the problem with the suspend resume thing (its not
> > something I've ever debugged), is all you need a clean break between pre
> > and post suspend, or do you need the actual time the machine was gone?
>
> I think it's more a question of what people are used to. I think folks
> used to debugging suspend/resume (at least on ARM) are used to having
> the printk timestamps reflect the amount of time the machine was gone.
>
> With a sched_clock() that counts during suspend, that feature doesn't
> work anymore. I'm not sure that this feature is a deal breaker, but it
> has been convenient.
IMHO, this isn't a deal breaker, it's nothing more than cosmetic issue.
The big hint about the sched_clock() behaviour is partly in the name,
and the behaviour you get from the scheduler if you don't give it what
it wants. The scheduler sets the requirements for sched_clock(), not
printk, so if we have to fix sched_clock() to get correct behaviour
from the scheduler, that's what we have to do irrespective of cosmetic
printk issues.
And there are many other ways to measure time off in suspend... we have
at least three other functions which return time, and which will return
updated time after a resume event.
^ permalink raw reply
* [PATCH] arm: sched: stop sched_clock() during suspend
From: Russell King - ARM Linux @ 2012-10-23 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY6ox+iJAGdSD=e7Yj55TzDWqOmLqu2fSRXvKJxqwfkhQ@mail.gmail.com>
On Tue, Oct 23, 2012 at 12:28:32AM +0200, Linus Walleij wrote:
> On Mon, Oct 22, 2012 at 7:05 PM, Kevin Hilman
> <khilman@deeprootsystems.com> wrote:
>
> > However, in light of RT throttling, this a correctness issue for process
> > accounting, so I agree that this should be done for all platforms
> > instead of providing an optional 'needs suspend' version of the API,
> > even though it means printk times no longer reflect time spent
> > suspended.
>
> Maybe we should get printk() to use the best clocksource
> instead.
>
> The reason AFAICT that printk() is using sched_clock() is that
> it's supposed to be fast. But now it seems that it's not going
> to return what printk() needs anymore.
No, printk() does not need this. You think it does, but it doesn't. What
we have is a difference between ARM and x86, and this difference is breaking
the scheduler.
The fact that the printk timestamp increments while suspended is a bug. It
doesn't on x86.
There's three other functions in the kernel which do return updated time.
I'm sure one of those can be used to printk() the time passed in suspend
at resume time, which would give the information required.
^ permalink raw reply
* [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
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