Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1570118 > unrolled thread

Re: Cherryview wake up events

Started byJohannes Stezenbach <js@sig21.net>
First post2017-01-30 22:00 +0100
Last post2017-02-09 10:50 +0100
Articles 20 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-01-30 22:00 +0100
    Re: Cherryview wake up events Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-01-30 23:10 +0100
      Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-01-31 15:50 +0100
      Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-01-31 15:50 +0100
        Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 11:00 +0100
          Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 11:40 +0100
            Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 12:20 +0100
              Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 12:40 +0100
                Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 13:20 +0100
                  Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 15:00 +0100
                    Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 15:30 +0100
                      Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 15:40 +0100
                        Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 16:10 +0100
                          Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 16:50 +0100
                            Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-02 17:00 +0100
                              Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-02 18:40 +0100
                                Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-03 11:10 +0100
                                  Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-03 14:20 +0100
                              Re: Cherryview wake up events Johannes Stezenbach <js@sig21.net> - 2017-02-09 10:30 +0100
                                Re: Cherryview wake up events Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-02-09 10:50 +0100

#1570118 — Re: Cherryview wake up events

FromJohannes Stezenbach <js@sig21.net>
Date2017-01-30 22:00 +0100
SubjectRe: Cherryview wake up events
Message-ID<t5rdo-bx-7@gated-at.bofh.it>
On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote:
> On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote:
> > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach <js@sig21.net> wrote:
> > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote:
> > 
> > >> Had you tried to add ID to axp20x-i2c.c ?
> > >
> > > Nope, since I have no idea if the axp and TI hardware is similar.
> > 
> > I think you would give a try.
> 
> I'll check it.

I checked the reference source code, my impression is the
TI Dollar Cove and and AXP288 are completely different hardware.

> > > [    5.331709] i2c_designware 808622C1:06: controller timed out
> > >
> > This is known: http://www.spinics.net/lists/intel-gfx/msg117738.html

Interestingly via this link I found Intel also published
the TI DCove source in a patch series against an unspecified kernel:
https://github.com/01org/ProductionKernelQuilts
specifically
https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
and some more (the series is quite messy).

For the Asus E200HA I'm not sure if the charger and coulomb
counter drivers are needed since charging just works and
the battery status is reported via ACPI.  It seems these
drivers are only for tablets without ACPI support, right?


Thanks,
Johannes

[toc] | [next] | [standalone]

#1570145

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-01-30 23:10 +0100
Message-ID<t5sj8-12l-21@gated-at.bofh.it>
In reply to#1570118
On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach <js@sig21.net> wrote:
> On Fri, Jan 27, 2017 at 02:30:58PM +0100, Johannes Stezenbach wrote:
>> On Fri, Jan 27, 2017 at 03:21:22PM +0200, Andy Shevchenko wrote:
>> > On Fri, Jan 27, 2017 at 1:38 PM, Johannes Stezenbach <js@sig21.net> wrote:
>> > > On Fri, Jan 27, 2017 at 12:56:53AM +0200, Andy Shevchenko wrote:
>> >
>> > >> Had you tried to add ID to axp20x-i2c.c ?
>> > >
>> > > Nope, since I have no idea if the axp and TI hardware is similar.
>> >
>> > I think you would give a try.
>>
>> I'll check it.
>
> I checked the reference source code, my impression is the
> TI Dollar Cove and and AXP288 are completely different hardware.

Thanks for checking.

Yes, due to not obvious communication to PMIC. I suppose that the IP
core is quite similar in all of them, the difference is just how OS
and other MCUs in SoC communicate with it.

So, basically what it means that I2C direct communication is prohibited here.

>
>> > > [    5.331709] i2c_designware 808622C1:06: controller timed out
>> > >
>> > This is known: http://www.spinics.net/lists/intel-gfx/msg117738.html
>
> Interestingly via this link I found Intel also published
> the TI DCove source in a patch series against an unspecified kernel:
> https://github.com/01org/ProductionKernelQuilts
> specifically
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
> and some more (the series is quite messy).
>
> For the Asus E200HA I'm not sure if the charger and coulomb
> counter drivers are needed since charging just works and
> the battery status is reported via ACPI.  It seems these
> drivers are only for tablets without ACPI support, right?

Have no idea.

What that code reminds me is MID family of devices. So, power button
is (reasonable) easy to get support of in that case.
Look into drivers/platform/x86/intel_mid_powerbtn.c. I recently
updated it to support Basin Cove on Intel Edison.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1570793

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-01-31 15:50 +0100
Message-ID<t5HUR-1S1-3@gated-at.bofh.it>
In reply to#1570145
On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote:
> You seem to suggest I should try and tackle it myself,
> which I would do, but for one I don't want to step on
> Mika's toes

Trust me, you don't step on my toes if you want to handle this yourself :)

But if noone else is going to anything about this, I'll then put it to
my todo list and work on it when I have some spare time. Currently busy
with some other things, though.

[toc] | [prev] | [next] | [standalone]

#1570798

FromJohannes Stezenbach <js@sig21.net>
Date2017-01-31 15:50 +0100
Message-ID<t5HUR-1S1-5@gated-at.bofh.it>
In reply to#1570145
Hi Andy and Mika,

