On 08-06-23, 10:09, Pierre-Louis Bossart wrote: > > > On 6/8/23 02:06, Vinod Koul wrote: > > On 31-05-23, 11:37, Bard Liao wrote: > >> From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > >> > >> This patch adds a new Device Number allocation strategy, with the IDA > >> used only for devices that are wake-capable. > >> > >> "regular" devices such as amplifiers will use Device Numbers > >> [1..min_ida-1]. > >> > >> "wake-capable" devices such as jack or microphone codecs will use > >> Device Numbers [min_ida..11]. > >> > >> This hybrid strategy extends the number of supported devices in a > >> system by only constraining the allocation if required, e.g. in the > >> case of Intel LunarLake platforms the wake-capable devices are > >> required to have a unique address to use the HDaudio SDI and HDAudio > >> WAKEEN/WAKESTS registers. > > > > This seems to be a consequence of Intel hardware decisions, so I guess > > best suited place for this is Intel controller, do we really want to > > have this in core logic? > > It's a valid objection. > > The reason why I added the alternate strategies in the core logic is > that the IDA and hybrid approach are just software-based with no > specific hardware dependencies. If QCOM or AMD wanted to use the > strategies contributed and tested by Intel, it'd be a two-line change on > their side. > > That said, it's likely that at some point *someone* will want to > constrain the device number allocation further, be it with ACPI/DT > properties or reading hardware registers. The device number is a > de-facto priority given the way we scan the PING frames, so some systems > may want to give a higher priority to a specific peripherals. > > This would push us to add a master ops callback to control the device > number allocation. It's a bit invasive but that would give the ultimate > flexibility. Reuse between vendors could be possible if 'generic' > callbacks were part of a library to pick from. > > I don't really have any objections if this vendor-specific callback was > preferred, it may be a bit early to add this but long-term it's probably > what makes more sense. > > I'll go with the flow on suggested recommendations. Thanks, if it all one of the other two controller start using this, it would make sense to move it to core then, for now would be better to have this in specific driver -- ~Vinod
