From: Nishanth Menon <nm@ti.com>
To: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Tony Lindgren <tony@atomide.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Kevin Hilman <khilman@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-omap <linux-omap@vger.kernel.org>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Subject: Re: regressions in linux-next?
Date: Tue, 22 Apr 2014 20:30:22 -0500 [thread overview]
Message-ID: <20140423013022.GA18648@kahuna> (raw)
In-Reply-To: <CABxcv=kx6zhJqVKcE1cijyOEak+jgXgsFaRAFYcZA4L_zxLRHg@mail.gmail.com>
On 01:08-20140423, Javier Martinez Canillas wrote:
[...]
> > on AM335x-sk:
> >> So this makes only am335x-sk to fail with the gpiolib irpchip
> >> conversion as reported by Peter and you.
> >>
> >> Do you know what special use of GPIO have this board to behave
> >> differently than the other boards? I've looked at the DTS but didn't
> >> find anything evident.
> >
> > I could not find anything interesting yet. Peter did mention that
> > reverting d04b76626e94 helped make the platform boot fine. I am trying
> > to add a few prints and see which specific line does things go bad..
> > and if so why.. unfortunately, I am using the board remotely as well..
> > Will try to track this down in the next few hours and post back.
> >
>
> Great, thanks a lot for your help and sorry for the inconvenience!
Yep - If I am correct, and as we all suspected, GPIO0_7 which controls
the VTT regulator for DDR is getting configured as input, instead of
output.
http://slexy.org/raw/s2gReMRZI6 (with diff:
http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was
trying to truncate and isolate - had to switch to non-relaxed versions
of writes to force sequencing with barriers to trace it down..)
Anyways, the key log is [0]:
gpiochip_irq_map -> calls
irq_set_irq_type(irq, chip->irq_default_type);
which inturn triggers: gpio-omap.c's gpio_irq_type
in this, logic:
if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to
setting the input type for the GPIO 0_7 (you can see the logic
walks through setting every GPIO to input!).
The original usage as far as I could discern was that this function was
only called after probe got completed as the gpio requests were
triggered.
There are probably many hacks possible, but a cleaner solution might
involve gpio_irqchip knowing when to set the type and knowing which gpios
not to mess with.
Example hack:
Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE,
in gpio-omap's gpio_irq_type could do:
if (type == IRQ_TYPE_NONE)
return 0;
boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other
side effects I have'nt thought through..
[0]:
[ 25.504976] DONE gpio_irq_type: 533 bank 0xf9e07000, offset 7
[ 25.511052] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-next-20140422-00003-gd9fc91f-dirty #12
[ 25.520811] [<c0014cf0>] (unwind_backtrace) from [<c0011984>] (show_stack+0x10/0x14)
[ 25.528870] [<c0011984>] (show_stack) from [<c05421b8>] (dump_stack+0x78/0x94)
[ 25.536390] [<c05421b8>] (dump_stack) from [<c03016c8>] (gpio_irq_type+0x1b4/0x218)
[ 25.544359] [<c03016c8>] (gpio_irq_type) from [<c008f0d4>] (__irq_set_trigger+0x5c/0xfc)
[ 25.552774] [<c008f0d4>] (__irq_set_trigger) from [<c0090888>] (irq_set_irq_type+0x38/0x58)
[ 25.561455] [<c0090888>] (irq_set_irq_type) from [<c02fbf4c>] (gpiochip_irq_map+0x60/0x68)
[ 25.570047] [<c02fbf4c>] (gpiochip_irq_map) from [<c0092908>] (irq_domain_associate+0x70/0x1b8)
[ 25.579087] [<c0092908>] (irq_domain_associate) from [<c0092abc>] (irq_create_mapping+0x6c/0xfc)
[ 25.588216] [<c0092abc>] (irq_create_mapping) from [<c02fbe4c>] (gpiochip_irqchip_add+0xa8/0xf0)
[ 25.597346] [<c02fbe4c>] (gpiochip_irqchip_add) from [<c0300bb8>] (omap_gpio_probe+0x2bc/0x8a4)
[ 25.606386] [<c0300bb8>] (omap_gpio_probe) from [<c0354ee4>] (platform_drv_probe+0x18/0x48)
[ 25.615068] [<c0354ee4>] (platform_drv_probe) from [<c03535d0>] (driver_probe_device+0x110/0x224)
[ 25.624286] [<c03535d0>] (driver_probe_device) from [<c0351e64>] (bus_for_each_drv+0x5c/0x88)
[ 25.633146] [<c0351e64>] (bus_for_each_drv) from [<c035348c>] (device_attach+0x74/0x8c)
[ 25.641471] [<c035348c>] (device_attach) from [<c0352b68>] (bus_probe_device+0x88/0xb0)
[ 25.649793] [<c0352b68>] (bus_probe_device) from [<c035114c>] (device_add+0x3a8/0x4dc)
[ 25.658029] [<c035114c>] (device_add) from [<c045ccb8>] (of_platform_device_create_pdata+0x70/0x94)
[ 25.667428] [<c045ccb8>] (of_platform_device_create_pdata) from [<c045cdb8>] (of_platform_bus_create+0xdc/0x184)
[ 25.677990] [<c045cdb8>] (of_platform_bus_create) from [<c045ce1c>] (of_platform_bus_create+0x140/0x184)
[ 25.687835] [<c045ce1c>] (of_platform_bus_create) from [<c045cec0>] (of_platform_populate+0x60/0x98)
[ 25.697323] [<c045cec0>] (of_platform_populate) from [<c07ad190>] (pdata_quirks_init+0x34/0x44)
[ 25.706364] [<c07ad190>] (pdata_quirks_init) from [<c07ace64>] (omap_generic_init+0x10/0x1c)
[ 25.715136] [<c07ace64>] (omap_generic_init) from [<c079e50c>] (customize_machine+0x1c/0x40)
[ 25.723906] [<c079e50c>] (customize_machine) from [<c0008a64>] (do_one_initcall+0x80/0x1c8)
[ 25.732591] [<c0008a64>] (do_one_initcall) from [<c079bc94>] (kernel_init_freeable+0xfc/0x1cc)
[ 25.741544] [<c079bc94>] (kernel_init_freeable) from [<c053cb1c>] (kernel_init+0x8/0xe4)
[ 25.749958] [<c053cb1c>] (kernel_init) from [<c000e708>] (ret_from_fork+0x14/0x2c)
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2014-04-23 1:30 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 13:18 regressions in linux-next? Nishanth Menon
2014-04-22 13:29 ` Peter Ujfalusi
2014-04-22 15:52 ` Javier Martinez Canillas
2014-04-22 19:37 ` Ezequiel Garcia
2014-04-22 22:32 ` Javier Martinez Canillas
2014-04-22 22:00 ` Linus Walleij
2014-04-22 23:03 ` Javier Martinez Canillas
2014-04-22 23:47 ` Tony Lindgren
2014-04-24 15:16 ` Kevin Hilman
2014-04-24 15:25 ` Nishanth Menon
2014-04-24 15:37 ` Javier Martinez Canillas
2014-04-24 15:42 ` Tony Lindgren
2014-04-24 16:33 ` Javier Martinez Canillas
2014-04-24 16:47 ` Tony Lindgren
2014-04-24 15:40 ` Tony Lindgren
2014-04-24 15:46 ` Nishanth Menon
2014-04-24 16:17 ` Tony Lindgren
2014-04-24 17:08 ` Nishanth Menon
2014-04-24 19:59 ` Aaro Koskinen
2014-04-24 19:22 ` Aaro Koskinen
2014-04-28 22:04 ` Paul Walmsley
2014-04-22 15:13 ` Nishanth Menon
2014-04-22 21:57 ` Nishanth Menon
2014-04-22 22:45 ` Javier Martinez Canillas
2014-04-22 22:52 ` Nishanth Menon
2014-04-22 23:08 ` Javier Martinez Canillas
2014-04-23 1:30 ` Nishanth Menon [this message]
2014-04-23 7:24 ` Javier Martinez Canillas
2014-04-23 10:59 ` Peter Ujfalusi
2014-04-23 13:01 ` Linus Walleij
2014-04-23 13:29 ` Nishanth Menon
2014-04-23 14:38 ` Linus Walleij
2014-04-23 14:50 ` Javier Martinez Canillas
2014-04-23 14:52 ` Linus Walleij
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=20140423013022.GA18648@kahuna \
--to=nm@ti.com \
--cc=javier@dowhile0.org \
--cc=khilman@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.com \
/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