* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-13 20:53 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-13 20:53 UTC (permalink / raw) To: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely, Tony Lindgren Hi, I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [ 2.264221] retu-mfd 2-0001: Retu v3.2 found [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter <jon-hunter@ti.com> Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Thanks, A. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-13 20:53 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-13 20:53 UTC (permalink / raw) To: linux-arm-kernel Hi, I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: [ 2.264221] retu-mfd 2-0001: Retu v3.2 found [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 The error is coming from regmap code. According to git bisect, it is caused by: commit ede4d7a5b9835510fd1f724367f68d2fa4128453 Author: Jon Hunter <jon-hunter@ti.com> Date: Fri Mar 1 11:22:47 2013 -0600 gpio/omap: convert gpio irq domain to linear mapping The commit does not anymore revert cleanly, and I haven't yet tried crafting a manual revert, so any fix proposals/ideas are welcome... Thanks, A. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-13 20:53 ` Aaro Koskinen @ 2013-05-16 18:09 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-16 18:09 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > Hi, > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > The error is coming from regmap code. According to git bisect, it is > caused by: > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > Author: Jon Hunter <jon-hunter@ti.com> > Date: Fri Mar 1 11:22:47 2013 -0600 > > gpio/omap: convert gpio irq domain to linear mapping > > The commit does not anymore revert cleanly, and I haven't yet tried > crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-16 18:09 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-16 18:09 UTC (permalink / raw) To: linux-arm-kernel * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > Hi, > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > The error is coming from regmap code. According to git bisect, it is > caused by: > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > Author: Jon Hunter <jon-hunter@ti.com> > Date: Fri Mar 1 11:22:47 2013 -0600 > > gpio/omap: convert gpio irq domain to linear mapping > > The commit does not anymore revert cleanly, and I haven't yet tried > crafting a manual revert, so any fix proposals/ideas are welcome... Hmm this might be a bit trickier to fix. Obviously the real solution is to convert omap1 to SPARSE_IRQ like we did for omap2+. For the -rc cycle, it might be possible to fix this by adding a different irq_to_gpio() and gpio_to_irq() functions for omap1. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-16 18:09 ` Tony Lindgren @ 2013-05-16 21:00 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-16 21:00 UTC (permalink / raw) To: Tony Lindgren; +Cc: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > The error is coming from regmap code. According to git bisect, it is > > caused by: > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > Author: Jon Hunter <jon-hunter@ti.com> > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > crafting a manual revert, so any fix proposals/ideas are welcome... > > Hmm this might be a bit trickier to fix. Obviously the real solution > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > For the -rc cycle, it might be possible to fix this by adding a > different irq_to_gpio() and gpio_to_irq() functions for omap1. The commit reverts cleanly if we also revert 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt service routine), which seems to be just some minor optimization. The result is below, and with it 770 works again. A. diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 2050891..a9b5813 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -52,6 +52,7 @@ struct gpio_bank { struct list_head node; void __iomem *base; u16 irq; + int irq_base; struct irq_domain *domain; u32 non_wakeup_gpios; u32 enabled_non_wakeup_gpios; @@ -87,14 +88,7 @@ struct gpio_bank { static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq) { - return bank->chip.base + gpio_irq; -} - -static int omap_gpio_to_irq(struct gpio_chip *chip, unsigned offset) -{ - struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip); - - return irq_find_mapping(bank->domain, offset); + return gpio_irq - bank->irq_base + bank->chip.base; } static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input) @@ -435,7 +429,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type) #endif if (!gpio) - gpio = irq_to_gpio(bank, d->hwirq); + gpio = irq_to_gpio(bank, d->irq); if (type & ~IRQ_TYPE_SENSE_MASK) return -EINVAL; @@ -588,7 +582,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) static int gpio_wake_enable(struct irq_data *d, unsigned int enable) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); return _set_gpio_wakeup(bank, gpio, enable); } @@ -688,7 +682,7 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) { void __iomem *isr_reg = NULL; u32 isr; - unsigned int bit; + unsigned int gpio_irq, gpio_index; struct gpio_bank *bank; int unmasked = 0; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -729,9 +723,14 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) if (!isr) break; - while (isr) { - bit = __ffs(isr); - isr &= ~(1 << bit); + gpio_irq = bank->irq_base; + for (; isr != 0; isr >>= 1, gpio_irq++) { + int gpio = irq_to_gpio(bank, gpio_irq); + + if (!(isr & 1)) + continue; + + gpio_index = GPIO_INDEX(bank, gpio); /* * Some chips can't respond to both rising and falling @@ -740,10 +739,10 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) * to respond to the IRQ for the opposite direction. * This will be indicated in the bank toggle_mask. */ - if (bank->toggle_mask & (1 << bit)) - _toggle_gpio_edge_triggering(bank, bit); + if (bank->toggle_mask & (1 << gpio_index)) + _toggle_gpio_edge_triggering(bank, gpio_index); - generic_handle_irq(irq_find_mapping(bank->domain, bit)); + generic_handle_irq(gpio_irq); } } /* if bank has any level sensitive GPIO pin interrupt @@ -759,7 +758,7 @@ exit: static void gpio_irq_shutdown(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned long flags; spin_lock_irqsave(&bank->lock, flags); @@ -770,7 +769,7 @@ static void gpio_irq_shutdown(struct irq_data *d) static void gpio_ack_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); _clear_gpio_irqstatus(bank, gpio); } @@ -778,7 +777,7 @@ static void gpio_ack_irq(struct irq_data *d) static void gpio_mask_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned long flags; spin_lock_irqsave(&bank->lock, flags); @@ -790,7 +789,7 @@ static void gpio_mask_irq(struct irq_data *d) static void gpio_unmask_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned int irq_mask = GPIO_BIT(bank, gpio); u32 trigger = irqd_get_trigger_type(d); unsigned long flags; @@ -956,6 +955,14 @@ static void gpio_set(struct gpio_chip *chip, unsigned offset, int value) spin_unlock_irqrestore(&bank->lock, flags); } +static int gpio_2irq(struct gpio_chip *chip, unsigned offset) +{ + struct gpio_bank *bank; + + bank = container_of(chip, struct gpio_bank, chip); + return bank->irq_base + offset; +} + /*---------------------------------------------------------------------*/ static void __init omap_gpio_show_rev(struct gpio_bank *bank) @@ -1052,7 +1059,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) bank->chip.direction_output = gpio_output; bank->chip.set_debounce = gpio_debounce; bank->chip.set = gpio_set; - bank->chip.to_irq = omap_gpio_to_irq; + bank->chip.to_irq = gpio_2irq; if (bank->is_mpuio) { bank->chip.label = "mpuio"; if (bank->regs->wkup_en) @@ -1067,16 +1074,15 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) gpiochip_add(&bank->chip); - for (j = 0; j < bank->width; j++) { - int irq = irq_create_mapping(bank->domain, j); - irq_set_lockdep_class(irq, &gpio_lock_class); - irq_set_chip_data(irq, bank); + for (j = bank->irq_base; j < bank->irq_base + bank->width; j++) { + irq_set_lockdep_class(j, &gpio_lock_class); + irq_set_chip_data(j, bank); if (bank->is_mpuio) { - omap_mpuio_alloc_gc(bank, irq, bank->width); + omap_mpuio_alloc_gc(bank, j, bank->width); } else { - irq_set_chip_and_handler(irq, &gpio_irq_chip, - handle_simple_irq); - set_irq_flags(irq, IRQF_VALID); + irq_set_chip(j, &gpio_irq_chip); + irq_set_handler(j, handle_simple_irq); + set_irq_flags(j, IRQF_VALID); } } irq_set_chained_handler(bank->irq, gpio_irq_handler); @@ -1131,10 +1137,14 @@ static int omap_gpio_probe(struct platform_device *pdev) } - bank->domain = irq_domain_add_linear(node, bank->width, - &irq_domain_simple_ops, NULL); - if (!bank->domain) + bank->irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (bank->irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); return -ENODEV; + } + + bank->domain = irq_domain_add_legacy(node, bank->width, bank->irq_base, + 0, &irq_domain_simple_ops, NULL); if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-16 21:00 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-16 21:00 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > The error is coming from regmap code. According to git bisect, it is > > caused by: > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > Author: Jon Hunter <jon-hunter@ti.com> > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > crafting a manual revert, so any fix proposals/ideas are welcome... > > Hmm this might be a bit trickier to fix. Obviously the real solution > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > For the -rc cycle, it might be possible to fix this by adding a > different irq_to_gpio() and gpio_to_irq() functions for omap1. The commit reverts cleanly if we also revert 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt service routine), which seems to be just some minor optimization. The result is below, and with it 770 works again. A. diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 2050891..a9b5813 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -52,6 +52,7 @@ struct gpio_bank { struct list_head node; void __iomem *base; u16 irq; + int irq_base; struct irq_domain *domain; u32 non_wakeup_gpios; u32 enabled_non_wakeup_gpios; @@ -87,14 +88,7 @@ struct gpio_bank { static int irq_to_gpio(struct gpio_bank *bank, unsigned int gpio_irq) { - return bank->chip.base + gpio_irq; -} - -static int omap_gpio_to_irq(struct gpio_chip *chip, unsigned offset) -{ - struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip); - - return irq_find_mapping(bank->domain, offset); + return gpio_irq - bank->irq_base + bank->chip.base; } static void _set_gpio_direction(struct gpio_bank *bank, int gpio, int is_input) @@ -435,7 +429,7 @@ static int gpio_irq_type(struct irq_data *d, unsigned type) #endif if (!gpio) - gpio = irq_to_gpio(bank, d->hwirq); + gpio = irq_to_gpio(bank, d->irq); if (type & ~IRQ_TYPE_SENSE_MASK) return -EINVAL; @@ -588,7 +582,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) static int gpio_wake_enable(struct irq_data *d, unsigned int enable) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); return _set_gpio_wakeup(bank, gpio, enable); } @@ -688,7 +682,7 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) { void __iomem *isr_reg = NULL; u32 isr; - unsigned int bit; + unsigned int gpio_irq, gpio_index; struct gpio_bank *bank; int unmasked = 0; struct irq_chip *chip = irq_desc_get_chip(desc); @@ -729,9 +723,14 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) if (!isr) break; - while (isr) { - bit = __ffs(isr); - isr &= ~(1 << bit); + gpio_irq = bank->irq_base; + for (; isr != 0; isr >>= 1, gpio_irq++) { + int gpio = irq_to_gpio(bank, gpio_irq); + + if (!(isr & 1)) + continue; + + gpio_index = GPIO_INDEX(bank, gpio); /* * Some chips can't respond to both rising and falling @@ -740,10 +739,10 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) * to respond to the IRQ for the opposite direction. * This will be indicated in the bank toggle_mask. */ - if (bank->toggle_mask & (1 << bit)) - _toggle_gpio_edge_triggering(bank, bit); + if (bank->toggle_mask & (1 << gpio_index)) + _toggle_gpio_edge_triggering(bank, gpio_index); - generic_handle_irq(irq_find_mapping(bank->domain, bit)); + generic_handle_irq(gpio_irq); } } /* if bank has any level sensitive GPIO pin interrupt @@ -759,7 +758,7 @@ exit: static void gpio_irq_shutdown(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned long flags; spin_lock_irqsave(&bank->lock, flags); @@ -770,7 +769,7 @@ static void gpio_irq_shutdown(struct irq_data *d) static void gpio_ack_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); _clear_gpio_irqstatus(bank, gpio); } @@ -778,7 +777,7 @@ static void gpio_ack_irq(struct irq_data *d) static void gpio_mask_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned long flags; spin_lock_irqsave(&bank->lock, flags); @@ -790,7 +789,7 @@ static void gpio_mask_irq(struct irq_data *d) static void gpio_unmask_irq(struct irq_data *d) { struct gpio_bank *bank = irq_data_get_irq_chip_data(d); - unsigned int gpio = irq_to_gpio(bank, d->hwirq); + unsigned int gpio = irq_to_gpio(bank, d->irq); unsigned int irq_mask = GPIO_BIT(bank, gpio); u32 trigger = irqd_get_trigger_type(d); unsigned long flags; @@ -956,6 +955,14 @@ static void gpio_set(struct gpio_chip *chip, unsigned offset, int value) spin_unlock_irqrestore(&bank->lock, flags); } +static int gpio_2irq(struct gpio_chip *chip, unsigned offset) +{ + struct gpio_bank *bank; + + bank = container_of(chip, struct gpio_bank, chip); + return bank->irq_base + offset; +} + /*---------------------------------------------------------------------*/ static void __init omap_gpio_show_rev(struct gpio_bank *bank) @@ -1052,7 +1059,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) bank->chip.direction_output = gpio_output; bank->chip.set_debounce = gpio_debounce; bank->chip.set = gpio_set; - bank->chip.to_irq = omap_gpio_to_irq; + bank->chip.to_irq = gpio_2irq; if (bank->is_mpuio) { bank->chip.label = "mpuio"; if (bank->regs->wkup_en) @@ -1067,16 +1074,15 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) gpiochip_add(&bank->chip); - for (j = 0; j < bank->width; j++) { - int irq = irq_create_mapping(bank->domain, j); - irq_set_lockdep_class(irq, &gpio_lock_class); - irq_set_chip_data(irq, bank); + for (j = bank->irq_base; j < bank->irq_base + bank->width; j++) { + irq_set_lockdep_class(j, &gpio_lock_class); + irq_set_chip_data(j, bank); if (bank->is_mpuio) { - omap_mpuio_alloc_gc(bank, irq, bank->width); + omap_mpuio_alloc_gc(bank, j, bank->width); } else { - irq_set_chip_and_handler(irq, &gpio_irq_chip, - handle_simple_irq); - set_irq_flags(irq, IRQF_VALID); + irq_set_chip(j, &gpio_irq_chip); + irq_set_handler(j, handle_simple_irq); + set_irq_flags(j, IRQF_VALID); } } irq_set_chained_handler(bank->irq, gpio_irq_handler); @@ -1131,10 +1137,14 @@ static int omap_gpio_probe(struct platform_device *pdev) } - bank->domain = irq_domain_add_linear(node, bank->width, - &irq_domain_simple_ops, NULL); - if (!bank->domain) + bank->irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (bank->irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); return -ENODEV; + } + + bank->domain = irq_domain_add_legacy(node, bank->width, bank->irq_base, + 0, &irq_domain_simple_ops, NULL); if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-16 21:00 ` Aaro Koskinen @ 2013-05-16 21:44 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-16 21:44 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > The error is coming from regmap code. According to git bisect, it is > > > caused by: > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > Author: Jon Hunter <jon-hunter@ti.com> > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > For the -rc cycle, it might be possible to fix this by adding a > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > The commit reverts cleanly if we also revert > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > service routine), which seems to be just some minor optimization. The > result is below, and with it 770 works again. Hmm in this case it seems that we should just fix it rather than go back to the old code, so let's take a look at that first. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-16 21:44 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-16 21:44 UTC (permalink / raw) To: linux-arm-kernel * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > The error is coming from regmap code. According to git bisect, it is > > > caused by: > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > Author: Jon Hunter <jon-hunter@ti.com> > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > For the -rc cycle, it might be possible to fix this by adding a > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > The commit reverts cleanly if we also revert > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > service routine), which seems to be just some minor optimization. The > result is below, and with it 770 works again. Hmm in this case it seems that we should just fix it rather than go back to the old code, so let's take a look at that first. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-16 21:44 ` Tony Lindgren @ 2013-05-20 17:46 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-20 17:46 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely * Tony Lindgren <tony@atomide.com> [130516 14:50]: > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > caused by: > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > The commit reverts cleanly if we also revert > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > service routine), which seems to be just some minor optimization. The > > result is below, and with it 770 works again. > > Hmm in this case it seems that we should just fix it rather than go back > to the old code, so let's take a look at that first. Does the following fix it for you or do we need to fix something else there too? Regards, Tony --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) const struct omap_gpio_platform_data *pdata; struct resource *res; struct gpio_bank *bank; + int irq_base; match = of_match_device(of_match_ptr(omap_gpio_match), dev); @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) pdata->get_context_loss_count; } - - bank->domain = irq_domain_add_linear(node, bank->width, - &irq_domain_simple_ops, NULL); - if (!bank->domain) + /* + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop + * irq_alloc_descs() and irq_domain_add_legacy() and just do: + * + * bank->domain = irq_domain_add_linear(node, bank->width, + * &irq_domain_simple_ops, NULL); + * if (!bank->domain) + * return -ENODEV; + */ + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); return -ENODEV; + } + + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, + 0, &irq_domain_simple_ops, NULL); if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-20 17:46 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-05-20 17:46 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [130516 14:50]: > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > caused by: > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > The commit reverts cleanly if we also revert > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > service routine), which seems to be just some minor optimization. The > > result is below, and with it 770 works again. > > Hmm in this case it seems that we should just fix it rather than go back > to the old code, so let's take a look at that first. Does the following fix it for you or do we need to fix something else there too? Regards, Tony --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) const struct omap_gpio_platform_data *pdata; struct resource *res; struct gpio_bank *bank; + int irq_base; match = of_match_device(of_match_ptr(omap_gpio_match), dev); @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) pdata->get_context_loss_count; } - - bank->domain = irq_domain_add_linear(node, bank->width, - &irq_domain_simple_ops, NULL); - if (!bank->domain) + /* + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop + * irq_alloc_descs() and irq_domain_add_legacy() and just do: + * + * bank->domain = irq_domain_add_linear(node, bank->width, + * &irq_domain_simple_ops, NULL); + * if (!bank->domain) + * return -ENODEV; + */ + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); return -ENODEV; + } + + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, + 0, &irq_domain_simple_ops, NULL); if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-20 17:46 ` Tony Lindgren @ 2013-05-21 17:39 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-21 17:39 UTC (permalink / raw) To: Tony Lindgren; +Cc: linux-arm-kernel, linux-omap, Jon Hunter, Grant Likely On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > caused by: > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > The commit reverts cleanly if we also revert > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > service routine), which seems to be just some minor optimization. The > > > result is below, and with it 770 works again. > > > > Hmm in this case it seems that we should just fix it rather than go back > > to the old code, so let's take a look at that first. > > Does the following fix it for you or do we need to fix something else > there too? Thanks, that fixes Retu probe on 770. Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> A. > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > + int irq_base; > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > - > - bank->domain = irq_domain_add_linear(node, bank->width, > - &irq_domain_simple_ops, NULL); > - if (!bank->domain) > + /* > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > + * > + * bank->domain = irq_domain_add_linear(node, bank->width, > + * &irq_domain_simple_ops, NULL); > + * if (!bank->domain) > + * return -ENODEV; > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > return -ENODEV; > + } > + > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-21 17:39 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-21 17:39 UTC (permalink / raw) To: linux-arm-kernel On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > caused by: > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > The commit reverts cleanly if we also revert > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > service routine), which seems to be just some minor optimization. The > > > result is below, and with it 770 works again. > > > > Hmm in this case it seems that we should just fix it rather than go back > > to the old code, so let's take a look at that first. > > Does the following fix it for you or do we need to fix something else > there too? Thanks, that fixes Retu probe on 770. Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> A. > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > + int irq_base; > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > - > - bank->domain = irq_domain_add_linear(node, bank->width, > - &irq_domain_simple_ops, NULL); > - if (!bank->domain) > + /* > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > + * > + * bank->domain = irq_domain_add_linear(node, bank->width, > + * &irq_domain_simple_ops, NULL); > + * if (!bank->domain) > + * return -ENODEV; > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > return -ENODEV; > + } > + > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-21 17:39 ` Aaro Koskinen @ 2013-05-21 19:37 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-21 19:37 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 21/05/13 18:39, Aaro Koskinen wrote: > On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>> >>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>> >>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>> caused by: >>>>>> >>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>> >>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>> >>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>> >>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>> >>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>> >>>> The commit reverts cleanly if we also revert >>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>> service routine), which seems to be just some minor optimization. The >>>> result is below, and with it 770 works again. >>> >>> Hmm in this case it seems that we should just fix it rather than go back >>> to the old code, so let's take a look at that first. >> >> Does the following fix it for you or do we need to fix something else >> there too? > > Thanks, that fixes Retu probe on 770. Sorry for not responding sooner, but I have been moving. >From looking at the code it appears that the regmap_add_irq_chip() is failing in the retu driver. I am not sure if this will work, but have you tried making the following change to the retu driver so that it also uses irq_domain_add_linear() as well? Just a thought ... Cheers Jon diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c index a183098..7ad8cd4 100644 --- a/drivers/mfd/retu-mfd.c +++ b/drivers/mfd/retu-mfd.c @@ -267,7 +267,7 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret < 0) return ret; - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, rdat->irq_chip, &rdev->irq_data); if (ret < 0) return ret; ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-21 19:37 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-21 19:37 UTC (permalink / raw) To: linux-arm-kernel On 21/05/13 18:39, Aaro Koskinen wrote: > On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>> >>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>> >>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>> caused by: >>>>>> >>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>> >>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>> >>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>> >>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>> >>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>> >>>> The commit reverts cleanly if we also revert >>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>> service routine), which seems to be just some minor optimization. The >>>> result is below, and with it 770 works again. >>> >>> Hmm in this case it seems that we should just fix it rather than go back >>> to the old code, so let's take a look at that first. >> >> Does the following fix it for you or do we need to fix something else >> there too? > > Thanks, that fixes Retu probe on 770. Sorry for not responding sooner, but I have been moving. >From looking at the code it appears that the regmap_add_irq_chip() is failing in the retu driver. I am not sure if this will work, but have you tried making the following change to the retu driver so that it also uses irq_domain_add_linear() as well? Just a thought ... Cheers Jon diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c index a183098..7ad8cd4 100644 --- a/drivers/mfd/retu-mfd.c +++ b/drivers/mfd/retu-mfd.c @@ -267,7 +267,7 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret < 0) return ret; - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, rdat->irq_chip, &rdev->irq_data); if (ret < 0) return ret; ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-21 19:37 ` Jon Hunter @ 2013-05-22 21:20 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-22 21:20 UTC (permalink / raw) To: Jon Hunter Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > On 21/05/13 18:39, Aaro Koskinen wrote: > > On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>> > >>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>> > >>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>> caused by: > >>>>>> > >>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>> > >>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>> > >>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>> > >>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>> > >>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>> > >>>> The commit reverts cleanly if we also revert > >>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>> service routine), which seems to be just some minor optimization. The > >>>> result is below, and with it 770 works again. > >>> > >>> Hmm in this case it seems that we should just fix it rather than go back > >>> to the old code, so let's take a look at that first. > >> > >> Does the following fix it for you or do we need to fix something else > >> there too? > > > > Thanks, that fixes Retu probe on 770. > > Sorry for not responding sooner, but I have been moving. > > From looking at the code it appears that the regmap_add_irq_chip() > is failing in the retu driver. I am not sure if this will work, > but have you tried making the following change to the retu driver > so that it also uses irq_domain_add_linear() as well? Just a thought ... This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Also other drivers report GPIO IRQ issues later in the boot, e.g. [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) [ 3.923706] No interrupt for UART wake GPIO: 37 With Tony's patch (without any Retu modifications), the boot is clean. So I guess gpio-omap fix is needed. A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..7ad8cd4 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,7 +267,7 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-22 21:20 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-22 21:20 UTC (permalink / raw) To: linux-arm-kernel On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > On 21/05/13 18:39, Aaro Koskinen wrote: > > On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>> > >>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>> > >>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>> caused by: > >>>>>> > >>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>> > >>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>> > >>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>> > >>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>> > >>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>> > >>>> The commit reverts cleanly if we also revert > >>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>> service routine), which seems to be just some minor optimization. The > >>>> result is below, and with it 770 works again. > >>> > >>> Hmm in this case it seems that we should just fix it rather than go back > >>> to the old code, so let's take a look at that first. > >> > >> Does the following fix it for you or do we need to fix something else > >> there too? > > > > Thanks, that fixes Retu probe on 770. > > Sorry for not responding sooner, but I have been moving. > > From looking at the code it appears that the regmap_add_irq_chip() > is failing in the retu driver. I am not sure if this will work, > but have you tried making the following change to the retu driver > so that it also uses irq_domain_add_linear() as well? Just a thought ... This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Also other drivers report GPIO IRQ issues later in the boot, e.g. [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) [ 3.923706] No interrupt for UART wake GPIO: 37 With Tony's patch (without any Retu modifications), the boot is clean. So I guess gpio-omap fix is needed. A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..7ad8cd4 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,7 +267,7 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-22 21:20 ` Aaro Koskinen @ 2013-05-23 19:02 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-23 19:02 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 22/05/13 22:20, Aaro Koskinen wrote: > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >> On 21/05/13 18:39, Aaro Koskinen wrote: >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>> >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>> >>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>> caused by: >>>>>>>> >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>> >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>> >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>> >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>> >>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>> >>>>>> The commit reverts cleanly if we also revert >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>> service routine), which seems to be just some minor optimization. The >>>>>> result is below, and with it 770 works again. >>>>> >>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>> to the old code, so let's take a look at that first. >>>> >>>> Does the following fix it for you or do we need to fix something else >>>> there too? >>> >>> Thanks, that fixes Retu probe on 770. >> >> Sorry for not responding sooner, but I have been moving. >> >> From looking at the code it appears that the regmap_add_irq_chip() >> is failing in the retu driver. I am not sure if this will work, >> but have you tried making the following change to the retu driver >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Sorry, there is another change needed. Can you try ... diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c index a183098..9080cd6 100644 --- a/drivers/mfd/retu-mfd.c +++ b/drivers/mfd/retu-mfd.c @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret < 0) return ret; - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, rdat->irq_chip, &rdev->irq_data); if (ret < 0) return ret; ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, - NULL, regmap_irq_chip_get_base(rdev->irq_data), - NULL); + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); if (ret < 0) { regmap_del_irq_chip(i2c->irq, rdev->irq_data); return ret; > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > [ 3.923706] No interrupt for UART wake GPIO: 37 Looks like the gpio is just conflicting with the RETU driver. > With Tony's patch (without any Retu modifications), the boot is clean. So > I guess gpio-omap fix is needed. Ideally it would be good if the RETU can use linear domains and then may be this can be avoided. Cheers Jon ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-23 19:02 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-23 19:02 UTC (permalink / raw) To: linux-arm-kernel On 22/05/13 22:20, Aaro Koskinen wrote: > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >> On 21/05/13 18:39, Aaro Koskinen wrote: >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>> >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>> >>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>> caused by: >>>>>>>> >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>> >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>> >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>> >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>> >>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>> >>>>>> The commit reverts cleanly if we also revert >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>> service routine), which seems to be just some minor optimization. The >>>>>> result is below, and with it 770 works again. >>>>> >>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>> to the old code, so let's take a look at that first. >>>> >>>> Does the following fix it for you or do we need to fix something else >>>> there too? >>> >>> Thanks, that fixes Retu probe on 770. >> >> Sorry for not responding sooner, but I have been moving. >> >> From looking at the code it appears that the regmap_add_irq_chip() >> is failing in the retu driver. I am not sure if this will work, >> but have you tried making the following change to the retu driver >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. Sorry, there is another change needed. Can you try ... diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c index a183098..9080cd6 100644 --- a/drivers/mfd/retu-mfd.c +++ b/drivers/mfd/retu-mfd.c @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) if (ret < 0) return ret; - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, rdat->irq_chip, &rdev->irq_data); if (ret < 0) return ret; ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, - NULL, regmap_irq_chip_get_base(rdev->irq_data), - NULL); + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); if (ret < 0) { regmap_del_irq_chip(i2c->irq, rdev->irq_data); return ret; > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > [ 3.923706] No interrupt for UART wake GPIO: 37 Looks like the gpio is just conflicting with the RETU driver. > With Tony's patch (without any Retu modifications), the boot is clean. So > I guess gpio-omap fix is needed. Ideally it would be good if the RETU can use linear domains and then may be this can be avoided. Cheers Jon ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-23 19:02 ` Jon Hunter @ 2013-05-23 20:13 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-23 20:13 UTC (permalink / raw) To: Jon Hunter Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: > On 22/05/13 22:20, Aaro Koskinen wrote: > > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > >> On 21/05/13 18:39, Aaro Koskinen wrote: > >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>>>> > >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>>>> > >>>>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>>>> caused by: > >>>>>>>> > >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>>>> > >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>>>> > >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>>>> > >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>>>> > >>>>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>>>> > >>>>>> The commit reverts cleanly if we also revert > >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>>>> service routine), which seems to be just some minor optimization. The > >>>>>> result is below, and with it 770 works again. > >>>>> > >>>>> Hmm in this case it seems that we should just fix it rather than go back > >>>>> to the old code, so let's take a look at that first. > >>>> > >>>> Does the following fix it for you or do we need to fix something else > >>>> there too? > >>> > >>> Thanks, that fixes Retu probe on 770. > >> > >> Sorry for not responding sooner, but I have been moving. > >> > >> From looking at the code it appears that the regmap_add_irq_chip() > >> is failing in the retu driver. I am not sure if this will work, > >> but have you tried making the following change to the retu driver > >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. > > Sorry, there is another change needed. Can you try ... I will try this. However, I would also like to point out that Retu works fine on N800/N810 (OMAP2). If the problem is in Retu, why only OMAP1 is affected? A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..9080cd6 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > > ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, > - NULL, regmap_irq_chip_get_base(rdev->irq_data), > - NULL); > + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); > if (ret < 0) { > regmap_del_irq_chip(i2c->irq, rdev->irq_data); > return ret; > > > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > > [ 3.923706] No interrupt for UART wake GPIO: 37 > > Looks like the gpio is just conflicting with the RETU driver. > > > With Tony's patch (without any Retu modifications), the boot is clean. So > > I guess gpio-omap fix is needed. > > Ideally it would be good if the RETU can use linear domains and then may be this > can be avoided. > > Cheers > Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-23 20:13 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-23 20:13 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: > On 22/05/13 22:20, Aaro Koskinen wrote: > > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > >> On 21/05/13 18:39, Aaro Koskinen wrote: > >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>>>> > >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>>>> > >>>>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>>>> caused by: > >>>>>>>> > >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>>>> > >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>>>> > >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>>>> > >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>>>> > >>>>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>>>> > >>>>>> The commit reverts cleanly if we also revert > >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>>>> service routine), which seems to be just some minor optimization. The > >>>>>> result is below, and with it 770 works again. > >>>>> > >>>>> Hmm in this case it seems that we should just fix it rather than go back > >>>>> to the old code, so let's take a look at that first. > >>>> > >>>> Does the following fix it for you or do we need to fix something else > >>>> there too? > >>> > >>> Thanks, that fixes Retu probe on 770. > >> > >> Sorry for not responding sooner, but I have been moving. > >> > >> From looking at the code it appears that the regmap_add_irq_chip() > >> is failing in the retu driver. I am not sure if this will work, > >> but have you tried making the following change to the retu driver > >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. > > Sorry, there is another change needed. Can you try ... I will try this. However, I would also like to point out that Retu works fine on N800/N810 (OMAP2). If the problem is in Retu, why only OMAP1 is affected? A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..9080cd6 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > > ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, > - NULL, regmap_irq_chip_get_base(rdev->irq_data), > - NULL); > + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); > if (ret < 0) { > regmap_del_irq_chip(i2c->irq, rdev->irq_data); > return ret; > > > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > > [ 3.923706] No interrupt for UART wake GPIO: 37 > > Looks like the gpio is just conflicting with the RETU driver. > > > With Tony's patch (without any Retu modifications), the boot is clean. So > > I guess gpio-omap fix is needed. > > Ideally it would be good if the RETU can use linear domains and then may be this > can be avoided. > > Cheers > Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-23 20:13 ` Aaro Koskinen @ 2013-05-28 18:41 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-28 18:41 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 23/05/13 21:13, Aaro Koskinen wrote: > On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: >> On 22/05/13 22:20, Aaro Koskinen wrote: >>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >>>> On 21/05/13 18:39, Aaro Koskinen wrote: >>>>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>>>> >>>>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>>>> >>>>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>>>> caused by: >>>>>>>>>> >>>>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>>>> >>>>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>>>> >>>>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>>>> >>>>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>>>> >>>>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>>>> >>>>>>>> The commit reverts cleanly if we also revert >>>>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>>>> service routine), which seems to be just some minor optimization. The >>>>>>>> result is below, and with it 770 works again. >>>>>>> >>>>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>>>> to the old code, so let's take a look at that first. >>>>>> >>>>>> Does the following fix it for you or do we need to fix something else >>>>>> there too? >>>>> >>>>> Thanks, that fixes Retu probe on 770. >>>> >>>> Sorry for not responding sooner, but I have been moving. >>>> >>>> From looking at the code it appears that the regmap_add_irq_chip() >>>> is failing in the retu driver. I am not sure if this will work, >>>> but have you tried making the following change to the retu driver >>>> so that it also uses irq_domain_add_linear() as well? Just a thought ... >>> >>> This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. >> >> Sorry, there is another change needed. Can you try ... > > I will try this. However, I would also like to point out that Retu works > fine on N800/N810 (OMAP2). If the problem is in Retu, why only OMAP1 > is affected? The problem is not with retu or the gpio driver per-se, its just that now they are conflicting because the way the irq domains are being allocated. So probably just getting lucky on the n8xx. I had tested on omap1-4 and had not seen any problems, but none of my boards used the retu driver. Cheers Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-28 18:41 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-28 18:41 UTC (permalink / raw) To: linux-arm-kernel On 23/05/13 21:13, Aaro Koskinen wrote: > On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: >> On 22/05/13 22:20, Aaro Koskinen wrote: >>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >>>> On 21/05/13 18:39, Aaro Koskinen wrote: >>>>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>>>> >>>>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>>>> >>>>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>>>> caused by: >>>>>>>>>> >>>>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>>>> >>>>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>>>> >>>>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>>>> >>>>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>>>> >>>>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>>>> >>>>>>>> The commit reverts cleanly if we also revert >>>>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>>>> service routine), which seems to be just some minor optimization. The >>>>>>>> result is below, and with it 770 works again. >>>>>>> >>>>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>>>> to the old code, so let's take a look at that first. >>>>>> >>>>>> Does the following fix it for you or do we need to fix something else >>>>>> there too? >>>>> >>>>> Thanks, that fixes Retu probe on 770. >>>> >>>> Sorry for not responding sooner, but I have been moving. >>>> >>>> From looking at the code it appears that the regmap_add_irq_chip() >>>> is failing in the retu driver. I am not sure if this will work, >>>> but have you tried making the following change to the retu driver >>>> so that it also uses irq_domain_add_linear() as well? Just a thought ... >>> >>> This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. >> >> Sorry, there is another change needed. Can you try ... > > I will try this. However, I would also like to point out that Retu works > fine on N800/N810 (OMAP2). If the problem is in Retu, why only OMAP1 > is affected? The problem is not with retu or the gpio driver per-se, its just that now they are conflicting because the way the irq domains are being allocated. So probably just getting lucky on the n8xx. I had tested on omap1-4 and had not seen any problems, but none of my boards used the retu driver. Cheers Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-23 19:02 ` Jon Hunter @ 2013-05-26 19:07 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-26 19:07 UTC (permalink / raw) To: Jon Hunter Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: > On 22/05/13 22:20, Aaro Koskinen wrote: > > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > >> On 21/05/13 18:39, Aaro Koskinen wrote: > >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>>>> > >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>>>> > >>>>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>>>> caused by: > >>>>>>>> > >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>>>> > >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>>>> > >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>>>> > >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>>>> > >>>>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>>>> > >>>>>> The commit reverts cleanly if we also revert > >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>>>> service routine), which seems to be just some minor optimization. The > >>>>>> result is below, and with it 770 works again. > >>>>> > >>>>> Hmm in this case it seems that we should just fix it rather than go back > >>>>> to the old code, so let's take a look at that first. > >>>> > >>>> Does the following fix it for you or do we need to fix something else > >>>> there too? > >>> > >>> Thanks, that fixes Retu probe on 770. > >> > >> Sorry for not responding sooner, but I have been moving. > >> > >> From looking at the code it appears that the regmap_add_irq_chip() > >> is failing in the retu driver. I am not sure if this will work, > >> but have you tried making the following change to the retu driver > >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. > > Sorry, there is another change needed. Can you try ... I don't see much improvement with this. Although Retu probe succeeds, genirq error logs are still there. Also none of the GPIO irqs used by other drivers seem to be working at all, e.g. touchscreen. A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..9080cd6 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > > ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, > - NULL, regmap_irq_chip_get_base(rdev->irq_data), > - NULL); > + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); > if (ret < 0) { > regmap_del_irq_chip(i2c->irq, rdev->irq_data); > return ret; > > > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > > [ 3.923706] No interrupt for UART wake GPIO: 37 > > Looks like the gpio is just conflicting with the RETU driver. > > > With Tony's patch (without any Retu modifications), the boot is clean. So > > I guess gpio-omap fix is needed. > > Ideally it would be good if the RETU can use linear domains and then may be this > can be avoided. > > Cheers > Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-26 19:07 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-26 19:07 UTC (permalink / raw) To: linux-arm-kernel On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: > On 22/05/13 22:20, Aaro Koskinen wrote: > > On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: > >> On 21/05/13 18:39, Aaro Koskinen wrote: > >>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: > >>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: > >>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > >>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > >>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > >>>>>>>> > >>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > >>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > >>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > >>>>>>>> > >>>>>>>> The error is coming from regmap code. According to git bisect, it is > >>>>>>>> caused by: > >>>>>>>> > >>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > >>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> > >>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 > >>>>>>>> > >>>>>>>> gpio/omap: convert gpio irq domain to linear mapping > >>>>>>>> > >>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried > >>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... > >>>>>>> > >>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution > >>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. > >>>>>>> > >>>>>>> For the -rc cycle, it might be possible to fix this by adding a > >>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. > >>>>>> > >>>>>> The commit reverts cleanly if we also revert > >>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > >>>>>> service routine), which seems to be just some minor optimization. The > >>>>>> result is below, and with it 770 works again. > >>>>> > >>>>> Hmm in this case it seems that we should just fix it rather than go back > >>>>> to the old code, so let's take a look at that first. > >>>> > >>>> Does the following fix it for you or do we need to fix something else > >>>> there too? > >>> > >>> Thanks, that fixes Retu probe on 770. > >> > >> Sorry for not responding sooner, but I have been moving. > >> > >> From looking at the code it appears that the regmap_add_irq_chip() > >> is failing in the retu driver. I am not sure if this will work, > >> but have you tried making the following change to the retu driver > >> so that it also uses irq_domain_add_linear() as well? Just a thought ... > > > > This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. > > Sorry, there is another change needed. Can you try ... I don't see much improvement with this. Although Retu probe succeeds, genirq error logs are still there. Also none of the GPIO irqs used by other drivers seem to be working at all, e.g. touchscreen. A. > diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c > index a183098..9080cd6 100644 > --- a/drivers/mfd/retu-mfd.c > +++ b/drivers/mfd/retu-mfd.c > @@ -267,14 +267,13 @@ static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id) > if (ret < 0) > return ret; > > - ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, -1, > + ret = regmap_add_irq_chip(rdev->regmap, i2c->irq, IRQF_ONESHOT, 0, > rdat->irq_chip, &rdev->irq_data); > if (ret < 0) > return ret; > > ret = mfd_add_devices(rdev->dev, -1, rdat->children, rdat->nchildren, > - NULL, regmap_irq_chip_get_base(rdev->irq_data), > - NULL); > + NULL, 0, regmap_irq_get_domain(rdev->irq_data)); > if (ret < 0) { > regmap_del_irq_chip(i2c->irq, rdev->irq_data); > return ret; > > > Also other drivers report GPIO IRQ issues later in the boot, e.g. > > > > [ 3.907928] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00002000 (RETU) > > [ 3.923706] No interrupt for UART wake GPIO: 37 > > Looks like the gpio is just conflicting with the RETU driver. > > > With Tony's patch (without any Retu modifications), the boot is clean. So > > I guess gpio-omap fix is needed. > > Ideally it would be good if the RETU can use linear domains and then may be this > can be avoided. > > Cheers > Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-26 19:07 ` Aaro Koskinen @ 2013-05-28 18:42 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-28 18:42 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 26/05/13 20:07, Aaro Koskinen wrote: > On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: >> On 22/05/13 22:20, Aaro Koskinen wrote: >>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >>>> On 21/05/13 18:39, Aaro Koskinen wrote: >>>>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>>>> >>>>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>>>> >>>>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>>>> caused by: >>>>>>>>>> >>>>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>>>> >>>>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>>>> >>>>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>>>> >>>>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>>>> >>>>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>>>> >>>>>>>> The commit reverts cleanly if we also revert >>>>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>>>> service routine), which seems to be just some minor optimization. The >>>>>>>> result is below, and with it 770 works again. >>>>>>> >>>>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>>>> to the old code, so let's take a look at that first. >>>>>> >>>>>> Does the following fix it for you or do we need to fix something else >>>>>> there too? >>>>> >>>>> Thanks, that fixes Retu probe on 770. >>>> >>>> Sorry for not responding sooner, but I have been moving. >>>> >>>> From looking at the code it appears that the regmap_add_irq_chip() >>>> is failing in the retu driver. I am not sure if this will work, >>>> but have you tried making the following change to the retu driver >>>> so that it also uses irq_domain_add_linear() as well? Just a thought ... >>> >>> This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. >> >> Sorry, there is another change needed. Can you try ... > > I don't see much improvement with this. Although Retu probe succeeds, > genirq error logs are still there. Also none of the GPIO irqs used by > other drivers seem to be working at all, e.g. touchscreen. Care to share the log? Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-28 18:42 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-28 18:42 UTC (permalink / raw) To: linux-arm-kernel On 26/05/13 20:07, Aaro Koskinen wrote: > On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote: >> On 22/05/13 22:20, Aaro Koskinen wrote: >>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote: >>>> On 21/05/13 18:39, Aaro Koskinen wrote: >>>>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote: >>>>>> * Tony Lindgren <tony@atomide.com> [130516 14:50]: >>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >>>>>>>> On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >>>>>>>>> * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >>>>>>>>>> I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >>>>>>>>>> >>>>>>>>>> [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >>>>>>>>>> [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >>>>>>>>>> [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >>>>>>>>>> >>>>>>>>>> The error is coming from regmap code. According to git bisect, it is >>>>>>>>>> caused by: >>>>>>>>>> >>>>>>>>>> commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >>>>>>>>>> Author: Jon Hunter <jon-hunter@ti.com> >>>>>>>>>> Date: Fri Mar 1 11:22:47 2013 -0600 >>>>>>>>>> >>>>>>>>>> gpio/omap: convert gpio irq domain to linear mapping >>>>>>>>>> >>>>>>>>>> The commit does not anymore revert cleanly, and I haven't yet tried >>>>>>>>>> crafting a manual revert, so any fix proposals/ideas are welcome... >>>>>>>>> >>>>>>>>> Hmm this might be a bit trickier to fix. Obviously the real solution >>>>>>>>> is to convert omap1 to SPARSE_IRQ like we did for omap2+. >>>>>>>>> >>>>>>>>> For the -rc cycle, it might be possible to fix this by adding a >>>>>>>>> different irq_to_gpio() and gpio_to_irq() functions for omap1. >>>>>>>> >>>>>>>> The commit reverts cleanly if we also revert >>>>>>>> 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >>>>>>>> service routine), which seems to be just some minor optimization. The >>>>>>>> result is below, and with it 770 works again. >>>>>>> >>>>>>> Hmm in this case it seems that we should just fix it rather than go back >>>>>>> to the old code, so let's take a look at that first. >>>>>> >>>>>> Does the following fix it for you or do we need to fix something else >>>>>> there too? >>>>> >>>>> Thanks, that fixes Retu probe on 770. >>>> >>>> Sorry for not responding sooner, but I have been moving. >>>> >>>> From looking at the code it appears that the regmap_add_irq_chip() >>>> is failing in the retu driver. I am not sure if this will work, >>>> but have you tried making the following change to the retu driver >>>> so that it also uses irq_domain_add_linear() as well? Just a thought ... >>> >>> This will trigger WARNING: at drivers/base/regmap/regmap-irq.c:514. >> >> Sorry, there is another change needed. Can you try ... > > I don't see much improvement with this. Although Retu probe succeeds, > genirq error logs are still there. Also none of the GPIO irqs used by > other drivers seem to be working at all, e.g. touchscreen. Care to share the log? Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-28 18:42 ` Jon Hunter @ 2013-05-29 18:55 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-29 18:55 UTC (permalink / raw) To: Jon Hunter Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel Hi, On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: > Care to share the log? Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile Retu this time, as it has nothing to do with GPIO IRQs being broken on OMAP1. 1) broken vanilla 3.10-rc3: serial wakeup GPIO irq gets IRQ 0 and no other GPIO IRQs seen in /proc/interrupts. genirq error logs seen in boot. 2) working 3.10-rc3 with Tony's fix <== this fix should be applied (http://marc.info/?l=linux-arm-kernel&m=136907202628855&w=2). GPIO IRQs are normal, e.g. touchscreen can be used. 3) .config used. A. --8<-- 1) Broken, vanilla 3.10-rc3: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc3-770_tiny (aaro@blackmetal) (gcc version 4.7.3 (GCC) ) #3 Wed May 29 21:28:04 EEST 2013 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] OMAP1710 [ 0.000000] revision 8 handled as 16xx id: 8b5f702f03330200 [ 0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e [ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz [ 0.000000] Kernel command line: mem=64M console=tty console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 64MB = 64MB total [ 0.000000] Memory: 60168k/60168k available, 5368k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc01cbd5c (1808 kB) [ 0.000000] .init : 0xc01cc000 - 0xc04503bc (2577 kB) [ 0.000000] .data : 0xc0452000 - 0xc0478240 ( 153 kB) [ 0.000000] .bss : 0xc0478240 - 0xc04a3d04 ( 175 kB) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:368 [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.002777] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688) [ 0.090057] pid_max: default: 32768 minimum: 301 [ 0.090942] Mount-cache hash table entries: 512 [ 0.092956] CPU: Testing write buffer coherency: ok [ 0.093902] Setting up static identity map for 0xc018d540 - 0xc018d57c [ 0.096618] devtmpfs: initialized [ 0.106231] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.113677] omap_gpio omap_gpio.1: Could not get gpio dbck [ 0.114044] OMAP GPIO hardware version 1.1 [ 0.114288] omap_gpio omap_gpio.2: Could not get gpio dbck [ 0.114746] omap_gpio omap_gpio.3: Could not get gpio dbck [ 0.115203] omap_gpio omap_gpio.4: Could not get gpio dbck [ 0.121490] MUX: initialized V6_USB0_TXD [ 0.121643] MUX: initialized W5_USB0_SE0 [ 0.121734] MUX: initialized Y5_USB0_RCV [ 0.121826] MUX: initialized AA9_USB0_VP [ 0.121887] MUX: initialized R9_USB0_VM [ 0.122833] MUX: initialized W19_1610_MMC2_DATDIR1 [ 0.126129] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz [ 0.137847] OMAP DMA hardware version 1 [ 0.138000] DMA capabilities: 0000000c:00000000:01ff:003f:007f [ 0.190521] bio: create slab <bio-0> at 0 [ 0.315185] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.320098] SCSI subsystem initialized [ 0.320465] omap_uwire omap_uwire: Runtime PM disabled, clock forced on. [ 0.322052] omap_uwire omap_uwire: master is unqueued, this is deprecated [ 0.326446] usbcore: registered new interface driver usbfs [ 0.327575] usbcore: registered new interface driver hub [ 0.328765] usbcore: registered new device driver usb [ 0.332427] Switching to clocksource 32k_counter [ 0.509490] OMAP OCPI interconnect driver loaded [ 1.194671] io scheduler noop registered (default) [ 1.233367] omapfb: lph8923 rev 92 LCD detected, 16 data lines [ 1.245727] omapfb: configured for panel lph8923 [ 1.254882] omapfb: LCDC initialized [ 1.255157] omapfb omapfb: SoSSI version 1.21 initialized [ 1.255889] omapfb omapfb: : Epson HWA742 LCD controller rev 1 initialized (CNF pins 7) [ 1.256134] omapfb omapfb: HWA742: setting update mode to auto [ 1.334136] Console: switching to colour frame buffer device 100x30 [ 1.370452] omapfb: Framebuffer initialized. Total vram 770048 planes 1 [ 1.383117] omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz [ 1.428649] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.535339] serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654 [ 1.942626] console [ttyS0] enabled [ 2.024841] serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 47) is a ST16654 [ 2.094818] serial8250.0: ttyS2 at MMIO 0xfffb9800 (irq = 15) is a ST16654 [ 2.184295] usbcore: registered new interface driver usb-storage [ 2.295166] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.314910] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.334442] omap-dma-engine omap-dma-engine: allocating channel for 54 [ 2.353729] omap-dma-engine omap-dma-engine: allocating channel for 55 [ 2.453918] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.473175] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.496093] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.515228] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.533538] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.551086] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.568450] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.586059] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.602905] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.619232] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.635070] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.651000] mmci-omap mmci-omap.1: command timeout (CMD1) [ 2.703674] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.718048] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.736267] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.749542] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.761718] usbcore: registered new interface driver usbhid [ 2.773590] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.785339] usbhid: USB HID core driver [ 2.796142] VFP support v0.3: not present [ 2.806823] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00000001 (serial wakeup) [ 2.822387] No interrupt for UART wake GPIO: 18 [ 2.833953] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00000001 (serial wakeup) [ 2.850372] No interrupt for UART wake GPIO: 49 [ 2.864074] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.958190] Freeing unused kernel memory: 2576K (c01cc000 - c0450000) [ 3.003692] mmci-omap mmci-omap.1: command timeout (CMD5) [ 3.019165] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.034576] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.050018] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.065429] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.081054] mmci-omap mmci-omap.1: command timeout (CMD1) [ 3.403076] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.419403] ohci ohci: OMAP OHCI [ 3.432556] ohci ohci: new USB bus registered, assigned bus number 1 [ 3.449584] ohci ohci: irq 38, io mem 0xfffba000 [ 3.554595] hub 1-0:1.0: USB hub found [ 3.569305] hub 1-0:1.0: 3 ports detected # cat /proc/interrupts CPU0 0: 0 GPIO serial wakeup 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 108 MPU LCD DMA 31: 0 MPU lcdc 38: 0 MPU ohci_hcd:usb1 46: 3 MPU serial 51: 0 MPU sossi_match 54: 361 MPU 32KHz timer 74: 26 MPU mmci-omap 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA Err: 0 --8<-- 2) OK, 3.10-rc3 with Tony's patch: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc3-770_tiny+ (aaro@blackmetal) (gcc version 4.7.3 (GCC) ) #4 Wed May 29 21:35:52 EEST 2013 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] OMAP1710 [ 0.000000] revision 8 handled as 16xx id: 8b5f702f03330200 [ 0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e [ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz [ 0.000000] Kernel command line: mem=64M console=tty console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 64MB = 64MB total [ 0.000000] Memory: 60168k/60168k available, 5368k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc01cbd5c (1808 kB) [ 0.000000] .init : 0xc01cc000 - 0xc04503bc (2577 kB) [ 0.000000] .data : 0xc0452000 - 0xc0478240 ( 153 kB) [ 0.000000] .bss : 0xc0478240 - 0xc04a3d04 ( 175 kB) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:368 [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.002807] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688) [ 0.090087] pid_max: default: 32768 minimum: 301 [ 0.090972] Mount-cache hash table entries: 512 [ 0.092956] CPU: Testing write buffer coherency: ok [ 0.093963] Setting up static identity map for 0xc018d568 - 0xc018d5a4 [ 0.096649] devtmpfs: initialized [ 0.106292] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.113555] omap_gpio omap_gpio.1: Could not get gpio dbck [ 0.113830] OMAP GPIO hardware version 1.1 [ 0.114105] omap_gpio omap_gpio.2: Could not get gpio dbck [ 0.114471] omap_gpio omap_gpio.3: Could not get gpio dbck [ 0.114868] omap_gpio omap_gpio.4: Could not get gpio dbck [ 0.121002] MUX: initialized V6_USB0_TXD [ 0.121124] MUX: initialized W5_USB0_SE0 [ 0.121215] MUX: initialized Y5_USB0_RCV [ 0.121307] MUX: initialized AA9_USB0_VP [ 0.121398] MUX: initialized R9_USB0_VM [ 0.122314] MUX: initialized W19_1610_MMC2_DATDIR1 [ 0.125671] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz [ 0.137451] OMAP DMA hardware version 1 [ 0.137634] DMA capabilities: 0000000c:00000000:01ff:003f:007f [ 0.190155] bio: create slab <bio-0> at 0 [ 0.315124] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.320068] SCSI subsystem initialized [ 0.320434] omap_uwire omap_uwire: Runtime PM disabled, clock forced on. [ 0.322021] omap_uwire omap_uwire: master is unqueued, this is deprecated [ 0.326446] usbcore: registered new interface driver usbfs [ 0.327545] usbcore: registered new interface driver hub [ 0.328735] usbcore: registered new device driver usb [ 0.332397] Switching to clocksource 32k_counter [ 0.510131] OMAP OCPI interconnect driver loaded [ 1.171295] io scheduler noop registered (default) [ 1.243957] omapfb: lph8923 rev 92 LCD detected, 16 data lines [ 1.259704] omapfb: configured for panel lph8923 [ 1.268859] omapfb: LCDC initialized [ 1.269134] omapfb omapfb: SoSSI version 1.21 initialized [ 1.269866] omapfb omapfb: : Epson HWA742 LCD controller rev 1 initialized (CNF pins 7) [ 1.270111] omapfb omapfb: HWA742: setting update mode to auto [ 1.331970] Console: switching to colour frame buffer device 100x30 [ 1.369232] omapfb: Framebuffer initialized. Total vram 770048 planes 1 [ 1.381774] omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz [ 1.435150] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.539184] serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654 [ 1.946960] console [ttyS0] enabled [ 2.024810] serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 47) is a ST16654 [ 2.104766] serial8250.0: ttyS2 at MMIO 0xfffb9800 (irq = 15) is a ST16654 [ 2.194488] usbcore: registered new interface driver usb-storage [ 2.246032] ads7846 spi2.0: touchscreen, irq 174 [ 2.266693] input: ADS7846 Touchscreen as /devices/platform/omap_uwire/spi_master/spi2/spi2.0/input/input0 [ 2.375030] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.396148] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.417114] omap-dma-engine omap-dma-engine: allocating channel for 54 [ 2.438018] omap-dma-engine omap-dma-engine: allocating channel for 55 [ 2.533843] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.554290] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.578033] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.598144] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.617492] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.636322] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.654968] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.673553] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.691131] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.708160] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.724914] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.741607] mmci-omap mmci-omap.1: command timeout (CMD1) [ 2.774658] usbcore: registered new interface driver usbhid [ 2.789337] usbhid: USB HID core driver [ 2.802001] VFP support v0.3: not present [ 2.817016] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.845886] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.864868] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.879516] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.893280] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.906005] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.918121] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.930236] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.942077] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.954254] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.965942] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.977355] mmci-omap mmci-omap.1: command timeout (CMD1) [ 3.050811] Freeing unused kernel memory: 2576K (c01cc000 - c0450000) [ 3.415039] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.427734] ohci ohci: OMAP OHCI [ 3.437652] ohci ohci: new USB bus registered, assigned bus number 1 [ 3.451171] ohci ohci: irq 38, io mem 0xfffba000 [ 3.554595] hub 1-0:1.0: USB hub found [ 3.565643] hub 1-0:1.0: 3 ports detected # cat /proc/interrupts CPU0 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 322 MPU LCD DMA 31: 0 MPU lcdc 38: 0 MPU ohci_hcd:usb1 46: 96 MPU serial 51: 0 MPU sossi_match 54: 631 MPU 32KHz timer 74: 26 MPU mmci-omap 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA 174: 1377 GPIO ads7846 177: 0 GPIO serial wakeup 196: 0 GPIO serial wakeup 208: 0 GPIO serial wakeup Err: 0 --8<-- 3) .config # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.10.0-rc3 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_NEED_MACH_MEMORY_H=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="-770_tiny" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_FHANDLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_HAVE_UID16=y CONFIG_HOTPLUG=y CONFIG_EXPERT=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_MODULES_USE_ELF_REL=y CONFIG_CLONE_BACKWARDS=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_OLD_SIGACTION=y # # GCOV-based kernel profiling # CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_MODULE_SIG is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_FREEZER is not set # # System Type # CONFIG_MMU=y # CONFIG_ARCH_MULTIPLATFORM is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_DOVE is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_MMP is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_LPC32XX is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_MSM is not set # CONFIG_ARCH_SHMOBILE is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C24XX is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_S5P64X0 is not set # CONFIG_ARCH_S5PC100 is not set # CONFIG_ARCH_S5PV210 is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP1=y # CONFIG_GPIO_PCA953X is not set # # TI OMAP Common Features # CONFIG_ARCH_OMAP_OTG=y # # OMAP Feature Selections # # CONFIG_OMAP_RESET_CLOCKS is not set CONFIG_OMAP_MUX=y # CONFIG_OMAP_MUX_DEBUG is not set CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y # CONFIG_OMAP_DM_TIMER is not set CONFIG_OMAP_SERIAL_WAKE=y CONFIG_OMAP_PM_NOOP=y # # TI OMAP1 specific features # # # OMAP Core Type # # CONFIG_ARCH_OMAP730 is not set # CONFIG_ARCH_OMAP850 is not set # CONFIG_ARCH_OMAP15XX is not set CONFIG_ARCH_OMAP16XX=y # # OMAP Board Type # # CONFIG_MACH_OMAP_INNOVATOR is not set # CONFIG_MACH_OMAP_H2 is not set # CONFIG_MACH_OMAP_H3 is not set # CONFIG_MACH_OMAP_OSK is not set CONFIG_MACH_NOKIA770=y # CONFIG_MACH_OMAP_GENERIC is not set CONFIG_ARCH_OMAP=y # CONFIG_PLAT_SPEAR is not set # # Processor Type # # CONFIG_CPU_ARM925T is not set CONFIG_CPU_ARM926T=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5TJ=y CONFIG_CPU_PABRT_LEGACY=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_COPY_V4WB=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y CONFIG_CPU_USE_DOMAINS=y # # Processor Features # # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARM_THUMB is not set # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_DCACHE_WRITETHROUGH is not set # CONFIG_CPU_CACHE_ROUND_ROBIN is not set # CONFIG_CACHE_L2X0 is not set CONFIG_ARM_L1_CACHE_SHIFT=5 CONFIG_ARM_NR_BANKS=8 # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_NR_GPIO=0 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_HZ=100 CONFIG_SCHED_HRTICK=y CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y # CONFIG_HIGHMEM is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HAVE_MEMBLOCK=y # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=999999 CONFIG_COMPACTION=y CONFIG_MIGRATION=y # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=0 # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_NEED_PER_CPU_KM=y # CONFIG_CLEANCACHE is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_ALIGNMENT_TRAP=y # CONFIG_UACCESS_WITH_MEMCPY is not set # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # # Boot options # # CONFIG_USE_OF is not set CONFIG_ATAGS=y # CONFIG_DEPRECATED_PARAM_STRUCT is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=tty console=ttyS0,115200n8" # CONFIG_CMDLINE_FROM_BOOTLOADER is not set CONFIG_CMDLINE_EXTEND=y # CONFIG_CMDLINE_FORCE is not set # CONFIG_XIP_KERNEL is not set CONFIG_KEXEC=y CONFIG_ATAGS_PROC=y # CONFIG_CRASH_DUMP is not set # CONFIG_AUTO_ZRELADDR is not set # # CPU Power Management # # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set # # Floating point emulation # # # At least one emulation must be selected # CONFIG_VFP=y # # Userspace binary formats # CONFIG_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_BINFMT_SCRIPT=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set CONFIG_COREDUMP=y # # Power management options # # CONFIG_SUSPEND is not set # CONFIG_PM_RUNTIME is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ARM_CPU_SUSPEND is not set # CONFIG_NET is not set CONFIG_HAVE_BPF_JIT=y # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y # CONFIG_DEVTMPFS_MOUNT is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set # CONFIG_DMA_SHARED_BUFFER is not set # CONFIG_CMA is not set # # Bus devices # # CONFIG_MTD is not set # CONFIG_PARPORT is not set # CONFIG_BLK_DEV is not set # # Misc devices # # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_AD525X_DPOT is not set # CONFIG_ATMEL_PWM is not set # CONFIG_DUMMY_IRQ is not set # CONFIG_ICS932S401 is not set # CONFIG_ATMEL_SSC is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_APDS9802ALS is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_SENSORS_BH1780 is not set # CONFIG_SENSORS_BH1770 is not set # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set # CONFIG_TI_DAC7512 is not set # CONFIG_BMP085_I2C is not set # CONFIG_BMP085_SPI is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_LATTICE_ECP3_CONFIG is not set # CONFIG_SRAM is not set # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_EEPROM_93XX46 is not set # # Texas Instruments shared transport line discipline # # CONFIG_SENSORS_LIS3_SPI is not set # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module # # CONFIG_ALTERA_STAPL is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_TARGET_CORE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # CONFIG_INPUT_SPARSEKMAP is not set # CONFIG_INPUT_MATRIXKMAP is not set # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y # CONFIG_TOUCHSCREEN_AD7877 is not set # CONFIG_TOUCHSCREEN_AD7879 is not set # CONFIG_TOUCHSCREEN_ATMEL_MXT is not set # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set # CONFIG_TOUCHSCREEN_BU21013 is not set # CONFIG_TOUCHSCREEN_CY8CTMG110 is not set # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set # CONFIG_TOUCHSCREEN_DYNAPRO is not set # CONFIG_TOUCHSCREEN_HAMPSHIRE is not set # CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_ILI210X is not set # CONFIG_TOUCHSCREEN_GUNZE is not set # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_WACOM_I2C is not set # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set # CONFIG_TOUCHSCREEN_MMS114 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set # CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TSC_SERIO is not set # CONFIG_TOUCHSCREEN_TSC2005 is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set # CONFIG_TOUCHSCREEN_W90X900 is not set # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_UNIX98_PTYS is not set # CONFIG_LEGACY_PTYS is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_TRACE_SINK is not set # CONFIG_DEVKMEM is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # CONFIG_SERIAL_8250_DW is not set # CONFIG_SERIAL_8250_EM is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX310X is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_SCCNXP is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_IFX6X60 is not set # CONFIG_SERIAL_ARC is not set # CONFIG_TTY_PRINTK is not set # CONFIG_HVC_DCC is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_R3964 is not set # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y # # I2C Hardware Bus support # # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_CBUS_GPIO=y # CONFIG_I2C_DESIGNWARE_PLATFORM is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_OMAP is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_STUB is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_ALTERA is not set CONFIG_SPI_BITBANG=y # CONFIG_SPI_GPIO is not set # CONFIG_SPI_OC_TINY is not set CONFIG_SPI_OMAP_UWIRE=y # CONFIG_SPI_PXA2XX_PCI is not set # CONFIG_SPI_SC18IS602 is not set # CONFIG_SPI_XCOMM is not set # CONFIG_SPI_XILINX is not set # CONFIG_SPI_DESIGNWARE is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # # Qualcomm MSM SSBI bus support # # CONFIG_SSBI is not set # CONFIG_HSI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # CONFIG_PTP_1588_CLOCK is not set # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # # CONFIG_PTP_1588_CLOCK_PCH is not set CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIO_DEVRES=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set # CONFIG_GPIO_SYSFS is not set # # Memory mapped GPIO drivers: # # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_EM is not set # CONFIG_GPIO_RCAR is not set # CONFIG_GPIO_TS5500 is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_SX150X is not set # CONFIG_GPIO_ADP5588 is not set # # PCI GPIO expanders: # # # SPI GPIO expanders: # # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MCP23S08 is not set # CONFIG_GPIO_MC33880 is not set # CONFIG_GPIO_74X164 is not set # # AC97 GPIO expanders: # # # MODULbus GPIO expanders: # # # USB GPIO expanders: # # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_POWER_AVS is not set # CONFIG_HWMON is not set # CONFIG_THERMAL is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_CORE is not set # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set # CONFIG_DW_WATCHDOG is not set # CONFIG_OMAP_WATCHDOG is not set # CONFIG_MAX63XX_WATCHDOG is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_AS3711 is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_AAT2870_CORE is not set # CONFIG_MFD_CROS_EC is not set # CONFIG_MFD_ASIC3 is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_DA9052_SPI is not set # CONFIG_MFD_DA9052_I2C is not set # CONFIG_MFD_DA9055 is not set # CONFIG_MFD_MC13XXX_SPI is not set # CONFIG_MFD_MC13XXX_I2C is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_HTC_I2CPLD is not set # CONFIG_MFD_88PM800 is not set # CONFIG_MFD_88PM805 is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_MAX77686 is not set # CONFIG_MFD_MAX77693 is not set # CONFIG_MFD_MAX8907 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_EZX_PCAP is not set # CONFIG_MFD_VIPERBOARD is not set # CONFIG_MFD_RETU is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_MFD_SMSC is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_SYSCON is not set # CONFIG_MFD_TI_AM335X_TSCADC is not set # CONFIG_MFD_LP8788 is not set # CONFIG_MFD_PALMAS is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912 is not set # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_MFD_TPS65912_SPI is not set # CONFIG_MFD_TPS80031 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_TWL6040_CORE is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_ARIZONA_SPI is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM831X_SPI is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # # CONFIG_DRM is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # # Frame buffer hardware drivers # # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_GOLDFISH is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_AUO_K190X is not set CONFIG_FB_OMAP=y CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y # CONFIG_FB_OMAP_MANUAL_UPDATE is not set CONFIG_FB_OMAP_LCD_MIPID=y # CONFIG_FB_OMAP_DMA_TUNE is not set # CONFIG_EXYNOS_VIDEO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Console display driver support # CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set # CONFIG_SOUND is not set # # HID support # CONFIG_HID=y # CONFIG_HIDRAW is not set # CONFIG_UHID is not set CONFIG_HID_GENERIC=y # # Special HID drivers # # CONFIG_HID_A4TECH is not set # CONFIG_HID_ACRUX is not set # CONFIG_HID_APPLE is not set # CONFIG_HID_APPLEIR is not set # CONFIG_HID_AUREAL is not set # CONFIG_HID_BELKIN is not set # CONFIG_HID_CHERRY is not set # CONFIG_HID_CHICONY is not set # CONFIG_HID_CYPRESS is not set # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set # CONFIG_HID_ELECOM is not set # CONFIG_HID_EZKEY is not set # CONFIG_HID_HOLTEK is not set # CONFIG_HID_KEYTOUCH is not set # CONFIG_HID_KYE is not set # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set # CONFIG_HID_GYRATION is not set # CONFIG_HID_ICADE is not set # CONFIG_HID_TWINHAN is not set # CONFIG_HID_KENSINGTON is not set # CONFIG_HID_LCPOWER is not set # CONFIG_HID_LENOVO_TPKBD is not set # CONFIG_HID_LOGITECH is not set # CONFIG_HID_MAGICMOUSE is not set # CONFIG_HID_MICROSOFT is not set # CONFIG_HID_MONTEREY is not set # CONFIG_HID_MULTITOUCH is not set # CONFIG_HID_NTRIG is not set # CONFIG_HID_ORTEK is not set # CONFIG_HID_PANTHERLORD is not set # CONFIG_HID_PETALYNX is not set # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_PS3REMOTE is not set # CONFIG_HID_ROCCAT is not set # CONFIG_HID_SAITEK is not set # CONFIG_HID_SAMSUNG is not set # CONFIG_HID_SONY is not set # CONFIG_HID_SPEEDLINK is not set # CONFIG_HID_STEELSERIES is not set # CONFIG_HID_SUNPLUS is not set # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set # CONFIG_HID_TIVO is not set # CONFIG_HID_TOPSEED is not set # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set # CONFIG_HID_SENSOR_HUB is not set # # USB HID support # CONFIG_USB_HID=y # CONFIG_HID_PID is not set # CONFIG_USB_HIDDEV is not set # # I2C HID support # # CONFIG_I2C_HID is not set CONFIG_USB_ARCH_HAS_OHCI=y # CONFIG_USB_ARCH_HAS_EHCI is not set # CONFIG_USB_ARCH_HAS_XHCI is not set CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_MON is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_HCD_OMAP1=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_DWC3 is not set # CONFIG_USB_CHIPIDEA is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_EZUSB_FX2 is not set # CONFIG_USB_HSIC_USB3503 is not set # CONFIG_USB_PHY is not set # CONFIG_USB_GADGET is not set CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # CONFIG_MMC_CLKGATE is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_SDHCI_PXAV3 is not set # CONFIG_MMC_SDHCI_PXAV2 is not set CONFIG_MMC_OMAP=y # CONFIG_MMC_SPI is not set # CONFIG_MMC_DW is not set # CONFIG_MMC_VUB300 is not set # CONFIG_MMC_USHC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y # CONFIG_RTC_CLASS is not set CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_DW_DMAC is not set # CONFIG_TIMB_DMA is not set CONFIG_DMA_OMAP=y CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=y # # DMA Clients # # CONFIG_ASYNC_TX_DMA is not set # CONFIG_DMATEST is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # CONFIG_VIRT_DRIVERS is not set # # Virtio drivers # # CONFIG_VIRTIO_MMIO is not set # # Microsoft Hyper-V guest support # # CONFIG_STAGING is not set CONFIG_CLKDEV_LOOKUP=y # # Hardware Spinlock drivers # CONFIG_CLKSRC_MMIO=y # CONFIG_MAILBOX is not set # CONFIG_IOMMU_SUPPORT is not set # # Remoteproc drivers # # CONFIG_STE_MODEM_RPROC is not set # # Rpmsg drivers # # CONFIG_PM_DEVFREQ is not set # CONFIG_EXTCON is not set # CONFIG_MEMORY is not set # CONFIG_IIO is not set # CONFIG_PWM is not set # CONFIG_IPACK_BUS is not set # CONFIG_RESET_CONTROLLER is not set # # File systems # # CONFIG_EXT2_FS is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4_FS is not set CONFIG_JBD=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_FILE_LOCKING is not set # CONFIG_FSNOTIFY is not set # CONFIG_DNOTIFY is not set # CONFIG_INOTIFY_USER is not set # CONFIG_FANOTIFY is not set # CONFIG_QUOTA is not set # CONFIG_QUOTACTL is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # # CONFIG_MSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_MAC_ROMAN is not set # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set # CONFIG_NLS_MAC_CROATIAN is not set # CONFIG_NLS_MAC_CYRILLIC is not set # CONFIG_NLS_MAC_GAELIC is not set # CONFIG_NLS_MAC_GREEK is not set # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set # CONFIG_NLS_MAC_ROMANIAN is not set # CONFIG_NLS_MAC_TURKISH is not set # CONFIG_NLS_UTF8 is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7 CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_READABLE_ASM is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set # CONFIG_LOCKUP_DETECTOR is not set # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_HAVE_DEBUG_KMEMLEAK=y # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # # RCU Debugging # # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_TRACE is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACING_SUPPORT=y # CONFIG_FTRACE is not set # CONFIG_RBTREE_TEST is not set # CONFIG_INTERVAL_TREE_TEST is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_TEST_STRING_HELPERS is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set # CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_LL is not set CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h" # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY_DMESG_RESTRICT is not set # CONFIG_SECURITY is not set # CONFIG_SECURITYFS is not set CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" # CONFIG_CRYPTO is not set # CONFIG_BINARY_PRINTF is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IO=y # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set # CONFIG_CRC8 is not set # CONFIG_XZ_DEC is not set # CONFIG_XZ_DEC_BCJ is not set CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_ATOMIC64=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y # CONFIG_AVERAGE is not set # CONFIG_CORDIC is not set # CONFIG_DDR is not set # CONFIG_VIRTUALIZATION is not set ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-29 18:55 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-05-29 18:55 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: > Care to share the log? Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile Retu this time, as it has nothing to do with GPIO IRQs being broken on OMAP1. 1) broken vanilla 3.10-rc3: serial wakeup GPIO irq gets IRQ 0 and no other GPIO IRQs seen in /proc/interrupts. genirq error logs seen in boot. 2) working 3.10-rc3 with Tony's fix <== this fix should be applied (http://marc.info/?l=linux-arm-kernel&m=136907202628855&w=2). GPIO IRQs are normal, e.g. touchscreen can be used. 3) .config used. A. --8<-- 1) Broken, vanilla 3.10-rc3: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc3-770_tiny (aaro at blackmetal) (gcc version 4.7.3 (GCC) ) #3 Wed May 29 21:28:04 EEST 2013 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] OMAP1710 [ 0.000000] revision 8 handled as 16xx id: 8b5f702f03330200 [ 0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e [ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz [ 0.000000] Kernel command line: mem=64M console=tty console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 64MB = 64MB total [ 0.000000] Memory: 60168k/60168k available, 5368k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc01cbd5c (1808 kB) [ 0.000000] .init : 0xc01cc000 - 0xc04503bc (2577 kB) [ 0.000000] .data : 0xc0452000 - 0xc0478240 ( 153 kB) [ 0.000000] .bss : 0xc0478240 - 0xc04a3d04 ( 175 kB) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:368 [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter@32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.002777] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688) [ 0.090057] pid_max: default: 32768 minimum: 301 [ 0.090942] Mount-cache hash table entries: 512 [ 0.092956] CPU: Testing write buffer coherency: ok [ 0.093902] Setting up static identity map for 0xc018d540 - 0xc018d57c [ 0.096618] devtmpfs: initialized [ 0.106231] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.113677] omap_gpio omap_gpio.1: Could not get gpio dbck [ 0.114044] OMAP GPIO hardware version 1.1 [ 0.114288] omap_gpio omap_gpio.2: Could not get gpio dbck [ 0.114746] omap_gpio omap_gpio.3: Could not get gpio dbck [ 0.115203] omap_gpio omap_gpio.4: Could not get gpio dbck [ 0.121490] MUX: initialized V6_USB0_TXD [ 0.121643] MUX: initialized W5_USB0_SE0 [ 0.121734] MUX: initialized Y5_USB0_RCV [ 0.121826] MUX: initialized AA9_USB0_VP [ 0.121887] MUX: initialized R9_USB0_VM [ 0.122833] MUX: initialized W19_1610_MMC2_DATDIR1 [ 0.126129] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz [ 0.137847] OMAP DMA hardware version 1 [ 0.138000] DMA capabilities: 0000000c:00000000:01ff:003f:007f [ 0.190521] bio: create slab <bio-0> at 0 [ 0.315185] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.320098] SCSI subsystem initialized [ 0.320465] omap_uwire omap_uwire: Runtime PM disabled, clock forced on. [ 0.322052] omap_uwire omap_uwire: master is unqueued, this is deprecated [ 0.326446] usbcore: registered new interface driver usbfs [ 0.327575] usbcore: registered new interface driver hub [ 0.328765] usbcore: registered new device driver usb [ 0.332427] Switching to clocksource 32k_counter [ 0.509490] OMAP OCPI interconnect driver loaded [ 1.194671] io scheduler noop registered (default) [ 1.233367] omapfb: lph8923 rev 92 LCD detected, 16 data lines [ 1.245727] omapfb: configured for panel lph8923 [ 1.254882] omapfb: LCDC initialized [ 1.255157] omapfb omapfb: SoSSI version 1.21 initialized [ 1.255889] omapfb omapfb: : Epson HWA742 LCD controller rev 1 initialized (CNF pins 7) [ 1.256134] omapfb omapfb: HWA742: setting update mode to auto [ 1.334136] Console: switching to colour frame buffer device 100x30 [ 1.370452] omapfb: Framebuffer initialized. Total vram 770048 planes 1 [ 1.383117] omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz [ 1.428649] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.535339] serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654 [ 1.942626] console [ttyS0] enabled [ 2.024841] serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 47) is a ST16654 [ 2.094818] serial8250.0: ttyS2 at MMIO 0xfffb9800 (irq = 15) is a ST16654 [ 2.184295] usbcore: registered new interface driver usb-storage [ 2.295166] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.314910] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.334442] omap-dma-engine omap-dma-engine: allocating channel for 54 [ 2.353729] omap-dma-engine omap-dma-engine: allocating channel for 55 [ 2.453918] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.473175] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.496093] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.515228] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.533538] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.551086] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.568450] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.586059] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.602905] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.619232] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.635070] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.651000] mmci-omap mmci-omap.1: command timeout (CMD1) [ 2.703674] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.718048] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.736267] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.749542] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.761718] usbcore: registered new interface driver usbhid [ 2.773590] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.785339] usbhid: USB HID core driver [ 2.796142] VFP support v0.3: not present [ 2.806823] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00000001 (serial wakeup) [ 2.822387] No interrupt for UART wake GPIO: 18 [ 2.833953] genirq: Flags mismatch irq 0. 00000001 (serial wakeup) vs. 00000001 (serial wakeup) [ 2.850372] No interrupt for UART wake GPIO: 49 [ 2.864074] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.958190] Freeing unused kernel memory: 2576K (c01cc000 - c0450000) [ 3.003692] mmci-omap mmci-omap.1: command timeout (CMD5) [ 3.019165] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.034576] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.050018] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.065429] mmci-omap mmci-omap.1: command timeout (CMD55) [ 3.081054] mmci-omap mmci-omap.1: command timeout (CMD1) [ 3.403076] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.419403] ohci ohci: OMAP OHCI [ 3.432556] ohci ohci: new USB bus registered, assigned bus number 1 [ 3.449584] ohci ohci: irq 38, io mem 0xfffba000 [ 3.554595] hub 1-0:1.0: USB hub found [ 3.569305] hub 1-0:1.0: 3 ports detected # cat /proc/interrupts CPU0 0: 0 GPIO serial wakeup 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 108 MPU LCD DMA 31: 0 MPU lcdc 38: 0 MPU ohci_hcd:usb1 46: 3 MPU serial 51: 0 MPU sossi_match 54: 361 MPU 32KHz timer 74: 26 MPU mmci-omap 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA Err: 0 --8<-- 2) OK, 3.10-rc3 with Tony's patch: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc3-770_tiny+ (aaro at blackmetal) (gcc version 4.7.3 (GCC) ) #4 Wed May 29 21:35:52 EEST 2013 [ 0.000000] Ignoring unrecognised tag 0x414f4d50 [ 0.000000] OMAP1710 [ 0.000000] revision 8 handled as 16xx id: 8b5f702f03330200 [ 0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2a93 ARM_CKCTL: 0x050e [ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/252.0/252.0 MHz [ 0.000000] Kernel command line: mem=64M console=tty console=ttyS0,115200n8 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 64MB = 64MB total [ 0.000000] Memory: 60168k/60168k available, 5368k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc01cbd5c (1808 kB) [ 0.000000] .init : 0xc01cc000 - 0xc04503bc (2577 kB) [ 0.000000] .data : 0xc0452000 - 0xc0478240 ( 153 kB) [ 0.000000] .bss : 0xc0478240 - 0xc04a3d04 ( 175 kB) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:368 [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter@32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] console [tty0] enabled [ 0.002807] Calibrating delay loop... 125.33 BogoMIPS (lpj=626688) [ 0.090087] pid_max: default: 32768 minimum: 301 [ 0.090972] Mount-cache hash table entries: 512 [ 0.092956] CPU: Testing write buffer coherency: ok [ 0.093963] Setting up static identity map for 0xc018d568 - 0xc018d5a4 [ 0.096649] devtmpfs: initialized [ 0.106292] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.113555] omap_gpio omap_gpio.1: Could not get gpio dbck [ 0.113830] OMAP GPIO hardware version 1.1 [ 0.114105] omap_gpio omap_gpio.2: Could not get gpio dbck [ 0.114471] omap_gpio omap_gpio.3: Could not get gpio dbck [ 0.114868] omap_gpio omap_gpio.4: Could not get gpio dbck [ 0.121002] MUX: initialized V6_USB0_TXD [ 0.121124] MUX: initialized W5_USB0_SE0 [ 0.121215] MUX: initialized Y5_USB0_RCV [ 0.121307] MUX: initialized AA9_USB0_VP [ 0.121398] MUX: initialized R9_USB0_VM [ 0.122314] MUX: initialized W19_1610_MMC2_DATDIR1 [ 0.125671] Clocking rate (xtal/DPLL1/MPU): 12.0/216.0/216.0 MHz [ 0.137451] OMAP DMA hardware version 1 [ 0.137634] DMA capabilities: 0000000c:00000000:01ff:003f:007f [ 0.190155] bio: create slab <bio-0> at 0 [ 0.315124] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.320068] SCSI subsystem initialized [ 0.320434] omap_uwire omap_uwire: Runtime PM disabled, clock forced on. [ 0.322021] omap_uwire omap_uwire: master is unqueued, this is deprecated [ 0.326446] usbcore: registered new interface driver usbfs [ 0.327545] usbcore: registered new interface driver hub [ 0.328735] usbcore: registered new device driver usb [ 0.332397] Switching to clocksource 32k_counter [ 0.510131] OMAP OCPI interconnect driver loaded [ 1.171295] io scheduler noop registered (default) [ 1.243957] omapfb: lph8923 rev 92 LCD detected, 16 data lines [ 1.259704] omapfb: configured for panel lph8923 [ 1.268859] omapfb: LCDC initialized [ 1.269134] omapfb omapfb: SoSSI version 1.21 initialized [ 1.269866] omapfb omapfb: : Epson HWA742 LCD controller rev 1 initialized (CNF pins 7) [ 1.270111] omapfb omapfb: HWA742: setting update mode to auto [ 1.331970] Console: switching to colour frame buffer device 100x30 [ 1.369232] omapfb: Framebuffer initialized. Total vram 770048 planes 1 [ 1.381774] omapfb: Pixclock 21940 kHz hfreq 24.9 kHz vfreq 51.0 Hz [ 1.435150] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.539184] serial8250.0: ttyS0 at MMIO 0xfffb0000 (irq = 46) is a ST16654 [ 1.946960] console [ttyS0] enabled [ 2.024810] serial8250.0: ttyS1 at MMIO 0xfffb0800 (irq = 47) is a ST16654 [ 2.104766] serial8250.0: ttyS2 at MMIO 0xfffb9800 (irq = 15) is a ST16654 [ 2.194488] usbcore: registered new interface driver usb-storage [ 2.246032] ads7846 spi2.0: touchscreen, irq 174 [ 2.266693] input: ADS7846 Touchscreen as /devices/platform/omap_uwire/spi_master/spi2/spi2.0/input/input0 [ 2.375030] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.396148] mmci-omap mmci-omap.1: Runtime PM disabled, clock forced on. [ 2.417114] omap-dma-engine omap-dma-engine: allocating channel for 54 [ 2.438018] omap-dma-engine omap-dma-engine: allocating channel for 55 [ 2.533843] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.554290] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.578033] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.598144] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.617492] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.636322] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.654968] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.673553] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.691131] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.708160] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.724914] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.741607] mmci-omap mmci-omap.1: command timeout (CMD1) [ 2.774658] usbcore: registered new interface driver usbhid [ 2.789337] usbhid: USB HID core driver [ 2.802001] VFP support v0.3: not present [ 2.817016] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.845886] mmci-omap mmci-omap.1: command timeout (CMD52) [ 2.864868] mmci-omap mmci-omap.1: command timeout (CMD8) [ 2.879516] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.893280] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.906005] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.918121] mmci-omap mmci-omap.1: command timeout (CMD5) [ 2.930236] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.942077] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.954254] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.965942] mmci-omap mmci-omap.1: command timeout (CMD55) [ 2.977355] mmci-omap mmci-omap.1: command timeout (CMD1) [ 3.050811] Freeing unused kernel memory: 2576K (c01cc000 - c0450000) [ 3.415039] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.427734] ohci ohci: OMAP OHCI [ 3.437652] ohci ohci: new USB bus registered, assigned bus number 1 [ 3.451171] ohci ohci: irq 38, io mem 0xfffba000 [ 3.554595] hub 1-0:1.0: USB hub found [ 3.565643] hub 1-0:1.0: 3 ports detected # cat /proc/interrupts CPU0 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 322 MPU LCD DMA 31: 0 MPU lcdc 38: 0 MPU ohci_hcd:usb1 46: 96 MPU serial 51: 0 MPU sossi_match 54: 631 MPU 32KHz timer 74: 26 MPU mmci-omap 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA 174: 1377 GPIO ads7846 177: 0 GPIO serial wakeup 196: 0 GPIO serial wakeup 208: 0 GPIO serial wakeup Err: 0 --8<-- 3) .config # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.10.0-rc3 Kernel Configuration # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_VECTORS_BASE=0xffff0000 CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_NEED_MACH_MEMORY_H=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="-770_tiny" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_FHANDLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_UIDGID_CONVERTED=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_HAVE_UID16=y CONFIG_HOTPLUG=y CONFIG_EXPERT=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set # CONFIG_KALLSYMS is not set CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set # CONFIG_SHMEM is not set # CONFIG_AIO is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_GENERIC_IDLE_POLL_SETUP=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_CLK=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_MODULES_USE_ELF_REL=y CONFIG_CLONE_BACKWARDS=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_OLD_SIGACTION=y # # GCOV-based kernel profiling # CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_MODULE_SIG is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_BSGLIB is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED="noop" CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_FREEZER is not set # # System Type # CONFIG_MMU=y # CONFIG_ARCH_MULTIPLATFORM is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_DOVE is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_MMP is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_LPC32XX is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_MSM is not set # CONFIG_ARCH_SHMOBILE is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C24XX is not set # CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_S5P64X0 is not set # CONFIG_ARCH_S5PC100 is not set # CONFIG_ARCH_S5PV210 is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP1=y # CONFIG_GPIO_PCA953X is not set # # TI OMAP Common Features # CONFIG_ARCH_OMAP_OTG=y # # OMAP Feature Selections # # CONFIG_OMAP_RESET_CLOCKS is not set CONFIG_OMAP_MUX=y # CONFIG_OMAP_MUX_DEBUG is not set CONFIG_OMAP_MUX_WARNINGS=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y # CONFIG_OMAP_DM_TIMER is not set CONFIG_OMAP_SERIAL_WAKE=y CONFIG_OMAP_PM_NOOP=y # # TI OMAP1 specific features # # # OMAP Core Type # # CONFIG_ARCH_OMAP730 is not set # CONFIG_ARCH_OMAP850 is not set # CONFIG_ARCH_OMAP15XX is not set CONFIG_ARCH_OMAP16XX=y # # OMAP Board Type # # CONFIG_MACH_OMAP_INNOVATOR is not set # CONFIG_MACH_OMAP_H2 is not set # CONFIG_MACH_OMAP_H3 is not set # CONFIG_MACH_OMAP_OSK is not set CONFIG_MACH_NOKIA770=y # CONFIG_MACH_OMAP_GENERIC is not set CONFIG_ARCH_OMAP=y # CONFIG_PLAT_SPEAR is not set # # Processor Type # # CONFIG_CPU_ARM925T is not set CONFIG_CPU_ARM926T=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5TJ=y CONFIG_CPU_PABRT_LEGACY=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_COPY_V4WB=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y CONFIG_CPU_USE_DOMAINS=y # # Processor Features # # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set # CONFIG_ARM_THUMB is not set # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_CPU_DCACHE_WRITETHROUGH is not set # CONFIG_CPU_CACHE_ROUND_ROBIN is not set # CONFIG_CACHE_L2X0 is not set CONFIG_ARM_L1_CACHE_SHIFT=5 CONFIG_ARM_NR_BANKS=8 # # Bus support # # CONFIG_PCI_SYSCALL is not set # CONFIG_PCCARD is not set # # Kernel Features # CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_NR_GPIO=0 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_HZ=100 CONFIG_SCHED_HRTICK=y CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set CONFIG_HAVE_ARCH_PFN_VALID=y # CONFIG_HIGHMEM is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HAVE_MEMBLOCK=y # CONFIG_HAVE_BOOTMEM_INFO_NODE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=999999 CONFIG_COMPACTION=y CONFIG_MIGRATION=y # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=0 # CONFIG_KSM is not set CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_NEED_PER_CPU_KM=y # CONFIG_CLEANCACHE is not set CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_ALIGNMENT_TRAP=y # CONFIG_UACCESS_WITH_MEMCPY is not set # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # # Boot options # # CONFIG_USE_OF is not set CONFIG_ATAGS=y # CONFIG_DEPRECATED_PARAM_STRUCT is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=tty console=ttyS0,115200n8" # CONFIG_CMDLINE_FROM_BOOTLOADER is not set CONFIG_CMDLINE_EXTEND=y # CONFIG_CMDLINE_FORCE is not set # CONFIG_XIP_KERNEL is not set CONFIG_KEXEC=y CONFIG_ATAGS_PROC=y # CONFIG_CRASH_DUMP is not set # CONFIG_AUTO_ZRELADDR is not set # # CPU Power Management # # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set # # Floating point emulation # # # At least one emulation must be selected # CONFIG_VFP=y # # Userspace binary formats # CONFIG_BINFMT_ELF=y CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y CONFIG_BINFMT_SCRIPT=y CONFIG_HAVE_AOUT=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set CONFIG_COREDUMP=y # # Power management options # # CONFIG_SUSPEND is not set # CONFIG_PM_RUNTIME is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ARM_CPU_SUSPEND is not set # CONFIG_NET is not set CONFIG_HAVE_BPF_JIT=y # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y # CONFIG_DEVTMPFS_MOUNT is not set CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_GENERIC_CPU_DEVICES is not set # CONFIG_DMA_SHARED_BUFFER is not set # CONFIG_CMA is not set # # Bus devices # # CONFIG_MTD is not set # CONFIG_PARPORT is not set # CONFIG_BLK_DEV is not set # # Misc devices # # CONFIG_SENSORS_LIS3LV02D is not set # CONFIG_AD525X_DPOT is not set # CONFIG_ATMEL_PWM is not set # CONFIG_DUMMY_IRQ is not set # CONFIG_ICS932S401 is not set # CONFIG_ATMEL_SSC is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_APDS9802ALS is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_SENSORS_BH1780 is not set # CONFIG_SENSORS_BH1770 is not set # CONFIG_SENSORS_APDS990X is not set # CONFIG_HMC6352 is not set # CONFIG_DS1682 is not set # CONFIG_TI_DAC7512 is not set # CONFIG_BMP085_I2C is not set # CONFIG_BMP085_SPI is not set # CONFIG_USB_SWITCH_FSA9480 is not set # CONFIG_LATTICE_ECP3_CONFIG is not set # CONFIG_SRAM is not set # CONFIG_C2PORT is not set # # EEPROM support # # CONFIG_EEPROM_AT24 is not set # CONFIG_EEPROM_AT25 is not set # CONFIG_EEPROM_LEGACY is not set # CONFIG_EEPROM_MAX6875 is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_EEPROM_93XX46 is not set # # Texas Instruments shared transport line discipline # # CONFIG_SENSORS_LIS3_SPI is not set # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module # # CONFIG_ALTERA_STAPL is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_SCSI_MOD=y # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_DH is not set # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_TARGET_CORE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # CONFIG_INPUT_SPARSEKMAP is not set # CONFIG_INPUT_MATRIXKMAP is not set # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # # CONFIG_INPUT_KEYBOARD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y # CONFIG_TOUCHSCREEN_AD7877 is not set # CONFIG_TOUCHSCREEN_AD7879 is not set # CONFIG_TOUCHSCREEN_ATMEL_MXT is not set # CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set # CONFIG_TOUCHSCREEN_BU21013 is not set # CONFIG_TOUCHSCREEN_CY8CTMG110 is not set # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set # CONFIG_TOUCHSCREEN_DYNAPRO is not set # CONFIG_TOUCHSCREEN_HAMPSHIRE is not set # CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set # CONFIG_TOUCHSCREEN_ILI210X is not set # CONFIG_TOUCHSCREEN_GUNZE is not set # CONFIG_TOUCHSCREEN_ELO is not set # CONFIG_TOUCHSCREEN_WACOM_W8001 is not set # CONFIG_TOUCHSCREEN_WACOM_I2C is not set # CONFIG_TOUCHSCREEN_MAX11801 is not set # CONFIG_TOUCHSCREEN_MCS5000 is not set # CONFIG_TOUCHSCREEN_MMS114 is not set # CONFIG_TOUCHSCREEN_MTOUCH is not set # CONFIG_TOUCHSCREEN_INEXIO is not set # CONFIG_TOUCHSCREEN_MK712 is not set # CONFIG_TOUCHSCREEN_PENMOUNT is not set # CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set # CONFIG_TOUCHSCREEN_TOUCHWIN is not set # CONFIG_TOUCHSCREEN_PIXCIR is not set # CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set # CONFIG_TOUCHSCREEN_TSC_SERIO is not set # CONFIG_TOUCHSCREEN_TSC2005 is not set # CONFIG_TOUCHSCREEN_TSC2007 is not set # CONFIG_TOUCHSCREEN_W90X900 is not set # CONFIG_TOUCHSCREEN_ST1232 is not set # CONFIG_TOUCHSCREEN_TPS6507X is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # # CONFIG_SERIO is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_UNIX98_PTYS is not set # CONFIG_LEGACY_PTYS is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_TRACE_SINK is not set # CONFIG_DEVKMEM is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DMA=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # CONFIG_SERIAL_8250_DW is not set # CONFIG_SERIAL_8250_EM is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX310X is not set CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_SCCNXP is not set # CONFIG_SERIAL_TIMBERDALE is not set # CONFIG_SERIAL_ALTERA_JTAGUART is not set # CONFIG_SERIAL_ALTERA_UART is not set # CONFIG_SERIAL_IFX6X60 is not set # CONFIG_SERIAL_ARC is not set # CONFIG_TTY_PRINTK is not set # CONFIG_HVC_DCC is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_R3964 is not set # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y # # I2C Hardware Bus support # # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_CBUS_GPIO=y # CONFIG_I2C_DESIGNWARE_PLATFORM is not set # CONFIG_I2C_GPIO is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_OMAP is not set # CONFIG_I2C_PCA_PLATFORM is not set # CONFIG_I2C_PXA_PCI is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_DIOLAN_U2C is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_STUB is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_ALTERA is not set CONFIG_SPI_BITBANG=y # CONFIG_SPI_GPIO is not set # CONFIG_SPI_OC_TINY is not set CONFIG_SPI_OMAP_UWIRE=y # CONFIG_SPI_PXA2XX_PCI is not set # CONFIG_SPI_SC18IS602 is not set # CONFIG_SPI_XCOMM is not set # CONFIG_SPI_XILINX is not set # CONFIG_SPI_DESIGNWARE is not set # # SPI Protocol Masters # # CONFIG_SPI_SPIDEV is not set # CONFIG_SPI_TLE62X0 is not set # # Qualcomm MSM SSBI bus support # # CONFIG_SSBI is not set # CONFIG_HSI is not set # # PPS support # # CONFIG_PPS is not set # # PPS generators support # # # PTP clock support # # CONFIG_PTP_1588_CLOCK is not set # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # # CONFIG_PTP_1588_CLOCK_PCH is not set CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_REQUIRE_GPIOLIB=y CONFIG_GPIO_DEVRES=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set # CONFIG_GPIO_SYSFS is not set # # Memory mapped GPIO drivers: # # CONFIG_GPIO_GENERIC_PLATFORM is not set # CONFIG_GPIO_EM is not set # CONFIG_GPIO_RCAR is not set # CONFIG_GPIO_TS5500 is not set # # I2C GPIO expanders: # # CONFIG_GPIO_MAX7300 is not set # CONFIG_GPIO_MAX732X is not set # CONFIG_GPIO_PCF857X is not set # CONFIG_GPIO_SX150X is not set # CONFIG_GPIO_ADP5588 is not set # # PCI GPIO expanders: # # # SPI GPIO expanders: # # CONFIG_GPIO_MAX7301 is not set # CONFIG_GPIO_MCP23S08 is not set # CONFIG_GPIO_MC33880 is not set # CONFIG_GPIO_74X164 is not set # # AC97 GPIO expanders: # # # MODULbus GPIO expanders: # # # USB GPIO expanders: # # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_POWER_AVS is not set # CONFIG_HWMON is not set # CONFIG_THERMAL is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_CORE is not set # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set # CONFIG_DW_WATCHDOG is not set # CONFIG_OMAP_WATCHDOG is not set # CONFIG_MAX63XX_WATCHDOG is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # # CONFIG_SSB is not set CONFIG_BCMA_POSSIBLE=y # # Broadcom specific AMBA # # CONFIG_BCMA is not set # # Multifunction device drivers # # CONFIG_MFD_CORE is not set # CONFIG_MFD_AS3711 is not set # CONFIG_PMIC_ADP5520 is not set # CONFIG_MFD_AAT2870_CORE is not set # CONFIG_MFD_CROS_EC is not set # CONFIG_MFD_ASIC3 is not set # CONFIG_PMIC_DA903X is not set # CONFIG_MFD_DA9052_SPI is not set # CONFIG_MFD_DA9052_I2C is not set # CONFIG_MFD_DA9055 is not set # CONFIG_MFD_MC13XXX_SPI is not set # CONFIG_MFD_MC13XXX_I2C is not set # CONFIG_HTC_EGPIO is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_HTC_I2CPLD is not set # CONFIG_MFD_88PM800 is not set # CONFIG_MFD_88PM805 is not set # CONFIG_MFD_88PM860X is not set # CONFIG_MFD_MAX77686 is not set # CONFIG_MFD_MAX77693 is not set # CONFIG_MFD_MAX8907 is not set # CONFIG_MFD_MAX8925 is not set # CONFIG_MFD_MAX8997 is not set # CONFIG_MFD_MAX8998 is not set # CONFIG_EZX_PCAP is not set # CONFIG_MFD_VIPERBOARD is not set # CONFIG_MFD_RETU is not set # CONFIG_MFD_PCF50633 is not set # CONFIG_MFD_RC5T583 is not set # CONFIG_MFD_SEC_CORE is not set # CONFIG_MFD_SI476X_CORE is not set # CONFIG_MFD_SM501 is not set # CONFIG_MFD_SMSC is not set # CONFIG_ABX500_CORE is not set # CONFIG_MFD_STMPE is not set # CONFIG_MFD_SYSCON is not set # CONFIG_MFD_TI_AM335X_TSCADC is not set # CONFIG_MFD_LP8788 is not set # CONFIG_MFD_PALMAS is not set # CONFIG_TPS6105X is not set # CONFIG_TPS65010 is not set # CONFIG_TPS6507X is not set # CONFIG_MFD_TPS65090 is not set # CONFIG_MFD_TPS65217 is not set # CONFIG_MFD_TPS6586X is not set # CONFIG_MFD_TPS65910 is not set # CONFIG_MFD_TPS65912 is not set # CONFIG_MFD_TPS65912_I2C is not set # CONFIG_MFD_TPS65912_SPI is not set # CONFIG_MFD_TPS80031 is not set # CONFIG_TWL4030_CORE is not set # CONFIG_TWL6040_CORE is not set # CONFIG_MFD_WL1273_CORE is not set # CONFIG_MFD_LM3533 is not set # CONFIG_MFD_TC3589X is not set # CONFIG_MFD_TMIO is not set # CONFIG_MFD_T7L66XB is not set # CONFIG_MFD_TC6387XB is not set # CONFIG_MFD_TC6393XB is not set # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_ARIZONA_SPI is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM831X_I2C is not set # CONFIG_MFD_WM831X_SPI is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_REGULATOR is not set # CONFIG_MEDIA_SUPPORT is not set # # Graphics support # # CONFIG_DRM is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set # CONFIG_FB_BOOT_VESA_SUPPORT is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set # CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set # CONFIG_FB_MODE_HELPERS is not set # CONFIG_FB_TILEBLITTING is not set # # Frame buffer hardware drivers # # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_GOLDFISH is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_AUO_K190X is not set CONFIG_FB_OMAP=y CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y # CONFIG_FB_OMAP_MANUAL_UPDATE is not set CONFIG_FB_OMAP_LCD_MIPID=y # CONFIG_FB_OMAP_DMA_TUNE is not set # CONFIG_EXYNOS_VIDEO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Console display driver support # CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y # CONFIG_LOGO_LINUX_VGA16 is not set # CONFIG_LOGO_LINUX_CLUT224 is not set # CONFIG_SOUND is not set # # HID support # CONFIG_HID=y # CONFIG_HIDRAW is not set # CONFIG_UHID is not set CONFIG_HID_GENERIC=y # # Special HID drivers # # CONFIG_HID_A4TECH is not set # CONFIG_HID_ACRUX is not set # CONFIG_HID_APPLE is not set # CONFIG_HID_APPLEIR is not set # CONFIG_HID_AUREAL is not set # CONFIG_HID_BELKIN is not set # CONFIG_HID_CHERRY is not set # CONFIG_HID_CHICONY is not set # CONFIG_HID_CYPRESS is not set # CONFIG_HID_DRAGONRISE is not set # CONFIG_HID_EMS_FF is not set # CONFIG_HID_ELECOM is not set # CONFIG_HID_EZKEY is not set # CONFIG_HID_HOLTEK is not set # CONFIG_HID_KEYTOUCH is not set # CONFIG_HID_KYE is not set # CONFIG_HID_UCLOGIC is not set # CONFIG_HID_WALTOP is not set # CONFIG_HID_GYRATION is not set # CONFIG_HID_ICADE is not set # CONFIG_HID_TWINHAN is not set # CONFIG_HID_KENSINGTON is not set # CONFIG_HID_LCPOWER is not set # CONFIG_HID_LENOVO_TPKBD is not set # CONFIG_HID_LOGITECH is not set # CONFIG_HID_MAGICMOUSE is not set # CONFIG_HID_MICROSOFT is not set # CONFIG_HID_MONTEREY is not set # CONFIG_HID_MULTITOUCH is not set # CONFIG_HID_NTRIG is not set # CONFIG_HID_ORTEK is not set # CONFIG_HID_PANTHERLORD is not set # CONFIG_HID_PETALYNX is not set # CONFIG_HID_PICOLCD is not set # CONFIG_HID_PRIMAX is not set # CONFIG_HID_PS3REMOTE is not set # CONFIG_HID_ROCCAT is not set # CONFIG_HID_SAITEK is not set # CONFIG_HID_SAMSUNG is not set # CONFIG_HID_SONY is not set # CONFIG_HID_SPEEDLINK is not set # CONFIG_HID_STEELSERIES is not set # CONFIG_HID_SUNPLUS is not set # CONFIG_HID_GREENASIA is not set # CONFIG_HID_SMARTJOYPLUS is not set # CONFIG_HID_TIVO is not set # CONFIG_HID_TOPSEED is not set # CONFIG_HID_THRUSTMASTER is not set # CONFIG_HID_ZEROPLUS is not set # CONFIG_HID_ZYDACRON is not set # CONFIG_HID_SENSOR_HUB is not set # # USB HID support # CONFIG_USB_HID=y # CONFIG_HID_PID is not set # CONFIG_USB_HIDDEV is not set # # I2C HID support # # CONFIG_I2C_HID is not set CONFIG_USB_ARCH_HAS_OHCI=y # CONFIG_USB_ARCH_HAS_EHCI is not set # CONFIG_USB_ARCH_HAS_XHCI is not set CONFIG_USB_SUPPORT=y CONFIG_USB_COMMON=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEFAULT_PERSIST=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_MON is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_HCD_OMAP1=y # CONFIG_USB_OHCI_HCD_PLATFORM is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may # # # also be needed; see USB_STORAGE Help for more info # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_REALTEK is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_STORAGE_ENE_UB6250 is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_DWC3 is not set # CONFIG_USB_CHIPIDEA is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_SEVSEG is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_YUREX is not set # CONFIG_USB_EZUSB_FX2 is not set # CONFIG_USB_HSIC_USB3503 is not set # CONFIG_USB_PHY is not set # CONFIG_USB_GADGET is not set CONFIG_MMC=y # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # CONFIG_MMC_CLKGATE is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=y CONFIG_MMC_BLOCK_MINORS=8 CONFIG_MMC_BLOCK_BOUNCE=y # CONFIG_SDIO_UART is not set # CONFIG_MMC_TEST is not set # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_SDHCI is not set # CONFIG_MMC_SDHCI_PXAV3 is not set # CONFIG_MMC_SDHCI_PXAV2 is not set CONFIG_MMC_OMAP=y # CONFIG_MMC_SPI is not set # CONFIG_MMC_DW is not set # CONFIG_MMC_VUB300 is not set # CONFIG_MMC_USHC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y # CONFIG_RTC_CLASS is not set CONFIG_DMADEVICES=y # CONFIG_DMADEVICES_DEBUG is not set # # DMA Devices # # CONFIG_DW_DMAC is not set # CONFIG_TIMB_DMA is not set CONFIG_DMA_OMAP=y CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=y # # DMA Clients # # CONFIG_ASYNC_TX_DMA is not set # CONFIG_DMATEST is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # CONFIG_VIRT_DRIVERS is not set # # Virtio drivers # # CONFIG_VIRTIO_MMIO is not set # # Microsoft Hyper-V guest support # # CONFIG_STAGING is not set CONFIG_CLKDEV_LOOKUP=y # # Hardware Spinlock drivers # CONFIG_CLKSRC_MMIO=y # CONFIG_MAILBOX is not set # CONFIG_IOMMU_SUPPORT is not set # # Remoteproc drivers # # CONFIG_STE_MODEM_RPROC is not set # # Rpmsg drivers # # CONFIG_PM_DEVFREQ is not set # CONFIG_EXTCON is not set # CONFIG_MEMORY is not set # CONFIG_IIO is not set # CONFIG_PWM is not set # CONFIG_IPACK_BUS is not set # CONFIG_RESET_CONTROLLER is not set # # File systems # # CONFIG_EXT2_FS is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4_FS is not set CONFIG_JBD=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_BTRFS_FS is not set # CONFIG_NILFS2_FS is not set # CONFIG_FS_POSIX_ACL is not set # CONFIG_FILE_LOCKING is not set # CONFIG_FSNOTIFY is not set # CONFIG_DNOTIFY is not set # CONFIG_INOTIFY_USER is not set # CONFIG_FANOTIFY is not set # CONFIG_QUOTA is not set # CONFIG_QUOTACTL is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # Caches # # CONFIG_FSCACHE is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # # CONFIG_MSDOS_FS is not set # CONFIG_VFAT_FS is not set # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ASCII is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_MAC_ROMAN is not set # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set # CONFIG_NLS_MAC_CROATIAN is not set # CONFIG_NLS_MAC_CYRILLIC is not set # CONFIG_NLS_MAC_GAELIC is not set # CONFIG_NLS_MAC_GREEK is not set # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set # CONFIG_NLS_MAC_ROMANIAN is not set # CONFIG_NLS_MAC_TURKISH is not set # CONFIG_NLS_UTF8 is not set # # Kernel hacking # CONFIG_PRINTK_TIME=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7 CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_READABLE_ASM is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set # CONFIG_LOCKUP_DETECTOR is not set # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 # CONFIG_DETECT_HUNG_TASK is not set # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_HAVE_DEBUG_KMEMLEAK=y # CONFIG_DEBUG_KMEMLEAK is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_INFO_REDUCED is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_MEMORY_INIT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_TEST_LIST_SORT is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_NOTIFIERS is not set # CONFIG_DEBUG_CREDENTIALS is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # # RCU Debugging # # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_RCU_TRACE is not set # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set # CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set # CONFIG_NOTIFIER_ERROR_INJECTION is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACING_SUPPORT=y # CONFIG_FTRACE is not set # CONFIG_RBTREE_TEST is not set # CONFIG_INTERVAL_TREE_TEST is not set # CONFIG_DMA_API_DEBUG is not set # CONFIG_ATOMIC64_SELFTEST is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_TEST_STRING_HELPERS is not set # CONFIG_TEST_KSTRTOX is not set # CONFIG_STRICT_DEVMEM is not set # CONFIG_ARM_UNWIND is not set # CONFIG_DEBUG_USER is not set # CONFIG_DEBUG_LL is not set CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S" CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h" # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY_DMESG_RESTRICT is not set # CONFIG_SECURITY is not set # CONFIG_SECURITYFS is not set CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" # CONFIG_CRYPTO is not set # CONFIG_BINARY_PRINTF is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IO=y # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set # CONFIG_CRC_T10DIF is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC32_SELFTEST is not set CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set # CONFIG_CRC8 is not set # CONFIG_XZ_DEC is not set # CONFIG_XZ_DEC_BCJ is not set CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_ATOMIC64=y CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y # CONFIG_AVERAGE is not set # CONFIG_CORDIC is not set # CONFIG_DDR is not set # CONFIG_VIRTUALIZATION is not set ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-29 18:55 ` Aaro Koskinen @ 2013-05-29 21:29 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-29 21:29 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 29/05/13 19:55, Aaro Koskinen wrote: > Hi, > > On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: >> Care to share the log? > > Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile > Retu this time, as it has nothing to do with GPIO IRQs being broken > on OMAP1. That's not entirely true. v3.10-rc3 is booting fine on an osk5912 and ethernet is working which is using a gpio for interrupts and it is getting interrupts. > 1) broken vanilla 3.10-rc3: serial wakeup GPIO irq gets IRQ 0 and no > other GPIO IRQs seen in /proc/interrupts. genirq error logs seen in boot. Getting 0 for the irq number definitely looks like the problem. > 2) working 3.10-rc3 with Tony's fix <== this fix should be applied > (http://marc.info/?l=linux-arm-kernel&m=136907202628855&w=2). GPIO IRQs > are normal, e.g. touchscreen can be used. > > 3) .config used. I am using the omap1_defconfig. Can you try that one for comparison? Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-29 21:29 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-29 21:29 UTC (permalink / raw) To: linux-arm-kernel On 29/05/13 19:55, Aaro Koskinen wrote: > Hi, > > On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: >> Care to share the log? > > Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile > Retu this time, as it has nothing to do with GPIO IRQs being broken > on OMAP1. That's not entirely true. v3.10-rc3 is booting fine on an osk5912 and ethernet is working which is using a gpio for interrupts and it is getting interrupts. > 1) broken vanilla 3.10-rc3: serial wakeup GPIO irq gets IRQ 0 and no > other GPIO IRQs seen in /proc/interrupts. genirq error logs seen in boot. Getting 0 for the irq number definitely looks like the problem. > 2) working 3.10-rc3 with Tony's fix <== this fix should be applied > (http://marc.info/?l=linux-arm-kernel&m=136907202628855&w=2). GPIO IRQs > are normal, e.g. touchscreen can be used. > > 3) .config used. I am using the omap1_defconfig. Can you try that one for comparison? Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-29 21:29 ` Jon Hunter @ 2013-05-29 22:41 ` Jon Hunter -1 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-29 22:41 UTC (permalink / raw) To: Aaro Koskinen Cc: Tony Lindgren, Grant Likely, linux-omap, Jon Hunter, linux-arm-kernel On 29/05/13 22:29, Jon Hunter wrote: > > On 29/05/13 19:55, Aaro Koskinen wrote: >> Hi, >> >> On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: >>> Care to share the log? >> >> Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile >> Retu this time, as it has nothing to do with GPIO IRQs being broken >> on OMAP1. > > That's not entirely true. v3.10-rc3 is booting fine on an osk5912 and > ethernet is working which is using a gpio for interrupts and it is > getting interrupts. Scratch that. It appears that the osk is using gpio-0 as the interrupt and so it is only by chance this is working. I agree it is broken and so Tony's fix is needed. Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-05-29 22:41 ` Jon Hunter 0 siblings, 0 replies; 58+ messages in thread From: Jon Hunter @ 2013-05-29 22:41 UTC (permalink / raw) To: linux-arm-kernel On 29/05/13 22:29, Jon Hunter wrote: > > On 29/05/13 19:55, Aaro Koskinen wrote: >> Hi, >> >> On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote: >>> Care to share the log? >> >> Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile >> Retu this time, as it has nothing to do with GPIO IRQs being broken >> on OMAP1. > > That's not entirely true. v3.10-rc3 is booting fine on an osk5912 and > ethernet is working which is using a gpio for interrupts and it is > getting interrupts. Scratch that. It appears that the osk is using gpio-0 as the interrupt and so it is only by chance this is working. I agree it is broken and so Tony's fix is needed. Jon ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-05-20 17:46 ` Tony Lindgren @ 2013-06-05 22:33 ` Grant Likely -1 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-05 22:33 UTC (permalink / raw) To: Tony Lindgren, Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap, Jon Hunter On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > caused by: > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > The commit reverts cleanly if we also revert > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > service routine), which seems to be just some minor optimization. The > > > result is below, and with it 770 works again. > > > > Hmm in this case it seems that we should just fix it rather than go back > > to the old code, so let's take a look at that first. > > Does the following fix it for you or do we need to fix something else > there too? > Hi Tony, Do you want me to apply this fix? It sounds like it solves the symptoms, but I'd like to know more about what the root cause is. Send me your s-o-b line and I'll apply the patch g. > > > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > + int irq_base; > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > - > - bank->domain = irq_domain_add_linear(node, bank->width, > - &irq_domain_simple_ops, NULL); > - if (!bank->domain) > + /* > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > + * > + * bank->domain = irq_domain_add_linear(node, bank->width, > + * &irq_domain_simple_ops, NULL); > + * if (!bank->domain) > + * return -ENODEV; > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > return -ENODEV; > + } > + > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-05 22:33 ` Grant Likely 0 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-05 22:33 UTC (permalink / raw) To: linux-arm-kernel On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > caused by: > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > The commit reverts cleanly if we also revert > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > service routine), which seems to be just some minor optimization. The > > > result is below, and with it 770 works again. > > > > Hmm in this case it seems that we should just fix it rather than go back > > to the old code, so let's take a look at that first. > > Does the following fix it for you or do we need to fix something else > there too? > Hi Tony, Do you want me to apply this fix? It sounds like it solves the symptoms, but I'd like to know more about what the root cause is. Send me your s-o-b line and I'll apply the patch g. > > > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > + int irq_base; > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > - > - bank->domain = irq_domain_add_linear(node, bank->width, > - &irq_domain_simple_ops, NULL); > - if (!bank->domain) > + /* > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > + * > + * bank->domain = irq_domain_add_linear(node, bank->width, > + * &irq_domain_simple_ops, NULL); > + * if (!bank->domain) > + * return -ENODEV; > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > return -ENODEV; > + } > + > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-05 22:33 ` Grant Likely @ 2013-06-06 15:53 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-06 15:53 UTC (permalink / raw) To: Grant Likely; +Cc: Aaro Koskinen, linux-arm-kernel, linux-omap, Jon Hunter * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > > caused by: > > > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > > > The commit reverts cleanly if we also revert > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > > service routine), which seems to be just some minor optimization. The > > > > result is below, and with it 770 works again. > > > > > > Hmm in this case it seems that we should just fix it rather than go back > > > to the old code, so let's take a look at that first. > > > > Does the following fix it for you or do we need to fix something else > > there too? > > > > Hi Tony, > > Do you want me to apply this fix? It sounds like it solves the symptoms, > but I'd like to know more about what the root cause is. > > Send me your s-o-b line and I'll apply the patch Yes sorry was meaning to send it as a proper patch, but got distracted. Please go ahead and apply it thanks: Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- a/drivers/gpio/gpio-omap.c > > +++ b/drivers/gpio/gpio-omap.c > > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > > const struct omap_gpio_platform_data *pdata; > > struct resource *res; > > struct gpio_bank *bank; > > + int irq_base; > > > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > > pdata->get_context_loss_count; > > } > > > > - > > - bank->domain = irq_domain_add_linear(node, bank->width, > > - &irq_domain_simple_ops, NULL); > > - if (!bank->domain) > > + /* > > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > > + * > > + * bank->domain = irq_domain_add_linear(node, bank->width, > > + * &irq_domain_simple_ops, NULL); > > + * if (!bank->domain) > > + * return -ENODEV; > > + */ > > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > > + if (irq_base < 0) { > > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > > return -ENODEV; > > + } > > + > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > > + 0, &irq_domain_simple_ops, NULL); > > > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > > bank->set_dataout = _set_gpio_dataout_reg; > > -- > Grant Likely, B.Sc, P.Eng. > Secret Lab Technologies, Ltd. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-06 15:53 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-06 15:53 UTC (permalink / raw) To: linux-arm-kernel * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > > caused by: > > > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > > > The commit reverts cleanly if we also revert > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > > service routine), which seems to be just some minor optimization. The > > > > result is below, and with it 770 works again. > > > > > > Hmm in this case it seems that we should just fix it rather than go back > > > to the old code, so let's take a look at that first. > > > > Does the following fix it for you or do we need to fix something else > > there too? > > > > Hi Tony, > > Do you want me to apply this fix? It sounds like it solves the symptoms, > but I'd like to know more about what the root cause is. > > Send me your s-o-b line and I'll apply the patch Yes sorry was meaning to send it as a proper patch, but got distracted. Please go ahead and apply it thanks: Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- a/drivers/gpio/gpio-omap.c > > +++ b/drivers/gpio/gpio-omap.c > > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > > const struct omap_gpio_platform_data *pdata; > > struct resource *res; > > struct gpio_bank *bank; > > + int irq_base; > > > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > > pdata->get_context_loss_count; > > } > > > > - > > - bank->domain = irq_domain_add_linear(node, bank->width, > > - &irq_domain_simple_ops, NULL); > > - if (!bank->domain) > > + /* > > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > > + * > > + * bank->domain = irq_domain_add_linear(node, bank->width, > > + * &irq_domain_simple_ops, NULL); > > + * if (!bank->domain) > > + * return -ENODEV; > > + */ > > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > > + if (irq_base < 0) { > > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > > return -ENODEV; > > + } > > + > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > > + 0, &irq_domain_simple_ops, NULL); > > > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > > bank->set_dataout = _set_gpio_dataout_reg; > > -- > Grant Likely, B.Sc, P.Eng. > Secret Lab Technologies, Ltd. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-06 15:53 ` Tony Lindgren @ 2013-06-23 22:16 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-23 22:16 UTC (permalink / raw) To: Grant Likely, Tony Lindgren; +Cc: linux-arm-kernel, linux-omap On Thu, Jun 06, 2013 at 08:53:41AM -0700, Tony Lindgren wrote: > * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: > > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > > > caused by: > > > > > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > > > > > The commit reverts cleanly if we also revert > > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > > > service routine), which seems to be just some minor optimization. The > > > > > result is below, and with it 770 works again. > > > > > > > > Hmm in this case it seems that we should just fix it rather than go back > > > > to the old code, so let's take a look at that first. > > > > > > Does the following fix it for you or do we need to fix something else > > > there too? > > > > > > > Hi Tony, > > > > Do you want me to apply this fix? It sounds like it solves the symptoms, > > but I'd like to know more about what the root cause is. > > > > Send me your s-o-b line and I'll apply the patch > > Yes sorry was meaning to send it as a proper patch, but got distracted. > Please go ahead and apply it thanks: > > Signed-off-by: Tony Lindgren <tony@atomide.com> What is the status of this patch? We're already at 3.10-rc7 and GPIO IRQs are still broken on OMAP1. A. > > > --- a/drivers/gpio/gpio-omap.c > > > +++ b/drivers/gpio/gpio-omap.c > > > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > > > const struct omap_gpio_platform_data *pdata; > > > struct resource *res; > > > struct gpio_bank *bank; > > > + int irq_base; > > > > > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > > > > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > > > pdata->get_context_loss_count; > > > } > > > > > > - > > > - bank->domain = irq_domain_add_linear(node, bank->width, > > > - &irq_domain_simple_ops, NULL); > > > - if (!bank->domain) > > > + /* > > > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > > > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > > > + * > > > + * bank->domain = irq_domain_add_linear(node, bank->width, > > > + * &irq_domain_simple_ops, NULL); > > > + * if (!bank->domain) > > > + * return -ENODEV; > > > + */ > > > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > > > + if (irq_base < 0) { > > > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > > > return -ENODEV; > > > + } > > > + > > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > > > + 0, &irq_domain_simple_ops, NULL); > > > > > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > > > bank->set_dataout = _set_gpio_dataout_reg; > > > > -- > > Grant Likely, B.Sc, P.Eng. > > Secret Lab Technologies, Ltd. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-23 22:16 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-23 22:16 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jun 06, 2013 at 08:53:41AM -0700, Tony Lindgren wrote: > * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: > > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: > > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: > > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: > > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: > > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: > > > > > > > > > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found > > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 > > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 > > > > > > > > > > > > > > The error is coming from regmap code. According to git bisect, it is > > > > > > > caused by: > > > > > > > > > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 > > > > > > > Author: Jon Hunter <jon-hunter@ti.com> > > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 > > > > > > > > > > > > > > gpio/omap: convert gpio irq domain to linear mapping > > > > > > > > > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried > > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... > > > > > > > > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution > > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. > > > > > > > > > > > > For the -rc cycle, it might be possible to fix this by adding a > > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. > > > > > > > > > > The commit reverts cleanly if we also revert > > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt > > > > > service routine), which seems to be just some minor optimization. The > > > > > result is below, and with it 770 works again. > > > > > > > > Hmm in this case it seems that we should just fix it rather than go back > > > > to the old code, so let's take a look at that first. > > > > > > Does the following fix it for you or do we need to fix something else > > > there too? > > > > > > > Hi Tony, > > > > Do you want me to apply this fix? It sounds like it solves the symptoms, > > but I'd like to know more about what the root cause is. > > > > Send me your s-o-b line and I'll apply the patch > > Yes sorry was meaning to send it as a proper patch, but got distracted. > Please go ahead and apply it thanks: > > Signed-off-by: Tony Lindgren <tony@atomide.com> What is the status of this patch? We're already at 3.10-rc7 and GPIO IRQs are still broken on OMAP1. A. > > > --- a/drivers/gpio/gpio-omap.c > > > +++ b/drivers/gpio/gpio-omap.c > > > @@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev) > > > const struct omap_gpio_platform_data *pdata; > > > struct resource *res; > > > struct gpio_bank *bank; > > > + int irq_base; > > > > > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > > > > > @@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev) > > > pdata->get_context_loss_count; > > > } > > > > > > - > > > - bank->domain = irq_domain_add_linear(node, bank->width, > > > - &irq_domain_simple_ops, NULL); > > > - if (!bank->domain) > > > + /* > > > + * REVISIT: Once we have omap1 supporting SPARSE_IRQ, we can drop > > > + * irq_alloc_descs() and irq_domain_add_legacy() and just do: > > > + * > > > + * bank->domain = irq_domain_add_linear(node, bank->width, > > > + * &irq_domain_simple_ops, NULL); > > > + * if (!bank->domain) > > > + * return -ENODEV; > > > + */ > > > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > > > + if (irq_base < 0) { > > > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > > > return -ENODEV; > > > + } > > > + > > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > > > + 0, &irq_domain_simple_ops, NULL); > > > > > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > > > bank->set_dataout = _set_gpio_dataout_reg; > > > > -- > > Grant Likely, B.Sc, P.Eng. > > Secret Lab Technologies, Ltd. > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-23 22:16 ` Aaro Koskinen @ 2013-06-23 23:06 ` Javier Martinez Canillas -1 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-23 23:06 UTC (permalink / raw) To: Aaro Koskinen Cc: Grant Likely, Tony Lindgren, linux-arm-kernel, linux-omap, Jon Hunter On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > On Thu, Jun 06, 2013 at 08:53:41AM -0700, Tony Lindgren wrote: >> * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: >> > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: >> > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: >> > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >> > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >> > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >> > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >> > > > > > > >> > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >> > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >> > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >> > > > > > > >> > > > > > > The error is coming from regmap code. According to git bisect, it is >> > > > > > > caused by: >> > > > > > > >> > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >> > > > > > > Author: Jon Hunter <jon-hunter@ti.com> >> > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 >> > > > > > > >> > > > > > > gpio/omap: convert gpio irq domain to linear mapping >> > > > > > > >> > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried >> > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... >> > > > > > >> > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution >> > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. >> > > > > > >> > > > > > For the -rc cycle, it might be possible to fix this by adding a >> > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. >> > > > > >> > > > > The commit reverts cleanly if we also revert >> > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >> > > > > service routine), which seems to be just some minor optimization. The >> > > > > result is below, and with it 770 works again. >> > > > >> > > > Hmm in this case it seems that we should just fix it rather than go back >> > > > to the old code, so let's take a look at that first. >> > > >> > > Does the following fix it for you or do we need to fix something else >> > > there too? >> > > >> > >> > Hi Tony, >> > >> > Do you want me to apply this fix? It sounds like it solves the symptoms, >> > but I'd like to know more about what the root cause is. >> > >> > Send me your s-o-b line and I'll apply the patch >> >> Yes sorry was meaning to send it as a proper patch, but got distracted. >> Please go ahead and apply it thanks: >> >> Signed-off-by: Tony Lindgren <tony@atomide.com> > > What is the status of this patch? We're already at 3.10-rc7 and GPIO > IRQs are still broken on OMAP1. > > A. > Hello, There is a problem with this patch. Currently with DeviceTree, using an OMAP GPIO as an IRQ is broken since before a driver can request the IRQ line, the GPIO bank has to be enabled and also the GPIO line has to be setup and configured as input with gpio_request(). This means that when defining: gpio6: gpio@49058000 { compatible = "ti,omap3-gpio"; reg = <0x49058000 0x200>; interrupts = <34>; ti,hwmods = "gpio6"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; interrupt-parent = <&gpio6>; interrupts = <16 8>; The GPIO is correctly mapped as an IRQ but a call to gpio_request() is never made and thus a all to request_irq() from the driver of the device using the GPIO-IRQ line fails. I posted the following patches that adds a custom .map function handler that calls gpio_request() automatically when an OMAP GPIO line is mapped as an IRQ: [v2,1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT [1]. [v2,2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT [2]. Now, this won't work if we revert to the legacy domain mapping. Of course we can came with a different solution but it will even more hack-ish than the one I posted. So I think that the correct solution is to add SPARSE_IRQ support to omap1 and not reverting Jon's patch. Of course this may not be possible since we are so close to 3.10 and most OMAP patches already merged for 3.11 but we should definitely try to have this at least for 3.12. Otherwise we won't be able to move to DT-only booting for OMAP2+. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2764821/ [2]: https://patchwork.kernel.org/patch/2764811/ ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-23 23:06 ` Javier Martinez Canillas 0 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-23 23:06 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > On Thu, Jun 06, 2013 at 08:53:41AM -0700, Tony Lindgren wrote: >> * Grant Likely <grant.likely@secretlab.ca> [130605 15:39]: >> > On Mon, 20 May 2013 10:46:21 -0700, Tony Lindgren <tony@atomide.com> wrote: >> > > * Tony Lindgren <tony@atomide.com> [130516 14:50]: >> > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130516 14:05]: >> > > > > On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote: >> > > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [130513 13:58]: >> > > > > > > I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken: >> > > > > > > >> > > > > > > [ 2.264221] retu-mfd 2-0001: Retu v3.2 found >> > > > > > > [ 2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12 >> > > > > > > [ 2.300140] retu-mfd: probe of 2-0001 failed with error -12 >> > > > > > > >> > > > > > > The error is coming from regmap code. According to git bisect, it is >> > > > > > > caused by: >> > > > > > > >> > > > > > > commit ede4d7a5b9835510fd1f724367f68d2fa4128453 >> > > > > > > Author: Jon Hunter <jon-hunter@ti.com> >> > > > > > > Date: Fri Mar 1 11:22:47 2013 -0600 >> > > > > > > >> > > > > > > gpio/omap: convert gpio irq domain to linear mapping >> > > > > > > >> > > > > > > The commit does not anymore revert cleanly, and I haven't yet tried >> > > > > > > crafting a manual revert, so any fix proposals/ideas are welcome... >> > > > > > >> > > > > > Hmm this might be a bit trickier to fix. Obviously the real solution >> > > > > > is to convert omap1 to SPARSE_IRQ like we did for omap2+. >> > > > > > >> > > > > > For the -rc cycle, it might be possible to fix this by adding a >> > > > > > different irq_to_gpio() and gpio_to_irq() functions for omap1. >> > > > > >> > > > > The commit reverts cleanly if we also revert >> > > > > 3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt >> > > > > service routine), which seems to be just some minor optimization. The >> > > > > result is below, and with it 770 works again. >> > > > >> > > > Hmm in this case it seems that we should just fix it rather than go back >> > > > to the old code, so let's take a look at that first. >> > > >> > > Does the following fix it for you or do we need to fix something else >> > > there too? >> > > >> > >> > Hi Tony, >> > >> > Do you want me to apply this fix? It sounds like it solves the symptoms, >> > but I'd like to know more about what the root cause is. >> > >> > Send me your s-o-b line and I'll apply the patch >> >> Yes sorry was meaning to send it as a proper patch, but got distracted. >> Please go ahead and apply it thanks: >> >> Signed-off-by: Tony Lindgren <tony@atomide.com> > > What is the status of this patch? We're already at 3.10-rc7 and GPIO > IRQs are still broken on OMAP1. > > A. > Hello, There is a problem with this patch. Currently with DeviceTree, using an OMAP GPIO as an IRQ is broken since before a driver can request the IRQ line, the GPIO bank has to be enabled and also the GPIO line has to be setup and configured as input with gpio_request(). This means that when defining: gpio6: gpio at 49058000 { compatible = "ti,omap3-gpio"; reg = <0x49058000 0x200>; interrupts = <34>; ti,hwmods = "gpio6"; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; interrupt-parent = <&gpio6>; interrupts = <16 8>; The GPIO is correctly mapped as an IRQ but a call to gpio_request() is never made and thus a all to request_irq() from the driver of the device using the GPIO-IRQ line fails. I posted the following patches that adds a custom .map function handler that calls gpio_request() automatically when an OMAP GPIO line is mapped as an IRQ: [v2,1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT [1]. [v2,2/2] gpio/omap: auto request GPIO as input if used as IRQ via DT [2]. Now, this won't work if we revert to the legacy domain mapping. Of course we can came with a different solution but it will even more hack-ish than the one I posted. So I think that the correct solution is to add SPARSE_IRQ support to omap1 and not reverting Jon's patch. Of course this may not be possible since we are so close to 3.10 and most OMAP patches already merged for 3.11 but we should definitely try to have this at least for 3.12. Otherwise we won't be able to move to DT-only booting for OMAP2+. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/2764821/ [2]: https://patchwork.kernel.org/patch/2764811/ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-23 23:06 ` Javier Martinez Canillas @ 2013-06-23 23:43 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-23 23:43 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Grant Likely, Tony Lindgren, linux-arm-kernel, linux-omap, Jon Hunter Hi, On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > What is the status of this patch? We're already at 3.10-rc7 and GPIO > > IRQs are still broken on OMAP1. [...] > There is a problem with this patch. [...] > So I think that the correct solution is to add SPARSE_IRQ support to > omap1 and not reverting Jon's patch. Of course this may not be > possible since we are so close to 3.10 and most OMAP patches already > merged for 3.11 but we should definitely try to have this at least for > 3.12. Otherwise we won't be able to move to DT-only booting for > OMAP2+. OMAP1 does not use DT. So we could put this code under #ifdef CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ work should not regress OMAP1. Demanding SPARSE_IRQ support for OMAP1 should have been discussed before these changes were made. It's not reasonable to assume such things can be made during rc-cycle. Also, now, I don't think it's reasonable to wait for that to be done, as it would take until 3.12 or even later to get OMAP1 functional again. A. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-23 23:43 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-23 23:43 UTC (permalink / raw) To: linux-arm-kernel Hi, On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > What is the status of this patch? We're already at 3.10-rc7 and GPIO > > IRQs are still broken on OMAP1. [...] > There is a problem with this patch. [...] > So I think that the correct solution is to add SPARSE_IRQ support to > omap1 and not reverting Jon's patch. Of course this may not be > possible since we are so close to 3.10 and most OMAP patches already > merged for 3.11 but we should definitely try to have this at least for > 3.12. Otherwise we won't be able to move to DT-only booting for > OMAP2+. OMAP1 does not use DT. So we could put this code under #ifdef CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ work should not regress OMAP1. Demanding SPARSE_IRQ support for OMAP1 should have been discussed before these changes were made. It's not reasonable to assume such things can be made during rc-cycle. Also, now, I don't think it's reasonable to wait for that to be done, as it would take until 3.12 or even later to get OMAP1 functional again. A. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-23 23:43 ` Aaro Koskinen @ 2013-06-24 1:01 ` Javier Martinez Canillas -1 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-24 1:01 UTC (permalink / raw) To: Aaro Koskinen Cc: Grant Likely, Tony Lindgren, linux-arm-kernel, linux-omap, Jon Hunter On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > Hi, > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> > IRQs are still broken on OMAP1. > > [...] > >> There is a problem with this patch. > > [...] > >> So I think that the correct solution is to add SPARSE_IRQ support to >> omap1 and not reverting Jon's patch. Of course this may not be >> possible since we are so close to 3.10 and most OMAP patches already >> merged for 3.11 but we should definitely try to have this at least for >> 3.12. Otherwise we won't be able to move to DT-only booting for >> OMAP2+. > > OMAP1 does not use DT. So we could put this code under #ifdef > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > work should not regress OMAP1. > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > these changes were made. It's not reasonable to assume such things can > be made during rc-cycle. Also, now, I don't think it's reasonable to > wait for that to be done, as it would take until 3.12 or even later to > get OMAP1 functional again. > > A. Hi, Yes, since we are so late in the -rc cycle and OMAP1 is currently broken I agree that the only sensible solution is to revert the patch for now. I just wanted to point out the issue that keeping the OMAP GPIO driver using legacy mapping domain represents a blocker to have GPIO-IRQ working with Device Tree for OMAP2+ Thanks a lot and best regards, Javier ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-24 1:01 ` Javier Martinez Canillas 0 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-24 1:01 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > Hi, > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> > IRQs are still broken on OMAP1. > > [...] > >> There is a problem with this patch. > > [...] > >> So I think that the correct solution is to add SPARSE_IRQ support to >> omap1 and not reverting Jon's patch. Of course this may not be >> possible since we are so close to 3.10 and most OMAP patches already >> merged for 3.11 but we should definitely try to have this at least for >> 3.12. Otherwise we won't be able to move to DT-only booting for >> OMAP2+. > > OMAP1 does not use DT. So we could put this code under #ifdef > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > work should not regress OMAP1. > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > these changes were made. It's not reasonable to assume such things can > be made during rc-cycle. Also, now, I don't think it's reasonable to > wait for that to be done, as it would take until 3.12 or even later to > get OMAP1 functional again. > > A. Hi, Yes, since we are so late in the -rc cycle and OMAP1 is currently broken I agree that the only sensible solution is to revert the patch for now. I just wanted to point out the issue that keeping the OMAP GPIO driver using legacy mapping domain represents a blocker to have GPIO-IRQ working with Device Tree for OMAP2+ Thanks a lot and best regards, Javier ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-24 1:01 ` Javier Martinez Canillas @ 2013-06-24 7:21 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-24 7:21 UTC (permalink / raw) To: Javier Martinez Canillas Cc: Aaro Koskinen, Grant Likely, linux-arm-kernel, linux-omap, Jon Hunter * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > Hi, > > > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> > IRQs are still broken on OMAP1. > > > > [...] > > > >> There is a problem with this patch. > > > > [...] > > > >> So I think that the correct solution is to add SPARSE_IRQ support to > >> omap1 and not reverting Jon's patch. Of course this may not be > >> possible since we are so close to 3.10 and most OMAP patches already > >> merged for 3.11 but we should definitely try to have this at least for > >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> OMAP2+. > > > > OMAP1 does not use DT. So we could put this code under #ifdef > > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > > work should not regress OMAP1. > > > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > > these changes were made. It's not reasonable to assume such things can > > be made during rc-cycle. Also, now, I don't think it's reasonable to > > wait for that to be done, as it would take until 3.12 or even later to > > get OMAP1 functional again. > > > > A. > > Hi, > > Yes, since we are so late in the -rc cycle and OMAP1 is currently > broken I agree that the only sensible solution is to revert the patch > for now. Agreed. > I just wanted to point out the issue that keeping the OMAP GPIO driver > using legacy mapping domain represents a blocker to have GPIO-IRQ > working with Device Tree for OMAP2+ Yes. We can do the ifdef Aaro suggested, and let's also plan on converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut away the dependency between these two. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-24 7:21 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-24 7:21 UTC (permalink / raw) To: linux-arm-kernel * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > > Hi, > > > > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> > IRQs are still broken on OMAP1. > > > > [...] > > > >> There is a problem with this patch. > > > > [...] > > > >> So I think that the correct solution is to add SPARSE_IRQ support to > >> omap1 and not reverting Jon's patch. Of course this may not be > >> possible since we are so close to 3.10 and most OMAP patches already > >> merged for 3.11 but we should definitely try to have this at least for > >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> OMAP2+. > > > > OMAP1 does not use DT. So we could put this code under #ifdef > > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > > work should not regress OMAP1. > > > > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > > these changes were made. It's not reasonable to assume such things can > > be made during rc-cycle. Also, now, I don't think it's reasonable to > > wait for that to be done, as it would take until 3.12 or even later to > > get OMAP1 functional again. > > > > A. > > Hi, > > Yes, since we are so late in the -rc cycle and OMAP1 is currently > broken I agree that the only sensible solution is to revert the patch > for now. Agreed. > I just wanted to point out the issue that keeping the OMAP GPIO driver > using legacy mapping domain represents a blocker to have GPIO-IRQ > working with Device Tree for OMAP2+ Yes. We can do the ifdef Aaro suggested, and let's also plan on converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut away the dependency between these two. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-24 7:21 ` Tony Lindgren @ 2013-06-24 15:35 ` Javier Martinez Canillas -1 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-24 15:35 UTC (permalink / raw) To: Tony Lindgren Cc: Aaro Koskinen, Grant Likely, linux-arm-kernel, linux-omap, Jon Hunter On Mon, Jun 24, 2013 at 9:21 AM, Tony Lindgren <tony@atomide.com> wrote: > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > Hi, >> > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> > IRQs are still broken on OMAP1. >> > >> > [...] >> > >> >> There is a problem with this patch. >> > >> > [...] >> > >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> merged for 3.11 but we should definitely try to have this at least for >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> OMAP2+. >> > >> > OMAP1 does not use DT. So we could put this code under #ifdef >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> > work should not regress OMAP1. >> > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> > these changes were made. It's not reasonable to assume such things can >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> > wait for that to be done, as it would take until 3.12 or even later to >> > get OMAP1 functional again. >> > >> > A. >> >> Hi, >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> broken I agree that the only sensible solution is to revert the patch >> for now. > > Agreed. > >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> working with Device Tree for OMAP2+ > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > away the dependency between these two. > > Regards, > > Tony Ok, so something like the following patch should do it (tested on an OMAP3 board): >From b9e262c688fb7f3ad733f140b55dddbc8e4716e6 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Date: Mon, 24 Jun 2013 17:13:23 +0200 Subject: [PATCH 1/1] gpio/omap: don't use linear domain mapping for OMAP1 commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ domain instead of using a legacy mapping. Not using a legacy mapping has a number of benefits but it requires the platform to support SPARSE_IRQ which currently is not supported on OMAP1. So this change caused a regression on OMAP1 platforms [1]. Since this issue is not present on all OMAP2+ platforms, there is no need to revert the driver to use legacy domain mapping for all the platforms. [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> --- drivers/gpio/gpio-omap.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index d3f7d2d..4a43036 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1094,6 +1094,9 @@ static int omap_gpio_probe(struct platform_device *pdev) const struct omap_gpio_platform_data *pdata; struct resource *res; struct gpio_bank *bank; +#ifdef CONFIG_ARCH_OMAP1 + int irq_base; +#endif match = of_match_device(of_match_ptr(omap_gpio_match), dev); @@ -1135,11 +1138,28 @@ static int omap_gpio_probe(struct platform_device *pdev) pdata->get_context_loss_count; } +#ifdef CONFIG_ARCH_OMAP1 + /* + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop + * irq_alloc_descs() and irq_domain_add_legacy() and just use a + * linear IRQ domain mapping for all OMAP platforms. + */ + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); + return -ENODEV; + } + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, + 0, &irq_domain_simple_ops, NULL); +#else bank->domain = irq_domain_add_linear(node, bank->width, &irq_domain_simple_ops, NULL); - if (!bank->domain) +#endif + if (!bank->domain) { + dev_err(dev, "Couldn't register an IRQ domain\n"); return -ENODEV; + } if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-24 15:35 ` Javier Martinez Canillas 0 siblings, 0 replies; 58+ messages in thread From: Javier Martinez Canillas @ 2013-06-24 15:35 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 24, 2013 at 9:21 AM, Tony Lindgren <tony@atomide.com> wrote: > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > Hi, >> > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> > IRQs are still broken on OMAP1. >> > >> > [...] >> > >> >> There is a problem with this patch. >> > >> > [...] >> > >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> merged for 3.11 but we should definitely try to have this at least for >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> OMAP2+. >> > >> > OMAP1 does not use DT. So we could put this code under #ifdef >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> > work should not regress OMAP1. >> > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> > these changes were made. It's not reasonable to assume such things can >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> > wait for that to be done, as it would take until 3.12 or even later to >> > get OMAP1 functional again. >> > >> > A. >> >> Hi, >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> broken I agree that the only sensible solution is to revert the patch >> for now. > > Agreed. > >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> working with Device Tree for OMAP2+ > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > away the dependency between these two. > > Regards, > > Tony Ok, so something like the following patch should do it (tested on an OMAP3 board): >From b9e262c688fb7f3ad733f140b55dddbc8e4716e6 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Date: Mon, 24 Jun 2013 17:13:23 +0200 Subject: [PATCH 1/1] gpio/omap: don't use linear domain mapping for OMAP1 commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ domain instead of using a legacy mapping. Not using a legacy mapping has a number of benefits but it requires the platform to support SPARSE_IRQ which currently is not supported on OMAP1. So this change caused a regression on OMAP1 platforms [1]. Since this issue is not present on all OMAP2+ platforms, there is no need to revert the driver to use legacy domain mapping for all the platforms. [1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg89005.html Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> --- drivers/gpio/gpio-omap.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index d3f7d2d..4a43036 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1094,6 +1094,9 @@ static int omap_gpio_probe(struct platform_device *pdev) const struct omap_gpio_platform_data *pdata; struct resource *res; struct gpio_bank *bank; +#ifdef CONFIG_ARCH_OMAP1 + int irq_base; +#endif match = of_match_device(of_match_ptr(omap_gpio_match), dev); @@ -1135,11 +1138,28 @@ static int omap_gpio_probe(struct platform_device *pdev) pdata->get_context_loss_count; } +#ifdef CONFIG_ARCH_OMAP1 + /* + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop + * irq_alloc_descs() and irq_domain_add_legacy() and just use a + * linear IRQ domain mapping for all OMAP platforms. + */ + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); + if (irq_base < 0) { + dev_err(dev, "Couldn't allocate IRQ numbers\n"); + return -ENODEV; + } + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, + 0, &irq_domain_simple_ops, NULL); +#else bank->domain = irq_domain_add_linear(node, bank->width, &irq_domain_simple_ops, NULL); - if (!bank->domain) +#endif + if (!bank->domain) { + dev_err(dev, "Couldn't register an IRQ domain\n"); return -ENODEV; + } if (bank->regs->set_dataout && bank->regs->clr_dataout) bank->set_dataout = _set_gpio_dataout_reg; -- 1.7.7.6 ^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-24 15:35 ` Javier Martinez Canillas @ 2013-06-25 18:14 ` Aaro Koskinen -1 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-25 18:14 UTC (permalink / raw) To: Javier Martinez Canillas, Tony Lindgren Cc: Grant Likely, linux-arm-kernel, linux-omap, Jon Hunter On Mon, Jun 24, 2013 at 05:35:18PM +0200, Javier Martinez Canillas wrote: > Ok, so something like the following patch should do it (tested on an > OMAP3 board): > > From b9e262c688fb7f3ad733f140b55dddbc8e4716e6 Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > Date: Mon, 24 Jun 2013 17:13:23 +0200 > Subject: [PATCH 1/1] gpio/omap: don't use linear domain mapping for OMAP1 > > commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") > converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ > domain instead of using a legacy mapping. Not using a legacy mapping has > a number of benefits but it requires the platform to support SPARSE_IRQ > which currently is not supported on OMAP1. > > So this change caused a regression on OMAP1 platforms [1]. > > Since this issue is not present on all OMAP2+ platforms, there is no need to > revert the driver to use legacy domain mapping for all the platforms. > > [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89005.html > > Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> I tested this on OMAP1 / 770, and it's fine. Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Thanks, A. > --- > drivers/gpio/gpio-omap.c | 22 +++++++++++++++++++++- > 1 files changed, 21 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index d3f7d2d..4a43036 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,9 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > +#ifdef CONFIG_ARCH_OMAP1 > + int irq_base; > +#endif > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1138,28 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > +#ifdef CONFIG_ARCH_OMAP1 > + /* > + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just use a > + * linear IRQ domain mapping for all OMAP platforms. > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > + return -ENODEV; > + } > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > +#else > bank->domain = irq_domain_add_linear(node, bank->width, > &irq_domain_simple_ops, NULL); > - if (!bank->domain) > +#endif > + if (!bank->domain) { > + dev_err(dev, "Couldn't register an IRQ domain\n"); > return -ENODEV; > + } > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; > -- > 1.7.7.6 ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-25 18:14 ` Aaro Koskinen 0 siblings, 0 replies; 58+ messages in thread From: Aaro Koskinen @ 2013-06-25 18:14 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 24, 2013 at 05:35:18PM +0200, Javier Martinez Canillas wrote: > Ok, so something like the following patch should do it (tested on an > OMAP3 board): > > From b9e262c688fb7f3ad733f140b55dddbc8e4716e6 Mon Sep 17 00:00:00 2001 > From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> > Date: Mon, 24 Jun 2013 17:13:23 +0200 > Subject: [PATCH 1/1] gpio/omap: don't use linear domain mapping for OMAP1 > > commit ede4d7a5 ("gpio/omap: convert gpio irq domain to linear mapping") > converted the OMAP GPIO driver to use a linear mapping for the GPIO IRQ > domain instead of using a legacy mapping. Not using a legacy mapping has > a number of benefits but it requires the platform to support SPARSE_IRQ > which currently is not supported on OMAP1. > > So this change caused a regression on OMAP1 platforms [1]. > > Since this issue is not present on all OMAP2+ platforms, there is no need to > revert the driver to use legacy domain mapping for all the platforms. > > [1]: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg89005.html > > Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> I tested this on OMAP1 / 770, and it's fine. Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Thanks, A. > --- > drivers/gpio/gpio-omap.c | 22 +++++++++++++++++++++- > 1 files changed, 21 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index d3f7d2d..4a43036 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -1094,6 +1094,9 @@ static int omap_gpio_probe(struct platform_device *pdev) > const struct omap_gpio_platform_data *pdata; > struct resource *res; > struct gpio_bank *bank; > +#ifdef CONFIG_ARCH_OMAP1 > + int irq_base; > +#endif > > match = of_match_device(of_match_ptr(omap_gpio_match), dev); > > @@ -1135,11 +1138,28 @@ static int omap_gpio_probe(struct platform_device *pdev) > pdata->get_context_loss_count; > } > > +#ifdef CONFIG_ARCH_OMAP1 > + /* > + * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop > + * irq_alloc_descs() and irq_domain_add_legacy() and just use a > + * linear IRQ domain mapping for all OMAP platforms. > + */ > + irq_base = irq_alloc_descs(-1, 0, bank->width, 0); > + if (irq_base < 0) { > + dev_err(dev, "Couldn't allocate IRQ numbers\n"); > + return -ENODEV; > + } > > + bank->domain = irq_domain_add_legacy(node, bank->width, irq_base, > + 0, &irq_domain_simple_ops, NULL); > +#else > bank->domain = irq_domain_add_linear(node, bank->width, > &irq_domain_simple_ops, NULL); > - if (!bank->domain) > +#endif > + if (!bank->domain) { > + dev_err(dev, "Couldn't register an IRQ domain\n"); > return -ENODEV; > + } > > if (bank->regs->set_dataout && bank->regs->clr_dataout) > bank->set_dataout = _set_gpio_dataout_reg; > -- > 1.7.7.6 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-24 7:21 ` Tony Lindgren @ 2013-06-24 15:53 ` Grant Likely -1 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-24 15:53 UTC (permalink / raw) To: Tony Lindgren Cc: Javier Martinez Canillas, Aaro Koskinen, linux-arm-kernel, linux-omap, Jon Hunter On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > Hi, >> > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> > IRQs are still broken on OMAP1. >> > >> > [...] >> > >> >> There is a problem with this patch. >> > >> > [...] >> > >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> merged for 3.11 but we should definitely try to have this at least for >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> OMAP2+. >> > >> > OMAP1 does not use DT. So we could put this code under #ifdef >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> > work should not regress OMAP1. >> > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> > these changes were made. It's not reasonable to assume such things can >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> > wait for that to be done, as it would take until 3.12 or even later to >> > get OMAP1 functional again. >> > >> > A. >> >> Hi, >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> broken I agree that the only sensible solution is to revert the patch >> for now. > > Agreed. > >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> working with Device Tree for OMAP2+ > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > away the dependency between these two. Alright. Sorry I dropped the ball on this one. I've lost track of which patch needs to get applied, but given that it is so late in the cycle, it would be better for someone else to apply the change, test and send a pull request to Linus. I'm okay with it going through the OMAP tree if that is the most expedient. Alternately, send me the pull request and I'll pass it on to Linus. g. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-24 15:53 ` Grant Likely 0 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-24 15:53 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> > Hi, >> > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> > IRQs are still broken on OMAP1. >> > >> > [...] >> > >> >> There is a problem with this patch. >> > >> > [...] >> > >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> merged for 3.11 but we should definitely try to have this at least for >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> OMAP2+. >> > >> > OMAP1 does not use DT. So we could put this code under #ifdef >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> > work should not regress OMAP1. >> > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> > these changes were made. It's not reasonable to assume such things can >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> > wait for that to be done, as it would take until 3.12 or even later to >> > get OMAP1 functional again. >> > >> > A. >> >> Hi, >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> broken I agree that the only sensible solution is to revert the patch >> for now. > > Agreed. > >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> working with Device Tree for OMAP2+ > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > away the dependency between these two. Alright. Sorry I dropped the ball on this one. I've lost track of which patch needs to get applied, but given that it is so late in the cycle, it would be better for someone else to apply the change, test and send a pull request to Linus. I'm okay with it going through the OMAP tree if that is the most expedient. Alternately, send me the pull request and I'll pass it on to Linus. g. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-24 15:53 ` Grant Likely @ 2013-06-25 7:04 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-25 7:04 UTC (permalink / raw) To: Grant Likely Cc: Javier Martinez Canillas, Aaro Koskinen, linux-arm-kernel, linux-omap, Jon Hunter * Grant Likely <grant.likely@secretlab.ca> [130624 09:00]: > On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > Hi, > >> > > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> >> > IRQs are still broken on OMAP1. > >> > > >> > [...] > >> > > >> >> There is a problem with this patch. > >> > > >> > [...] > >> > > >> >> So I think that the correct solution is to add SPARSE_IRQ support to > >> >> omap1 and not reverting Jon's patch. Of course this may not be > >> >> possible since we are so close to 3.10 and most OMAP patches already > >> >> merged for 3.11 but we should definitely try to have this at least for > >> >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> >> OMAP2+. > >> > > >> > OMAP1 does not use DT. So we could put this code under #ifdef > >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > >> > work should not regress OMAP1. > >> > > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > >> > these changes were made. It's not reasonable to assume such things can > >> > be made during rc-cycle. Also, now, I don't think it's reasonable to > >> > wait for that to be done, as it would take until 3.12 or even later to > >> > get OMAP1 functional again. > >> > > >> > A. > >> > >> Hi, > >> > >> Yes, since we are so late in the -rc cycle and OMAP1 is currently > >> broken I agree that the only sensible solution is to revert the patch > >> for now. > > > > Agreed. > > > >> I just wanted to point out the issue that keeping the OMAP GPIO driver > >> using legacy mapping domain represents a blocker to have GPIO-IRQ > >> working with Device Tree for OMAP2+ > > > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > > away the dependency between these two. > > Alright. Sorry I dropped the ball on this one. I've lost track of > which patch needs to get applied, but given that it is so late in the > cycle, it would be better for someone else to apply the change, test > and send a pull request to Linus. I'm okay with it going through the > OMAP tree if that is the most expedient. Alternately, send me the pull > request and I'll pass it on to Linus. OK, I'll wait for Aaro's ack on Javier's patch and then put it into a branch for you. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-25 7:04 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-25 7:04 UTC (permalink / raw) To: linux-arm-kernel * Grant Likely <grant.likely@secretlab.ca> [130624 09:00]: > On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: > > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: > >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> > Hi, > >> > > >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: > >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: > >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO > >> >> > IRQs are still broken on OMAP1. > >> > > >> > [...] > >> > > >> >> There is a problem with this patch. > >> > > >> > [...] > >> > > >> >> So I think that the correct solution is to add SPARSE_IRQ support to > >> >> omap1 and not reverting Jon's patch. Of course this may not be > >> >> possible since we are so close to 3.10 and most OMAP patches already > >> >> merged for 3.11 but we should definitely try to have this at least for > >> >> 3.12. Otherwise we won't be able to move to DT-only booting for > >> >> OMAP2+. > >> > > >> > OMAP1 does not use DT. So we could put this code under #ifdef > >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ > >> > work should not regress OMAP1. > >> > > >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before > >> > these changes were made. It's not reasonable to assume such things can > >> > be made during rc-cycle. Also, now, I don't think it's reasonable to > >> > wait for that to be done, as it would take until 3.12 or even later to > >> > get OMAP1 functional again. > >> > > >> > A. > >> > >> Hi, > >> > >> Yes, since we are so late in the -rc cycle and OMAP1 is currently > >> broken I agree that the only sensible solution is to revert the patch > >> for now. > > > > Agreed. > > > >> I just wanted to point out the issue that keeping the OMAP GPIO driver > >> using legacy mapping domain represents a blocker to have GPIO-IRQ > >> working with Device Tree for OMAP2+ > > > > Yes. We can do the ifdef Aaro suggested, and let's also plan on > > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut > > away the dependency between these two. > > Alright. Sorry I dropped the ball on this one. I've lost track of > which patch needs to get applied, but given that it is so late in the > cycle, it would be better for someone else to apply the change, test > and send a pull request to Linus. I'm okay with it going through the > OMAP tree if that is the most expedient. Alternately, send me the pull > request and I'll pass it on to Linus. OK, I'll wait for Aaro's ack on Javier's patch and then put it into a branch for you. Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-25 7:04 ` Tony Lindgren @ 2013-06-25 11:49 ` Grant Likely -1 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-25 11:49 UTC (permalink / raw) To: Tony Lindgren Cc: Javier Martinez Canillas, Aaro Koskinen, linux-arm-kernel, linux-omap, Jon Hunter On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren <tony@atomide.com> wrote: > * Grant Likely <grant.likely@secretlab.ca> [130624 09:00]: >> On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: >> > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > Hi, >> >> > >> >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> >> > IRQs are still broken on OMAP1. >> >> > >> >> > [...] >> >> > >> >> >> There is a problem with this patch. >> >> > >> >> > [...] >> >> > >> >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> >> merged for 3.11 but we should definitely try to have this at least for >> >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> >> OMAP2+. >> >> > >> >> > OMAP1 does not use DT. So we could put this code under #ifdef >> >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> >> > work should not regress OMAP1. >> >> > >> >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> >> > these changes were made. It's not reasonable to assume such things can >> >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> >> > wait for that to be done, as it would take until 3.12 or even later to >> >> > get OMAP1 functional again. >> >> > >> >> > A. >> >> >> >> Hi, >> >> >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> >> broken I agree that the only sensible solution is to revert the patch >> >> for now. >> > >> > Agreed. >> > >> >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> >> working with Device Tree for OMAP2+ >> > >> > Yes. We can do the ifdef Aaro suggested, and let's also plan on >> > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut >> > away the dependency between these two. >> >> Alright. Sorry I dropped the ball on this one. I've lost track of >> which patch needs to get applied, but given that it is so late in the >> cycle, it would be better for someone else to apply the change, test >> and send a pull request to Linus. I'm okay with it going through the >> OMAP tree if that is the most expedient. Alternately, send me the pull >> request and I'll pass it on to Linus. > > OK, I'll wait for Aaro's ack on Javier's patch and then put it into a > branch for you. Thanks Tony. g. ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-25 11:49 ` Grant Likely 0 siblings, 0 replies; 58+ messages in thread From: Grant Likely @ 2013-06-25 11:49 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren <tony@atomide.com> wrote: > * Grant Likely <grant.likely@secretlab.ca> [130624 09:00]: >> On Mon, Jun 24, 2013 at 8:21 AM, Tony Lindgren <tony@atomide.com> wrote: >> > * Javier Martinez Canillas <martinez.javier@gmail.com> [130623 18:08]: >> >> On Mon, Jun 24, 2013 at 1:43 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> > Hi, >> >> > >> >> > On Mon, Jun 24, 2013 at 01:06:37AM +0200, Javier Martinez Canillas wrote: >> >> >> On Mon, Jun 24, 2013 at 12:16 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote: >> >> >> > What is the status of this patch? We're already at 3.10-rc7 and GPIO >> >> >> > IRQs are still broken on OMAP1. >> >> > >> >> > [...] >> >> > >> >> >> There is a problem with this patch. >> >> > >> >> > [...] >> >> > >> >> >> So I think that the correct solution is to add SPARSE_IRQ support to >> >> >> omap1 and not reverting Jon's patch. Of course this may not be >> >> >> possible since we are so close to 3.10 and most OMAP patches already >> >> >> merged for 3.11 but we should definitely try to have this at least for >> >> >> 3.12. Otherwise we won't be able to move to DT-only booting for >> >> >> OMAP2+. >> >> > >> >> > OMAP1 does not use DT. So we could put this code under #ifdef >> >> > CONFIG_ARCH_OMAP1 or similar. It's just a few lines of code. OMAP2+ >> >> > work should not regress OMAP1. >> >> > >> >> > Demanding SPARSE_IRQ support for OMAP1 should have been discussed before >> >> > these changes were made. It's not reasonable to assume such things can >> >> > be made during rc-cycle. Also, now, I don't think it's reasonable to >> >> > wait for that to be done, as it would take until 3.12 or even later to >> >> > get OMAP1 functional again. >> >> > >> >> > A. >> >> >> >> Hi, >> >> >> >> Yes, since we are so late in the -rc cycle and OMAP1 is currently >> >> broken I agree that the only sensible solution is to revert the patch >> >> for now. >> > >> > Agreed. >> > >> >> I just wanted to point out the issue that keeping the OMAP GPIO driver >> >> using legacy mapping domain represents a blocker to have GPIO-IRQ >> >> working with Device Tree for OMAP2+ >> > >> > Yes. We can do the ifdef Aaro suggested, and let's also plan on >> > converting omap1 to use SPARSE_IRQ. But with the ifdef we can cut >> > away the dependency between these two. >> >> Alright. Sorry I dropped the ball on this one. I've lost track of >> which patch needs to get applied, but given that it is so late in the >> cycle, it would be better for someone else to apply the change, test >> and send a pull request to Linus. I'm okay with it going through the >> OMAP tree if that is the most expedient. Alternately, send me the pull >> request and I'll pass it on to Linus. > > OK, I'll wait for Aaro's ack on Javier's patch and then put it into a > branch for you. Thanks Tony. g. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression 2013-06-25 11:49 ` Grant Likely @ 2013-06-26 7:06 ` Tony Lindgren -1 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-26 7:06 UTC (permalink / raw) To: Grant Likely Cc: Javier Martinez Canillas, Aaro Koskinen, linux-arm-kernel, linux-omap, Jon Hunter * Grant Likely <grant.likely@secretlab.ca> [130625 04:56]: > On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren <tony@atomide.com> wrote: > > > > OK, I'll wait for Aaro's ack on Javier's patch and then put it into a > > branch for you. > > Thanks Tony. Pull request sent as "[GIT PULL] GPIO regression fix for omap1 for v3.10-rc". Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
* [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression @ 2013-06-26 7:06 ` Tony Lindgren 0 siblings, 0 replies; 58+ messages in thread From: Tony Lindgren @ 2013-06-26 7:06 UTC (permalink / raw) To: linux-arm-kernel * Grant Likely <grant.likely@secretlab.ca> [130625 04:56]: > On Tue, Jun 25, 2013 at 8:04 AM, Tony Lindgren <tony@atomide.com> wrote: > > > > OK, I'll wait for Aaro's ack on Javier's patch and then put it into a > > branch for you. > > Thanks Tony. Pull request sent as "[GIT PULL] GPIO regression fix for omap1 for v3.10-rc". Regards, Tony ^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~2013-06-26 7:06 UTC | newest] Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-13 20:53 [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression Aaro Koskinen 2013-05-13 20:53 ` Aaro Koskinen 2013-05-16 18:09 ` Tony Lindgren 2013-05-16 18:09 ` Tony Lindgren 2013-05-16 21:00 ` Aaro Koskinen 2013-05-16 21:00 ` Aaro Koskinen 2013-05-16 21:44 ` Tony Lindgren 2013-05-16 21:44 ` Tony Lindgren 2013-05-20 17:46 ` Tony Lindgren 2013-05-20 17:46 ` Tony Lindgren 2013-05-21 17:39 ` Aaro Koskinen 2013-05-21 17:39 ` Aaro Koskinen 2013-05-21 19:37 ` Jon Hunter 2013-05-21 19:37 ` Jon Hunter 2013-05-22 21:20 ` Aaro Koskinen 2013-05-22 21:20 ` Aaro Koskinen 2013-05-23 19:02 ` Jon Hunter 2013-05-23 19:02 ` Jon Hunter 2013-05-23 20:13 ` Aaro Koskinen 2013-05-23 20:13 ` Aaro Koskinen 2013-05-28 18:41 ` Jon Hunter 2013-05-28 18:41 ` Jon Hunter 2013-05-26 19:07 ` Aaro Koskinen 2013-05-26 19:07 ` Aaro Koskinen 2013-05-28 18:42 ` Jon Hunter 2013-05-28 18:42 ` Jon Hunter 2013-05-29 18:55 ` Aaro Koskinen 2013-05-29 18:55 ` Aaro Koskinen 2013-05-29 21:29 ` Jon Hunter 2013-05-29 21:29 ` Jon Hunter 2013-05-29 22:41 ` Jon Hunter 2013-05-29 22:41 ` Jon Hunter 2013-06-05 22:33 ` Grant Likely 2013-06-05 22:33 ` Grant Likely 2013-06-06 15:53 ` Tony Lindgren 2013-06-06 15:53 ` Tony Lindgren 2013-06-23 22:16 ` Aaro Koskinen 2013-06-23 22:16 ` Aaro Koskinen 2013-06-23 23:06 ` Javier Martinez Canillas 2013-06-23 23:06 ` Javier Martinez Canillas 2013-06-23 23:43 ` Aaro Koskinen 2013-06-23 23:43 ` Aaro Koskinen 2013-06-24 1:01 ` Javier Martinez Canillas 2013-06-24 1:01 ` Javier Martinez Canillas 2013-06-24 7:21 ` Tony Lindgren 2013-06-24 7:21 ` Tony Lindgren 2013-06-24 15:35 ` Javier Martinez Canillas 2013-06-24 15:35 ` Javier Martinez Canillas 2013-06-25 18:14 ` Aaro Koskinen 2013-06-25 18:14 ` Aaro Koskinen 2013-06-24 15:53 ` Grant Likely 2013-06-24 15:53 ` Grant Likely 2013-06-25 7:04 ` Tony Lindgren 2013-06-25 7:04 ` Tony Lindgren 2013-06-25 11:49 ` Grant Likely 2013-06-25 11:49 ` Grant Likely 2013-06-26 7:06 ` Tony Lindgren 2013-06-26 7:06 ` Tony Lindgren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.