On Tue, Jan 31, 2017 at 12:05:07AM +0200, Andy Shevchenko wrote:
> On Mon, Jan 30, 2017 at 10:57 PM, Johannes Stezenbach <js@sig21.net> wrote:
> >
> > I checked the reference source code, my impression is the
> > TI Dollar Cove and and AXP288 are completely different hardware.
> 
> Thanks for checking.
> 
> Yes, due to not obvious communication to PMIC. I suppose that the IP
> core is quite similar in all of them, the difference is just how OS
> and other MCUs in SoC communicate with it.
> 
> So, basically what it means that I2C direct communication is prohibited here.

Not sure about that, but I guess this is needed:
https://lists.freedesktop.org/archives/intel-gfx/2017-January/117696.html

> >> > This is known: http://www.spinics.net/lists/intel-gfx/msg117738.html
> >
> > Interestingly via this link I found Intel also published
> > the TI DCove source in a patch series against an unspecified kernel:
> > https://github.com/01org/ProductionKernelQuilts
> > specifically
> > https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
> > https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
> > and some more (the series is quite messy).

FWIW, now I came across yet another source for this driver:
https://android.googlesource.com/kernel/x86/+/android-x86-grant-3.10-marshmallow-mr1-wear-release/drivers/external_drivers/drivers/mfd/intel_pmic/
(but seems to be older)

> > For the Asus E200HA I'm not sure if the charger and coulomb
> > counter drivers are needed since charging just works and
> > the battery status is reported via ACPI.  It seems these
> > drivers are only for tablets without ACPI support, right?
> 
> Have no idea.
> 
> What that code reminds me is MID family of devices. So, power button
> is (reasonable) easy to get support of in that case.
> Look into drivers/platform/x86/intel_mid_powerbtn.c. I recently
> updated it to support Basin Cove on Intel Edison.

You seem to suggest I should try and tackle it myself,
which I would do, but for one I don't want to step on
Mika's toes, secondly ISTR you indicated you have newer,
better source than what is available publicly?
If you want me to take it, please let me know which tree
to work against and any other suggestions you have.

Some more questions:
- Powerbutton driver seems simple enough, the only specialty
  of the TI dcove PB driver is the workarond for lost button
  press event after resume.  However, I still don't see how
  the PB would cause thermal event irqs on E200HA and how the
  PMIC driver would change it?
- Wakeup from freeze state (E200HA doesn't support suspend / ACPI S3)
  is only step 1, to make it usable we need S0ix support.
  Any hints about that?

I think the mfd driver would be similar to intel_soc_pmic_crc.c,
the dollar_cove_ti_powerbtn.c I would keep instead of merging
it into intel_mid_powerbtn.c.  I guess what we need is in
drivers/acpi/pmic/ something similar to intel_pmic_crc.c,
the ProductionKernelQuilts has 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch.


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572236

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 11:00 +0100
Message-ID<t6mlk-2a2-11@gated-at.bofh.it>
In reply to#1570798
Hi Mika,

On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote:
> - Powerbutton driver seems simple enough, the only specialty
>   of the TI dcove PB driver is the workarond for lost button
>   press event after resume.  However, I still don't see how
>   the PB would cause thermal event irqs on E200HA and how the
>   PMIC driver would change it?

In ProductionKernelQuilts I found
DC-TI-PMIC-disable-power-button-support.patch so I guess it
might not be needed because it's probably handled by ACPI.

> I think the mfd driver would be similar to intel_soc_pmic_crc.c,
> the dollar_cove_ti_powerbtn.c I would keep instead of merging
> it into intel_mid_powerbtn.c.  I guess what we need is in
> drivers/acpi/pmic/ something similar to intel_pmic_crc.c,
> the ProductionKernelQuilts has 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch.

I have preliminary versions of the mfd and opregion driver,
while testing I found the GPIO opregion is not registered:

Excerpt from DSDT:
https://linuxtv.org/~js/e200ha/dsdt.dsl

            Device (PMI2)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "INT33F5" /* TI PMIC Controller */)  // _HID: Hardware ID
                Name (_CID, "INT33F5" /* TI PMIC Controller */)  // _CID: Compatible ID
                Name (_DDN, "TI PMIC Controller")  // _DDN: DOS Device Name
                Name (_HRV, 0x03)  // _HRV: Hardware Revision
                Name (_UID, One)  // _UID: Unique ID
                Name (_DEP, Package (0x02)  // _DEP: Dependencies
                {
                    I2C7, 
                    GPO1
                })
                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Name (SBUF, ResourceTemplate ()
                    {
                        I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000F4240,
                            AddressingMode7Bit, "\\_SB.PCI0.I2C7",
                            0x00, ResourceConsumer, , Exclusive,
                            )
                        GpioInt (Level, ActiveHigh, Shared, PullDefault, 0x0000,
                            "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x000F
                            }
                    })
                    Return (SBUF) /* \_SB_.PCI0.I2C7.PMI2._CRS.SBUF */
                }
