On Tue, Dec 31, 2024 at 03:44:36PM +0800, Pengyu Luo wrote: > On Tue, Dec 31, 2024 at 1:00 PM Aiqun(Maria) Yu <quic_aiquny@xxxxxxxxxxx> wrote: > > On 12/30/2024 6:44 PM, Pengyu Luo wrote: > > > On Mon, Dec 30, 2024 at 5:04 PM Aiqun(Maria) Yu <quic_aiquny@xxxxxxxxxxx> wrote: > > >> On 12/28/2024 1:13 AM, Pengyu Luo wrote: > > [...] > > >>> + i2c_transfer(client->adapter, msgs, 2); > > >> > > >> ARRAY_SIZE(msgs) is suggested instead of pure 2. > > >> > > > > > > Agree > > > > > >>> + usleep_range(2000, 2500); > > >> > > >> Why is a sleep needed here? Is this information specified in any datasheet? > > >> > > > > > > Have a break between 2 transaction. This sleep happens in acpi code, also > > > inside a critical region. I rearranged it. > > > > > > Local7 = Acquire (\_SB.IC16.MUEC, 0x03E8) > > > ... > > > write ops > > > ... > > > Sleep (0x02) > > > ... > > > read ops > > > ... > > > Release (\_SB.IC16.MUEC) > > > > Could you please share the exact code snippet that is being referenced? > > I'm a bit confused because it doesn't seem to align with the current > > logic, which doesn't have read operations within the same mutex lock. I > > also want to understand the background and necessity of the sleep function. > > > > I mentioned I rearranged it to optimize it. In a EC transaction, > write sleep read => write read sleep, in this way, we sleep once a > transaction. Sleeping between write and read is logical: it provides EC some time to respond. Sleeping after read is complete doesn't seem to have any reason. > > Please search > 'device name + acpi table' on the internet, someone dumped it and uploaded > it, in SSDT, check ECCD. I am not sure if huawei allows users to dump it. > So I don't provide it here. -- With best wishes Dmitry
