ACPI _PS0 failing with UNINITIALIZED_ARG

[Alexander Boettcher]

Hi,

just a minor idea: the acpi rsdp revision is currently hard-corded in
base-nova's core platform.cc to '2'. I don't really believe that this
could make a difference, but maybe check that this actually matches the
revision as reported by grub2 to the kernel. The revision is currently
not exported to Genode 'core'.

Just an idea.

Alex.

On 04.08.2017 13:05, Johannes Kliemann wrote:
> Hi,
> 
> thanks for your answer. Well the I2C controller is already enabled. I
> can successfully run \_SB_.I2C4._PS(0|3). I even can measure the effect
> since the magic value in the mmio is only available if _PS0 was called
> on the I2C controller.
> 
> I have traced the initialization on Linux (exactly said the calls of
> evaluate object) and there doesn't seem to be anything unusual.
> 
>> \_SB_.I2C4._STA
>> \_SB_.I2C4.TCS2._STA
>> \_SB_.I2C4.SSCN
>> \_SB_.I2C4.FMCN
>> \_SB_.I2C4.FPCN
>> \_SB_.I2C4.HSCN
>> \_SB_.I2C4._STA
>> \_SB_.I2C4.TCS2._STA
>> \_SB_.I2C4._PS3
>> \_SB_.I2C4._STA
>> \_SB_.I2C4.TCS2._STA
>> \_SB_.I2C4._PS0
>> \_SB_.I2C4.TCS2._PS3
>> \_SB_.I2C4.TCS2._PS0
> 
> This is the sequence called by Linux (shortened, double entries are
> omitted). Beside the status calls I can't see anything special.
> 
> Regards,
> Johannes
> 
> Am 04.08.2017 um 11:12 schrieb Alexander Boettcher:
>> Hi,
>>
>> On 03.08.2017 13:29, Johannes Kliemann wrote:
>>>> I have a touchscreen controller (which is an I2C slave) that I need to enable via APCI. This should be done by calling the _PS0 ACPI method. I call this method by using AcpiEvaluateObject with no arguments and no return values.
>>
>> just guessing. Since the touchscreen controller is a slave of the I2C
>> controller, you have to have a (ACPI) driver to enable the I2C and
>> potentially also the right I2C slaves.
>>
>>>> what am I missing to successfully enable the touchscreen device via ACPI? Is there something the Linux kernel is initializing implicitly (I couldn't find something like this)?
>>>
>>> The current workaround for this issue is to use the GPIO pins to enable
>>> the controller. But this isn't the desired way since it requires an
>>> additional GPIO driver that takes ~100 LOC and also a separate ACPI
>>> initialization for this driver.
>>
>> again, just guessing. Your workaround sounds bit like a part of the
>> initialize sequence of the I2C controller.
>>
>>> Besides that other functions that are needed to get initial parameters
>>> return errors. On the specific device I have the following examples:
>>>
>>>> \_SB_.I2C4.SSCN
>>>> \_SB_.I2C4.FMCN
>>>> \_SB_.I2C4.FPCN
>>>> \_SB_.I2C4.HSCN
>>
>> again, just guessing. Probably you need/have to find the right acpi
>> method to initialize the I2C controller, so that the slaves, as your
>> touchscreen, may work properly.
>>
>>>> what am I missing to successfully enable the touchscreen device via
>> ACPI? Is there something the Linux kernel is initializing implicitly (I
>> couldn't find something like this)?
>>
>> ... just guessing: the Linux kernel initialize the I2C controller for
>> sure fully, thats why the I2C method in the ACPI tables of your I2C
>> slave work in Linux ?
>>
>>
>> If all my guessing above is wrong, another direction could be to check
>> the version of the acpica library used by Genode and the ACPICA version
>> you have in the Linux kernel. I know that ACPICA library code and Linux
>> code does not exactly match (but they have common roots), so that one
>> may possibly deduce the difference in the behavior. Maybe a update to a
>> new ACPICA library version for Genode can help (since there a features
>> and fixes in the upstream ACPICA library according to the changelog) ?
>>
>> Good luck,
>>

-- 
Alexander Boettcher
Genode Labs

http://www.genode-labs.com - http://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth