| Message ID | 20191219103153.14875-1-srinivas.kandagatla@linaro.org |
|---|---|
| Headers | show |
| Series | ASoC: Add support to WCD9340/WCD9341 codec | expand |
On 19/12/2019 16:36, Pierre-Louis Bossart wrote: > >> +static int wcd934x_slim_status(struct slim_device *sdev, >> + enum slim_device_status status) >> +{ >> + switch (status) { >> + case SLIM_DEVICE_STATUS_UP: >> + return wcd934x_slim_status_up(sdev); >> + case SLIM_DEVICE_STATUS_DOWN: >> + mfd_remove_devices(&sdev->dev); >> + break; >> + default: >> + return -EINVAL; >> + } >> + >> + return 0; >> +} >> + > > this is interesting/surprising - I just noticed what looks like a > significant change in how probe/initialization are handled. > > It was my understanding that in SLIMbus the Linux devices are created at > probe time, and when the device reports present this 'device_status' > callback is used to notify the codec driver of a change. The rationale > for this was that the codec driver may control power switches/gpios that > are necessary for the device to appear on the bus. We use same rational here to power switch and flip reset pins in device probe to power up the actual SLIMBus device in device probe. Only difference here is that the actual SLIMBus device itself is represented as many child devices based on there functionality. SLIMBus parent device in this case is MFD device which is created at probe time. However child devices for that device like gpio controller, codec, clock controller and soundwire controller are created only after the device is enumerated on the bus. Before that none of these devices will be in a position to talk on the bus. > > This argument was used to require an change in the SoundWire > implementation, so we followed this model of creating devices at probe > time based on information reported by ACPI/DT, and used the > 'update_status' callback when the device is present on the bus (which > may happen after a delay or controlled by an external power switch). > This approach can lead to 'ghost devices' described in firmware but not > populated in hardware, and power management opens on how long a bus > needs to remain active if no devices report present. > > What I understand from the code above is that the devices are actually > created when the SLIMbus device reports PRESENT, which seems a 180 > degree change in directions? > Note these are the child devices of the MFD SLIMBus device. > I actually prefer it this way, and all current discussions in MIPI > circles point to the fact that when the bus starts all devices on that > bus should already be powered and have the ability to report present > immediately (if the bus starts in a 'safe' mode and then later programs > different PHY parameters, a device can no longer join the bus) In our case we need to switch on few regulators and flip the reset pio to be able to bring the device to enumerate. > > I would however not remove the devices when the status is down but only > on an explicit .remove. Am open for suggestions but I would not like the child devices to talk on the bus once the SLIMbus device is down! Only way to ensure or make it silent is to remove. Thanks, srini > > Feedback welcome. > -Pierre >
>>> Note these are the child devices of the MFD SLIMBus device. >> >> Ah ok. I guess the creation of those child devices when the parent >> SLIMbus device reports PRESENT initially if fine, it's the part where >> you remove them if the device loses sync or gets powered off which is >> odd. And I guess technically you could still have race conditions >> where a child device starts a transaction just as the parent is no >> longer attached to the bus. > > Losing power to SLIMBus device is very odd usecase and if it happens > suggests that threre are bigger issues on the board design itself. This > case should never happen. Even if it happens we would get timeout errors > on every SLIMbus transactions. > >> >>>> I would however not remove the devices when the status is down but >>>> only on an explicit .remove. >>> >>> Am open for suggestions but I would not like the child devices to >>> talk on the bus once the SLIMbus device is down! Only way to ensure >>> or make it silent is to remove. >> >> it's as if you are missing a mechanism to forward the parent status to >> the children so use remove() for lack of a better solution? > That is true. This gives bit more control on the slave device lifecycle. > Current solution works fine for now with less complexities across > multiple drivers. I also agree that there is scope of improvement in > future for this. ok, makes sense, thanks for the answers. No further questions, so Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This patchset adds support to Qualcomm WCD9340/WCD9341 Codec which is a standalone Hi-Fi audio codec IC. This codec supports both I2S/I2C and SLIMbus audio interfaces. On slimbus interface it supports two data lanes; 16 Tx ports and 8 Rx ports. It has Five DACs and seven dedicated interpolators, Multibutton headset control (MBHC), Active noise cancellation, Sidetone paths, MAD (mic activity detection) and codec processing engine. It supports Class-H differential earpiece out and stereo single ended headphones out. This codec also has integrated SoundWire controller. Patchset for this is already sent for review. This patchset has been tested on SDM845 based DragonBoard DB845c and Lenovo Yoga C630 laptop with WSA881x smart speaker amplifiers via soundwire and 4 DMICs. gpio controller patch does not have any link dependency, it can go by its own. Most of the code in this driver is rework of Qualcomm downstream drivers used in Andriod. Credits to Banajit Goswami and Patrick Lai's Team. Thanks, srini Changes since v5: - added correct MFD dependency to codec driver Srinivas Kandagatla (11): ASoC: dt-bindings: add dt bindings for WCD9340/WCD9341 audio codec mfd: wcd934x: add support to wcd9340/wcd9341 codec ASoC: wcd934x: add support to wcd9340/wcd9341 codec ASoC: wcd934x: add basic controls ASoC: wcd934x: add playback dapm widgets ASoC: wcd934x: add capture dapm widgets ASoC: wcd934x: add audio routings dt-bindings: gpio: wcd934x: Add bindings for gpio gpio: wcd934x: Add support to wcd934x gpio controller ASoC: qcom: dt-bindings: Add compatible for DB845c and Lenovo Yoga ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga .../bindings/gpio/qcom,wcd934x-gpio.yaml | 47 + .../devicetree/bindings/sound/qcom,sdm845.txt | 5 +- .../bindings/sound/qcom,wcd934x.yaml | 175 + drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-wcd934x.c | 104 + drivers/mfd/Kconfig | 12 + drivers/mfd/Makefile | 1 + drivers/mfd/wcd934x.c | 306 + include/linux/mfd/wcd934x/registers.h | 531 ++ include/linux/mfd/wcd934x/wcd934x.h | 31 + sound/soc/codecs/Kconfig | 8 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/wcd934x.c | 5084 +++++++++++++++++ sound/soc/qcom/sdm845.c | 86 +- 15 files changed, 6399 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/qcom,wcd934x-gpio.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml create mode 100644 drivers/gpio/gpio-wcd934x.c create mode 100644 drivers/mfd/wcd934x.c create mode 100644 include/linux/mfd/wcd934x/registers.h create mode 100644 include/linux/mfd/wcd934x/wcd934x.h create mode 100644 sound/soc/codecs/wcd934x.c -- 2.21.0