Re: [PATCH] hw_random: omap3-rom-rng: convert timer to delayed work

2015-11-17 Thread Herbert Xu 
On Fri, Nov 06, 2015 at 12:15:24AM +0200, Aaro Koskinen wrote:
> We cannot put the HW RNG to idle using a timer because we cannot disable
> clocks from atomic context. Use a delayed work instead.
> 
> Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.
> 
> Reported-by: Sebastian Reichel 
> Signed-off-by: Aaro Koskinen 

Thanks for the patch.  Can you please remove timer.h and include
workqueue.h instead?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/39] pinctrl: Move am4372 and dra7 macros to the the SoC header files

2015-11-17 Thread Linus Walleij 
On Fri, Nov 13, 2015 at 5:53 AM, Javier Martinez Canillas
 wrote:

> The  header file defines a set of macros
> for different SoCs families that falls under the OMAP sub-arch, that
> allow to define the padconf register physical address instead of the
> register offset from the padconf base.
>
> But the am43xx and dra7xx SoCs families have their own pinctrl header
> file so the DTS using these SoCs aren't able to use the AM4372_IOPAD()
> and DRA7XX_CORE_IOPAD() macros since  is
> not included.
>
> Move the macros to the correct header files so can be used by the DTS.
>
> Signed-off-by: Javier Martinez Canillas 

I need Tony's ACK on this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/39] pinctrl: Move am4372 and dra7 macros to the the SoC header files

2015-11-17 Thread Javier Martinez Canillas 
Hello Linus,

On 11/17/2015 10:47 AM, Linus Walleij wrote:
> On Fri, Nov 13, 2015 at 5:53 AM, Javier Martinez Canillas
>  wrote:
> 
>> The  header file defines a set of macros
>> for different SoCs families that falls under the OMAP sub-arch, that
>> allow to define the padconf register physical address instead of the
>> register offset from the padconf base.
>>
>> But the am43xx and dra7xx SoCs families have their own pinctrl header
>> file so the DTS using these SoCs aren't able to use the AM4372_IOPAD()
>> and DRA7XX_CORE_IOPAD() macros since  is
>> not included.
>>
>> Move the macros to the correct header files so can be used by the DTS.
>>
>> Signed-off-by: Javier Martinez Canillas 
> 
> I need Tony's ACK on this.
>

OK, I believe he was waiting for yours to pick the series though ;)
 
> Yours,
> Linus Walleij
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-11-17 Thread Julia Lawall 
On Tue, 17 Nov 2015, Boris Brezillon wrote:

> Hi Julia,
>
> On Tue, 17 Nov 2015 10:05:03 +0100 (CET)
> Julia Lawall  wrote:
>
> > > > (This isn't the worst one, but it just happens to be one of the first.)
> > > > There are many cases where the typical style would be to declare a new
> > > > variable at the top of the function, where you perform the
> > > > macro/function-call to convert from one abstraction to another. Like
> > > >
> > > > static int nfc_set_sram_bank(struct atmel_nand_host *host, unsigned int 
> > > > bank)
> > > > {
> > > > struct mtd_info *mtd = nand_to_mtd(>nand_chip);
> > > > ...
> > > >
> > > > and then use it later. Can that be done very easily?
> > > >
> > > > >   return -EINVAL;
> > > > >   nfc_writel(host->nfc->hsmc_regs, BANK, 
> > > > > ATMEL_HSMC_NFC_BANK1);
> > > > >   } else {
> > > >
> > > > ...
> > >
> > > Honestly, I don't know how to do that with a coccinelle script, and it
> > > will probably take me more time to find how to do it than addressing
> > > those problems manually.
> > >
> > > Julia, could you give us some hint?
> >
> > Probably something like the following would be easiest.  You can just run
> > it after your other transformations:
> >
> > @r exists@
> > identifier f;
> > expression e;
> > @@
> >
> > f(...) { <+...  nand_to_mtd(e) ...+> }
> >
> > @@
> > identifier r.f;
> > expression r.e;
> > @@
> >
> > f(...) {
> > + struct mtd_info *mtd = nand_to_mtd(e);
> > ...
> > }
>
> Thanks for the the suggestion...
>
> >
> > This won't work if there is more than one possible value of e.  If that is
> > likely, then I could come up with something more complex.  It also assumes
> > that you want to convert all such calls.  If you only want to convert calls
> > that occur in a particular context, eg a field reference, then you could
> > enhance the pattern inside the <+... ...+> in the first rule.
>
> ... unfortunately, as you've guessed, it's a bit more complicated.
> This mtd local variable is usually extracted from another local
> variable (struct nand_chip *chip), so we have to declare
>
> struct mtd_info *mtd = nand_to_mtd(e);
>
> after
>
> struct nand_chip *chip = expression;
>
> But this is not the only particular case. Sometime the chip variable is
> not assigned where it's declared (especially when it is dynamically
> allocated), and sometime it does not exist at all (we just extract it
> from a private struct: >chip).
> The mtd variable can also be declared in sub-code blocks (loop or
> conditional statements).
> And, as you stated, we might want to keep direct calls to nand_to_mtd()
> if it's only called once in a function context.
>
> I'm pretty sure we could describe all those cases with specific context
> description, but I must admit that it takes less time for me to fix
> those specific cases manually than figuring out how to describe them
> correctly in a coccinelle script :).
>
> This being said, I'd be happy to see how you would handle all these
> different cases.

