I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c?
Or else I'm not really following this... $SUBJECT is a bit confusing.
On Sat, Aug 9, 2014 at 12:26 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Regardless of this though I think that both the
Hello Linus,
On 08/11/2014 10:32 AM, Linus Walleij wrote:
I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c?
Or else I'm not really following this... $SUBJECT is a bit confusing.
Yes, the thing is that at the beginning I (wrongly) thought that the IRQ trigger
type
On 07/08/14 08:44, Javier Martinez Canillas wrote:
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when requesting an IRQ.
On Fri, Aug 08, 2014 at 03:07:33PM +0100, Nick Dyer wrote:
On 07/08/14 08:44, Javier Martinez Canillas wrote:
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the
+Thomas Gleixner, Jason Cooper, Benjamin Herrenschmidt and Thomas Abraham
Hello Dmitry,
On 08/08/2014 06:21 PM, Dmitry Torokhov wrote:
On Fri, Aug 08, 2014 at 03:07:33PM +0100, Nick Dyer wrote:
On 07/08/14 08:44, Javier Martinez Canillas wrote:
The Atmel maXTouch driver assumed that the IRQ
Hello,
On 08/08/2014 06:38 PM, Javier Martinez Canillas wrote:
It seems as if the first call to exynos_irq_set_type() that is made by OF is a
no-op while the second call is the one that actually setups the hw correctly.
Does this make any sense? Maybe is related to the pin not being muxed
+CC Linus, as this became also pinctrl related.
On 08.08.2014 20:29, Javier Martinez Canillas wrote:
Hello,
On 08/08/2014 06:38 PM, Javier Martinez Canillas wrote:
It seems as if the first call to exynos_irq_set_type() that is made by OF is
a
no-op while the second call is the one that
Hi,
On Fri, Aug 8, 2014 at 11:29 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hello,
On 08/08/2014 06:38 PM, Javier Martinez Canillas wrote:
It seems as if the first call to exynos_irq_set_type() that is made by OF is
a
no-op while the second call is the one that
Hello Doug,
On 08/08/2014 10:54 PM, Doug Anderson wrote:
Hi,
To fix the issue a variation of patch [0] will be posted that moves the IRQ
pinmux setup from .irq_set_type to the .irq_request_resources function
handler.
That way the pin will be setup as IRQ regardless of the the trigger type
Javier,
On Fri, Aug 8, 2014 at 3:26 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
I have some vague recollection that I set interrupts to pin-function
0 by default for some reason (assuming they would go to 0xf when
interrupts were enabled). ...but I can't for the life
The Atmel maXTouch driver assumed that the IRQ type flags will
always be passed using platform data but this is not true when
booting using Device Trees. In these setups the interrupt type
was ignored by the driver when requesting an IRQ.
This means that it will fail if a machine specified other
11 matches
Mail list logo