...
                Name (AVBL, Zero)
                Name (AVBD, Zero)
                Name (AVBG, Zero)
                Method (_REG, 2, NotSerialized)  // _REG: Region Availability
                {
                    If (Arg0 == 0x08)
                    {
                        AVBG = Arg1
                    }

                    If (Arg0 == 0x8D)
                    {
                        AVBL = Arg1
                    }

                    If (Arg0 == 0x8C)
                    {
                        AVBD = Arg1
                    }
                }


acpidbg:
        \_SB.PCI0.I2C7.PMI2.AVBL Integer      ffff8be7b74d97a8 01 = 0000000000000001
        \_SB.PCI0.I2C7.PMI2.AVBD Integer      ffff8be7b74d94d8 01 = 0000000000000001
        \_SB.PCI0.I2C7.PMI2.AVBG Integer      ffff8be7b74d9be0 01 = 0000000000000000

Any idea about it?
devm_gpiochip_add_data() in chv_gpio_probe() indirectly calls acpi_gpiochip_add()
which should use _DEP to figure out to call _REG, right?

Also PMI2 has

                OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
                Field (GPOP, ByteAcc, NoLock, Preserve)
                {
                    Connection (
                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                            "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
                            )
                            {   // Pin list
                                0x0020
                            }
                    ), 
                    GMP0,   1, 
                    ...
                    (repeat for many more pins)

I guess it means it uses chv_gpio pins and can't work
if the GPIO opregion is not registered?


FWIW, with the mfd driver, /proc/interrupts has

 180:          0          0          0          0  chv-gpio    9  TI Dollar Cove

I guess the 9 refers to the 10th pin in north_pins[] which is pin 0x000F, right?
I boot with "dyndbg=file gpiolib* +p" and get

[  +0.012798] acpi INT33F5:00: GPIO: looking up 0 in _CRS
[  +0.000214] intel_soc_pmic_i2c i2c-INT33F5:00: GPIO lookup for consumer intel_soc_pmic
[  +0.000003] intel_soc_pmic_i2c i2c-INT33F5:00: using ACPI for GPIO lookup
[  +0.000005] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpios
[  +0.000005] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpio
[  +0.000005] acpi INT33F5:00: GPIO: looking up 0 in _CRS
[  +0.000091] cherryview-pinctrl INT33FF:01: request pin 15 (GPIO_SUS0) for INT33FF:01:406

but so far the irq never triggers.


Thanks
Johannes

[toc] | [prev] | [next] | [standalone]

#1572258

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 11:40 +0100
Message-ID<t6mY1-2GK-1@gated-at.bofh.it>
In reply to#1572236
On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> Hi Mika,
> 
> On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote:
> > - Powerbutton driver seems simple enough, the only specialty
> >   of the TI dcove PB driver is the workarond for lost button
> >   press event after resume.  However, I still don't see how
> >   the PB would cause thermal event irqs on E200HA and how the
> >   PMIC driver would change it?
> 
> In ProductionKernelQuilts I found
> DC-TI-PMIC-disable-power-button-support.patch so I guess it
> might not be needed because it's probably handled by ACPI.
> 
> > I think the mfd driver would be similar to intel_soc_pmic_crc.c,
> > the dollar_cove_ti_powerbtn.c I would keep instead of merging
> > it into intel_mid_powerbtn.c.  I guess what we need is in
> > drivers/acpi/pmic/ something similar to intel_pmic_crc.c,
> > the ProductionKernelQuilts has 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch.
> 
> I have preliminary versions of the mfd and opregion driver,
> while testing I found the GPIO opregion is not registered:

Cool, I take it that you started working on that ;-)

> Excerpt from DSDT:
> https://linuxtv.org/~js/e200ha/dsdt.dsl
> 
>             Device (PMI2)
>             {
>                 Name (_ADR, Zero)  // _ADR: Address
>                 Name (_HID, "INT33F5" /* TI PMIC Controller */)  // _HID: Hardware ID
>                 Name (_CID, "INT33F5" /* TI PMIC Controller */)  // _CID: Compatible ID
>                 Name (_DDN, "TI PMIC Controller")  // _DDN: DOS Device Name
>                 Name (_HRV, 0x03)  // _HRV: Hardware Revision
>                 Name (_UID, One)  // _UID: Unique ID
>                 Name (_DEP, Package (0x02)  // _DEP: Dependencies
>                 {
>                     I2C7, 
>                     GPO1
>                 })
>                 Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>                 {
>                     Name (SBUF, ResourceTemplate ()
>                     {
>                         I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000F4240,
>                             AddressingMode7Bit, "\\_SB.PCI0.I2C7",
>                             0x00, ResourceConsumer, , Exclusive,
>                             )
>                         GpioInt (Level, ActiveHigh, Shared, PullDefault, 0x0000,
>                             "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>                             )
>                             {   // Pin list
>                                 0x000F
>                             }
>                     })
>                     Return (SBUF) /* \_SB_.PCI0.I2C7.PMI2._CRS.SBUF */
>                 }
> ...
>                 Name (AVBL, Zero)
>                 Name (AVBD, Zero)
>                 Name (AVBG, Zero)
>                 Method (_REG, 2, NotSerialized)  // _REG: Region Availability
>                 {
>                     If (Arg0 == 0x08)
>                     {
>                         AVBG = Arg1
>                     }
> 
>                     If (Arg0 == 0x8D)
>                     {
>                         AVBL = Arg1
>                     }
> 
>                     If (Arg0 == 0x8C)
>                     {
>                         AVBD = Arg1
>                     }
>                 }
> 
> 
> acpidbg:
>         \_SB.PCI0.I2C7.PMI2.AVBL Integer      ffff8be7b74d97a8 01 = 0000000000000001
>         \_SB.PCI0.I2C7.PMI2.AVBD Integer      ffff8be7b74d94d8 01 = 0000000000000001
>         \_SB.PCI0.I2C7.PMI2.AVBG Integer      ffff8be7b74d9be0 01 = 0000000000000000
> 
> Any idea about it?
> devm_gpiochip_add_data() in chv_gpio_probe() indirectly calls acpi_gpiochip_add()
> which should use _DEP to figure out to call _REG, right?

Actually no, we don't support all _DEP in Linux yet. But that's not the
problem though. See below.

> Also PMI2 has
> 
>                 OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
>                 Field (GPOP, ByteAcc, NoLock, Preserve)
>                 {
>                     Connection (
>                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
>                             "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
>                             )
>                             {   // Pin list
>                                 0x0020
>                             }
>                     ), 
>                     GMP0,   1, 
>                     ...
>                     (repeat for many more pins)
> 
> I guess it means it uses chv_gpio pins and can't work
> if the GPIO opregion is not registered?

That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
suppose.

So in addition to the PMIC MFD driver, you need to have a GPIO driver
for Dollar Cove (I guess the quilt patch series included that as well?).

If you look under the /sys/bus/acpi/devices/DEVICE, it should include
bunch of physical_nodeX links. Those are the subdevices of the MFD so
when the GPIO driver registers the GPIO core then automatically installs
GPIO OpRegion handler.

> FWIW, with the mfd driver, /proc/interrupts has
> 
>  180:          0          0          0          0  chv-gpio    9  TI Dollar Cove
> 
> I guess the 9 refers to the 10th pin in north_pins[] which is pin 0x000F, right?
> I boot with "dyndbg=file gpiolib* +p" and get
> 
> [  +0.012798] acpi INT33F5:00: GPIO: looking up 0 in _CRS
> [  +0.000214] intel_soc_pmic_i2c i2c-INT33F5:00: GPIO lookup for consumer intel_soc_pmic
> [  +0.000003] intel_soc_pmic_i2c i2c-INT33F5:00: using ACPI for GPIO lookup
> [  +0.000005] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpios
> [  +0.000005] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpio
> [  +0.000005] acpi INT33F5:00: GPIO: looking up 0 in _CRS
> [  +0.000091] cherryview-pinctrl INT33FF:01: request pin 15 (GPIO_SUS0) for INT33FF:01:406
> 
> but so far the irq never triggers.

Probably because the PMIC does not have anything to report yet. When you
add the DCOVE GPIO driver, and start receiving input events from the
button array, then you should see that interrupt count increasing. If
everything works correctly.

[toc] | [prev] | [next] | [standalone]

#1572281

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 12:20 +0100
Message-ID<t6nAJ-3eT-7@gated-at.bofh.it>
In reply to#1572258
On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> >                 OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
> >                 Field (GPOP, ByteAcc, NoLock, Preserve)
> >                 {
> >                     Connection (
> >                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> >                             "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
> >                             )
> >                             {   // Pin list
> >                                 0x0020
> >                             }
> >                     ), 
> >                     GMP0,   1, 
> >                     ...
> >                     (repeat for many more pins)
> > 
> > I guess it means it uses chv_gpio pins and can't work
> > if the GPIO opregion is not registered?
> 
> That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
> suppose.
> 
> So in addition to the PMIC MFD driver, you need to have a GPIO driver
> for Dollar Cove (I guess the quilt patch series included that as well?).

Nope, I see it for AX288 but didn't find it for TI DCove.  And in
current Linus' tree axp288_cells[] doesn't include gpio so
I concluded it's not needed... what am I missing?


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572295

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 12:40 +0100
Message-ID<t6nU6-3lz-29@gated-at.bofh.it>
In reply to#1572281
On Thu, Feb 02, 2017 at 12:12:22PM +0100, Johannes Stezenbach wrote:
> On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote:
> > On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> > >                 OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
> > >                 Field (GPOP, ByteAcc, NoLock, Preserve)
> > >                 {
> > >                     Connection (
> > >                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> > >                             "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
> > >                             )
> > >                             {   // Pin list
> > >                                 0x0020
> > >                             }
> > >                     ), 
> > >                     GMP0,   1, 
> > >                     ...
> > >                     (repeat for many more pins)
> > > 
> > > I guess it means it uses chv_gpio pins and can't work
> > > if the GPIO opregion is not registered?
> > 
> > That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
> > suppose.
> > 
> > So in addition to the PMIC MFD driver, you need to have a GPIO driver
> > for Dollar Cove (I guess the quilt patch series included that as well?).
> 
> Nope, I see it for AX288 but didn't find it for TI DCove.  And in
> current Linus' tree axp288_cells[] doesn't include gpio so
> I concluded it's not needed... what am I missing?

So reading your DSDT there is that GPIO button array device \_SB.TBAD
which has one GpioInt() referencing \_SB.PCI0.I2C7.PMI2. I suppose that
is the power button GPIO.

In order to use that there needs to be a GPIO driver exposing those
GPIOs to other drivers. So it is definitely needed.

[toc] | [prev] | [next] | [standalone]

#1572319

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 13:20 +0100
Message-ID<t6owO-3OM-17@gated-at.bofh.it>
In reply to#1572295
On Thu, Feb 02, 2017 at 01:35:08PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 12:12:22PM +0100, Johannes Stezenbach wrote:
> > On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote:
> > > On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> > > >                 OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
> > > >                 Field (GPOP, ByteAcc, NoLock, Preserve)
> > > >                 {
> > > >                     Connection (
> > > >                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> > > >                             "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
> > > >                             )
> > > >                             {   // Pin list
> > > >                                 0x0020
> > > >                             }
> > > >                     ), 
> > > >                     GMP0,   1, 
> > > >                     ...
> > > >                     (repeat for many more pins)
> > > > 
> > > > I guess it means it uses chv_gpio pins and can't work
> > > > if the GPIO opregion is not registered?
> > > 
> > > That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
> > > suppose.
> > > 
> > > So in addition to the PMIC MFD driver, you need to have a GPIO driver
> > > for Dollar Cove (I guess the quilt patch series included that as well?).
> > 
> > Nope, I see it for AX288 but didn't find it for TI DCove.  And in
> > current Linus' tree axp288_cells[] doesn't include gpio so
> > I concluded it's not needed... what am I missing?
> 
> So reading your DSDT there is that GPIO button array device \_SB.TBAD
> which has one GpioInt() referencing \_SB.PCI0.I2C7.PMI2. I suppose that
> is the power button GPIO.
> 
> In order to use that there needs to be a GPIO driver exposing those
> GPIOs to other drivers. So it is definitely needed.

Actually, looking again the patches you found:

https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch

Did you try to them both? The latter seems to handle the power button
by talking directly with the PMIC (instead of using a GPIO).

Let's include the original author (Ramakrishna) as well if we could get
some information from him.

[toc] | [prev] | [next] | [standalone]

#1572376

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 15:00 +0100
Message-ID<t6q5z-4M6-17@gated-at.bofh.it>
In reply to#1572319
On Thu, Feb 02, 2017 at 02:16:39PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 01:35:08PM +0200, Mika Westerberg wrote:
> > On Thu, Feb 02, 2017 at 12:12:22PM +0100, Johannes Stezenbach wrote:
> > > On Thu, Feb 02, 2017 at 12:31:22PM +0200, Mika Westerberg wrote:
> > > > On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> > > > >                 OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
> > > > >                 Field (GPOP, ByteAcc, NoLock, Preserve)
> > > > >                 {
> > > > >                     Connection (
> > > > >                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
> > > > >                             "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
> > > > >                             )
> > > > >                             {   // Pin list
> > > > >                                 0x0020
> > > > >                             }
> > > > >                     ), 
> > > > >                     GMP0,   1, 
> > > > >                     ...
> > > > >                     (repeat for many more pins)
> > > > > 
> > > > > I guess it means it uses chv_gpio pins and can't work
> > > > > if the GPIO opregion is not registered?
> > > > 
> > > > That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
> > > > suppose.
> > > > 
> > > > So in addition to the PMIC MFD driver, you need to have a GPIO driver
> > > > for Dollar Cove (I guess the quilt patch series included that as well?).
> > > 
> > > Nope, I see it for AX288 but didn't find it for TI DCove.  And in
> > > current Linus' tree axp288_cells[] doesn't include gpio so
> > > I concluded it's not needed... what am I missing?
> > 
> > So reading your DSDT there is that GPIO button array device \_SB.TBAD
> > which has one GpioInt() referencing \_SB.PCI0.I2C7.PMI2. I suppose that
> > is the power button GPIO.
> > 
> > In order to use that there needs to be a GPIO driver exposing those
> > GPIOs to other drivers. So it is definitely needed.
> 
> Actually, looking again the patches you found:
> 
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch
> https://github.com/01org/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/PWRBTN-add-driver-for-TI-PMIC.patch
> 
> Did you try to them both? The latter seems to handle the power button
> by talking directly with the PMIC (instead of using a GPIO).

Nope, as I've written earlier:
> In ProductionKernelQuilts I found
> DC-TI-PMIC-disable-power-button-support.patch so I guess it
> might not be needed because it's probably handled by ACPI.

[  +0.000338] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[  +0.000127] ACPI: Power Button [PWRB]
...
[  +0.000248] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
[  +0.000116] ACPI: Power Button [PWRF]

And I also have:

[  +0.000004] soc_button_array INTCFD9:00: GPIO lookup for consumer soc_button_array
[  +0.000002] soc_button_array INTCFD9:00: using ACPI for GPIO lookup
[  +0.000003] acpi INTCFD9:00: GPIO: looking up soc_button_array-gpios
[  +0.000004] acpi INTCFD9:00: GPIO: looking up soc_button_array-gpio
[  +0.000003] acpi INTCFD9:00: GPIO: looking up 0 in _CRS
[  +0.000610] soc_button_array INTCFD9:00: lookup for GPIO soc_button_array failed
(repeats for 5 buttons, one of them should succeed)

> Let's include the original author (Ramakrishna) as well if we could get
> some information from him.

Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from ProductionKernelQuilts,
it doesn't seem hard to do the same for the TI PMIC, but it needs information
from the PMIC datasheet for irq and gpio control registers.
Hopefully you have a patch or at least could provide the information.


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572404

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 15:30 +0100
Message-ID<t6qyC-5bD-17@gated-at.bofh.it>
In reply to#1572376
On Thu, Feb 02, 2017 at 02:52:57PM +0100, Johannes Stezenbach wrote:
> Nope, as I've written earlier:
> > In ProductionKernelQuilts I found
> > DC-TI-PMIC-disable-power-button-support.patch so I guess it
> > might not be needed because it's probably handled by ACPI.
> 
> [  +0.000338] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
> [  +0.000127] ACPI: Power Button [PWRB]
> ...
> [  +0.000248] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
> [  +0.000116] ACPI: Power Button [PWRF]

Yeah, but shouldn't hurt to try it out :)

> And I also have:
> 
> [  +0.000004] soc_button_array INTCFD9:00: GPIO lookup for consumer soc_button_array
> [  +0.000002] soc_button_array INTCFD9:00: using ACPI for GPIO lookup
> [  +0.000003] acpi INTCFD9:00: GPIO: looking up soc_button_array-gpios
> [  +0.000004] acpi INTCFD9:00: GPIO: looking up soc_button_array-gpio
> [  +0.000003] acpi INTCFD9:00: GPIO: looking up 0 in _CRS
> [  +0.000610] soc_button_array INTCFD9:00: lookup for GPIO soc_button_array failed
> (repeats for 5 buttons, one of them should succeed)

It fails because of the missing GPIO driver.

> > Let's include the original author (Ramakrishna) as well if we could get
> > some information from him.
> 
> Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from ProductionKernelQuilts,
> it doesn't seem hard to do the same for the TI PMIC, but it needs information
> from the PMIC datasheet for irq and gpio control registers.
> Hopefully you have a patch or at least could provide the information.

That patch looks like a GPIO driver for DCOVE. Did you try it already?

[toc] | [prev] | [next] | [standalone]

#1572413

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 15:40 +0100
Message-ID<t6qIi-5eS-37@gated-at.bofh.it>
In reply to#1572404
On Thu, Feb 02, 2017 at 04:26:18PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 02:52:57PM +0100, Johannes Stezenbach wrote:
> > Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from ProductionKernelQuilts,
> > it doesn't seem hard to do the same for the TI PMIC, but it needs information
> > from the PMIC datasheet for irq and gpio control registers.
> > Hopefully you have a patch or at least could provide the information.
> 
> That patch looks like a GPIO driver for DCOVE. Did you try it already?

Hell, no.  Without datasheets I can't compare if registers
are compatible between AXP288 and TI DDOVE (SND9039).
Couldn't it damager the hardware if I mess up charger
and voltage regulator related registers?

And current Linus' tree doesn't have the AXP288 GPIO,
and ProductionKernelQuilts doesn't use AXP288 GPIO
for TI DCOVE.

Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572447

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 16:10 +0100
Message-ID<t6rbj-5Ei-5@gated-at.bofh.it>
In reply to#1572413
On Thu, Feb 02, 2017 at 03:31:45PM +0100, Johannes Stezenbach wrote:
> On Thu, Feb 02, 2017 at 04:26:18PM +0200, Mika Westerberg wrote:
> > On Thu, Feb 02, 2017 at 02:52:57PM +0100, Johannes Stezenbach wrote:
> > > Looking at 0002-GPIO-Adding-AXP288-PMIC-GPIO-driver.patch from ProductionKernelQuilts,
> > > it doesn't seem hard to do the same for the TI PMIC, but it needs information
> > > from the PMIC datasheet for irq and gpio control registers.
> > > Hopefully you have a patch or at least could provide the information.
> > 
> > That patch looks like a GPIO driver for DCOVE. Did you try it already?
> 
> Hell, no.  Without datasheets I can't compare if registers
> are compatible between AXP288 and TI DDOVE (SND9039).
> Couldn't it damager the hardware if I mess up charger
> and voltage regulator related registers?

It might yes :)