Maybe the following would be useful.  It won't handle all the cases, but
maybe it will take care of a good number of the nontrivial ones.

julia

@r@
local idexpression x;
identifier fld,y;
@@

nand_to_mtd(>fld)->y

@exists@
type T;
local idexpression r.x;
identifier xx,r.y,r.fld;
@@

T xx;
+ struct mtd_info *mtd = nand_to_mtd(>fld);
...
nand_to_mtd(@xx->fld)->y

@@
local idexpression r.x;
identifier r.fld;
@@

struct mtd_info *mtd = nand_to_mtd(>fld);
<...
- nand_to_mtd(>fld)
+ mtd
...>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank

2015-11-17 Thread Jyri Sarha 

On 11/17/15 12:28, Daniel Vetter wrote:

On Fri, Nov 13, 2015 at 05:53:13PM +0200, Jyri Sarha wrote:

Since first RFC version:
- Added "drm/atomic: Track drm_plane's active state"-patch

We would need something like this to get rid off OMAPDSS somewhat
messy runtime_resume code. How does this look, could this generic
solution be refined to be acceptable for mainline, or should we start
looking a local solution to omapdrm?


One more comment besides what I've written in the older thread: You're not
on latest drm-next, which has gained an active_only paramter to the plane
commit helper.

It might be best to discuss this topic on #dri-devel on freenode irc a
bit.



Thanks a lot for you comments!

I just rebased my stuff on top the the latest drm-next. I think I need 
digest your earlier comments about drm_atomic_add_affected_planes etc. a 
bit before I can take advantage of any interactive communication. I'll 
try to follow those instruction first and see where it leads me.


Thanks,
Jyri


Cheers, Daniel



Jyri Sarha (2):
   drm/atomic: Track drm_plane's active state
   drm/atomic: Disable planes on blanked CRTC and enable on unblank

  drivers/gpu/drm/drm_atomic_helper.c | 82 +
  drivers/gpu/drm/drm_plane_helper.c  | 10 +
  include/drm/drm_atomic_helper.h | 39 +-
  include/drm/drm_crtc.h  |  2 +
  4 files changed, 70 insertions(+), 63 deletions(-)

--
1.9.1





--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-11-17 Thread Boris Brezillon 
Hi Julia,

On Tue, 17 Nov 2015 10:05:03 +0100 (CET)
Julia Lawall  wrote:

> > > (This isn't the worst one, but it just happens to be one of the first.)
> > > There are many cases where the typical style would be to declare a new
> > > variable at the top of the function, where you perform the
> > > macro/function-call to convert from one abstraction to another. Like
> > >
> > > static int nfc_set_sram_bank(struct atmel_nand_host *host, unsigned int 
> > > bank)
> > > {
> > >   struct mtd_info *mtd = nand_to_mtd(>nand_chip);
> > >   ...
> > >
> > > and then use it later. Can that be done very easily?
> > >
> > > > return -EINVAL;
> > > > nfc_writel(host->nfc->hsmc_regs, BANK, 
> > > > ATMEL_HSMC_NFC_BANK1);
> > > > } else {
> > >
> > > ...
> >
> > Honestly, I don't know how to do that with a coccinelle script, and it
> > will probably take me more time to find how to do it than addressing
> > those problems manually.
> >
> > Julia, could you give us some hint?
> 
> Probably something like the following would be easiest.  You can just run
> it after your other transformations:
> 
> @r exists@
> identifier f;
> expression e;
> @@
> 
> f(...) { <+...  nand_to_mtd(e) ...+> }
> 
> @@
> identifier r.f;
> expression r.e;
> @@
> 
> f(...) {
> + struct mtd_info *mtd = nand_to_mtd(e);
> ...
> }

Thanks for the the suggestion...

> 
> This won't work if there is more than one possible value of e.  If that is
> likely, then I could come up with something more complex.  It also assumes
> that you want to convert all such calls.  If you only want to convert calls
> that occur in a particular context, eg a field reference, then you could
> enhance the pattern inside the <+... ...+> in the first rule.

... unfortunately, as you've guessed, it's a bit more complicated.
This mtd local variable is usually extracted from another local
variable (struct nand_chip *chip), so we have to declare

struct mtd_info *mtd = nand_to_mtd(e);

after

struct nand_chip *chip = expression;

But this is not the only particular case. Sometime the chip variable is
not assigned where it's declared (especially when it is dynamically
allocated), and sometime it does not exist at all (we just extract it
from a private struct: >chip).
The mtd variable can also be declared in sub-code blocks (loop or
conditional statements).
And, as you stated, we might want to keep direct calls to nand_to_mtd()
if it's only called once in a function context.

I'm pretty sure we could describe all those cases with specific context
description, but I must admit that it takes less time for me to fix
those specific cases manually than figuring out how to describe them
correctly in a coccinelle script :).

This being said, I'd be happy to see how you would handle all these
different cases.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

2015-11-17 Thread Brian Norris 
Hi,

On Tue, Nov 17, 2015 at 12:02:29PM +0530, Vignesh R wrote:
> On 11/13/2015 09:35 PM, Cyrille Pitchen wrote:
> > 
> > In September I've sent a series of patches to enhance the support of QSPI 
> > flash
> > memories. Patch 4 was dedicated to the m25p80 driver and set the
> > rx_nbits / tx_nbits fields of spi_transfer struct(s) in order to configure 
> > the
> > number of I/O lines independently for the opcode, address and data parts.
> > The work was done for m25p80_read() but also for _read_reg(), _write_reg() 
> > and
> > _write().
> > The patched m25p80 driver was then tested with an at25 memory to check non-
> > regression.
> > 
> > This series of patches also added 4 enum spi_protocol fields inside struct
> > spi_nor so the spi-nor framework can tell the (Q)SPI controller driver what 
> > SPI
> > protocol should be use for erase, read, write and register read/write
> > operations, depending on the memory manufacturer and the command opcode.
> > This was done to better support Micron, Spansion and Macronix QSPI memories.
> > 
> > I have tested the series with Micron QSPI memories and Atmel QSPI controller
> > and I guess Marek also tested it on his side with Spansion QSPI memories and
> > another QSPI controller.
> > 
> > So if it can help other developers to develop QSPI controller drivers, the
> > series is still available there:
> > 
> > for the whole series:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371170.html
> > 
> > for patch 4 (depends on patch 2 for enum spi_protocol):
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371173.html
> > 
> 
> Should I rebase my next version on top of above patches by Cyrille or
> shall I post on top of 4.4-rc1?

I'm sorry to say I really haven't had the time to review that properly.
I'm also not sure it is a true dependency for your series, as you're
tackling different pieces of the puzzle. So it's mostly just a conflict,
not a real direct help.

So unless I'm misunderstanding, I'd suggest submitting MTD stuff against
the latest l2-mtd.git (or linux-next.git; l2-mtd.git is included there),
and I'll let you know if conflicts come up that need fixing.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Minimal support for dm814x

2015-11-17 Thread Matthijs van Duin 
On 13 November 2015 at 15:52, Tony Lindgren  wrote:
> I think this is the most recent TI git repo for dm81xx changes:
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary

Yeah, although I usually prefer to look at the
linux-ipnc-rdk-dm81xx.git and linux-dvr-rdk-dm81xx.git that descend
from it since they include some fixes that the last TI kernel doesn't.
(However they may also include patches specific to the ipnc/dvr
hardware, so some caution is needed.)

Since arago can be sluggish I just mirrored all three branches on github:
https://github.com/dutchanddutch/ti81xx-linux
I've also fixed an obnoxious commit in the ipnc-rdk which changed all
files to mode 755, since this made comparisons rather unpleasant.

The PLL code looks pretty mediocre to me. In particular, they make no
effort whatsoever to configure an exact ratio. It seems their
algorithm uses whatever predivider was already programmed, selects the
minimum postdivider that puts the DCO clock within valid range, and
then approximates the dco/refclk ratio using the fractional
multiplier.

This works in principle, but both minimizing the DCO and (often
needlessly) using the fractional multiplier seem like recipes to
maximize the clock jitter. Mind you, I don't know how much jitter
we're talking about here, I don't recall having seen specs about this.

I also have some concerns about the correctness of the implementation.
I haven't analyzed it in any detail, but repeated occurrences of
expressions of the form   (unsigned long long)( foo * bar )   make me
doubt whether the author realizes this is utterly pointless and will,
for 32-bit arguments, still perform a 32-bit multiplication.

Matthijs
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] arm, am335x: add support for the bosch shc board

2015-11-17 Thread Heiko Schocher 
add support for the am335x based shc board.

UART: 0-2 and 4
DRAM: 512 MiB
MMC:  OMAP SD/MMC: 0 @ 26 MHz
  OMAP SD/MMC: 1 @ 26 MHz
I2C:  at24 eeprom, pcf8563
USB:  USB1 (host)

Signed-off-by: Heiko Schocher 
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
  accepted.
  http://www.spinics.net/lists/devicetree/msg98542.html

- leds: leds-gpio: add shutdown function
  accepted.
  https://lkml.org/lkml/2015/10/13/169

- net: phy: smsc: disable energy detect mode
  accepted
  [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
  https://lkml.org/lkml/2015/10/17/2
  [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
  https://lkml.org/lkml/2015/10/17/4

- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
  http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
  @Dave: What is the current state of this patch?
  I have the same problem here on this am335x based board

- [PATCH v2] regulator: tps65217: remove tps65217.dtsi file
  http://www.kernelhub.org/?msg=868907=2

- bootlog and automated tests:
  http://xeidos.ddns.net/buildbot/waterfall

Changes in v2:
- Use IOPAD pinmux macro as Robert Nelson
  suggested.

 arch/arm/boot/dts/Makefile   |   3 +-
 arch/arm/boot/dts/am335x-shc.dts | 577 +++
 2 files changed, 579 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am335x-shc.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..65d750f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,7 +466,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-pepper.dtb \
am335x-lxm.dtb \
am335x-chiliboard.dtb \
-   am335x-wega-rdk.dtb
+   am335x-wega-rdk.dtb \
+   am335x-shc.dtb
 dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
new file mode 100644
index 000..1b5b044
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -0,0 +1,577 @@
+/*
+ * support for the bosch am335x based shc c3 board
+ *
+ * Copyright, C) 2015 Heiko Schocher 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include 
+
+/ {
+   model = "Bosch SHC";
+   compatible = "ti,am335x-shc", "ti,am335x-bone", "ti,am33xx";
+
+   aliases {
+   mmcblk0 = 
+   mmcblk1 = 
+   };
+
+   cpus {
+   cpu@0 {
+   /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+   operating-points = <
+   /* kHzuV */
+   594000  1225000
+   294000  1125000
+   >;
+   voltage-tolerance = <2>; /* 2 percentage */
+   cpu0-supply = <_reg>;
+   };
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   back_button {
+   label = "Back Button";
+   gpios = < 29 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+
+   front_button {
+   label = "Front Button";
+   gpios = < 25 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+   };
+
+   leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <_leds_s0>;
+
+   compatible = "gpio-leds";
+
+   led@1 {
+   label = "shc:power:red";
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led@2 {
+   label = "shc:power:bl";
+   gpios = < 22 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "timer";
+   default-state = "on";
+   };
+
+   led@3 {
+   label = "shc:lan:red";
+   gpios = < 26 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led@4 {
+   label = "shc:lan:bl";
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+

[PATCH] clk: gpio: Get parent clk names already in of_gpio_clk_setup()

2015-11-17 Thread Jyri Sarha 
Get parent clk names already in of_gpio_clk_setup() and store the
names in struct clk_gpio_delayed_register_data. of_clk_get_parent_name()
can not be called in struct of_clk_provider's get() callback since it
may make a recursive call to of_clk_get_from_provider() and this in turn
tries to recursively lock of_clk_mutex.

Signed-off-by: Jyri Sarha 
Cc: Sergej Sawazki 
---
Something has changed in Linux mainline so that getting the clk
parent names in struct of_clk_provider's get() callback does not work
anymore. This patch should fix the problem.

 drivers/clk/clk-gpio.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 10819e2..335322d 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -209,6 +209,8 @@ EXPORT_SYMBOL_GPL(clk_register_gpio_mux);
 
 struct clk_gpio_delayed_register_data {
const char *gpio_name;
+   int num_parents;
+   const char **parent_names;
struct device_node *node;
struct mutex lock;
struct clk *clk;
@@ -222,8 +224,6 @@ static struct clk *of_clk_gpio_delayed_register_get(
 {
struct clk_gpio_delayed_register_data *data = _data;
struct clk *clk;
-   const char **parent_names;
-   int i, num_parents;
int gpio;
enum of_gpio_flags of_flags;
 
@@ -248,26 +248,14 @@ static struct clk *of_clk_gpio_delayed_register_get(
return ERR_PTR(gpio);
}
 
-   num_parents = of_clk_get_parent_count(data->node);
-
-   parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
-   if (!parent_names) {
-   clk = ERR_PTR(-ENOMEM);
-   goto out;
-   }
-
-   for (i = 0; i < num_parents; i++)
-   parent_names[i] = of_clk_get_parent_name(data->node, i);
-
-   clk = data->clk_register_get(data->node->name, parent_names,
-   num_parents, gpio, of_flags & OF_GPIO_ACTIVE_LOW);
+   clk = data->clk_register_get(data->node->name, data->parent_names,
+   data->num_parents, gpio, of_flags & OF_GPIO_ACTIVE_LOW);
if (IS_ERR(clk))
goto out;
 
data->clk = clk;
 out:
mutex_unlock(>lock);
-   kfree(parent_names);
 
return clk;
 }
@@ -296,11 +284,24 @@ static void __init of_gpio_clk_setup(struct device_node 
*node,
unsigned gpio, bool active_low))
 {
struct clk_gpio_delayed_register_data *data;
+   const char **parent_names;
+   int i, num_parents;
 
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return;
 
+   num_parents = of_clk_get_parent_count(node);
+
+   parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
+   if (!parent_names)
+   return;
+
+   for (i = 0; i < num_parents; i++)
+   parent_names[i] = of_clk_get_parent_name(node, i);
+
+   data->num_parents = num_parents;
+   data->parent_names = parent_names;
data->node = node;
data->gpio_name = gpio_name;
data->clk_register_get = clk_register_get;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] clk: gpio: Get parent clk names already in of_gpio_clk_setup()

2015-11-17 Thread Jyri Sarha 
Get parent clk names already in of_gpio_clk_setup() and store the
names in struct clk_gpio_delayed_register_data. of_clk_get_parent_name()
can not be called in struct of_clk_provider's get() callback since it
may make a recursive call to of_clk_get_from_provider() and this in turn
tries to recursively lock of_clk_mutex.

Signed-off-by: Jyri Sarha 
Cc: Sergej Sawazki 
---
Something has changed in Linux mainline so that getting the clk
parent names in struct of_clk_provider's get() callback does not work
anymore. This patch should fix the problem.

 drivers/clk/clk-gpio.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 10819e2..335322d 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -209,6 +209,8 @@ EXPORT_SYMBOL_GPL(clk_register_gpio_mux);
 
 struct clk_gpio_delayed_register_data {
const char *gpio_name;
+   int num_parents;
+   const char **parent_names;
struct device_node *node;
struct mutex lock;
struct clk *clk;
@@ -222,8 +224,6 @@ static struct clk *of_clk_gpio_delayed_register_get(
 {
struct clk_gpio_delayed_register_data *data = _data;
struct clk *clk;
-   const char **parent_names;
-   int i, num_parents;
int gpio;
enum of_gpio_flags of_flags;
 
@@ -248,26 +248,14 @@ static struct clk *of_clk_gpio_delayed_register_get(
return ERR_PTR(gpio);
}
 
-   num_parents = of_clk_get_parent_count(data->node);
-
-   parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
-   if (!parent_names) {
-   clk = ERR_PTR(-ENOMEM);
-   goto out;
-   }
-
-   for (i = 0; i < num_parents; i++)
-   parent_names[i] = of_clk_get_parent_name(data->node, i);
-
-   clk = data->clk_register_get(data->node->name, parent_names,
-   num_parents, gpio, of_flags & OF_GPIO_ACTIVE_LOW);
+   clk = data->clk_register_get(data->node->name, data->parent_names,
+   data->num_parents, gpio, of_flags & OF_GPIO_ACTIVE_LOW);
if (IS_ERR(clk))
goto out;
 
data->clk = clk;
 out:
mutex_unlock(>lock);
-   kfree(parent_names);
 
return clk;
 }
@@ -296,11 +284,24 @@ static void __init of_gpio_clk_setup(struct device_node 
*node,
unsigned gpio, bool active_low))
 {
struct clk_gpio_delayed_register_data *data;
+   const char **parent_names;
+   int i, num_parents;
 
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return;
 
+   num_parents = of_clk_get_parent_count(node);
+
+   parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
+   if (!parent_names)
+   return;
+
+   for (i = 0; i < num_parents; i++)
+   parent_names[i] = of_clk_get_parent_name(node, i);
+
+   data->num_parents = num_parents;
+   data->parent_names = parent_names;
data->node = node;
data->gpio_name = gpio_name;
data->clk_register_get = clk_register_get;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC v2 0/2] Disable planes on blanked CRTC and enable on unblank

2015-11-17 Thread Daniel Vetter 
On Fri, Nov 13, 2015 at 05:53:13PM +0200, Jyri Sarha wrote:
> Since first RFC version:
> - Added "drm/atomic: Track drm_plane's active state"-patch
> 
> We would need something like this to get rid off OMAPDSS somewhat
> messy runtime_resume code. How does this look, could this generic
> solution be refined to be acceptable for mainline, or should we start
> looking a local solution to omapdrm?

One more comment besides what I've written in the older thread: You're not
on latest drm-next, which has gained an active_only paramter to the plane
commit helper.

It might be best to discuss this topic on #dri-devel on freenode irc a
bit.

Cheers, Daniel

> 
> Jyri Sarha (2):
>   drm/atomic: Track drm_plane's active state
>   drm/atomic: Disable planes on blanked CRTC and enable on unblank
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 82 
> +
>  drivers/gpu/drm/drm_plane_helper.c  | 10 +
>  include/drm/drm_atomic_helper.h | 39 +-
>  include/drm/drm_crtc.h  |  2 +
>  4 files changed, 70 insertions(+), 63 deletions(-)
> 
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-11-17 Thread Boris Brezillon 
Hi Brian,

On Mon, 16 Nov 2015 19:00:19 -0800
Brian Norris  wrote:

> Hi Boris,
> 
> On Mon, Nov 16, 2015 at 02:37:47PM +0100, Boris Brezillon wrote:
> > struct nand_chip now embeds an mtd device. Patch all drivers to make use
> > of this mtd instance instead of using the instance embedded in their
> > private struct or dynamically allocated.
> > 
> > Signed-off-by: Boris Brezillon 
> > Cc: Julia Lawall 
> > ---
> > Most of those changes were generate with this coccinelle script:
> > http://code.bulix.org/5vxuih-89429
> 
> I appreciate that this patch is mostly autogenerated (a good thing for
> preventing errors!), but there are some issues that I don't think play
> out very well stylistically. Hopefully the cocci script can be improved
> to handle some of this?
> 
> I'll try to point out a few snippets below.
> 
> Also, in case others are interested in reviewing your cocci script
> directly, it might be better to paste it inline than to link to it.
> Given the size of the patch, I don't think people would mind a few dozen
> extra lines to show how it wsa generated. Or maybe stick some in the
> cover letter too, if you end up reusing them in several patches.

Sure, I'll paste the script directly in the commit message next time.

> 
> > ---
> >  drivers/mtd/nand/ams-delta.c   | 13 ++--
> >  drivers/mtd/nand/atmel_nand.c  | 11 ++-
> >  drivers/mtd/nand/au1550nd.c| 18 ++---
> >  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
> >  drivers/mtd/nand/bcm47xxnflash/main.c  |  7 +-
> >  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
> >  drivers/mtd/nand/bf5xx_nand.c  | 14 ++--
> >  drivers/mtd/nand/brcmnand/brcmnand.c   | 11 ++-
> >  drivers/mtd/nand/cafe_nand.c   | 10 +--
> >  drivers/mtd/nand/cmx270_nand.c | 11 ++-
> >  drivers/mtd/nand/cs553x_nand.c | 13 ++--
> >  drivers/mtd/nand/davinci_nand.c| 25 +++
> >  drivers/mtd/nand/denali.c  | 61 +
> >  drivers/mtd/nand/denali.h  |  1 -
> >  drivers/mtd/nand/diskonchip.c  | 11 ++-
> >  drivers/mtd/nand/docg4.c   | 18 +++--
> >  drivers/mtd/nand/fsl_elbc_nand.c   | 22 +++---
> >  drivers/mtd/nand/fsl_ifc_nand.c| 23 +++
> >  drivers/mtd/nand/fsl_upm.c | 26 +++
> >  drivers/mtd/nand/fsmc_nand.c   | 59 +---
> >  drivers/mtd/nand/gpio.c| 16 ++---
> >  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
> >  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
> >  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
> >  drivers/mtd/nand/hisi504_nand.c| 11 ++-
> >  drivers/mtd/nand/jz4740_nand.c |  9 ++-
> >  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
> >  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
> >  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
> >  drivers/mtd/nand/mxc_nand.c|  5 +-
> >  drivers/mtd/nand/nandsim.c | 12 ++--
> >  drivers/mtd/nand/ndfc.c| 22 +++---
> >  drivers/mtd/nand/nuc900_nand.c | 21 +++---
> >  drivers/mtd/nand/omap2.c   | 94 
> > +++---
> >  drivers/mtd/nand/orion_nand.c  |  4 +-
> >  drivers/mtd/nand/pasemi_nand.c | 14 ++--
> >  drivers/mtd/nand/plat_nand.c   | 14 ++--
> >  drivers/mtd/nand/pxa3xx_nand.c | 33 -
> 
> ^^ BTW, this file already has a few conflicts. Sorry :(
> 
> I'll try to keep any eye out for things like this once we're close to
> being able to apply something like this, so I don't merge unnecessary
> churn. But for now, I hope we can review this series, and it won't be
> too much work to rebase/resend once the bigger things have been worked
> out.

No problem, resolving this conflict was pretty easy.

> 
> >  drivers/mtd/nand/r852.c| 34 --
> >  drivers/mtd/nand/r852.h|  1 -
> >  drivers/mtd/nand/s3c2410.c | 19 +++---
> >  drivers/mtd/nand/sh_flctl.c|  8 +--
> >  drivers/mtd/nand/sharpsl.c | 18 ++---
> >  drivers/mtd/nand/socrates_nand.c   |  5 +-
> >  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
> >  drivers/mtd/nand/tmio_nand.c   |  7 +-
> >  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
> >  drivers/mtd/nand/vf610_nfc.c   |  5 +-
> >  include/linux/mtd/sh_flctl.h   |  3 +-
> >  49 files changed, 383 insertions(+), 385 deletions(-)
> > 
> 
> ...
> 
> > diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c

Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

2015-11-17 Thread Julia Lawall 
> > (This isn't the worst one, but it just happens to be one of the first.)
> > There are many cases where the typical style would be to declare a new
> > variable at the top of the function, where you perform the
> > macro/function-call to convert from one abstraction to another. Like
> >
> > static int nfc_set_sram_bank(struct atmel_nand_host *host, unsigned int 
> > bank)
> > {
> > struct mtd_info *mtd = nand_to_mtd(>nand_chip);
> > ...
> >
> > and then use it later. Can that be done very easily?
> >
> > >   return -EINVAL;
> > >   nfc_writel(host->nfc->hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK1);
> > >   } else {
> >
> > ...
>
> Honestly, I don't know how to do that with a coccinelle script, and it
> will probably take me more time to find how to do it than addressing
> those problems manually.
>
> Julia, could you give us some hint?

Probably something like the following would be easiest.  You can just run
it after your other transformations:

@r exists@
identifier f;
expression e;
@@

f(...) { <+...  nand_to_mtd(e) ...+> }

@@
identifier r.f;
expression r.e;
@@

f(...) {
+ struct mtd_info *mtd = nand_to_mtd(e);
...
}

This won't work if there is more than one possible value of e.  If that is
likely, then I could come up with something more complex.  It also assumes
that you want to convert all such calls.  If you only want to convert calls
that occur in a particular context, eg a field reference, then you could
enhance the pattern inside the <+... ...+> in the first rule.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 18/27] mtd: nand: update mtd_to_nand()

2015-11-17 Thread Boris Brezillon 
On Mon, 16 Nov 2015 19:03:53 -0800
Brian Norris  wrote:

> On Mon, Nov 16, 2015 at 02:37:51PM +0100, Boris Brezillon wrote:
> > Now that all drivers are using the mtd instance embedded in the nand_chip
> 
> Do you have a script that verifies this? I thought you did at some
> point, and it'd be nice to note it, so I can also use it to verify
> things once it gets applied.

No, didn't write that script, but it should probably look like the one
I used to remove the mtd field from driver private struct.

> 
> > struct we can safely update the mtd_to_nand_chip() implementation to use
> 
> Nit: s/mtd_to_nand_chip/mtd_to_nand/

Yep, I'll fix that.

> 
> > the container_of macro instead of returning the content of mtd->priv.
> > This will allow us to remove mtd->priv = chip assignments done in all
> > NAND controller drivers.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  include/linux/mtd/nand.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index 8ec071e..873646d 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -734,7 +734,7 @@ static inline struct device_node 
> > *nand_get_flash_node(struct nand_chip *chip)
> >  
> >  static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
> >  {
> > -   return mtd->priv;
> > +   return container_of(mtd, struct nand_chip, mtd);
> >  }
> >  
> >  static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
> > -- 
> > 2.1.4
> > 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] [media] include/media: move platform_data to linux/platform_data/media

2015-11-17 Thread Mauro Carvalho Chehab 
Em Mon, 16 Nov 2015 13:28:10 +0100
Arnd Bergmann  escreveu:

> I think we can also move some of the existing platform data headers to the 
> same
> place, but that could be a separate patch:
> 
> $ git grep linux/platform_data drivers/media/
> drivers/media/platform/coda/coda-common.c:#include 
> 
> drivers/media/platform/soc_camera/mx2_camera.c:#include 
> 
> drivers/media/platform/soc_camera/mx3_camera.c:#include 
> 
> drivers/media/platform/soc_camera/mx3_camera.c:#include 
> 
> drivers/media/platform/soc_camera/pxa_camera.c:#include 
> 
> drivers/media/platform/soc_camera/rcar_vin.c:#include 
> 

Fair enough. Just sent a separate patch to address that.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] arm, am335x: add support for the bosch shc board

2015-11-17 Thread Dave Gerlach 

Hi,
On 11/17/2015 02:24 AM, Heiko Schocher wrote:

add support for the am335x based shc board.

UART: 0-2 and 4
DRAM: 512 MiB
MMC:  OMAP SD/MMC: 0 @ 26 MHz
   OMAP SD/MMC: 1 @ 26 MHz
I2C:  at24 eeprom, pcf8563
USB:  USB1 (host)

Signed-off-by: Heiko Schocher 
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
   accepted.
   http://www.spinics.net/lists/devicetree/msg98542.html

- leds: leds-gpio: add shutdown function
   accepted.
   https://lkml.org/lkml/2015/10/13/169

- net: phy: smsc: disable energy detect mode
   accepted
   [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
   https://lkml.org/lkml/2015/10/17/2
   [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
   https://lkml.org/lkml/2015/10/17/4

- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
   @Dave: What is the current state of this patch?
   I have the same problem here on this am335x based board



A different approach is being taken for resolving the issue of rtc hwmod 
on am43x epos evm [1], which is what I was attempting to solve with the 
patch you have linked. We decided to avoid changing omap_hwmod code and 
I haven't been pursuing the ti,no-init flag anymore.


Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg121987.html


- [PATCH v2] regulator: tps65217: remove tps65217.dtsi file
   http://www.kernelhub.org/?msg=868907=2

- bootlog and automated tests:
   http://xeidos.ddns.net/buildbot/waterfall

Changes in v2:
- Use IOPAD pinmux macro as Robert Nelson
   suggested.

  arch/arm/boot/dts/Makefile   |   3 +-
  arch/arm/boot/dts/am335x-shc.dts | 577 +++
  2 files changed, 579 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/am335x-shc.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..65d750f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,7 +466,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-pepper.dtb \
am335x-lxm.dtb \
am335x-chiliboard.dtb \
-   am335x-wega-rdk.dtb
+   am335x-wega-rdk.dtb \
+   am335x-shc.dtb
  dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
new file mode 100644
index 000..1b5b044
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -0,0 +1,577 @@
+/*
+ * support for the bosch am335x based shc c3 board
+ *
+ * Copyright, C) 2015 Heiko Schocher 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include 
+
+/ {
+   model = "Bosch SHC";
+   compatible = "ti,am335x-shc", "ti,am335x-bone", "ti,am33xx";
+
+   aliases {
+   mmcblk0 = 
+   mmcblk1 = 
+   };
+
+   cpus {
+   cpu@0 {
+   /*
+* To consider voltage drop between PMIC and SoC,
+* tolerance value is reduced to 2% from 4% and
+* voltage value is increased as a precaution.
+*/
+   operating-points = <
+   /* kHzuV */
+   594000  1225000
+   294000  1125000
+   >;
+   voltage-tolerance = <2>; /* 2 percentage */
+   cpu0-supply = <_reg>;
+   };
+   };
+
+   gpio_keys {
+   compatible = "gpio-keys";
+
+   back_button {
+   label = "Back Button";
+   gpios = < 29 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+
+   front_button {
+   label = "Front Button";
+   gpios = < 25 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   debounce-interval = <1000>;
+   gpio-key,wakeup;
+   };
+   };
+
+   leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <_leds_s0>;
+
+   compatible = "gpio-leds";
+
+   led@1 {
+   label = "shc:power:red";
+   gpios = < 23 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   led@2 {
+   label = "shc:power:bl";
+   gpios = < 22 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "timer";
+

[BISECTED] v4.4-rc1 GPIO regression on OMAP1

2015-11-17 Thread Aaro Koskinen 
Hi,

Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:

450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
commit 450fa54cfd66e3dda6eda26256637ee8928af12a
Author: Grygorii Strashko 
Date:   Fri Sep 25 12:28:03 2015 -0700

gpio: omap: convert to use generic irq handler

Reverting the commit works (as a quick workaround at least).

The crash log:

[0.253612] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.262613] pgd = c0004000
[0.265754] [] *pgd=
[0.269862] Internal error: Oops: 75 [#1] ARM
[0.274734] Modules linked in:
[0.278313] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.4.0-rc1-e3-los_afe0c+-2-g25379c0-dirty #1
[0.288246] Hardware name: Amstrad E3 (Delta)
[0.293146] task: c1836000 ti: c1838000 task.ti: c1838000
[0.299155] PC is at irq_gc_mask_set_bit+0x1c/0x60
[0.304525] LR is at __irq_do_set_handler+0x118/0x15c
[0.310165] pc : []lr : []psr: 60d3
[0.310165] sp : c1839c90  ip : c1862c64  fp : c1839c9c
[0.322740] r10:   r9 : c0411950  r8 : c0411bbc
[0.328533] r7 :   r6 : c185c310  r5 : c00444e8  r4 : c185c300
[0.335687] r3 : c1854b50  r2 :   r1 :   r0 : c185c310
[0.342858] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.351153] Control: 317f  Table: 10004000  DAC: 0057
[0.357494] Process swapper (pid: 1, stack limit = 0xc1838190)
[0.363917] Stack: (0xc1839c90 to 0xc183a000)
[0.368837] 9c80: c1839cc4 c1839ca0 
c0047d4c c0048480
[0.377916] 9ca0:   0050 c185c300 c00444e8  
c1839cec c1839cc8
[0.386989] 9cc0: c0047dd4 c0047c44 c0046f40 a053 0050 c00444e8 
 0050
[0.396064] 9ce0: c1839d0c c1839cf0 c0047e1c c0047da0 c1862c64 0050 
 0050
[0.405139] 9d00: c1839d24 c1839d10 c01b345c c0047dfc c185cb00 c185c310 
c1839d54 c1839d28
[0.414214] 9d20: c0049670 c01b3430 c0075888 c0043440 c1854b50 0001 
0010 0050
[0.423293] 9d40: c185cb00 c0411bbc c1839d7c c1839d58 c0049894 c0049604 
 c1862c64
[0.432375] 9d60: c1854b50 c1862c64 c0419280 c1862c64 c1839d9c c1839d80 
c01b3328 c004980c
[0.441456] 9d80: c1862c64 c1862c64 c1862c10 c1854b50 c1839ddc c1839da0 
c01b79f4 c01b32d4
[0.450530] 9da0:   c0411958 c0419294  c0411950 
c0419294 c0411984
[0.459605] 9dc0: c0419294  c03e45e8  c1839df4 c1839de0 
c01fcf58 c01b7708
[0.468684] 9de0: c0411950 c045ce30 c1839e1c c1839df8 c01fb668 c01fcf3c 
c0411950 c0419294
[0.477759] 9e00: c0411984   c03e45e8 c1839e3c c1839e20 
c01fb844 c01fb518
[0.486836] 9e20:  c0419294 c01fb7a4  c1839e64 c1839e40 
c01f9a90 c01fb7b4
[0.495913] 9e40: c185434c c185b450 c185b514 c0419294 c185b4e0 c041d9c8 
c1839e74 c1839e68
[0.504991] 9e60: c01fb078 c01f9a28 c1839e9c c1839e78 c01facf8 c01fb068 
c03931d0 c1839e88
[0.514069] 9e80: c0419294 c040bb80 c1804960 c03f5a08 c1839eb4 c1839ea0 
c01fbdb0 c01fab7c
[0.523150] 9ea0: c040bb80 c040bb80 c1839ec4 c1839eb8 c01fcf18 c01fbd40 
c1839ed4 c1839ec8
[0.532227] 9ec0: c03f5a20 c01fcef0 c1839f4c c1839ed8 c000966c c03f5a18 
c1839efc c1839ee8
[0.541304] 9ee0: c03e4604 c019b3b4 c03e2700 c1ffcd34 c1839f4c c1839f00 
c00314ec c03e45f8
[0.550384] 9f00:   0002 0002  c03e2024 
c038f2fc 
[0.559465] 9f20: c1839f4c 0002 c03ff81c 0002 c03ff820 005e 
c042ba80 c042ba80
[0.568543] 9f40: c1839f94 c1839f50 c03e4e14 c00095f0 0002 0002 
 c03e45e8
[0.577625] 9f60: 9b7bd08b c0406660 ad19cf47  c0305764  
 
[0.586701] 9f80:   c1839fac c1839f98 c0305774 c03e4d18 
 c0305764
[0.595775] 9fa0:  c1839fb0 c000a440 c0305774   
 
[0.604845] 9fc0:       
 
[0.613916] 9fe0:     0013  
faef8a80 f438707c
[0.622908] Backtrace: 
[0.625894] [] (irq_gc_mask_set_bit) from [] 
(__irq_do_set_handler+0x118/0x15c)
[0.635897] [] (__irq_do_set_handler) from [] 
(__irq_set_handler+0x44/0x5c)
[0.645458]  r6: r5:c00444e8 r4:c185c300
[0.650746] [] (__irq_set_handler) from [] 
(irq_set_chip_and_handler_name+0x30/0x34)
[0.661128]  r7:0050 r6: r5:c00444e8 r4:0050
[0.667559] [] (irq_set_chip_and_handler_name) from [] 
(gpiochip_irq_map+0x3c/0x8c)
[0.677869]  r7:0050 r6: r5:0050 r4:c1862c64
[0.684300] [] (gpiochip_irq_map) from [] 
(irq_domain_associate+0x7c/0x1c4)
[0.693885]  r5:c185c310 r4:c185cb00
[0.698072] [] (irq_domain_associate) from []