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 [off-list ref] wrote:

quoted

On 12/30/2024 6:44 PM, Pengyu Luo wrote:

quoted

On Mon, Dec 30, 2024 at 5:04 PM Aiqun(Maria) Yu [off-list ref] wrote:

quoted

On 12/28/2024 1:13 AM, Pengyu Luo wrote:

[...]

quoted

quoted

quoted

+     i2c_transfer(client->adapter, msgs, 2);

ARRAY_SIZE(msgs) is suggested instead of pure 2.

Agree

quoted

quoted

+     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