Apollo Lake GPIO driver with Coreboot/U-Boot

[Simon Glass]

Hi Wolfgang,

On Sat, 18 Jan 2020 at 00:56, Wolfgang Wallner
<wolfgang.wallner at br-automation.com> wrote:
>
> Hello Simon,
>
> > -----"Simon Glass" <sjg at chromium.org> schrieb: -----
> > On Thu, 16 Jan 2020 at 02:55, Wolfgang Wallner
> > <wolfgang.wallner at br-automation.com> wrote:
> > >
> > > Hello Simon, Bin, all,
> > >
> > > I have an Apollo Lake based device, where U-Boot is booted as a Coreboot
> > > payload. I would like to utilize the Apollo Lake GPIO driver
> > > (drivers/gpio/intel_gpio.c), but I struggle with the dependencies.
> > >
> > > For my use case, I face 2 obstacles:
> > >
> > >   1) Some required drivers are not built
> > >
> > >     The Apollo Lake GPIO driver requires the P2SB and ITSS drivers, but those
> > >     are located in arch/x86/cpu/apollolake. Drivers in this directory are not
> > >     included in my build as it builds for Coreboot, not for Apollo Lake.
> > >
> > >   2) Some header files are not found
> > >
> > >     The header files gpio.h and itss.h are located in
> > >     arch/x86/include/asm/arch-apollolake, but as I build for Coreboot the
> > >     symlink arch/x86/include/asm/arch points to arch-coreboot instead of
> > >     arch-apollolake, so those header files are not found.
> > >
> > > Does anyone have recommendations on how to solve those issues?
> > > Would it be possible to move the drivers for P2SB and ITSS out of
> > > arch/x86/cpu/apollolake to the generic drivers/ directory?
> >
> > I don't have any great ideas. At present we rely on the device tree to
> > bind these drivers but I suppose we could add the PCI IDs and then the
> > coreboot target could bind them.
>
> I have added the relevant entries in my device tree, the point is that the
> required drivers are not even built, because they are located in the
> Apollo Lake directory. This is why I asked wheter we could move them to the
> generic drivers directory. (This could also make sense IMHO as they are not
> specific for Apollo Lake, but could be used for mulitple generations of chips)

Yes that sounds OK to me.

>
> Also the header files are not found during compilation, as the symlink for
> "arch" points to "arch-coreboot" in my case, not to "arch-apollolake" where
> the header files are located.
>
> At the moment I have modified the build system so taht the drivers are
> compiled for my setup. This works, and the drivers are correctly bound
> according to the device tree entries. But this is just a hack, not a proper
> solution.
>
> > I did send a series to add checks to skip low-level init as needed
> > when running from coreboot:
> >
> > http://patchwork.ozlabs.org/project/uboot/list/?series=149993
>
> Thanks for pointing that out, I have missed it on the mailing list.
> I will have a look at them.
>
> Btw, did you see my patches regarding fixes for Apollo Lake GPIO and SPI?
>
> GPIO:   https://patchwork.ozlabs.org/patch/1220857/
> SPI:    https://patchwork.ozlabs.org/patch/1222779/

Yes looks good. Will review.

>
> > You're welcome. I'm expecting to have full ACPI support around the end
> > of the month.
>
> If I can help by testing I would be interested.
> What is the current state? What is still missing?

The current state as of early January is that the ACPI tables for
Coral are complete with the possible exception of USB. It builds and
boots Linux but there is a lot of cleaning up to do. I've created some
rough commits - see u-boot-dm/acpi-working

There are about 40 commits left to clean up. I still expect to have
this done around the end of January.

Regards,
Simon