Palmetto GPIO pin configuration for Voltage Translator Control

[Andrew Jeffery]

On Tue, 2016-11-29 at 11:55 -0600, Christopher Bostic wrote:
> > 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.

"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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161130/caa6d833/attachment.sig>