Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1408287 > unrolled thread

pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Back to article view | Back to linux.kernel

Contents

  pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl  for device-tree machines' Guenter Roeck <linux@roeck-us.net> - 2016-05-27 22:30 +0200
    Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines' Robert Jarzmik <robert.jarzmik@free.fr> - 2016-05-28 10:30 +0200
      Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl  for device-tree machines' Guenter Roeck <linux@roeck-us.net> - 2016-05-28 23:20 +0200
        Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines' Robert Jarzmik <robert.jarzmik@free.fr> - 2016-05-31 08:30 +0200
          Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl  for device-tree machines' Guenter Roeck <linux@roeck-us.net> - 2016-05-31 17:00 +0200

#1408287 — pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Hi,

your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree
machines") causes various non-devicetree systems to fail with the following
error messages when running a pxa_defconfig image.

During boot:

Can't request reset_gpio

At reboot:

reboot: Restarting system
------------[ cut here ]------------
kernel BUG at arch/arm/mach-pxa/reset.c:59!
...

Added logging shows that the error seen when trying to request the reset gpio
is -EPROBE_DEFER, and that the pxa gpio driver is not instantiated.

This is seen when attempting to run akita, borzoi, spitz, terrier, or tosa
in qemu with pxa_defconfig. Reverting your patch fixes the problem.

Is this on purpose ? Unless I am missing something, it effectively means that
pxa_defconfig no longer works for pxa3xx systems, since those do not support
devicetree (or at least there is no devicetree file which includes pxa3xx.dtsi).

Thanks,
Guenter

[toc] | [next] | [standalone]

#1408394 — Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Guenter Roeck <linux@roeck-us.net> writes:

> Hi,
>
> your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree
> machines") causes various non-devicetree systems to fail with the following
> error messages when running a pxa_defconfig image.
Ah yes, you're right.

>
> During boot:
>
> Can't request reset_gpio
>
> At reboot:
>
> reboot: Restarting system
> ------------[ cut here ]------------
> kernel BUG at arch/arm/mach-pxa/reset.c:59!
> ...
>
> Added logging shows that the error seen when trying to request the reset gpio
> is -EPROBE_DEFER, and that the pxa gpio driver is not instantiated.
>
> This is seen when attempting to run akita, borzoi, spitz, terrier, or tosa
> in qemu with pxa_defconfig. Reverting your patch fixes the problem.
>
> Is this on purpose ?
Well no :)
The real reason behind is that gpio handling for pxa in its current state cannot
be built for _both_ a devicetree machine (ie. pxa-dt.c) and a non devicetree
machine (ie. corgi, tosa, ...).

This is turn is because for devicetree a pinctrl is enforced for the machine,
and a pinctrl driver is required. If it's not available, pxa_gpio_request()
fails on pinctrl_request_gpio() and returns -EPROBE_DEFER.

Now the true chicken and egg problem is than machine files,
ie. arch/arm/mach-pxa/xxx.c are using gpio before the drivers are probed, in the
init_machine() function, and that's why pinctrl/gpio for legacy machine files is
a bit difficult.

> Unless I am missing something, it effectively means that
> pxa_defconfig no longer works for pxa3xx systems, since those do not support
> devicetree (or at least there is no devicetree file which includes
> pxa3xx.dtsi).
I'd rather say that pxa_defconfig doesn't work anymore on any legacy system.
Its first purpose was to ensure compilation coverage of all legacy pxa systems.
Its second one was to have a single kernel bootable on all legacy pxa systems.

Therefore, would you tell me if the patch in [1] fixes your issue ?

Cheers.

-- 
Robert

[1] One solution
---8<---
From d6079c9cce351e217df947b4c5e243d350c39823 Mon Sep 17 00:00:00 2001
From: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Sat, 28 May 2016 10:17:33 +0200
Subject: [PATCH] ARM: pxa: remove devicetree boards from pxa_defconfig

If both legacy and device-tree machines are mixed in the same defconfig,
the legacy boards don't boot up anymore with gpio request deferral
errors.

This is seen when attempting to run akita, borzoi, spitz, terrier, or
tosa in qemu with pxa_defconfig.

The real reason behind is that gpio handling for pxa in its current state cannot
be built for _both_ a devicetree machine (ie. pxa-dt.c) and a non devicetree
machine (ie. corgi, tosa, ...).

This is turn is because for devicetree a pinctrl is enforced for the
machine, and a pinctrl driver is required. If it's not available,
pxa_gpio_request() fails on pinctrl_request_gpio() and returns
-EPROBE_DEFER.  It was introduced by commit :
    f806dac5938b ("ARM: pxa: activate pinctrl for device-tree machines")

Now the true chicken and egg problem is than machine files,
ie. arch/arm/mach-pxa/xxx.c are using gpio before the drivers are probed, in the
init_machine() function, and that's why pinctrl/gpio for legacy machine files is
a bit difficult.

