* Re: [PATCH v4] dt-bindings: display: atmel,lcdc: convert to dtschema
From: Rob Herring @ 2024-03-25 14:39 UTC (permalink / raw)
To: Dharma Balasubiramani
Cc: Conor Dooley, devicetree, Alexandre Belloni, Daniel Vetter,
Thomas Zimmermann, Maarten Lankhorst, linux-kernel, Maxime Ripard,
Rob Herring, dri-devel, Krzysztof Kozlowski, Claudiu Beznea,
David Airlie, linux-arm-kernel
In-Reply-To: <20240318-lcdc-fb-v4-1-c533c7c2c706@microchip.com>
On Mon, 18 Mar 2024 11:10:13 +0530, Dharma Balasubiramani wrote:
> Convert the atmel,lcdc bindings to DT schema.
> Changes during conversion: add missing clocks and clock-names properties.
>
> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
> ---
> This patch converts the existing lcdc display text binding to JSON schema.
> The binding is split into two namely
> lcdc.yaml
> - Holds the frame buffer properties
> lcdc-display.yaml
> - Holds the display panel properties which is a phandle to the display
> property in lcdc fb node.
>
> These bindings are tested using the following command.
> 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> ---
> Changes in v4:
> - Add maximum for atmel,guard-time property.
> - Add constraints for bits-per-pixel property.
> - Update the atmel,lcd-wiring-mode property's ref to point single string
> rather than an array.
> - Add constraints for atmel,lcd-wiring-mode property.
> - Add maxItems to the atmel,power-control-gpio property.
> - Link to v3: https://lore.kernel.org/r/20240304-lcdc-fb-v3-1-8b616fbb0199@microchip.com
>
> Changes in v3:
> - Remove the generic property "bits-per-pixel"
> - Link to v2: https://lore.kernel.org/r/20240304-lcdc-fb-v2-1-a14b463c157a@microchip.com
>
> Changes in v2:
> - Run checkpatch and remove whitespace errors.
> - Add the standard interrupt flags.
> - Split the binding into two, namely lcdc.yaml and lcdc-display.yaml.
> - Link to v1: https://lore.kernel.org/r/20240223-lcdc-fb-v1-1-4c64cb6277df@microchip.com
> ---
> .../bindings/display/atmel,lcdc-display.yaml | 103 +++++++++++++++++++++
> .../devicetree/bindings/display/atmel,lcdc.txt | 87 -----------------
> .../devicetree/bindings/display/atmel,lcdc.yaml | 70 ++++++++++++++
> 3 files changed, 173 insertions(+), 87 deletions(-)
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
From: Jonathan Cameron @ 2024-03-25 14:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrej Picej, haibo.chen, linux-iio, devicetree, jic23, lars,
shawnguo, s.hauer, kernel, festevam, imx, linux-arm-kernel,
linux-kernel, robh, krzysztof.kozlowski+dt, conor+dt, upstream
In-Reply-To: <178594a2-cd5f-4608-aae6-7d68fd0817e0@linaro.org>
On Mon, 25 Mar 2024 10:58:51 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 22/03/2024 10:58, Andrej Picej wrote:
> > On 22. 03. 24 09:14, Krzysztof Kozlowski wrote:
> >> On 22/03/2024 08:39, Andrej Picej wrote:
> >>> On 20. 03. 24 13:15, Krzysztof Kozlowski wrote:
> >>>> On 20/03/2024 13:05, Andrej Picej wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On 20. 03. 24 11:26, Krzysztof Kozlowski wrote:
> >>>>>> On 20/03/2024 11:04, Andrej Picej wrote:
> >>>>>>> Document calibration properties and how to set them.
> >>>>>>
> >>>>>> Bindings are before users.
> >>>>>
> >>>>> will change patch order when I send a v2.
> >>>>>
> >>>>>>
> >>>>>> Please use subject prefixes matching the subsystem. You can get them for
> >>>>>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> >>>>>> your patch is touching.
> >>>>>> There is no file extension in prefixes.
> >>>>>
> >>>>> So: dt-bindings: iio/adc: nxp,imx93-adc: Add calibration properties?
> >>>>
> >>>> Did you run the command I proposed? I don't see much of "/", but except
> >>>> that looks good.
> >>>
> >>> Ok noted.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> >>>>>>> ---
> >>>>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++++++++++++
> >>>>>>> 1 file changed, 15 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> index dacc526dc695..64958be62a6a 100644
> >>>>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
> >>>>>>> @@ -46,6 +46,21 @@ properties:
> >>>>>>> "#io-channel-cells":
> >>>>>>> const: 1
> >>>>>>>
> >>>>>>> + nxp,calib-avg-en:
> >>>>>>> + description:
> >>>>>>> + Enable or disable averaging of calibration time.
> >>>>>>> + enum: [ 0, 1 ]
> >>>>>>> +
> >>>>>>> + nxp,calib-nr-samples:
> >>>>>>> + description:
> >>>>>>> + Selects the number of averaging samples to be used during calibration.
> >>>>>>> + enum: [ 16, 32, 128, 512 ]
> >>>>>>> +
> >>>>>>> + nxp,calib-t-samples:
> >>>>>>> + description:
> >>>>>>> + Specifies the sample time of calibration conversions.
> >>>>>>> + enum: [ 8, 16, 22, 32 ]
> >>>>>>
> >>>>>> No, use existing, generic properties. Open other bindings for this.
> >>>>>
> >>>>> You mean I should use generic properties for the ADC calibration
> >>>>> settings? Is there already something in place? Because as I understand
> >>>>> it, these calib-* values only effect the calibration process of the ADC.
> >>>>
> >>>> Please take a look at other devices and dtschema. We already have some
> >>>> properties for this... but maybe they cannot be used?
> >>>>
> >>>
> >>> I did look into other ADC devices, grep across iio/adc, adc bindings
> >>> folders and couldn't find anything closely related to what we are
> >>> looking for. Could you please point me to the properties that you think
> >>> should be used for this?
> >>
> >> Indeed, there are few device specific like qcom,avg-samples. We have
> >> though oversampling-ratio, settling-time-us and min-sample-time (which
> >> is not that good because does not use unit suffix).
> >
> > Ok, these are examples but I think I should not use them, since these
> > are i.MX93 ADC specific settings, which are used for configuration of
>
>
> No vendor prefix, so they rather should be generic, not imx93
> specific... But this the binding for imx93, so I don't understand your
> statement.
Based on my current understanding what we have here is not remotely
generic, so standard properties don't make sense (though naming the
nxp ones in a consistent fashion with other bindings is useful)
I'm not entirely convinced there is a strong argument to support them at all
though. Still thinking / gathering info on that.
>
> > calibration process, and are not related to the standard conversion
> > process during runtime. Calibration process is the first step that
> > should be done after every power-on reset.
> >
> >>
> >> Then follow up questions:
> >> - nxp,calib-avg-en: Why is it a board-level decision? I would assume
> >> this depends on user choice and what kind of input you have (which could
> >> be board dependent or could be runtime decision).
> >
> > Not really sure I get your question, so please elaborate if I missed the
> > point.
> > This is a user choice, to enable or disable the averaging function in
> > calibration, but this is a board-level decision, probably relates on
> > external ADC regulators and input connections. The same options are used
> > for every ADC channel and this can not be a runtime decision, since
> > calibration is done before the ADC is even registered.
>
> You now mix how Linux driver behaves with hardware. Why you cannot
> recalibrate later, e.g. when something else is being connected to the
> exposed pins?
Generally we don't make strong efforts to support dev board use cases where
the components wired tend to change. So normally this isn't too much of
a concern. Previously, we've tried to support this stuff and it always
ends up as a mess because of the crazy range of things that can be wired.
Jonathan
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Kalle Valo @ 2024-03-25 14:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski,
ath11k, Johan Hovold
In-Reply-To: <CAMRc=Mc2Tc8oHr5NVo=aHAADkJtGCDAVvJs+7V-19m2zGi-vbw@mail.gmail.com>
Bartosz Golaszewski <brgl@bgdev.pl> writes:
> On Mon, Mar 25, 2024 at 2:57 PM Kalle Valo <kvalo@kernel.org> wrote:
>
>>
>> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>>
>> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>> >
>> > Add a PCI compatible for the ATH11K module on QCA6390 and describe the
>> > power inputs from the PMU that it consumes.
>> >
>> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>>
>> [...]
>>
>> > +allOf:
>> > + - if:
>> > + properties:
>> > + compatible:
>> > + contains:
>> > + const: pci17cb,1101
>> > + then:
>> > + required:
>> > + - vddrfacmn-supply
>> > + - vddaon-supply
>> > + - vddwlcx-supply
>> > + - vddwlmx-supply
>> > + - vddrfa0p8-supply
>> > + - vddrfa1p2-supply
>> > + - vddrfa1p7-supply
>> > + - vddpcie0p9-supply
>> > + - vddpcie1p8-supply
>>
>> I don't know DT well enough to know what the "required:" above means,
>> but does this take into account that there are normal "plug&play" type
>> of QCA6390 boards as well which don't need any DT settings?
>
> Do they require a DT node though for some reason?
You can attach the device to any PCI slot, connect the WLAN antenna and
it just works without DT nodes. I'm trying to make sure here that basic
setup still works.
Adding also Johan and ath11k list. For example, I don't know what's the
plan with Lenovo X13s, will it use this framework? I guess in theory we
could have devices which use qcom,ath11k-calibration-variant from DT but
not any of these supply properties?
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema
From: Rob Herring @ 2024-03-25 14:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Inki Dae, devicetree, Seung-Woo Kim, linux-samsung-soc,
Conor Dooley, Alim Akhtar, Maxime Ripard, Maarten Lankhorst,
David Airlie, Daniel Vetter, Krzysztof Kozlowski, dri-devel,
linux-arm-kernel, Thomas Zimmermann, Kyungmin Park, linux-kernel
In-Reply-To: <20240313182855.14140-1-krzysztof.kozlowski@linaro.org>
On Wed, 13 Mar 2024 19:28:55 +0100, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to
> DT schema with a change: add power-domains, already used in DTS.
>
> This Display Port controller is actually variant of Analogix Display
> Port bridge, however new DT Schema does not reference analogix,dp.yaml,
> because of incompatibilities in the driver. The analogix,dp.yaml
> expects two ports, input and output, but Linux Exynos DP DRM driver and
> DTS use only one port: output.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. Document deprecated samsung,hpd-gpios
> ---
> .../bindings/display/exynos/exynos_dp.txt | 112 ------------
> .../display/samsung/samsung,exynos5-dp.yaml | 163 ++++++++++++++++++
> 2 files changed, 163 insertions(+), 112 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> create mode 100644 Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml
>
Applied, thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] arm64: dts: ti: k3-am625-beagleplay: Use mmc-pwrseq for wl18xx enable
From: Nishanth Menon @ 2024-03-25 14:35 UTC (permalink / raw)
To: Tero Kristo, Vignesh Raghavendra, Nishanth Menon
Cc: Robert Nelson, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
linux-kernel, devicetree, linux-arm-kernel, Shengyu Qu,
Sukrut Bellary, Javier Martinez Canillas, Bill Mills
From: Sukrut Bellary <sukrut.bellary@linux.com>
BeaglePlay SBC[1] has Texas Instrument's WL18xx WiFi chipset[2].
Currently, WLAN_EN is configured as regulator and regulator-always-on.
However, the timing and wlan_en sequencing is not correctly modelled.
This causes the sdio access to fail during runtime-pm power operations
saving or during system suspend/resume/hibernation/freeze operations.
This is because the WLAN_EN line is not deasserted to low '0' to power
down the WiFi. So during restore, the WiFi driver tries to load the FW
without following correct power sequence. WLAN_EN => '1'/assert (high)
to power-up the chipset.
Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable
'WLAN_EN'. mmc-pwrseq-simple provides power sequence flexibility with
support for post power-on and power-off delays.
Typical log signature that indicates this bug is:
wl1271_sdio mmc2:0001:2: sdio write failed (-110)
Followed by possibly a kernel warning (depending on firmware present):
WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
[1] https://www.beagleboard.org/boards/beagleplay
[2] https://www.ti.com/lit/ds/symlink/wl1807mod.pdf
Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay")
Suggested-by: Shengyu Qu <wiagn233@outlook.com>
Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Picking this patch up since Sukrut was not able to refresh the patch in
the list and it does'nt make much sense to hold off this critical fixup.
Boot log:
https://gist.github.com/nmenon/a34abd03a6aaf84a39ffa569df248285
(includes defconfig change to make iwd work)
Changes Since v1:
* Update the power-on-time to 10ms (same as used in:
arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
)
* Add in-code documentation pointing at timing diagram for the values
used.
* Fixup fail log and commit message and make it generic to indicate
various other usecases of failure.
* Re-test on v6.9-rc1
V1: https://lore.kernel.org/all/20231213213219.566369-1-sukrut.bellary@linux.com/
.../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 27 +++++++++----------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
index a34e0df2ab86..ffc613543968 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts
@@ -82,6 +82,17 @@ wkup_r5fss0_core0_dma_memory_region: r5f-dma-memory@9db00000 {
};
};
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_en_pins_default>;
+ /* Interal power on time(Figure 8-3) * 2 */
+ post-power-on-delay-ms = <10>;
+ /* Re-enable time(Figure 8-2) + 20uS */
+ power-off-delay-us = <80>;
+ reset-gpios = <&main_gpio0 38 GPIO_ACTIVE_LOW>;
+ };
+
vsys_5v0: regulator-1 {
bootph-all;
compatible = "regulator-fixed";
@@ -104,20 +115,6 @@ vdd_3v3: regulator-2 {
regulator-boot-on;
};
- wlan_en: regulator-3 {
- /* OUTPUT of SN74AVC2T244DQMR */
- compatible = "regulator-fixed";
- regulator-name = "wlan_en";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- enable-active-high;
- regulator-always-on;
- vin-supply = <&vdd_3v3>;
- gpio = <&main_gpio0 38 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_en_pins_default>;
- };
-
vdd_3v3_sd: regulator-4 {
/* output of TPS22918DBVR-U21 */
bootph-all;
@@ -839,13 +836,13 @@ &sdhci1 {
};
&sdhci2 {
- vmmc-supply = <&wlan_en>;
pinctrl-names = "default";
pinctrl-0 = <&wifi_pins_default>, <&wifi_32k_clk>;
non-removable;
ti,fails-without-test-cd;
cap-power-off-card;
keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
assigned-clocks = <&k3_clks 157 158>;
assigned-clock-parents = <&k3_clks 157 160>;
#address-cells = <1>;
base-commit: 4cece764965020c22cff7665b18a012006359095
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 00/27] Update SMMUv3 to the modern iommu API (part 2/3)
From: Jason Gunthorpe @ 2024-03-25 14:35 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf7bPOtRg9tLSOKT@google.com>
On Sat, Mar 23, 2024 at 01:38:04PM +0000, Mostafa Saleh wrote:
> Hi Jason,
>
> On Mon, Mar 04, 2024 at 07:43:48PM -0400, Jason Gunthorpe wrote:
> > Continuing the work of part 1 this focuses on the CD, PASID and SVA
> > components:
> >
> > - attach_dev failure does not change the HW configuration.
> >
> > - Full PASID API support including:
> > - S1/SVA domains attached to PASIDs
>
> I am still going through the series, but I see at the end the main SMMUv3
> driver has set_dev_pasid operation, are there any in-tree drivers that
> use that? (and how can I test it).
Not yet, but some will be coming. Currently only Intel driver supports
it, but Intel HW has other problems making it unusable..
A big part of the effort here is to enable the platform ecosystem so
devices and drivers can use it. Moritz has access to a device that
can exercise this, though we are still working on it.
> > - IDENTITY/BLOCKED/S1 attached to RID
> > - Change of the RID domain while PASIDs are attached
> >
> > - Streamlined SVA support using the core infrastructure
> >
> > - Hitless, whenever possible, change between two domains
>
> Can you please clarify what cases are expected to be hitless?
> From what I see if ASID and TTB0 changes that would break the CD.
Right. For CD it is only the SVA mm release flow, setting EPD0.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package
From: Mark Brown @ 2024-03-25 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-3-brgl@bgdev.pl>
[-- Attachment #1.1: Type: text/plain, Size: 434 bytes --]
On Mon, Mar 25, 2024 at 02:16:10PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The WCN7850 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. Extend the bindings for QCA6390 to also
> document this model.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
From: Mark Brown @ 2024-03-25 14:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-2-brgl@bgdev.pl>
[-- Attachment #1.1: Type: text/plain, Size: 407 bytes --]
On Mon, Mar 25, 2024 at 02:16:09PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. This document describes this module.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/5] KVM: arm64: Add accessor for per-CPU state
From: Suzuki K Poulose @ 2024-03-25 14:31 UTC (permalink / raw)
To: Marc Zyngier, kvmarm, linux-arm-kernel, kvm
Cc: James Morse, Oliver Upton, Zenghui Yu, James Clark,
Anshuman Khandual, Mark Brown, Dongli Zhang
In-Reply-To: <20240322170945.3292593-2-maz@kernel.org>
Hi Marc
On 22/03/2024 17:09, Marc Zyngier wrote:
> In order to facilitate the introduction of new per-CPU state,
> add a new host_data_ptr() helped that hides some of the per-CPU
> verbosity, and make it easier to move that state around in the
> future.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/include/asm/kvm_host.h | 37 +++++++++++++++++++++++
> arch/arm64/kvm/arm.c | 2 +-
> arch/arm64/kvm/hyp/include/hyp/debug-sr.h | 4 +--
> arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++---
> arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 +-
> arch/arm64/kvm/hyp/nvhe/setup.c | 3 +-
> arch/arm64/kvm/hyp/nvhe/switch.c | 4 +--
> arch/arm64/kvm/hyp/vhe/switch.c | 4 +--
> arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 4 +--
> arch/arm64/kvm/pmu.c | 2 +-
> 10 files changed, 53 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 6883963bbc3a..ca6ef663950d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -530,6 +530,17 @@ struct kvm_cpu_context {
> u64 *vncr_array;
> };
>
> +/*
> + * This structure is instantiated on a per-CPU basis, and contains
> + * data that is:
> + *
> + * - tied to a single physical CPU, and
> + * - either have a lifetime that does not extend past vcpu_put()
> + * - or is an invariant for the lifetime of the system
> + *
> + * Use host_data_ptr(field) as a way to access a pointer to such a
> + * field.
> + */
> struct kvm_host_data {
> struct kvm_cpu_context host_ctxt;
> };
> @@ -1167,6 +1178,32 @@ struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
>
> DECLARE_KVM_HYP_PER_CPU(struct kvm_host_data, kvm_host_data);
>
> +/*
> + * How we access per-CPU host data depends on the where we access it from,
> + * and the mode we're in:
> + *
> + * - VHE and nVHE hypervisor bits use their locally defined instance
> + *
> + * - the rest of the kernel use either the VHE or nVHE one, depending on
> + * the mode we're running in.
> + *
> + * Unless we're in protected mode, fully deprivileged, and the nVHE
> + * per-CPU stuff is exclusively accessible to the protected EL2 code.
> + * In this case, the EL1 code uses the *VHE* data as its private state
> + * (which makes sense in a way as there shouldn't be any shared state
> + * between the host and the hypervisor).
Does this mean we have a bug in cpu_hyp_init_context(), e.g. for a
hotplugged CPU and needs to be fixed for stable ?
Eitherways,
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> + *
> + * Yes, this is all totally trivial. Shoot me now.
> + */
> +#if defined(__KVM_NVHE_HYPERVISOR__) || defined(__KVM_VHE_HYPERVISOR__)
> +#define host_data_ptr(f) (&this_cpu_ptr(&kvm_host_data)->f)
> +#else
> +#define host_data_ptr(f) \
> + (static_branch_unlikely(&kvm_protected_mode_initialized) ? \
> + &this_cpu_ptr(&kvm_host_data)->f : \
> + &this_cpu_ptr_hyp_sym(kvm_host_data)->f)
> +#endif
> +
> static inline void kvm_init_host_cpu_context(struct kvm_cpu_context *cpu_ctxt)
> {
> /* The host's MPIDR is immutable, so let's set it up at boot time */
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 3dee5490eea9..a24287c3ba99 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1971,7 +1971,7 @@ static void cpu_set_hyp_vector(void)
>
> static void cpu_hyp_init_context(void)
> {
> - kvm_init_host_cpu_context(&this_cpu_ptr_hyp_sym(kvm_host_data)->host_ctxt);
> + kvm_init_host_cpu_context(host_data_ptr(host_ctxt));
>
> if (!is_kernel_in_hyp_mode())
> cpu_init_hyp_mode();
> diff --git a/arch/arm64/kvm/hyp/include/hyp/debug-sr.h b/arch/arm64/kvm/hyp/include/hyp/debug-sr.h
> index 961bbef104a6..eec0f8ccda56 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/debug-sr.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/debug-sr.h
> @@ -135,7 +135,7 @@ static inline void __debug_switch_to_guest_common(struct kvm_vcpu *vcpu)
> if (!vcpu_get_flag(vcpu, DEBUG_DIRTY))
> return;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> guest_ctxt = &vcpu->arch.ctxt;
> host_dbg = &vcpu->arch.host_debug_state.regs;
> guest_dbg = kern_hyp_va(vcpu->arch.debug_ptr);
> @@ -154,7 +154,7 @@ static inline void __debug_switch_to_host_common(struct kvm_vcpu *vcpu)
> if (!vcpu_get_flag(vcpu, DEBUG_DIRTY))
> return;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> guest_ctxt = &vcpu->arch.ctxt;
> host_dbg = &vcpu->arch.host_debug_state.regs;
> guest_dbg = kern_hyp_va(vcpu->arch.debug_ptr);
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index e3fcf8c4d5b4..ae198b84ca01 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -155,7 +155,7 @@ static inline bool cpu_has_amu(void)
>
> static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> {
> - struct kvm_cpu_context *hctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + struct kvm_cpu_context *hctxt = host_data_ptr(host_ctxt);
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>
> CHECK_FGT_MASKS(HFGRTR_EL2);
> @@ -191,7 +191,7 @@ static inline void __activate_traps_hfgxtr(struct kvm_vcpu *vcpu)
>
> static inline void __deactivate_traps_hfgxtr(struct kvm_vcpu *vcpu)
> {
> - struct kvm_cpu_context *hctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + struct kvm_cpu_context *hctxt = host_data_ptr(host_ctxt);
> struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>
> if (!cpus_have_final_cap(ARM64_HAS_FGT))
> @@ -226,7 +226,7 @@ static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
>
> write_sysreg(0, pmselr_el0);
>
> - hctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + hctxt = host_data_ptr(host_ctxt);
> ctxt_sys_reg(hctxt, PMUSERENR_EL0) = read_sysreg(pmuserenr_el0);
> write_sysreg(ARMV8_PMU_USERENR_MASK, pmuserenr_el0);
> vcpu_set_flag(vcpu, PMUSERENR_ON_CPU);
> @@ -260,7 +260,7 @@ static inline void __deactivate_traps_common(struct kvm_vcpu *vcpu)
> if (kvm_arm_support_pmu_v3()) {
> struct kvm_cpu_context *hctxt;
>
> - hctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + hctxt = host_data_ptr(host_ctxt);
> write_sysreg(ctxt_sys_reg(hctxt, PMUSERENR_EL0), pmuserenr_el0);
> vcpu_clear_flag(vcpu, PMUSERENR_ON_CPU);
> }
> diff --git a/arch/arm64/kvm/hyp/nvhe/psci-relay.c b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> index d57bcb6ab94d..dfe8fe0f7eaf 100644
> --- a/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> +++ b/arch/arm64/kvm/hyp/nvhe/psci-relay.c
> @@ -205,7 +205,7 @@ asmlinkage void __noreturn __kvm_host_psci_cpu_entry(bool is_cpu_on)
> struct psci_boot_args *boot_args;
> struct kvm_cpu_context *host_ctxt;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
>
> if (is_cpu_on)
> boot_args = this_cpu_ptr(&cpu_on_args);
> diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> index bc58d1b515af..ae00dfa80801 100644
> --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> @@ -257,8 +257,7 @@ static int fix_hyp_pgtable_refcnt(void)
>
> void __noreturn __pkvm_init_finalise(void)
> {
> - struct kvm_host_data *host_data = this_cpu_ptr(&kvm_host_data);
> - struct kvm_cpu_context *host_ctxt = &host_data->host_ctxt;
> + struct kvm_cpu_context *host_ctxt = host_data_ptr(host_ctxt);
> unsigned long nr_pages, reserved_pages, pfn;
> int ret;
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
> index c50f8459e4fc..544a419b9a39 100644
> --- a/arch/arm64/kvm/hyp/nvhe/switch.c
> +++ b/arch/arm64/kvm/hyp/nvhe/switch.c
> @@ -264,7 +264,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> pmr_sync();
> }
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> host_ctxt->__hyp_running_vcpu = vcpu;
> guest_ctxt = &vcpu->arch.ctxt;
>
> @@ -367,7 +367,7 @@ asmlinkage void __noreturn hyp_panic(void)
> struct kvm_cpu_context *host_ctxt;
> struct kvm_vcpu *vcpu;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> vcpu = host_ctxt->__hyp_running_vcpu;
>
> if (vcpu) {
> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index 1581df6aec87..14b7a6bc5909 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> @@ -221,7 +221,7 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> struct kvm_cpu_context *guest_ctxt;
> u64 exit_code;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> host_ctxt->__hyp_running_vcpu = vcpu;
> guest_ctxt = &vcpu->arch.ctxt;
>
> @@ -306,7 +306,7 @@ static void __hyp_call_panic(u64 spsr, u64 elr, u64 par)
> struct kvm_cpu_context *host_ctxt;
> struct kvm_vcpu *vcpu;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> vcpu = host_ctxt->__hyp_running_vcpu;
>
> __deactivate_traps(vcpu);
> diff --git a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> index a8b9ea496706..e12bd7d6d2dc 100644
> --- a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> @@ -67,7 +67,7 @@ void __vcpu_load_switch_sysregs(struct kvm_vcpu *vcpu)
> struct kvm_cpu_context *guest_ctxt = &vcpu->arch.ctxt;
> struct kvm_cpu_context *host_ctxt;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
> __sysreg_save_user_state(host_ctxt);
>
> /*
> @@ -110,7 +110,7 @@ void __vcpu_put_switch_sysregs(struct kvm_vcpu *vcpu)
> struct kvm_cpu_context *guest_ctxt = &vcpu->arch.ctxt;
> struct kvm_cpu_context *host_ctxt;
>
> - host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + host_ctxt = host_data_ptr(host_ctxt);
>
> __sysreg_save_el1_state(guest_ctxt);
> __sysreg_save_user_state(guest_ctxt);
> diff --git a/arch/arm64/kvm/pmu.c b/arch/arm64/kvm/pmu.c
> index a243934c5568..329819806096 100644
> --- a/arch/arm64/kvm/pmu.c
> +++ b/arch/arm64/kvm/pmu.c
> @@ -232,7 +232,7 @@ bool kvm_set_pmuserenr(u64 val)
> if (!vcpu || !vcpu_get_flag(vcpu, PMUSERENR_ON_CPU))
> return false;
>
> - hctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> + hctxt = host_data_ptr(host_ctxt);
> ctxt_sys_reg(hctxt, PMUSERENR_EL0) = val;
> return true;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 07/27] iommu/arm-smmu-v3: Move the CD generation for S1 domains into a function
From: Jason Gunthorpe @ 2024-03-25 14:30 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf7VFce6E_8NM2r8@google.com>
On Sat, Mar 23, 2024 at 01:11:49PM +0000, Mostafa Saleh wrote:
> On Mon, Mar 04, 2024 at 07:43:55PM -0400, Jason Gunthorpe wrote:
> > Introduce arm_smmu_make_s1_cd() to build the CD from the paging S1 domain,
> > and reorganize all the places programming S1 domain CD table entries to
> > call it.
> >
> > Split arm_smmu_update_s1_domain_cd_entry() from
> > arm_smmu_update_ctx_desc_devices() so that the S1 path has its own call
> > chain separate from the unrelated SVA path.
> >
> > arm_smmu_update_s1_domain_cd_entry() only works on S1 domains
> > attached to RIDs and refreshes all their CDs.
> >
> > Remove the forced clear of the CD during S1 domain attach,
> > arm_smmu_write_cd_entry() will do this automatically if necessary.
> >
> > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 25 +++++++-
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 60 +++++++++++++------
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 8 +++
> > 3 files changed, 75 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index bb9bb6fd7914ce..6acc65f6d00a71 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -54,6 +54,29 @@ static void arm_smmu_update_ctx_desc_devices(struct arm_smmu_domain *smmu_domain
> > spin_unlock_irqrestore(&smmu_domain->devices_lock, flags);
> > }
> >
> > +static void
> > +arm_smmu_update_s1_domain_cd_entry(struct arm_smmu_domain *smmu_domain)
> > +{
> > + struct arm_smmu_master *master;
> > + struct arm_smmu_cd target_cd;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&smmu_domain->devices_lock, flags);
> > + list_for_each_entry(master, &smmu_domain->devices, domain_head) {
> > + struct arm_smmu_cd *cdptr;
> > +
> > + /* S1 domains only support RID attachment right now */
> > + cdptr = arm_smmu_get_cd_ptr(master, IOMMU_NO_PASID);
> > + if (WARN_ON(!cdptr))
>
> This should never hit, no? Otherwise that means this path can allocate memory
> with a spinlock.
Right, WARN_ON's should never be hit.
> > +void arm_smmu_make_s1_cd(struct arm_smmu_cd *target,
> > + struct arm_smmu_master *master,
> > + struct arm_smmu_domain *smmu_domain)
> > +{
> > + struct arm_smmu_ctx_desc *cd = &smmu_domain->cd;
> > +
> > + memset(target, 0, sizeof(*target));
> > +
> > + target->data[0] = cpu_to_le64(
> > + cd->tcr |
> > +#ifdef __BIG_ENDIAN
> > + CTXDESC_CD_0_ENDI |
> > +#endif
> > + CTXDESC_CD_0_V |
> > + CTXDESC_CD_0_AA64 |
> > + (master->stall_enabled ? CTXDESC_CD_0_S : 0) |
> > + CTXDESC_CD_0_R |
> > + CTXDESC_CD_0_A |
> > + CTXDESC_CD_0_ASET |
> > + FIELD_PREP(CTXDESC_CD_0_ASID, cd->asid)
> > + );
> > +
> > + target->data[1] = cpu_to_le64(cd->ttbr & CTXDESC_CD_1_TTB0_MASK);
> > + target->data[3] = cpu_to_le64(cd->mair);
> > +}
> > +
>
> That seems to duplicate some logic from arm_smmu_write_ctx_desc(),
> can that be consolidated?
Yes, it is consolidated by deleting arm_smmu_write_ctx_desc() in a few
more patches.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 05/27] iommu/arm-smmu-v3: Make CD programming use arm_smmu_write_entry()
From: Jason Gunthorpe @ 2024-03-25 14:25 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf7S109OKJlRVXiR@google.com>
On Sat, Mar 23, 2024 at 01:02:15PM +0000, Mostafa Saleh wrote:
> Hi Jason,
>
> On Mon, Mar 04, 2024 at 07:43:53PM -0400, Jason Gunthorpe wrote:
> > CD table entries and STE's have the same essential programming sequence,
> > just with different types and sizes.
> >
> > Have arm_smmu_write_ctx_desc() generate a target CD and call
> > arm_smmu_write_entry() to do the programming. Due to the way the
> > target CD is generated by modifying the existing CD this alone is not
> > enough for the CD callers to be freed of the ordering requirements.
> >
> > The following patches will make the rest of the CD flow mirror the STE
> > flow with precise CD contents generated in all cases.
> >
> > Currently the logic can't ensure that the CD always conforms to the used
> > requirements until all the CD generation is moved to the new method. Add a
> > temporary no_used_check to disable the assertions.
> >
>
> I am still going through the patches, but is it possible to
> reorder/squash to avoid that, so it is easier to review?
After Nicolin's remark I changed this one use a temporary helper to 0
the unused bits then we delete the helper instead of touching the
machinery itself. It is much clearer.
We can't avoid this with patch ordering because the progression is to
move CD generation out of arm_smmu_write_ctx_desc() type-by-type then
delete it. In the mean time we need to use the new write logic in all
cases because I'm not sure the old/new schemes have compatible
assumptions for the existing arm_smmu_write_ctx_desc() to be safe.
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/4] arm64: dts: rockchip: add wolfvision pf5 io expander board
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
Add device tree overlay for the WolfVision PF5 IO Expander board. This
extension board can be attached to the WolfVision PF5 mainboard and
features
- TI DP83826 Ethernet PHY
- RJ45 jack
- USB-A host port
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../rk3568-wolfvision-pf5-io-expander.dtso | 137 +++++++++++++++++++++
2 files changed, 138 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 8fb35a363e4f..0192980ef37f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -108,6 +108,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-wifi.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5-io-expander.dtso b/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5-io-expander.dtso
new file mode 100644
index 000000000000..ebcaeafc3800
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5-io-expander.dtso
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Device tree overlay for the WolfVision PF5 IO Expander board.
+ *
+ * Copyright (C) 2024 WolfVision GmbH.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/rk3568-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+ gmac0_clkin: external-gmac0-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ clock-output-names = "gmac0_clkin";
+ #clock-cells = <0>;
+ };
+
+ usb_host_vbus: usb-host-vbus-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_host_vbus_en>;
+ regulator-name = "usb_host_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v_in>;
+ };
+
+ vcc1v8_eth: vcc1v8-eth-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PC1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc1v8_eth_en>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "1v8_eth";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_eth: vcc3v3-eth-regulator {
+ compatible = "regulator-fixed";
+ enable-active-low;
+ gpio = <&gpio0 RK_PC0 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_eth_enn>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "3v3_eth";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+};
+
+&gmac0 {
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>,
+ <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RMII_SPEED>,
+ <&gmac0_clkin>;
+ clock_in_out = "input";
+ phy-handle = <&dp83826>;
+ phy-mode = "rmii";
+ phy-supply = <&vcc3v3_eth>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_clkinout
+ &gmac0_rx_er
+ &gmac0_rx_bus2
+ &gmac0_tx_bus2>;
+ status = "okay";
+};
+
+&mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp83826: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x0>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ð_wake_intn ð_phy_rstn>;
+ reset-assert-us = <1000>;
+ reset-deassert-us = <2000>;
+ reset-gpios = <&gpio0 RK_PD4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+};
+
+&pinctrl {
+ ethernet {
+ eth_wake_intn: eth-wake-intn-pinctrl {
+ rockchip,pins = <0 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ eth_phy_rstn: eth-phy-rstn-pinctrl {
+ rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc1v8_eth_en: vcc1v8-eth-en-pinctrl {
+ rockchip,pins = <0 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc3v3_eth_enn: vcc3v3-eth-enn-pinctrl {
+ rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ usb_host_vbus_en: usb-host-vbus-en-pinctrl {
+ rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&usb_host1_xhci {
+ maximum-speed = "high-speed";
+ phys = <&usb2phy0_host>;
+ phy-names = "usb2-phy";
+ status = "okay";
+};
+
+&usb2phy0_host {
+ phy-supply = <&usb_host_vbus>;
+ status = "okay";
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: rockchip: add wolfvision pf5 mainboard
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
Add device tree for the WolfVision PF5 mainboard. It features
- Rockchip RK3568 SoC
- eMMC
- RTC with backup battery
- on-board PDM microphone
- 12V DC jack
- HDMI output
- USB-C device port
as well as various expansion headers for different extension boards.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3568-wolfvision-pf5.dts | 528 +++++++++++++++++++++
2 files changed, 529 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index f906a868b71a..8fb35a363e4f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -107,6 +107,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-qnap-ts433.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-radxa-e25.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-coolpi-cm5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-wifi.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5.dts b/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5.dts
new file mode 100644
index 000000000000..a814749eaa97
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-wolfvision-pf5.dts
@@ -0,0 +1,528 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Device tree for the WolfVision PF5 mainboard.
+ *
+ * Copyright (C) 2024 WolfVision GmbH.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/regulator/ti,tps62864.h>
+#include <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+ model = "WolfVision PF5";
+ compatible = "wolfvision,rk3568-pf5", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ mmc0 = &sdhci;
+ rtc0 = &pcf85623;
+ rtc1 = &rk809;
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ hdmi_tx: hdmi-tx-connector {
+ compatible = "hdmi-connector";
+ hdmi-pwr-supply = <&hdmi_tx_5v>;
+ type = "a";
+
+ port {
+ hdmi_tx_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ hdmi_tx_5v: hdmi-tx-5v-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 RK_PC5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_tx_5v_en>;
+ regulator-name = "hdmi_tx_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v_in>;
+ };
+
+ pdm_codec: pdm-codec {
+ compatible = "dmic-codec";
+ num-channels = <1>;
+ #sound-dai-cells = <0>;
+ };
+
+ pdm_sound: pdm-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "microphone";
+
+ simple-audio-card,cpu {
+ sound-dai = <&pdm>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&pdm_codec>;
+ };
+ };
+
+ vcc12v_in: vcc12v-in-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "12v_in";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc12v_cam: vcc12v-cam-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc12v_cam_en>;
+ regulator-name = "12v_cam";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ vin-supply = <&vcc12v_in>;
+ };
+
+ vcc5v_in: vcc5v-in-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "5v_in";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc12v_in>;
+ };
+
+ vcc3v8_cam: vcc3v8-cam-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio0 RK_PC3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v8_cam_en>;
+ regulator-name = "3v8_cam";
+ regulator-min-microvolt = <3800000>;
+ regulator-max-microvolt = <3800000>;
+ vin-supply = <&vcc5v_in>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v_in>;
+ };
+};
+
+&combphy0 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vcc0v9_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vcc0v9_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vcc0v9_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vcc0v9_cpu>;
+};
+
+&gpu {
+ mali-supply = <&vcc0v9_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ avdd-0v9-supply = <&vcc0v9a_image>;
+ avdd-1v8-supply = <&vcc1v8a_image>;
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_tx_in>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ vcc1-supply = <&vcc5v_in>;
+ vcc2-supply = <&vcc5v_in>;
+ vcc3-supply = <&vcc5v_in>;
+ vcc4-supply = <&vcc5v_in>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc5v_in>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ wakeup-source;
+
+ regulators {
+ vcc0v9_logic: DCDC_REG1 {
+ regulator-name = "0v9_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc0v9_gpu: DCDC_REG2 {
+ regulator-name = "0v9_gpu";
+ regulator-always-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v1_ddr4: DCDC_REG3 {
+ regulator-name = "1v1_ddr4";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc0v9_npu: DCDC_REG4 {
+ regulator-name = "0v9_npu";
+ regulator-always-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8: DCDC_REG5 {
+ regulator-name = "1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc0v9a_image: LDO_REG1 {
+ regulator-name = "0v9a_image";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc0v9a: LDO_REG2 {
+ regulator-name = "0v9a";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc0v9a_pmu: LDO_REG3 {
+ regulator-name = "0v9a_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vcc3v3_acodec: LDO_REG4 {
+ regulator-name = "3v3_acodec";
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sd: LDO_REG5 {
+ regulator-name = "3v3_sd";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "3v3_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc1v8a: LDO_REG7 {
+ regulator-name = "1v8a";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8a_pmu: LDO_REG8 {
+ regulator-name = "1v8a_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8a_image: LDO_REG9 {
+ regulator-name = "1v8a_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_sw: SWITCH_REG1 {
+ regulator-name = "3v3_sw";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+
+ regulator@42 {
+ compatible = "ti,tps62869";
+ reg = <0x42>;
+
+ regulators {
+ vcc0v9_cpu: SW {
+ regulator-name = "0v9_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <TPS62864_MODE_FPWM>;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1150000>;
+ vin-supply = <&vcc5v_in>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+
+ pcf85623: rtc@51 {
+ compatible = "nxp,pcf85263";
+ reg = <0x51>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk32k_in>;
+ quartz-load-femtofarads = <12500>;
+ };
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m1_xfer>;
+};
+
+&pdm {
+ pinctrl-0 = <&pdmm0_clk
+ &pdmm0_sdi0>;
+ status = "okay";
+};
+
+&pinctrl {
+ cam {
+ vcc12v_cam_en: vcc12v-cam-en-pinctrl {
+ rockchip,pins = <2 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc3v8_cam_en: vcc3v8-cam-en-pinctrl {
+ rockchip,pins = <0 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ hdmitx {
+ hdmi_tx_5v_en: hdmi-tx-5v-en-pinctrl {
+ rockchip,pins = <4 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l-pinctrl {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vcc3v3_acodec>;
+ vccio2-supply = <&vcc1v8>;
+ vccio3-supply = <&vcc3v3_sd>;
+ vccio4-supply = <&vcc1v8>;
+ vccio5-supply = <&vcc1v8>;
+ vccio6-supply = <&vcc3v3_sw>;
+ vccio7-supply = <&vcc3v3_sw>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc1v8a>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ max-frequency = <200000000>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ vmmc-supply = <&vcc3v3_sw>;
+ vqmmc-supply = <&vcc1v8>;
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ dr_mode = "peripheral";
+ /* The following quirks are required since the bInterval is 1 and we
+ * handle steady ISOC streaming. See Usecase 3 in commit 729dcffd1ed3
+ * ("usb: dwc3: gadget: Add support for disabling U1 and U2 entries").
+ */
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ /*
+ * Without this quirk the available fifosize seems to be miscalculated
+ * in cases where many endpoints are used. In one particular situation
+ * 8 IN EPs and 3 OUT EPs where selected and lead to stalled transfers
+ * without the resize quirk.
+ */
+ tx-fifo-resize;
+
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_otg {
+ status = "okay";
+};
+
+&vop {
+ assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP2>;
+ assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: arm: rockchip: add wolfvision pf5 mainboard
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
Add the WolfVision PF5 mainboard, which serves as base for recent
WolfVision products. It features the Rockchip RK3568 SoC and can
be extended with several different extension boards.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index fcf7316ecd74..99bd5e2c76a0 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -927,6 +927,11 @@ properties:
- const: turing,rk1
- const: rockchip,rk3588
+ - description: WolfVision PF5 mainboard
+ items:
+ - const: wolfvision,rk3568-pf5
+ - const: rockchip,rk3568
+
- description: Xunlong Orange Pi 5 Plus
items:
- const: xunlong,orangepi-5-plus
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: rockchip: add wolfvision pf5 mainboard
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
Habidere,
This series adds the device tree for the WolfVision PF5 mainboard, which
serves as base for recent WolfVision products. It features the Rockchip
RK3568 and can be extended with several different extension boards.
The WolfVision PF5 IO Expander is one example of such an extension board.
The corresponding device tree overlay is also included in this series.
May this be the beginning of a beautiful friendship :-)
Looking forward to your comments!
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
Michael Riesch (4):
dt-bindings: add wolfvision vendor prefix
dt-bindings: arm: rockchip: add wolfvision pf5 mainboard
arm64: dts: rockchip: add wolfvision pf5 mainboard
arm64: dts: rockchip: add wolfvision pf5 io expander board
.../devicetree/bindings/arm/rockchip.yaml | 5 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/rockchip/Makefile | 2 +
.../rk3568-wolfvision-pf5-io-expander.dtso | 137 ++++++
.../boot/dts/rockchip/rk3568-wolfvision-pf5.dts | 528 +++++++++++++++++++++
5 files changed, 674 insertions(+)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240325-feature-wolfvision-pf5-5c1924c0389c
Best regards,
--
Michael Riesch <michael.riesch@wolfvision.net>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/4] dt-bindings: add wolfvision vendor prefix
From: Michael Riesch @ 2024-03-25 14:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Michael Riesch
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
Add vendor prefix for WolfVision GmbH (https://wolfvision.com).
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index b97d298b3eb6..59c6c6760bc0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1627,6 +1627,8 @@ patternProperties:
description: Wondermedia Technologies, Inc.
"^wobo,.*":
description: Wobo
+ "^wolfvision,.*":
+ description: WolfVision GmbH
"^x-powers,.*":
description: X-Powers
"^xen,.*":
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5 08/27] iommu/arm-smmu-v3: Move allocation of the cdtable into arm_smmu_get_cd_ptr()
From: Jason Gunthorpe @ 2024-03-25 14:21 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf3W3lo8dXZuKbgm@google.com>
On Fri, Mar 22, 2024 at 07:07:10PM +0000, Mostafa Saleh wrote:
> Hi Jason,
>
> On Mon, Mar 04, 2024 at 07:43:56PM -0400, Jason Gunthorpe wrote:
> > No reason to force callers to do two steps. Make arm_smmu_get_cd_ptr()
> > able to return an entry in all cases except OOM
>
> I believe the current code is more clear, as it is explicit about which path
> is expected to allocate.
I think we had this allocate vs no allocate discussion before on
something else..
It would be good to make *full* allocate/noallocate variants of
get_cd_ptr() and the cases that must never allocate call the no
allocate variation. There are some issues with GFP_KERNEL/ATOMIC that
are a bit hard to understand as well.
This is a bigger issue than just the cd_table, as even the leafs
should not allocate.
> As there are many callers for arm_smmu_get_cd_ptr() directly and indirectly,
> and it read-modify-writes the cdtable, it would be a pain to debug not
> knowing which one could allocate, and this patch only abstracts one
> allocating call, so it is not much code less.
> For example, (again I don’t know much about SVA) I think there might be a
> race condition as follows:
> arm_smmu_attach_dev
> arm_smmu_domain_finalise() => set domain stage
> [....]
> arm_smmu_get_cd_ptr() => RMW master->cd_table
>
> arm_smmu_sva_set_dev_pasid
> __arm_smmu_sva_bind
> Check stage is valid
> [...]
> arm_smmu_write_ctx_desc
> arm_smmu_get_cd_ptr => RMW master->cd_table
>
> If this path is true though, I guess the in current code, we would need some
> barriers in arm_smmu_get_cd_ptr(), arm_smmu_get_cd_ptr()
Both of those functions are called under the group mutex held by the
core code.
The only valid condition to change the CD table backing memory is when
the group mutex is held. We now have iommu_group_mutex_assert() so an
alloc/noalloc split can call that test on the alloc side which is
motivation enough to do it, IMHO.
I will split the function and sort it all out, but I will still
integrate the cd_table allocation into the allocating version of
get_cd_ptr().
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] iommu/arm-smmu-v3: support suspend/resume
From: Jason Gunthorpe @ 2024-03-25 13:48 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Thomas Gleixner,
Marc Zyngier, Bixuan Cui, linux-arm-kernel, iommu, linux-kernel,
Peng Fan
In-Reply-To: <20240324-smmu-v3-v1-3-11bc96e156a5@nxp.com>
On Sun, Mar 24, 2024 at 08:29:00PM +0800, Peng Fan (OSS) wrote:
> +static void arm_smmu_resume_unique_irqs(struct arm_smmu_device *smmu)
> +{
> + struct device *dev = smmu->dev;
> + struct msi_desc *desc;
> + struct msi_msg msg;
> +
> + if (!dev->msi.domain)
> + return;
> +
> + desc = irq_get_msi_desc(smmu->evtq.q.irq);
> + if (desc) {
> + get_cached_msi_msg(smmu->evtq.q.irq, &msg);
> + arm_smmu_write_msi_msg(desc, &msg);
> + }
> +
> + desc = irq_get_msi_desc(smmu->gerr_irq);
> + if (desc) {
> + get_cached_msi_msg(smmu->gerr_irq, &msg);
> + arm_smmu_write_msi_msg(desc, &msg);
> + }
> +
> + if (smmu->features & ARM_SMMU_FEAT_PRI) {
> + desc = irq_get_msi_desc(smmu->priq.q.irq);
> + if (desc) {
> + get_cached_msi_msg(smmu->priq.q.irq, &msg);
> + arm_smmu_write_msi_msg(desc, &msg);
> + }
> + }
> +}
I wonder if this should be done instead by converting the driver away
from platform MSI to the new MSI mechanism?
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/22] ASoC: mediatek: Add common machine soundcard driver probe mechanism
From: Mark Brown @ 2024-03-25 14:18 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: shraash, alsa-devel, allen-kh.cheng, kuninori.morimoto.gx,
lgirdwood, tiwai, shane.chien, krzysztof.kozlowski+dt,
claudiu.beznea, kernel, robh, nfraprado, amergnat, zhourui,
jiaxin.yu, trevor.wu, wenst, devicetree, conor+dt, ckeepax, arnd,
frank.li, maso.huang, u.kleine-koenig, eugen.hristev,
alpernebiyasak, linux-mediatek, linux-sound, matthias.bgg, perex,
linux-arm-kernel, xiazhengqiao, dianders, linux-kernel,
jarkko.nikula
In-Reply-To: <20240313110147.1267793-6-angelogioacchino.delregno@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 3033 bytes --]
On Wed, Mar 13, 2024 at 12:01:30PM +0100, AngeloGioacchino Del Regno wrote:
> Add a common machine soundcard driver probe function that supports both
> DSP and AFE-direct usecases and also provides a hook for legacy machine
> soundcard driver probe mechanisms.
>
> Note that the hook is there because, even for legacy probe, a lot of the
> actual code can still be commonized, hence still reducing duplication
> for the legacy devicetree retrocompatibility cases.
>
> This common probe function deprecates all of the inconsistent previous
> probe mechanisms and aims to settle all of the MediaTek card drivers on
> consistent and common devicetree properties describing wanted DAIs,
> device specific DAI configuration and DAI links to codecs found on
> each device/board.
This breaks allmodconfig builds:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c: In function ‘mtk_sof_dai_link_fixup’:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c:18:41: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
18 | struct mtk_sof_priv *sof_priv = soc_card_data->sof_priv;
| ^~~~~~~~~~~~~
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c: In function ‘mtk_sof_card_probe’:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c:58:41: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
58 | struct mtk_sof_priv *sof_priv = soc_card_data->sof_priv;
| ^~~~~~~~~~~~~
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c: In function ‘mtk_sof_find_tplg_be’:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c:76:41: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
76 | struct mtk_sof_priv *sof_priv = soc_card_data->sof_priv;
| ^~~~~~~~~~~~~
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c: In function ‘mtk_sof_check_tplg_be_dai_link_fixup’:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c:116:41: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
116 | struct mtk_sof_priv *sof_priv = soc_card_data->sof_priv;
| ^~~~~~~~~~~~~
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c: In function ‘mtk_sof_card_late_probe’:
/build/stage/linux/sound/soc/mediatek/common/mtk-dsp-sof-common.c:147:41: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
147 | struct mtk_sof_priv *sof_priv = soc_card_data->sof_priv;
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 8/8] PCI: dwc: ep: Remove "core_init_notifier" flag
From: Manivannan Sadhasivam @ 2024-03-25 14:17 UTC (permalink / raw)
To: Niklas Cassel
Cc: Jingoo Han, Gustavo Pimentel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Marek Vasut, Yoshihiro Shimoda, Thierry Reding, Jonathan Hunter,
Kishon Vijay Abraham I, Vidya Sagar, Vignesh Raghavendra,
Richard Zhu, Lucas Stach, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Minghuan Lian, Mingkai Hu, Roy Zang, Kunihiko Hayashi,
Masami Hiramatsu, Kishon Vijay Abraham I, Jesper Nilsson,
Srikanth Thokala, linux-pci, linux-kernel, linux-renesas-soc,
linux-arm-msm, linux-tegra, linux-omap, linux-arm-kernel,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <Zf1xTkuK8yBZXmQ0@ryzen>
On Fri, Mar 22, 2024 at 12:53:50PM +0100, Niklas Cassel wrote:
> On Thu, Mar 14, 2024 at 01:18:06PM +0530, Manivannan Sadhasivam wrote:
> > "core_init_notifier" flag is set by the glue drivers requiring refclk from
> > the host to complete the DWC core initialization. Also, those drivers will
> > send a notification to the EPF drivers once the initialization is fully
> > completed using the pci_epc_init_notify() API. Only then, the EPF drivers
> > will start functioning.
> >
> > For the rest of the drivers generating refclk locally, EPF drivers will
> > start functioning post binding with them. EPF drivers rely on the
> > 'core_init_notifier' flag to differentiate between the drivers.
> > Unfortunately, this creates two different flows for the EPF drivers.
> >
> > So to avoid that, let's get rid of the "core_init_notifier" flag and follow
> > a single initialization flow for the EPF drivers. This is done by calling
> > the dw_pcie_ep_init_notify() from all glue drivers after the completion of
> > dw_pcie_ep_init_registers() API. This will allow all the glue drivers to
> > send the notification to the EPF drivers once the initialization is fully
> > completed.
> >
> > Only difference here is that, the drivers requiring refclk from host will
> > send the notification once refclk is received, while others will send it
> > during probe time itself.
> >
> > But this also requires the EPC core driver to deliver the notification
> > after EPF driver bind. Because, the glue driver can send the notification
> > before the EPF drivers bind() and in those cases the EPF drivers will miss
> > the event. To accommodate this, EPC core is now caching the state of the
> > EPC initialization in 'init_complete' flag and pci-ep-cfs driver sends the
> > notification to EPF drivers based on that after each EPF driver bind.
> >
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> > drivers/pci/controller/dwc/pci-dra7xx.c | 2 ++
> > drivers/pci/controller/dwc/pci-imx6.c | 2 ++
> > drivers/pci/controller/dwc/pci-keystone.c | 2 ++
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 2 ++
> > drivers/pci/controller/dwc/pcie-artpec6.c | 2 ++
> > drivers/pci/controller/dwc/pcie-designware-plat.c | 2 ++
> > drivers/pci/controller/dwc/pcie-keembay.c | 2 ++
> > drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 -
> > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 ++
> > drivers/pci/controller/dwc/pcie-tegra194.c | 1 -
> > drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 ++
> > drivers/pci/endpoint/functions/pci-epf-test.c | 18 +++++-------------
> > drivers/pci/endpoint/pci-ep-cfs.c | 9 +++++++++
> > drivers/pci/endpoint/pci-epc-core.c | 22 ++++++++++++++++++++++
> > include/linux/pci-epc.h | 7 ++++---
> > 15 files changed, 58 insertions(+), 18 deletions(-)
>
> FWIW:
> Tested-by: Niklas Cassel <cassel@kernel.org>
>
>
>
> However, when looking at this, I was surprised that you never call something
> that will set:
> init_complete = false;
> from e.g. dw_pcie_ep_deinit() or dw_pcie_ep_cleanup().
>
> I saw that you do seem to set
> init_complete = false;
> in your other follow up series that is based on this one.
>
> What will happen if you run with only this series merged (without your
> follow up series), on a platform that used to have .core_init_notifier?
>
> If you do remove and recreate the symlink on a platform with external
> refclk, since you never set init_complete to false, you could trigger
> EPF core_init callback, e.g. pci_epf_test_core_init() to be called,
> which will do DBI writes even when there is no refclk.
>
> E.g. (on a platform with external refclk):
> 1) Create symlink to pci-epf-test in configfs.
> 2) Start RC, your EPC driver will call ep_init_notifiy() when perst
> deasserts.
> 3) Run pci-epf-test.
> 4) Remove the pci-epf-test symlink
> 5) Shutdown RC
> 6) Create symlink to pci-epf-test in configfs.
> This will see that init_complete is true, and will do DBI writes
> which will crash your system, since you don't have a refclk.
>
> Perhaps you should move the patch that calls a function that sets
> init_complete = false;
> to this series, so that this crash is not possible?
>
Good catch! But moving that patch to this series requires moving some other
patches as well. So in the meantime, I'll set this flag to false in
dw_pcie_ep_cleanup().
[...]
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 18c80002d3bd..fc0282b0d626 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
[...]
> > - if (!core_init_notifier) {
> > - ret = pci_epf_test_core_init(epf);
> > - if (ret)
> > - return ret;
> > - }
> > -
>
> While you did fix up all DWC based drivers, the non-DWC EPC drivers that
> did not have epc_features->core_init_notifier before this patch:
>
> drivers/pci/controller/cadence/pcie-cadence-ep.c:#include <linux/pci-epc.h>
> drivers/pci/controller/pcie-rcar-ep.c:#include <linux/pci-epc.h>
> drivers/pci/controller/pcie-rockchip-ep.c:#include <linux/pci-epc.h>
>
> I don't think that they will work with pci-epf-test anymore, since AFAICT,
> you did not add a call to: pci_epc_init_notify() or similar in these EPC drivers.
> (Like this patch does to all the DWC-based drivers without a core_init_notifier.)
>
Doh, yeah I completely missed these. Thanks for pointing out. Will add the
notify_init call in next version.
- Mani
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 06/27] iommu/arm-smmu-v3: Consolidate clearing a CD table entry
From: Jason Gunthorpe @ 2024-03-25 14:14 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf3PoRy_q7dC_SA9@google.com>
On Fri, Mar 22, 2024 at 06:36:17PM +0000, Mostafa Saleh wrote:
> > +void arm_smmu_clear_cd(struct arm_smmu_master *master, ioasid_t ssid)
> > +{
> > + struct arm_smmu_cd target = {};
> > + struct arm_smmu_cd *cdptr;
> > +
> > + if (!master->cd_table.cdtab)
> > + return;
> > + cdptr = arm_smmu_get_cd_ptr(master, ssid);
> > + if (WARN_ON(!cdptr))
> > + return;
>
> I don’t understand the SVA code enough, but AFAICT, arm_smmu_sva_set_dev_pasid
> can allocate the L2 CD table through arm_smmu_write_ctx_desc.
Yes
> And if it failed
> before allocating the CD table, then remove_dev_pasid would be
> called,
If it fails the core code should not call remove_dev_pasid() on a
domain that was never attached. There is an obscure error unwinding
issue in the core code Yi is looking to fix regarding multi-device
PASID groups, but it is not a driver issue..
> which warns here, the previous code would tolerate that, but that
> might regress on systems with panic_on_warn, so I am not sure if
> that is necessary.
Right, if it does hit it signals there is some error unwinding bug in
the core code that should be resolved.
> Otherwise, Reviewed-by: Mostafa Saleh <smostafa@google.com>
Thanks,
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 04/27] iommu/arm-smmu-v3: Add an ops indirection to the STE code
From: Jason Gunthorpe @ 2024-03-25 14:11 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Eric Auger, Jean-Philippe Brucker, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameerali Kolothum Thodi
In-Reply-To: <Zf3KgGj4Tfc8ytgi@google.com>
On Fri, Mar 22, 2024 at 06:14:24PM +0000, Mostafa Saleh wrote:
> > @@ -1027,57 +1038,55 @@ static void arm_smmu_get_ste_used(const struct arm_smmu_ste *ent,
> > * unused_update is an intermediate value of entry that has unused bits set to
> > * their new values.
> > */
> > -static u8 arm_smmu_entry_qword_diff(const struct arm_smmu_ste *entry,
> > - const struct arm_smmu_ste *target,
> > - struct arm_smmu_ste *unused_update)
> > +static u8 arm_smmu_entry_qword_diff(struct arm_smmu_entry_writer *writer,
> > + const __le64 *entry, const __le64 *target,
> > + __le64 *unused_update)
> > {
> > - struct arm_smmu_ste target_used = {};
> > - struct arm_smmu_ste cur_used = {};
> > + __le64 target_used[NUM_ENTRY_QWORDS] = {};
> > + __le64 cur_used[NUM_ENTRY_QWORDS] = {};
> This is confusing to me, the function was modified to be generic, so its has
> args are __le64 * instead of struct arm_smmu_ste *.
Right
> But NUM_ENTRY_QWORDS is defined as “(sizeof(struct arm_smmu_ste) / sizeof(u64))”
> and in the same function writer->ops->num_entry_qwords is used
> nterchangeably,
Right
> I understand that this not a constant and the compiler would complain.
> But since for any other num_entry_qwords larger than NUM_ENTRY_QWORDS it fails,
> and we know STEs and CDs both have the same size, we simplify the code and make
> it a constant everywhere.
So you say to get rid of num_entry_qwords and just use the constant?
> I see in the next patch, that this is redefined to be the max between STE and
> CD, but again, this hardware and it never changes, so my opinion is to simplify
> the code, as there is no need to generalize this part.
Yes, we need a constant.
It would look like this, it is a little bit simpler:
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a54062faccde38..d015f41900d802 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -63,9 +63,9 @@ enum arm_smmu_msi_index {
ARM_SMMU_MAX_MSIS,
};
-#define NUM_ENTRY_QWORDS \
- (max(sizeof(struct arm_smmu_ste), sizeof(struct arm_smmu_cd)) / \
- sizeof(u64))
+#define NUM_ENTRY_QWORDS 8
+static_assert(sizeof(struct arm_smmu_ste) == NUM_ENTRY_QWORDS * sizeof(u64));
+static_assert(sizeof(struct arm_smmu_cd) == NUM_ENTRY_QWORDS * sizeof(u64));
static phys_addr_t arm_smmu_msi_cfg[ARM_SMMU_MAX_MSIS][3] = {
[EVTQ_MSI_INDEX] = {
@@ -1045,7 +1045,7 @@ static u8 arm_smmu_entry_qword_diff(struct arm_smmu_entry_writer *writer,
writer->ops->get_used(entry, cur_used);
writer->ops->get_used(target, target_used);
- for (i = 0; i != writer->ops->num_entry_qwords; i++) {
+ for (i = 0; i != NUM_ENTRY_QWORDS; i++) {
/*
* Check that masks are up to date, the make functions are not
* allowed to set a bit to 1 if the used function doesn't say it
@@ -1114,7 +1114,6 @@ static bool entry_set(struct arm_smmu_entry_writer *writer, __le64 *entry,
void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *entry,
const __le64 *target)
{
- unsigned int num_entry_qwords = writer->ops->num_entry_qwords;
__le64 unused_update[NUM_ENTRY_QWORDS];
u8 used_qword_diff;
@@ -1137,9 +1136,9 @@ void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *entry,
*/
unused_update[critical_qword_index] =
entry[critical_qword_index];
- entry_set(writer, entry, unused_update, 0, num_entry_qwords);
+ entry_set(writer, entry, unused_update, 0, NUM_ENTRY_QWORDS);
entry_set(writer, entry, target, critical_qword_index, 1);
- entry_set(writer, entry, target, 0, num_entry_qwords);
+ entry_set(writer, entry, target, 0, NUM_ENTRY_QWORDS);
} else if (used_qword_diff) {
/*
* At least two qwords need their inuse bits to be changed. This
@@ -1148,7 +1147,7 @@ void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *entry,
*/
unused_update[0] = entry[0] & (~writer->ops->v_bit);
entry_set(writer, entry, unused_update, 0, 1);
- entry_set(writer, entry, target, 1, num_entry_qwords - 1);
+ entry_set(writer, entry, target, 1, NUM_ENTRY_QWORDS - 1);
entry_set(writer, entry, target, 0, 1);
} else {
/*
@@ -1157,7 +1156,7 @@ void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer, __le64 *entry,
* compute_qword_diff().
*/
WARN_ON_ONCE(
- entry_set(writer, entry, target, 0, num_entry_qwords));
+ entry_set(writer, entry, target, 0, NUM_ENTRY_QWORDS));
}
}
@@ -1272,7 +1271,6 @@ static const struct arm_smmu_entry_writer_ops arm_smmu_cd_writer_ops = {
.sync = arm_smmu_cd_writer_sync_entry,
.get_used = arm_smmu_get_cd_used,
.v_bit = cpu_to_le64(CTXDESC_CD_0_V),
- .num_entry_qwords = sizeof(struct arm_smmu_cd) / sizeof(u64),
};
void arm_smmu_write_cd_entry(struct arm_smmu_master *master, int ssid,
@@ -1460,7 +1458,6 @@ static const struct arm_smmu_entry_writer_ops arm_smmu_ste_writer_ops = {
.sync = arm_smmu_ste_writer_sync_entry,
.get_used = arm_smmu_get_ste_used,
.v_bit = cpu_to_le64(STRTAB_STE_0_V),
- .num_entry_qwords = sizeof(struct arm_smmu_ste) / sizeof(u64),
};
static void arm_smmu_write_ste(struct arm_smmu_master *master, u32 sid,
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index 8ba07b00bf6056..5936dc5f76786a 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -779,7 +779,6 @@ struct arm_smmu_entry_writer {
};
struct arm_smmu_entry_writer_ops {
- unsigned int num_entry_qwords;
__le64 v_bit;
void (*get_used)(const __le64 *entry, __le64 *used);
void (*sync)(struct arm_smmu_entry_writer *writer);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Bartosz Golaszewski @ 2024-03-25 14:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <87r0fy8lde.fsf@kernel.org>
On Mon, Mar 25, 2024 at 2:57 PM Kalle Valo <kvalo@kernel.org> wrote:
>
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
>
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > Add a PCI compatible for the ATH11K module on QCA6390 and describe the
> > power inputs from the PMU that it consumes.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> [...]
>
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: pci17cb,1101
> > + then:
> > + required:
> > + - vddrfacmn-supply
> > + - vddaon-supply
> > + - vddwlcx-supply
> > + - vddwlmx-supply
> > + - vddrfa0p8-supply
> > + - vddrfa1p2-supply
> > + - vddrfa1p7-supply
> > + - vddpcie0p9-supply
> > + - vddpcie1p8-supply
>
> I don't know DT well enough to know what the "required:" above means,
> but does this take into account that there are normal "plug&play" type
> of QCA6390 boards as well which don't need any DT settings?
>
Do they require a DT node though for some reason?
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Kalle Valo @ 2024-03-25 14:01 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, Catalin Marinas, Will Deacon,
Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven, Arnd Bergmann,
Neil Armstrong, Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov, linux-bluetooth, netdev,
devicetree, linux-kernel, linux-wireless, linux-arm-msm,
linux-arm-kernel, linux-pci, linux-pm, Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-6-brgl@bgdev.pl>
Bartosz Golaszewski <brgl@bgdev.pl> writes:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Add device-tree bindings for the ATH12K module found in the WCN7850
> package.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> .../bindings/net/wireless/qcom,ath12k.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
> new file mode 100644
> index 000000000000..c0aad4815953
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2024 Linaro Limited
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies ath12k wireless devices (PCIe)
> +
> +maintainers:
> + - Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
IMHO it would be better to have just driver maintainers listed here.
> + - Jeff Johnson <quic_jjohnson@quicinc.com>
> + - Kalle Valo <kvalo@kernel.org>
> +
> +description:
> + Qualcomm Technologies IEEE 802.11ax PCIe devices.
> +
> +properties:
> + compatible:
> + enum:
> + - pci17cb,1107 # WCN7850
> +
> + reg:
> + maxItems: 1
> +
> + vddaon-supply:
> + description: VDD_AON supply regulator handle
> +
> + vddwlcx-supply:
> + description: VDD_WLCX supply regulator handle
> +
> + vddwlmx-supply:
> + description: VDD_WLMX supply regulator handle
> +
> + vddrfacmn-supply:
> + description: VDD_RFA_CMN supply regulator handle
> +
> + vddrfa0p8-supply:
> + description: VDD_RFA_0P8 supply regulator handle
> +
> + vddrfa1p2-supply:
> + description: VDD_RFA_1P2 supply regulator handle
> +
> + vddrfa1p8-supply:
> + description: VDD_RFA_1P8 supply regulator handle
> +
> + vddpcie0p9-supply:
> + description: VDD_PCIE_0P9 supply regulator handle
> +
> + vddpcie1p8-supply:
> + description: VDD_PCIE_1P8 supply regulator handle
> +
> +required:
> + - compatible
> + - reg
> + - vddaon-supply
> + - vddwlcx-supply
> + - vddwlmx-supply
> + - vddrfacmn-supply
> + - vddrfa0p8-supply
> + - vddrfa1p2-supply
> + - vddrfa1p8-supply
> + - vddpcie0p9-supply
> + - vddpcie1p8-supply
Same comment here as in patch 4. There are also ath12k PCI devices which
don't need DT at all. I don't know if that should be reflected in the
bindings doc but I want to point out this.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] pinctrl/meson: fix typo in PDM's pin name
From: Neil Armstrong @ 2024-03-25 13:59 UTC (permalink / raw)
To: Jan Dakinevich, Linus Walleij, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20240325113058.248022-1-jan.dakinevich@salutedevices.com>
On 25/03/2024 12:30, Jan Dakinevich wrote:
> Other pins have _a or _x suffix, but this one doesn't have any. Most
> likely this is a typo.
>
> Fixes: dabad1ff8561 ("pinctrl: meson: add pinctrl driver support for Meson-A1 SoC")
> Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
> ---
> Links:
>
> [1] https://lore.kernel.org/lkml/20240314232201.2102178-1-jan.dakinevich@salutedevices.com/
>
> Changes:
> v1 -> v2: Detached from v1's series (patch 15)
>
> drivers/pinctrl/meson/pinctrl-meson-a1.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/meson/pinctrl-meson-a1.c b/drivers/pinctrl/meson/pinctrl-meson-a1.c
> index 79f5d753d7e1..50a87d9618a8 100644
> --- a/drivers/pinctrl/meson/pinctrl-meson-a1.c
> +++ b/drivers/pinctrl/meson/pinctrl-meson-a1.c
> @@ -250,7 +250,7 @@ static const unsigned int pdm_dclk_x_pins[] = { GPIOX_10 };
> static const unsigned int pdm_din2_a_pins[] = { GPIOA_6 };
> static const unsigned int pdm_din1_a_pins[] = { GPIOA_7 };
> static const unsigned int pdm_din0_a_pins[] = { GPIOA_8 };
> -static const unsigned int pdm_dclk_pins[] = { GPIOA_9 };
> +static const unsigned int pdm_dclk_a_pins[] = { GPIOA_9 };
>
> /* gen_clk */
> static const unsigned int gen_clk_x_pins[] = { GPIOX_7 };
> @@ -591,7 +591,7 @@ static struct meson_pmx_group meson_a1_periphs_groups[] = {
> GROUP(pdm_din2_a, 3),
> GROUP(pdm_din1_a, 3),
> GROUP(pdm_din0_a, 3),
> - GROUP(pdm_dclk, 3),
> + GROUP(pdm_dclk_a, 3),
> GROUP(pwm_c_a, 3),
> GROUP(pwm_b_a, 3),
>
> @@ -755,7 +755,7 @@ static const char * const spi_a_groups[] = {
>
> static const char * const pdm_groups[] = {
> "pdm_din0_x", "pdm_din1_x", "pdm_din2_x", "pdm_dclk_x", "pdm_din2_a",
> - "pdm_din1_a", "pdm_din0_a", "pdm_dclk",
> + "pdm_din1_a", "pdm_din0_a", "pdm_dclk_a",
> };
>
> static const char * const gen_clk_groups[] = {
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox