How Chromium get x86 ACPI configuration and pass it to device driver?

[Scott Liu]

Because of I have project that porting Chromium os onto x86 win10 platform for touchscreen device. The device interface is i2c-hid and its i2c address, hid-descritpor address is also passed from BIOS to chomium's data struct. 

Because it is from BIOS so that I don't need to set device information(eg: i2c address, IRQ, Reset GPIO...) to DSDT. 

Above is my imagine, please correct me if wrong.

Now I would like to understand how acpi pass data to chromium data struct, which file I can refer. Because of my device is not able to be detected by chromium os and I'd like to debug it. Any advise would be appreciate, thanks. 

[Dmitry Torokhov]

Hi Scott,

On Wed, May 10, 2017 at 2:22 AM, Scott Liu <scot...@emc.com.tw> wrote:
> Because of I have project that porting Chromium os onto x86 win10 platform
> for touchscreen device. The device interface is i2c-hid and its i2c address,
> hid-descritpor address is also passed from BIOS to chomium's data struct.
> Because it is from BIOS so that I don't need to set device information(eg:
> i2c address, IRQ, Reset GPIO...) to DSDT.

DSDT is a part of BIOS and contains description of hardware present in
the system, including i2c addresses, interrupts, etc. The kernel ACPI
subsystem parses DSDT and initializes the devices accordingly. This is
pretty much the only way for BIOS to communicate details of
non-discoverable devices to the operating system, so I am not sure why
you think you do not need to touch DSDT.

As I mentioned in another e-mail, you can introduce a quick hack and
instantiate i2c device by hand, like
drivres/platform/chrome/chromeos-laptop.c does for some older systems,
but that has nothing to do with BIOS.

>
> Above is my imagine, please correct me if wrong.
>
> Now I would like to understand how acpi pass data to chromium data struct,
> which file I can refer. Because of my device is not able to be detected by
> chromium os and I'd like to debug it. Any advise would be appreciate,
> thanks.

See drivers/hid/i2c-hid/i2c-hid.c::i2c_hid_acpi_pdata() to see how
i2c-hid driver parses ACPI data to fetch HID descriptor address. The
client address and interrupts are parsed in the generic i2c code, see
drivers/i2c/i2c-core.c::acpi_i2c_add_device().

Thanks,
Dmitry

[Scott Liu]

Hi Dmitry,

On Thursday, May 11, 2017 at 6:11:49 AM UTC+8, Dmitry Torokhov wrote:

Hi Scott,

On Wed, May 10, 2017 at 2:22 AM, Scott Liu <scot...@emc.com.tw> wrote:
> Because of I have project that porting Chromium os onto x86 win10 platform
> for touchscreen device. The device interface is i2c-hid and its i2c address,
> hid-descritpor address is also passed from BIOS to chomium's data struct.
> Because it is from BIOS so that I don't need to set device information(eg:
> i2c address, IRQ, Reset GPIO...) to DSDT.

DSDT is a part of BIOS and contains description of hardware present in
the system, including i2c addresses, interrupts, etc. The kernel ACPI
subsystem parses DSDT and initializes the devices accordingly. This is
pretty much the only way for BIOS to communicate details of
non-discoverable devices to the operating system, so I am not sure why
you think you do not need to touch DSDT.

My concept is that chromium OS and BIOS are different hardware. The device information(DSDT) is located on BIOS.

Once boot up, OS will to get device information from BIOS then OS will bring it up if get Elan I2C device information.

So there are nothing to do at OS side. Right?

Now I see that 'coreboot' is like BIOS and DSDT information will be located at coreboot.

So do I have to modify coreboot for adding my device information, like
coreboot/src/mainboard/google/reef/variants/baseboard/devicetree.cb does.

And which file should I modify if BOARD=x86-generic. (eg: project reef, it mapped to upon path)

If above answer is Yes, how can I get hardware information from current platform?

