Palmetto GPIO pin configuration for Voltage Translator Control

Palmetto GPIO pin configuration for Voltage Translator Control

[Christopher Bostic]

I'm attempting to identify the present owner of the 'Voltage
Translator Control' pin (H6).  This should be owned by the OpenFSI
device driver but the GPIO Linux driver indicates this pin is in use
when OpenFSI attempts to grab it.   Talking with Brad Bishop it
appears that H6 is not defined in
openbmc/skeleton/blob/master/configs/Palmetto.py .   The OpenFSI
driver can successfully grab the other pins it needs which are defined
in this file:  FSI_DATA, FSI_ENABLE, FSI_CLK, CRONUS_SEL.

File excerpt:

GPIO_CONFIG = {} GPIO_CONFIG['FSI_CLK'] = { 'gpio_pin': 'A4',
'direction': 'out' } GPIO_CONFIG['FSI_DATA'] = { 'gpio_pin': 'A5',
'direction': 'out' } GPIO_CONFIG['FSI_ENABLE'] = { 'gpio_pin': 'D0',
'direction': 'out' } GPIO_CONFIG['POWER_PIN'] = { 'gpio_pin': 'E1',
'direction': 'out' } GPIO_CONFIG['CRONUS_SEL'] = { 'gpio_pin': 'A6',
'direction': 'out' }
.
.
.

Can an entry for the voltage translator control pin be added to this
or is there a reason it is not defined in Palmetto.py?   Additionally,
any other code using this pin should be updated to not touch it.

Note that this is not directly related to the GPIO hog updates that
are in process of being added to the palmetto device tree.  This issue
exists without that change.

Any input would be appreciated.

Thanks,
Chris

Re: Palmetto GPIO pin configuration for Voltage Translator Control

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Mon, 2016-11-28 at 14:56 -0600, Christopher Bostic wrote:
> Note that this is not directly related to the GPIO hog updates that
> are in process of being added to the palmetto device tree.

So, to clarify:

The patch I sent to the list a week or so ago isn't in the process of
being applied in any way for two reasons:

1. Per Joel's reply it will not be carried in the OpenBMC kernel tree
2. The OpenBMC bitbake build process *already* applies it to the kernel
during its build process, as of September. The patch is carried in the
OpenBMC tree[1].

[1] https://github.com/openbmc/openbmc/blob/a103a3723b4329225d9316393bf0620027d02aa6/meta-openbmc-bsp/meta-aspeed/meta-ast2400/recipes-kernel/linux/linux-obmc_%25.bbappend#L3

> This issue exists without that change.

You can confirm the presence of the hog at runtime either from dmesg or
sysfs:

    # ls -1     /sys/firmware/devicetree/base/ahb/apb/gpio@1e780000     | grep h6
    pin_gpio_h6
    # dmesg | grep -i h6
    GPIO line 382 (H6) hogged as output/high

If you are booting your own kernel built directly from the OpenBMC
kernel tree with your patches applied and are still seeing the pin in
use then that's certainly odd. The existence of the hogs patch can be
ignored and we need to investigate what is going on.

However, if you are booting the kernel produced from the OpenBMC
bitbake build process, then seeing this pin in use is expected
behaviour as the hogs patch will have been applied.

Can you please detail how you are building the kernel you are testing?
I want to make sure we're not sneaking in the patch when you weren't
expecting it.

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Palmetto GPIO pin configuration for Voltage Translator Control

[Christopher Bostic]

On Mon, Nov 28, 2016 at 6:15 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Mon, 2016-11-28 at 14:56 -0600, Christopher Bostic wrote:
>> Note that this is not directly related to the GPIO hog updates that
>> are in process of being added to the palmetto device tree.
>
> So, to clarify:
>
> The patch I sent to the list a week or so ago isn't in the process of
> being applied in any way for two reasons:
>
> 1. Per Joel's reply it will not be carried in the OpenBMC kernel tree
> 2. The OpenBMC bitbake build process *already* applies it to the kernel
> during its build process, as of September. The patch is carried in the
> OpenBMC tree[1].
>
> [1] https://github.com/openbmc/openbmc/blob/a103a3723b4329225d9316393bf0620027d02aa6/meta-openbmc-bsp/meta-aspeed/meta-ast2400/recipes-kernel/linux/linux-obmc_%25.bbappend#L3
>
>> This issue exists without that change.
>
> You can confirm the presence of the hog at runtime either from dmesg or
> sysfs:
>
>     # ls -1     /sys/firmware/devicetree/base/ahb/apb/gpio@1e780000     | grep h6
>     pin_gpio_h6
>     # dmesg | grep -i h6
>     GPIO line 382 (H6) hogged as output/high
>

Hi Andrew,

