GPIO driver for Intel Atom SoC

[Lundberg, Johannes]

Hi

I want to port the pinctrl-cherryview driver from Linux.

I've seen there is the gpiobus and a controller gpioc, can any of these be
leverage when porting pinctrl?

What is the recommend way to proceed?

Thanks!

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Adrian Chadd]

Take a look at what one of the gpio controllers do. Eg ar71xx_gpio.c.
You have to implement those methods.

(I think someone did a GPIO controller thing for some AMD CPU too?)


-a


On 11 June 2016 at 21:59, Lundberg, Johannes

> https://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobil...@freebsd.org"

[Ian Lepore]

On Sat, 2016-06-11 at 21:59 -0700, Lundberg, Johannes wrote:
> Hi
>
> I want to port the pinctrl-cherryview driver from Linux.
>
> I've seen there is the gpiobus and a controller gpioc, can any of
> these be
> leverage when porting pinctrl?
>
> What is the recommend way to proceed?
>
> Thanks!
>

The term 'pinctrl' has a very specific meaning in the FDT/devicetree
world which is prevelant in linux these days. A pinctrl driver is not
just a gpio controller driver. If the linux driver you're talking
about is in fact an FDT pinctrl driver, then you'll essentially be
embracing the entire FDT world (it's an alternative to ACPI and hints
and other types of metadata for describing hardware). You'll also be
breaking new ground in freebsd by being the first to try to use
freebsd's FDT support framework on an x86 platform.

-- Ian

[Lundberg, Johannes]

Hi Ian

Thanks for the heads up.

This is a vanilla Intel chip with ACPI.
ACPI ID is INT33FF (Intel Serial IO GPIO Controller).

I don't think I need to worry about FDT. (Hopefully)
I can't find any traces of FDT in the Linux driver.

On Sun, Jun 12, 2016 at 10:12 AM, Ian Lepore <i...@freebsd.org> wrote:

> On Sat, 2016-06-11 at 21:59 -0700, Lundberg, Johannes wrote:
> > Hi
> >
> > I want to port the pinctrl-cherryview driver from Linux.
> >
> > I've seen there is the gpiobus and a controller gpioc, can any of
> > these be
> > leverage when porting pinctrl?
> >
> > What is the recommend way to proceed?
> >
> > Thanks!
> >
>
> The term 'pinctrl' has a very specific meaning in the FDT/devicetree
> world which is prevelant in linux these days. A pinctrl driver is not
> just a gpio controller driver. If the linux driver you're talking
> about is in fact an FDT pinctrl driver, then you'll essentially be
> embracing the entire FDT world (it's an alternative to ACPI and hints
> and other types of metadata for describing hardware). You'll also be
> breaking new ground in freebsd by being the first to try to use
> freebsd's FDT support framework on an x86 platform.
>
> -- Ian
>

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.

[Lundberg, Johannes]

Thanks Adrian

Looks like this is something I can base the new driver on.
Hopefully with this we can get eMMC support for Intel SDHCI controller.

On Sun, Jun 12, 2016 at 12:11 AM, Adrian Chadd <adrian...@gmail.com>
wrote:

[Ian Lepore]

On Sun, 2016-06-12 at 10:48 -0700, Lundberg, Johannes wrote:
> Thanks Adrian
>
> Looks like this is something I can base the new driver on.
> Hopefully with this we can get eMMC support for Intel SDHCI
> controller.
>

Why do we need gpio support for emmc/sdhci? Is there a power-enable
pin that has to be asserted or something? I don't think we have an API
that lets an arbitrary driver which is not a child of the gpiobus
manipulate pins, outside of the FDT world.

-- Ian

[Lundberg, Johannes]

On Sun, Jun 12, 2016 at 11:02 AM, Ian Lepore <i...@freebsd.org> wrote:

>
> Why do we need gpio support for emmc/sdhci? Is there a power-enable
> pin that has to be asserted or something? I don't think we have an API
> that lets an arbitrary driver which is not a child of the gpiobus
> manipulate pins, outside of the FDT world.
>
> -- Ian
>
>

Yes, emmc need to be activated/enabled using GPIO.
That's only one of many things we need GPIO for.

The chip is Atom Z8000 (Cherryview, but this is also applicable to Baytrail
(Z3000))

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.

[Imre Vadasz]

Hi,

Microsoft has some documentation on GPIO handling with SD card controllers,
which should apply to most Cherryview devices:
https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd

I did some work on Cherryview SoC support in DragonFlyBSD.
In DragonFly master, there is a simple GPIO driver for cherryview in
/sys/bus/gpio/gpio_intel. In master, it's currently only used for
handling the ACPI GeneralPurposeIo operation regions, and
Acpi-Event-Interrupts (which replace GPE interrupts on reduced-hardware
platforms).

I have some further (more prototype level) code which also contains some
code for Intel sdhci controller integration:
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/shortlog/refs/heads/cherryview

With this branch everything sdcard/eMMC related works quite nicely, e.g.
it properly handles plugging in/out the sd-card on my HP X2 210 detachable
on DragonFlyBSD.

To handle everything properly this contains a bit of work on mostly ACPI
related stuff:

ACPI device initialization order needs to be according to the ACPI _DEP methods:
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/25dec08cafa3ce9089eb5b216700f4e678b3356d

We need to map ACPI nodes to the device objects (and at least track a
reference count for debugging):
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/23135590ffb33b40f170c786ea95fc133358ebdb

Then some kind of API is needed for handling the GeneralPurposeIo resources
declared for the device in the ACPI tables (e.g. the sdhci controller).
(i.e. some way of attempting to "map" the resource from the device driver):
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/d5b3d3447bbdd42a68359aebd61f271bfa830951

And I have a prototype of adapting the sdhci driver to handle the GPIO
ACPI resources, as described in "https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd":
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/5d2844c280211cbb256a5ecc3ea27f952149e452

Regards,
Imre Vadász

[Lundberg, Johannes]

Hi Imre

This is great information. Thank you!

My device have an emmc chip on the pcb (non-removable).
Have you tested you code on that kind of system?

Current unmodified FreeBSD can detect the sdhci_pci controller and a mmc
card on slot0 but timeouts when trying to init the mmc. Not sure why it is
failing. I assumed it needed activating through some gpios but maybe it's
not that easy..

--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.

[Lundberg, Johannes]

Hi Imre

I got the device in /dev/mmcsd0. I think the reason was that mmcsd wasn't
loaded (need to load manually it seems..)

Do you think your patch in mmc is something that should be pushed upstream
in FreeBSD or is it more of a hack?
I am talking about
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/444adb3eab999964539da816dc292a2ad058918c

On Mon, Jun 13, 2016 at 2:56 PM, Imre Vadasz <im...@vdsz.com> wrote:

> Hi,
>
> Having the SDHCI controller in ACPI space won't help, because FreeBSD
> doesn't have the code for attaching sdhci(4) via acpi yet.
>
> You should try setting the hw.mmc.debug tunable in the bootloader.
> You should probably try booting with hw.mmc.debug=3 to get as much
> debugging output as possible from mmc(4). It should at least tell you
> if/how it recognizes the eMMC disk, and maybe something helpful for
> further debugging.
>
> Imre
>
> On 13:44 Mon 13 Jun , Lundberg, Johannes wrote:
> > Hi Imre
> >
> >
> > I have attached the logs.
> > The board is this: http://www.up-board.org/
> >
> > Since we don't have sdhci_acpi.c (yet) I select the SDHCI controller to
> be
> > on PCI in BIOS.
> > Would it be better to have it in ACPI space because of the MMC/GPIO
> stuff?
> >
> >
> > I tried your patch and amazingly identification of the mmc card now
> works!!
> > I can't believe it was that simple...
> > However, I do not get any /dev/mmc* devices.
> >
> > sdhci_pci0: <Braswell Storage Cluster Control MMC Port> mem
> > 0x91927000-0x91927fff at device 16.0 on pci0
> > sdhci_pci0: 1 slot(s) allocated
> > mmc0: <MMC/SD bus> on sdhci_pci0
> >
> > Thanks!
> >
> >
> >
> > --
> > Name: Johannes Lundberg
> > Position: Mirama project leader
> > Phone: +1-408-636-2161
> > Skype: brilliantjohannes
> > Online: LinkedIn <http://jp.linkedin.com/in/lundbergjohannes> Facebook
> > <https://www.facebook.com/miramaone> Reddit
> > <https://www.reddit.com/user/yohanesu75/> Twitter
> > <https://twitter.com/Yohanesu75Tweet> GitHub <
> https://github.com/yohanesu75>
> > GitLab <https://gitlab.com/u/johannes_lundberg>
> > Company: Mirama <http://mira.ma> Brilliantservice US
> > <http://www.brilliantserviceusa.com> Brilliantservice JP
> > <http://www.brilliantservice.co.jp>

> >
> > On Mon, Jun 13, 2016 at 12:36 PM, Imre Vadasz <im...@vdsz.com> wrote:
> >
> > > Hi,
> > >

> > > If possible, it would be quite interesting and helpful if you could
> post
> > > the ACPI tables of your device (i.e. by running "acpidump -b" and
> uploading
> > > the output files), as well as the list of pci devices from "pciconf
> -lcvb".
> > >
> > > The HP X2 210 detachable I'm running DragonFly on, has an internal eMMC
> > > on its pcb, as well as an external micro-sdcard slot, and both work
> for me.
> > > I forgot to mention that I need a small workaround to make the eMMC
> work,
> > > which you could try out:
> > >
> > >
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/444adb3eab999964539da816dc292a2ad058918c
> > >
> > > It seems quite unlikely that the mmc would need activating through a
> gpio,
> > > assuming your device can boot from that internal mmc.
> > >
> > > My HP detachable can boot from the internal eMMC, but not from the
> external
> > > micro-sd slot. The micro-sd slot is powered on by the _PS0 ACPI method
> of
> > > the corresponding ACPI device, and that _PS0 method does some I2C
> > > transactions through an I2cSerialBus ACPI operation-region Field. For
> that
> > > part I added a helper driver which installs the necessary handler
> function
> > > in the ACPICA framework:
> > >
> > >
> https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/98eefd6fca52090fe45779e35c41f4b15942517f
> > >
> > > Imre