(eg: interrupt, reset gpio number, i2c bus # )

As I mentioned in another e-mail, you can introduce a quick hack and
instantiate i2c device by hand, like
drivres/platform/chrome/chromeos-laptop.c does for some older systems,
but that has nothing to do with BIOS.

I am use originally device not new device, so the hardware information should be right.

thank you in advance.

Scott

 

[Dmitry Torokhov]

As long as the description of the device in DSDT matches to what OS
expects/needs.

>
> Now I see that 'coreboot' is like BIOS and DSDT information will be located
> at coreboot.
> So do I have to modify coreboot for adding my device information, like
> coreboot/src/mainboard/google/reef/variants/baseboard/devicetree.cb does.
> And which file should I modify if BOARD=x86-generic. (eg: project reef, it
> mapped to upon path)

Are you trying to replace stock x86 BIOS with a coreboot? That would
be a massive undertaking, and I am not sure why you would want to do
that.

>
> If above answer is Yes, how can I get hardware information from current
> platform?
> (eg: interrupt, reset gpio number, i2c bus # )

Either from schematic, or looking at existing DSDT.

>
>
>> As I mentioned in another e-mail, you can introduce a quick hack and
>> instantiate i2c device by hand, like
>> drivres/platform/chrome/chromeos-laptop.c does for some older systems,
>> but that has nothing to do with BIOS.
>>
>
> I am use originally device not new device, so the hardware information
> should be right.

OK, then retrieve the original DSDT (you can grab it form
/sys/firmware/acpi/tables/DSDT, you may also need the rest of the
tables form there), disassemble with "iasl" utility, and look up the
device particulars there. Then you should be able to see why i2c-hid
does not bind to the device and what is needed to fix this.

Thanks,
Dmitry

[劉嘉駿]

Hi Dmitry,

> -----Original Message-----
>
> Are you trying to replace stock x86 BIOS with a coreboot? That would be a
> massive undertaking, and I am not sure why you would want to do that.
>

I am not sure if chromium can explore i2c device without to replace BIOS to coreboot.
Of cause, the best thing is chromium OS works without replace BIOS to coreboot.

The attached file is kernel log (chrome_kernel_4-4_log).
I did printk on somewhere with label [ELAN], you can ignore it if it bothers.
It seems kernel didn't get Elan information from DSDT?

Another file is dsdt.asl(dsdt.dsl.bz2) file which described Elan device information.
And this file should be fine because of Elan touchscreen works well on win10.

Thanks for helps,
Scott

[Vincent Palatin]

On Fri, May 12, 2017 at 11:04 AM, 劉嘉駿 <scot...@emc.com.tw> wrote:

> Are you trying to replace stock x86 BIOS with a coreboot? That would be a
> massive undertaking, and I am not sure why you would want to do that.
>

I am not sure if chromium can explore i2c device without to replace BIOS to coreboot.

Yes it can, as Dmitry said a couple of time in the previous emails : "you can introduce a quick hack and

instantiate i2c device by hand, like drivres/platform/chrome/chromeos-laptop.c does for some older systems,
but that has nothing to do with BIOS."

 

Of cause, the best thing is chromium OS works without replace BIOS to coreboot.

The attached file is kernel log (chrome_kernel_4-4_log).
I did printk on somewhere with label [ELAN], you can ignore it if it bothers.
It seems kernel didn't get Elan information from DSDT?

Given this DSDT contains the PNP0C50 device for the Elan hardware, you should check what the i2c-hid driver thinks about it by turning on the debugging there (in drivers/hid/i2c-hid/i2c-hid.c, you can see a 'bool debug' variable which can be passed as a kernel parameter / module parameter or simply hardcoded)

[劉嘉駿]

Hi Vincent & Dmitry,
Thank you for your time and patience.
I have tried chromeos-laptop to find my device by add device information in chromeos_laptop_dmi_table[] but still can't work.
The dmi_check_system() checked okay but failed on find_i2c_adapter_num(..) because Elan device doesn’t connect to any i2c bus.

ls /sys/bus/i2c/device is not listed Elan device and showed following devices(cat /sys/bus/i2c/device/i2c-*/name):
i915 gmbus dpc
i915 gmbus dpb
i915 gmbus dpd
DPDDC-A
DPDDC-B
DPDDC-C
SMBus I801 adapter at f040

Also i2c-hid driver is not executed, I see nothing messages by turning on i2c-hid debug flag.
I think it is because underlying driver(i2c bus drivers) are not recognized Elan device so that upper driver will not be functionality.

Please refer to attached Kernel log and the log with label [ELAN] is by me.
Any advice is great appreciated, thank again!

BR
Scott

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Dmitry Torokhov]

Are we positive that it is i2c device? I thought x360 used USB...
Could you post DSDT for the device?

[劉嘉駿]

Hi Dmitry,
I am sure this is i2c device, confirmed from window's device management, Elan's engineering tool.

DSDT is attached file. (dsdt.bz2)
This file is made by window's asl tool ( iasl.exe -d dsdt.aml).

Not made by Ubuntu's iasl tool is because there are got error as iasl_error.png.
Thanks.

BR,
Scott (Tel: 07-5370105#69)

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dt...@chromium.org]
> Sent: Tuesday, May 16, 2017 1:01 AM
> To: 劉嘉駿
> Cc: Vincent Palatin; Dmitry Torokhov; Chromium OS dev
> Subject: Re: [cros-dev] How Chromium get x86 ACPI configuration and pass it
> to device driver?
>

[劉嘉駿]

Hi Dmitry,
Since I have post on linux-i2c mailing list and get feedback.
I checked those kernel configurations and found that was all default with amd64-generic.
So I built amd64-generic image and touch works.
Thank you for helps!

BR,
Scott

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dt...@chromium.org]
> Sent: Tuesday, May 16, 2017 1:01 AM
> To: 劉嘉駿