* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Russell King - ARM Linux @ 2012-10-27 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027163224.67d57aef@endymion.delvare>
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who was apparently familiar with such practice, so I
> > > assumed it was OK. Actually I still assume it is, until someone comes
> > > with an supported architecture where it is not.
> >
> > According to Al Viro, that would be m68k.
>
> OK... So to make things clear, let me ask Al directly about it. Al, can
> you please tell us if:
>
> --- a/include/uapi/linux/i2c.h
> +++ b/include/uapi/linux/i2c.h
> struct i2c_msg {
> __u16 addr; /* slave address */
> __u16 flags;
> __u16 len; /* msg length */
> + __u16 transferred; /* actual bytes transferred */
> __u8 *buf; /* pointer to msg data */
> };
>
> would break binary compatibility on m68k or any other architecture you
> are familiar with? Note that struct i2c_msg isn't declared with
> attribute packed, so my assumption was that pointer "buf" was align on
> at least 4 bytes, leaving a hole between len and buf. Am I wrong?
So, you're attitude here is "I don't believe you, you are lying". Well,
if you have that level of distrust of your fellow developers, then you
don't deserve to be a Linux developer at all - and given that why should
I take any notice of you in the future over I2C stuff.
Especially as you've just proven that you don't know how to deal properly
with APIs...
Quite frankly I find your attitude towards me here totally disgusting and
insulting.
Not surprisingly, I didn't lie (I don't lie) and so I didn't "make up"
that M68k is one such architecture, and you've now had the confirmation
from Al.
So, I look forward to your apology for _implying_ that I'm a liar over
this issue, or if not, your resignation as I2C maintainer.
Thanks.
^ permalink raw reply
* [PATCH 1/2] pinctrl/: at91: fix warmings
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-27 17:53 UTC (permalink / raw)
To: linux-arm-kernel
/opt/work/linux-2.6/drivers/pinctrl/pinctrl-at91.c: In function 'at91_pinctrl_probe_dt':
/opt/work/linux-2.6/drivers/pinctrl/pinctrl-at91.c:952:12: warning: assignment discards qualifiers from pointer target type
/opt/work/linux-2.6/drivers/pinctrl/pinctrl-at91.c: In function 'at91_gpio_probe':
/opt/work/linux-2.6/drivers/pinctrl/pinctrl-at91.c:1517:17: warning: assignment discards qualifiers from pointer target type
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
drivers/pinctrl/pinctrl-at91.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 0679643..6485d7e 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -949,7 +949,7 @@ static int __devinit at91_pinctrl_probe_dt(struct platform_device *pdev,
return -ENODEV;
info->dev = &pdev->dev;
- info->ops =
+ info->ops = (struct at91_pinctrl_mux_ops*)
of_match_device(at91_pinctrl_of_match, &pdev->dev)->data;
at91_pinctrl_child_count(info, np);
@@ -1514,7 +1514,7 @@ static int __devinit at91_gpio_probe(struct platform_device *pdev)
goto err;
}
- at91_chip->ops =
+ at91_chip->ops = (struct at91_pinctrl_mux_ops*)
of_match_device(at91_gpio_of_match, &pdev->dev)->data;
at91_chip->pioc_virq = irq;
at91_chip->pioc_idx = alias_idx;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] MAINTAINERS: add pinctrl atmel at91 entry
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-27 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351360392-8669-1-git-send-email-plagnioj@jcrosoft.com>
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 027ec2b..cb97031 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5624,6 +5624,12 @@ S: Maintained
F: drivers/pinctrl/
F: include/linux/pinctrl/
+PIN CONTROLLER - ATMEL AT91
+M: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: drivers/pinctrl/pinctrl-at91.c
+
PIN CONTROLLER - ST SPEAR
M: Viresh Kumar <viresh.linux@gmail.com>
L: spear-devel at list.st.com
--
1.7.10.4
^ permalink raw reply related
* imx-sdma.c broken on imx53 for sound
From: Fabio Estevam @ 2012-10-27 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39c8a3f022e86d3eae0fb7b6e48049f1.squirrel@webmail.efn.org>
Hi Rick,
On Fri, Oct 19, 2012 at 3:07 PM, Rick Bronson <rick@efn.org> wrote:
> Hi,
>
> On the iMX53, the sound chip sgtl5000 seems to get SDMA channel 0, but
> this code in drivers/dma/imx-sdma.c:
>
> /* not interested in channel 0 interrupts */
> if (sdmac->channel == 0)
> return;
>
> causes the DMA to be ignored. If I comment out the above, I still get no
> sound...
>
> Anyone have any ideas?
Are you providing the mx53 sdma firmware?
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] Add FDT support to Pandaboard initialization
From: Constantine Shulyupin @ 2012-10-27 18:50 UTC (permalink / raw)
To: linux-arm-kernel
From: Constantine Shulyupin <const@MakeLinux.com>
Problem:
- FDT is supported only by generic OMAP board initialization in arch/arm/mach-omap2/board-generic.c and lacks some configurations, which are not yet configured in FDT (USB for example).
Solution:
- arch/arm/mach-omap2/board-omap4panda.c supports initialization with FDT and without it.
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 33 ++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..fea7a83 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -31,6 +31,7 @@
#include <linux/ti_wilink_st.h>
#include <linux/wl12xx.h>
#include <linux/platform_data/omap-abe-twl6040.h>
+#include <linux/of_platform.h>
#include <asm/hardware/gic.h>
#include <asm/mach-types.h>
@@ -526,3 +527,35 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
.timer = &omap4_timer,
.restart = omap_prcm_restart,
MACHINE_END
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+ { .compatible = "simple-bus", },
+ { .compatible = "ti,omap-infra", },
+ { }
+};
+
+static void __init panda_dt_init(void)
+{
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ omap4_panda_init();
+}
+
+static const char *omap4_panda_compat[] __initdata = {
+ "ti,omap4-panda",
+ "ti,omap4",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP4_PANDA_DT, "OMAP4 Pandaboard with FDT support")
+ .dt_compat = omap4_panda_compat,
+ .reserve = omap_reserve,
+ .smp = smp_ops(omap4_smp_ops),
+ .map_io = omap4_map_io,
+ .init_early = omap4430_init_early,
+ .init_irq = omap_gic_of_init,
+ .handle_irq = gic_handle_irq,
+ .init_machine = panda_dt_init,
+ .init_late = omap4430_init_late,
+ .timer = &omap4_timer,
+ .restart = omap_prcm_restart,
+MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 7/7] i2c: omap: implement handling for 'transferred' bytes
From: Paul Walmsley @ 2012-10-27 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351167915-15079-8-git-send-email-balbi@ti.com>
Hi
On Thu, 25 Oct 2012, Felipe Balbi wrote:
> this is important in cases where client driver
> wants to know how many bytes were actually
> transferred.
>
> There is one trick here: if transfer is completed,
> meaning I2C_CNT reaches zero, then ARDY will be
> asserted to let SW know that it can program a
> new transfer.
>
> When ARDY is asserted, I2C_CNT is reset to the
> original value (msg->len), which means that
> for a successful message, msg->transferred = msg->len
> and we don't need to spend time with a register
> read.
>
> In case of NACK condition, however, I2C_CNT will
> remain with the end value which is the amount of
> data transferred until NACK condition found on the
> bus inclusive. In this situation, msg->transferred
> needs to be initialized with:
>
> msg->len - read(I2C_CNT) - 1;
>
> This patch implements exactly that handling.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/i2c/busses/i2c-omap.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 699fa12..d268e92 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -588,6 +588,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> goto out;
> }
>
> + msg->transferred = msg->len;
> + wmb();
If this barrier is being used to ensure that the compiler doesn't move
this store past the point at which the I2C interrupt handler can be
entered, then please consider the same comments as on the other
patch that adds a barrier:
http://marc.info/?l=linux-omap&m=135129247524136&w=2
http://marc.info/?l=linux-omap&m=135135357305794&w=2
- Paul
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Jean Delvare @ 2012-10-27 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027171036.GA24822@ZenIV.linux.org.uk>
Hi Al,
On Sat, 27 Oct 2012 18:10:36 +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> > On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> >
> > > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > > is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> > > struct foo {
> > > char x;
> > > void *p;
> > > }; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
> > > occupied by p.
> > >
> > > Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
> > > surprised by e.g. coldfire-based SoC with i2c on it.
> >
> > BTW, that's easily verified - take a cross-compiler and do this:
> > ; cat >a.c <<'EOF'
> > struct { char x; void *y; } v;
> > int z = (char *)&v.y - (char *)&v;
> > EOF
> > ; m68k-linux-gnu-gcc -S a.c
> > ; grep -A1 'z:' a.s
> > z:
> > .long 2
> > ;
> > and watch what it puts into z. gcc is very liberal about what it considers
> > a constant expression, so it allows that sort of expressions as initializers
> > for global variables. Not a portable C, but convenient for experiments like
> > that; just grab a cross-toolchain and feed it testcases of that kind...
Thanks for the fast and complete answer.
> ... and google for i2c coldfire immediately turns up this:
> http://mailman.uclinux.org/pipermail/uclinux-dev/2012-May/051874.html
> with
> +config I2C_COLDFIRE
> + tristate "Freescale Coldfire I2C driver"
> + depends on !M5272
> + help
> + This driver supports the I2C interface availible on most Freescale
> + Coldfire processors.
> +
> + This driver can be built as a module. If so, the module
> + will be called i2c-coldfire.
>
> in it, along with addition of drivers/i2c/busses/i2c-coldfire.c... IOW,
> i2c on m68k is quite real. Sorry, no go - you don't even have an excuse
> of i2c never existing on the architecture in question.
You are completely right, we will have to find another way to let bus
drivers report how much of each message they managed to transmit or
receive.
Thanks again,
--
Jean Delvare
^ permalink raw reply
* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Fabio Estevam @ 2012-10-27 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004135130.GC5554@sortiz-mobl>
Hi Samuel,
On Thu, Oct 4, 2012 at 10:51 AM, Samuel Ortiz <samuel.ortiz@intel.com> wrote:
>> I want to add mc34708 support to mx53qsb and need this series to be applied.
> I understand. I'll queue it to my for-next branch as soon as the merge window
> is closed.
Could you please queue this series? I still do not see it applied in
your 'for-next-merge' branch.
I will add mc34708 touchscreen support and need Uwe's series to be applied.
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH 1/3] irqchip: add basic infrastructure
From: Arnd Bergmann @ 2012-10-27 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Saturday 27 October 2012, Thomas Petazzoni wrote:
> With the recent creation of the drivers/irqchip/ directory, it is
> desirable to move irq controller drivers here. At the moment, the only
> driver here is irq-bcm2835, the driver for the irq controller found in
> the ARM BCM2835 SoC, present in Rasberry Pi systems. This irq
> controller driver was exporting its initialization function and its
> irq handling function through a header file in
> <linux/irqchip/bcm2835.h>.
Very nice series!
I think it would be good if Thomas Gleixner as the IRQ subsystem maintainer
could have a look as well. We should probably add the drivers/irqchip
directory to that MAINTAINERS entry.
Arnd
^ permalink raw reply
* [PATCH 1/3] irqchip: add basic infrastructure
From: Thomas Gleixner @ 2012-10-27 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210271921.17472.arnd@arndb.de>
On Sat, 27 Oct 2012, Arnd Bergmann wrote:
> On Saturday 27 October 2012, Thomas Petazzoni wrote:
> > With the recent creation of the drivers/irqchip/ directory, it is
> > desirable to move irq controller drivers here. At the moment, the only
> > driver here is irq-bcm2835, the driver for the irq controller found in
> > the ARM BCM2835 SoC, present in Rasberry Pi systems. This irq
> > controller driver was exporting its initialization function and its
> > irq handling function through a header file in
> > <linux/irqchip/bcm2835.h>.
>
> Very nice series!
>
> I think it would be good if Thomas Gleixner as the IRQ subsystem maintainer
> could have a look as well. We should probably add the drivers/irqchip
> directory to that MAINTAINERS entry.
I skimmed over the patches and they look very reasonable. I try to
find a time slot to give it a more thorough look.
So: Tentatively-acked-by-me
^ permalink raw reply
* [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
From: Mark Brown @ 2012-10-27 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349423012-18048-1-git-send-email-ulf.hansson@stericsson.com>
On Fri, Oct 05, 2012 at 09:43:32AM +0200, Ulf Hansson wrote:
> To be able to deactivate resourses in suspend, the resourses must
> first be surely active. This is done with a pm_runtime_get_sync.
> Once the resourses are restored to active state again in resume,
> the runtime pm usage count can be decreased with a pm_runtime_put.
The PM core will ensure devices are runtime resumed before we enter
suspend precisely due to this sort of issue.
-------------- 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/20121027/e3ecc64f/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] ASoC: sam9g20_wm8731: convert to device tree support
From: Mark Brown @ 2012-10-27 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901079-18307-4-git-send-email-voice.shen@atmel.com>
On Mon, Oct 22, 2012 at 06:17:58PM +0800, Bo Shen wrote:
> Covert sam9g20 wm8731 to device tree support
> And enable it through dts file
>
> Tested on sam9g20 EK board
This needs to add binding documentation for the board.
> + dai: dai {
> + compatible = "atmel,atmel-ssc-dai";
> + atmel,dai-master = <&ssc0>;
> + };
This looks wrong - this is a Linux-specific virtual device sitting on
top of the SSC which is the actual physical device. The usual patterns
would be something like have the machine driver register the DAI based
on the SSC specified in the bindings (much like how you're handling the
platform already).
-------------- 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/20121027/9129200a/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] ASoC: sam9g20_wm8731: fix the issue for non-DT kernel
From: Mark Brown @ 2012-10-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901079-18307-5-git-send-email-voice.shen@atmel.com>
On Mon, Oct 22, 2012 at 06:17:59PM +0800, Bo Shen wrote:
> When register platform from DAIs, the platform device to PCM no longer
> needed. So, fix it with this patch
This should be squashed into the change which changes the registeration
to ensure that we don't get both methods used simultaneously.
-------------- 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/20121027/64dc5f06/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] spi: spidev: Add device tree bindings
From: Mark Brown @ 2012-10-27 22:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351238873-25230-2-git-send-email-maxime.ripard@free-electrons.com>
On Fri, Oct 26, 2012 at 10:07:52AM +0200, Maxime Ripard wrote:
> This will allow to probe spidev from device tree
So, this isn't really something we should have in DT in this format -
the fact that we happen to control some device from userspace isn't a
generic property of the board really, we may end up changing our minds
on Linux too. The most obvious thing for this seems to be to add the
specific devices to spidev as the OF bindings rather than just register
as some non-specific "spidev" so we can change our minds later about how
to handle the devices. Not sure that's urgently tasteful but it does
mean we move the "we handle this in userspace" bit out of the .dts into
the kernel which seems better.
-------------- 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/20121027/bad6ce54/attachment.sig>
^ permalink raw reply
* [PATCH v2 RESEND] ARM: pxa: hx4700: Fix backlight PWM device number
From: Haojian Zhuang @ 2012-10-27 23:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50814466.235bb40a.1e56.ffffd458SMTPIN_ADDED@mx.google.com>
On Fri, Oct 19, 2012 at 8:15 PM, Paul Parsons <lost.distance@yahoo.com> wrote:
> Recent changes to PXA PWM support changed the PXA27X PWM device
> numbering scheme.
>
> The linux-3.5 PXA PWM driver followed the hardware numbering scheme for
> the 4 PWMs, while the linux-3.6-rc1 PXA PWM driver has adopted a linear
> numbering scheme:
>
> Address Hardware 3.5 pwm_id 3.6-rc1 pwm_id
> 0x40b00000 PWM0 0 0
> 0x40b00010 PWM2 2 1
> 0x40c00000 PWM1 1 2
> 0x40c00010 PWM3 3 3
>
> The hx4700 backlight uses PWM1 at 0x40c00000. Consequently the pwm_id
> must be changed from 1 to 2.
>
> This patch fixes the backlight PWM device number and at the same time
> moves from the legacy PWM API (pwm_id) to the new PWM API (pwm_lookup).
>
> Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> ---
>
> V2: Switch from legacy PWM API to new PWM API.
>
> arch/arm/mach-pxa/hx4700.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
> index e631198..d66f9f9 100644
> --- a/arch/arm/mach-pxa/hx4700.c
> +++ b/arch/arm/mach-pxa/hx4700.c
> @@ -28,6 +28,7 @@
> #include <linux/mfd/asic3.h>
> #include <linux/mtd/physmap.h>
> #include <linux/pda_power.h>
> +#include <linux/pwm.h>
> #include <linux/pwm_backlight.h>
> #include <linux/regulator/driver.h>
> #include <linux/regulator/gpio-regulator.h>
> @@ -556,7 +557,7 @@ static struct platform_device hx4700_lcd = {
> */
>
> static struct platform_pwm_backlight_data backlight_data = {
> - .pwm_id = 1,
> + .pwm_id = -1, /* Superseded by pwm_lookup */
> .max_brightness = 200,
> .dft_brightness = 100,
> .pwm_period_ns = 30923,
> @@ -571,6 +572,10 @@ static struct platform_device backlight = {
> },
> };
>
> +static struct pwm_lookup hx4700_pwm_lookup[] = {
> + PWM_LOOKUP("pxa27x-pwm.1", 0, "pwm-backlight", NULL),
> +};
> +
> /*
> * USB "Transceiver"
> */
> @@ -872,6 +877,7 @@ static void __init hx4700_init(void)
> pxa_set_stuart_info(NULL);
>
> platform_add_devices(devices, ARRAY_SIZE(devices));
> + pwm_add_table(hx4700_pwm_lookup, ARRAY_SIZE(hx4700_pwm_lookup));
>
> pxa_set_ficp_info(&ficp_info);
> pxa27x_set_i2c_power_info(NULL);
> --
> 1.7.8.6
>
>
>
>
Applied
Thanks
Haojian
^ permalink raw reply
* [PATCH] [ARM] pxa/spitz_pm.c: Fix hang under certain conditions when resuming from STR.
From: Haojian Zhuang @ 2012-10-27 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351183898-12856-1-git-send-email-dromede@gmail.com>
On Fri, Oct 26, 2012 at 12:51 AM, <dromede@gmail.com> wrote:
> From: Marko Katic <dromede.gmail.com>
>
> Devices that use spitz_pm.c will fail to resume
> from STR (Suspend To Ram) when the charger plug is inserted
> or removed when a device is in STR mode. The culprit is
> a misconfigured gpio line - GPIO18. GPIO18 should be configured as a
> regular GPIO input but it gets configured as an alternate function
> GPIO18_RDY. And then later in postsuspend() it gets configured as
> a regular GPIO18 input line.
>
> Fix this by removing the GPIO18_RDY configuration so that GPIO18
> only gets configured as a regular gpio input.
>
> Signed-off-by: Marko Katic <dromede.gmail.com>
Applied with fixing your email to dromede at gmail.com
Thanks
Haojian
^ permalink raw reply
* [GIT PULL][for 3.7] pull request from upload/fix in arch-pxa git tree
From: Haojian Zhuang @ 2012-10-27 23:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof & Arnd,
Please help to pull upload/fix branch from arch-pxa git tree.
Best Regards
Haojian
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://github.com/hzhuang1/linux.git upload/fix
for you to fetch changes up to 510fcb0d331f314cd20d0067d56f29302846f47b:
ARM: pxa/spitz_pm: Fix hang when resuming from STR (2012-10-28 07:53:45 +0800)
----------------------------------------------------------------
Marko Katic (1):
ARM: pxa/spitz_pm: Fix hang when resuming from STR
Paul Parsons (1):
ARM: pxa: hx4700: Fix backlight PWM device number
arch/arm/mach-pxa/hx4700.c | 8 +++++++-
arch/arm/mach-pxa/spitz_pm.c | 8 ++------
2 files changed, 9 insertions(+), 7 deletions(-)
^ permalink raw reply
* [GIT PULL][for 3.8] pull request from upload/board in arch-pxa git tree
From: Haojian Zhuang @ 2012-10-27 23:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd & Olof,
Please help to pull upload/board branch from arch-pxa git tree.
Best Regards
Haojian
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://github.com/hzhuang1/linux.git upload/board
for you to fetch changes up to f534958f092bab25eadc25dbfa01657918239b77:
ARM: pxa: use module_platform_driver macro (2012-10-26 17:25:15 +0800)
----------------------------------------------------------------
Paul Parsons (1):
ARM: pxa2xx: Remove EXPERIMENTAL dependency from spi-pxa2xx driver
Srinivas Kandagatla (1):
ARM: pxa: use module_platform_driver macro
arch/arm/mach-pxa/pxa3xx-ulpi.c | 13 +------------
drivers/spi/Kconfig | 2 +-
2 files changed, 2 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH 1/3] irqchip: add basic infrastructure
From: Stephen Warren @ 2012-10-28 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/27/2012 10:45 AM, Thomas Petazzoni wrote:
...
> So, upon the suggestion of Rob Herring and Arnd Bergmann, this commit
> introduces a small infrastructure that defines a central
> irqchip_init() function in drivers/irqchip/irqchip.c, which is meant
> to be called as the ->init_irq() callback of ARM platforms.
This patch.
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
As a minor aside, I only received patch 2/3 in my inbox initially, and
that made no sense to me without reading this patch too. It would have
been helpful to have been CC'd on the whole series.
^ permalink raw reply
* [PATCH 2/3] arm: bcm2835: convert to the irqchip infrastructure
From: Stephen Warren @ 2012-10-28 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-2-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/27/2012 10:45 AM, Thomas Petazzoni wrote:
> Register the irq controller driver in the main
> drivers/irqchip/irqchip.c file, and make sure that the initialization
> function of the driver sets handle_arch_irq() appropriately. This
> requires a bit of movement in the driver since the
> bcm2835_handle_irq() must move before the armctrl_of_init() function
> to avoid a forward declaration.
>
> On the arch/arm side, use irqchip_init() as the ->init_irq() callback,
> and remove the definition of ->handle_irq() since this is now done by
> the irq controller driver.
> diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
> +static void armctrl_handle_bank(int bank, struct pt_regs *regs)
To make the patch more readable, I'd suggest adding function prototypes
at the start of the file, and not re-arranging the code. That'll remove
the large cut/paste block in the diff. I wouldn't point out this trivial
issue except that I think this needs a respin for the minor issue I
raise below.
> -static int __init armctrl_of_init(struct device_node *node,
> - struct device_node *parent)
> +int __init armctrl_of_init(struct device_node *node,
> + struct device_node *parent)
Since this is now a public API, it should probably be named better. How
about bcm2835_irqchip_init()?
Aside from that,
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
I don't foresee any likely conflicts with anything I'll stage for 3.8 in
the bcm2835 tree, so feel free to take this through the irq tree or
directly into arm-soc as appropriate.
^ permalink raw reply
* [PATCH 3/3] arm: mvebu: move irq controller driver to drivers/irqchip
From: Stephen Warren @ 2012-10-28 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-3-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/27/2012 10:45 AM, Thomas Petazzoni wrote:
A patch description might be useful.
The same add-prototype-vs-cut/paste comment as in patch 2 could apply here.
Aside from that, this patch,
Reviewed-by: Stephen Warren <swarren@wwwdotorg.org>
^ permalink raw reply
* [GIT PULL v2] Renesas ARM-based SoC boards for v3.8
From: Simon Horman @ 2012-10-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Hi Arnd,
please consider the following board enhancements for 3.8.
----------------------------------------------------------------
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git boards
for you to fetch changes up to 39fe22dd9b60c26a6e1a5279abfb6473d67723e6:
ARM: mach-shmobile: Use DT_MACHINE for mackerel (2012-10-24 17:06:15 +0900)
----------------------------------------------------------------
Bastian Hecht (1):
ARM: mach-shmobile: add FLCTL DMA slave definitions for sh7372
Kuninori Morimoto (6):
ARM: shmobile: armadillo800eva: enable restart
ARM: shmobile: r8a7779: add HSPI clock support
ARM: shmobile: r8a7779: add I2C clock support
ARM: shmobile: r8a7779: add I2C driver support
ARM: shmobile: marzen: add HSPI support
ARM: shmobile: r8a7740: fixup DT machine desc name typo
Nobuhiro Iwamatsu (2):
ARM: shmobile: r8a7740: Enable PMU
ARM: mach-shmobile: Use DT_MACHINE for mackerel
Tetsuyuki Kobayashi (3):
ARM: shmobile: kzm9g: enable magnetometer ak8975.
ARM: shmobile: kzm9g: enable three-axis digital accelerometer ADXL345
ARM: shmobile: kzm9g: enable DMAEngine on SHDI0 and SDHI2
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sh7372-mackerel.dts | 22 +++++++
arch/arm/configs/armadillo800eva_defconfig | 1 +
arch/arm/configs/kzm9g_defconfig | 4 ++
arch/arm/configs/marzen_defconfig | 4 ++
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm/mach-shmobile/board-armadillo800eva.c | 8 +++
arch/arm/mach-shmobile/board-kzm9g.c | 14 ++++-
arch/arm/mach-shmobile/board-mackerel.c | 8 ++-
arch/arm/mach-shmobile/board-marzen.c | 25 ++++++++
arch/arm/mach-shmobile/clock-r8a7779.c | 16 ++++-
arch/arm/mach-shmobile/include/mach/sh7372.h | 4 ++
arch/arm/mach-shmobile/setup-r8a7740.c | 18 +++++-
arch/arm/mach-shmobile/setup-r8a7779.c | 77 ++++++++++++++++++++++++
arch/arm/mach-shmobile/setup-sh7372.c | 20 ++++++
15 files changed, 220 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/sh7372-mackerel.dts
^ permalink raw reply
* [PATCH 01/12] ARM: shmobile: r8a7740: Enable PMU
From: Simon Horman @ 2012-10-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351391173-32379-1-git-send-email-horms@verge.net.au>
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
This patch enables PMU for r8a7740.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/configs/armadillo800eva_defconfig | 1 +
arch/arm/mach-shmobile/setup-r8a7740.c | 16 ++++++++++++++++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f78d259..3d76407 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -7,6 +7,7 @@ CONFIG_LOG_BUF_SHIFT=16
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_PERF_EVENTS=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 11bb1d9..1e032cb 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -590,6 +590,21 @@ static struct platform_device i2c1_device = {
.num_resources = ARRAY_SIZE(i2c1_resources),
};
+static struct resource pmu_resources[] = {
+ [0] = {
+ .start = evt2irq(0x19a0),
+ .end = evt2irq(0x19a0),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device pmu_device = {
+ .name = "arm-pmu",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(pmu_resources),
+ .resource = pmu_resources,
+};
+
static struct platform_device *r8a7740_late_devices[] __initdata = {
&i2c0_device,
&i2c1_device,
@@ -597,6 +612,7 @@ static struct platform_device *r8a7740_late_devices[] __initdata = {
&dma1_device,
&dma2_device,
&usb_dma_device,
+ &pmu_device,
};
/*
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/12] ARM: shmobile: kzm9g: enable magnetometer ak8975.
From: Simon Horman @ 2012-10-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351391173-32379-1-git-send-email-horms@verge.net.au>
From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
This patch enables magnetometer ak8975.
I checked ak8975_probe() returns successfully.
Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/configs/kzm9g_defconfig | 2 ++
arch/arm/mach-shmobile/board-kzm9g.c | 6 +++++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index c88b578..1404b04 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -119,6 +119,8 @@ CONFIG_DMADEVICES=y
CONFIG_SH_DMAE=y
CONFIG_ASYNC_TX_DMA=y
CONFIG_STAGING=y
+CONFIG_SENSORS_AK8975=y
+CONFIG_IIO=y
# CONFIG_DNOTIFY is not set
CONFIG_INOTIFY_USER=y
CONFIG_VFAT_FS=y
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index 0a43f31..a37da78 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -557,7 +557,11 @@ static struct i2c_board_info i2c0_devices[] = {
},
{
I2C_BOARD_INFO("r2025sd", 0x32),
- }
+ },
+ {
+ I2C_BOARD_INFO("ak8975", 0x0c),
+ .irq = intcs_evt2irq(0x3380), /* IRQ28 */
+ },
};
static struct i2c_board_info i2c1_devices[] = {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/12] ARM: shmobile: kzm9g: enable three-axis digital accelerometer ADXL345
From: Simon Horman @ 2012-10-28 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351391173-32379-1-git-send-email-horms@verge.net.au>
From: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
This patch enables three-axis digital accelerometer ADXL345.
Test:
sudo cat /dev/input/event2
then tip up the board. You get something from /dev/input/event2.
Signed-off-by: Tetsuyuki Kobayashi <koba@kmckk.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/arm/configs/kzm9g_defconfig | 2 ++
arch/arm/mach-shmobile/board-kzm9g.c | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 1404b04..ce99e3e 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -74,6 +74,8 @@ CONFIG_KEYBOARD_GPIO=y
# CONFIG_INPUT_MOUSE is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ST1232=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_ADXL34X=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=9
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index a37da78..1a46422 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -562,6 +562,10 @@ static struct i2c_board_info i2c0_devices[] = {
I2C_BOARD_INFO("ak8975", 0x0c),
.irq = intcs_evt2irq(0x3380), /* IRQ28 */
},
+ {
+ I2C_BOARD_INFO("adxl34x", 0x1d),
+ .irq = intcs_evt2irq(0x3340), /* IRQ26 */
+ },
};
static struct i2c_board_info i2c1_devices[] = {
--
1.7.10.4
^ permalink raw reply related
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