[RFC] Read lane mapping information for soundwire peripherals #4704
Conversation
This patch adds the code to read lane mapping information from ACPI for soundwire peripheral. Signed-off-by: Chao Song <[email protected]>
This patch reads DisCo properties for rt722-sdca soundwire peripheral device. Signed-off-by: Chao Song <[email protected]>
aiChaoSONG
force-pushed
the
lane_mapping
branch
from
3f824b1 to
8708d90
Compare
| * mipi-sdw-lane-x-mapping properties, where x is 1..7, and the values for those | ||
| * properties are mipi-sdw-manager-lane-x or mipi-sdw-peripheral-link-y, where x | ||
| * is an integer between 1 to 7 if the lane is connected to a master lane, y is a | ||
| * character between A to E if the lane is connected to another slave lane. |
There was a problem hiding this comment.
be consistent and use manager/peripheral
| { | ||
| struct sdw_slave_prop *prop = &slave->prop; | ||
| struct device *dev = &slave->dev; | ||
| char prop_name[30]; |
There was a problem hiding this comment.
add a define and explanation for the size
| size_t len; | ||
| int ret, i; | ||
|
|
||
| for (i = 0; i < SDW_MAX_LANES; i++) { |
There was a problem hiding this comment.
i=1, lane0 is always connected
|
|
||
| for (i = 0; i < SDW_MAX_LANES; i++) { | ||
| snprintf(prop_name, sizeof(prop_name), "mipi-sdw-lane-%d-mapping", i); | ||
| ret = device_property_read_string(dev, prop_name, &prop_val); |
There was a problem hiding this comment.
why read a string if you are trying to read an hex value?
There was a problem hiding this comment.
That's the dilemma here, the possible values for the property mipi-sdw-lane-x-mapping are mipi-sdw-manager-lane-y or mipi-sdw-peripheral-link-z in the DisCo spec, where y is an integet between 1 to 7, z is an char between A to E.
With the last character y or z, the link is able to be identified, so I just use the last character from the property value string. Here I store them as character, '1', '2', ... '7', 'A',...,'E'. A second step to transform them to hex value is possible.
Or we could store the intact string mipi-sdw-manager-lane-y/mipi-sdw-peripheral-link-z with a string array, but I think it will be hard to use later, because I think the 1..7 number also denote the lane ID for master device, parsing is needed later.
There was a problem hiding this comment.
why read a string if you are trying to read an hex value?
Because the value shall be mipi-sdw-manager-lane-<m>, where is an integer between 1 and 7 if the lane connects to Manager, or mipi-sdw-peripheral-link-<tag>, where is 1 to 5 characters that uniquely identify the Link in the system if the line connects to Peripheral.
There was a problem hiding this comment.
Ah yes, I missed this in the spec, thanks for enlightening me @bardliao and @aiChaoSONG !
I would report a warning on mipi-sdw-peripheral-link- and ignore it because we don't have support for device-to-device communication. We may add this in the future but this requires a complete rework of the 'stream' definition where there is no manager involved. I don't even know how we would represent this with DPCM, all dai links have cpu- and codec DAIs.
|
SOFCI TEST |
|
Bard will take care of this in SDW multilane support, close |
Before you review the RFC, please spend 5 minutes to read DisCo spec for soundwire(Version 2.0, 7 April 2023) page 16 for the explanation for
mipi-sdw-lane-<n>-mapping, and Page 27 for the Lane Mapping Example.This RFC proposes the structure to store the mapping information(By Bard), and read the mapping information from ACPI and store in the structure (By Chao).
This RFC does not propose how the mapping information in the structure is used, it is the next step.
The mapping information is faked now, because no BIOS provide these information:
Dmesg output for error messge in code: