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