> And current Linus' tree doesn't have the AXP288 GPIO,
> and ProductionKernelQuilts doesn't use AXP288 GPIO
> for TI DCOVE.

OK, I guess it is easier if I just order one of those machines here and
figure out how to get the PMIC driver working.

Is the model Asus E200HA? Something like this (sorry the information is
in Finnish but the machine should look the same):

https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone

Also can you remind me what exactly is not working so we can prioritize?

Thanks.

[toc] | [prev] | [next] | [standalone]

#1572476

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 16:50 +0100
Message-ID<t6rO1-5RR-5@gated-at.bofh.it>
In reply to#1572447
On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> OK, I guess it is easier if I just order one of those machines here and
> figure out how to get the PMIC driver working.

Oh, I assumed the bottleneck is developer time, not lack of hardware...

> Is the model Asus E200HA? Something like this (sorry the information is
> in Finnish but the machine should look the same):
> 
> https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone

Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.

> Also can you remind me what exactly is not working so we can prioritize?

There are reports hibernate isn't working, presumably because
the storage is 32MB eMMC.  I've never tried.  It doesn't
support ACPI S3 (suspend-to-RAM).  So currently one has
to boot+shutdown everytime (or keep it running).

1. There seems to be no way to wake it up after "echo freeze >/sys/power/state".
   That is the reason for wanting the power button to wake it up.
   Whether the PB creates an input event is secondary.
   (the LID also doesn't wake it up, but it creates an input event)
2. I've no idea what would be the power consumption in freeze state,
   so I guess support for the S0ix states is needed
3. It randomly hangs at boot, often with a message related to i2c timeout.
   I tried Hans de Goede's patches but it didn't work for me
   (question is if the semphore address is the same for
   AXP288 and TI DCove; the DSDT has the _SEM method so the
   semphore is needed).

Everything else is secondary.  E.g. there is an ADC driver used for thermal
used by the opregion driver, I didn't port it and just implemented
like for AXP288 by simple register reads (which might not work for TI).
We could fix this later.


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572488

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-02 17:00 +0100
Message-ID<t6rXJ-5Vl-39@gated-at.bofh.it>
In reply to#1572476
On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote:
> On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> > OK, I guess it is easier if I just order one of those machines here and
> > figure out how to get the PMIC driver working.
> 
> Oh, I assumed the bottleneck is developer time, not lack of hardware...

Well, both actually ;)

