Brandon Breitenstein has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
google/chromeec: Add USB MUX Interrupt
Kernel relies on the USB MUX interrupt to configure USB devices that are connected on the Type-C ports for TGL. Adding in the Q1C Interrupt so the Kernel can properly receive and configure USB devices
BUG=b:152902608 TEST=buld_packages for volteer and verified that Proto 1 and Proto 2 are now seeing extcon events
Change-Id: Ie3a2f829a295f090a03e72e12f19ecc5bb724952 Signed-off-by: Brandon Breitenstein brandon.breitenstein@intel.com --- M src/ec/google/chromeec/acpi/ec.asl 1 file changed, 7 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/24/40024/1
diff --git a/src/ec/google/chromeec/acpi/ec.asl b/src/ec/google/chromeec/acpi/ec.asl index 95494ea..558b0e5 100644 --- a/src/ec/google/chromeec/acpi/ec.asl +++ b/src/ec/google/chromeec/acpi/ec.asl @@ -366,6 +366,13 @@ Notify (CREC, 0x80) }
+ //USB MUX Interrupt + Method (_Q1C, 0, NotSerialized) + { + Store ("ED: USB MUX", Debug) + Notify (CREC, 0x80) + } + // TABLET mode switch Event Method (_Q1D, 0, NotSerialized) {
Vijay P Hiremath has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 1: Code-Review+1
Caveh Jalali has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 1:
(2 comments)
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... PS1, Line 369: USB add space
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... PS1, Line 372: ED EC?
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Hello Vijay P Hiremath, build bot (Jenkins), Furquan Shaikh, Wonkyu Kim, Caveh Jalali, Utkarsh H Patel, Prashant Malani,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/40024
to look at the new patch set (#2).
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
google/chromeec: Add USB MUX Interrupt
Kernel relies on the USB MUX interrupt to configure USB devices that are connected on the Type-C ports for TGL. Adding in the Q1C Interrupt so the Kernel can properly receive and configure USB devices
BUG=b:152902608 TEST=buld_packages for volteer and verified that Proto 1 and Proto 2 are now seeing extcon events
Change-Id: Ie3a2f829a295f090a03e72e12f19ecc5bb724952 Signed-off-by: Brandon Breitenstein brandon.breitenstein@intel.com --- M src/ec/google/chromeec/acpi/ec.asl 1 file changed, 7 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/24/40024/2
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
(2 comments)
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... PS1, Line 369: USB
add space
Done
https://review.coreboot.org/c/coreboot/+/40024/1/src/ec/google/chromeec/acpi... PS1, Line 372: ED
EC?
Done
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 1:
Patch Set 1: Code-Review-1
Adding pmalani@.
Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 1:
> Patch Set 1: Code-Review-1 > > Adding pmalani@. > > Prashant told me last week that this change is no longer necessary for extcon events.
That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Thanks for the update. Does the kernel driver pull the correct Mux info from the EC when the interrupt occurs?
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
> Patch Set 1: > > > Patch Set 1: Code-Review-1 > > > > Adding pmalani@. > > > > Prashant told me last week that this change is no longer necessary for extcon events. > > That is for the cros_ec change (EXT device) this change is still needed
Would you happen to know what kernel driver is servicing this interrupt? Also, when exactly in the PD discovery and mode entry process is this interrupt triggered?
We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt.
I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Thanks for the update. Does the kernel driver pull the correct Mux info from the EC when the interrupt occurs?
It is only pulling the first event no subsequent events
So for TBT and for DP it's only getting the initial connect request not the safe mode or alt mode requests that follow.
for TBT you should see something like the following [ 39.220409] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 39.220413] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 40.748557] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.748561] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0 [ 40.752853] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=1,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.752857] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0
Where the first set is the initial connect request, the second set is the safe mode request and the last is the alt mode request
with the pd notify patches you only see the first request
[ 88.528218] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 88.528221] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 96.972844] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 96.972848] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0
This is two different connects of the same device with unplug inbetween
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
> Patch Set 2: > > > Patch Set 1: > > > > > Patch Set 1: Code-Review-1 > > > > > > Adding pmalani@. > > > > > > Prashant told me last week that this change is no longer necessary for extcon events. > > > > That is for the cros_ec change (EXT device) this change is still needed > > Would you happen to know what kernel driver is servicing this interrupt? > Also, when exactly in the PD discovery and mode entry process is this interrupt triggered? > > We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt. > > I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed.
I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Thanks for the update. Does the kernel driver pull the correct Mux info from the EC when the interrupt occurs?
It is only pulling the first event no subsequent events
So for TBT and for DP it's only getting the initial connect request not the safe mode or alt mode requests that follow.
for TBT you should see something like the following [ 39.220409] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 39.220413] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 40.748557] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.748561] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0 [ 40.752853] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=1,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.752857] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0
Where the first set is the initial connect request, the second set is the safe mode request and the last is the alt mode request
with the pd notify patches you only see the first request
[ 88.528218] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 88.528221] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 96.972844] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 96.972848] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0
This is two different connects of the same device with unplug inbetween
Looks like there are two requests for the second set (maybe I'm interpreting it incorrectly).
How was that interrupt being asserted earlier by the EC? It could be that the EC code needs to reset a pd host event instead.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
> Patch Set 2: > > > Patch Set 2: > > > > > Patch Set 1: > > > > > > > Patch Set 1: Code-Review-1 > > > > > > > > Adding pmalani@. > > > > > > > > Prashant told me last week that this change is no longer necessary for extcon events. > > > > > > That is for the cros_ec change (EXT device) this change is still needed > > > > Would you happen to know what kernel driver is servicing this interrupt? > > Also, when exactly in the PD discovery and mode entry process is this interrupt triggered? > > > > We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt. > > > > I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed. > > I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me
Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Thanks for the update. Does the kernel driver pull the correct Mux info from the EC when the interrupt occurs?
It is only pulling the first event no subsequent events
So for TBT and for DP it's only getting the initial connect request not the safe mode or alt mode requests that follow.
for TBT you should see something like the following [ 39.220409] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 39.220413] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 40.748557] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.748561] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0 [ 40.752853] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=1,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.752857] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0
Where the first set is the initial connect request, the second set is the safe mode request and the last is the alt mode request
with the pd notify patches you only see the first request
[ 88.528218] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 88.528221] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 96.972844] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 96.972848] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0
This is two different connects of the same device with unplug inbetween
Looks like there are two requests for the second set (maybe I'm interpreting it incorrectly).
How was that interrupt being asserted earlier by the EC? It could be that the EC code needs to reset a pd host event instead.
Sorry, I meant "E code needs to send a PD host event instead"
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
Patch Set 2:
> Patch Set 2: > > > Patch Set 2: > > > > > Patch Set 2: > > > > > > > Patch Set 1: > > > > > > > > > Patch Set 1: Code-Review-1 > > > > > > > > > > Adding pmalani@. > > > > > > > > > > Prashant told me last week that this change is no longer necessary for extcon events. > > > > > > > > That is for the cros_ec change (EXT device) this change is still needed > > > > > > Would you happen to know what kernel driver is servicing this interrupt? > > > Also, when exactly in the PD discovery and mode entry process is this interrupt triggered? > > > > > > We want to back out the HACK which causes the LPC driver to call the notifier chain on every interrupt. > > > > > > I have 2 CLs (https://chromium-review.googlesource.com/q/hashtag:%22extcon-pd-notify%22+(s...)) that use the PD notifier mechanism, which is what will be used once extcon is removed. > > > > I'll talk with Utkarsh on this cause even with the above mentioned Kernel patches without this interrupt events aren't coming through on the driver. He will be able to better address this than me > > Looks like we hadn't seen these patches yet so this was done without knowledge of the Kernel changes...we were just working on verifying TCSS on upstream and found this to be missing will abandon after I test with the Kernel patches
Great, will stand by. Please also make sure that you have the following two patches in your kernel: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2... https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
The above two are meant to replace the need for the extcon DT entry via ACPI.
Looks to be working but not fully working...we are not able to see DP come up but I will abandon this patch for now as yours seem to solve the main issue here
Thanks for the update. Does the kernel driver pull the correct Mux info from the EC when the interrupt occurs?
It is only pulling the first event no subsequent events
So for TBT and for DP it's only getting the initial connect request not the safe mode or alt mode requests that follow.
for TBT you should see something like the following [ 39.220409] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 39.220413] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 40.748557] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.748561] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0 [ 40.752853] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=1,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 40.752857] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=2, tbt_usb4_cable_gen=0
Where the first set is the initial connect request, the second set is the safe mode request and the last is the alt mode request
with the pd notify patches you only see the first request
[ 88.528218] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 88.528221] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0 [ 96.972844] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt=0,usb4=0 tbt_type=0, optical_cable=0, tbt_usb4_link=0 [ 96.972848] extcon-tcss-cros-ec extcon-tcss-cros-ec: tbt_usb4_cable_speed=0, tbt_usb4_cable_gen=0
This is two different connects of the same device with unplug inbetween
Looks like there are two requests for the second set (maybe I'm interpreting it incorrectly).
How was that interrupt being asserted earlier by the EC? It could be that the EC code needs to reset a pd host event instead.
Sorry, I meant "E code needs to send a PD host event instead"
That is two different connects (I connected the dock twice to see what was happening notice how far apart the timestamps are)
I will have Vijay comment on that as I am not familiar with the EC code in relation to this Vijay has been handling everything there
Vijay P Hiremath has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
please pick this CL too, lets trace entire log https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2...
Vijay P Hiremath has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Re on EC events: As defined in SAS EC_HOST_EVENT_USB_MUX (SCI event) is triggered from EC when there is a change needed in USB MUX.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
Patch Set 2:
Re on EC events: As defined in SAS EC_HOST_EVENT_USB_MUX (SCI event) is triggered from EC when there is a change needed in USB MUX.
Thanks Vijay. Could you kindly point me to the SAS document link, and relevant section.
I'm curious, if the change in the EC was made a while ago, why wasn't this change in upstream coreboot already?
At a high level, the kernel and coreboot hack to allow these events to be delivered via the LPCS notify event (crrev.com/c/2002185) cannot be upstreamed, so we have to develop a way to route this through the PD notifier mechanism.
Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 2:
(4 comments)
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@10 PS2, Line 10: Adding in the Q1C Add the Q1C
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@11 PS2, Line 11: so the Kernel can properly receive and configure USB devices Please add a dot/period at the end of sentences.
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@14 PS2, Line 14: buld_packages build_packages
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@15 PS2, Line 15: extcon What does that mean?
Hello Vijay P Hiremath, build bot (Jenkins), Furquan Shaikh, Wonkyu Kim, Caveh Jalali, Utkarsh H Patel, Prashant Malani,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/40024
to look at the new patch set (#3).
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
google/chromeec: Add USB MUX Interrupt
Kernel relies on the USB MUX interrupt to configure USB devices that are connected on the Type-C ports for TGL. Add the Q1C Interrupt so the Kernel can properly receive and configure USB devices.
BUG=b:152902608 TEST=build_packages for volteer and verified that Proto 1 and Proto 2 are now seeing extcon events in kernel logs
Change-Id: Ie3a2f829a295f090a03e72e12f19ecc5bb724952 Signed-off-by: Brandon Breitenstein brandon.breitenstein@intel.com --- M src/ec/google/chromeec/acpi/ec.asl 1 file changed, 7 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/24/40024/3
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(4 comments)
Patch Set 2:
(4 comments)
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@10 PS2, Line 10: Adding in the Q1C
Add the Q1C
Done
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@11 PS2, Line 11: so the Kernel can properly receive and configure USB devices
Please add a dot/period at the end of sentences.
Done
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@14 PS2, Line 14: buld_packages
build_packages
Done
https://review.coreboot.org/c/coreboot/+/40024/2//COMMIT_MSG@15 PS2, Line 15: extcon
What does that mean?
Done
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
Patch Set 2:
Patch Set 2:
Re on EC events: As defined in SAS EC_HOST_EVENT_USB_MUX (SCI event) is triggered from EC when there is a change needed in USB MUX.
Thanks Vijay. Could you kindly point me to the SAS document link, and relevant section.
I'm curious, if the change in the EC was made a while ago, why wasn't this change in upstream coreboot already?
At a high level, the kernel and coreboot hack to allow these events to be delivered via the LPCS notify event (crrev.com/c/2002185) cannot be upstreamed, so we have to develop a way to route this through the PD notifier mechanism.
That is a good question it was on the private branch that was used to test Volteer until this last week and upon doing TCSS testing found it missing on upstream. It appears all other parts of the patch that added this were upstreamed so it is possible that this piece was just missed cause everything else way there
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(2 comments)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 373: Notify (CREC, 0x80) I wonder if it is better to do the following:
#ifdef EC_ENABLE_PD_MCU_DEVICE Method (_Q1C, 0, NotSerialized) { Store ("EC: USB MUX", Debug) Notify (_SB.PCI0.LPCB.EC0.CREC.ECPD, 0x80) } #endif
This ensures that the Notify() interrupt is routed to the child device (cros-usbpd-notify) instead of the Cros EC LPC parent device.
Note that this too would be a sort of hack, since the ECPD notify should be initiated from the EC, instead of having EC_HOST_EVENT_USB_MUX remapped to the handler for EC_HOST_EVENT_PD_MCU.
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : } I think it's good to investigate what on the Chrome OS kernel is using the EC_HOST_EVENT_USB_MUX interrupt.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 373: Notify (CREC, 0x80)
I wonder if it is better to do the following: […]
I chatted a bit with furquan@, and it seems like my suggestion may be the best path forward here for now.
Brandon, can you kindly do the following: - Incorporate the above change into this CL, and add a comment mentioning that this is a short-term solution while we transition to the PD notifier framework. - Try this CL with the kernel CLs I mentioned (which remove the LPCS hack and use the USBPD notifier).
I will also do the same. If we can verify that things work, then let's move ahead with the proposed solution.
I will also file a bug tracking this CL (we should remove it once the PD notifier stack and Type C connector class port driver are complete). WDYT?
Rajmohan Mani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
I think it's good to investigate what on the Chrome OS kernel is using the EC_HOST_EVENT_USB_MUX int […]
During the TCSS bring up in ICL, I had to implement this _Q1C method to get cros_ec_lpc_acpi_notify() invoked in drivers/platform/chrome/cros_ec_lpc.c for type-c events.
With the new cros-usbpd-notify(), if there's a cleaner way to directly notify cros-usbpd, that would be ideal.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
During the TCSS bring up in ICL, I had to implement this _Q1C method to get cros_ec_lpc_acpi_notify( […]
Got it. Thanks for the context!
Do you know what on the EC is calling _Q1C ? Is it the virtual MUX driver code? https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1340491/...
I think the solution suggested in Comment #373 is a good one while we wait for all the EC/AP API changes.
Rajmohan Mani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
Got it. Thanks for the context! […]
_Qxx methods are exposed by the EC driver through ACPI listings for the EC device, to handle GPE events that is raised from a GPE bit tied to an EC. Once a GPE event occurs (Type-C event in this case), the OS ACPI layer will invoke _Q1C() associated with EC.
EC_HOST_EVENT_USB_MUX is 0x1C, so we have this _Q1C handler being called.I added EC_HOST_EVENT_MASK(EC_HOST_EVENT_USB_MUX) bit to MAINBOARD_EC_SCI_EVENTS in src/mainboard/google/<boardname>/variants/baseboard/include/baseboard/ec.h, so that we register for EC_HOST_EVENT_USB_MUX events.
I don't have much depth on EC, but EC_HOST_EVENT_USB_MUX seems intuitive for Type-C / USB events. If there is a way, we can get _Q16() / EC_HOST_EVENT_PD_MCU handler, invoked for Type-C events, we can simply drop this CL and remove support for EC_HOST_EVENT_USB_MUX. But if using EC_HOST_EVENT_USB_MUX is recommended / correct way of handling Type-C events, calling required handler from here may not be a hack IMO.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
_Qxx methods are exposed by the EC driver through ACPI listings for the EC device, to handle GPE eve […]
I think using EC_HOST_EVENT_USB_MUX *may* be acceptable, but why then is the LPCS hack (crrev.com/c//2002185) required? Registering normally for the EC notifier should have been sufficient.
I think it should be possible to have this assert the same notifier bit as Q16.
Rajmohan Mani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
(1 comment)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
I think using EC_HOST_EVENT_USB_MUX *may* be acceptable, but why then is the LPCS hack (crrev. […]
During that bring up effort, I used this EC_HOST_EVENT_USB_MUX, since it was a Type-C event, with the understanding that it had to be debugged to see why that hack was needed and what the proper solution could be.
It sounds like using _Q16 / EC_HOST_EVENT_PD_MCU handler with the kernel CLs you mentioned (which remove the LPCS hack and use the USBPD notifier) is the proper solution.
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
Brandon, have you been able to try out the changes suggested in L373? I'm having some network issues which are preventing access to my devices....
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
Patch Set 3:
Brandon, have you been able to try out the changes suggested in L373? I'm having some network issues which are preventing access to my devices....
I have not had a chance yet as I do not have any devices connected to my board in the Office. I will make the change and have Utkarsh test it out on Proto 2 today
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 3:
Patch Set 3:
Patch Set 3:
Brandon, have you been able to try out the changes suggested in L373? I'm having some network issues which are preventing access to my devices....
I have not had a chance yet as I do not have any devices connected to my board in the Office. I will make the change and have Utkarsh test it out on Proto 2 today
Seems Utkarsh is also working from home today I will see who I can get to test this out today
Hello build bot (Jenkins), Vijay P Hiremath, Furquan Shaikh, Wonkyu Kim, Caveh Jalali, Nick Vaccaro, Utkarsh H Patel, Prashant Malani,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/40024
to look at the new patch set (#4).
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
google/chromeec: Add USB MUX Interrupt
Kernel relies on the USB MUX interrupt to configure USB devices that are connected on the Type-C ports for TGL. Adding in the Q1C Interrupt so the Kernel can properly receive and configure USB devices
BUG=b:152902608 TEST=buld_packages for volteer and verified that Proto 1 and Proto 2 are now seeing extcon events
Change-Id: Ie3a2f829a295f090a03e72e12f19ecc5bb724952 Signed-off-by: Brandon Breitenstein brandon.breitenstein@intel.com --- M src/ec/google/chromeec/acpi/ec.asl 1 file changed, 9 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/24/40024/4
Prashant Malani has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 4: Code-Review+1
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 4: Code-Review+2
Brandon Breitenstein has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 4:
(2 comments)
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... File src/ec/google/chromeec/acpi/ec.asl:
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 373: Notify (CREC, 0x80)
I chatted a bit with furquan@, and it seems like my suggestion may be the best path forward here for […]
Ack
https://review.coreboot.org/c/coreboot/+/40024/3/src/ec/google/chromeec/acpi... PS3, Line 369: // USB MUX Interrupt : Method (_Q1C, 0, NotSerialized) : { : Store ("EC: USB MUX", Debug) : Notify (CREC, 0x80) : }
During that bring up effort, I used this EC_HOST_EVENT_USB_MUX, since it was a Type-C event, with th […]
Ack
Duncan Laurie has submitted this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
google/chromeec: Add USB MUX Interrupt
Kernel relies on the USB MUX interrupt to configure USB devices that are connected on the Type-C ports for TGL. Adding in the Q1C Interrupt so the Kernel can properly receive and configure USB devices
BUG=b:152902608 TEST=buld_packages for volteer and verified that Proto 1 and Proto 2 are now seeing extcon events
Change-Id: Ie3a2f829a295f090a03e72e12f19ecc5bb724952 Signed-off-by: Brandon Breitenstein brandon.breitenstein@intel.com Reviewed-on: https://review.coreboot.org/c/coreboot/+/40024 Tested-by: build bot (Jenkins) no-reply@coreboot.org Reviewed-by: Prashant Malani pmalani@google.com Reviewed-by: Furquan Shaikh furquan@google.com --- M src/ec/google/chromeec/acpi/ec.asl 1 file changed, 9 insertions(+), 0 deletions(-)
Approvals: build bot (Jenkins): Verified Furquan Shaikh: Looks good to me, approved Prashant Malani: Looks good to me, but someone else must approve
diff --git a/src/ec/google/chromeec/acpi/ec.asl b/src/ec/google/chromeec/acpi/ec.asl index 1b8e128..67e5f56 100644 --- a/src/ec/google/chromeec/acpi/ec.asl +++ b/src/ec/google/chromeec/acpi/ec.asl @@ -355,6 +355,15 @@ Notify (CREC, 0x80) }
+#ifdef EC_ENABLE_PD_MCU_DEVICE + // USB MUX Interrupt + Method (_Q1C, 0, NotSerialized) + { + Store ("EC: USB MUX", Debug) + Notify (_SB.PCI0.LPCB.EC0.CREC.ECPD, 0x80) + } +#endif + // TABLET mode switch Event Method (_Q1D, 0, NotSerialized) {
9elements QA has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40024 )
Change subject: google/chromeec: Add USB MUX Interrupt ......................................................................
Patch Set 5:
Automatic boot test returned (PASS/FAIL/TOTAL): 3/0/3 Emulation targets: EMULATION_QEMU_X86_Q35 using payload TianoCore : SUCCESS : https://lava.9esec.io/r/2308 EMULATION_QEMU_X86_Q35 using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/2307 EMULATION_QEMU_X86_I440FX using payload SeaBIOS : SUCCESS : https://lava.9esec.io/r/2306
Please note: This test is under development and might not be accurate at all!
-
9elements QA (Code Review) -
Brandon Breitenstein (Code Review)
-
Caveh Jalali (Code Review)
-
Duncan Laurie (Code Review)
-
Furquan Shaikh (Code Review)
-
Paul Menzel (Code Review)
-
Prashant Malani (Code Review)
-
Rajmohan Mani (Code Review)
-
Vijay P Hiremath (Code Review)