Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in src/drivers/i2c/designware. It is used across multiple platforms and has a quite good configurability from mainboard side. One can tweak everything needed and make it work with the needed timing easily. Though I stumbled lately across a thing I wouldn't expect the way it is.
It is possible to define the speed one needs to operate the I2C bus on in devicetree by setting the .speed-value to one of the supported defines (I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or I2C_SPEED_FAST_ULTRA), e.g.:
register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD } }"
If one just sets the .speed value, the driver will take care about the needed SCL clock rate and set it up to a default value. Yes, these values might be not the best for the current bus load but should at least provide a clock that matches the requested speed. This default values are defined in src/drivers/i2c/designware/dw_i2c.c as follows: /* High and low times in different speed modes (in ns) */ enum { /* SDA Hold Time */ DEFAULT_SDA_HOLD_TIME = 300, /* Standard Speed */ MIN_SS_SCL_HIGHTIME = 4000, MIN_SS_SCL_LOWTIME = 4700, /* Fast Speed */ MIN_FS_SCL_HIGHTIME = 600, MIN_FS_SCL_LOWTIME = 1300, /* Fast Plus Speed */ MIN_FP_SCL_HIGHTIME = 260, MIN_FP_SCL_LOWTIME = 500, /* High Speed */ MIN_HS_SCL_HIGHTIME = 60, MIN_HS_SCL_LOWTIME = 160, };
While these values do match the needed _minimum_ durations for the high and low period of the SCL signal according to the I2C-specification [1], they are not enough for the overall clock cycle to match the requested speed. Let's take standard speed for example:
MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 114,943 kHz instead of 100 kHz The same applies to the other speeds as well.
As the driver is aware of the clock the IP is clocked with inside the Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. There is code already which computes the needed counter values for high and low period from the provided IP-clock, *LOWTIME and *HIGHTIME in dw_i2c_gen_speed_config(): ... if (speed >= I2C_SPEED_HIGH) { /* High speed */ hcnt_min = MIN_HS_SCL_HIGHTIME; lcnt_min = MIN_HS_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST_PLUS) { /* Fast-Plus speed */ hcnt_min = MIN_FP_SCL_HIGHTIME; lcnt_min = MIN_FP_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST) { /* Fast speed */ hcnt_min = MIN_FS_SCL_HIGHTIME; lcnt_min = MIN_FS_SCL_LOWTIME; } else { /* Standard speed */ hcnt_min = MIN_SS_SCL_HIGHTIME; lcnt_min = MIN_SS_SCL_LOWTIME; } config->speed = speed; config->scl_hcnt = ic_clk * hcnt_min / KHz; config->scl_lcnt = ic_clk * lcnt_min / KHz; config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz; ...
I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) to match the needed minimum constraints while still fulfilling the overall clock cycle, e.g. by increasing the HIGHTIME. But I would like to hear other opinions on that. Surely I am not aware of all the use cases out there.
And again: These default values can easily be overridden in the devicetree with something like this: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD, .speed_config[0] = { .speed = I2C_SPEED_STANDARD, .scl_lcnt = 664, .scl_hcnt = 657, /*This value is smaller due to the IP adding a count of 8 internally, see [2]*/ .sda_hold = 39 } }, }"
But I would expect the driver to do it right in the default configuration.
Any input is highly welcome.
Werner
[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf [2] https://dokumen.tips/documents/designware-dw-apb-i2c-databook-pudn-designwar...
Hi Werner,
I agree we could probably do a little better than we do today (feel free to submit a patch ;)), but speaking for what I have seen on bringing up Chrome OS devices, the ODMs ultimately end up having to tweak these values depending on the board design (bus load, etc.); e.g.
``` $ git grep 'scl_lcnt' -- src/mainboard/google/*.cb | wc -l 72 ```
One idea we've had is to implement a sysfs interface in the Linux kernel to expose a way to change these registers at runtime, so they can be tuned, or add a custom module to our payload (depthcharge) to allow tuning these values in the CLI.
-Tim
On Tue, Apr 27, 2021 at 3:01 AM Zeh, Werner werner.zeh@siemens.com wrote:
Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in src/drivers/i2c/designware. It is used across multiple platforms and has a quite good configurability from mainboard side. One can tweak everything needed and make it work with the needed timing easily. Though I stumbled lately across a thing I wouldn't expect the way it is.
It is possible to define the speed one needs to operate the I2C bus on in devicetree by setting the .speed-value to one of the supported defines (I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or I2C_SPEED_FAST_ULTRA), e.g.:
register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD } }"
If one just sets the .speed value, the driver will take care about the needed SCL clock rate and set it up to a default value. Yes, these values might be not the best for the current bus load but should at least provide a clock that matches the requested speed. This default values are defined in src/drivers/i2c/designware/dw_i2c.c as follows: /* High and low times in different speed modes (in ns) */ enum { /* SDA Hold Time */ DEFAULT_SDA_HOLD_TIME = 300, /* Standard Speed */ MIN_SS_SCL_HIGHTIME = 4000, MIN_SS_SCL_LOWTIME = 4700, /* Fast Speed */ MIN_FS_SCL_HIGHTIME = 600, MIN_FS_SCL_LOWTIME = 1300, /* Fast Plus Speed */ MIN_FP_SCL_HIGHTIME = 260, MIN_FP_SCL_LOWTIME = 500, /* High Speed */ MIN_HS_SCL_HIGHTIME = 60, MIN_HS_SCL_LOWTIME = 160, };
While these values do match the needed _minimum_ durations for the high and low period of the SCL signal according to the I2C-specification [1], they are not enough for the overall clock cycle to match the requested speed. Let's take standard speed for example:
MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 114,943 kHz instead of 100 kHz The same applies to the other speeds as well.
As the driver is aware of the clock the IP is clocked with inside the Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. There is code already which computes the needed counter values for high and low period from the provided IP-clock, *LOWTIME and *HIGHTIME in dw_i2c_gen_speed_config(): ... if (speed >= I2C_SPEED_HIGH) { /* High speed */ hcnt_min = MIN_HS_SCL_HIGHTIME; lcnt_min = MIN_HS_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST_PLUS) { /* Fast-Plus speed */ hcnt_min = MIN_FP_SCL_HIGHTIME; lcnt_min = MIN_FP_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST) { /* Fast speed */ hcnt_min = MIN_FS_SCL_HIGHTIME; lcnt_min = MIN_FS_SCL_LOWTIME; } else { /* Standard speed */ hcnt_min = MIN_SS_SCL_HIGHTIME; lcnt_min = MIN_SS_SCL_LOWTIME; } config->speed = speed; config->scl_hcnt = ic_clk * hcnt_min / KHz; config->scl_lcnt = ic_clk * lcnt_min / KHz; config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz; ...
I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) to match the needed minimum constraints while still fulfilling the overall clock cycle, e.g. by increasing the HIGHTIME. But I would like to hear other opinions on that. Surely I am not aware of all the use cases out there.
And again: These default values can easily be overridden in the devicetree with something like this: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD, .speed_config[0] = { .speed = I2C_SPEED_STANDARD, .scl_lcnt = 664, .scl_hcnt = 657, /*This value is smaller due to the IP adding a count of 8 internally, see [2]*/ .sda_hold = 39 } }, }"
But I would expect the driver to do it right in the default configuration.
Any input is highly welcome.
Werner
[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf [2] https://dokumen.tips/documents/designware-dw-apb-i2c-databook-pudn-designwar... _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
In the meantime Kyösti provided a patch [1] where the clock timing is computed based on rise and fall times in the default case. This results in a much more accurate timings which I was able to measure on mb/siemens/mc_apl6
Nevertheless, looking closer to the driver implementation, a few odds are in there. First, the values 7 and 1 [2] (which actually should be 8 and 1 according to the Synopsis specification) are completely uncommented and therefore hard to understand from somebody without the specification in mind. In addition, I still have not fully understood why the spike rejection counter value is subtracted from the count value for the high period as it is not described that way in the specification.
Further on, we easily can run into issues if the OS decides to switch the bus frequency from <= FULL_SPEED_PLUS to HIGH_SPEED on some platforms as e.g. on Apollo Lake there is a stronger output driver enabled internally for HIGH_SPEED mode which significantly changes the rise and fall times. So maybe the earlier implementation, where we had a set of parameters reported in ACPI for every implemented bus speed (removed with [3]), was not so bad in this regard.
Werner
[1] https://review.coreboot.org/c/coreboot/+/52723 [2] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src... [3] https://review.coreboot.org/c/coreboot/+/34385
Von: Tim Wawrzynczak twawrzynczak@google.com Gesendet: Dienstag, 27. April 2021 23:01 An: werner.zeh@siemens.com Cc: coreboot coreboot@coreboot.org Betreff: Re: [coreboot] Default-timings in Designware I2C driver
Hi Werner,
I agree we could probably do a little better than we do today (feel free to submit a patch ;)), but speaking for what I have seen on bringing up Chrome OS devices, the ODMs ultimately end up having to tweak these values depending on the board design (bus load, etc.); e.g.
``` $ git grep 'scl_lcnt' -- src/mainboard/google/*.cb | wc -l 72 ```
One idea we've had is to implement a sysfs interface in the Linux kernel to expose a way to change these registers at runtime, so they can be tuned, or add a custom module to our payload (depthcharge) to allow tuning these values in the CLI.
-Tim
On Tue, Apr 27, 2021 at 3:01 AM Zeh, Werner mailto:werner.zeh@siemens.com wrote: Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in src/drivers/i2c/designware. It is used across multiple platforms and has a quite good configurability from mainboard side. One can tweak everything needed and make it work with the needed timing easily. Though I stumbled lately across a thing I wouldn't expect the way it is.
It is possible to define the speed one needs to operate the I2C bus on in devicetree by setting the .speed-value to one of the supported defines (I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or I2C_SPEED_FAST_ULTRA), e.g.:
register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD } }"
If one just sets the .speed value, the driver will take care about the needed SCL clock rate and set it up to a default value. Yes, these values might be not the best for the current bus load but should at least provide a clock that matches the requested speed. This default values are defined in src/drivers/i2c/designware/dw_i2c.c as follows: /* High and low times in different speed modes (in ns) */ enum { /* SDA Hold Time */ DEFAULT_SDA_HOLD_TIME = 300, /* Standard Speed */ MIN_SS_SCL_HIGHTIME = 4000, MIN_SS_SCL_LOWTIME = 4700, /* Fast Speed */ MIN_FS_SCL_HIGHTIME = 600, MIN_FS_SCL_LOWTIME = 1300, /* Fast Plus Speed */ MIN_FP_SCL_HIGHTIME = 260, MIN_FP_SCL_LOWTIME = 500, /* High Speed */ MIN_HS_SCL_HIGHTIME = 60, MIN_HS_SCL_LOWTIME = 160, };
While these values do match the needed _minimum_ durations for the high and low period of the SCL signal according to the I2C-specification [1], they are not enough for the overall clock cycle to match the requested speed. Let's take standard speed for example:
MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 114,943 kHz instead of 100 kHz The same applies to the other speeds as well.
As the driver is aware of the clock the IP is clocked with inside the Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. There is code already which computes the needed counter values for high and low period from the provided IP-clock, *LOWTIME and *HIGHTIME in dw_i2c_gen_speed_config(): ... if (speed >= I2C_SPEED_HIGH) { /* High speed */ hcnt_min = MIN_HS_SCL_HIGHTIME; lcnt_min = MIN_HS_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST_PLUS) { /* Fast-Plus speed */ hcnt_min = MIN_FP_SCL_HIGHTIME; lcnt_min = MIN_FP_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST) { /* Fast speed */ hcnt_min = MIN_FS_SCL_HIGHTIME; lcnt_min = MIN_FS_SCL_LOWTIME; } else { /* Standard speed */ hcnt_min = MIN_SS_SCL_HIGHTIME; lcnt_min = MIN_SS_SCL_LOWTIME; } config->speed = speed; config->scl_hcnt = ic_clk * hcnt_min / KHz; config->scl_lcnt = ic_clk * lcnt_min / KHz; config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz; ...
I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) to match the needed minimum constraints while still fulfilling the overall clock cycle, e.g. by increasing the HIGHTIME. But I would like to hear other opinions on that. Surely I am not aware of all the use cases out there.
And again: These default values can easily be overridden in the devicetree with something like this: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD, .speed_config[0] = { .speed = I2C_SPEED_STANDARD, .scl_lcnt = 664, .scl_hcnt = 657, /*This value is smaller due to the IP adding a count of 8 internally, see [2]*/ .sda_hold = 39 } }, }"
But I would expect the driver to do it right in the default configuration.
Any input is highly welcome.
Werner
[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co... [2] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdokumen.ti... _______________________________________________ coreboot mailing list -- mailto:coreboot@coreboot.org To unsubscribe send an email to mailto:coreboot-leave@coreboot.org
Hi Werner,
Sorry if you think https://review.coreboot.org/c/coreboot/+/34385 could break things for you. Feel free to push somewhat of a revert (if you can think of a better message than "bad counts" :) )
-Tim
On Thu, Apr 29, 2021 at 8:55 AM Zeh, Werner werner.zeh@siemens.com wrote:
In the meantime Kyösti provided a patch [1] where the clock timing is computed based on rise and fall times in the default case. This results in a much more accurate timings which I was able to measure on mb/siemens/mc_apl6
Nevertheless, looking closer to the driver implementation, a few odds are in there. First, the values 7 and 1 [2] (which actually should be 8 and 1 according to the Synopsis specification) are completely uncommented and therefore hard to understand from somebody without the specification in mind. In addition, I still have not fully understood why the spike rejection counter value is subtracted from the count value for the high period as it is not described that way in the specification.
Further on, we easily can run into issues if the OS decides to switch the bus frequency from <= FULL_SPEED_PLUS to HIGH_SPEED on some platforms as e.g. on Apollo Lake there is a stronger output driver enabled internally for HIGH_SPEED mode which significantly changes the rise and fall times. So maybe the earlier implementation, where we had a set of parameters reported in ACPI for every implemented bus speed (removed with [3]), was not so bad in this regard.
Werner
[1] https://review.coreboot.org/c/coreboot/+/52723 [2] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src... [3] https://review.coreboot.org/c/coreboot/+/34385
Von: Tim Wawrzynczak twawrzynczak@google.com Gesendet: Dienstag, 27. April 2021 23:01 An: werner.zeh@siemens.com Cc: coreboot coreboot@coreboot.org Betreff: Re: [coreboot] Default-timings in Designware I2C driver
Hi Werner,
I agree we could probably do a little better than we do today (feel free to submit a patch ;)), but speaking for what I have seen on bringing up Chrome OS devices, the ODMs ultimately end up having to tweak these values depending on the board design (bus load, etc.); e.g.
$ git grep 'scl_lcnt' -- src/mainboard/google/*.cb | wc -l 72One idea we've had is to implement a sysfs interface in the Linux kernel to expose a way to change these registers at runtime, so they can be tuned, or add a custom module to our payload (depthcharge) to allow tuning these values in the CLI.
-Tim
On Tue, Apr 27, 2021 at 3:01 AM Zeh, Werner mailto:werner.zeh@siemens.com wrote: Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in src/drivers/i2c/designware. It is used across multiple platforms and has a quite good configurability from mainboard side. One can tweak everything needed and make it work with the needed timing easily. Though I stumbled lately across a thing I wouldn't expect the way it is.
It is possible to define the speed one needs to operate the I2C bus on in devicetree by setting the .speed-value to one of the supported defines (I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or I2C_SPEED_FAST_ULTRA), e.g.:
register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD } }"
If one just sets the .speed value, the driver will take care about the needed SCL clock rate and set it up to a default value. Yes, these values might be not the best for the current bus load but should at least provide a clock that matches the requested speed. This default values are defined in src/drivers/i2c/designware/dw_i2c.c as follows: /* High and low times in different speed modes (in ns) */ enum { /* SDA Hold Time */ DEFAULT_SDA_HOLD_TIME = 300, /* Standard Speed */ MIN_SS_SCL_HIGHTIME = 4000, MIN_SS_SCL_LOWTIME = 4700, /* Fast Speed */ MIN_FS_SCL_HIGHTIME = 600, MIN_FS_SCL_LOWTIME = 1300, /* Fast Plus Speed */ MIN_FP_SCL_HIGHTIME = 260, MIN_FP_SCL_LOWTIME = 500, /* High Speed */ MIN_HS_SCL_HIGHTIME = 60, MIN_HS_SCL_LOWTIME = 160, };
While these values do match the needed _minimum_ durations for the high and low period of the SCL signal according to the I2C-specification [1], they are not enough for the overall clock cycle to match the requested speed. Let's take standard speed for example:
MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 114,943 kHz instead of 100 kHz The same applies to the other speeds as well.
As the driver is aware of the clock the IP is clocked with inside the Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. There is code already which computes the needed counter values for high and low period from the provided IP-clock, *LOWTIME and *HIGHTIME in dw_i2c_gen_speed_config(): ... if (speed >= I2C_SPEED_HIGH) { /* High speed */ hcnt_min = MIN_HS_SCL_HIGHTIME; lcnt_min = MIN_HS_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST_PLUS) { /* Fast-Plus speed */ hcnt_min = MIN_FP_SCL_HIGHTIME; lcnt_min = MIN_FP_SCL_LOWTIME; } else if (speed >= I2C_SPEED_FAST) { /* Fast speed */ hcnt_min = MIN_FS_SCL_HIGHTIME; lcnt_min = MIN_FS_SCL_LOWTIME; } else { /* Standard speed */ hcnt_min = MIN_SS_SCL_HIGHTIME; lcnt_min = MIN_SS_SCL_LOWTIME; } config->speed = speed; config->scl_hcnt = ic_clk * hcnt_min / KHz; config->scl_lcnt = ic_clk * lcnt_min / KHz; config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz; ...
I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) to match the needed minimum constraints while still fulfilling the overall clock cycle, e.g. by increasing the HIGHTIME. But I would like to hear other opinions on that. Surely I am not aware of all the use cases out there.
And again: These default values can easily be overridden in the devicetree with something like this: register "common_soc_config" = "{ .i2c[0] = { .speed = I2C_SPEED_STANDARD, .speed_config[0] = { .speed = I2C_SPEED_STANDARD, .scl_lcnt = 664, .scl_hcnt = 657, /*This value is smaller due to the IP adding a count of 8 internally, see [2]*/ .sda_hold = 39 } }, }"
But I would expect the driver to do it right in the default configuration.
Any input is highly welcome.
Werner
[1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.co... [2] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdokumen.ti... _______________________________________________ coreboot mailing list -- mailto:coreboot@coreboot.org To unsubscribe send an email to mailto:coreboot-leave@coreboot.org
Hi Tim.
CB:34385 does not break anything for me because we just use STANDARD speed in our system. It just came to my attention once I had a deeper look at the driver and its evolvement. I just wanted to mention that there are cases where the calculated and reported timing can be suitable for a given speed in coreboot and a speed switch to HIGH in OS (which can be done since the controller supports it and a very similar driver is used at OS-side) will lead to a different timing, worse case not matching the hardware circumstances and therefore ending up in violating the I2C spec.
Werner
Zeh, Werner wrote:
there are cases where the calculated and reported timing can be suitable for a given speed in coreboot and a speed switch to HIGH in OS ... will lead to a different timing, worse case not matching the hardware circumstances and therefore ending up in violating the I2C spec.
I think this is an important point, if the OS driver does not calculate different parameters, but relies on what coreboot prepares.
In that case, coreboot should make an effort to prepare correctly for all speeds, possibly by pushing this responsibility onto whoever adds a new mainboard and/or informing the OS driver about which speeds have actually been correctly prepared by coreboot.
coreboot should indeed not prepare for only some of the possible cases at runtime and then stick its head in the sand yolo style.
Does the coreboot code communicate something to the OS driver already?
//Peter
Hi Peter.
Does the coreboot code communicate something to the OS driver already?
Yes, there is an ACPI entry which reports current timings in dw_i2c_acpi_write_speed_config() [1]. This code used to provide a report for all available speeds but was changed in [2]. Though I am not sure how much of the information would be used by the kernel driver at all. But at least a valid reporting should be something coreboot delivers. The rest is up to the driver.
Werner
[1]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src... [2]: https://review.coreboot.org/c/coreboot/+/34385
-
Peter Stuge -
Tim Wawrzynczak -
Zeh, Werner