As for now, to keep the compilation coverage and testing of legacy
machines, this patch removes the 2 devicetree machines from pxa_defconfig.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
 arch/arm/configs/pxa_defconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index dc5517eaf09f..a016ecc0084b 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -26,8 +26,6 @@ CONFIG_PARTITION_ADVANCED=y
 CONFIG_LDM_PARTITION=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_PXA=y
-CONFIG_MACH_PXA27X_DT=y
-CONFIG_MACH_PXA3XX_DT=y
 CONFIG_ARCH_LUBBOCK=y
 CONFIG_MACH_MAINSTONE=y
 CONFIG_MACH_ZYLONITE300=y
-- 
2.1.4

[toc] | [prev] | [next] | [standalone]

#1408524

On 05/28/2016 01:24 AM, Robert Jarzmik wrote:
> Guenter Roeck <linux@roeck-us.net> writes:
>
>> Hi,
>>
>> your mainline commit f806dac5938b ("ARM: pxa: activate pinctrl for device-tree
>> machines") causes various non-devicetree systems to fail with the following
>> error messages when running a pxa_defconfig image.
> Ah yes, you're right.
>
>>
>> During boot:
>>
>> Can't request reset_gpio
>>
>> At reboot:
>>
>> reboot: Restarting system
>> ------------[ cut here ]------------
>> kernel BUG at arch/arm/mach-pxa/reset.c:59!
>> ...
>>
>> Added logging shows that the error seen when trying to request the reset gpio
>> is -EPROBE_DEFER, and that the pxa gpio driver is not instantiated.
>>
>> This is seen when attempting to run akita, borzoi, spitz, terrier, or tosa
>> in qemu with pxa_defconfig. Reverting your patch fixes the problem.
>>
>> Is this on purpose ?
> Well no :)
> The real reason behind is that gpio handling for pxa in its current state cannot
> be built for _both_ a devicetree machine (ie. pxa-dt.c) and a non devicetree
> machine (ie. corgi, tosa, ...).
>
> This is turn is because for devicetree a pinctrl is enforced for the machine,
> and a pinctrl driver is required. If it's not available, pxa_gpio_request()
> fails on pinctrl_request_gpio() and returns -EPROBE_DEFER.
>
> Now the true chicken and egg problem is than machine files,
> ie. arch/arm/mach-pxa/xxx.c are using gpio before the drivers are probed, in the
> init_machine() function, and that's why pinctrl/gpio for legacy machine files is
> a bit difficult.
>
>> Unless I am missing something, it effectively means that
>> pxa_defconfig no longer works for pxa3xx systems, since those do not support
>> devicetree (or at least there is no devicetree file which includes
>> pxa3xx.dtsi).
> I'd rather say that pxa_defconfig doesn't work anymore on any legacy system.
> Its first purpose was to ensure compilation coverage of all legacy pxa systems.
> Its second one was to have a single kernel bootable on all legacy pxa systems.
>
> Therefore, would you tell me if the patch in [1] fixes your issue ?
>

Yes, it does. It is actually the workaround I deployed for my test builds,
since I thought that the change was on purpose.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1409834 — Re: pxa_defconfig runtime failures due to 'ARM: pxa: activate pinctrl for device-tree machines'

Guenter Roeck <linux@roeck-us.net> writes:

> On 05/28/2016 01:24 AM, Robert Jarzmik wrote:
>> Guenter Roeck <linux@roeck-us.net> writes:
>>
>>> Hi,
>> I'd rather say that pxa_defconfig doesn't work anymore on any legacy system.
>> Its first purpose was to ensure compilation coverage of all legacy pxa systems.
>> Its second one was to have a single kernel bootable on all legacy pxa systems.
>>
>> Therefore, would you tell me if the patch in [1] fixes your issue ?
>>
>
> Yes, it does. It is actually the workaround I deployed for my test builds,
> since I thought that the change was on purpose.

Good. Can I take that as a Tested-by ?

Cheers.

-- 
Robert

[toc] | [prev] | [next] | [standalone]

#1410361

On 05/30/2016 11:27 PM, Robert Jarzmik wrote:
> Guenter Roeck <linux@roeck-us.net> writes:
>
>> On 05/28/2016 01:24 AM, Robert Jarzmik wrote:
>>> Guenter Roeck <linux@roeck-us.net> writes:
>>>
>>>> Hi,
>>> I'd rather say that pxa_defconfig doesn't work anymore on any legacy system.
>>> Its first purpose was to ensure compilation coverage of all legacy pxa systems.
>>> Its second one was to have a single kernel bootable on all legacy pxa systems.
>>>
>>> Therefore, would you tell me if the patch in [1] fixes your issue ?
>>>
>>
>> Yes, it does. It is actually the workaround I deployed for my test builds,
>> since I thought that the change was on purpose.
>
> Good. Can I take that as a Tested-by ?
>
Yes.

Guenter

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web