[coreboot] Re: [RFC] How should we manage tree-wide changes?

2021-04-27 Thread Piotr Król
On 4/21/21 8:33 PM, Patrick Georgi via coreboot wrote: > Hi everybody, Hi, > > In our leadership meeting[1] we discussed how we should deal with > tree-wide changes (ranging from "new file header" to "some API is gone > now"). The concern was that right now, anything can change at any time, >

[coreboot] Re: Default-timings in Designware I2C driver

2021-04-27 Thread Tim Wawrzynczak via coreboot
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

[coreboot] Re: ACPI SSDT Help

2021-04-27 Thread Tim Wawrzynczak via coreboot
Hi Rocky, You have a couple of options that I can think of: 1) Add the device to the DSDT, but find a way to implement a `_STA` Method that will return 0x0 if the device does not exist, and 0xF if it does 2) Push a patch to add a similar mechanism to load a `ssdt.aml` file from CBFS (similar to

[coreboot] Re: [RFC] How should we manage tree-wide changes?

2021-04-27 Thread Patrick Georgi via coreboot
Am Do., 22. Apr. 2021 um 22:58 Uhr schrieb Peter Stuge : > Patrick Georgi via coreboot wrote: > > tree-wide changes > .. > > there may be other approaches on how to make development easier > > I'm a big fan of semantic patching as provided by coccinelle and used > heavily in Linux kernel

[coreboot] Default-timings in Designware I2C driver

2021-04-27 Thread Zeh, Werner
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.