Comment 208 for bug 1563110

(In reply to Andy Shevchenko from comment #84)
> (In reply to Pierre Bossart from comment #82)
> > Interesting, I also saw some GPIO issues with a rt5670 device using the
> > latest broonie/for-next kernel. Wondering if I was missing a Kconfig or if
> > the gpio support did change.
>
> GPIO ACPI lib has been changed, now we require to either use _CRS indexes
> only (no GPIO names allowed) or use GPIO with name and _DSD or hard coded
> mapping table provided.

in sound/soc/codecs/rt5670.c there is GPIO name:

rt5670.c:570: rt5670->hp_gpio.name = "headphone detect";

Are you saying this needs to be replaced by something else?

>
> I just looked to rt5670.c and noticed an ugly is_valleyview() function. Can
> you utilize power resources instead if they are available? For example in
> DSDT attached to this bug we see
>
> Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
> {
> CLK3
> })
>
> I'm pretty sure it's about the same PMC PLT clock. I think entire approach
> with clocks might be revisited after reading ACPI DSDT tables carefully.
>
> Care to check?

I have no idea what you're asking for, it's probably a different point anyways unrelated to GPIOs. There is no is_valleyview() in the codec driver, but there are some in the machine drivers. if you check your email, you'll see a question from me last week asking how I am supposed to know if the firmware manages the clock or not. I ended-up calling devm_clk_get() unconditionally, assuming that there is no harm and that if the clock is firmware controlled it will not be gated on clk_disable/unprepare. see https://github.com/plbossart/sound/commit/233602172d97270dfc47222fa5805b8dabd4b1ce

>
> (In reply to Johannes Stezenbach from comment #83)
> > I tried topic/soc-cx2072x-4.13, sound works well for me on
> > speaker and headphones. However, plugging in headphones does
> > not turn off the speaker, is this supposed to be handled by PA
> > or other userspace?
>
> You may check how pin is utilized. Mount debugfs and check status of pin in
> /sys/kernel/debug/gpio and /sys/kernel/debug/pinctrl/<HID:UID>/pins, where
> <HID> is a HID of pin control device. From DSDT it looks like it should be
> under INT33FF:02.