Linux boot delayed by value of generic.reset_off_delay_ms (touchscreen reset)?

[Paul Menzel]

Dear coreboot folks,

On the Dell Latitude 5430 Chromebook (google/brya/var/crota) there is a 
delay of 160 ms during startup in the Linux kernel [1]:

[    0.000000] microcode: microcode updated early to revision 
0x430, date = 2023-06-07
     [    0.000000] Linux version 5.15.124-20281-g306376f9e9db 
(chrome-bot@chromeos-release-builder-us-central1-c-x32-9-oel9) (Chromium 
OS 17.0_pre496208_p20230501-r16 clang version 17.0.0 
(/mnt/host/source/src/third_party/llvm-project 
98f5a340975bc00197c57e39eb4ca26e2da0e8a2), LLD 17.0.0) #1 SMP PREEMPT 
Mon Oct 2 18:31:36 PDT 2023
     […]
     [    0.150271] ACPI: PM: Power Resource [PR00]
     [    0.313289] ACPI: PM: Power Resource [PR01]

A @google.com person commented, that this *could* be caused by the reset 
delay of the ELAN touchscreen. From 
`src/third_party/coreboot/src/mainboard/google/brya/variants/crota/overridetree.cb`:

device ref i2c3 on
    		chip drivers/i2c/hid
    			register "generic.hid" = ""ELAN900C""
    			register "generic.desc" = ""ELAN Touchscreen""
    			register "generic.irq" = "ACPI_IRQ_LEVEL_LOW(GPP_C7_IRQ)"
    			register "generic.detect" = "1"
    			register "generic.reset_gpio" =
    						"ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C1)"
    			register "generic.reset_delay_ms" = "150"
    			register "generic.reset_off_delay_ms" = "1"
    			register "generic.enable_gpio" =
    						"ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_C0)"
    			register "generic.enable_delay_ms" = "6"
    			register "generic.stop_gpio" =
    						"ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C6)"
    			register "generic.stop_off_delay_ms" = "1"
    			register "generic.has_power_resource" = "1"
    			register "hid_desc_reg_offset" = "0x01"
    			device i2c 0x16 on end
    		end
    	end

As I have been bitten the last time, I tried to flash a Dell Chromebook, 
I am weary to test, so I am asking here.
> The delay is unavoidable, although I suppose there's room for
> improvement on making ACPI power sequencing parallelizable or
> otherwise deferring it until the device is actually getting probed
> (preferably using asynchronous probe, since this is a slow device --
> ChromeOS tends to configure touchscreen drivers for async probe
> already, or else loaded as modules).
>
> Perhaps you can take this problem upstream if you'd like to work on
> something, but from a ChromeOS perspective this is either Intended
> Behavior or a Feature Request. I don't think we're interested in
> tracking this as a Feature Request here.

During startup this reset delay should not hold up the boot, should it? 
Could the firmware reset the touchscreen, and somehow message the OS, 
that it’s not needed anymore?

Kind regards,

Paul

[1]: https://issuetracker.google.com/issues/303565666

PS: I was unable to change the issue title to correct PR01 to PR00.

[Matt DeVillier]

On Tue, Dec 5, 2023 at 12:39 PM Paul Menzel  wrote:
> Dear coreboot folks,
>
> On the Dell Latitude 5430 Chromebook (google/brya/var/crota) there is a
> delay of 160 ms during startup in the Linux kernel [1]:
>  [    0.000000] microcode: microcode updated early to revision
>
> 0x430, date = 2023-06-07
>      [    0.000000] Linux version 5.15.124-20281-g306376f9e9db
> (chrome-bot@chromeos-release-builder-us-central1-c-x32-9-oel9) (Chromium
> OS 17.0_pre496208_p20230501-r16 clang version 17.0.0
> (/mnt/host/source/src/third_party/llvm-project
> 98f5a340975bc00197c57e39eb4ca26e2da0e8a2), LLD 17.0.0) #1 SMP PREEMPT
> Mon Oct 2 18:31:36 PDT 2023
>      […]
>      [    0.150271] ACPI: PM: Power Resource [PR00]
>      [    0.313289] ACPI: PM: Power Resource [PR01]
>
> A @google.com person commented, that this *could* be caused by the reset
> delay of the ELAN touchscreen. From
>
> `src/third_party/coreboot/src/mainboard/google/brya/variants/crota/overridetree.cb`:
>             device ref i2c3 on
>                     chip drivers/i2c/hid
>                             register "generic.hid" = ""ELAN900C""
>                             register "generic.desc" = ""ELAN
>
> Touchscreen""
>                                 register "generic.irq" =
> "ACPI_IRQ_LEVEL_LOW(GPP_C7_IRQ)"
>                                 register "generic.detect" = "1"
>                                 register "generic.reset_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C1)"
>                                 register "generic.reset_delay_ms" = "150"
>                                 register "generic.reset_off_delay_ms" = "1"
>                                 register "generic.enable_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_C0)"
>                                 register "generic.enable_delay_ms" = "6"
>                                 register "generic.stop_gpio" =
>
> "ACPI_GPIO_OUTPUT_ACTIVE_LOW(GPP_C6)"
>                                 register "generic.stop_off_delay_ms" = "1"
>                                 register "generic.has_power_resource" = "1"
>                                 register "hid_desc_reg_offset" = "0x01"
>                                 device i2c 0x16 on end
>                         end
>                 end
>
> As I have been bitten the last time, I tried to flash a Dell Chromebook,
> I am weary to test, so I am asking here.

CROTA has been tested using my MrChromebox upstream-based firmware, you
shouldn't have any issues booting it
> > The delay is unavoidable, although I suppose there's room for
> > improvement on making ACPI power sequencing parallelizable or
> > otherwise deferring it until the device is actually getting probed
> > (preferably using asynchronous probe, since this is a slow device --
> > ChromeOS tends to configure touchscreen drivers for async probe
> > already, or else loaded as modules).
> >
> > Perhaps you can take this problem upstream if you'd like to work on
> > something, but from a ChromeOS perspective this is either Intended
> > Behavior or a Feature Request. I don't think we're interested in
> > tracking this as a Feature Request here.

IMO ChromeOS should drop the "probed" flag nonsense and implement TS power
sequencing and detection in coreboot for all devices going forward.
> During startup this reset delay should not hold up the boot, should it?
> Could the firmware reset the touchscreen, and somehow message the OS,
> that it’s not needed anymore?

What the OS driver does with the delay value isn't something coreboot can
really control. The Linux drivers assume nothing has been done and perform
their own power sequencing, regardless of whether coreboot has already done
it (which in most cases now, it has). The Linux drivers skipping power
sequencing would likely require a new ACPI flag to be added to both the
drivers and the firmware / ACPI device.
> Kind regards,
>
> Paul
>
> PS: I was unable to change the issue title to correct PR01 to PR00.
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]