Hi again,
first, I have posted this question already on Stackoverflow [1] and Reddit [2] but forgot to put it on the mailing list.
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.
When calling this method on the parent object (I2C4), everything goes fine but calling it on the touch screen controller (TCS2), it fails. What also makes me wonder is that it returns AE_AML_UNINITIALIZED_ARG even though it doesn't take any args (according to the DSDT).
Calling the _CRS method on the same object also works without any problems. I also looked into the Linux kernel source how they change ACPI power states and they use the exact same mechanism. It boils down to the use of acpi_evaluate_object in acpi_dev_pm_explicit_set which also seems to work on the touchscreen device.
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.
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
Similar things also happen on the GPIO device (_SB_.GPO1).
Regards, Johannes
[1]: https://stackoverflow.com/questions/44382881/acpi-ps0-failing-with-uninitial... [2]: https://www.reddit.com/r/osdev/comments/6mtlv7/acpi_psx_function_returns_ae_... DSDT: https://gist.github.com/jklmnn/15ed561202e04390e7bc366c0f803577#file-dsdt-ds...
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,
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,
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 -
Johannes Kliemann