Palmetto GPIO pin configuration for Voltage Translator Control

[Christopher Bostic]

On Mon, Nov 28, 2016 at 6:15 PM, Andrew Jeffery <andrew at 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 at 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