The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
This device requires two power supplies and a specific power sequence to
reach normal operation, where it registers itself as a USB device. These
constraints cannot be cleanly solved without the use of a driver that
guarantees proper initialization during system power-up sequences and
sleep-mode transitions.
Once in normal operation, the device works like a regular USB device
with the obvious limitation that it cannot be unplugged because of its
onboard nature.
This series adds support for the XMOS XVF3500 and includes the device
bindings, which also required a new entry in vendor-prefixes for the
XMOS manufacturer.
[1] https://www.xmos.com/xvf3500/
Signed-off-by: Javier Carrasco <[email protected]>
---
Javier Carrasco (3):
dt-bindings: vendor-prefixes: add XMOS
ASoC: dt-bindings: xmos,xvf3500: add bindings for XMOS XVF3500
ALSA: usb: add support for XMOS XVF3500
.../devicetree/bindings/sound/xmos,xvf3500.yaml | 51 ++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 ++
sound/usb/Kconfig | 9 ++
sound/usb/Makefile | 3 +-
sound/usb/xvf3500/Makefile | 4 +
sound/usb/xvf3500/xvf3500.c | 140 +++++++++++++++++++++
7 files changed, 215 insertions(+), 1 deletion(-)
---
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
change-id: 20240111-feature-xvf3500_driver-c872839c11be
Best regards,
--
Javier Carrasco <[email protected]>
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
Add new bindings to define the device properties.
[1] https://www.xmos.com/xvf3500/
Signed-off-by: Javier Carrasco <[email protected]>
---
.../devicetree/bindings/sound/xmos,xvf3500.yaml | 51 ++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
new file mode 100644
index 000000000000..e93a735a0f1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: XMOS XVF3500 VocalFusion Voice Processor
+
+maintainers:
+ - Javier Carrasco <[email protected]>
+
+description: |-
+ The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
+ multicore controller for voice processing.
+ https://www.xmos.com/xvf3500/
+
+properties:
+ compatible:
+ const: xmos,xvf3500
+
+ reset-gpios:
+ maxItems: 1
+
+ vcc1v0-supply:
+ description: |
+ Regulator for the 1V0 supply.
+
+ vcc3v3-supply:
+ description: |
+ Regulator for the 3V3 supply.
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reset-gpios
+ - vcc1v0-supply
+ - vcc3v3-supply
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ xvf3500: voice-processor {
+ compatible = "xmos,xvf3500";
+ reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
+ vcc1v0-supply = <&vcc1v0>;
+ vcc3v3-supply = <&vcc3v3>;
+ };
+
+...
--
2.39.2
The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
multicore controller for voice processing.
This simple driver provides the power sequence the device requires,
which consists of enabling the regulators that control the device
supplies and a reset de-assertion after a delay of at least 100ns.
Simple PM operations to handle the power sequence after resuming
from a power-down mode are also provided.
Once in normal operation, the device registers itself as a USB device.
Therefore, this driver requires USB to be available in order to
guarantee full support.
[1] https://www.xmos.com/xvf3500/
Signed-off-by: Javier Carrasco <[email protected]>
---
MAINTAINERS | 7 +++
sound/usb/Kconfig | 9 +++
sound/usb/Makefile | 3 +-
sound/usb/xvf3500/Makefile | 4 ++
sound/usb/xvf3500/xvf3500.c | 140 ++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 162 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a7c4cf8201e0..fb9be0e12c71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23960,6 +23960,13 @@ S: Supported
W: http://www.marvell.com
F: drivers/i2c/busses/i2c-xlp9xx.c
+XMOS XVF3500 VOICE PROCESSOR DRIVER
+M: Javier Carrasco <[email protected]>
+L: [email protected]
+S: Supported
+F: Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
+F: sound/usb/xvf3500/xvf3500.c
+
XRA1403 GPIO EXPANDER
M: Nandor Han <[email protected]>
L: [email protected]
diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index 4a9569a3a39a..11565429163b 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -176,6 +176,15 @@ config SND_BCD2000
To compile this driver as a module, choose M here: the module
will be called snd-bcd2000.
+config SND_XVF3500
+ tristate "XMOS XVF3500 voice processor driver"
+ help
+ Say Y here to include support for the XMOS XVF3500 voice
+ processor.
+
+ To compile this driver as a module, choose M here: the module
+ will be called snd-xvf3500.
+
source "sound/usb/line6/Kconfig"
endif # SND_USB
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 8c657c2753c8..4171db0f483c 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -34,5 +34,6 @@ obj-$(CONFIG_SND_USB_UA101) += snd-usbmidi-lib.o
obj-$(CONFIG_SND_USB_USX2Y) += snd-usbmidi-lib.o
obj-$(CONFIG_SND_USB_US122L) += snd-usbmidi-lib.o
-obj-$(CONFIG_SND) += misc/ usx2y/ caiaq/ 6fire/ hiface/ bcd2000/
+obj-$(CONFIG_SND) += misc/ usx2y/ caiaq/ 6fire/ hiface/ bcd2000/ xvf3500/
obj-$(CONFIG_SND_USB_LINE6) += line6/
+
diff --git a/sound/usb/xvf3500/Makefile b/sound/usb/xvf3500/Makefile
new file mode 100644
index 000000000000..51a61c8f165d
--- /dev/null
+++ b/sound/usb/xvf3500/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+snd-xvf3500-y := xvf3500.o
+
+obj-$(CONFIG_SND_XVF3500) += snd-xvf3500.o
diff --git a/sound/usb/xvf3500/xvf3500.c b/sound/usb/xvf3500/xvf3500.c
new file mode 100644
index 000000000000..647e5d09d1e5
--- /dev/null
+++ b/sound/usb/xvf3500/xvf3500.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Driver for the XMOS XVF3500 VocalFusion Voice Processor.
+ *
+ * Copyright (C) 2023 WolfVision GmbH.
+ *
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+static const char * const supply_names[] = {
+ "vcc1v0",
+ "vcc3v3",
+};
+
+#define NUM_SUPPLIES ARRAY_SIZE(supply_names)
+
+struct xvf3500 {
+ struct regulator_bulk_data supplies[NUM_SUPPLIES];
+ struct device *dev;
+ struct gpio_desc *reset;
+};
+
+static int xvf3500_power(struct xvf3500 *priv, bool on)
+{
+ int ret;
+
+ if (on) {
+ ret = regulator_bulk_enable(NUM_SUPPLIES, priv->supplies);
+ if (ret) {
+ dev_err(priv->dev, "failed to enable supplies: %d\n", ret);
+ return ret;
+ }
+ /*
+ * A delay of >=100ns + regulator startup is needed before releasing
+ * the reset here. Wait for 10 ms to be on the safe side.
+ */
+ fsleep(10000);
+ gpiod_set_value_cansleep(priv->reset, 0);
+ } else {
+ gpiod_set_value_cansleep(priv->reset, 1);
+ ret = regulator_bulk_disable(NUM_SUPPLIES, priv->supplies);
+ if (ret) {
+ dev_err(priv->dev, "failed to disable supplies: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int xvf3500_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct xvf3500 *priv;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ dev_set_drvdata(dev, priv);
+
+ regulator_bulk_set_supply_names(priv->supplies, supply_names,
+ NUM_SUPPLIES);
+
+ ret = devm_regulator_bulk_get(dev, NUM_SUPPLIES, priv->supplies);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to get regulator supplies\n");
+ return ret;
+ }
+
+ priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset))
+ return dev_err_probe(priv->dev, PTR_ERR(priv->reset),
+ "failed to get reset GPIO\n");
+
+ return xvf3500_power(priv, true);
+}
+
+static void xvf3500_remove(struct platform_device *pdev)
+{
+ struct xvf3500 *priv = dev_get_drvdata(&pdev->dev);
+
+ xvf3500_power(priv, false);
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int xvf3500_suspend(struct device *dev)
+{
+ struct xvf3500 *priv = dev_get_drvdata(dev);
+
+ xvf3500_power(priv, false);
+
+ return 0;
+}
+
+static int xvf3500_resume(struct device *dev)
+{
+ struct xvf3500 *priv = dev_get_drvdata(dev);
+
+ xvf3500_power(priv, true);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(xvf3500_pm, xvf3500_suspend, xvf3500_resume);
+#define XVF3500_PM_OPS (&xvf3500_pm)
+#else
+#define XVF3500_PM_OPS NULL
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct of_device_id xvf3500_of_table[] = {
+ {
+ .compatible = "xmos,xvf3500",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xvf3500_of_table);
+
+static struct platform_driver xvf3500_driver = {
+ .driver = {
+ .name = "xvf3500",
+ .of_match_table = xvf3500_of_table,
+ .pm = XVF3500_PM_OPS,
+ },
+ .probe = xvf3500_probe,
+ .remove_new = xvf3500_remove,
+};
+module_platform_driver(xvf3500_driver);
+
+MODULE_AUTHOR("Javier Carrasco <[email protected]>");
+MODULE_DESCRIPTION("XMOS XVF3500 Voice Processor");
+MODULE_LICENSE("GPL");
--
2.39.2
On 15/01/2024 10:16, Javier Carrasco wrote:
> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
> multicore controller for voice processing.
>
> Add new bindings to define the device properties.
I don't see any bus, so how does it work? How do you get the voice data
from it? I also do not see any DAI: neither here nor in the driver...
If there is going to be any new version, then implement all following
comments:
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> [1] https://www.xmos.com/xvf3500/
>
> Signed-off-by: Javier Carrasco <[email protected]>
> ---
> .../devicetree/bindings/sound/xmos,xvf3500.yaml | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
> new file mode 100644
> index 000000000000..e93a735a0f1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: XMOS XVF3500 VocalFusion Voice Processor
> +
> +maintainers:
> + - Javier Carrasco <[email protected]>
> +
> +description: |-
Do not need '|-' unless you need to preserve formatting.
> + The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
> + multicore controller for voice processing.
> + https://www.xmos.com/xvf3500/
> +
> +properties:
> + compatible:
> + const: xmos,xvf3500
> +
> + reset-gpios:
> + maxItems: 1
> +
> + vcc1v0-supply:
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Regulator for the 1V0 supply.
> +
> + vcc3v3-supply:
> + description: |
Do not need '|' unless you need to preserve formatting.
> + Regulator for the 3V3 supply.
> +
> +additionalProperties: false
This goes after required: block.
> +
> +required:
> + - compatible
> + - reset-gpios
> + - vcc1v0-supply
> + - vcc3v3-supply
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + xvf3500: voice-processor {
Drop unused label.
Best regards,
Krzysztof
On 15.01.24 14:02, Krzysztof Kozlowski wrote:
> On 15/01/2024 10:16, Javier Carrasco wrote:
>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>> multicore controller for voice processing.
>>
>> Add new bindings to define the device properties.
>
> I don't see any bus, so how does it work? How do you get the voice data
> from it? I also do not see any DAI: neither here nor in the driver...
>
The voice data and any other information can be retrieved directly via
USB from userspace. Once in normal operation, the device acts as a
regular "onboard" USB device and the driver does not need to do any
further management.
> If there is going to be any new version, then implement all following
> comments:
>
> A nit, subject: drop second/last, redundant "bindings for". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
>
>>
>> [1] https://www.xmos.com/xvf3500/
>>
>> Signed-off-by: Javier Carrasco <[email protected]>
>> ---
>> .../devicetree/bindings/sound/xmos,xvf3500.yaml | 51 ++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
>> new file mode 100644
>> index 000000000000..e93a735a0f1a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/sound/xmos,xvf3500.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: XMOS XVF3500 VocalFusion Voice Processor
>> +
>> +maintainers:
>> + - Javier Carrasco <[email protected]>
>> +
>> +description: |-
>
> Do not need '|-' unless you need to preserve formatting.
>
>
>> + The XMOS XVF3500 VocalFusion Voice Processor is a low-latency, 32-bit
>> + multicore controller for voice processing.
>> + https://www.xmos.com/xvf3500/
>> +
>> +properties:
>> + compatible:
>> + const: xmos,xvf3500
>> +
>> + reset-gpios:
>> + maxItems: 1
>> +
>> + vcc1v0-supply:
>> + description: |
>
> Do not need '|' unless you need to preserve formatting.
>
>
>> + Regulator for the 1V0 supply.
>> +
>> + vcc3v3-supply:
>> + description: |
>
> Do not need '|' unless you need to preserve formatting.
>
>> + Regulator for the 3V3 supply.
>> +
>> +additionalProperties: false
>
> This goes after required: block.
>
>> +
>> +required:
>> + - compatible
>> + - reset-gpios
>> + - vcc1v0-supply
>> + - vcc3v3-supply
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/gpio/gpio.h>
>> +
>> + xvf3500: voice-processor {
>
> Drop unused label.
>
>
>
> Best regards,
> Krzysztof
>
Thank you for your feedback and best regards,
Javier Carrasco
On 15/01/2024 14:58, Javier Carrasco wrote:
> On 15.01.24 14:02, Krzysztof Kozlowski wrote:
>> On 15/01/2024 10:16, Javier Carrasco wrote:
>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>>> multicore controller for voice processing.
>>>
>>> Add new bindings to define the device properties.
>>
>> I don't see any bus, so how does it work? How do you get the voice data
>> from it? I also do not see any DAI: neither here nor in the driver...
>>
> The voice data and any other information can be retrieved directly via
> USB from userspace. Once in normal operation, the device acts as a
> regular "onboard" USB device and the driver does not need to do any
> further management.
So is this an USB device? If yes, then shouldn't be just auto-discovered
and you add here some bindings for other device? This looks like coding
power sequence not in USB node, but in some other, new node.
Best regards,
Krzysztof
On 15.01.24 15:35, Krzysztof Kozlowski wrote:
> On 15/01/2024 14:58, Javier Carrasco wrote:
>> On 15.01.24 14:02, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 10:16, Javier Carrasco wrote:
>>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>>>> multicore controller for voice processing.
>>>>
>>>> Add new bindings to define the device properties.
>>>
>>> I don't see any bus, so how does it work? How do you get the voice data
>>> from it? I also do not see any DAI: neither here nor in the driver...
>>>
>> The voice data and any other information can be retrieved directly via
>> USB from userspace. Once in normal operation, the device acts as a
>> regular "onboard" USB device and the driver does not need to do any
>> further management.
>
> So is this an USB device? If yes, then shouldn't be just auto-discovered
> and you add here some bindings for other device? This looks like coding
> power sequence not in USB node, but in some other, new node.
>
> Best regards,
> Krzysztof
>
It is an USB device that requires two power supplies and a reset to
boot. Afterwards it is auto-discovered and functions normally as a
regular USB device. In that sense it works like the onboard USB HUBs:
https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c
The onboard USB HUB driver is of course more complex because it has to
support other features, but the idea of enabling the power supplies and
toggling the reset signal is essentially the same.
Best regards,
Javier Carrasco
On 15/01/2024 16:59, Javier Carrasco wrote:
>>> The voice data and any other information can be retrieved directly via
>>> USB from userspace. Once in normal operation, the device acts as a
>>> regular "onboard" USB device and the driver does not need to do any
>>> further management.
>>
>> So is this an USB device? If yes, then shouldn't be just auto-discovered
>> and you add here some bindings for other device? This looks like coding
>> power sequence not in USB node, but in some other, new node.
>>
>> Best regards,
>> Krzysztof
>>
> It is an USB device that requires two power supplies and a reset to
> boot. Afterwards it is auto-discovered and functions normally as a
> regular USB device. In that sense it works like the onboard USB HUBs:
>
> https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c
>
> The onboard USB HUB driver is of course more complex because it has to
> support other features, but the idea of enabling the power supplies and
> toggling the reset signal is essentially the same.
>
Yeah, about that... so this is not really correct device representation
for DT. There is no such device as XVF3500 outside of USB bus. There is
XVF3500 but on USB bus and this should be there. In the past we allowed
such root-level devices just because we did not have other way to handle
them. Now we have.
Best regards,
Krzysztof
On 15.01.24 17:03, Krzysztof Kozlowski wrote:
> On 15/01/2024 16:59, Javier Carrasco wrote:
>>>> The voice data and any other information can be retrieved directly via
>>>> USB from userspace. Once in normal operation, the device acts as a
>>>> regular "onboard" USB device and the driver does not need to do any
>>>> further management.
>>>
>>> So is this an USB device? If yes, then shouldn't be just auto-discovered
>>> and you add here some bindings for other device? This looks like coding
>>> power sequence not in USB node, but in some other, new node.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>> It is an USB device that requires two power supplies and a reset to
>> boot. Afterwards it is auto-discovered and functions normally as a
>> regular USB device. In that sense it works like the onboard USB HUBs:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c
>>
>> The onboard USB HUB driver is of course more complex because it has to
>> support other features, but the idea of enabling the power supplies and
>> toggling the reset signal is essentially the same.
>>
>
> Yeah, about that... so this is not really correct device representation
> for DT. There is no such device as XVF3500 outside of USB bus. There is
> XVF3500 but on USB bus and this should be there. In the past we allowed
> such root-level devices just because we did not have other way to handle
> them. Now we have.
>
> Best regards,
> Krzysztof
>
Do you mean that the XVF3500 should not be represented as a platform
device and instead it should turn into an USB device represented as a
node of an USB controller? Something like this (Rockchip SoC):
&usb_host1_xhci {
...
xvf3500 {
...
};
};
Did I get you right or is that not the correct representation? Thank you
again.
Best regards,
Javier Carrasco
On 15/01/2024 17:24, Javier Carrasco wrote:
> Do you mean that the XVF3500 should not be represented as a platform
> device and instead it should turn into an USB device represented as a
> node of an USB controller? Something like this (Rockchip SoC):
>
> &usb_host1_xhci {
> ...
>
> xvf3500 {
> ...
> };
> };
>
> Did I get you right or is that not the correct representation? Thank you
> again.
I believe it should be just like onboard hub. I don't understand why
onboard hub was limited to hub, because other USB devices also could be
designed similarly by hardware folks :/
And if we talk about Linux drivers, then your current solution does not
support suspend/resume and device unbind.
Best regards,
Krzysztof
On 15.01.24 19:11, Krzysztof Kozlowski wrote:
> On 15/01/2024 17:24, Javier Carrasco wrote:
>> Do you mean that the XVF3500 should not be represented as a platform
>> device and instead it should turn into an USB device represented as a
>> node of an USB controller? Something like this (Rockchip SoC):
>>
>> &usb_host1_xhci {
>> ...
>>
>> xvf3500 {
>> ...
>> };
>> };
>>
>> Did I get you right or is that not the correct representation? Thank you
>> again.
>
> I believe it should be just like onboard hub. I don't understand why
> onboard hub was limited to hub, because other USB devices also could be
> designed similarly by hardware folks :/
>
> And if we talk about Linux drivers, then your current solution does not
> support suspend/resume and device unbind.
>
> Best regards,
> Krzysztof
>
Actually this series is an attempt to get rid of a misuse of the
onboard_usb_hub driver by a device that is not a HUB, but requires the
platform-part of that driver for the initialization.
What would be the best approach to provide support upstream? Should I
turn this driver into a generic USB driver that does what the
platform-part of the onboard HUB does? Or are we willing to accept
non-HUB devices in the onboard_usb_hub driver even though it supports
more operations?
I am adding linux-usb to this thread in case someone has other suggestions.
Thanks and best regards,
Javier Carrasco
On 15/01/2024 20:43, Javier Carrasco wrote:
> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>> Do you mean that the XVF3500 should not be represented as a platform
>>> device and instead it should turn into an USB device represented as a
>>> node of an USB controller? Something like this (Rockchip SoC):
>>>
>>> &usb_host1_xhci {
>>> ...
>>>
>>> xvf3500 {
>>> ...
>>> };
>>> };
>>>
>>> Did I get you right or is that not the correct representation? Thank you
>>> again.
>>
>> I believe it should be just like onboard hub. I don't understand why
>> onboard hub was limited to hub, because other USB devices also could be
>> designed similarly by hardware folks :/
>>
>> And if we talk about Linux drivers, then your current solution does not
>> support suspend/resume and device unbind.
>>
>> Best regards,
>> Krzysztof
>>
>
> Actually this series is an attempt to get rid of a misuse of the
> onboard_usb_hub driver by a device that is not a HUB, but requires the
> platform-part of that driver for the initialization.
That's just naming issue, isn't it?
>
> What would be the best approach to provide support upstream? Should I
> turn this driver into a generic USB driver that does what the
> platform-part of the onboard HUB does? Or are we willing to accept
No, because you did not solve the problems I mentioned. This is neither
accurate hardware description nor proper Linux driver model handling PM
and unbind.
> non-HUB devices in the onboard_usb_hub driver even though it supports
> more operations?
>
> I am adding linux-usb to this thread in case someone has other suggestions.
I don't see any difference between this device and onboard hub. The
concept and the problem is the same. Therefore either treat it as as
onboard hub or come with USB-version of PCI power sequencing.
https://lore.kernel.org/all/[email protected]/
Best regards,
Krzysztof
On 15.01.24 21:43, Krzysztof Kozlowski wrote:
> On 15/01/2024 20:43, Javier Carrasco wrote:
>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>> device and instead it should turn into an USB device represented as a
>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>
>>>> &usb_host1_xhci {
>>>> ...
>>>>
>>>> xvf3500 {
>>>> ...
>>>> };
>>>> };
>>>>
>>>> Did I get you right or is that not the correct representation? Thank you
>>>> again.
>>>
>>> I believe it should be just like onboard hub. I don't understand why
>>> onboard hub was limited to hub, because other USB devices also could be
>>> designed similarly by hardware folks :/
>>>
>>> And if we talk about Linux drivers, then your current solution does not
>>> support suspend/resume and device unbind.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Actually this series is an attempt to get rid of a misuse of the
>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>> platform-part of that driver for the initialization.
>
> That's just naming issue, isn't it?
>
>>
>> What would be the best approach to provide support upstream? Should I
>> turn this driver into a generic USB driver that does what the
>> platform-part of the onboard HUB does? Or are we willing to accept
>
> No, because you did not solve the problems I mentioned. This is neither
> accurate hardware description nor proper Linux driver model handling PM
> and unbind.
>
You mentioned the PM handling twice, but I am not sure what you mean.
The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
freeze and memory power states with positive results. On the other hand,
I suppose that you insisted for a good reason, so I would be grateful if
you could show me what I am doing wrong. The macro pattern was taken
from other devices under sound/, which also check CONFIG_PM_SLEEP,
but maybe I took a bad example or missed something.
>> non-HUB devices in the onboard_usb_hub driver even though it supports
>> more operations?
>>
>> I am adding linux-usb to this thread in case someone has other suggestions.
>
> I don't see any difference between this device and onboard hub. The
> concept and the problem is the same. Therefore either treat it as as
> onboard hub or come with USB-version of PCI power sequencing.
>
I have nothing against adding this device to onboard_usb_hub as long as
it is valid upstream, so no conflicts arise with new additions to the
list (which was the trigger for all of this with v6.7). That is
obviously the most trivial solution and as you said, it is justs a
naming issue because the power sequence is not HUB-specific.
> https://lore.kernel.org/all/[email protected]/
>
> Best regards,
> Krzysztof
>
Thanks and best regards,
Javier Carrasco
On 22.01.24 13:01, Takashi Iwai wrote:
> On Tue, 16 Jan 2024 08:29:04 +0100,
> Javier Carrasco wrote:
>>
>> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>>> device and instead it should turn into an USB device represented as a
>>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>>
>>>>>> &usb_host1_xhci {
>>>>>> ...
>>>>>>
>>>>>> xvf3500 {
>>>>>> ...
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>>> again.
>>>>>
>>>>> I believe it should be just like onboard hub. I don't understand why
>>>>> onboard hub was limited to hub, because other USB devices also could be
>>>>> designed similarly by hardware folks :/
>>>>>
>>>>> And if we talk about Linux drivers, then your current solution does not
>>>>> support suspend/resume and device unbind.
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>> Actually this series is an attempt to get rid of a misuse of the
>>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>>> platform-part of that driver for the initialization.
>>>
>>> That's just naming issue, isn't it?
>>>
>>>>
>>>> What would be the best approach to provide support upstream? Should I
>>>> turn this driver into a generic USB driver that does what the
>>>> platform-part of the onboard HUB does? Or are we willing to accept
>>>
>>> No, because you did not solve the problems I mentioned. This is neither
>>> accurate hardware description nor proper Linux driver model handling PM
>>> and unbind.
>>>
>> You mentioned the PM handling twice, but I am not sure what you mean.
>> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
>> freeze and memory power states with positive results. On the other hand,
>> I suppose that you insisted for a good reason, so I would be grateful if
>> you could show me what I am doing wrong. The macro pattern was taken
>> from other devices under sound/, which also check CONFIG_PM_SLEEP,
>> but maybe I took a bad example or missed something.
>
> FWIW, the patterns in sound/ are somewhat outdated and need to be
> refreshed. Nowadays one should use DEFINE_SIMPLE_DEV_PM_OPS() instead
> (that should work without ifdef).
>
>
> thanks,
>
> Takashi
Thank you for your feedback. I noticed that the pattern looks different,
but given that many devices in sound/ still use that pattern, I just
followed suit. In that case I will only use DEFINE_SIMPLE_DEV_PM_OPS.
Thanks again and best regards,
Javier Carrasco
On Tue, 16 Jan 2024 08:29:04 +0100,
Javier Carrasco wrote:
>
> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
> > On 15/01/2024 20:43, Javier Carrasco wrote:
> >> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
> >>> On 15/01/2024 17:24, Javier Carrasco wrote:
> >>>> Do you mean that the XVF3500 should not be represented as a platform
> >>>> device and instead it should turn into an USB device represented as a
> >>>> node of an USB controller? Something like this (Rockchip SoC):
> >>>>
> >>>> &usb_host1_xhci {
> >>>> ...
> >>>>
> >>>> xvf3500 {
> >>>> ...
> >>>> };
> >>>> };
> >>>>
> >>>> Did I get you right or is that not the correct representation? Thank you
> >>>> again.
> >>>
> >>> I believe it should be just like onboard hub. I don't understand why
> >>> onboard hub was limited to hub, because other USB devices also could be
> >>> designed similarly by hardware folks :/
> >>>
> >>> And if we talk about Linux drivers, then your current solution does not
> >>> support suspend/resume and device unbind.
> >>>
> >>> Best regards,
> >>> Krzysztof
> >>>
> >>
> >> Actually this series is an attempt to get rid of a misuse of the
> >> onboard_usb_hub driver by a device that is not a HUB, but requires the
> >> platform-part of that driver for the initialization.
> >
> > That's just naming issue, isn't it?
> >
> >>
> >> What would be the best approach to provide support upstream? Should I
> >> turn this driver into a generic USB driver that does what the
> >> platform-part of the onboard HUB does? Or are we willing to accept
> >
> > No, because you did not solve the problems I mentioned. This is neither
> > accurate hardware description nor proper Linux driver model handling PM
> > and unbind.
> >
> You mentioned the PM handling twice, but I am not sure what you mean.
> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
> freeze and memory power states with positive results. On the other hand,
> I suppose that you insisted for a good reason, so I would be grateful if
> you could show me what I am doing wrong. The macro pattern was taken
> from other devices under sound/, which also check CONFIG_PM_SLEEP,
> but maybe I took a bad example or missed something.
FWIW, the patterns in sound/ are somewhat outdated and need to be
refreshed. Nowadays one should use DEFINE_SIMPLE_DEV_PM_OPS() instead
(that should work without ifdef).
thanks,
Takashi
On 22.01.24 13:29, Krzysztof Kozlowski wrote:
> On 16/01/2024 08:29, Javier Carrasco wrote:
>> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>>> device and instead it should turn into an USB device represented as a
>>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>>
>>>>>> &usb_host1_xhci {
>>>>>> ...
>>>>>>
>>>>>> xvf3500 {
>>>>>> ...
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>>> again.
>>>>>
>>>>> I believe it should be just like onboard hub. I don't understand why
>>>>> onboard hub was limited to hub, because other USB devices also could be
>>>>> designed similarly by hardware folks :/
>>>>>
>>>>> And if we talk about Linux drivers, then your current solution does not
>>>>> support suspend/resume and device unbind.
>>>>>
>>>>> Best regards,
>>>>> Krzysztof
>>>>>
>>>>
>>>> Actually this series is an attempt to get rid of a misuse of the
>>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>>> platform-part of that driver for the initialization.
>>>
>>> That's just naming issue, isn't it?
>>>
>>>>
>>>> What would be the best approach to provide support upstream? Should I
>>>> turn this driver into a generic USB driver that does what the
>>>> platform-part of the onboard HUB does? Or are we willing to accept
>>>
>>> No, because you did not solve the problems I mentioned. This is neither
>>> accurate hardware description nor proper Linux driver model handling PM
>>> and unbind.
>>>
>> You mentioned the PM handling twice, but I am not sure what you mean.
>> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
>> freeze and memory power states with positive results. On the other hand,
>> I suppose that you insisted for a good reason, so I would be grateful if
>> you could show me what I am doing wrong. The macro pattern was taken
>> from other devices under sound/, which also check CONFIG_PM_SLEEP,
>> but maybe I took a bad example or missed something.
>
> You have two Linux devices: USB device and platform device. The platform
> device controls power of USB device. If platform device goes to some
> variant of sleep (PRM, system PM) before the USB device, how will USB
> device react? Will it work? I doubt.
>
> You have no ordering / dependencies / device links between these devices
> thus possible problems.
>
Thank you for clarifying this point. I only covered the platform device
and such device links are missing. I will opt for the inclusion in
onboard_usb_hub, which already covers both devices.
>>>> non-HUB devices in the onboard_usb_hub driver even though it supports
>>>> more operations?
>>>>
>>>> I am adding linux-usb to this thread in case someone has other suggestions.
>>>
>>> I don't see any difference between this device and onboard hub. The
>>> concept and the problem is the same. Therefore either treat it as as
>>> onboard hub or come with USB-version of PCI power sequencing.
>>>
>> I have nothing against adding this device to onboard_usb_hub as long as
>> it is valid upstream, so no conflicts arise with new additions to the
>> list (which was the trigger for all of this with v6.7). That is
>
> I am sorry, but we talk here only about upstream. I don't know therefore
> what "valid upstream" means. You cannot send a patch which is "not valid
> upstream". I mean, technically you can, but this would be waste of our
> time and receive rather annoyed responses.
>
I meant valid upstream, so sending such patch makes sense to the
community (and not only to us). So far you are the source of feedback
upstream, so I will follow your advice.
>> obviously the most trivial solution and as you said, it is justs a
>> naming issue because the power sequence is not HUB-specific.
>
> I would ack it. Others? No clue, I also do not remember full story
> behind onboard USB hub and why it was called "hub" instead of "onboard
> USB device".
>
> Best regards,
> Krzysztof
>
Thank you and best regards,
Javier Carrasco
On 16/01/2024 08:29, Javier Carrasco wrote:
> On 15.01.24 21:43, Krzysztof Kozlowski wrote:
>> On 15/01/2024 20:43, Javier Carrasco wrote:
>>> On 15.01.24 19:11, Krzysztof Kozlowski wrote:
>>>> On 15/01/2024 17:24, Javier Carrasco wrote:
>>>>> Do you mean that the XVF3500 should not be represented as a platform
>>>>> device and instead it should turn into an USB device represented as a
>>>>> node of an USB controller? Something like this (Rockchip SoC):
>>>>>
>>>>> &usb_host1_xhci {
>>>>> ...
>>>>>
>>>>> xvf3500 {
>>>>> ...
>>>>> };
>>>>> };
>>>>>
>>>>> Did I get you right or is that not the correct representation? Thank you
>>>>> again.
>>>>
>>>> I believe it should be just like onboard hub. I don't understand why
>>>> onboard hub was limited to hub, because other USB devices also could be
>>>> designed similarly by hardware folks :/
>>>>
>>>> And if we talk about Linux drivers, then your current solution does not
>>>> support suspend/resume and device unbind.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Actually this series is an attempt to get rid of a misuse of the
>>> onboard_usb_hub driver by a device that is not a HUB, but requires the
>>> platform-part of that driver for the initialization.
>>
>> That's just naming issue, isn't it?
>>
>>>
>>> What would be the best approach to provide support upstream? Should I
>>> turn this driver into a generic USB driver that does what the
>>> platform-part of the onboard HUB does? Or are we willing to accept
>>
>> No, because you did not solve the problems I mentioned. This is neither
>> accurate hardware description nor proper Linux driver model handling PM
>> and unbind.
>>
> You mentioned the PM handling twice, but I am not sure what you mean.
> The driver provides callbacks for SIMPLE_DEV_PM_OPS, which I tested in
> freeze and memory power states with positive results. On the other hand,
> I suppose that you insisted for a good reason, so I would be grateful if
> you could show me what I am doing wrong. The macro pattern was taken
> from other devices under sound/, which also check CONFIG_PM_SLEEP,
> but maybe I took a bad example or missed something.
You have two Linux devices: USB device and platform device. The platform
device controls power of USB device. If platform device goes to some
variant of sleep (PRM, system PM) before the USB device, how will USB
device react? Will it work? I doubt.
You have no ordering / dependencies / device links between these devices
thus possible problems.
>>> non-HUB devices in the onboard_usb_hub driver even though it supports
>>> more operations?
>>>
>>> I am adding linux-usb to this thread in case someone has other suggestions.
>>
>> I don't see any difference between this device and onboard hub. The
>> concept and the problem is the same. Therefore either treat it as as
>> onboard hub or come with USB-version of PCI power sequencing.
>>
> I have nothing against adding this device to onboard_usb_hub as long as
> it is valid upstream, so no conflicts arise with new additions to the
> list (which was the trigger for all of this with v6.7). That is
I am sorry, but we talk here only about upstream. I don't know therefore
what "valid upstream" means. You cannot send a patch which is "not valid
upstream". I mean, technically you can, but this would be waste of our
time and receive rather annoyed responses.
> obviously the most trivial solution and as you said, it is justs a
> naming issue because the power sequence is not HUB-specific.
I would ack it. Others? No clue, I also do not remember full story
behind onboard USB hub and why it was called "hub" instead of "onboard
USB device".
Best regards,
Krzysztof