From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nishanth Menon Subject: Re: regressions in linux-next? Date: Tue, 22 Apr 2014 20:30:22 -0500 Message-ID: <20140423013022.GA18648@kahuna> References: <53566C20.6000208@ti.com> <53568706.1050204@ti.com> <5356E5E4.1060509@ti.com> <5356F2A4.6010106@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:43875 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756072AbaDWBaZ (ORCPT ); Tue, 22 Apr 2014 21:30:25 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Javier Martinez Canillas Cc: Tony Lindgren , Santosh Shilimkar , Kevin Hilman , Linus Walleij , linux-omap , Peter Ujfalusi 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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 25.528870] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 25.536390] [] (dump_stack) from [] (gpio_irq_type+0x1b4/0x218) [ 25.544359] [] (gpio_irq_type) from [] (__irq_set_trigger+0x5c/0xfc) [ 25.552774] [] (__irq_set_trigger) from [] (irq_set_irq_type+0x38/0x58) [ 25.561455] [] (irq_set_irq_type) from [] (gpiochip_irq_map+0x60/0x68) [ 25.570047] [] (gpiochip_irq_map) from [] (irq_domain_associate+0x70/0x1b8) [ 25.579087] [] (irq_domain_associate) from [] (irq_create_mapping+0x6c/0xfc) [ 25.588216] [] (irq_create_mapping) from [] (gpiochip_irqchip_add+0xa8/0xf0) [ 25.597346] [] (gpiochip_irqchip_add) from [] (omap_gpio_probe+0x2bc/0x8a4) [ 25.606386] [] (omap_gpio_probe) from [] (platform_drv_probe+0x18/0x48) [ 25.615068] [] (platform_drv_probe) from [] (driver_probe_device+0x110/0x224) [ 25.624286] [] (driver_probe_device) from [] (bus_for_each_drv+0x5c/0x88) [ 25.633146] [] (bus_for_each_drv) from [] (device_attach+0x74/0x8c) [ 25.641471] [] (device_attach) from [] (bus_probe_device+0x88/0xb0) [ 25.649793] [] (bus_probe_device) from [] (device_add+0x3a8/0x4dc) [ 25.658029] [] (device_add) from [] (of_platform_device_create_pdata+0x70/0x94) [ 25.667428] [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0xdc/0x184) [ 25.677990] [] (of_platform_bus_create) from [] (of_platform_bus_create+0x140/0x184) [ 25.687835] [] (of_platform_bus_create) from [] (of_platform_populate+0x60/0x98) [ 25.697323] [] (of_platform_populate) from [] (pdata_quirks_init+0x34/0x44) [ 25.706364] [] (pdata_quirks_init) from [] (omap_generic_init+0x10/0x1c) [ 25.715136] [] (omap_generic_init) from [] (customize_machine+0x1c/0x40) [ 25.723906] [] (customize_machine) from [] (do_one_initcall+0x80/0x1c8) [ 25.732591] [] (do_one_initcall) from [] (kernel_init_freeable+0xfc/0x1cc) [ 25.741544] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xe4) [ 25.749958] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) -- Regards, Nishanth Menon