On Mon, Mar 18, 2024 at 11:27:37PM -0500, Samuel Holland wrote: > Hi Inochi, > > On 2024-03-18 11:03 PM, Inochi Amaoto wrote: > > On Mon, Mar 18, 2024 at 10:22:47PM -0500, Samuel Holland wrote: > >> On 2024-03-18 1:38 AM, Inochi Amaoto wrote: > >>> The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with > >>> an additional channel remap register located in the top system control > >>> area. The DMA channel is exclusive to each core. > >>> > >>> Add the dmamux binding for CV18XX/SG200X series SoC > >>> > >>> Signed-off-by: Inochi Amaoto <inochiama@outlook.com> > >>> Reviewed-by: Rob Herring <robh@kernel.org> > >>> --- > >>> .../bindings/dma/sophgo,cv1800-dmamux.yaml | 47 ++++++++++++++++ > >>> include/dt-bindings/dma/cv1800-dma.h | 55 +++++++++++++++++++ > >>> 2 files changed, 102 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > >>> create mode 100644 include/dt-bindings/dma/cv1800-dma.h > >>> > >>> diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > >>> new file mode 100644 > >>> index 000000000000..c813c66737ba > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > >>> @@ -0,0 +1,47 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: Sophgo CV1800/SG200 Series DMA mux > >>> + > >>> +maintainers: > >>> + - Inochi Amaoto <inochiama@outlook.com> > >>> + > >>> +allOf: > >>> + - $ref: dma-router.yaml# > >>> + > >>> +properties: > >>> + compatible: > >>> + const: sophgo,cv1800-dmamux > >>> + > >>> + reg: > >>> + maxItems: 2 > >>> + > >>> + '#dma-cells': > >>> + const: 3 > >>> + description: > >>> + The first cells is DMA channel. The second one is device id. > >>> + The third one is the cpu id. > >> > >> There are 43 devices, but only 8 channels. Since the channel is statically > >> specified in the devicetree as the first cell here, that means the SoC DT author > >> must pre-select which 8 of the 43 devices are usable, right? > > > > Yes, you are right. > > > >> And then the rest > >> would have to omit their dma properties. Wouldn't it be better to leave out the > >> channel number here and dynamically allocate channels at runtime? > >> > > > > You mean defining all the dma channel in the device and allocation channel > > selectively? This is workable, but it still needs a hint to allocate channel. > > I mean allocating hardware channels only when a channel is requested by a client > driver. The dmamux driver could maintain a counter and allocate the channels > sequentially -- then the first 8 calls to cv1800_dmamux_route_allocate() would > succeed and later calls from other devices would fail. > > > Also, according to the information from sophgo, it does not support dynamic > > channel allocation, so all channel can only be initialize once. > > That's important to know. In that case, the driver should probably leave the > registers alone in cv1800_dmamux_free(), and then scan to see if a device is > already mapped to a channel before allocating a new one. (Or it should have some > other way of remembering the mapping.) That way a single client can repeatedly > allocate/free its DMA channel without consuming all of the hardware channels. > Yes, this is needed. > > There is another problem, since we defined all the dmas property in the device, > > How to mask the devices if we do not want to use dma on them? I have see SPI > > device will disable DMA when allocation failed, I guess this is this mechanism > > is the same for all devices? > > I2C/SPI/UART controller drivers generally still work after failing to acquire a > DMA channel. For audio-related drivers, DMA is generally a hard dependency. > > If each board has 8 or fewer DMA-capable devices enabled in its DT, there is no > problem. If some board enables more than 8 DMA-capable devices, then it should > use "/delete-property/ dmas;" on the devices that would be least impacted by > missing DMA. Otherwise, which devices get functional DMA depends on driver probe > order. > > Normally you wouldn't need to do "/delete-property/ dmas;", because many drivers > only request the DMA channel when actively being used (e.g. userspace has the > TTY/spidev/ALSA device file open), but this doesn't help if you can only assign > each channel once. > That is the problem. It is hard when the register can be only write once. It may be better to let the end user to determine which device wants dma. I will do some more reverse engineering to check whether it is possible to do a remap, And at least for now, I will implement the basic mechanisms. Thanks for your explanation. > Regards, > Samuel > > >>> + > >>> + dma-masters: > >>> + maxItems: 1 > >>> + > >>> + dma-requests: > >>> + const: 8 > >>> + > >>> +required: > >>> + - '#dma-cells' > >>> + - dma-masters > >>> + > >>> +additionalProperties: false > >>> + > >>> +examples: > >>> + - | > >>> + dma-router { > >>> + compatible = "sophgo,cv1800-dmamux"; > >>> + #dma-cells = <3>; > >>> + dma-masters = <&dmac>; > >>> + dma-requests = <8>; > >>> + }; > >>> diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h > >>> new file mode 100644 > >>> index 000000000000..3ce9dac25259 > >>> --- /dev/null > >>> +++ b/include/dt-bindings/dma/cv1800-dma.h > >>> @@ -0,0 +1,55 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ > >>> + > >>> +#ifndef __DT_BINDINGS_DMA_CV1800_H__ > >>> +#define __DT_BINDINGS_DMA_CV1800_H__ > >>> + > >>> +#define DMA_I2S0_RX 0 > >>> +#define DMA_I2S0_TX 1 > >>> +#define DMA_I2S1_RX 2 > >>> +#define DMA_I2S1_TX 3 > >>> +#define DMA_I2S2_RX 4 > >>> +#define DMA_I2S2_TX 5 > >>> +#define DMA_I2S3_RX 6 > >>> +#define DMA_I2S3_TX 7 > >>> +#define DMA_UART0_RX 8 > >>> +#define DMA_UART0_TX 9 > >>> +#define DMA_UART1_RX 10 > >>> +#define DMA_UART1_TX 11 > >>> +#define DMA_UART2_RX 12 > >>> +#define DMA_UART2_TX 13 > >>> +#define DMA_UART3_RX 14 > >>> +#define DMA_UART3_TX 15 > >>> +#define DMA_SPI0_RX 16 > >>> +#define DMA_SPI0_TX 17 > >>> +#define DMA_SPI1_RX 18 > >>> +#define DMA_SPI1_TX 19 > >>> +#define DMA_SPI2_RX 20 > >>> +#define DMA_SPI2_TX 21 > >>> +#define DMA_SPI3_RX 22 > >>> +#define DMA_SPI3_TX 23 > >>> +#define DMA_I2C0_RX 24 > >>> +#define DMA_I2C0_TX 25 > >>> +#define DMA_I2C1_RX 26 > >>> +#define DMA_I2C1_TX 27 > >>> +#define DMA_I2C2_RX 28 > >>> +#define DMA_I2C2_TX 29 > >>> +#define DMA_I2C3_RX 30 > >>> +#define DMA_I2C3_TX 31 > >>> +#define DMA_I2C4_RX 32 > >>> +#define DMA_I2C4_TX 33 > >>> +#define DMA_TDM0_RX 34 > >>> +#define DMA_TDM0_TX 35 > >>> +#define DMA_TDM1_RX 36 > >>> +#define DMA_AUDSRC 37 > >>> +#define DMA_SPI_NAND 38 > >>> +#define DMA_SPI_NOR 39 > >>> +#define DMA_UART4_RX 40 > >>> +#define DMA_UART4_TX 41 > >>> +#define DMA_SPI_NOR1 42 > >>> + > >>> +#define DMA_CPU_A53 0 > >>> +#define DMA_CPU_C906_0 1 > >>> +#define DMA_CPU_C906_1 2 > >>> + > >>> + > >>> +#endif // __DT_BINDINGS_DMA_CV1800_H__ > >>> -- > >>> 2.44.0 > >>> > >>> > >>> _______________________________________________ > >>> linux-riscv mailing list > >>> linux-riscv@lists.infradead.org > >>> http://lists.infradead.org/mailman/listinfo/linux-riscv > >> >
On 16/03/2024 14:06, Ayush Singh wrote: > > Are you sure this fits in Linux coding style limit (not checkpatch > limit, but the limit expressed by Linux coding style)? > > > Well, I am just using clang-format with column width of 100 instead of > 80. The docs now say 80 is prefered rather than mandatory, so well I was So you introduce your own style? Then consider it mandatory... > using 100 since I prefer that. If 80 is necessary or would make review > easier than I can just switch to it. You do not choose your own coding style. > > > I will remove serdev, pwm, clickID and send a new patch with the minimal > driver and better commit messages as suggested with Vaishnav. It is > important to have good support for mikroBUS boards without clickID as well. Best regards, Krzysztof
On 19/03/2024 01:51, Tanmay Shah wrote:
> Hello Krzysztof,
>
> Thanks for reviews. Please find my comments below.
>
> On 3/17/24 1:53 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal-NET platform is successor of Versal platform. It
>>> contains multiple clusters of cortex-R52 real-time processing units.
>>> Each cluster contains two cores of cortex-R52 processors. Each cluster
>>> can be configured in lockstep mode or split mode.
>>>
>>> Each R52 core is assigned 128KB of TCM memory. ATCM memory is 64KB, BTCM
>>> and CTCM memoreis are 32KB each. Each TCM memory has its own dedicated
>>> power-domain that needs to be requested before using it.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> .../remoteproc/xlnx,zynqmp-r5fss.yaml | 220 +++++++++++++++---
>>> 1 file changed, 184 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> index 711da0272250..55654ee02eef 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> @@ -18,7 +18,9 @@ description: |
>>>
>>> properties:
>>> compatible:
>>> - const: xlnx,zynqmp-r5fss
>>> + enum:
>>> + - xlnx,zynqmp-r5fss
>>> + - xlnx,versal-net-r52fss
>>>
>>> "#address-cells":
>>> const: 2
>>> @@ -64,7 +66,9 @@ patternProperties:
>>>
>>> properties:
>>> compatible:
>>> - const: xlnx,zynqmp-r5f
>>> + enum:
>>> + - xlnx,zynqmp-r5f
>>> + - xlnx,versal-net-r52f
>>>
>>> reg:
>>> minItems: 1
>>> @@ -135,9 +139,11 @@ required:
>>> allOf:
>>> - if:
>>> properties:
>>> - xlnx,cluster-mode:
>>> - enum:
>>> - - 1
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - xlnx,versal-net-r52fss
>>
>> Why do you touch these lines?
>>
>>> +
>>> then:
>>> patternProperties:
>>> "^r5f@[0-9a-f]+$":
>>> @@ -149,16 +155,14 @@ allOf:
>>> items:
>>> - description: ATCM internal memory
>>> - description: BTCM internal memory
>>> - - description: extra ATCM memory in lockstep mode
>>> - - description: extra BTCM memory in lockstep mode
>>> + - description: CTCM internal memory
>>>
>>> reg-names:
>>> minItems: 1
>>> items:
>>> - - const: atcm0
>>> - - const: btcm0
>>> - - const: atcm1
>>> - - const: btcm1
>>> + - const: atcm
>>> + - const: btcm
>>> + - const: ctcm
>>>
>>> power-domains:
>>> minItems: 2
>>> @@ -166,33 +170,70 @@ allOf:
>>> - description: RPU core power domain
>>> - description: ATCM power domain
>>> - description: BTCM power domain
>>> - - description: second ATCM power domain
>>> - - description: second BTCM power domain
>>> + - description: CTCM power domain
>>>
>>> else:
>>> - patternProperties:
>>> - "^r5f@[0-9a-f]+$":
>>> - type: object
>>> -
>>> - properties:
>>> - reg:
>>> - minItems: 1
>>> - items:
>>> - - description: ATCM internal memory
>>> - - description: BTCM internal memory
>>> -
>>> - reg-names:
>>> - minItems: 1
>>> - items:
>>> - - const: atcm0
>>> - - const: btcm0
>>> -
>>> - power-domains:
>>> - minItems: 2
>>> - items:
>>> - - description: RPU core power domain
>>> - - description: ATCM power domain
>>> - - description: BTCM power domain
>>> + allOf:
>>> + - if:
>>> + properties:
>>> + xlnx,cluster-mode:
>>> + enum:
>>> + - 1
>>
>> Whatever you did here, is not really readable. You have now multiple
>> if:then:if:then embedded.
>
> For ZynqMP platform, TCM can be configured differently in lockstep mode
> and split mode.
>
> For Versal-NET no such configuration is available, but new CTCM memory
> is added.
>
> So, I am trying to achieve following representation of TCM for both:
>
> if: versal-net compatible
> then:
> ATCM - 64KB
> BTCM - 32KB
> CTCM - 32KB
>
> else: (ZynqMP compatible)
> if:
> xlnx,cluster-mode (lockstep mode)
> then:
> ATCM0 - 64KB
> BTCM0 - 64KB
> ATCM1 - 64KB
> BTCM1 - 64KB
> else: (split mode)
> ATCM0 - 64KB
> BTCM0 - 64KB
>
>
> If bindings are getting complicated, does it make sense to introduce
> new file for Versal-NET bindings? Let me know how you would like me
> to proceed.
All this is broken in your previous patchset, but now we nicely see.
No, this does not work like this. You do not have entirely different
programming models in one device, don't you?
Best regards,
Krzysztof
On 11/03/2024 18:59, Tanmay Shah wrote:
> From: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled memories(TCMs) are low-latency memory that provides
> predictable instruction execution and predictable data load/store
> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>
> The TCM resources(reg, reg-names and power-domain) are documented for
> each TCM in the R5 node. The reg and reg-names are made as required
> properties as we don't want to hardcode TCM addresses for future
> platforms and for zu+ legacy implementation will ensure that the
> old dts w/o reg/reg-names works and stable ABI is maintained.
>
> It also extends the examples for TCM split and lockstep modes.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
I responded under my reviewed-tag, but to be clear, also here:
This patch has is not ready. Please do not merge.
Best regards,
Krzysztof
On 12/03/2024 13:13, Krzysztof Kozlowski wrote:
> On 11/03/2024 18:59, Tanmay Shah wrote:
>> From: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>>
>> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
>> UltraScale+ platform. It will help in defining TCM in device-tree
>> and make it's access platform agnostic and data-driven.
>>
>> Tightly-coupled memories(TCMs) are low-latency memory that provides
>> predictable instruction execution and predictable data load/store
>> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
>> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>>
>> The TCM resources(reg, reg-names and power-domain) are documented for
>> each TCM in the R5 node. The reg and reg-names are made as required
>> properties as we don't want to hardcode TCM addresses for future
>> platforms and for zu+ legacy implementation will ensure that the
>> old dts w/o reg/reg-names works and stable ABI is maintained.
>>
>> It also extends the examples for TCM split and lockstep modes.
>>
>> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>>
>> Changes in v13:
>> - Have power-domains property for lockstep case instead of
>> keeping it flexible.
>> - Add "items:" list in power-domains property
>
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
And unreviewed. It turns out you now mix devices and bring incompatible
programming models under one compatible. And this leads to problems in
your further patches.
NAK.
Best regards,
Krzysztof
On 19/03/2024 02:06, Tanmay Shah wrote:
>
>
> On 3/17/24 1:55 PM, Krzysztof Kozlowski wrote:
>> On 15/03/2024 22:15, Tanmay Shah wrote:
>>> AMD-Xilinx Versal and Versal-NET are successor of ZynqMP platform. ZynqMP
>>> remoteproc driver is mostly compatible with new platforms except few
>>> platform specific differences.
>>>
>>> Versal has same IP of cortex-R5 cores hence maintained compatible string
>>> same as ZynqMP platform. However, hardcode TCM addresses are not
>>> supported for new platforms and must be provided in device-tree as per
>>> new bindings. This makes TCM representation data-driven and easy to
>>> maintain. This check is provided in the driver.
>>>
>>> For Versal-NET platform, TCM doesn't need to be configured in lockstep
>>> mode or split mode. Hence that call to PMC firmware is avoided in the
>>> driver for Versal-NET platform.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> drivers/remoteproc/xlnx_r5_remoteproc.c | 19 +++++++++++++++----
>>> 1 file changed, 15 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> index d4a22caebaad..193bc159d1b4 100644
>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> @@ -323,9 +323,12 @@ static int zynqmp_r5_set_mode(struct zynqmp_r5_core *r5_core,
>>> return ret;
>>> }
>>>
>>> - ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>>> - if (ret < 0)
>>> - dev_err(r5_core->dev, "failed to configure TCM\n");
>>> + /* TCM configuration is not needed in versal-net */
>>> + if (device_is_compatible(r5_core->dev, "xlnx,zynqmp-r5f")) {
>>> + ret = zynqmp_pm_set_tcm_config(r5_core->pm_domain_id, tcm_mode);
>>> + if (ret < 0)
>>> + dev_err(r5_core->dev, "failed to configure TCM\n");
>>> + }
>>>
>>> return ret;
>>> }
>>> @@ -933,10 +936,17 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>>> int ret, i;
>>>
>>> r5_core = cluster->r5_cores[0];
>>> +
>>> + /*
>>> + * New platforms must use device tree for TCM parsing.
>>> + * Only ZynqMP uses hardcode TCM.
>>> + */
>>> if (of_find_property(r5_core->np, "reg", NULL))
>>> ret = zynqmp_r5_get_tcm_node_from_dt(cluster);
>>> - else
>>> + else if (of_machine_is_compatible("xlnx,zynqmp"))
>>> ret = zynqmp_r5_get_tcm_node(cluster);
>>
>> That's poor code. Your drivers should not depend on platform. I don't
>> understand why you need to do this and how is even related to this patch.
>
> You are correct, ideally this shouldn't be needed. However, this driver contains
> hardcode TCM addresses that were used before TCM bindings were designed and available in
> device-tree. This check is provided to maintain backward compatibility with device-tree
> where TCM isn't expected.
>
> For new platforms (Versal and Versal-NET) TCM must be provided in device-tree and for
> ZynqMP if it's not in device-tree then to maintain backward compatibility hardcode
> addresses are used.
That does not work like this. You cannot bind to some sort of different
compatible. If you disagree, please list the compatibles the driver
binds to.
Best regards,
Krzysztof
On 19/03/2024 04:57, Anjelique Melendez wrote:
>
>
> On 3/14/2024 2:20 PM, Krzysztof Kozlowski wrote:
>> On 14/03/2024 21:04, Anjelique Melendez wrote:
>>> Update the Qualcomm Technologies, Inc. PMIC GPIO binding documentation
>>> to include compatible strings for PMIH010x and PMD802x PMICs.
>>>
>>> Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
>>> ---
>>> .../bindings/pinctrl/qcom,pmic-gpio.yaml | 20 +++++++++++++++++++
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>>> index 2b17d244f051..5cc04c016b25 100644
>>> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>>> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>>> @@ -57,10 +57,12 @@ properties:
>>> - qcom,pma8084-gpio
>>> - qcom,pmc8180-gpio
>>> - qcom,pmc8180c-gpio
>>> + - qcom,pmd802x-gpio
>>
>> Is the "x" some sort of wildcard or actual PMIC model/version name?
>> Wildcards are in general discouraged.
>>
>
> "x" is being used as a wildcard here so can update with actual PMIC version
> in next version.
>
Then please drop it also in all future submissions, as asked by writing
bindings.
Best regards,
Krzysztof
On 17/03/2024 16:52, Jan Dakinevich wrote: > > > On 3/15/24 13:22, Jerome Brunet wrote: >> >> On Fri 15 Mar 2024 at 11:00, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: >> >>> On 15/03/2024 00:21, Jan Dakinevich wrote: >>>> This option allow to redefine the rate of DSP system clock. >>> >>> And why is it suitable for bindings? Describe the hardware, not what you >>> want to do in the driver. >>> >>>> >>>> Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com> >>>> --- >>>> Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml | 4 ++++ >>>> 1 file changed, 4 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml >>>> index df21dd72fc65..d2f23a59a6b6 100644 >>>> --- a/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml >>>> +++ b/Documentation/devicetree/bindings/sound/amlogic,axg-pdm.yaml >>>> @@ -40,6 +40,10 @@ properties: >>>> resets: >>>> maxItems: 1 >>>> >>>> + sysrate: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: redefine rate of DSP system clock >>> >>> No vendor prefix, so is it a generic property? Also, missing unit >>> suffix, but more importantly I don't understand why this is a property >>> of hardware. >> >> +1. >> >> The appropriate way to set rate of the clock before the driver take over >> is 'assigned-rate', if you need to customize this for different >> platform. >> > > It would be great, but it doesn't work. Below, is what I want to see: > > assigned-clocks = > <&clkc_audio AUD2_CLKID_PDM_SYSCLK_SEL>, > <&clkc_audio AUD2_CLKID_PDM_SYSCLK_DIV>; > assigned-clock-parents = > <&clkc_pll CLKID_FCLK_DIV3>, > <0>; > assigned-clock-rates = > <0>, > <256000000>; > > But regardles of this declaration, PDM's driver unconditionally sets That's driver's problem. You do not change bindings, just because your driver behaves differently. Just fix driver. > sysclk'rate to 250MHz and throws away everything that was configured > before, reparents audio2_pdm_sysclk_mux to hifi_pll and changes > hifi_pll's rate. > > This value 250MHz is declared here: > > static const struct axg_pdm_cfg axg_pdm_config = { > .filters = &axg_default_filters, > .sys_rate = 250000000, > }; > > The property 'sysrate' is intended to redefine hardcoded 'sys_rate' > value in 'axg_pdm_config'. What does it have to do with bindings? Change driver if you are not happy how it operates. Best regards, Krzysztof
On 17/03/2024 17:35, Jan Dakinevich wrote:
>
>
> On 3/17/24 19:27, Krzysztof Kozlowski wrote:
>> On 17/03/2024 16:55, Jan Dakinevich wrote:
>>>
>>>
>>> On 3/15/24 13:00, Krzysztof Kozlowski wrote:
>>>> On 15/03/2024 00:21, Jan Dakinevich wrote:
>>>>> This option allow to redefine the rate of DSP system clock.
>>>>
>>>> And why is it suitable for bindings? Describe the hardware, not what you
>>>> want to do in the driver.
>>>>
>>>
>>> What do you mean? I am adding some new property and should describe it
>>> in dt-bindinds. Isn't it?
>>
>> No, if the property is not suitable for bindings, you should not add it
>> in the first place. So again: explain what sort of hardware, not driver,
>> problem you are solving here, so we can understand why do you need new
>> property. Otherwise use existing properties or no properties, because we
>> do not define all possible clocks in the bindings.
>>
>> Let's be clear: with such commit msg explanation as you have, my answer
>> is: no, driver should set clock frequency and you do not need this
>> property at all.
>>
>
> Could you please take a look on answer to "Jerome Brunet
> <jbrunet@baylibre.com>"'s message on the same thread. There, I am trying
> to explain what I am solving by this commit.
How is this answer here? You asked "What do you mean", so apparently you
did not understand why I am responding and why you cannot just document
whatever you wish, because that "whatever you wish" is not correct. I
explained that but now you respond that I should read other part of
emails. Really?
So again, do you understand that commit msg should provide rationale why
you think this describes hardware and why this is suitable for bindings?
Best regards,
Krzysztof
The production PDK3 carrier board rev.200 contains additional GPIO expander to control power and reset signals for each CSI2 plug separately. Describe this expander in the carrier board DT. The label is used by sensor DTOs to reference the expander and its signals. Signed-off-by: Marek Vasut <marex@denx.de> --- Cc: Conor Dooley <conor+dt@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: devicetree@vger.kernel.org Cc: imx@lists.linux.dev Cc: kernel@dh-electronics.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts index b749e28e5ede5..ac7ec7533a3c8 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-pdk3.dts @@ -167,6 +167,16 @@ sgtl5000: codec@a { VDDIO-supply = <®_vdd_3p3v_awo>; }; + csi2exp: gpio@24 { + compatible = "nxp,pca9570"; + reg = <0x24>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = + "CSI2_#RESET", "CSI2_#PWDN", + "CSI_#PWDN", "CSI_#RESET"; + }; + typec@3d { compatible = "nxp,ptn5150"; reg = <0x3d>; -- 2.43.0
Hi Inochi, On 2024-03-18 11:03 PM, Inochi Amaoto wrote: > On Mon, Mar 18, 2024 at 10:22:47PM -0500, Samuel Holland wrote: >> On 2024-03-18 1:38 AM, Inochi Amaoto wrote: >>> The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with >>> an additional channel remap register located in the top system control >>> area. The DMA channel is exclusive to each core. >>> >>> Add the dmamux binding for CV18XX/SG200X series SoC >>> >>> Signed-off-by: Inochi Amaoto <inochiama@outlook.com> >>> Reviewed-by: Rob Herring <robh@kernel.org> >>> --- >>> .../bindings/dma/sophgo,cv1800-dmamux.yaml | 47 ++++++++++++++++ >>> include/dt-bindings/dma/cv1800-dma.h | 55 +++++++++++++++++++ >>> 2 files changed, 102 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml >>> create mode 100644 include/dt-bindings/dma/cv1800-dma.h >>> >>> diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml >>> new file mode 100644 >>> index 000000000000..c813c66737ba >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml >>> @@ -0,0 +1,47 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Sophgo CV1800/SG200 Series DMA mux >>> + >>> +maintainers: >>> + - Inochi Amaoto <inochiama@outlook.com> >>> + >>> +allOf: >>> + - $ref: dma-router.yaml# >>> + >>> +properties: >>> + compatible: >>> + const: sophgo,cv1800-dmamux >>> + >>> + reg: >>> + maxItems: 2 >>> + >>> + '#dma-cells': >>> + const: 3 >>> + description: >>> + The first cells is DMA channel. The second one is device id. >>> + The third one is the cpu id. >> >> There are 43 devices, but only 8 channels. Since the channel is statically >> specified in the devicetree as the first cell here, that means the SoC DT author >> must pre-select which 8 of the 43 devices are usable, right? > > Yes, you are right. > >> And then the rest >> would have to omit their dma properties. Wouldn't it be better to leave out the >> channel number here and dynamically allocate channels at runtime? >> > > You mean defining all the dma channel in the device and allocation channel > selectively? This is workable, but it still needs a hint to allocate channel. I mean allocating hardware channels only when a channel is requested by a client driver. The dmamux driver could maintain a counter and allocate the channels sequentially -- then the first 8 calls to cv1800_dmamux_route_allocate() would succeed and later calls from other devices would fail. > Also, according to the information from sophgo, it does not support dynamic > channel allocation, so all channel can only be initialize once. That's important to know. In that case, the driver should probably leave the registers alone in cv1800_dmamux_free(), and then scan to see if a device is already mapped to a channel before allocating a new one. (Or it should have some other way of remembering the mapping.) That way a single client can repeatedly allocate/free its DMA channel without consuming all of the hardware channels. > There is another problem, since we defined all the dmas property in the device, > How to mask the devices if we do not want to use dma on them? I have see SPI > device will disable DMA when allocation failed, I guess this is this mechanism > is the same for all devices? I2C/SPI/UART controller drivers generally still work after failing to acquire a DMA channel. For audio-related drivers, DMA is generally a hard dependency. If each board has 8 or fewer DMA-capable devices enabled in its DT, there is no problem. If some board enables more than 8 DMA-capable devices, then it should use "/delete-property/ dmas;" on the devices that would be least impacted by missing DMA. Otherwise, which devices get functional DMA depends on driver probe order. Normally you wouldn't need to do "/delete-property/ dmas;", because many drivers only request the DMA channel when actively being used (e.g. userspace has the TTY/spidev/ALSA device file open), but this doesn't help if you can only assign each channel once. Regards, Samuel >>> + >>> + dma-masters: >>> + maxItems: 1 >>> + >>> + dma-requests: >>> + const: 8 >>> + >>> +required: >>> + - '#dma-cells' >>> + - dma-masters >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + dma-router { >>> + compatible = "sophgo,cv1800-dmamux"; >>> + #dma-cells = <3>; >>> + dma-masters = <&dmac>; >>> + dma-requests = <8>; >>> + }; >>> diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h >>> new file mode 100644 >>> index 000000000000..3ce9dac25259 >>> --- /dev/null >>> +++ b/include/dt-bindings/dma/cv1800-dma.h >>> @@ -0,0 +1,55 @@ >>> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ >>> + >>> +#ifndef __DT_BINDINGS_DMA_CV1800_H__ >>> +#define __DT_BINDINGS_DMA_CV1800_H__ >>> + >>> +#define DMA_I2S0_RX 0 >>> +#define DMA_I2S0_TX 1 >>> +#define DMA_I2S1_RX 2 >>> +#define DMA_I2S1_TX 3 >>> +#define DMA_I2S2_RX 4 >>> +#define DMA_I2S2_TX 5 >>> +#define DMA_I2S3_RX 6 >>> +#define DMA_I2S3_TX 7 >>> +#define DMA_UART0_RX 8 >>> +#define DMA_UART0_TX 9 >>> +#define DMA_UART1_RX 10 >>> +#define DMA_UART1_TX 11 >>> +#define DMA_UART2_RX 12 >>> +#define DMA_UART2_TX 13 >>> +#define DMA_UART3_RX 14 >>> +#define DMA_UART3_TX 15 >>> +#define DMA_SPI0_RX 16 >>> +#define DMA_SPI0_TX 17 >>> +#define DMA_SPI1_RX 18 >>> +#define DMA_SPI1_TX 19 >>> +#define DMA_SPI2_RX 20 >>> +#define DMA_SPI2_TX 21 >>> +#define DMA_SPI3_RX 22 >>> +#define DMA_SPI3_TX 23 >>> +#define DMA_I2C0_RX 24 >>> +#define DMA_I2C0_TX 25 >>> +#define DMA_I2C1_RX 26 >>> +#define DMA_I2C1_TX 27 >>> +#define DMA_I2C2_RX 28 >>> +#define DMA_I2C2_TX 29 >>> +#define DMA_I2C3_RX 30 >>> +#define DMA_I2C3_TX 31 >>> +#define DMA_I2C4_RX 32 >>> +#define DMA_I2C4_TX 33 >>> +#define DMA_TDM0_RX 34 >>> +#define DMA_TDM0_TX 35 >>> +#define DMA_TDM1_RX 36 >>> +#define DMA_AUDSRC 37 >>> +#define DMA_SPI_NAND 38 >>> +#define DMA_SPI_NOR 39 >>> +#define DMA_UART4_RX 40 >>> +#define DMA_UART4_TX 41 >>> +#define DMA_SPI_NOR1 42 >>> + >>> +#define DMA_CPU_A53 0 >>> +#define DMA_CPU_C906_0 1 >>> +#define DMA_CPU_C906_1 2 >>> + >>> + >>> +#endif // __DT_BINDINGS_DMA_CV1800_H__ >>> -- >>> 2.44.0 >>> >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>
On Mon, Feb 26, 2024 at 05:43:29PM -0500, Frank Li wrote: > On Tue, Feb 27, 2024 at 12:52:45AM +0300, Serge Semin wrote: > > On Tue, Feb 13, 2024 at 04:50:26PM -0500, Frank Li wrote: > > > Reserve space at end of first IORESOURCE_MEM window as message TLP MMIO > > > window. This space's size is 'region_align'. > > > > > > Set outbound ATU map memory write to send PCI message. So one MMIO write > > > can trigger a PCI message, such as PME_Turn_Off. > > > > > > Add common dwc_pme_turn_off() function. > > > > > > Call dwc_pme_turn_off() to send out PME_Turn_Off message in general > > > dw_pcie_suspend_noirq() if there are not platform callback pme_turn_off() > > > exist. > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > > --- > > > drivers/pci/controller/dwc/pcie-designware-host.c | 93 ++++++++++++++++++++++- > > > drivers/pci/controller/dwc/pcie-designware.h | 2 + > > > 2 files changed, 91 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c > > > index 267687ab33cbc..5e83756492462 100644 > > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > > > @@ -393,6 +393,31 @@ static int dw_pcie_msi_host_init(struct dw_pcie_rp *pp) > > > return 0; > > > } > > > > > > +static void dw_pcie_host_request_msg_tlp_res(struct dw_pcie_rp *pp) > > > +{ > > > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > > > + struct resource_entry *win; > > > + struct resource *res; > > > + > > > + win = resource_list_first_type(&pp->bridge->windows, IORESOURCE_MEM); > > > + if (win) { > > > + res = devm_kzalloc(pci->dev, sizeof(*res), GFP_KERNEL); > > > + if (!res) > > > + return; > > > + > > > + /* Reserve last region_align block as message TLP space */ > > > + res->start = win->res->end - pci->region_align + 1; > > > + res->end = win->res->end; > > > + res->name = "msg"; > > > + res->flags = win->res->flags | IORESOURCE_BUSY; > > > + > > > + if (!request_resource(win->res, res)) > > > + pp->msg_res = res; > > > + else > > > + devm_kfree(pci->dev, res); > > > + } > > > +} > > > + > > > int dw_pcie_host_init(struct dw_pcie_rp *pp) > > > { > > > struct dw_pcie *pci = to_dw_pcie_from_pp(pp); > > > @@ -479,6 +504,9 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp) > > > > > > dw_pcie_iatu_detect(pci); > > > > > > > > + /* Need call after dw_pcie_iatu_detect() before dw_pcie_setup_rc() */ > > > + dw_pcie_host_request_msg_tlp_res(pp); > > > > This may cause regressions for instance if the outbound memory window > > is small and is fully dedicated for some device like VGA/GPU/etc. > > There are host memory map windows, which are quite big. It will be too > small if only because one page size windows less. > > Look like it is impossible to dedicated to one device, all pcie devices > (VGA/GPU) should go through standard pcie probe flow, the bar will be > allocated from bridge windows space. > No, Sergey's concern is still valid. You are allocating the memory for TLPs at the end of the existing MEM range. But there is a chance that it could cause memory hungry devices like GPU to run out of memory in an existing setup. That being said, I also do not want to hold off merging this series. So let's make this region opt-in for drivers making use of this feature. This way, if we migrate to a dedicated 'ranges' region in the future, we can remove the conditional check and base the check on the existence of the new region. - Mani > > > > Why not to use a new ranges-based mapping as we discussed earlier: > > https://lore.kernel.org/linux-pci/20240214061412.GB4618@thinkpad/ > > ? > > If driver can auto alloc from known range, why need static defined in dts > files. > > static alloc can't resolve small outbound memory windows problem. It may > disable this feature. > > > > > I know it might be troublesome but still it would be much better > > and more portable across various platforms. > > > > Bjorn, Lorenzo, Krzysztofm Rob could you please follow the link above > > and give your opinion about the solution suggested there? > > > > -Serge(y) > > > > > + > > > ret = dw_pcie_edma_detect(pci); > > > if (ret) > > > goto err_free_msi; > > > @@ -536,6 +564,11 @@ void dw_pcie_host_deinit(struct dw_pcie_rp *pp) > > > > > > dw_pcie_edma_remove(pci); > > > > > > + if (pp->msg_res) { > > > + release_resource(pp->msg_res); > > > + devm_kfree(pci->dev, pp->msg_res); > > > + } > > > + > > > if (pp->has_msi_ctrl) > > > dw_pcie_free_msi(pp); > > > > > > @@ -697,6 +730,10 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp) > > > atu.pci_addr = entry->res->start - entry->offset; > > > atu.size = resource_size(entry->res); > > > > > > + /* MSG TLB window resource reserve at one of end of IORESOURCE_MEM resource */ > > > + if (pp->msg_res && pp->msg_res->parent == entry->res) > > > + atu.size -= resource_size(pp->msg_res); > > > + > > > ret = dw_pcie_prog_outbound_atu(pci, &atu); > > > if (ret) { > > > dev_err(pci->dev, "Failed to set MEM range %pr\n", > > > @@ -728,6 +765,8 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp) > > > dev_warn(pci->dev, "Ranges exceed outbound iATU size (%d)\n", > > > pci->num_ob_windows); > > > > > > + pp->msg_atu_index = i; > > > + > > > i = 0; > > > resource_list_for_each_entry(entry, &pp->bridge->dma_ranges) { > > > if (resource_type(entry->res) != IORESOURCE_MEM) > > > @@ -833,11 +872,54 @@ int dw_pcie_setup_rc(struct dw_pcie_rp *pp) > > > } > > > EXPORT_SYMBOL_GPL(dw_pcie_setup_rc); > > > > > > +/* Using message outbound ATU to send out PME_Turn_Off message for dwc PCIe controller */ > > > +static int dw_pcie_pme_turn_off(struct dw_pcie *pci) > > > +{ > > > + struct dw_pcie_ob_atu_cfg atu = { 0 }; > > > + void __iomem *m; > > > + int ret; > > > + > > > + if (pci->num_ob_windows <= pci->pp.msg_atu_index) > > > + return -EINVAL; > > > + > > > + if (!pci->pp.msg_res) > > > + return -EINVAL; > > > + > > > + atu.code = PCIE_MSG_CODE_PME_TURN_OFF; > > > + atu.routing = PCIE_MSG_TYPE_R_BC; > > > + atu.type = PCIE_ATU_TYPE_MSG; > > > + atu.size = resource_size(pci->pp.msg_res); > > > + atu.index = pci->pp.msg_atu_index; > > > + > > > + if (!atu.size) { > > > + dev_dbg(pci->dev, > > > + "atu memory map windows is zero, please check 'msg' reg in dts\n"); > > > + return -ENOMEM; > > > + } > > > + > > > + atu.cpu_addr = pci->pp.msg_res->start; > > > + > > > + ret = dw_pcie_prog_outbound_atu(pci, &atu); > > > + if (ret) > > > + return ret; > > > + > > > + m = ioremap(atu.cpu_addr, pci->region_align); > > > + if (!m) > > > + return -ENOMEM; > > > + > > > + /* A dummy write is converted to a Msg TLP */ > > > + writel(0, m); > > > + > > > + iounmap(m); > > > + > > > + return 0; > > > +} > > > + > > > int dw_pcie_suspend_noirq(struct dw_pcie *pci) > > > { > > > u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); > > > u32 val; > > > - int ret; > > > + int ret = 0; > > > > > > /* > > > * If L1SS is supported, then do not put the link into L2 as some > > > @@ -849,10 +931,13 @@ int dw_pcie_suspend_noirq(struct dw_pcie *pci) > > > if (dw_pcie_get_ltssm(pci) <= DW_PCIE_LTSSM_DETECT_ACT) > > > return 0; > > > > > > - if (!pci->pp.ops->pme_turn_off) > > > - return 0; > > > + if (pci->pp.ops->pme_turn_off) > > > + pci->pp.ops->pme_turn_off(&pci->pp); > > > + else > > > + ret = dw_pcie_pme_turn_off(pci); > > > > > > - pci->pp.ops->pme_turn_off(&pci->pp); > > > + if (ret) > > > + return ret; > > > > > > ret = read_poll_timeout(dw_pcie_get_ltssm, val, val == DW_PCIE_LTSSM_L2_IDLE, > > > PCIE_PME_TO_L2_TIMEOUT_US/10, > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h > > > index 703b50bc5e0f1..9e6076aa4c850 100644 > > > --- a/drivers/pci/controller/dwc/pcie-designware.h > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h > > > @@ -341,6 +341,8 @@ struct dw_pcie_rp { > > > struct pci_host_bridge *bridge; > > > raw_spinlock_t lock; > > > DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS); > > > + int msg_atu_index; > > > + struct resource *msg_res; > > > }; > > > > > > struct dw_pcie_ep_ops { > > > > > > -- > > > 2.34.1 > > > > > > -- மணிவண்ணன் சதாசிவம்
> +/** > + * struct xilinx_fpga_core - interface between the driver and the core manager > + * of Xilinx 7 Series FPGA manager > + * @dev: device node > + * @write: write callback of the driver > + * @prog_b: PROGRAM_B gpio descriptor > + * @init_b: INIT_B gpio descriptor > + * @done: DONE gpio descriptor Please re-check the Documentation again: "Structure fields that are inside a private: area are not listed in the generated output documentation" > + */ > +struct xilinx_fpga_core { > +/* public: */ > + struct device *dev; > + int (*write)(struct xilinx_fpga_core *core, const char *buf, > + size_t count); > +/* private: handled by xilinx-core */ > + struct gpio_desc *prog_b; > + struct gpio_desc *init_b; > + struct gpio_desc *done; > +}; > + [...] > - > static int xilinx_spi_probe(struct spi_device *spi) > { > - struct xilinx_spi_conf *conf; > - struct fpga_manager *mgr; > + struct xilinx_fpga_core *conf; Why do you name it conf? Maybe "core" is better? Thanks, Yilun
CYW43439 is a Wi-Fi + Bluetooth combo device from Infineon. The Bluetooth part is capable of Bluetooth 5.2 BR/EDR/LE . This chip is present e.g. on muRata 1YN module. Extend the binding with its DT compatible using fallback compatible string to "brcm,bcm4329-bt" which seems to be the oldest compatible device. This should also prevent the growth of compatible string tables in drivers. The existing block of compatible strings is retained. Signed-off-by: Marek Vasut <marex@denx.de> --- Cc: "David S. Miller" <davem@davemloft.net> Cc: Conor Dooley <conor+dt@kernel.org> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org --- V2: - Introduce fallback compatible string - Reword the second half of commit message to reflect that --- .../bindings/net/broadcom-bluetooth.yaml | 33 +++++++++++-------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml index cc70b00c6ce57..4a1bfc2b35849 100644 --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml @@ -14,20 +14,25 @@ description: properties: compatible: - enum: - - brcm,bcm20702a1 - - brcm,bcm4329-bt - - brcm,bcm4330-bt - - brcm,bcm4334-bt - - brcm,bcm43430a0-bt - - brcm,bcm43430a1-bt - - brcm,bcm43438-bt - - brcm,bcm4345c5 - - brcm,bcm43540-bt - - brcm,bcm4335a0 - - brcm,bcm4349-bt - - cypress,cyw4373a0-bt - - infineon,cyw55572-bt + oneOf: + - items: + - enum: + - infineon,cyw43439-bt + - const: brcm,bcm4329-bt + - enum: + - brcm,bcm20702a1 + - brcm,bcm4329-bt + - brcm,bcm4330-bt + - brcm,bcm4334-bt + - brcm,bcm43430a0-bt + - brcm,bcm43430a1-bt + - brcm,bcm43438-bt + - brcm,bcm4345c5 + - brcm,bcm43540-bt + - brcm,bcm4335a0 + - brcm,bcm4349-bt + - cypress,cyw4373a0-bt + - infineon,cyw55572-bt shutdown-gpios: maxItems: 1 -- 2.43.0
On Mon, Mar 18, 2024 at 10:36:01PM -0500, Samuel Holland wrote: > On 2024-03-18 1:38 AM, Inochi Amaoto wrote: > > Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping > > its request lines. The multiplexer supports at most 8 request lines. > > > > Add driver for Sophgo CV18XX/SG200X DMA multiplexer. > > > > Signed-off-by: Inochi Amaoto <inochiama@outlook.com> > > --- > > drivers/dma/Kconfig | 9 ++ > > drivers/dma/Makefile | 1 + > > drivers/dma/cv1800-dmamux.c | 232 ++++++++++++++++++++++++++++++++++++ > > 3 files changed, 242 insertions(+) > > create mode 100644 drivers/dma/cv1800-dmamux.c > > > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > > index 002a5ec80620..cb31520b9f86 100644 > > --- a/drivers/dma/Kconfig > > +++ b/drivers/dma/Kconfig > > @@ -546,6 +546,15 @@ config PLX_DMA > > These are exposed via extra functions on the switch's > > upstream port. Each function exposes one DMA channel. > > > > +config SOPHGO_CV1800_DMAMUX > > + tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support" > > + depends on MFD_SYSCON > > + depends on ARCH_SOPHGO > > + help > > + Support for the DMA multiplexer on Sophgo CV1800/SG2000 > > + series SoCs. > > + Say Y here if your board have this soc. > > + > > config STE_DMA40 > > bool "ST-Ericsson DMA40 support" > > depends on ARCH_U8500 > > diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile > > index dfd40d14e408..7465f249ee47 100644 > > --- a/drivers/dma/Makefile > > +++ b/drivers/dma/Makefile > > @@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/ > > obj-$(CONFIG_PXA_DMA) += pxa_dma.o > > obj-$(CONFIG_RENESAS_DMA) += sh/ > > obj-$(CONFIG_SF_PDMA) += sf-pdma/ > > +obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o > > obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o > > obj-$(CONFIG_STM32_DMA) += stm32-dma.o > > obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o > > diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c > > new file mode 100644 > > index 000000000000..b41c39f2e338 > > --- /dev/null > > +++ b/drivers/dma/cv1800-dmamux.c > > @@ -0,0 +1,232 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com> > > + */ > > + > > +#include <linux/bitops.h> > > +#include <linux/module.h> > > +#include <linux/of_dma.h> > > +#include <linux/of_address.h> > > +#include <linux/of_platform.h> > > +#include <linux/platform_device.h> > > +#include <linux/regmap.h> > > +#include <linux/spinlock.h> > > +#include <linux/mfd/syscon.h> > > + > > +#include <soc/sophgo/cv1800-sysctl.h> > > +#include <dt-bindings/dma/cv1800-dma.h> > > + > > +#define DMAMUX_NCELLS 3 > > +#define MAX_DMA_MAPPING_ID DMA_SPI_NOR1 > > +#define MAX_DMA_CPU_ID DMA_CPU_C906_1 > > +#define MAX_DMA_CH_ID 7 > > + > > +#define DMAMUX_INTMUX_REGISTER_LEN 4 > > +#define DMAMUX_NR_CH_PER_REGISTER 4 > > +#define DMAMUX_BIT_PER_CH 8 > > +#define DMAMUX_CH_MASk GENMASK(5, 0) > > +#define DMAMUX_INT_BIT_PER_CPU 10 > > +#define DMAMUX_CH_UPDATE_BIT BIT(31) > > + > > +#define DMAMUX_CH_SET(chid, val) \ > > + (((val) << ((chid) * DMAMUX_BIT_PER_CH)) | DMAMUX_CH_UPDATE_BIT) > > +#define DMAMUX_CH_MASK(chid) \ > > + DMAMUX_CH_SET(chid, DMAMUX_CH_MASk) > > + > > +#define DMAMUX_INT_BIT(chid, cpuid) \ > > + BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid)) > > +#define DMAMUX_INTEN_BIT(cpuid) \ > > + DMAMUX_INT_BIT(8, cpuid) > > +#define DMAMUX_INT_CH_BIT(chid, cpuid) \ > > + (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid)) > > +#define DMAMUX_INT_MASK(chid) \ > > + (DMAMUX_INT_BIT(chid, DMA_CPU_A53) | \ > > + DMAMUX_INT_BIT(chid, DMA_CPU_C906_0) | \ > > + DMAMUX_INT_BIT(chid, DMA_CPU_C906_1)) > > +#define DMAMUX_INT_CH_MASK(chid, cpuid) \ > > + (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid)) > > + > > +struct cv1800_dmamux_data { > > + struct dma_router dmarouter; > > + struct regmap *regmap; > > + spinlock_t lock; > > + DECLARE_BITMAP(used_chans, MAX_DMA_CH_ID); > > + DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID); > > +}; > > + > > +struct cv1800_dmamux_map { > > + unsigned int channel; > > + unsigned int peripheral; > > + unsigned int cpu; > > +}; > > + > > +static void cv1800_dmamux_free(struct device *dev, void *route_data) > > +{ > > + struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev); > > + struct cv1800_dmamux_map *map = route_data; > > + u32 regoff = map->channel % DMAMUX_NR_CH_PER_REGISTER; > > + u32 regpos = map->channel / DMAMUX_NR_CH_PER_REGISTER; > > + unsigned long flags; > > + > > + spin_lock_irqsave(&dmamux->lock, flags); > > + > > + regmap_update_bits(dmamux->regmap, > > + regpos + CV1800_SDMA_DMA_CHANNEL_REMAP0, > > + DMAMUX_CH_MASK(regoff), > > + DMAMUX_CH_UPDATE_BIT); > > + > > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX, > > + DMAMUX_INT_CH_MASK(map->channel, map->cpu), > > + DMAMUX_INTEN_BIT(map->cpu)); > > + > > + clear_bit(map->channel, dmamux->used_chans); > > + clear_bit(map->peripheral, dmamux->mapped_peripherals); > > + > > + spin_unlock_irqrestore(&dmamux->lock, flags); > > + > > + kfree(map); > > +} > > + > > +static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, > > + struct of_dma *ofdma) > > +{ > > + struct platform_device *pdev = of_find_device_by_node(ofdma->of_node); > > + struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev); > > + struct cv1800_dmamux_map *map; > > + unsigned long flags; > > + unsigned int chid, devid, cpuid; > > + u32 regoff, regpos; > > + > > + if (dma_spec->args_count != DMAMUX_NCELLS) { > > + dev_err(&pdev->dev, "invalid number of dma mux args\n"); > > + return ERR_PTR(-EINVAL); > > + } > > + > > + chid = dma_spec->args[0]; > > + devid = dma_spec->args[1]; > > + cpuid = dma_spec->args[2]; > > + dma_spec->args_count -= 2; > > + > > + if (chid > MAX_DMA_CH_ID) { > > + dev_err(&pdev->dev, "invalid channel id: %u\n", chid); > > + return ERR_PTR(-EINVAL); > > + } > > + > > + if (devid > MAX_DMA_MAPPING_ID) { > > + dev_err(&pdev->dev, "invalid device id: %u\n", devid); > > + return ERR_PTR(-EINVAL); > > + } > > + > > + if (cpuid > MAX_DMA_CPU_ID) { > > + dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid); > > + return ERR_PTR(-EINVAL); > > + } > > + > > + dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0); > > + if (!dma_spec->np) { > > + dev_err(&pdev->dev, "can't get dma master\n"); > > + return ERR_PTR(-EINVAL); > > + } > > + > > + map = kzalloc(sizeof(*map), GFP_KERNEL); > > + if (!map) > > + return ERR_PTR(-ENOMEM); > > + > > + map->channel = chid; > > + map->peripheral = devid; > > + map->cpu = cpuid; > > + > > + regoff = chid % DMAMUX_NR_CH_PER_REGISTER; > > + regpos = chid / DMAMUX_NR_CH_PER_REGISTER; > > + > > + spin_lock_irqsave(&dmamux->lock, flags); > > + > > + if (test_and_set_bit(devid, dmamux->mapped_peripherals)) { > > + dev_err(&pdev->dev, "already used device mapping: %u\n", devid); > > + goto failed; > > + } > > + > > + if (test_and_set_bit(chid, dmamux->used_chans)) { > > + clear_bit(devid, dmamux->mapped_peripherals); > > + dev_err(&pdev->dev, "already used channel id: %u\n", chid); > > + goto failed; > > + } > > + > > + regmap_set_bits(dmamux->regmap, > > + regpos + CV1800_SDMA_DMA_CHANNEL_REMAP0, > > + DMAMUX_CH_SET(regoff, devid)); > > + > > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX, > > + DMAMUX_INT_CH_MASK(chid, cpuid), > > + DMAMUX_INT_CH_BIT(chid, cpuid)); > > + > > + spin_unlock_irqrestore(&dmamux->lock, flags); > > + > > + dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n", > > + chid, devid, cpuid); > > + > > + return map; > > + > > +failed: > > + spin_unlock_irqrestore(&dmamux->lock, flags); > > + dev_err(&pdev->dev, "already used channel id: %u\n", chid); > > This error is already logged above. > > > + return ERR_PTR(-EBUSY); > > +} > > + > > +static int cv1800_dmamux_probe(struct platform_device *pdev) > > +{ > > + struct device *dev = &pdev->dev; > > + struct device_node *mux_node = dev->of_node; > > + struct cv1800_dmamux_data *data; > > + struct device *parent = dev->parent; > > + struct device_node *dma_master; > > + struct regmap *map = NULL; > > + > > + if (!parent) > > + return -ENODEV; > > + > > + map = device_node_to_regmap(parent->of_node); > > + if (IS_ERR(map)) > > + return PTR_ERR(map); > > + > > + dma_master = of_parse_phandle(mux_node, "dma-masters", 0); > > + if (!dma_master) { > > + dev_err(dev, "invalid dma-requests property\n"); > > This error message doesn't match the property the code looks at. > > > + return -ENODEV; > > + } > > + of_node_put(dma_master); > > + > > + data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL); > > + if (!data) > > + return -ENOMEM; > > + > > + spin_lock_init(&data->lock); > > + data->regmap = map; > > + data->dmarouter.dev = dev; > > + data->dmarouter.route_free = cv1800_dmamux_free; > > + > > + platform_set_drvdata(pdev, data); > > + > > + return of_dma_router_register(mux_node, > > + cv1800_dmamux_route_allocate, > > + &data->dmarouter); > > +} > > + > > +static const struct of_device_id cv1800_dmamux_ids[] = { > > + { .compatible = "sophgo,cv1800-dmamux", }, > > + { } > > +}; > > +MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids); > > + > > +static struct platform_driver cv1800_dmamux_driver = { > > + .driver = { > > + .name = "fsl-raideng", > > copy-paste error? Thanks for point it out. > > > + .of_match_table = cv1800_dmamux_ids, > > + }, > > + .probe = cv1800_dmamux_probe, > > +}; > > +module_platform_driver(cv1800_dmamux_driver); > > This driver can be built as an unloadable module, so it needs a .remove_new > function calling at least of_dma_controller_free(). > Thanks. > Regards, > Samuel > > > + > > +MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>"); > > +MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver"); > > +MODULE_LICENSE("GPL"); > > -- > > 2.44.0 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv >
This patch adds STM32 PWR regulators DT support on stm32mp131. This requires TFA to clear RCC_SECCFGR, is disabled by default and can only be enabled on board DT level. Signed-off-by: Marek Vasut <marex@denx.de> --- Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Conor Dooley <conor+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org Cc: kernel@dh-electronics.com Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com --- arch/arm/boot/dts/st/stm32mp131.dtsi | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi index 3900f32da797b..58b8ae759998d 100644 --- a/arch/arm/boot/dts/st/stm32mp131.dtsi +++ b/arch/arm/boot/dts/st/stm32mp131.dtsi @@ -1092,6 +1092,30 @@ rcc: rcc@50000000 { <&scmi_clk CK_SCMI_LSI>; }; + pwr_regulators: pwr@50001000 { + compatible = "st,stm32mp1,pwr-reg"; + reg = <0x50001000 0x10>; + status = "disabled"; + + reg11: reg11 { + regulator-name = "reg11"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + }; + + reg18: reg18 { + regulator-name = "reg18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + usb33: usb33 { + regulator-name = "usb33"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + }; + exti: interrupt-controller@5000d000 { compatible = "st,stm32mp13-exti", "syscon"; interrupt-controller; -- 2.43.0
On Mon, Mar 18, 2024 at 10:22:47PM -0500, Samuel Holland wrote: > On 2024-03-18 1:38 AM, Inochi Amaoto wrote: > > The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with > > an additional channel remap register located in the top system control > > area. The DMA channel is exclusive to each core. > > > > Add the dmamux binding for CV18XX/SG200X series SoC > > > > Signed-off-by: Inochi Amaoto <inochiama@outlook.com> > > Reviewed-by: Rob Herring <robh@kernel.org> > > --- > > .../bindings/dma/sophgo,cv1800-dmamux.yaml | 47 ++++++++++++++++ > > include/dt-bindings/dma/cv1800-dma.h | 55 +++++++++++++++++++ > > 2 files changed, 102 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > > create mode 100644 include/dt-bindings/dma/cv1800-dma.h > > > > diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > > new file mode 100644 > > index 000000000000..c813c66737ba > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > > @@ -0,0 +1,47 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Sophgo CV1800/SG200 Series DMA mux > > + > > +maintainers: > > + - Inochi Amaoto <inochiama@outlook.com> > > + > > +allOf: > > + - $ref: dma-router.yaml# > > + > > +properties: > > + compatible: > > + const: sophgo,cv1800-dmamux > > + > > + reg: > > + maxItems: 2 > > + > > + '#dma-cells': > > + const: 3 > > + description: > > + The first cells is DMA channel. The second one is device id. > > + The third one is the cpu id. > > There are 43 devices, but only 8 channels. Since the channel is statically > specified in the devicetree as the first cell here, that means the SoC DT author > must pre-select which 8 of the 43 devices are usable, right? Yes, you are right. > And then the rest > would have to omit their dma properties. Wouldn't it be better to leave out the > channel number here and dynamically allocate channels at runtime? > You mean defining all the dma channel in the device and allocation channel selectively? This is workable, but it still needs a hint to allocate channel. Also, according to the information from sophgo, it does not support dynamic channel allocation, so all channel can only be initialize once. There is another problem, since we defined all the dmas property in the device, How to mask the devices if we do not want to use dma on them? I have see SPI device will disable DMA when allocation failed, I guess this is this mechanism is the same for all devices? Regards, Inochi > Regards, > Samuel > > > + > > + dma-masters: > > + maxItems: 1 > > + > > + dma-requests: > > + const: 8 > > + > > +required: > > + - '#dma-cells' > > + - dma-masters > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + dma-router { > > + compatible = "sophgo,cv1800-dmamux"; > > + #dma-cells = <3>; > > + dma-masters = <&dmac>; > > + dma-requests = <8>; > > + }; > > diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h > > new file mode 100644 > > index 000000000000..3ce9dac25259 > > --- /dev/null > > +++ b/include/dt-bindings/dma/cv1800-dma.h > > @@ -0,0 +1,55 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ > > + > > +#ifndef __DT_BINDINGS_DMA_CV1800_H__ > > +#define __DT_BINDINGS_DMA_CV1800_H__ > > + > > +#define DMA_I2S0_RX 0 > > +#define DMA_I2S0_TX 1 > > +#define DMA_I2S1_RX 2 > > +#define DMA_I2S1_TX 3 > > +#define DMA_I2S2_RX 4 > > +#define DMA_I2S2_TX 5 > > +#define DMA_I2S3_RX 6 > > +#define DMA_I2S3_TX 7 > > +#define DMA_UART0_RX 8 > > +#define DMA_UART0_TX 9 > > +#define DMA_UART1_RX 10 > > +#define DMA_UART1_TX 11 > > +#define DMA_UART2_RX 12 > > +#define DMA_UART2_TX 13 > > +#define DMA_UART3_RX 14 > > +#define DMA_UART3_TX 15 > > +#define DMA_SPI0_RX 16 > > +#define DMA_SPI0_TX 17 > > +#define DMA_SPI1_RX 18 > > +#define DMA_SPI1_TX 19 > > +#define DMA_SPI2_RX 20 > > +#define DMA_SPI2_TX 21 > > +#define DMA_SPI3_RX 22 > > +#define DMA_SPI3_TX 23 > > +#define DMA_I2C0_RX 24 > > +#define DMA_I2C0_TX 25 > > +#define DMA_I2C1_RX 26 > > +#define DMA_I2C1_TX 27 > > +#define DMA_I2C2_RX 28 > > +#define DMA_I2C2_TX 29 > > +#define DMA_I2C3_RX 30 > > +#define DMA_I2C3_TX 31 > > +#define DMA_I2C4_RX 32 > > +#define DMA_I2C4_TX 33 > > +#define DMA_TDM0_RX 34 > > +#define DMA_TDM0_TX 35 > > +#define DMA_TDM1_RX 36 > > +#define DMA_AUDSRC 37 > > +#define DMA_SPI_NAND 38 > > +#define DMA_SPI_NOR 39 > > +#define DMA_UART4_RX 40 > > +#define DMA_UART4_TX 41 > > +#define DMA_SPI_NOR1 42 > > + > > +#define DMA_CPU_A53 0 > > +#define DMA_CPU_C906_0 1 > > +#define DMA_CPU_C906_1 2 > > + > > + > > +#endif // __DT_BINDINGS_DMA_CV1800_H__ > > -- > > 2.44.0 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv >
On 3/14/2024 2:20 PM, Krzysztof Kozlowski wrote:
> On 14/03/2024 21:04, Anjelique Melendez wrote:
>> Update the Qualcomm Technologies, Inc. PMIC GPIO binding documentation
>> to include compatible strings for PMIH010x and PMD802x PMICs.
>>
>> Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
>> ---
>> .../bindings/pinctrl/qcom,pmic-gpio.yaml | 20 +++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>> index 2b17d244f051..5cc04c016b25 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
>> @@ -57,10 +57,12 @@ properties:
>> - qcom,pma8084-gpio
>> - qcom,pmc8180-gpio
>> - qcom,pmc8180c-gpio
>> + - qcom,pmd802x-gpio
>
> Is the "x" some sort of wildcard or actual PMIC model/version name?
> Wildcards are in general discouraged.
>
"x" is being used as a wildcard here so can update with actual PMIC version
in next version.
Thanks,
Anjelique
On 2024-03-18 1:38 AM, Inochi Amaoto wrote: > Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping > its request lines. The multiplexer supports at most 8 request lines. > > Add driver for Sophgo CV18XX/SG200X DMA multiplexer. > > Signed-off-by: Inochi Amaoto <inochiama@outlook.com> > --- > drivers/dma/Kconfig | 9 ++ > drivers/dma/Makefile | 1 + > drivers/dma/cv1800-dmamux.c | 232 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 242 insertions(+) > create mode 100644 drivers/dma/cv1800-dmamux.c > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 002a5ec80620..cb31520b9f86 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -546,6 +546,15 @@ config PLX_DMA > These are exposed via extra functions on the switch's > upstream port. Each function exposes one DMA channel. > > +config SOPHGO_CV1800_DMAMUX > + tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support" > + depends on MFD_SYSCON > + depends on ARCH_SOPHGO > + help > + Support for the DMA multiplexer on Sophgo CV1800/SG2000 > + series SoCs. > + Say Y here if your board have this soc. > + > config STE_DMA40 > bool "ST-Ericsson DMA40 support" > depends on ARCH_U8500 > diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile > index dfd40d14e408..7465f249ee47 100644 > --- a/drivers/dma/Makefile > +++ b/drivers/dma/Makefile > @@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/ > obj-$(CONFIG_PXA_DMA) += pxa_dma.o > obj-$(CONFIG_RENESAS_DMA) += sh/ > obj-$(CONFIG_SF_PDMA) += sf-pdma/ > +obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o > obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o > obj-$(CONFIG_STM32_DMA) += stm32-dma.o > obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o > diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c > new file mode 100644 > index 000000000000..b41c39f2e338 > --- /dev/null > +++ b/drivers/dma/cv1800-dmamux.c > @@ -0,0 +1,232 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com> > + */ > + > +#include <linux/bitops.h> > +#include <linux/module.h> > +#include <linux/of_dma.h> > +#include <linux/of_address.h> > +#include <linux/of_platform.h> > +#include <linux/platform_device.h> > +#include <linux/regmap.h> > +#include <linux/spinlock.h> > +#include <linux/mfd/syscon.h> > + > +#include <soc/sophgo/cv1800-sysctl.h> > +#include <dt-bindings/dma/cv1800-dma.h> > + > +#define DMAMUX_NCELLS 3 > +#define MAX_DMA_MAPPING_ID DMA_SPI_NOR1 > +#define MAX_DMA_CPU_ID DMA_CPU_C906_1 > +#define MAX_DMA_CH_ID 7 > + > +#define DMAMUX_INTMUX_REGISTER_LEN 4 > +#define DMAMUX_NR_CH_PER_REGISTER 4 > +#define DMAMUX_BIT_PER_CH 8 > +#define DMAMUX_CH_MASk GENMASK(5, 0) > +#define DMAMUX_INT_BIT_PER_CPU 10 > +#define DMAMUX_CH_UPDATE_BIT BIT(31) > + > +#define DMAMUX_CH_SET(chid, val) \ > + (((val) << ((chid) * DMAMUX_BIT_PER_CH)) | DMAMUX_CH_UPDATE_BIT) > +#define DMAMUX_CH_MASK(chid) \ > + DMAMUX_CH_SET(chid, DMAMUX_CH_MASk) > + > +#define DMAMUX_INT_BIT(chid, cpuid) \ > + BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid)) > +#define DMAMUX_INTEN_BIT(cpuid) \ > + DMAMUX_INT_BIT(8, cpuid) > +#define DMAMUX_INT_CH_BIT(chid, cpuid) \ > + (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid)) > +#define DMAMUX_INT_MASK(chid) \ > + (DMAMUX_INT_BIT(chid, DMA_CPU_A53) | \ > + DMAMUX_INT_BIT(chid, DMA_CPU_C906_0) | \ > + DMAMUX_INT_BIT(chid, DMA_CPU_C906_1)) > +#define DMAMUX_INT_CH_MASK(chid, cpuid) \ > + (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid)) > + > +struct cv1800_dmamux_data { > + struct dma_router dmarouter; > + struct regmap *regmap; > + spinlock_t lock; > + DECLARE_BITMAP(used_chans, MAX_DMA_CH_ID); > + DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID); > +}; > + > +struct cv1800_dmamux_map { > + unsigned int channel; > + unsigned int peripheral; > + unsigned int cpu; > +}; > + > +static void cv1800_dmamux_free(struct device *dev, void *route_data) > +{ > + struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev); > + struct cv1800_dmamux_map *map = route_data; > + u32 regoff = map->channel % DMAMUX_NR_CH_PER_REGISTER; > + u32 regpos = map->channel / DMAMUX_NR_CH_PER_REGISTER; > + unsigned long flags; > + > + spin_lock_irqsave(&dmamux->lock, flags); > + > + regmap_update_bits(dmamux->regmap, > + regpos + CV1800_SDMA_DMA_CHANNEL_REMAP0, > + DMAMUX_CH_MASK(regoff), > + DMAMUX_CH_UPDATE_BIT); > + > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX, > + DMAMUX_INT_CH_MASK(map->channel, map->cpu), > + DMAMUX_INTEN_BIT(map->cpu)); > + > + clear_bit(map->channel, dmamux->used_chans); > + clear_bit(map->peripheral, dmamux->mapped_peripherals); > + > + spin_unlock_irqrestore(&dmamux->lock, flags); > + > + kfree(map); > +} > + > +static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec, > + struct of_dma *ofdma) > +{ > + struct platform_device *pdev = of_find_device_by_node(ofdma->of_node); > + struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev); > + struct cv1800_dmamux_map *map; > + unsigned long flags; > + unsigned int chid, devid, cpuid; > + u32 regoff, regpos; > + > + if (dma_spec->args_count != DMAMUX_NCELLS) { > + dev_err(&pdev->dev, "invalid number of dma mux args\n"); > + return ERR_PTR(-EINVAL); > + } > + > + chid = dma_spec->args[0]; > + devid = dma_spec->args[1]; > + cpuid = dma_spec->args[2]; > + dma_spec->args_count -= 2; > + > + if (chid > MAX_DMA_CH_ID) { > + dev_err(&pdev->dev, "invalid channel id: %u\n", chid); > + return ERR_PTR(-EINVAL); > + } > + > + if (devid > MAX_DMA_MAPPING_ID) { > + dev_err(&pdev->dev, "invalid device id: %u\n", devid); > + return ERR_PTR(-EINVAL); > + } > + > + if (cpuid > MAX_DMA_CPU_ID) { > + dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid); > + return ERR_PTR(-EINVAL); > + } > + > + dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0); > + if (!dma_spec->np) { > + dev_err(&pdev->dev, "can't get dma master\n"); > + return ERR_PTR(-EINVAL); > + } > + > + map = kzalloc(sizeof(*map), GFP_KERNEL); > + if (!map) > + return ERR_PTR(-ENOMEM); > + > + map->channel = chid; > + map->peripheral = devid; > + map->cpu = cpuid; > + > + regoff = chid % DMAMUX_NR_CH_PER_REGISTER; > + regpos = chid / DMAMUX_NR_CH_PER_REGISTER; > + > + spin_lock_irqsave(&dmamux->lock, flags); > + > + if (test_and_set_bit(devid, dmamux->mapped_peripherals)) { > + dev_err(&pdev->dev, "already used device mapping: %u\n", devid); > + goto failed; > + } > + > + if (test_and_set_bit(chid, dmamux->used_chans)) { > + clear_bit(devid, dmamux->mapped_peripherals); > + dev_err(&pdev->dev, "already used channel id: %u\n", chid); > + goto failed; > + } > + > + regmap_set_bits(dmamux->regmap, > + regpos + CV1800_SDMA_DMA_CHANNEL_REMAP0, > + DMAMUX_CH_SET(regoff, devid)); > + > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX, > + DMAMUX_INT_CH_MASK(chid, cpuid), > + DMAMUX_INT_CH_BIT(chid, cpuid)); > + > + spin_unlock_irqrestore(&dmamux->lock, flags); > + > + dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n", > + chid, devid, cpuid); > + > + return map; > + > +failed: > + spin_unlock_irqrestore(&dmamux->lock, flags); > + dev_err(&pdev->dev, "already used channel id: %u\n", chid); This error is already logged above. > + return ERR_PTR(-EBUSY); > +} > + > +static int cv1800_dmamux_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct device_node *mux_node = dev->of_node; > + struct cv1800_dmamux_data *data; > + struct device *parent = dev->parent; > + struct device_node *dma_master; > + struct regmap *map = NULL; > + > + if (!parent) > + return -ENODEV; > + > + map = device_node_to_regmap(parent->of_node); > + if (IS_ERR(map)) > + return PTR_ERR(map); > + > + dma_master = of_parse_phandle(mux_node, "dma-masters", 0); > + if (!dma_master) { > + dev_err(dev, "invalid dma-requests property\n"); This error message doesn't match the property the code looks at. > + return -ENODEV; > + } > + of_node_put(dma_master); > + > + data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; > + > + spin_lock_init(&data->lock); > + data->regmap = map; > + data->dmarouter.dev = dev; > + data->dmarouter.route_free = cv1800_dmamux_free; > + > + platform_set_drvdata(pdev, data); > + > + return of_dma_router_register(mux_node, > + cv1800_dmamux_route_allocate, > + &data->dmarouter); > +} > + > +static const struct of_device_id cv1800_dmamux_ids[] = { > + { .compatible = "sophgo,cv1800-dmamux", }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids); > + > +static struct platform_driver cv1800_dmamux_driver = { > + .driver = { > + .name = "fsl-raideng", copy-paste error? > + .of_match_table = cv1800_dmamux_ids, > + }, > + .probe = cv1800_dmamux_probe, > +}; > +module_platform_driver(cv1800_dmamux_driver); This driver can be built as an unloadable module, so it needs a .remove_new function calling at least of_dma_controller_free(). Regards, Samuel > + > +MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>"); > +MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver"); > +MODULE_LICENSE("GPL"); > -- > 2.44.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Add three missing cDSP fastrpc compute-cb nodes for the SM8650 SoC. Signed-off-by: Ling Xu <quic_lxu5@quicinc.com> --- * v1->v2: Lowercase hex v1: https://lore.kernel.org/linux-arm-msm/20240314063334.31942-1-quic_lxu5@quicinc.com/ --- --- arch/arm64/boot/dts/qcom/sm8650.dtsi | 32 ++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi index ba72d8f38420..57158e4606b1 100644 --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi @@ -5084,6 +5084,38 @@ <&apps_smmu 0x19c8 0x0>; dma-coherent; }; + + /* note: secure cb9 in downstream */ + + compute-cb@10 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <12>; + + iommus = <&apps_smmu 0x196c 0x0>, + <&apps_smmu 0x0c0c 0x20>, + <&apps_smmu 0x19cc 0x0>; + dma-coherent; + }; + + compute-cb@11 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <13>; + + iommus = <&apps_smmu 0x196d 0x0>, + <&apps_smmu 0x0c0d 0x20>, + <&apps_smmu 0x19cd 0x0>; + dma-coherent; + }; + + compute-cb@12 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <14>; + + iommus = <&apps_smmu 0x196e 0x0>, + <&apps_smmu 0x0c0e 0x20>, + <&apps_smmu 0x19ce 0x0>; + dma-coherent; + }; }; }; }; -- 2.17.1
On 2024-03-18 1:38 AM, Inochi Amaoto wrote: > The DMA IP of Sophgo CV18XX/SG200X is based on a DW AXI CORE, with > an additional channel remap register located in the top system control > area. The DMA channel is exclusive to each core. > > Add the dmamux binding for CV18XX/SG200X series SoC > > Signed-off-by: Inochi Amaoto <inochiama@outlook.com> > Reviewed-by: Rob Herring <robh@kernel.org> > --- > .../bindings/dma/sophgo,cv1800-dmamux.yaml | 47 ++++++++++++++++ > include/dt-bindings/dma/cv1800-dma.h | 55 +++++++++++++++++++ > 2 files changed, 102 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > create mode 100644 include/dt-bindings/dma/cv1800-dma.h > > diff --git a/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > new file mode 100644 > index 000000000000..c813c66737ba > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/sophgo,cv1800-dmamux.yaml > @@ -0,0 +1,47 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/dma/sophgo,cv1800-dmamux.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Sophgo CV1800/SG200 Series DMA mux > + > +maintainers: > + - Inochi Amaoto <inochiama@outlook.com> > + > +allOf: > + - $ref: dma-router.yaml# > + > +properties: > + compatible: > + const: sophgo,cv1800-dmamux > + > + reg: > + maxItems: 2 > + > + '#dma-cells': > + const: 3 > + description: > + The first cells is DMA channel. The second one is device id. > + The third one is the cpu id. There are 43 devices, but only 8 channels. Since the channel is statically specified in the devicetree as the first cell here, that means the SoC DT author must pre-select which 8 of the 43 devices are usable, right? And then the rest would have to omit their dma properties. Wouldn't it be better to leave out the channel number here and dynamically allocate channels at runtime? Regards, Samuel > + > + dma-masters: > + maxItems: 1 > + > + dma-requests: > + const: 8 > + > +required: > + - '#dma-cells' > + - dma-masters > + > +additionalProperties: false > + > +examples: > + - | > + dma-router { > + compatible = "sophgo,cv1800-dmamux"; > + #dma-cells = <3>; > + dma-masters = <&dmac>; > + dma-requests = <8>; > + }; > diff --git a/include/dt-bindings/dma/cv1800-dma.h b/include/dt-bindings/dma/cv1800-dma.h > new file mode 100644 > index 000000000000..3ce9dac25259 > --- /dev/null > +++ b/include/dt-bindings/dma/cv1800-dma.h > @@ -0,0 +1,55 @@ > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ > + > +#ifndef __DT_BINDINGS_DMA_CV1800_H__ > +#define __DT_BINDINGS_DMA_CV1800_H__ > + > +#define DMA_I2S0_RX 0 > +#define DMA_I2S0_TX 1 > +#define DMA_I2S1_RX 2 > +#define DMA_I2S1_TX 3 > +#define DMA_I2S2_RX 4 > +#define DMA_I2S2_TX 5 > +#define DMA_I2S3_RX 6 > +#define DMA_I2S3_TX 7 > +#define DMA_UART0_RX 8 > +#define DMA_UART0_TX 9 > +#define DMA_UART1_RX 10 > +#define DMA_UART1_TX 11 > +#define DMA_UART2_RX 12 > +#define DMA_UART2_TX 13 > +#define DMA_UART3_RX 14 > +#define DMA_UART3_TX 15 > +#define DMA_SPI0_RX 16 > +#define DMA_SPI0_TX 17 > +#define DMA_SPI1_RX 18 > +#define DMA_SPI1_TX 19 > +#define DMA_SPI2_RX 20 > +#define DMA_SPI2_TX 21 > +#define DMA_SPI3_RX 22 > +#define DMA_SPI3_TX 23 > +#define DMA_I2C0_RX 24 > +#define DMA_I2C0_TX 25 > +#define DMA_I2C1_RX 26 > +#define DMA_I2C1_TX 27 > +#define DMA_I2C2_RX 28 > +#define DMA_I2C2_TX 29 > +#define DMA_I2C3_RX 30 > +#define DMA_I2C3_TX 31 > +#define DMA_I2C4_RX 32 > +#define DMA_I2C4_TX 33 > +#define DMA_TDM0_RX 34 > +#define DMA_TDM0_TX 35 > +#define DMA_TDM1_RX 36 > +#define DMA_AUDSRC 37 > +#define DMA_SPI_NAND 38 > +#define DMA_SPI_NOR 39 > +#define DMA_UART4_RX 40 > +#define DMA_UART4_TX 41 > +#define DMA_SPI_NOR1 42 > + > +#define DMA_CPU_A53 0 > +#define DMA_CPU_C906_0 1 > +#define DMA_CPU_C906_1 2 > + > + > +#endif // __DT_BINDINGS_DMA_CV1800_H__ > -- > 2.44.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
> -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: 2024年3月19日 2:51 > To: Joy Zou <joy.zou@nxp.com>; Frank Li <frank.li@nxp.com>; Jacky Bai > <ping.bai@nxp.com>; lgirdwood@gmail.com; broonie@kernel.org; > robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; > conor+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de > Cc: kernel@pengutronix.de; festevam@gmail.com; dl-linux-imx > <linux-imx@nxp.com>; devicetree@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; > imx@lists.linux.dev > Subject: [EXT] Re: [PATCH v5 3/3] arm64: dts: imx93-11x11-evk: add > pca9451a support > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report > this email' button > > > On 18/03/2024 10:56, Joy Zou wrote: > > Support pca9451a on imx93-11x11-evk. > > > > Signed-off-by: Joy Zou <joy.zou@nxp.com> > > --- > > Changes in v5: > > 1.adjust gpio@22 to the front of pmic@25. > > > > Changes in v4: > > 1. modify the comment for uSDHC but not i2c. > > > > Changes in v3: > > 1. modify the voltages constraints according to the imx93 datasheet. > > --- > > .../boot/dts/freescale/imx93-11x11-evk.dts | 111 > ++++++++++++++++++ > > 1 file changed, 111 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts > b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts > > index 9921ea13ab48..478a134d4416 100644 > > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts > > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts > > @@ -183,6 +183,104 @@ &wdog3 { > > status = "okay"; > > }; > > > > +&lpi2c2 { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + clock-frequency = <400000>; > > + pinctrl-names = "default", "sleep"; > > + pinctrl-0 = <&pinctrl_lpi2c2>; > > + pinctrl-1 = <&pinctrl_lpi2c2>; > > + status = "okay"; > > + > > + pcal6524: gpio@22 { > > + compatible = "nxp,pcal6524"; > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pinctrl_pcal6524>; > > + reg = <0x22>; > > reg is the second property. Please do not introduce some other coding style. Yes, will change the reg to the second property. Thanks for your comments! BR Joy Zou > > Best regards, > Krzysztof
On Sun, 17 Mar 2024 18:59:18 +0530, Rajendra Nayak wrote:
> The compatible's for the cluster/domain idle states of x1e80100
> are wrong, fix it.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: x1e80100: Fix the compatible for cluster idle states
commit: d6feddef4b82b3245a32089f6e6618bee1ae6cd9
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On Thu, 15 Feb 2024 16:09:27 +0530, Ritesh Kumar wrote:
> Build the Novatek NT36672E DSI Panel driver as module and enable
> display subsystem on Qualcomm qcm6490 idp board.
>
Applied, thanks!
[1/2] arm64: defconfig: enable Novatek NT36672E DSI Panel driver
commit: 55ca24e5f9f432e27499ce5baa85f233931901c1
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
On Mon, 19 Feb 2024 13:27:20 +0530, Krishna Kurapati wrote:
> Recent binding update [1] indicates that there are hs_phy_irq
> present in primary and secondary usb controllers of sc8280xp.
>
> Add the missing hs_phy_irq for these controllers. Since the driver
> doesn't use this interrupt, this change has been only compile
> tested.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sc8280xp: Add missing hs_phy_irq in USB nodes
commit: 343dfe6206b2793f7f5196b849dfbb4efcc5c048
Best regards,
--
Bjorn Andersson <andersson@kernel.org>