| Message ID | 20240115-feature-xvf3500_driver-v1-2-ed9cfb48bb85@wolfvision.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ALSA: usb: add support for XMOS XVF3500 | expand |
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 <javier.carrasco@wolfvision.net> > --- > .../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 <javier.carrasco@wolfvision.net> > + > +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 <javier.carrasco@wolfvision.net> >> --- >> .../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 <javier.carrasco@wolfvision.net> >> + >> +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/20240104130123.37115-1-brgl@bgdev.pl/ 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/20240104130123.37115-1-brgl@bgdev.pl/ > > Best regards, > Krzysztof > Thanks 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 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
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 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
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 <javier.carrasco@wolfvision.net> + +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>; + }; + +...
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 <javier.carrasco@wolfvision.net> --- .../devicetree/bindings/sound/xmos,xvf3500.yaml | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+)