> > Is the model Asus E200HA? Something like this (sorry the information is
> > in Finnish but the machine should look the same):
> > 
> > https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone
> 
> Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.

OK, we have one other Cherrytrail machine here which may have the same
PMIC. We'll check that first and if it does not have the same, I'll
order the above machine.

> > Also can you remind me what exactly is not working so we can prioritize?
> 
> There are reports hibernate isn't working, presumably because
> the storage is 32MB eMMC.  I've never tried.  It doesn't
> support ACPI S3 (suspend-to-RAM).  So currently one has
> to boot+shutdown everytime (or keep it running).
> 
> 1. There seems to be no way to wake it up after "echo freeze >/sys/power/state".
>    That is the reason for wanting the power button to wake it up.
>    Whether the PB creates an input event is secondary.
>    (the LID also doesn't wake it up, but it creates an input event)
> 2. I've no idea what would be the power consumption in freeze state,
>    so I guess support for the S0ix states is needed
> 3. It randomly hangs at boot, often with a message related to i2c timeout.
>    I tried Hans de Goede's patches but it didn't work for me
>    (question is if the semphore address is the same for
>    AXP288 and TI DCove; the DSDT has the _SEM method so the
>    semphore is needed).
> 
> Everything else is secondary.  E.g. there is an ADC driver used for thermal
> used by the opregion driver, I didn't port it and just implemented
> like for AXP288 by simple register reads (which might not work for TI).
> We could fix this later.

OK, thanks.

[toc] | [prev] | [next] | [standalone]

#1572542

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-02 18:40 +0100
Message-ID<t6twu-6ZQ-15@gated-at.bofh.it>
In reply to#1572488
On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote:
> > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> > > Is the model Asus E200HA? Something like this (sorry the information is
> > > in Finnish but the machine should look the same):
> > > 
> > > https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone
> > 
> > Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.
> 
> OK, we have one other Cherrytrail machine here which may have the same
> PMIC. We'll check that first and if it does not have the same, I'll
> order the above machine.

In case it is useful to know, I installed Debian stretch following this:
https://wiki.debian.org/InstallingDebianOn/Asus/E200HA

I built my kernel using a relatively minimal kernel config,
let me know if you want it.  I could also post the
two patches which port the mfd and opregion drivers, but
they are straight forward copies of intel_soc_pmic_crc.c
and intel_pmic_crc.c from 4.10.0-rc6+ with code copy&pasted
from the ProductionKernelQuilts patches and s/crc/dc_ti/ etc.,
except I scamped the thermal handler to skip the ADC driver port for now.


Maybe I should've used intel_pmic_xpower.c instead of
intel_pmic_crc.c, since as I write this I see there
is a no-op intel_xpower_pmic_gpio_handler() registered.
This is the trick that fixes this:
        \_SB.PCI0.I2C7.PMI2.AVBG Integer      ffff8be7b74d9be0 01 = 0000000000000001

But now it generates ACPI errors about thermal zone
and "acpi -V" usually hangs it up.

[    5.500927] ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20160930/evregion-300)
[    5.503842] No Local Variables are initialized for method [TMPR]
[    5.506703] No Arguments are initialized for method [TMPR]
[    5.509557] ACPI Error: Method parse/execution failed [\_SB.ATKD.TMPR] (Node ffff8a7d374e87f8), AE_ERROR (20160930/ps
parse-543)
[    5.512481] ACPI Error: Method parse/execution failed [\_SB.ATKD.WMNB] (Node ffff8a7d374e7ed8), AE_ERROR (20160930/ps
parse-543)
[    6.545403] i2c_designware 808622C1:06: controller timed out
[    6.550763] ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20160930/evregion-300)
[    6.555783] No Local Variables are initialized for method [TMPR]
[    6.558769] No Arguments are initialized for method [TMPR]
[    6.561571] ACPI Error: Method parse/execution failed [\_SB.ATKD.TMPR] (Node ffff8a7d374e87f8), AE_ERROR (20160930/ps
parse-543)
[    6.564487] ACPI Error: Method parse/execution failed [\_SB.ATKD.WMNB] (Node ffff8a7d374e7ed8), AE_ERROR (20160930/ps
parse-543)

