On Fri, Jul 29, 2022 at 11:46:32AM -0500, Pierre-Louis Bossart wrote: > > >>>>> That should be fine, tools should just be looking for the attributes, > >>>>> not the existance of a directory, right? > >>>> > >>>> The idea what that we would only expose ports that actually exist. > >>>> That's helpful information anyone with a basic knowledge of the > >>>> SoundWire specification would understand. > >>> > >>> Is "dp0" a port? If so, why isn't it a real device? > >> > >> The SoundWire spec defines the concept of 'data port'. The valid ranges > >> are 1..14, but in all existing devices the number of data ports is way > >> smaller, typically 2 to 4. Data ports (DPn) are source or sink, and > >> there's no firm rule that data ports needs to be contiguous. > >> > >> DP0 is a 'special case' where the data transport is used for control > >> information, e.g. programming large set of registers or firmware > >> download. DP0 is completely optional in hardware, and not handled in > >> Linux for now. > >> > >> DP0 and DPn expose low-level transport registers, which define how the > >> contents of a FIFO will be written or read from the bus. Think of it as > >> a generalization of the concept of TDM slots, where instead of having a > >> fixed slot per frame the slot position/repetition/runlength can be > >> programmed. > >> > >> The data ports could be as simple as 1-bit PDM, or support 8ch PCM > >> 24-bits. That's the sort of information reported in attributes. > > > > Why not make them a real device like we do for USB endpoints? > > I don't see what adding another layer of hierarchy would bring. In their > simplest configuration, there are 6 registers 8-bit exposed. And the > port registers, when present, are accessed with a plain vanilla offset. Who uses these registers? > > What uses these sysfs files today that would be confused about an empty > > directory? > > That's a good question. I am not aware of any tools making use of those > attributes. To a large degree, they are helpful only for debug and > support, all these read-only attributes could be moved to debugfs. That > could be a way to simplify everyone's life.... That would be much nicer, put it all in a single debugfs file and it would be so simple. What attributes could we do that for? thanks, greg k-h