The hog messages weren't there prior in my tests.  I was using a
slightly older dev-4.7 kernel and the Palmetto dts file didn't have
the hog definitions.

> If you are booting your own kernel built directly from the OpenBMC
> kernel tree with your patches applied and are still seeing the pin in
> use then that's certainly odd. The existence of the hogs patch can be
> ignored and we need to investigate what is going on.

I have been booting my own kernel from a forked version of the OpenBMC
kernel tree using the bitbake build process.  Maybe I had missed some
updates.  In any case, today I updated to the dts file with all the
hog definitions and removed only the H7 pin lines.   I see that H7 is
not hogged and that I can successfully grab the pin.  I wasn't able to
do this before.  I'll back up to v4.9-rc1 and see if the problem is
resolved there as well.

Still not clear to me what was grabbing the pin prior to this.

Thanks for your input
Chris

>
> However, if you are booting the kernel produced from the OpenBMC
> bitbake build process, then seeing this pin in use is expected
> behaviour as the hogs patch will have been applied.
>
> Can you please detail how you are building the kernel you are testing?
> I want to make sure we're not sneaking in the patch when you weren't
> expecting it.
>
> Cheers,
>
> Andrew

Re: Palmetto GPIO pin configuration for Voltage Translator Control

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 3741 bytes --]

On Tue, 2016-11-29 at 11:55 -0600, Christopher Bostic wrote:
> > On Mon, Nov 28, 2016 at 6:15 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > On Mon, 2016-11-28 at 14:56 -0600, Christopher Bostic wrote:
> > > Note that this is not directly related to the GPIO hog updates that
> > > are in process of being added to the palmetto device tree.
> > 
> > So, to clarify:
> > 
> > The patch I sent to the list a week or so ago isn't in the process of
> > being applied in any way for two reasons:
> > 
> > 1. Per Joel's reply it will not be carried in the OpenBMC kernel tree
> > 2. The OpenBMC bitbake build process *already* applies it to the kernel
> > during its build process, as of September. The patch is carried in the
> > OpenBMC tree[1].
> > 
> > [1] https://github.com/openbmc/openbmc/blob/a103a3723b4329225d9316393bf0620027d02aa6/meta-openbmc-bsp/meta-aspeed/meta-ast2400/recipes-kernel/linux/linux-obmc_%25.bbappend#L3
> > 
> > > This issue exists without that change.
> > 
> > You can confirm the presence of the hog at runtime either from dmesg or
> > sysfs:
> > 
> > > >     # ls -1     /sys/firmware/devicetree/base/ahb/apb/gpio@1e780000     | grep h6
> >     pin_gpio_h6
> >     # dmesg | grep -i h6
> >     GPIO line 382 (H6) hogged as output/high
> > 
> 
> Hi Andrew,
> 
> The hog messages weren't there prior in my tests.  I was using a
> slightly older dev-4.7 kernel and the Palmetto dts file didn't have
> the hog definitions.

"slightly older" is a vague, but it shouldn't matter as the Palmetto
DTS in openbmc/linux repo never had (and never will have) the hog
definitions in it.

> 
> > If you are booting your own kernel built directly from the OpenBMC
> > kernel tree with your patches applied and are still seeing the pin in
> > use then that's certainly odd. The existence of the hogs patch can be
> > ignored and we need to investigate what is going on.
> 
> I have been booting my own kernel from a forked version of the OpenBMC
> kernel tree using the bitbake build process. 

I strongly suspect this is where your problem lies. You are using
bitbake to build the kernel, and I presume have modified the recipe to
point to your local kernel tree. If that is the case then bitbake is
automatically applying the hog patch for you no matter what you try, by
my later comment:

    > However, if you are booting the kernel produced from the OpenBMC
    > bitbake build process, then seeing this pin in use is expected
    > behaviour as the hogs patch will have been applied.

I was trying to make the distinction between booting a kernel built by
you directly invoking `make` in your local *kernel* source tree vs
indirectly building the kernel by invoking `bitbake` in your local
*openbmc/openbmc* source tree.

>  Maybe I had missed some
> updates.

I don't think any would have been relevant.

>   In any case, today I updated to the dts file with all the
> hog definitions and removed only the H7 pin lines.   I see that H7 is
> not hogged and that I can successfully grab the pin. 

H7? Or H6? Anyway, my hypothesis here is that hogs patch no longer
applied, perhaps due to a conflict, and as you didn't hog the line in
your change you are free to acquire it through the GPIO API. It feels
wrong that bitbake would continue in the face of the patch failing to
apply, but that sort of wouldn't surprise me either.

>  I wasn't able to
> do this before.  I'll back up to v4.9-rc1 and see if the problem is
> resolved there as well.
> 
> Still not clear to me what was grabbing the pin prior to this.

From the above, I still think it was the hogs patch being applied by
bitbake.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]