(I knew my thermal opregion code was preliminary but I didn't expect it to error.)


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1572992

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-03 11:10 +0100
Message-ID<t6IYx-dX-13@gated-at.bofh.it>
In reply to#1572542
On Thu, Feb 02, 2017 at 06:32:33PM +0100, Johannes Stezenbach wrote:
> On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote:
> > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote:
> > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> > > > Is the model Asus E200HA? Something like this (sorry the information is
> > > > in Finnish but the machine should look the same):
> > > > 
> > > > https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone
> > > 
> > > Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.
> > 
> > OK, we have one other Cherrytrail machine here which may have the same
> > PMIC. We'll check that first and if it does not have the same, I'll
> > order the above machine.
> 
> In case it is useful to know, I installed Debian stretch following this:
> https://wiki.debian.org/InstallingDebianOn/Asus/E200HA
> 
> I built my kernel using a relatively minimal kernel config,
> let me know if you want it.  I could also post the
> two patches which port the mfd and opregion drivers, but
> they are straight forward copies of intel_soc_pmic_crc.c
> and intel_pmic_crc.c from 4.10.0-rc6+ with code copy&pasted
> from the ProductionKernelQuilts patches and s/crc/dc_ti/ etc.,
> except I scamped the thermal handler to skip the ADC driver port for now.

Thanks!

Just for book keeping purposes, can you file a kernel.org bugzilla bug
about this and add all the necessary information, and your patches
there? You can assign the bug directly to me.

[toc] | [prev] | [next] | [standalone]

#1573079

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-03 14:20 +0100
Message-ID<t6LWp-22L-15@gated-at.bofh.it>
In reply to#1572992
On Fri, Feb 03, 2017 at 12:00:00PM +0200, Mika Westerberg wrote:
> Just for book keeping purposes, can you file a kernel.org bugzilla bug
> about this and add all the necessary information, and your patches
> there? You can assign the bug directly to me.

I filed it but cannot assign it, added you to CC.
https://bugzilla.kernel.org/show_bug.cgi?id=193891

Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1577415

FromJohannes Stezenbach <js@sig21.net>
Date2017-02-09 10:30 +0100
Message-ID<t8Td9-4n9-33@gated-at.bofh.it>
In reply to#1572488
On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote:
> On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote:
> > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> > > Is the model Asus E200HA? Something like this (sorry the information is
> > > in Finnish but the machine should look the same):
> > > 
> > > https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone
> > 
> > Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.
> 
> OK, we have one other Cherrytrail machine here which may have the same
> PMIC. We'll check that first and if it does not have the same, I'll
> order the above machine.

Probably it's too early to ask, but did you go for the E200HA
or what device are you going to use?  And did you start poking
at it, or what timeframe can we expect some patches to test?

BTW, just to clarify about the test patches I added in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=193891
You can use them but I also don't mind if they go to the
garbage can, they were just quickly cobbled together
for testing.


Thanks,
Johannes

[toc] | [prev] | [next] | [standalone]

#1577432

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-02-09 10:50 +0100
Message-ID<t8Twu-4tQ-13@gated-at.bofh.it>
In reply to#1577415
On Thu, Feb 09, 2017 at 10:24:26AM +0100, Johannes Stezenbach wrote:
> On Thu, Feb 02, 2017 at 05:58:26PM +0200, Mika Westerberg wrote:
> > On Thu, Feb 02, 2017 at 04:42:43PM +0100, Johannes Stezenbach wrote:
> > > On Thu, Feb 02, 2017 at 05:02:12PM +0200, Mika Westerberg wrote:
> > > > Is the model Asus E200HA? Something like this (sorry the information is
> > > > in Finnish but the machine should look the same):
> > > > 
> > > > https://www.karkkainen.com/verkkokauppa/asus-e200ha-fd0005ts-11-6--hd-kannettava-tietokone
> > > 
> > > Looks right, mine is E200HA-FD0004TS but I think that just means dark blue color.
> > 
> > OK, we have one other Cherrytrail machine here which may have the same
> > PMIC. We'll check that first and if it does not have the same, I'll
> > order the above machine.
> 
> Probably it's too early to ask, but did you go for the E200HA
> or what device are you going to use?  And did you start poking
> at it, or what timeframe can we expect some patches to test?

I ordered E200HA from the above link. It should arrive soon so I have
not yet started working on it. My colleaque (Erik Veijola, CC'd) is
actually doing the real work - I'll help him when there is need.

About the time frame, once the machine arrives we'll start working and
try to get the patches ready as soon as possible (but remember we have
other things to do as well).

Let's use the bugzilla entry to track progress.

> BTW, just to clarify about the test patches I added in bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=193891
> You can use them but I also don't mind if they go to the
> garbage can, they were just quickly cobbled together
> for testing.

OK, thanks.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web