[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59f78ca7-ea09-41d7-9e6e-b0ce1af484e4@linux.intel.com>
Date: Thu, 25 Apr 2024 08:43:20 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Mohammad Rafi Shaik <quic_mohs@...cinc.com>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Banajit Goswami <bgoswami@...cinc.com>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>
Cc: linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, quic_rohkumar@...cinc.com,
quic_pkumpatl@...cinc.com
Subject: Re: [PATCH v3 2/7] ASoC: codecs: wcd937x: add wcd937x codec driver
> +struct wcd937x_priv {
> + struct sdw_slave *tx_sdw_dev;
> + struct sdw_slave *rx_sdw_dev;
Does this mean that the codec has 2 SoundWire interfaces?
If yes, aren't there merits in splitting the implementation in two
separate drivers, one for each interface and probing on the relevant partID?
This is how the RT713 was handled. The mic function was exposed as the
RT1713.
By representing the device as a single entity, things could be fun
because the two interfaces are really independent. things like clock
stop are handled at the interface level.
The code in this driver is difficult to review, for example in the probe
you wait for the TX part to complete the enumeration/initialization, but
there's nothing mentioned or stated on the RX part, and there's really
nothing related to the detection of this device. I don't actually see a
sdw_driver at all, it's a platform driver.
Would you mind adding a paragraph on how the SoundWire interfaces are
handled and how the SoundWire bus is involved if there's no sdw_driver?
Thanks!
Powered by blists - more mailing lists