[AMD Official Use Only - General] Hi Andrew,
I sent out a new V8 series last week. A kernel parameter `wbrf` was introduced there to decide the policy. Please help to check whether that makes sense to you. Please share your insights there. BR, Evan > -----Original Message----- > From: Andrew Lunn <[email protected]> > Sent: Wednesday, July 26, 2023 4:10 AM > To: Limonciello, Mario <[email protected]> > Cc: Quan, Evan <[email protected]>; [email protected]; [email protected]; > Deucher, Alexander <[email protected]>; Koenig, Christian > <[email protected]>; Pan, Xinhui <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; Lazar, Lijo > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; amd- > [email protected]; [email protected]; linux- > [email protected]; [email protected] > Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF > > > This comes back to the point that was mentioned by Johannes - you need > > to have deep design understanding of the hardware to know whether or > > not you will have producers that a consumer need to react to. > > Yes, this is the policy is keep referring to. I would expect that there is > something > somewhere in ACPI which says for this machine, the policy is Yes/No. > > It could well be that AMD based machine has a different ACPI extension to > indicate this policy to what Intel machine has. As far as i understand it, you > have not submitted this yet for formal approval, this is all vendor specific, > so > Intel could do it completely differently. Hence i would expect a generic API > to > tell the core what the policy is, and your glue code can call into ACPI to > find out > that information, and then tell the core. > > > If all producers indicate their frequency and all consumers react to > > it you may have activated mitigations that are unnecessary. The > > hardware designer may have added extra shielding or done the layout > > such that they're not needed. > > And the policy will indicate No, nothing needs to be done. The core can then > tell produces and consumes not to bother telling the core anything. > > > So I don't think we're ever going to be in a situation that the > > generic implementation should be turned on by default. It's a "developer > knob". > > Wrong. You should have a generic core, which your AMD CPU DDR device > plugs into. The Intel CPU DDR device can plug into, the nvidea GPU can plug > into, your Radeon GPU can plug into, the intel ARC can plug into, the generic > WiFi core plugs into, etc. > > > If needed these can then be enabled using the AMD ACPI interface, a DT > > one if one is developed or maybe even an allow-list of SMBIOS strings. > > Notice i've not mentioned DT for a while. I just want a generic core, which > AMD, Intel, nvidea, Ampare, Graviton, Qualcomm, Marvell, ..., etc can use. We > should be solving this problem once, for everybody, not adding a solution for > just one vendor. > > Andrew
