Re: [PATCH 3/3] soundwire: bus_type: add sdw_master_device support

From: Pierre-Louis Bossart
Date: Tue May 12 2020 - 13:01:09 EST




On 5/12/20 11:08 AM, Pierre-Louis Bossart wrote:


On 5/12/20 10:59 AM, Vinod Koul wrote:
On 12-05-20, 09:36, Pierre-Louis Bossart wrote:
On 5/11/20 10:30 PM, Vinod Koul wrote:
On 11-05-20, 14:00, Pierre-Louis Bossart wrote:
+ÂÂÂ md = &bus->md;
+ÂÂÂ md->dev.bus = &sdw_bus_type;
+ÂÂÂ md->dev.type = &sdw_master_type;
+ÂÂÂ md->dev.parent = parent;
+ÂÂÂ md->dev.of_node = parent->of_node;
+ÂÂÂ md->dev.fwnode = fwnode;
+ÂÂÂ md->dev.dma_mask = parent->dma_mask;
+
+ÂÂÂ dev_set_name(&md->dev, "sdw-master-%d", bus->link_id);

This give nice sdw-master-0. In DT this comes from reg property. I dont
seem to recall if the ACPI/Disco spec treats link_id as unique across
the system, can you check that please, if not we would need to update
this.
Table 3 in the Disco for Soundwire 1.0 spec: "all LinkID values are relative
to the immediate parent Device."

There isn't any known implementation with more than one controller.

But then it can come in "future" right. So lets try to make it future
proof by not using the link_id (we can expose that as a sysfs if people
want to know). So a global unique id needs to allocated (hint: idr or
equivalent) and used as master_id

Can you clarify if you are asking for a global ID for Intel/ACPI platforms,
or for DT as well? I can't figure out from the soundwire-controller.yaml
definitions if there is already a notion of unique ID.

If ACPI was unique, then I was planning to update the definition below
to include that. Given that it is not the case, let's make it agnostic to
underlying firmware.

I am not sure I understand how this would be done.

The call sequence is

sdw_bus_master_add(bus)
ÂÂÂ sdw_master_device_add(bus, parent, fw_node)

At the bus level, we don't have any information on which controller the bus is related to.

We'd need to add an argument to sdw_bus_master_add() and have the controller unique ID be allocated outside of the SoundWire core, hence my question on whether the DT definition should not be extended.

And btw I don't think it makes sense to add a new definition for Intel. We already have a notion of HDaudio bus->idx that's set to zero since we don't have a case for multiple HDaudio controllers.

if we ever do have more than once controller, then we should rely on HDaudio bus->idx as the identifier and not create one specifically for SoundWire - which means as I mentioned above passing an argument and not defining a controller ID in the SoundWire core.