* Re: [PATCH] MAINTAINERS: adjust DRM DRIVERS FOR EXYNOS after dt-binding conversion
From: Krzysztof Kozlowski @ 2024-04-11 6:36 UTC (permalink / raw)
To: Lukas Bulwahn, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
dri-devel, devicetree
Cc: kernel-janitors, linux-kernel, Lukas Bulwahn
In-Reply-To: <20240411063000.48794-1-lukas.bulwahn@redhat.com>
On 11/04/2024 08:30, Lukas Bulwahn wrote:
> Commit ad6d17e10306 ("dt-bindings: display: samsung,exynos5-dp: convert to
> DT Schema") converts the last exynos display devicetree binding to json.
> With that, all exynos display devicetree bindings are now located in
> Documentation/devicetree/bindings/display/samsung/ and the directory with
> the previous txt devicetree bindings, i.e.,
> Documentation/devicetree/bindings/display/exynos/, has disappeared.
>
> Adjust the DRM DRIVERS FOR EXYNOS section to this change.
This should go via Rob's tree.
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: PCI: mediatek,mt7621: add missing child node reg
From: Sergio Paracuellos @ 2024-04-11 6:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Helgaas, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hector Martin, Sven Peter, Alyssa Rosenzweig,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Florian Fainelli, Jim Quinlan, Nicolas Saenz Julienne,
Will Deacon, Linus Walleij, Srikanth Thokala, Ryder Lee,
Jianjun Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Daire McNamara, Bjorn Andersson, Konrad Dybcio, Marek Vasut,
Yoshihiro Shimoda, Shawn Lin, Heiko Stuebner, Jingoo Han,
Gustavo Pimentel, Manivannan Sadhasivam, Bharat Kumar Gogada,
Michal Simek, Geert Uytterhoeven, Magnus Damm, Neil Armstrong,
Mark Kettenis, Tom Joseph, Ahmad Zainie, Jiaxun Yang,
Kishon Vijay Abraham I, Thippeswamy Havalige, linux-pci,
devicetree, linux-kernel, asahi, linux-arm-kernel,
linux-rpi-kernel, linux-mediatek, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <0336b752-ba98-497b-96d0-efc01ffbd93c@linaro.org>
On Thu, Apr 11, 2024 at 8:20 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 11/04/2024 08:13, Sergio Paracuellos wrote:
> >
> >>
> >> I think the question should be towards Mediatek folks. I don't know what
> >> this hardware is exactly, just looks like pci-pci-bridge. The driver
> >> calls the children host bridges as "ports".
> >
> > You can see the topology here in my first driver submit cover letter
> > message [0].
> >
>
> Useful diagram, thanks. It would be great if you could add it to the
> binding description.
Sure, I will do it depending on time hopefully sooner than later :-).
Best regards,
Sergio Paracuellos
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* RE: [EXT] Re: [PATCH v3 1/1] arm64: dts: imx93-11x11-evk: add rtc PCF2131 support
From: Joy Zou @ 2024-04-11 6:37 UTC (permalink / raw)
To: Marco Felsch
Cc: Jacky Bai, Frank Li, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240410074026.qjpk3sjhtbb6sw7j@pengutronix.de>
> -----Original Message-----
> From: Marco Felsch <m.felsch@pengutronix.de>
> Sent: 2024年4月10日 15:40
> To: Joy Zou <joy.zou@nxp.com>
> Cc: Jacky Bai <ping.bai@nxp.com>; robh+dt@kernel.org;
> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org;
> shawnguo@kernel.org; s.hauer@pengutronix.de; devicetree@vger.kernel.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; kernel@pengutronix.de; festevam@gmail.com;
> linux-arm-kernel@lists.infradead.org
> Subject: [EXT] Re: [PATCH v3 1/1] arm64: dts: imx93-11x11-evk: add rtc
> PCF2131 support
> On 24-04-10, Joy Zou wrote:
> > Support rtc PCF2131 on imx93-11x11-evk.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > ---
> > Changes in v3:
> > 1.adjust the indentation.
> >
> > Changes in v2:
> > 1. remove unnecessary status property.
> > ---
> > .../boot/dts/freescale/imx93-11x11-evk.dts | 24
> +++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > index 07e85a30a25f..73e0bca36b81 100644
> > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> > @@ -281,6 +281,23 @@ ldo5: LDO5 {
> > };
> > };
> >
> > +&lpi2c3 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + clock-frequency = <400000>;
> > + pinctrl-names = "default", "sleep";
> > + pinctrl-0 = <&pinctrl_lpi2c3>;
> > + pinctrl-1 = <&pinctrl_lpi2c3>;
>
> Are both "default" and "sleep" pinctrl's required? It doesn't make any sense
> to provde a sleep state which uses the same pinctrl state.
Thanks for your comments!
Currently, We only use default. Yeah, It's confused that a sleep state which uses the same pinctrl state.
So will remove the sleep.
BR
Joy Zou
>
> Regards,
> Marco
>
^ permalink raw reply
* Re: [PATCH v8 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Fenglin Wu @ 2024-04-11 6:41 UTC (permalink / raw)
To: Konrad Dybcio, kernel, Andy Gross, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree
In-Reply-To: <3f8c970c-6a0d-4fc3-a2d3-e0797e7055cf@linaro.org>
Hi Konrad,
On 4/11/2024 2:10 AM, Konrad Dybcio wrote:
>
>
>> -#define VIB_MAX_LEVEL_mV (3100)
>> -#define VIB_MIN_LEVEL_mV (1200)
>> -#define VIB_MAX_LEVELS (VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
>> +#define VIB_MAX_LEVEL_mV(vib) (vib->drv2_addr ? (3544) : (3100))
>
> You shouldn't need the additional inside parentheses
>
> Also, is this really a good discriminator for the voltage ranges? Do *all*
> PMIC vibrators with a drv2_addr operate within this range? If not, consider
> a struct field here
>
Currently, yes, all PMIC vibrators with a drv2_addr (PMI632, PM7250B,
PM7325B, PM7550BA) operate within the same range because they are the
same type.
>
>> +#define VIB_MIN_LEVEL_mV(vib) (vib->drv2_addr ? (1504) : (1200))
>> +#define VIB_MAX_LEVELS(vib) (VIB_MAX_LEVEL_mV(vib) -
>> VIB_MIN_LEVEL_mV(vib))
>
> If the ranges are supposed to be inclusive, this is off-by-one. But looking
> at the driver, it seems like MIN_LEVEL may be "off"? I'm not sure though.
>
> Either way, this would be a separate fix.
> [...]
The voltage range [1504, 3544] for the new SPMI vibrator is inclusive. I
checked the voltage range [1200 3100] for PM8916 SPMI vibrator is also
inclusive. I couldn't find any document to confirm if the SSBI vibrator
but I assume it is the same as PM8916. I will make change before the
series to address it.
Thanks for reviewing the changes!
Fenglin
^ permalink raw reply
* Re: [PATCH V4 0/3] Add reset controller driver for ums512
From: Stephen Boyd @ 2024-04-11 6:42 UTC (permalink / raw)
To: Baolin Wang, Chunyan Zhang, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Orson Zhai, Philipp Zabel, Rob Herring,
Zhifeng Tang
Cc: linux-clk, devicetree, linux-kernel, Zhifeng Tang, Wenming Wu
In-Reply-To: <20240123025613.3976-1-zhifeng.tang@unisoc.com>
Quoting Zhifeng Tang (2024-01-22 18:56:10)
> From: "zhifeng.tang" <zhifeng.tang@unisoc.com>
>
> In most of Sprd SOCs,The clock controller register block also
> contains reset bits for some of these peripherals,so reset
> controller and clock provider are combined together as a block,
> and put it under the driver/clk/.
>
> Changes in v4:
> - Add description why reset controller put it under the driver/clk/
Please use an auxiliary device and put the code almost entirely under
drivers/reset/. You can still have the data tables in the clk driver if
you want, but I don't see why an auxiliary device can't be used.
^ permalink raw reply
* Re: [PATCH net-next v2 3/5] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Romain Gantois @ 2024-04-11 6:49 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, Romain Gantois, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Clément Léger, Thomas Petazzoni,
netdev, devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel, Maxime Chevallier
In-Reply-To: <ZhbmVVXgu27ZZaNf@shell.armlinux.org.uk>
Hello Russell,
On Wed, 10 Apr 2024, Russell King (Oracle) wrote:
> patch as a theoretical solution to Romain. After build-testing it locally
> I did notice it. I would've thought that Romain would've build-tested
> before sending out his patch set and would've fixed it up... I didn't
> have time to properly fix up my patch (essentially would've ment
I build-tested the patches but didn't realize that CONFIG_DWMAC_SOCFPGA was not
enabled in my configuration. So that's my bad, sorry.
Best Regards,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sa8155p-adp: use correct gpio for SDHC2 CD
From: Stephan Gerhold @ 2024-04-11 6:51 UTC (permalink / raw)
To: Volodymyr Babchuk
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <87cyqw6fvh.fsf@epam.com>
On Wed, Apr 10, 2024 at 09:57:02PM +0000, Volodymyr Babchuk wrote:
> Stephan Gerhold <stephan@gerhold.net> writes:
> > On Wed, Apr 10, 2024 at 01:41:30PM +0000, Volodymyr Babchuk wrote:
> >> Card Detect pin for SHDC2 on SA8155P-ADP is connected to GPIO4 of
> >> PMM8155AU_1, not to internal TLMM. This change fixes two issues at
> >> once: not working ethernet (because GPIO4 is used for MAC TX) and SD
> >> detection.
> >>
> >> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/sa8155p-adp.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> >> index 5e4287f8c8cd1..6b08ce246b78c 100644
> >> --- a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> >> +++ b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> >> @@ -384,7 +384,7 @@ &remoteproc_cdsp {
> >> &sdhc_2 {
> >> status = "okay";
> >>
> >> - cd-gpios = <&tlmm 4 GPIO_ACTIVE_LOW>;
> >> + cd-gpios = <&pmm8155au_1_gpios 4 GPIO_ACTIVE_LOW>;
> >
> > Good catch!
>
> Yeah... It took time to understand why ethernet is not working
> sometimes. It appeared that there were race between SDHC and MAC
> initialization.
>
> >
> >> pinctrl-names = "default", "sleep";
> >> pinctrl-0 = <&sdc2_on>;
> >> pinctrl-1 = <&sdc2_off>;
> >
> > These two pinctrl configure "gpio96" for "sd-cd-pins". Yet another wrong
> > GPIO? Should probably drop that and add proper pinctrl for the actual
> > GPIO in the PMIC. Seems like Qualcomm configured the PMIC GPIO with
> > pull-up downstream [1] (not sure if this is the right file). It might be
> > redundant if there is an external pull-up on the board, but only the
> > schematic could tell that for sure.
>
> If I only had schematic for this board... gpio96 puzzles me as well. I
> can understand where wrong GPIO4 come from. But gpio96 origin is
> completely unclear. I have user manual for the board, it mention
> functions of some GPIOs, but there is nothing about gpio96. Anyways, I
> removed it from the DTS (see diff below) and I see no issues with SD card.
>
I believe this might have been mistakenly copied from some SM8150
example, there you can occasionally find cd-gpios defined as <&tlmm 96>.
E.g. in sm8150-pinctrl.dtsi downstream:
https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/484af352989c912db8f3b6393fc090006029066f/arch/arm64/boot/dts/qcom/sm8150-pinctrl.dtsi#L70-81
> > FWIW: Looking closer at the broken commit, the regulator voltage setup
> > of &sdhc_2 looks suspicious too. Typically one would want a 1.8V capable
> > regulator for the vqmmc-supply to properly use ultra high-speed modes,
> > but &vreg_l13c_2p96 seems to be configured with 2.504V-2.960V at the
> > moment. On downstream it seems to be 1.8V-2.96V [2] (again, not sure if
> > this is the right file). I would recommend re-checking this too and
> > testing if UHS cards are detected correctly (if you have the board).
>
> This is actually a good catch. I changed the voltage range to 1.8V-2.96V and
> now my card detects in UHS/SDR104 mode. Prior to this change it worked only
> in HS mode.
>
Yay!
> > &vreg_l17a_2p96 has the same 2.504V-2.960V, but has 2.704V-2.960V
> > downstream [3]. This is close at least, might be fine as-is (but I'm not
> > convinced there is a good reason to differ there).
> >
>
> Well, I believe that downstream configuration is more correct, but I
> can't prove it, so I'll leave it as is.
>
Ack.
> Diff for additional changes looks like this:
>
> diff --git a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> index 6b08ce246b78c..b2a3496ff68ad 100644
> --- a/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> +++ b/arch/arm64/boot/dts/qcom/sa8155p-adp.dts
> @@ -283,7 +283,7 @@ vreg_l12c_1p808: ldo12 {
>
> vreg_l13c_2p96: ldo13 {
> regulator-name = "vreg_l13c_2p96";
> - regulator-min-microvolt = <2504000>;
> + regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <2960000>;
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
> @@ -386,8 +386,8 @@ &sdhc_2 {
>
> cd-gpios = <&pmm8155au_1_gpios 4 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&sdc2_on>;
> - pinctrl-1 = <&sdc2_off>;
> + pinctrl-0 = <&sdc2_on &pmm8155au_1_sdc2_on>;
> + pinctrl-1 = <&sdc2_off &pmm8155au_1_sdc2_off>;
> vqmmc-supply = <&vreg_l13c_2p96>; /* IO line power */
> vmmc-supply = <&vreg_l17a_2p96>; /* Card power line */
> bus-width = <4>;
> @@ -505,13 +505,6 @@ data-pins {
> bias-pull-up; /* pull up */
> drive-strength = <16>; /* 16 MA */
> };
> -
> - sd-cd-pins {
> - pins = "gpio96";
> - function = "gpio";
> - bias-pull-up; /* pull up */
> - drive-strength = <2>; /* 2 MA */
> - };
> };
>
> sdc2_off: sdc2-off-state {
> @@ -532,13 +525,6 @@ data-pins {
> bias-pull-up; /* pull up */
> drive-strength = <2>; /* 2 MA */
> };
> -
> - sd-cd-pins {
> - pins = "gpio96";
> - function = "gpio";
> - bias-pull-up; /* pull up */
> - drive-strength = <2>; /* 2 MA */
> - };
> };
>
> usb2phy_ac_en1_default: usb2phy-ac-en1-default-state {
> @@ -604,3 +590,25 @@ phy-reset-pins {
> };
> };
> };
> +
> +&pmm8155au_1_gpios {
> + pmm8155au_1_sdc2_on: pmm8155au_1-sdc2-on-state {
> + sd-cd-pin {
> + pins = "gpio4";
> + function = "normal";
> + input-enable;
> + bias-pull-up;
> + power-source = <0>;
> + };
> + };
> +
> + pmm8155au_1_sdc2_off: pmm8155au_1-sdc2-off-state {
> + sd-cd-pin {
> + pins = "gpio4";
> + function = "normal";
> + input-enable;
> + bias-pull-up;
> + power-source = <0>;
> + };
> + };
Since the configuration is the same for both on and off state, you can
combine this into one node and then reference it twice. Also, the single
subnode should not be needed:
pmm8155au_1_sdc2_cd: pmm8155au_1-sdc2-cd-state {
pins = "gpio4";
function = "normal";
input-enable;
bias-pull-up;
power-source = <0>;
};
&sdhc_2 {
pinctrl-0 = <&sdc2_on &pmm8155au_1_sdc2_cd>;
pinctrl-1 = <&sdc2_off &pmm8155au_1_sdc2_cd>;
};
Looks good to me otherwise, thanks for cleaning this up!
>
> I am planning to send v2 tomorrow.
>
Thanks!
Stephan
^ permalink raw reply
* Re: [PATCH v5 0/2] Samsung Galaxy Z Fold5 initial support
From: Alexandru Serdeliuc @ 2024-04-11 6:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8f2c7963-c660-41b6-a93c-0ac19818ecda@linaro.org>
Hi,
The list of changes (changelog) from the cover is not what I should add?
My patches received only two ACK tags, on V3 and on the initial request
(v1), I was not able to identify any other, I added them to their place
in the change log
...
- v3
. added b4 version 3
. removed address and size cells in device description
Acked-by: Rob Herring<robh@kernel.org>
...
- v1
. The initial request was split in two patches sent due to the following checkpatch warning, was requested to re send them together:
WARNING: DT binding docs and includes should be a separate patch. See: Documentation/devicetree/bindings/submitting-patches.rst
Acked-by: Krzysztof Kozlowski<krzysztof.kozlowski@linaro.org>
I suppose that adding them to their place in change log is wrong, I
should create a v6 and put them at the end of the cover letter? Or how
to proceed?
Best regards,
Alexandru Marc Serdeliuc
On 11/4/24 8:03, Krzysztof Kozlowski wrote:
> On 10/04/2024 23:28, Alexandru Marc Serdeliuc via B4 Relay wrote:
>> This documents and add intial dts support for Samsung Galaxy Z Fold5 (samsung,q5q)
>> which is a foldable phone by Samsung based on the sm8550 SoC.
>>
>> ChangeLog
>>
>> - v5
>> . Added ChangeLog
>> . Added missing Acked-by tags in their respective section in ChangeLog
> Where? I cannot find anything.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v8 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support
From: Fenglin Wu @ 2024-04-11 6:58 UTC (permalink / raw)
To: Konrad Dybcio, kernel, Andy Gross, Bjorn Andersson,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, linux-kernel, devicetree
In-Reply-To: <3f8c970c-6a0d-4fc3-a2d3-e0797e7055cf@linaro.org>
Hi Konrad,
On 4/11/2024 2:10 AM, Konrad Dybcio wrote:
>
>
>> + if (regs->drv2_mask) {
>> + if (on)
>> + val = (vib->level << regs->drv2_shift) & regs->drv2_mask;
>> + else
>> + val = 0;
>> + rc = regmap_write(vib->regmap, vib->drv2_addr, val);
>
> Are you purposefuly zeroing out the other bits?
>
> If yes, consider regmap_write_bits here
> If not, consider regmap_update_bits here
>
>> + if (rc < 0)
>> + return rc;
>
> Ignore regmap_r/w errors, these mean a complete failure of the API and
> we don't generally assume MMIO accesses can fail
>
> Unless SPMI is known to have issues here
>
Sorry, forgot to reply on this comment. Yes, SPMI transaction would fail
(even with very low odds) on some boards if the layout of SPMI lines is
not good enough. I'd like to keep the consistence since the whole driver
also checks the regmap_r/w errors.
^ permalink raw reply
* [PATCH v3] media: mediatek: vcodec: support 36 bits physical address
From: Yunfei Dong @ 2024-04-11 7:01 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Nícolas F . R . A . Prado,
Nicolas Dufresne, Hans Verkuil, AngeloGioacchino Del Regno,
Benjamin Gaignard, Nathan Hebert, Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
The physical address on the MT8188 platform is larger than 32 bits,
change the type from unsigned int to dma_addr_t to be able to access
the high bits of the address.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
compared with v2:
- remove unless cast
---
.../media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c | 2 +-
.../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
index 9649f4ec1f2a..5f848691cea4 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
@@ -449,7 +449,7 @@ static int vdec_vp8_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
inst->frm_cnt, y_fb_dma, c_fb_dma, fb);
inst->cur_fb = fb;
- dec->bs_dma = (unsigned long)bs->dma_addr;
+ dec->bs_dma = bs->dma_addr;
dec->bs_sz = bs->size;
dec->cur_y_fb_dma = y_fb_dma;
dec->cur_c_fb_dma = c_fb_dma;
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
index cf48d09b78d7..eea709d93820 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
@@ -1074,7 +1074,7 @@ static int vdec_vp9_slice_setup_tile_buffer(struct vdec_vp9_slice_instance *inst
unsigned int mi_row;
unsigned int mi_col;
unsigned int offset;
- unsigned int pa;
+ dma_addr_t pa;
unsigned int size;
struct vdec_vp9_slice_tiles *tiles;
unsigned char *pos;
@@ -1109,7 +1109,7 @@ static int vdec_vp9_slice_setup_tile_buffer(struct vdec_vp9_slice_instance *inst
pos = va + offset;
end = va + bs->size;
/* truncated */
- pa = (unsigned int)bs->dma_addr + offset;
+ pa = bs->dma_addr + offset;
tb = instance->tile.va;
for (i = 0; i < rows; i++) {
for (j = 0; j < cols; j++) {
--
2.18.0
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Add USB-C orientation GPIO
From: Luca Weiss @ 2024-04-11 7:06 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
Define the USB-C orientation GPIOs so that the USB-C ports orientation
is known without having to resort to the altmode notifications.
On PCB level this is the signal from PM7250B (pin CC_OUT) which is
called USB_PHY_PS.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Depends on (for bindings): https://lore.kernel.org/linux-arm-msm/20240409-hdk-orientation-gpios-v2-0-658efd993987@linaro.org/
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 4ff9fc24e50e..f3432701945f 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -77,6 +77,8 @@ pmic-glink {
#address-cells = <1>;
#size-cells = <0>;
+ orientation-gpios = <&tlmm 140 GPIO_ACTIVE_HIGH>;
+
connector@0 {
compatible = "usb-c-connector";
reg = <0>;
---
base-commit: 65b0418f6e86eef0f62fc053fb3622fbaa3e506e
change-id: 20240411-fp5-usb-c-gpio-afd22741adcd
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply related
* Re: [PATCH v9 1/6] dt-bindings: clock: sophgo: Add clock controller of SG2000 series SoC
From: Stephen Boyd @ 2024-04-11 7:07 UTC (permalink / raw)
To: Albert Ou, Chao Wei, Chen Wang, Conor Dooley, Inochi Amaoto,
Krzysztof Kozlowski, Michael Turquette, Palmer Dabbelt,
Paul Walmsley, Rob Herring
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, linux-clk, devicetree,
linux-kernel, linux-riscv, Krzysztof Kozlowski
In-Reply-To: <IA1PR20MB495368F185E018767CC6714ABB262@IA1PR20MB4953.namprd20.prod.outlook.com>
Quoting Inochi Amaoto (2024-03-09 01:02:51)
> SG2000 series SoC has the same clock as CV1810 series, but the clock
> related to A53 is functional in SG2000 series. So a new compatible
> string is needed for the new SoC.
>
> Add definition for the clock controller of the SG2000 series SoC.
>
> Link: https://github.com/sophgo/sophgo-doc/releases/tag/sg2000-datasheet-v1.0-alpha
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v9 2/6] clk: sophgo: Add clock support for CV1800 SoC
From: Stephen Boyd @ 2024-04-11 7:07 UTC (permalink / raw)
To: Albert Ou, Chao Wei, Chen Wang, Conor Dooley, Inochi Amaoto,
Krzysztof Kozlowski, Michael Turquette, Palmer Dabbelt,
Paul Walmsley, Rob Herring
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, linux-clk, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB49534F37F802CAF117364D66BB262@IA1PR20MB4953.namprd20.prod.outlook.com>
Quoting Inochi Amaoto (2024-03-09 01:02:52)
> Add clock definition and driver code for CV1800 SoC.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> Link: https://github.com/milkv-duo/duo-files/blob/6f4e9b8ecb459e017cca1a8df248a19ca70837a3/duo/datasheet/CV180X-Clock-v1.xlsx
> Link: https://github.com/milkv-duo/duo-files/blob/6f4e9b8ecb459e017cca1a8df248a19ca70837a3/duo/datasheet/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v9 3/6] clk: sophgo: Add clock support for CV1810 SoC
From: Stephen Boyd @ 2024-04-11 7:07 UTC (permalink / raw)
To: Albert Ou, Chao Wei, Chen Wang, Conor Dooley, Inochi Amaoto,
Krzysztof Kozlowski, Michael Turquette, Palmer Dabbelt,
Paul Walmsley, Rob Herring
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, linux-clk, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB495357FB5EEA1623DAB08C94BB262@IA1PR20MB4953.namprd20.prod.outlook.com>
Quoting Inochi Amaoto (2024-03-09 01:02:53)
> Add clock definition and init code for CV1810 SoC.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> Link: https://github.com/milkv-duo/duo-files/blob/6f4e9b8ecb459e017cca1a8df248a19ca70837a3/duo/datasheet/CV180X-Clock-v1.xlsx
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v9 4/6] clk: sophgo: Add clock support for SG2000 SoC
From: Stephen Boyd @ 2024-04-11 7:07 UTC (permalink / raw)
To: Albert Ou, Chao Wei, Chen Wang, Conor Dooley, Inochi Amaoto,
Krzysztof Kozlowski, Michael Turquette, Palmer Dabbelt,
Paul Walmsley, Rob Herring
Cc: Jisheng Zhang, Liu Gui, Jingbao Qiu, dlan, linux-clk, devicetree,
linux-kernel, linux-riscv
In-Reply-To: <IA1PR20MB49537156E71B64483F15C0F2BB262@IA1PR20MB4953.namprd20.prod.outlook.com>
Quoting Inochi Amaoto (2024-03-09 01:02:54)
> Add init code for SG2000 SoC.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> Link: https://github.com/sophgo/sophgo-doc/releases/tag/sg2000-datasheet-v1.0-alpha
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v3] media: mediatek: vcodec: support 36 bits physical address
From: Hans Verkuil @ 2024-04-11 7:11 UTC (permalink / raw)
To: Yunfei Dong, Mauro Carvalho Chehab,
Nícolas F . R . A . Prado, Nicolas Dufresne,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240411070127.12384-1-yunfei.dong@mediatek.com>
Hi Yunfei,
Since the v2 patch is now merged in mainline as-is, you need to make a patch
on top of that.
So just post a new patch that applies to the mainline.
Regards,
Hans
On 11/04/2024 09:01, Yunfei Dong wrote:
> The physical address on the MT8188 platform is larger than 32 bits,
> change the type from unsigned int to dma_addr_t to be able to access
> the high bits of the address.
>
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> compared with v2:
> - remove unless cast
> ---
> .../media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c | 2 +-
> .../mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
> index 9649f4ec1f2a..5f848691cea4 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp8_if.c
> @@ -449,7 +449,7 @@ static int vdec_vp8_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
> inst->frm_cnt, y_fb_dma, c_fb_dma, fb);
>
> inst->cur_fb = fb;
> - dec->bs_dma = (unsigned long)bs->dma_addr;
> + dec->bs_dma = bs->dma_addr;
> dec->bs_sz = bs->size;
> dec->cur_y_fb_dma = y_fb_dma;
> dec->cur_c_fb_dma = c_fb_dma;
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
> index cf48d09b78d7..eea709d93820 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c
> @@ -1074,7 +1074,7 @@ static int vdec_vp9_slice_setup_tile_buffer(struct vdec_vp9_slice_instance *inst
> unsigned int mi_row;
> unsigned int mi_col;
> unsigned int offset;
> - unsigned int pa;
> + dma_addr_t pa;
> unsigned int size;
> struct vdec_vp9_slice_tiles *tiles;
> unsigned char *pos;
> @@ -1109,7 +1109,7 @@ static int vdec_vp9_slice_setup_tile_buffer(struct vdec_vp9_slice_instance *inst
> pos = va + offset;
> end = va + bs->size;
> /* truncated */
> - pa = (unsigned int)bs->dma_addr + offset;
> + pa = bs->dma_addr + offset;
> tb = instance->tile.va;
> for (i = 0; i < rows; i++) {
> for (j = 0; j < cols; j++) {
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: usb: add common Type-C USB Switch schema
From: Luca Weiss @ 2024-04-11 7:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Neil Armstrong, linux-usb, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <20240122094406.32198-1-krzysztof.kozlowski@linaro.org>
On Mon Jan 22, 2024 at 10:44 AM CET, Krzysztof Kozlowski wrote:
> Several bindings implement parts of Type-C USB orientation and mode
> switching, and retiming. Keep definition of such properties in one
> place, new usb-switch schema, to avoid duplicate defines.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> ---
>
> Changes in v2:
> 1. Fix language typos handle->handler (Luca)
> 2. Drop debugging left-over (Luca)
> ---
> .../devicetree/bindings/usb/fcs,fsa4480.yaml | 12 ++--
> .../devicetree/bindings/usb/gpio-sbu-mux.yaml | 12 ++--
> .../devicetree/bindings/usb/nxp,ptn36502.yaml | 12 ++--
> .../bindings/usb/onnn,nb7vpq904m.yaml | 13 ++--
> .../bindings/usb/qcom,wcd939x-usbss.yaml | 12 ++--
> .../devicetree/bindings/usb/usb-switch.yaml | 67 +++++++++++++++++++
> 6 files changed, 92 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/usb-switch.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> index f9410eb76a62..8b25b9a01ced 100644
> --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> @@ -27,13 +27,8 @@ properties:
> vcc-supply:
> description: power supply (2.7V-5.5V)
>
> - mode-switch:
> - description: Flag the port as possible handle of altmode switching
> - type: boolean
> -
> - orientation-switch:
> - description: Flag the port as possible handler of orientation switching
> - type: boolean
> + mode-switch: true
> + orientation-switch: true
>
> port:
> $ref: /schemas/graph.yaml#/$defs/port-base
> @@ -79,6 +74,9 @@ required:
> - reg
> - port
>
> +allOf:
> + - $ref: usb-switch.yaml#
> +
> additionalProperties: false
>
> examples:
Hi Krzysztof,
This patch seems to break validation for fsa4480 if data-lanes is set in
the endpoint like the following
diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
index f9410eb76a62..3aa03fd65556 100644
--- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
+++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
@@ -102,6 +102,7 @@ examples:
port {
fsa4480_ept: endpoint {
remote-endpoint = <&typec_controller>;
+ data-lanes = <0 1>;
};
};
};
Similar to how it's already used on qcom/qcm6490-fairphone-fp5.dts
I'm guessing the 'port' definition in the common schema somehow
disallows the fsa4480 schema from describing it further?
Regards
Luca
> diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> index d3b2b666ec2a..88e1607cf053 100644
> --- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> @@ -33,13 +33,8 @@ properties:
> vcc-supply:
> description: power supply
>
> - mode-switch:
> - description: Flag the port as possible handle of altmode switching
> - type: boolean
> -
> - orientation-switch:
> - description: Flag the port as possible handler of orientation switching
> - type: boolean
> + mode-switch: true
> + orientation-switch: true
>
> port:
> $ref: /schemas/graph.yaml#/properties/port
> @@ -54,6 +49,9 @@ required:
> - orientation-switch
> - port
>
> +allOf:
> + - $ref: usb-switch.yaml#
> +
> additionalProperties: false
>
> examples:
> diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
> index eee548ac1abe..d805dde80796 100644
> --- a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
> +++ b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
> @@ -20,13 +20,8 @@ properties:
> vdd18-supply:
> description: Power supply for VDD18 pin
>
> - retimer-switch:
> - description: Flag the port as possible handle of SuperSpeed signals retiming
> - type: boolean
> -
> - orientation-switch:
> - description: Flag the port as possible handler of orientation switching
> - type: boolean
> + orientation-switch: true
> + retimer-switch: true
>
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
> @@ -49,6 +44,9 @@ required:
> - compatible
> - reg
>
> +allOf:
> + - $ref: usb-switch.yaml#
> +
> additionalProperties: false
>
> examples:
> diff --git a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
> index c0201da002f6..589914d22bf2 100644
> --- a/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
> +++ b/Documentation/devicetree/bindings/usb/onnn,nb7vpq904m.yaml
> @@ -21,14 +21,8 @@ properties:
> description: power supply (1.8V)
>
> enable-gpios: true
> -
> - retimer-switch:
> - description: Flag the port as possible handle of SuperSpeed signals retiming
> - type: boolean
> -
> - orientation-switch:
> - description: Flag the port as possible handler of orientation switching
> - type: boolean
> + orientation-switch: true
> + retimer-switch: true
>
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
> @@ -95,6 +89,9 @@ required:
> - compatible
> - reg
>
> +allOf:
> + - $ref: usb-switch.yaml#
> +
> additionalProperties: false
>
> examples:
> diff --git a/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml
> index 7ddfd3313a18..96346723f3e9 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,wcd939x-usbss.yaml
> @@ -35,13 +35,8 @@ properties:
> vdd-supply:
> description: USBSS VDD power supply
>
> - mode-switch:
> - description: Flag the port as possible handle of altmode switching
> - type: boolean
> -
> - orientation-switch:
> - description: Flag the port as possible handler of orientation switching
> - type: boolean
> + mode-switch: true
> + orientation-switch: true
>
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
> @@ -63,6 +58,9 @@ required:
> - reg
> - ports
>
> +allOf:
> + - $ref: usb-switch.yaml#
> +
> additionalProperties: false
>
> examples:
> diff --git a/Documentation/devicetree/bindings/usb/usb-switch.yaml b/Documentation/devicetree/bindings/usb/usb-switch.yaml
> new file mode 100644
> index 000000000000..da76118e73a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-switch.yaml
> @@ -0,0 +1,67 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/usb-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: USB Orientation and Mode Switches Common Properties
> +
> +maintainers:
> + - Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> +
> +description:
> + Common properties for devices handling USB mode and orientation switching.
> +
> +properties:
> + mode-switch:
> + description: Possible handler of altmode switching
> + type: boolean
> +
> + orientation-switch:
> + description: Possible handler of orientation switching
> + type: boolean
> +
> + retimer-switch:
> + description: Possible handler of SuperSpeed signals retiming
> + type: boolean
> +
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + A port node to link the device to a TypeC controller for the purpose of
> + handling altmode muxing and orientation switching.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Super Speed (SS) Output endpoint to the Type-C connector
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description:
> + Super Speed (SS) Input endpoint from the Super-Speed PHY
> + unevaluatedProperties: false
> +
> + properties:
> + endpoint:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 8
> + uniqueItems: true
> + items:
> + maximum: 8
> +
> +oneOf:
> + - required:
> + - port
> + - required:
> + - ports
> +
> +additionalProperties: true
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Lee Jones @ 2024-04-11 7:13 UTC (permalink / raw)
To: Gergo Koteles
Cc: Ike Panhc, Hans de Goede, Ilpo Järvinen, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <8ac95e85a53dc0b8cce1e27fc1cab6d19221543b.1712063200.git.soyer@irl.hu>
On Tue, 02 Apr 2024, Gergo Koteles wrote:
> Newer laptops have FnLock LED.
>
> Add a define for this very common function.
>
> Signed-off-by: Gergo Koteles <soyer@irl.hu>
> ---
> include/dt-bindings/leds/common.h | 1 +
> 1 file changed, 1 insertion(+)
Hans,
You can take this in via the x86 tree, but please capitalise the first
letter of the subject line when doing so.
dt-bindings: leds: Add LED_FUNCTION_FNLOCK
Acked-by: Lee Jones <lee@kernel.org>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH V3 2/3] clk: sprd: Add reset controller driver for ums512
From: Stephen Boyd @ 2024-04-11 7:18 UTC (permalink / raw)
To: tang zhifeng
Cc: Baolin Wang, Chunyan Zhang, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Orson Zhai, Philipp Zabel, Rob Herring,
Zhifeng Tang, linux-clk, devicetree, linux-kernel, Wenming Wu
In-Reply-To: <CAPUP7E7RmfOpN4C+BZT-52OeLe349NY_XPaj6HaiG_O42r9n9g@mail.gmail.com>
Quoting tang zhifeng (2024-01-15 18:10:45)
>
> Dear Stephen
> We clock controller register block also contains reset bits for some of these
> peripherals，
> so reset controller and clock provider are combined together as a block,and put
> it under the driver/clk/.
> Under driver/clk/, we can also see that other manufacturers support reset
> controller。
I still don't see any reason why it can't be an auxiliary device and the
reset driver put in drivers/reset/
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium, pn-swap' property
From: Alexandru Ardelean @ 2024-04-11 7:23 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <dxm3js6qpcw3n4duid4vmhnkxacmzgq4rnvpbdx62pcn34ybzc@q57pst7lyumf>
On Sun, Apr 7, 2024 at 11:31 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote:
> > On some HW designs, it's easier for the layout if the P/N pins are swapped.
> > The driver currently has a DT property to do that.
> >
> > This change documents the 'lontium,pn-swap' property.
> >
> > Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> > ---
> > .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > index 2cef252157985..3a804926b288a 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> > @@ -24,6 +24,12 @@ properties:
> > maxItems: 1
> > description: GPIO connected to active high RESET pin.
> >
> > + lontium,pn-swap:
> > + description: Swap the polarities of the P/N pins in software.
> > + On some HW designs, the layout is simplified if the P/N pins
> > + are inverted.
> > + type: boolean
> > +
>
> I'd like to point out the standard `lane-polarities` property defined at
> Documentation/devicetree/bindings/media/video-interfaces.yaml. You can
> define and use it for the corresponding endpoint in the lt8912b schema.
>
Ohhh.
Interesting :)
Many thanks for pointing this out.
This will make things much easier.
Will do a V2 with this in a week or two.
I'm traveling now.
Thanks
Alex
> > ports:
> > $ref: /schemas/graph.yaml#/properties/ports
> >
> > --
> > 2.44.0
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: clock: Add Loongson-2K expand clock index
From: Stephen Boyd @ 2024-04-11 7:23 UTC (permalink / raw)
To: Binbin Zhou, Binbin Zhou, Conor Dooley, Huacai Chen,
Krzysztof Kozlowski, Michael Turquette, Rob Herring, Yinbo Zhu
Cc: Huacai Chen, loongson-kernel, linux-clk, devicetree, Xuerui Wang,
loongarch, Binbin Zhou, Conor Dooley
In-Reply-To: <76844e0e4dae290425f7c8025f7f36810cb3a3a8.1712731524.git.zhoubinbin@loongson.cn>
Quoting Binbin Zhou (2024-04-10 19:58:06)
> In the new Loongson-2K family of SoCs, more clock indexes are needed,
> such as clock gates.
> The patch adds these clock indexes
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH 07/10] riscv: add ISA extension parsing for Zcmop
From: Clément Léger @ 2024-04-11 7:25 UTC (permalink / raw)
To: Deepak Gupta, Conor Dooley
Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Rob Herring, Krzysztof Kozlowski, Anup Patel, Shuah Khan,
Atish Patra, linux-doc, linux-riscv, linux-kernel, devicetree,
kvm, kvm-riscv, linux-kselftest
In-Reply-To: <ZhcTiakvfbjb2hon@debug.ba.rivosinc.com>
On 11/04/2024 00:32, Deepak Gupta wrote:
> On Wed, Apr 10, 2024 at 11:27:16PM +0100, Conor Dooley wrote:
>> On Wed, Apr 10, 2024 at 11:16:11PM +0100, Conor Dooley wrote:
>>> On Wed, Apr 10, 2024 at 02:32:41PM -0700, Deepak Gupta wrote:
>>> > On Wed, Apr 10, 2024 at 11:11:00AM +0200, Clément Léger wrote:
>>> > > Add parsing for Zcmop ISA extension which was ratified in commit
>>> > > b854a709c00 ("Zcmop is ratified/1.0") of the riscv-isa-manual.
>>> > >
>>> > > Signed-off-by: Clément Léger <cleger@rivosinc.com>
>>> > > ---
>>> > > arch/riscv/include/asm/hwcap.h | 1 +
>>> > > arch/riscv/kernel/cpufeature.c | 1 +
>>> > > 2 files changed, 2 insertions(+)
>>> > >
>>> > > diff --git a/arch/riscv/include/asm/hwcap.h
>>> b/arch/riscv/include/asm/hwcap.h
>>> > > index b7551bad341b..cff7660de268 100644
>>> > > --- a/arch/riscv/include/asm/hwcap.h
>>> > > +++ b/arch/riscv/include/asm/hwcap.h
>>> > > @@ -86,6 +86,7 @@
>>> > > #define RISCV_ISA_EXT_ZCB 77
>>> > > #define RISCV_ISA_EXT_ZCD 78
>>> > > #define RISCV_ISA_EXT_ZCF 79
>>> > > +#define RISCV_ISA_EXT_ZCMOP 80
>>> > >
>>> > > #define RISCV_ISA_EXT_XLINUXENVCFG 127
>>> > >
>>> > > diff --git a/arch/riscv/kernel/cpufeature.c
>>> b/arch/riscv/kernel/cpufeature.c
>>> > > index 09dee071274d..f1450cd7231e 100644
>>> > > --- a/arch/riscv/kernel/cpufeature.c
>>> > > +++ b/arch/riscv/kernel/cpufeature.c
>>> > > @@ -265,6 +265,7 @@ const struct riscv_isa_ext_data
>>> riscv_isa_ext[] = {
>>> > > __RISCV_ISA_EXT_DATA(zcb, RISCV_ISA_EXT_ZCB),
>>> > > __RISCV_ISA_EXT_DATA(zcd, RISCV_ISA_EXT_ZCD),
>>> > > __RISCV_ISA_EXT_DATA(zcf, RISCV_ISA_EXT_ZCF),
>>> > > + __RISCV_ISA_EXT_DATA(zcmop, RISCV_ISA_EXT_ZCMOP),
>>> >
>>> > As per spec zcmop is dependent on zca. So perhaps below ?
>>> >
>>> > __RISCV_ISA_EXT_SUPERSET(zicboz, RISCV_ISA_EXT_ZCMOP,
>>> RISCV_ISA_EXT_ZCA)
>>>
>>> What's zicboz got to do with it, copy-pasto I guess?
>
> Yes, copy-pasta :-)
>
>>> If we're gonna imply stuff like this though I think we need some
>>> comments explaining why it's okay.
>>
>> Also, I'm inclined to call that out specifically in the binding, I've
>> not yet checked if dependencies actually work for elements of a string
>> array like the do for individual properties. I'll todo list that..
>
> Earlier examples of specifying dependency on envcfg actually had functional
> use case.
> So you are right, I am not sure if its actually needed in this
> particular case.
I actually saw that and think about addressing it but AFAICT, this
should be handled by the machine firmware passing the isa string to the
kernel (ie, it should be valid). In the case of QEMU, it takes care of
setting the extension that are required by this extension itself.
If we consider to have potentially broken isa string (ie extensions
dependencies not correctly handled), then we'll need some way to
validate this within the kernel.
Clément
>
> And yes definitley, dependency should be mentioned in binding.
>
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: usb: add common Type-C USB Switch schema
From: Krzysztof Kozlowski @ 2024-04-11 7:25 UTC (permalink / raw)
To: Luca Weiss, Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Neil Armstrong,
linux-usb, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <D0H3VE6RLM2I.MK2NT1P9N02O@fairphone.com>
On 11/04/2024 09:13, Luca Weiss wrote:
> On Mon Jan 22, 2024 at 10:44 AM CET, Krzysztof Kozlowski wrote:
>> Several bindings implement parts of Type-C USB orientation and mode
>> switching, and retiming. Keep definition of such properties in one
>> place, new usb-switch schema, to avoid duplicate defines.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> ---
>>
>> Changes in v2:
>> 1. Fix language typos handle->handler (Luca)
>> 2. Drop debugging left-over (Luca)
>> ---
>> .../devicetree/bindings/usb/fcs,fsa4480.yaml | 12 ++--
>> .../devicetree/bindings/usb/gpio-sbu-mux.yaml | 12 ++--
>> .../devicetree/bindings/usb/nxp,ptn36502.yaml | 12 ++--
>> .../bindings/usb/onnn,nb7vpq904m.yaml | 13 ++--
>> .../bindings/usb/qcom,wcd939x-usbss.yaml | 12 ++--
>> .../devicetree/bindings/usb/usb-switch.yaml | 67 +++++++++++++++++++
>> 6 files changed, 92 insertions(+), 36 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-switch.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> index f9410eb76a62..8b25b9a01ced 100644
>> --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
>> @@ -27,13 +27,8 @@ properties:
>> vcc-supply:
>> description: power supply (2.7V-5.5V)
>>
>> - mode-switch:
>> - description: Flag the port as possible handle of altmode switching
>> - type: boolean
>> -
>> - orientation-switch:
>> - description: Flag the port as possible handler of orientation switching
>> - type: boolean
>> + mode-switch: true
>> + orientation-switch: true
>>
>> port:
>> $ref: /schemas/graph.yaml#/$defs/port-base
>> @@ -79,6 +74,9 @@ required:
>> - reg
>> - port
>>
>> +allOf:
>> + - $ref: usb-switch.yaml#
>> +
>> additionalProperties: false
>>
>> examples:
>
> Hi Krzysztof,
>
> This patch seems to break validation for fsa4480 if data-lanes is set in
> the endpoint like the following
>
> diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> index f9410eb76a62..3aa03fd65556 100644
> --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml
> @@ -102,6 +102,7 @@ examples:
> port {
> fsa4480_ept: endpoint {
> remote-endpoint = <&typec_controller>;
> + data-lanes = <0 1>;
> };
> };
> };
>
> Similar to how it's already used on qcom/qcm6490-fairphone-fp5.dts
>
> I'm guessing the 'port' definition in the common schema somehow
> disallows the fsa4480 schema from describing it further?
There is no such code in qcm6490-fairphone-fp5.dts. There was no such
code in the example of fsa4480 when I was testing my changes (and
examples should be complete), so this did not pop up.
You right, new schema does not allow extending the port. However the
true question is, why muxing happens on the port to the SoC controller?
The graph in commit msg fad89aa14 shows it happens on the side of the
connector.
Looks like fsa4480 mixes connector with the controller.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/6] clk: clk-loongson2: Refactor driver for adding new platforms
From: Stephen Boyd @ 2024-04-11 7:28 UTC (permalink / raw)
To: Binbin Zhou, Binbin Zhou, Conor Dooley, Huacai Chen,
Krzysztof Kozlowski, Michael Turquette, Rob Herring, Yinbo Zhu
Cc: Huacai Chen, loongson-kernel, linux-clk, devicetree, Xuerui Wang,
loongarch, Binbin Zhou
In-Reply-To: <fb020d1ca19e6f4cdcc95c87b2748869ca76b8ec.1712731524.git.zhoubinbin@loongson.cn>
Quoting Binbin Zhou (2024-04-10 19:58:07)
> The driver only supported loongson-2K1000 at first, but the clock
> structure of loongson-2K0500 and loongson-2K2000 are actually similar,
> and I tried to refactor the whole driver to adjust to the addition of
> the new platform.
>
> Briefly, I have divided all clocks into three categories according to
> their properties and their parent clocks: Independent PLLs, clocks based
> on frequency scales, and clock dividers.
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> drivers/clk/clk-loongson2.c | 459 ++++++++++++++++--------------------
> 1 file changed, 199 insertions(+), 260 deletions(-)
>
> diff --git a/drivers/clk/clk-loongson2.c b/drivers/clk/clk-loongson2.c
> index bacdcbb287ac..ff2ade6a471a 100644
> --- a/drivers/clk/clk-loongson2.c
> +++ b/drivers/clk/clk-loongson2.c
> @@ -6,6 +6,7 @@
>
> #include <linux/err.h>
> #include <linux/init.h>
> +#include <linux/clk.h>
Why is this included? I removed it and applied to clk-next.
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: clock: loongson2: Add Loongson-2K0500 compatible
From: Stephen Boyd @ 2024-04-11 7:29 UTC (permalink / raw)
To: Binbin Zhou, Binbin Zhou, Conor Dooley, Huacai Chen,
Krzysztof Kozlowski, Michael Turquette, Rob Herring, Yinbo Zhu
Cc: Huacai Chen, loongson-kernel, linux-clk, devicetree, Xuerui Wang,
loongarch, Binbin Zhou, Conor Dooley
In-Reply-To: <c4784102d2bb8bf6982799babe39d5827235461d.1712731524.git.zhoubinbin@loongson.cn>
Quoting Binbin Zhou (2024-04-10 19:58:08)
> Add the devicetree compatible for Loongson-2K0500 clocks.
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
Applied to clk-next
^ 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