mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
To: Harini Katakam <harini.katakam@xilinx.com>
Cc: <linus.walleij@linaro.org>, <gnurou@gmail.com>,
	<grant.likely@linaro.org>, <robh+dt@kernel.org>,
	<pawel.moll@arm.com>, <mark.rutland@arm.com>,
	<ijc+devicetree@hellion.org.uk>, <galak@codeaurora.org>,
	<rob@landley.net>, <michal.simek@xilinx.com>,
	<linux-gpio@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <harinikatakamlinux@gmail.com>,
	Harini Katakam <harinik@xilinx.com>
Subject: Re: [PATCH v2 1/2] gpio: Add driver for Zynq GPIO controller
Date: Wed, 18 Jun 2014 08:36:52 -0700	[thread overview]
Message-ID: <5cc8b89b-20ff-4fa9-92dd-bb2f6d3512d8@BY2FFO11FD030.protection.gbl> (raw)
In-Reply-To: <1403091577-10232-1-git-send-email-harinik@xilinx.com>

Hi Linus,

I did some of the changes for this v2 and a few things are not clear to
me.

The first is, how is userspace supposed to find the correct offset for a
GPIO pin. E.g. let's say GPIO 10 of this SOC-internal GPIO controller is
something I want to control. So, I'd export GPIO (chip-base + 10). But
this chip-base seems pretty variable. v1 of this patch had it hardcoded
to 0, which resulted in a predictable offset, but apparently was utterly
wrong. Now I see an offset of 138 for this chip when using my config.
And when I use multi_v7_defconfig the offset is somewhere in the 800s,
IIRC. The best I found was the 'label' in the gpiochip's sysfs entry,
but documentation says that is not necessarily unique, and parsing labes
seems sub-optimal too.

The second issue is a stack trace (below) I see when triggering
interrupts (e.g. echo rising > edge; and then pushing the connected
button). Looking at the stack trace, I don't see an obvious error (I
think I pretty much copied the IRQ registration from the gpio-pl061.c
driver you mentioned). Is this an issue in this driver or the core code?
This happens on Linus' latest tip. Despite all this chatter the system
still works and doesn't not seem to lock up.

Here the stack trace:
# echo rising > edge
  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
  in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
  no locks held by swapper/0/0.
  irq event stamp: 55488
  hardirqs last  enabled at (55485): [<c03bf10c>] cpuidle_enter_state+0x60/0xec
  hardirqs last disabled at (55486): [<c0014374>] __irq_svc+0x34/0x78
  softirqs last  enabled at (55488): [<c002fc40>] _local_bh_enable+0x58/0x64
  softirqs last disabled at (55487): [<c0030534>] irq_enter+0x48/0x88
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc1-xilinx-00021-gf5ddad957172 #88
  [<c0017840>] (unwind_backtrace) from [<c0013770>] (show_stack+0x20/0x24)
  [<c0013770>] (show_stack) from [<c04d94a0>] (dump_stack+0x8c/0xd0)
  [<c04d94a0>] (dump_stack) from [<c005d5e4>] (__might_sleep+0x1ac/0x1e4)
  [<c005d5e4>] (__might_sleep) from [<c04dc19c>] (mutex_lock_nested+0x40/0x46c)
  [<c04dc19c>] (mutex_lock_nested) from [<c019df34>] (kernfs_notify+0xac/0x148)
  [<c019df34>] (kernfs_notify) from [<c02d89e0>] (gpio_sysfs_irq+0x1c/0x24)
  [<c02d89e0>] (gpio_sysfs_irq) from [<c008588c>] (handle_irq_event_percpu+0xa8/0x3c0)
  [<c008588c>] (handle_irq_event_percpu) from [<c0085bf0>] (handle_irq_event+0x4c/0x6c)
  [<c0085bf0>] (handle_irq_event) from [<c0088a28>] (handle_simple_irq+0xac/0xbc)
  [<c0088a28>] (handle_simple_irq) from [<c0084fec>] (generic_handle_irq+0x30/0x40)
  [<c0084fec>] (generic_handle_irq) from [<c02de3fc>] (zynq_gpio_irqhandler+0xe8/0x130)
  [<c02de3fc>] (zynq_gpio_irqhandler) from [<c0084fec>] (generic_handle_irq+0x30/0x40)
  [<c0084fec>] (generic_handle_irq) from [<c000fd24>] (handle_IRQ+0x78/0xa0)
  [<c000fd24>] (handle_IRQ) from [<c000868c>] (gic_handle_irq+0x4c/0x70)
  [<c000868c>] (gic_handle_irq) from [<c0014384>] (__irq_svc+0x44/0x78)
  Exception stack(0xc0755ec8 to 0xc0755f10)
  5ec0:                   00000001 00000004 00000000 c075fb70 00000001 edfc9310
  5ee0: 8ed05707 0000001d 9e7f7ffa 0000001d c0752308 c0755f44 c0755ee0 c0755f10
  5f00: c0077340 c03bf110 200d0013 ffffffff
  [<c0014384>] (__irq_svc) from [<c03bf110>] (cpuidle_enter_state+0x64/0xec)
  [<c03bf110>] (cpuidle_enter_state) from [<c03bf2a0>] (cpuidle_enter+0x24/0x28)
  [<c03bf2a0>] (cpuidle_enter) from [<c0071d94>] (cpu_idle_loop+0x2e0/0x6fc)
  [<c0071d94>] (cpu_idle_loop) from [<c00721cc>] (cpupri_find+0x0/0x108)
  
  =================================
  [ INFO: inconsistent lock state ]
  3.16.0-rc1-xilinx-00021-gf5ddad957172 #88 Not tainted
  ---------------------------------
  inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
  swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
   (kernfs_mutex){?.+.+.}, at: [<c019df34>] kernfs_notify+0xac/0x148
  {HARDIRQ-ON-W} state was registered at:
    [<c0079a08>] lock_acquire+0xfc/0x21c
    [<c04dc1e0>] mutex_lock_nested+0x84/0x46c
    [<c019d668>] kernfs_activate+0x2c/0xf8
    [<c019d9b8>] kernfs_create_root+0xbc/0xe0
    [<c070edac>] sysfs_init+0x20/0x5c
    [<c070cef4>] mnt_init+0x108/0x258
    [<c070caa8>] vfs_caches_init+0x9c/0x110
    [<c06f5c3c>] start_kernel+0x364/0x3fc
    [<00008074>] 0x8074
  irq event stamp: 55488
  hardirqs last  enabled at (55485): [<c03bf10c>] cpuidle_enter_state+0x60/0xec
  hardirqs last disabled at (55486): [<c0014374>] __irq_svc+0x34/0x78
  softirqs last  enabled at (55488): [<c002fc40>] _local_bh_enable+0x58/0x64
  softirqs last disabled at (55487): [<c0030534>] irq_enter+0x48/0x88
  
  other info that might help us debug this:
   Possible unsafe locking scenario:
  
         CPU0
         ----
    lock(kernfs_mutex);
    <Interrupt>
      lock(kernfs_mutex);
  
   *** DEADLOCK ***
  
  no locks held by swapper/0/0.
  
  stack backtrace:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc1-xilinx-00021-gf5ddad957172 #88
  [<c0017840>] (unwind_backtrace) from [<c0013770>] (show_stack+0x20/0x24)
  [<c0013770>] (show_stack) from [<c04d94a0>] (dump_stack+0x8c/0xd0)
  [<c04d94a0>] (dump_stack) from [<c0076a50>] (print_usage_bug+0x254/0x2c4)
  [<c0076a50>] (print_usage_bug) from [<c0076e6c>] (mark_lock+0x3ac/0x674)
  [<c0076e6c>] (mark_lock) from [<c0078024>] (__lock_acquire+0x934/0x1b58)
  [<c0078024>] (__lock_acquire) from [<c0079a08>] (lock_acquire+0xfc/0x21c)
  [<c0079a08>] (lock_acquire) from [<c04dc1e0>] (mutex_lock_nested+0x84/0x46c)
  [<c04dc1e0>] (mutex_lock_nested) from [<c019df34>] (kernfs_notify+0xac/0x148)
  [<c019df34>] (kernfs_notify) from [<c02d89e0>] (gpio_sysfs_irq+0x1c/0x24)
  [<c02d89e0>] (gpio_sysfs_irq) from [<c008588c>] (handle_irq_event_percpu+0xa8/0x3c0)
  [<c008588c>] (handle_irq_event_percpu) from [<c0085bf0>] (handle_irq_event+0x4c/0x6c)
  [<c0085bf0>] (handle_irq_event) from [<c0088a28>] (handle_simple_irq+0xac/0xbc)
  [<c0088a28>] (handle_simple_irq) from [<c0084fec>] (generic_handle_irq+0x30/0x40)
  [<c0084fec>] (generic_handle_irq) from [<c02de3fc>] (zynq_gpio_irqhandler+0xe8/0x130)
  [<c02de3fc>] (zynq_gpio_irqhandler) from [<c0084fec>] (generic_handle_irq+0x30/0x40)
  [<c0084fec>] (generic_handle_irq) from [<c000fd24>] (handle_IRQ+0x78/0xa0)
  [<c000fd24>] (handle_IRQ) from [<c000868c>] (gic_handle_irq+0x4c/0x70)
  [<c000868c>] (gic_handle_irq) from [<c0014384>] (__irq_svc+0x44/0x78)
  Exception stack(0xc0755ec8 to 0xc0755f10)
  5ec0:                   00000001 00000004 00000000 c075fb70 00000001 edfc9310
  5ee0: 8ed05707 0000001d 9e7f7ffa 0000001d c0752308 c0755f44 c0755ee0 c0755f10
  5f00: c0077340 c03bf110 200d0013 ffffffff
  [<c0014384>] (__irq_svc) from [<c03bf110>] (cpuidle_enter_state+0x64/0xec)
  [<c03bf110>] (cpuidle_enter_state) from [<c03bf2a0>] (cpuidle_enter+0x24/0x28)
  [<c03bf2a0>] (cpuidle_enter) from [<c0071d94>] (cpu_idle_loop+0x2e0/0x6fc)
  [<c0071d94>] (cpu_idle_loop) from [<c00721cc>] (cpupri_find+0x0/0x108)

	Thanks,
	Sören


  parent reply	other threads:[~2014-06-18 15:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 11:39 Harini Katakam
2014-06-18 11:39 ` [PATCH v2 2/2] devicetree: Add Zynq GPIO devicetree bindings documentation Harini Katakam
2014-07-07 14:53   ` Linus Walleij
2014-07-07 17:35     ` Sören Brinkmann
2014-06-18 15:36 ` Sören Brinkmann [this message]
2014-07-07 14:51   ` [PATCH v2 1/2] gpio: Add driver for Zynq GPIO controller Linus Walleij
2014-07-07 15:23     ` Baruch Siach
2014-07-08  9:27       ` Linus Walleij
2014-07-11  6:28         ` Baruch Siach
2014-07-11 12:06           ` Linus Walleij
2014-07-11 12:27             ` Baruch Siach
2014-07-11 12:38               ` Linus Walleij
2014-07-07 16:08     ` Sören Brinkmann
2014-07-08  9:34       ` Linus Walleij
2014-07-08 15:55         ` Sören Brinkmann
2014-07-10  8:57           ` Linus Walleij
2014-07-07 14:45 ` Linus Walleij
2014-07-07 17:33   ` Sören Brinkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5cc8b89b-20ff-4fa9-92dd-bb2f6d3512d8@BY2FFO11FD030.protection.gbl \
    --to=soren.brinkmann@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=harini.katakam@xilinx.com \
    --cc=harinik@xilinx.com \
    --cc=harinikatakamlinux@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=pawel.moll@arm.com \
    --cc=rob@landley.net \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®