Re: [PATCH v5, 2/4] soc: mediatek: mmsys: add component POSTMASK
Hi Yongqiang,
Thank you for your patch.
Missatge de Yongqiang Niu del dia dl., 12
d’abr. 2021 a les 16:05:
>
> This patch add component POSTMASK
>
> Signed-off-by: Yongqiang Niu
Reviewed-by: Enric Balletbo i Serra
> ---
> include/linux/soc/mediatek/mtk-mmsys.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index f6b58f9..7718cd6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL_2L1,
> DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_POSTMASK0,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> DDP_COMPONENT_PWM2,
> --
> 1.8.1.1.dirty
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 1/4] soc: mediatek: mmsys: add component OVL_2L2
Hi Yongqiang,
Thank you for your patch.
Missatge de Yongqiang Niu del dia dl., 12
d’abr. 2021 a les 16:04:
>
> This patch add component OVL_2L2
>
> Signed-off-by: Yongqiang Niu
> Reviewed-by: Chun-Kuang Hu
Reviewed-by: Enric Balletbo i Serra
> ---
> include/linux/soc/mediatek/mtk-mmsys.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 2228bf6..f6b58f9 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL_2L0,
> DDP_COMPONENT_OVL_2L1,
> + DDP_COMPONENT_OVL_2L2,
> DDP_COMPONENT_OVL1,
> DDP_COMPONENT_PWM0,
> DDP_COMPONENT_PWM1,
> --
> 1.8.1.1.dirty
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 15 d’abr.
2021 a les 11:37:
>
> Kenzo is known as Acer Chromebook 311.
>
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/Makefile| 1 +
> .../boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts | 12
> 2 files changed, 13 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index b33d0bc58021..25770d83059d 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) +=
> mt8183-kukui-jacuzzi-burnet.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kenzo.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
> new file mode 100644
> index ..6f1aa692753a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kenzo.dts
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-juniper.dtsi"
> +
> +/ {
> + model = "Google kenzo sku17 board";
> + compatible = "google,juniper-sku17", "google,juniper",
> "mediatek,mt8183";
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 7/8] arm64: dts: mt8183: Add kukui-jacuzzi-burnet board
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 15 d’abr.
2021 a les 11:36:
>
> Burnet is known as HP Chromebook x360 11MK G3 EE
>
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../mediatek/mt8183-kukui-jacuzzi-burnet.dts | 33 +++
> 2 files changed, 34 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 5f43bbc2ea72..b33d0bc58021 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-hana-rev7.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-burnet.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
> new file mode 100644
> index ..b97ca331970e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-burnet.dts
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> + model = "Google burnet board";
> + compatible = "google,burnet", "mediatek,mt8183";
> +};
> +
> +&mt6358codec {
> + mediatek,dmic-mode = <1>; /* one-wire */
> +};
> +
> +&i2c0 {
> + touchscreen@2c {
> + compatible = "hid-over-i2c";
> + reg = <0x2c>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&touchscreen_pins>;
> + interrupts-extended = <&pio 155 IRQ_TYPE_LEVEL_LOW>;
> +
> + post-power-on-delay-ms = <200>;
> + hid-descr-addr = <0x0020>;
> + };
> +};
> +
> +&i2c2 {
> + clock-stretch-ns = <4100>;
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 6/8] arm64: dts: mt8183: Add kukui-jacuzzi-willow board
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 15 d’abr.
2021 a les 11:38:
>
> Willow is known as Acer Chromebook 311 (C722/C722T)
>
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 2 ++
> .../mt8183-kukui-jacuzzi-willow-sku0.dts | 13 +
> .../mt8183-kukui-jacuzzi-willow-sku1.dts | 12
> .../mediatek/mt8183-kukui-jacuzzi-willow.dtsi | 28 +++
> 4 files changed, 55 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index df70674949ce..5f43bbc2ea72 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -16,6 +16,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku0.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-willow-sku1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
> diff --git
> a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> new file mode 100644
> index ..281265f082db
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku0.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-willow.dtsi"
> +
> +/ {
> + model = "Google willow board sku0";
> + compatible = "google,willow-sku0", "google,willow", "mediatek,mt8183";
> +};
> +
> diff --git
> a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> new file mode 100644
> index ..22e56bdc1ee3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow-sku1.dts
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi-willow.dtsi"
> +
> +/ {
> + model = "Google willow board sku1";
> + compatible = "google,willow-sku1", "google,willow", "mediatek,mt8183";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
> new file mode 100644
> index ..3204c1abc4ee
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-willow.dtsi
> @@ -0,0 +1,28 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +&i2c2 {
> + clock-stretch-ns = <9500>;
> +
> + trackpad@2c {
> + compatible = "hid-over-i2c";
> + reg = <0x2c>;
> + hid-descr-addr = <0x20>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&trackpad_pins>;
> +
> + interrupts-extended = <&pio 7 IRQ_TYPE_LEVEL_LOW>;
> +
> + wakeup-source;
> + };
> +};
> +
> +&qca_wifi {
> + qcom,ath10k-calibration-variant = "GO_JUNIPER";
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 5/8] arm64: dts: mt8183: Add kukui-jacuzzi-kappa board
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 15 d’abr.
2021 a les 11:36:
>
> Kappa is known as HP Chromebook 11a
>
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/Makefile| 1 +
> .../dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts | 16
> 2 files changed, 17 insertions(+)
> create mode 100644
> arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index a1c50adc98fa..df70674949ce 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -15,6 +15,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-damu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-juniper-sku16.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-jacuzzi-kappa.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kakadu.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku16.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-kodama-sku272.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> new file mode 100644
> index ..b3f46c16e5d7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-kappa.dts
> @@ -0,0 +1,16 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> + model = "Google kappa board";
> + compatible = "google,kappa", "mediatek,mt8183";
> +};
> +
> +&mt6358codec {
> + mediatek,dmic-mode = <1>; /* one-wire */
> +};
> --
> 2.31.1.295.g9ea45b61b8-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 4/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kenzo
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Kenzo is known as Acer Chromebook 311. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 0870490aa350..39e4a99ebb37 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -137,9 +137,11 @@ properties: > items: >- const: google,damu >- const: mediatek,mt8183 > - - description: Google Juniper (Acer Chromebook Spin 311) > + - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer > Crhomebook 311) > items: > - - const: google,juniper-sku16 > + - enum: > + - google,juniper-sku16 > + - google,juniper-sku17 >- const: google,juniper >- const: mediatek,mt8183 >- description: Google Kakadu (ASUS Chromebook Detachable CM3) > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 3/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-burnet
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Burnet is known as HP Chromebook x360 11MK G3 EE. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 96c401597bd8..0870490aa350 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -122,6 +122,10 @@ properties: >- enum: >- mediatek,mt8195-evb >- const: mediatek,mt8195 > + - description: Google Burnet (HP Chromebook x360 11MK G3 EE) > +items: > + - const: google,burnet > + - const: mediatek,mt8183 >- description: Google Krane (Lenovo IdeaPad Duet, 10e,...) > items: >- enum: > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-willow
Hi Hsin-Yi. Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Willow is known as Acer Chromebook 311 (C722/C722T). > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index 81b86b189a8d..96c401597bd8 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -157,6 +157,13 @@ properties: >- google,kodama-sku32 >- const: google,kodama >- const: mediatek,mt8183 > + - description: Google Willow (Acer Chromebook 311 C722/C722T) > +items: > + - enum: > + - google,willow-sku0 > + - google,willow-sku1 > + - const: google,willow > + - const: mediatek,mt8183 >- items: >- enum: >- mediatek,mt8183-pumpkin > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 1/8] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-kappa
Hi Hsin-Yi, Thank you for your patch. Missatge de Hsin-Yi Wang del dia dj., 15 d’abr. 2021 a les 11:36: > > Kappa is known as HP Chromebook 11a. > > Signed-off-by: Hsin-Yi Wang Reviewed-by: Enric Balletbo i Serra > --- > Documentation/devicetree/bindings/arm/mediatek.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml > b/Documentation/devicetree/bindings/arm/mediatek.yaml > index aff57a8c8c30..81b86b189a8d 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml > @@ -144,6 +144,10 @@ properties: >- const: google,kakadu-rev2 >- const: google,kakadu >- const: mediatek,mt8183 > + - description: Google Kappa (HP Chromebook 11a) > +items: > + - const: google,kappa > + - const: mediatek,mt8183 >- description: Google Kodama (Lenovo 10e Chromebook Tablet) > items: >- enum: > -- > 2.31.1.295.g9ea45b61b8-goog > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/3] arm64: dts: mt8183: fix dtbs_check warning
Hi Matthias,
Thank you for your patch.
Missatge de l'adreça del dia dc., 14 d’abr.
2021 a les 16:48:
>
> From: Matthias Brugger
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 0ff7b67a6806..c5e822b6b77a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -681,13 +681,13 @@ cpu_thermal: cpu_thermal {
> sustainable-power = <5000>;
>
> trips {
> - threshold: trip-point@0 {
> + threshold: trip-point0 {
> temperature = <68000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - target: trip-point@1 {
> + target: trip-point1 {
> temperature = <8>;
> hysteresis = <2000>;
> type = "passive";
> @@ -1103,7 +1103,7 @@ u2port0: usb-phy@0 {
> status = "okay";
> };
>
> - u3port0: usb-phy@0700 {
> + u3port0: usb-phy@700 {
> reg = <0x0700 0x900>;
> clocks = <&clk26m>;
> clock-names = "ref";
> --
> 2.30.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Reviewed-by: Enric Balletbo i Serra
Re: [PATCH 1/3] arm64: dts: mt8183-pumpkin: fix dtbs_check warning
Hi Matthias,
Thank you for your patch.
Missatge de l'adreça del dia dc., 14 d’abr.
2021 a les 16:48:
>
> From: Matthias Brugger
>
> Fix unit names to make dtbs_check happy.
>
> Signed-off-by: Matthias Brugger
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> index eb6e595c2975..0aff5eb52e88 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-pumpkin.dts
> @@ -32,7 +32,7 @@ reserved-memory {
> #size-cells = <2>;
> ranges;
>
> - scp_mem_reserved: scp_mem_region {
> + scp_mem_reserved: scp_mem_region@5000 {
> compatible = "shared-dma-pool";
> reg = <0 0x5000 0 0x290>;
> no-map;
> @@ -55,7 +55,7 @@ led-green {
> };
> };
>
> - ntc@0 {
> + ntc {
> compatible = "murata,ncp03wf104";
> pullup-uv = <180>;
> pullup-ohm = <39>;
> --
> 2.30.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Reviewed-by: Enric Balletbo i Serra
Re: [PATCH] platform/chrome: cros_ec_typec: Handle hard reset
Hi Prashant,
Thank you for your patch.
Missatge de Prashant Malani del dia dj., 15
d’abr. 2021 a les 4:15:
>
> The Chrome Embedded Controller (EC) generates a hard reset type C event
> when a USB Power Delivery (PD) hard reset is encountered. Handle this
> event by unregistering the partner and cable on the associated port and
> clearing the event flag.
>
> Also update the EC command header to include the new event bit. This bit
> is included in the latest version of the Chrome EC headers[1].
>
> [1]
> https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.h
>
> Cc: Benson Leung
> Signed-off-by: Prashant Malani
> ---
> drivers/platform/chrome/cros_ec_typec.c| 13 +
> include/linux/platform_data/cros_ec_commands.h | 1 +
Could this be a separate patch?
Thank you.
Enric
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_typec.c
> b/drivers/platform/chrome/cros_ec_typec.c
> index d3df1717a5fd..22052f569f2a 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -905,6 +905,19 @@ static void cros_typec_handle_status(struct
> cros_typec_data *typec, int port_num
> return;
> }
>
> + /* If we got a hard reset, unregister everything and return. */
> + if (resp.events & PD_STATUS_EVENT_HARD_RESET) {
> + cros_typec_remove_partner(typec, port_num);
> + cros_typec_remove_cable(typec, port_num);
> +
> + ret = cros_typec_send_clear_event(typec, port_num,
> + PD_STATUS_EVENT_HARD_RESET);
> + if (ret < 0)
> + dev_warn(typec->dev,
> +"Failed hard reset event clear, port: %d\n",
> port_num);
> + return;
> + }
> +
> /* Handle any events appropriately. */
> if (resp.events & PD_STATUS_EVENT_SOP_DISC_DONE &&
> !typec->ports[port_num]->sop_disc_done) {
> u16 sop_revision;
> diff --git a/include/linux/platform_data/cros_ec_commands.h
> b/include/linux/platform_data/cros_ec_commands.h
> index 5ff8597ceabd..9156078c6fc6 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -5678,6 +5678,7 @@ enum tcpc_cc_polarity {
>
> #define PD_STATUS_EVENT_SOP_DISC_DONE BIT(0)
> #define PD_STATUS_EVENT_SOP_PRIME_DISC_DONEBIT(1)
> +#define PD_STATUS_EVENT_HARD_RESET BIT(2)
>
> struct ec_params_typec_status {
> uint8_t port;
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Re: [PATCH v5 1/2] mfd: google,cros-ec: add DT bindings for a baseboard's switch device
Hi Ikjoon,
Thank you for your patch.
Missatge de Ikjoon Jang del dia dj., 15 d’abr.
2021 a les 5:32:
>
> This is for ChromeOS tablets which have a 'cros_cbas' switch device
> in the "Whiskers" base board. This device can be instantiated only by
> device tree on ARM platforms. ChromeOS EC doesn't provide a way to
> probe the device.
>
> Signed-off-by: Ikjoon Jang
>
> ---
>
> Changes in v5:
> - Add missing blank lines and change the description property's position.
> - Add a note to description: "this device cannot be detected at runtime."
>
> Changes in v4:
> Define cros-cbase bindings inside google,cros-ec.yaml instead of
> a separated binding document.
>
> .../bindings/mfd/google,cros-ec.yaml | 20 +++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index 76bf16ee27ec..8dcce176b72e 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -114,6 +114,22 @@ properties:
>- "#address-cells"
>- "#size-cells"
>
> + cbas:
> +type: object
> +
> +description:
> + This device is used to signal when a detachable base is attached
> + to a Chrome OS tablet. This device cannot be detected at runtime.
> +
> +properties:
> + compatible:
> +const: google,cros-cbas
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> patternProperties:
>"^i2c-tunnel[0-9]*$":
> type: object
> @@ -180,6 +196,10 @@ examples:
> interrupts = <99 0>;
> interrupt-parent = <&gpio7>;
> spi-max-frequency = <500>;
> +
> +base_detection: cbas {
nit: Rob, shouldn't this be just cbas?
> +compatible = "google,cros-cbas";
> +};
> };
> };
>
> --
> 2.31.1.295.g9ea45b61b8-goog
>
Acked-by: Enric Balletbo i Serra
Re: [PATCH v2 0/3] Misc bug fixes in mtk power domain driver
Hi Bilal, Thank you for your patch. Missatge de Bilal Wasim del dia dt., 16 de febr. 2021 a les 13:00: > > > ping - can this series be merged ? > This series breaks my display with the current mainline. With those patches applied my display doesn't turn on and I get the following error. Note that in mainline we don't have a gpu working driver. [ 66.979546] [ cut here ] [ 66.984234] [CRTC:43:crtc-0] vblank wait timed out [ 66.989070] WARNING: CPU: 2 PID: 432 at drivers/gpu/drm/drm_atomic_helper.c:1512 drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 67.001166] Modules linked in: af_alg mwifiex_sdio mwifiex btmrvl_sdio btmrvl bluetooth mtk_vcodec_dec mtk_vcodec_enc cfg80211 uvcvideo mtk _mdp mtk_vcodec_common v4l2_h264 v4l2_mem2mem videobuf2_dma_contig videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev smsc ecdh_generic mt8173_rt5650 ecc smsc95xx rfkill mc usbnet cros_ec_sensors snd_soc_rt5645 cros_ec_sensors_core elants_i2c mt8173_afe_pcm c rct10dif_ce elan_i2c industrialio_triggered_buffer sbs_battery cros_ec_chardev kfifo_buf cros_usbpd_charger cros_usbpd_logger snd_soc_rl6231 s nd_soc_mtk_common mtk_vpu display_connector pwm_bl fuse ip_tables x_tables ipv6 [ 67.057686] CPU: 2 PID: 432 Comm: gnome-shell Tainted: GW 5.12.0-rc5+ #25 [ 67.065861] Hardware name: Google Elm (DT) [ 67.069950] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 67.075952] pc : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 67.082477] lr : drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 67.089000] sp : 800012c23aa0 [ 67.092308] x29: 800012c23aa0 x28: 0004 [ 67.097621] x27: x26: 0001 [ 67.102933] x25: 0038 x24: c4726000 [ 67.108246] x23: 0001 x22: [ 67.113558] x21: cabbd880 x20: c3bd8080 [ 67.118869] x19: x18: [ 67.124180] x17: 0010 x16: [ 67.129492] x15: 0030 x14: [ 67.134805] x13: 800011ce2680 x12: 07c2 [ 67.140117] x11: 0296 x10: 800011d3a680 [ 67.145428] x9 : f000 x8 : 800011ce2680 [ 67.150741] x7 : 800011d3a680 x6 : [ 67.156052] x5 : x4 : ff77c918 [ 67.161364] x3 : ff783878 x2 : [ 67.166674] x1 : x0 : cc66 [ 67.171985] Call trace: [ 67.174426] drm_atomic_helper_wait_for_vblanks.part.0+0x278/0x2a0 [ 67.180603] drm_atomic_helper_commit_tail_rpm+0x80/0xa0 [ 67.185913] commit_tail+0xa0/0x180 [ 67.189399] drm_atomic_helper_commit+0x160/0x370 [ 67.194100] drm_atomic_commit+0x4c/0x60 [ 67.198022] drm_mode_obj_set_property_ioctl+0x164/0x460 [ 67.203330] drm_ioctl_kernel+0xc4/0x11c [ 67.207251] drm_ioctl+0x210/0x430 [ 67.210650] __arm64_sys_ioctl+0xa8/0xec ... Thanks, Enric > On Mon, 1 Feb 2021 17:14:13 +0500 > Bilal Wasim wrote: > > > Incorrect mask for the "bus_prot_clr" field meant that imgtec > > gpu power domain (mfg_async) was not powered up correctly, causing > > failure in driver booting. Fixing this and also adding "domain_suuply" > > capability to "mfg_async" power domain (for mt8173) as imgtec gpu > > needs da9211 regulator to be enabled before enabling this subdomain. > > > > Tested with mt8173 elm chromebook. > > > > Bilal Wasim (3): > > soc: mediatek: pm-domains: Use correct mask for bus_prot_clr > > soc: mediatek: pm-domains: Add domain_supply cap for mfg_async PD > > arm64: dts: mediatek: mt8173: Add domain supply for mfg_async > > > > arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 > > arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 4 > > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +- > > drivers/soc/mediatek/mt8173-pm-domains.h | 1 + > > drivers/soc/mediatek/mtk-pm-domains.h| 2 +- > > 5 files changed, 11 insertions(+), 2 deletions(-) > > > > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v5 08/11] dt-bindings: add power-domain header for RK3568 SoCs
Missatge de Elaine Zhang del dia dv., 26 de març 2021 a les 10:18: > > According to a description from TRM, add all the power domains > > Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra > --- > include/dt-bindings/power/rk3568-power.h | 32 > 1 file changed, 32 insertions(+) > create mode 100644 include/dt-bindings/power/rk3568-power.h > > diff --git a/include/dt-bindings/power/rk3568-power.h > b/include/dt-bindings/power/rk3568-power.h > new file mode 100644 > index ..6cc1af1a9d26 > --- /dev/null > +++ b/include/dt-bindings/power/rk3568-power.h > @@ -0,0 +1,32 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#ifndef __DT_BINDINGS_POWER_RK3568_POWER_H__ > +#define __DT_BINDINGS_POWER_RK3568_POWER_H__ > + > +/* VD_CORE */ > +#define RK3568_PD_CPU_00 > +#define RK3568_PD_CPU_11 > +#define RK3568_PD_CPU_22 > +#define RK3568_PD_CPU_33 > +#define RK3568_PD_CORE_ALIVE 4 > + > +/* VD_PMU */ > +#define RK3568_PD_PMU 5 > + > +/* VD_NPU */ > +#define RK3568_PD_NPU 6 > + > +/* VD_GPU */ > +#define RK3568_PD_GPU 7 > + > +/* VD_LOGIC */ > +#define RK3568_PD_VI 8 > +#define RK3568_PD_VO 9 > +#define RK3568_PD_RGA 10 > +#define RK3568_PD_VPU 11 > +#define RK3568_PD_CENTER 12 > +#define RK3568_PD_RKVDEC 13 > +#define RK3568_PD_RKVENC 14 > +#define RK3568_PD_PIPE 15 > +#define RK3568_PD_LOGIC_ALIVE 16 > + > +#endif > -- > 2.17.1 > > > > > ___ > Linux-rockchip mailing list > linux-rockc...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 10/11] dt-bindings: power: rockchip: Add bindings for RK3568 Soc
Missatge de Elaine Zhang del dia dv., 26 de març 2021 a les 10:19: > > Add the compatible string for RK3568 SoC. > > Signed-off-by: Elaine Zhang Reviewed-by: Enric Balletbo i Serra > --- > .../devicetree/bindings/power/rockchip,power-controller.yaml| 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > index 9fec9e227432..a4d223255c3b 100644 > --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > @@ -37,6 +37,7 @@ properties: >- rockchip,rk3366-power-controller >- rockchip,rk3368-power-controller >- rockchip,rk3399-power-controller > + - rockchip,rk3568-power-controller > >"#power-domain-cells": > const: 1 > @@ -90,6 +91,7 @@ patternProperties: >"include/dt-bindings/power/rk3366-power.h" >"include/dt-bindings/power/rk3368-power.h" >"include/dt-bindings/power/rk3399-power.h" > + "include/dt-bindings/power/rk3568-power.h" > >clocks: > description: | > -- > 2.17.1 > > > > > ___ > Linux-rockchip mailing list > linux-rockc...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 06/11] arm64: dts: rockchip: Fix power-controller node names for rk3399
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:18:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 40
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index edbbf35fe19e..142f5593d48b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -971,26 +971,26 @@
> #size-cells = <0>;
>
> /* These power domains are grouped by VD_CENTER */
> - pd_iep@RK3399_PD_IEP {
> + power-domain@RK3399_PD_IEP {
> reg = ;
> clocks = <&cru ACLK_IEP>,
> <&cru HCLK_IEP>;
> pm_qos = <&qos_iep>;
> };
> - pd_rga@RK3399_PD_RGA {
> + power-domain@RK3399_PD_RGA {
> reg = ;
> clocks = <&cru ACLK_RGA>,
> <&cru HCLK_RGA>;
> pm_qos = <&qos_rga_r>,
> <&qos_rga_w>;
> };
> - pd_vcodec@RK3399_PD_VCODEC {
> + power-domain@RK3399_PD_VCODEC {
> reg = ;
> clocks = <&cru ACLK_VCODEC>,
> <&cru HCLK_VCODEC>;
> pm_qos = <&qos_video_m0>;
> };
> - pd_vdu@RK3399_PD_VDU {
> + power-domain@RK3399_PD_VDU {
> reg = ;
> clocks = <&cru ACLK_VDU>,
> <&cru HCLK_VDU>;
> @@ -999,94 +999,94 @@
> };
>
> /* These power domains are grouped by VD_GPU */
> - pd_gpu@RK3399_PD_GPU {
> + power-domain@RK3399_PD_GPU {
> reg = ;
> clocks = <&cru ACLK_GPU>;
> pm_qos = <&qos_gpu>;
> };
>
> /* These power domains are grouped by VD_LOGIC */
> - pd_edp@RK3399_PD_EDP {
> + power-domain@RK3399_PD_EDP {
> reg = ;
> clocks = <&cru PCLK_EDP_CTRL>;
> };
> - pd_emmc@RK3399_PD_EMMC {
> + power-domain@RK3399_PD_EMMC {
> reg = ;
> clocks = <&cru ACLK_EMMC>;
> pm_qos = <&qos_emmc>;
> };
> - pd_gmac@RK3399_PD_GMAC {
> + power-domain@RK3399_PD_GMAC {
> reg = ;
> clocks = <&cru ACLK_GMAC>,
> <&cru PCLK_GMAC>;
> pm_qos = <&qos_gmac>;
> };
> - pd_sd@RK3399_PD_SD {
> + power-domain@RK3399_PD_SD {
> reg = ;
> clocks = <&cru HCLK_SDMMC>,
> <&cru SCLK_SDMMC>;
> pm_qos = <&qos_sd>;
> };
> - pd_sdioaudio@RK3399_PD_SDIOAUDIO {
> + power-domain@RK3399_PD_SDIOAUDIO {
> reg = ;
> clocks = <&cru HCLK_SDIO>;
> pm_qos = <&qos_sdioaudio>;
> };
> - pd_tcpc0@RK3399_PD_TCPD0 {
> + power-domain@RK3399_PD_TCPD0 {
> reg = ;
> clocks = <&cru SCLK_UPHY0_TCPDCORE>,
> <&cru SCLK_UPHY0_TCPDPHY_REF>;
> };
> - pd_tcpc1@RK3399_PD_TCPD1 {
> + power-domain@RK3399_PD_TCPD1 {
> reg = ;
> clocks = <&cru SCLK_UPHY1_TCPDCORE>,
> <&cru SCLK_UPHY1_TCPDPHY_REF>;
> };
> - pd_usb3@RK3399_PD_USB3 {
> + power-domain@RK3399_PD_USB3 {
>
Re: [PATCH v5 05/11] arm64: dts: rockchip: Fix power-controller node names for rk3328
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:17:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 063ed0adbec4..084acfd597af 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -303,13 +303,13 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pd_hevc@RK3328_PD_HEVC {
> + power-domain@RK3328_PD_HEVC {
> reg = ;
> };
> - pd_video@RK3328_PD_VIDEO {
> + power-domain@RK3328_PD_VIDEO {
> reg = ;
> };
> - pd_vpu@RK3328_PD_VPU {
> + power-domain@RK3328_PD_VPU {
> reg = ;
> clocks = <&cru ACLK_VPU>, <&cru HCLK_VPU>;
> };
> --
> 2.17.1
>
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 03/11] arm: dts: rockchip: Fix power-controller node names for rk3288
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:16:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm/boot/dts/rk3288.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index ea7416c31f9b..6f4d7929e351 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -769,7 +769,7 @@
> * *_HDMI HDMI
> * *_MIPI_*MIPI
> */
> - pd_vio@RK3288_PD_VIO {
> + power-domain@RK3288_PD_VIO {
> reg = ;
> clocks = <&cru ACLK_IEP>,
> <&cru ACLK_ISP>,
> @@ -811,7 +811,7 @@
> * Note: The following 3 are HEVC(H.265) clocks,
> * and on the ACLK_HEVC_NIU (NOC).
> */
> - pd_hevc@RK3288_PD_HEVC {
> + power-domain@RK3288_PD_HEVC {
> reg = ;
> clocks = <&cru ACLK_HEVC>,
> <&cru SCLK_HEVC_CABAC>,
> @@ -825,7 +825,7 @@
> * (video endecoder & decoder) clocks that on the
> * ACLK_VCODEC_NIU and HCLK_VCODEC_NIU (NOC).
> */
> - pd_video@RK3288_PD_VIDEO {
> + power-domain@RK3288_PD_VIDEO {
> reg = ;
> clocks = <&cru ACLK_VCODEC>,
> <&cru HCLK_VCODEC>;
> @@ -836,7 +836,7 @@
> * Note: ACLK_GPU is the GPU clock,
> * and on the ACLK_GPU_NIU (NOC).
> */
> - pd_gpu@RK3288_PD_GPU {
> + power-domain@RK3288_PD_GPU {
> reg = ;
> clocks = <&cru ACLK_GPU>;
> pm_qos = <&qos_gpu_r>,
> --
> 2.17.1
>
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 04/11] arm64: dts: rockchip: Fix power-controller node names for px30
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:17:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/rockchip/px30.dtsi | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi
> b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index c45b0cfcae09..fb3a863e0caf 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -247,20 +247,20 @@
> #size-cells = <0>;
>
> /* These power domains are grouped by VD_LOGIC */
> - pd_usb@PX30_PD_USB {
> + power-domain@PX30_PD_USB {
> reg = ;
> clocks = <&cru HCLK_HOST>,
> <&cru HCLK_OTG>,
> <&cru SCLK_OTG_ADP>;
> pm_qos = <&qos_usb_host>, <&qos_usb_otg>;
> };
> - pd_sdcard@PX30_PD_SDCARD {
> + power-domain@PX30_PD_SDCARD {
> reg = ;
> clocks = <&cru HCLK_SDMMC>,
> <&cru SCLK_SDMMC>;
> pm_qos = <&qos_sdmmc>;
> };
> - pd_gmac@PX30_PD_GMAC {
> + power-domain@PX30_PD_GMAC {
> reg = ;
> clocks = <&cru ACLK_GMAC>,
> <&cru PCLK_GMAC>,
> @@ -268,7 +268,7 @@
> <&cru SCLK_GMAC_RX_TX>;
> pm_qos = <&qos_gmac>;
> };
> - pd_mmc_nand@PX30_PD_MMC_NAND {
> + power-domain@PX30_PD_MMC_NAND {
> reg = ;
> clocks = <&cru HCLK_NANDC>,
> <&cru HCLK_EMMC>,
> @@ -281,14 +281,14 @@
> pm_qos = <&qos_emmc>, <&qos_nand>,
> <&qos_sdio>, <&qos_sfc>;
> };
> - pd_vpu@PX30_PD_VPU {
> + power-domain@PX30_PD_VPU {
> reg = ;
> clocks = <&cru ACLK_VPU>,
> <&cru HCLK_VPU>,
> <&cru SCLK_CORE_VPU>;
> pm_qos = <&qos_vpu>, <&qos_vpu_r128>;
> };
> - pd_vo@PX30_PD_VO {
> + power-domain@PX30_PD_VO {
> reg = ;
> clocks = <&cru ACLK_RGA>,
> <&cru ACLK_VOPB>,
> @@ -304,7 +304,7 @@
> pm_qos = <&qos_rga_rd>, <&qos_rga_wr>,
> <&qos_vop_m0>, <&qos_vop_m1>;
> };
> - pd_vi@PX30_PD_VI {
> + power-domain@PX30_PD_VI {
> reg = ;
> clocks = <&cru ACLK_CIF>,
> <&cru ACLK_ISP>,
> @@ -315,7 +315,7 @@
> <&qos_isp_wr>, <&qos_isp_m1>,
> <&qos_vip>;
> };
> - pd_gpu@PX30_PD_GPU {
> + power-domain@PX30_PD_GPU {
> reg = ;
> clocks = <&cru SCLK_GPU>;
> pm_qos = <&qos_gpu>;
> --
> 2.17.1
>
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 02/11] arm: dts: rockchip: Fix power-controller node names for rk3188
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:17:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm/boot/dts/rk3188.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
> index 2298a8d840ba..5db32fdbe6e7 100644
> --- a/arch/arm/boot/dts/rk3188.dtsi
> +++ b/arch/arm/boot/dts/rk3188.dtsi
> @@ -699,7 +699,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pd_vio@RK3188_PD_VIO {
> + power-domain@RK3188_PD_VIO {
> reg = ;
> clocks = <&cru ACLK_LCDC0>,
> <&cru ACLK_LCDC1>,
> @@ -721,7 +721,7 @@
> <&qos_rga>;
> };
>
> - pd_video@RK3188_PD_VIDEO {
> + power-domain@RK3188_PD_VIDEO {
> reg = ;
> clocks = <&cru ACLK_VDPU>,
> <&cru ACLK_VEPU>,
> @@ -730,7 +730,7 @@
> pm_qos = <&qos_vpu>;
> };
>
> - pd_gpu@RK3188_PD_GPU {
> + power-domain@RK3188_PD_GPU {
> reg = ;
> clocks = <&cru ACLK_GPU>;
> pm_qos = <&qos_gpu>;
> --
> 2.17.1
>
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v5 01/11] arm: dts: rockchip: Fix power-controller node names for rk3066a
i
Missatge de Elaine Zhang del dia dv., 26 de
març 2021 a les 10:17:
>
> Use more generic names (as recommended in the device tree specification
> or the binding documentation)
>
> Signed-off-by: Elaine Zhang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm/boot/dts/rk3066a.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
> index 252750c97f97..bbc3bff50856 100644
> --- a/arch/arm/boot/dts/rk3066a.dtsi
> +++ b/arch/arm/boot/dts/rk3066a.dtsi
> @@ -755,7 +755,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pd_vio@RK3066_PD_VIO {
> + power-domain@RK3066_PD_VIO {
> reg = ;
> clocks = <&cru ACLK_LCDC0>,
> <&cru ACLK_LCDC1>,
> @@ -782,7 +782,7 @@
> <&qos_rga>;
> };
>
> - pd_video@RK3066_PD_VIDEO {
> + power-domain@RK3066_PD_VIDEO {
> reg = ;
> clocks = <&cru ACLK_VDPU>,
> <&cru ACLK_VEPU>,
> @@ -791,7 +791,7 @@
> pm_qos = <&qos_vpu>;
> };
>
> - pd_gpu@RK3066_PD_GPU {
> + power-domain@RK3066_PD_GPU {
> reg = ;
> clocks = <&cru ACLK_GPU>;
> pm_qos = <&qos_gpu>;
> --
> 2.17.1
>
>
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema
Hi Elaine,
Missatge de elaine.zhang del dia dj., 25 de
març 2021 a les 7:43:
>
> Hi,Heiko:
>
> 在 2021/3/24 下午9:31, Heiko Stübner 写道:
> > Am Mittwoch, 24. März 2021, 11:32:42 CET schrieb Enric Balletbo i Serra:
> >> On 24/3/21 11:25, Enric Balletbo i Serra wrote:
> >>> Hi Elaine,
> >>>
> >>> On 24/3/21 11:18, elaine.zhang wrote:
> Hi, Enric
>
> 在 2021/3/24 下午5:56, Enric Balletbo i Serra 写道:
> > Hi Elaine,
> >
> > This is not the exact version I sent, and you reintroduced a "problem"
> > that were
> > already solved/discussed on previous versions. See below:
> >
> > On 24/3/21 8:16, Elaine Zhang wrote:
> >> Convert the soc/rockchip/power_domain.txt binding document to
> >> json-schema and move to the power bindings directory.
> >>
> >> Signed-off-by: Enric Balletbo i Serra
> > If you do significant is a good practice shortly describe them within
> > [] here.
> >
> >> Signed-off-by: Elaine Zhang
> > Note that my last version already had the
> >
> > Reviewed-by: Rob Herring
> >
> > Which should be fine for merging (with probably only minor changes) and
> > you
> > could maintain if you don't do significant changes, but that's not the
> > case, as
> > I said, you are reintroducing one problem. Please review the comments
> > already
> > received on this patchset or similar patchsets to avoid this.
> >
> >> ---
> >>.../power/rockchip,power-controller.yaml | 284
> >> ++
> >>.../bindings/soc/rockchip/power_domain.txt| 136 -
> >>2 files changed, 284 insertions(+), 136 deletions(-)
> >>create mode 100644
> >> Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> >>delete mode 100644
> >> Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> >> b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> >> new file mode 100644
> >> index ..a220322c5139
> >> --- /dev/null
> >> +++
> >> b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
> >> @@ -0,0 +1,284 @@
> >> +# SPDX-License-Identifier: GPL-2.0-only
> >> +%YAML 1.2
> >> +---
> >> +$id:
> >> http://devicetree.org/schemas/power/rockchip,power-controller.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Rockchip Power Domains
> >> +
> >> +maintainers:
> >> + - Elaine Zhang
> >> + - Rob Herring
> > Up to Rob, but I don't think Rob would like to be the maintainer. I
> > think you
> > can only include yourself and Heiko.
> >
> >
> >> + - Heiko Stuebner
> >> +
> >> +description: |
> >> + Rockchip processors include support for multiple power domains
> >> which can be
> >> + powered up/down by software based on different application
> >> scenarios to
> >> save power.
> >> +
> >> + Power domains contained within power-controller node are generic
> >> power domain
> >> + providers documented in
> >> Documentation/devicetree/bindings/power/power-domain.yaml.
> >> +
> >> + IP cores belonging to a power domain should contain a
> >> "power-domains"
> >> + property that is a phandle for the power domain node representing
> >> the domain.
> >> +
> >> +properties:
> >> + $nodename:
> >> +const: power-controller
> >> +
> >> + compatible:
> >> +enum:
> >> + - rockchip,px30-power-controller
> >> + - rockchip,rk3036-power-controller
> >> + - rockchip,rk3066-power-controller
> >> + - rockchip,rk3128-power-controller
> >> + - rockchip,rk3188-power-controller
> >> + - rockchip,rk3228-power-controller
> >> + - rockchip,rk3288-power-controller
> >> + - rockchip,rk3328-power-controller
> >> + - rockchip,rk3366-power-controller
> >> + - rockchip,rk3368-power-controller
> >> + - rockchip,rk3399-power-controller
> >> +
> >> + "#power-domain-cells":
> >> +const: 1
> >> +
> >> + "#address-cells":
> >> +const: 1
> >> +
> >> + "#size-cells":
> >> +const: 0
> >> +
> >> +patternProperties:
> >> + "^pd_[0-9a-z_]{2,10}@[0-9a-f]+$":
> >> +type: object
> >> +description: |
> >> + Represents the power domains within the power controller node as
> >> documented
> >> + in Documentation/devicetree/bindings/power/power-domain.yaml.
> >> +
> > The node names must be generic, as this is power-domain must be in the
> > form:
> >
> > +patternProperties:
> > + "^power-domain@[0-9a-f]+$":
> In this way, dtbs_check cannot b
Re: [PATCH v2 2/3] dt-bindings: Convert the rockchip power_domain to YAML and extend
Hi Elaine, Missatge de Johan Jonker del dia dt., 23 de març 2021 a les 12:06: > > Hi Elaine, > > Some comments. Have a look if it's useful or that you disagree > with...(part 1) > > == > There is currently already a patch proposal that does the same. > Could you read that review history and port the good things to your own > patch serie? > > Re: [PATCH] dt-bindings: power: rockchip: Convert to json-schema > https://lore.kernel.org/linux-rockchip/20201007151159.GA221754@bogus/ > > Re: [PATCH v3] dt-bindings: power: rockchip: Convert to json-schema > https://lore.kernel.org/linux-rockchip/20201007151159.GA221754@bogus/ > In fact, the latest version is v6 which can be found here: https://patchwork.kernel.org/project/linux-rockchip/patch/20210225102643.653095-1-enric.balle...@collabora.com/ Feel free to integrate and/or improve that version in your series.
Re: [v5, 1/2] drm/mediatek: mtk_dpi: Add check for max clock rate in mode_valid
Hi Rex-BC Chen,
Thank you for your patch.
Missatge de Rex-BC Chen del dia dj., 18 de
març 2021 a les 6:42:
>
> Add per-platform max clock rate check in mtk_dpi_bridge_mode_valid.
>
> Signed-off-by: Pi-Hsun Shih
> Signed-off-by: Rex-BC Chen
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index b05f900d9322..0b427ad0cd9b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -120,6 +120,7 @@ struct mtk_dpi_yc_limit {
> struct mtk_dpi_conf {
> unsigned int (*cal_factor)(int clock);
> u32 reg_h_fre_con;
> + u32 max_clock_khz;
> bool edge_sel_en;
> };
>
> @@ -557,9 +558,23 @@ static void mtk_dpi_bridge_enable(struct drm_bridge
> *bridge)
> mtk_dpi_set_display_mode(dpi, &dpi->mode);
> }
>
> +static enum drm_mode_status
> +mtk_dpi_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode)
> +{
> + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> +
> + if (dpi->conf->max_clock_khz && mode->clock >
> dpi->conf->max_clock_khz)
Maybe I read this patch too fast, but why the &&? Shouldn't be more
simple and readable
if (mode->clock > max_clock)
Thanks,
Enric
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> .attach = mtk_dpi_bridge_attach,
> .mode_set = mtk_dpi_bridge_mode_set,
> + .mode_valid = mtk_dpi_bridge_mode_valid,
> .disable = mtk_dpi_bridge_disable,
> .enable = mtk_dpi_bridge_enable,
> };
> @@ -668,17 +683,20 @@ static unsigned int mt8183_calculate_factor(int clock)
> static const struct mtk_dpi_conf mt8173_conf = {
> .cal_factor = mt8173_calculate_factor,
> .reg_h_fre_con = 0xe0,
> + .max_clock_khz = 30,
> };
>
> static const struct mtk_dpi_conf mt2701_conf = {
> .cal_factor = mt2701_calculate_factor,
> .reg_h_fre_con = 0xb0,
> .edge_sel_en = true,
> + .max_clock_khz = 15,
> };
>
> static const struct mtk_dpi_conf mt8183_conf = {
> .cal_factor = mt8183_calculate_factor,
> .reg_h_fre_con = 0xe0,
> + .max_clock_khz = 10,
> };
>
> static int mtk_dpi_probe(struct platform_device *pdev)
> --
> 2.18.0
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 7/7] arm64: dts: mt8173: Drop compatible for mt6397
Hi Matthias,
Thank you for your patch.
Missatge de l'adreça del dia dv., 12 de març
2021 a les 15:57:
>
> From: Matthias Brugger
>
> The regulator framework does not need compatible, it's actually
> superfluous. Drop it from the DT.
>
> Signed-off-by: Matthias Brugger
>
> Series-to: lee.jo...@linaro.org
> Series-to: robh...@kernel.org
> Series-to: matthias@gmail.com
> Series-to: lgirdw...@gmail.com
> Series-to: broo...@kernel.org
> Series-cc: devicet...@vger.kernel.org
> Series-cc: linux-arm-ker...@lists.infradead.org
> Series-cc: linux-media...@lists.infradead.org
> Series-cc: linux-kernel@vger.kernel.org
> ---
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 4 +---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> index 21452c51a20a8..db06a986f763e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> @@ -916,9 +916,7 @@ pio6397: pinctrl {
> #gpio-cells = <2>;
> };
>
> - regulator: mt6397regulator {
> - compatible = "mediatek,mt6397-regulator";
> -
> + mt6397regulator {
The same happens here, it is not checked because the mt6397 is not in
YAML format yet, but once we do this it'll trigger an error as the
node name should be 'regulators'
> mt6397_vpca15_reg: buck_vpca15 {
> regulator-compatible = "buck_vpca15";
> regulator-name = "vpca15";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 6dffada2e66b4..c3f2a85d55fe7 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -303,9 +303,7 @@ pmic: mt6397 {
> interrupt-controller;
> #interrupt-cells = <2>;
>
> - mt6397regulator: mt6397regulator {
> - compatible = "mediatek,mt6397-regulator";
> -
> + mt6397regulator {
> mt6397_vpca15_reg: buck_vpca15 {
> regulator-compatible = "buck_vpca15";
> regulator-name = "vpca15";
> --
> 2.30.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH 2/7] dt-bindigns: regulator: mtk: Drop unneeded compatible
Hi Matthias,
Thank you for your patch. There is a typo in the subject line
s/dt-bindigns/dt-bindings/ Rob might miss this patch as he filters the
patches by subject I guess.
Missatge de l'adreça del dia dv., 12 de març
2021 a les 15:57:
>
> From: Matthias Brugger
>
> The regulator does not need to have a device tree compatible, if it's
> part of an MFD. We leave the node name to the SoC specific name (e.g.
> mt6323regulator) to allow older kernels to work with the new binding.
>
> Signed-off-by: Matthias Brugger
> ---
> .../bindings/regulator/mt6323-regulator.txt| 2 +-
> .../bindings/regulator/mt6358-regulator.txt| 4 +---
> .../bindings/regulator/mt6397-regulator.txt| 14 +-
> 3 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> index a48749db4df36..69f32e1a6702e 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> @@ -19,7 +19,7 @@ LDO:
> Example:
>
> pmic: mt6323 {
> - mt6323regulator: regulators {
> + mt6323regulator {
If you convert this binding to YAML, you'll probably get a review that
the node name must be just 'regulators' here. And then, looking at the
other patches something will break I guess ...
> mt6323_vproc_reg: buck_vproc{
> regulator-name = "vproc";
> regulator-min-microvolt = < 70>;
> diff --git a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> index 9a90a92f2d7e1..ba1214da5bf7c 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/mt6358-regulator.txt
> @@ -23,9 +23,7 @@ Example:
> pmic {
> compatible = "mediatek,mt6358";
>
> - mt6358regulator: mt6358regulator {
> - compatible = "mediatek,mt6358-regulator";
> -
> + mt6358regulator {
> mt6358_vdram1_reg: buck_vdram1 {
> regulator-compatible = "buck_vdram1";
> regulator-name = "vdram1";
> diff --git a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> b/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> index c080086d3e629..2b14362ac56e1 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> @@ -1,11 +1,9 @@
> Mediatek MT6397 Regulator
>
> -Required properties:
> -- compatible: "mediatek,mt6397-regulator"
> -- mt6397regulator: List of regulators provided by this controller. It is
> named
> - according to its regulator type, buck_ and ldo_.
> - The definition for each of these nodes is defined using the standard
> binding
> - for regulators at
> Documentation/devicetree/bindings/regulator/regulator.txt.
> +List of regulators provided by this controller. It is named
> +according to its regulator type, buck_ and ldo_.
> +The definition for each of these nodes is defined using the standard binding
> +for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
>
> The valid names for regulators are::
> BUCK:
> @@ -23,9 +21,7 @@ Example:
> pmic {
> compatible = "mediatek,mt6397";
>
> - mt6397regulator: mt6397regulator {
> - compatible = "mediatek,mt6397-regulator";
> -
> + mt6397regulator {
> mt6397_vpca15_reg: buck_vpca15 {
> regulator-compatible = "buck_vpca15";
> regulator-name = "vpca15";
> --
> 2.30.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] arm64: dts: mediatek: Add gce client reg for display subcomponents
Hi Hsin-Yi,
Thank you for the patch.
Missatge de Hsin-Yi Wang del dia dl., 1 de febr.
2021 a les 12:05:
>
> Add mediatek,gce-client-reg for ccorr, aal, gamma, dither.
>
> Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
> Signed-off-by: Hsin-Yi Wang
FWIW this removes some errors from the boot log like this:
platform 1401.aal: error -2 can't parse gce-client-reg property (0)
Tested-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index b3b8afec5ab9a..0ed37dd9d80b4 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1058,6 +1058,7 @@ ccorr0: ccorr@1400f000 {
> interrupts = ;
> power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> clocks = <&mmsys CLK_MM_DISP_CCORR0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400
> 0xf000 0x1000>;
> };
>
> aal0: aal@1401 {
> @@ -1067,6 +1068,7 @@ aal0: aal@1401 {
> interrupts = ;
> power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> clocks = <&mmsys CLK_MM_DISP_AAL0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401 0
> 0x1000>;
> };
>
> gamma0: gamma@14011000 {
> @@ -1075,6 +1077,7 @@ gamma0: gamma@14011000 {
> interrupts = ;
> power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401
> 0x1000 0x1000>;
> };
>
> dither0: dither@14012000 {
> @@ -1083,6 +1086,7 @@ dither0: dither@14012000 {
> interrupts = ;
> power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> clocks = <&mmsys CLK_MM_DISP_DITHER0>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1401
> 0x2000 0x1000>;
> };
>
> dsi0: dsi@14014000 {
> --
> 2.30.0.365.g02bc693789-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] arm64: dts: mt8183: Add power-domains properity to mfgcfg
Hi Ikjoon,
Thank you for your patch.
Missatge de Ikjoon Jang del dia dc., 24 de febr.
2021 a les 10:21:
>
> mfgcfg clock is under MFG_ASYNC power domain
>
> Signed-off-by: Weiyi Lu
> Signed-off-by: Ikjoon Jang
> ---
>
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7..3384df5284c0 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -962,6 +962,7 @@ mfgcfg: syscon@1300 {
> compatible = "mediatek,mt8183-mfgcfg", "syscon";
> reg = <0 0x1300 0 0x1000>;
> #clock-cells = <1>;
> + power-domains = <&scpsys
> MT8183_POWER_DOMAIN_MFG_ASYNC>;
I don't think this will work in mainline, at least, the reference name
should be &spm
Thanks,
Enric
> };
>
> mmsys: syscon@1400 {
> --
> 2.30.0.617.g56c4b15f3c-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3] arm64: dts: mediatek: Add mt8192 power domains controller
Hi Weiyi,
Missatge de Weiyi Lu del dia dj., 18 de febr.
2021 a les 11:31:
>
> On Mon, 2020-11-30 at 19:16 +0800, Weiyi Lu wrote:
> > On Fri, 2020-11-27 at 13:42 +0100, Matthias Brugger wrote:
> > >
> > > On 19/11/2020 15:13, Enric Balletbo Serra wrote:
> > > > Hi Weiyi,
> > > >
> > > > Missatge de Weiyi Lu del dia dj., 19 de nov.
> > > > 2020 a les 14:10:
> > > >>
> > > >> On Thu, 2020-11-19 at 13:13 +0100, Enric Balletbo Serra wrote:
> > > >>> Hi Weiyi,
> > > >>>
> > > >>> Thank you for the patch
> > > >>>
> > > >>> Missatge de Weiyi Lu del dia dj., 19 de nov.
> > > >>> 2020 a les 11:48:
> > > >>>>
> > > >>>> Add power domains controller node for SoC mt8192
> > > >>>>
> > > >>>> Signed-off-by: Weiyi Lu
> > > >>>> ---
> > > [...]
> > > >>>> + /* System Power Manager */
> > > >>>> + spm: power-controller {
> > > >>>> + compatible =
> > > >>>> "mediatek,mt8192-power-controller";
> > > >>>> + #address-cells = <1>;
> > > >>>> + #size-cells = <0>;
> > > >>>> + #power-domain-cells = <1>;
> > > >>>> +
> > > >>>> + /* power domain of the SoC */
> > > >>>> + audio@MT8192_POWER_DOMAIN_AUDIO {
> > > >>>
> > > >>> If you run the dt_bindings_check it should return some errors, as all
> > > >>> these node names should be 'power-domain@'. Which is a bit annoying
> > > >>> because then you will get a bunch of errors like this:
> > > >>>
> > > >>> [1.969110] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [1.976997] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [1.984828] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [1.992657] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.000685] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.008566] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.016395] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.024221] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.032049] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.039874] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.047699] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.055524] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.063352] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>> [2.071176] debugfs: Directory 'power-domain' with parent
> > > >>> 'pm_genpd' already present!
> > > >>>
> > > >>> But that's another problem that should be handled in debugfs system.
> > > >>>
> > > >>
> > > >> Indeed...so I chose to use different name in dts to avoid problems in
> > > >> debugfs. It does violate the naming rules.
> > > >>
> > > >
> > > > But your binding will not pass (or trigger warnings) the dtb check
> > > > then. Rob was clear that names should be generic. Proper fix is fix
> > > > debugfs not the binding.
> > > >
> > >
> > > By the way, is anybody working on this debugfs issue?
> > >
> >
> > I think we can solve this problem by adding "name" to the struct
> > scpsys_domain_data and use this domain_data->name as the genpd.name.
> > This is very simple. But I want to know if you both like it?
> >
>
> Hi Enric and Matthias,
>
> May I have your opinions on how you might to fix this issue?
> I'll try to give another name to each power domain in the
> scpsys_domain_data and register power domain with this name like below
>
> struct scpsys_domain_data {
> ...
> + char *name;
> };
>
>
> - pd->genpd.name = node->name;
> + pd->genpd.name = pd->data->name ?: node->name;
>
>
> Does it violate the naming rules to some extent? or it's acceptable?
>
I think it could be acceptable, I think doesn't violate any rule. My
doubt here is we should name in a generic way in the form
'power-domain@addr' getting the last part of the full node name to
avoid conflicts or if the name should be driver-specific. I think it
makes sense to be driver-specific as is more helpful for debugging
purposes. If we do driver-specific (with data->name) I'd fail if is
not supplied.
Thanks,
Enric
> > > Regards,
> > > Matthias
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
Re: [PATCH v4, 01/10] soc: mediatek: mmsys: create mmsys folder
Hi Yongqiang Niu, Thank you for your patch. Missatge de Yongqiang Niu del dia dt., 5 de gen. 2021 a les 4:07: > > the mmsys will more and more complicated after support > more and more SoCs, add an independent folder will be > more clear > > Signed-off-by: Yongqiang Niu > --- > drivers/soc/mediatek/Makefile | 2 +- It will not apply cleanly anymore after the below commit that is already queued. Maybe you could rebase the patches and resend them again? commit e1e4f7fea37572f0ccf3887430e52c491e9accb6 Author: CK Hu Date: Tue Jul 21 15:46:06 2020 +0800 soc / drm: mediatek: Move mtk mutex driver to soc folder mtk mutex is used by DRM and MDP driver, and its function is SoC-specific, so move it to soc folder. With that fixed, Reviewed-by: Enric Balletbo i Serra Thanks, Enric > drivers/soc/mediatek/mmsys/Makefile| 2 + > drivers/soc/mediatek/mmsys/mtk-mmsys.c | 373 > + > drivers/soc/mediatek/mtk-mmsys.c | 373 > - > 4 files changed, 376 insertions(+), 374 deletions(-) > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c > delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > index b6908db..eca9774 100644 > --- a/drivers/soc/mediatek/Makefile > +++ b/drivers/soc/mediatek/Makefile > @@ -5,4 +5,4 @@ obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o > -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > diff --git a/drivers/soc/mediatek/mmsys/Makefile > b/drivers/soc/mediatek/mmsys/Makefile > new file mode 100644 > index 000..f44eadc > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c > b/drivers/soc/mediatek/mmsys/mtk-mmsys.c > new file mode 100644 > index 000..18f9397 > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c > @@ -0,0 +1,373 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2014 MediaTek Inc. > + * Author: James Liao > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > + > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > +#define DISP_REG_CONFIG_OUT_SEL0x04c > +#define DISP_REG_CONFIG_DSI_SEL0x050 > +#define DISP_REG_CONFIG_DPI_SEL0x064 > + > +#define OVL0_MOUT_EN_COLOR00x1 > +#define OD_MOUT_EN_RDMA0 0x1 > +#define OD1_MOUT_EN_RDMA1 BIT(16) > +#define UFOE_MOUT_EN_DSI0 0x1 > +#define COLOR0_SEL_IN_OVL0 0x1 > +#define OVL1_MOUT_EN_COLOR10x1 > +#define GAMMA_MOUT_EN_RDMA10x1 > +#define RDMA0_SOUT_DPI00x2 > +#define RDMA0_SOUT_DPI10x3 > +#define RDMA0_SOUT_DSI10x1 > +#define RDMA0_SOUT_DSI20x4 > +#define RDMA0_SOUT_DSI30x5 > +#define RDMA1_SOUT_DPI00x2 > +#define RDMA1_SOUT_DPI10x3 > +#define RDMA1_SOUT_DSI10x1 > +#define RDMA1_SOUT_DSI20x4 > +#define RDMA1_SOUT_DSI30x5 > +#define RDMA2_SOUT_DPI00x2 > +#define RDMA2_SOUT_DPI10x3 > +#define RDMA2_SOUT_DSI10x1 > +#define RDMA2_SOUT_DSI20x4 > +#define RDMA2_SOUT_DSI30x5 > +#define DPI0_SEL_IN_RDMA1 0x1 > +#define DPI0_SEL_IN_RDMA2 0x3 > +#define DPI1_SEL_IN_RDMA1
Re: [PATCH v13 7/8] soc: mediatek: add mtk mutex support for MT8183
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dv., 29 de gen.
2021 a les 10:23:
>
> From: Yongqiang Niu
>
> Add mtk mutex support for MT8183 SoC.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: CK Hu
Reviewed-by: Enric Balletbo i Serra
FWIW this patch is required to have the display working on the
Chromebook IdeaPad Duet, so
Tested-by: Enric Balletbo i Serra
Matthias, If I am not wrong, this patch is the only one that is not
applied for this series. I know that is too late for 5.12, but If
you're fine with it, could you pick this patch directly or do you
prefer a resend of this patch alone once you will start to accept
patches for the next release?
Thanks,
Enric
> ---
> drivers/soc/mediatek/mtk-mutex.c | 50
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-mutex.c
> b/drivers/soc/mediatek/mtk-mutex.c
> index f531b119da7a9..718a41beb6afb 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -14,6 +14,8 @@
>
> #define MT2701_MUTEX0_MOD0 0x2c
> #define MT2701_MUTEX0_SOF0 0x30
> +#define MT8183_MUTEX0_MOD0 0x30
> +#define MT8183_MUTEX0_SOF0 0x2c
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> @@ -37,6 +39,18 @@
> #define MT8167_MUTEX_MOD_DISP_DITHER 15
> #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8183_MUTEX_MOD_DISP_RDMA00
> +#define MT8183_MUTEX_MOD_DISP_RDMA11
> +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> +#define MT8183_MUTEX_MOD_DISP_WDMA012
> +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> +
> #define MT8173_MUTEX_MOD_DISP_OVL0 11
> #define MT8173_MUTEX_MOD_DISP_OVL1 12
> #define MT8173_MUTEX_MOD_DISP_RDMA013
> @@ -87,6 +101,11 @@
> #define MT2712_MUTEX_SOF_DSI3 6
> #define MT8167_MUTEX_SOF_DPI0 2
> #define MT8167_MUTEX_SOF_DPI1 3
> +#define MT8183_MUTEX_SOF_DSI0 1
> +#define MT8183_MUTEX_SOF_DPI0 2
> +
> +#define MT8183_MUTEX_EOF_DSI0 (MT8183_MUTEX_SOF_DSI0 << 6)
> +#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
>
> struct mtk_mutex {
> int id;
> @@ -181,6 +200,20 @@ static const unsigned int
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> +};
> +
> static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -198,6 +231,13 @@ static const unsigned int
> mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> };
>
> +/* Add EOF setting so overlay hardware can receive frame done irq */
> +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> + [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> + [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> + [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
> +};
> +
> static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -227,6 +267,14 @@ static const struct mtk_mutex_data
> mt8173_mutex_driver_data = {
> .mutex_sof_reg = MT2701_MUTEX0_SOF0,
> };
>
> +static const struct mtk_mutex_data mt8183_mutex_driver_data = {
> + .mutex_mod = mt8183_mutex_mod,
> + .mutex_sof = mt8183_mutex_sof,
> + .mutex_mod_reg = MT8183_MUTEX0_MOD0,
> + .mutex_sof_reg = MT8183_MUTEX0_SOF0,
> + .n
Re: [PATCH v4 2/3] dt-bindings: iio: Add cros ec proximity yaml doc
Hi Stephen,
Missatge de Stephen Boyd del dia dt., 2 de febr.
2021 a les 19:53:
>
> Some cros ECs support a front proximity MKBP event via
> 'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
> a node that is a child of the main cros_ec device node. Devices that
> have this ability will describe this in firmware.
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Douglas Anderson
> Cc: Gwendal Grignou
> Cc:
> Cc: Rob Herring
> Cc: Enric Balletbo i Serra
> Signed-off-by: Stephen Boyd
Thanks for adding a full example, IIRC this is preferred by Rob and we
are also trying to apply this rule on all the cros-ec related
bindings, so the dt_bindings_check really checks a full example. From
my side looks good to me.
Reviewed-by: Enric Balletbo i Serra
> ---
> .../google,cros-ec-mkbp-proximity.yaml| 46 +++
> .../bindings/mfd/google,cros-ec.yaml | 3 ++
> 2 files changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
>
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> new file mode 100644
> index ..d82b929af445
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id:
> http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ChromeOS EC MKBP Proximity Sensor
> +
> +maintainers:
> + - Stephen Boyd
> + - Benson Leung
> + - Enric Balletbo i Serra
> +
> +description: |
> + Google's ChromeOS EC sometimes has the ability to detect user proximity.
> + This is implemented on the EC as near/far logic and exposed to the OS
> + via an MKBP switch bit.
> +
> +properties:
> + compatible:
> +const: google,cros-ec-mkbp-proximity
> +
> + label:
> +description: Name for proximity sensor
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +additionalProperties: false
> +
> +examples:
> + - |
> +spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ec@0 {
> +compatible = "google,cros-ec-spi";
> +reg = <0>;
> +proximity {
> + compatible = "google,cros-ec-mkbp-proximity";
> + label = "proximity-wifi-lte";
> +};
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index 76bf16ee27ec..479a9f15de32 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -94,6 +94,9 @@ properties:
>keyboard-controller:
> $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
>
> + proximity:
> +$ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
> +
>codecs:
> type: object
> additionalProperties: false
> --
> https://chromeos.dev
>
Re: [PATCH v11 1/9] arm64: dts: mt8183: rename rdma fifo size
Hi Hsin-Yi,
Thank you for the patch.
Missatge de Hsin-Yi Wang del dia dj., 28 de gen.
2021 a les 8:28:
>
> From: Yongqiang Niu
>
> property name must include only lowercase and '-'
>
This is a leftover while I forward ported the patch, the
rdma_fifo_size only existed on the downstream kernels, in mainline it
is with '-', so we should probably add the fixes tag here.
Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Chun-Kuang Hu
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 5b782a4769e7e..6c84ccb709af6 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1011,7 +1011,7 @@ rdma0: rdma@1400b000 {
> clocks = <&mmsys CLK_MM_DISP_RDMA0>;
> iommus = <&iommu M4U_PORT_DISP_RDMA0>;
> mediatek,larb = <&larb0>;
> - mediatek,rdma_fifo_size = <5120>;
> + mediatek,rdma-fifo-size = <5120>;
> mediatek,gce-client-reg = <&gce SUBSYS_1400
> 0xb000 0x1000>;
> };
>
> @@ -1023,7 +1023,7 @@ rdma1: rdma@1400c000 {
> clocks = <&mmsys CLK_MM_DISP_RDMA1>;
> iommus = <&iommu M4U_PORT_DISP_RDMA1>;
> mediatek,larb = <&larb0>;
> - mediatek,rdma_fifo_size = <2048>;
> + mediatek,rdma-fifo-size = <2048>;
> mediatek,gce-client-reg = <&gce SUBSYS_1400
> 0xc000 0x1000>;
> };
>
> --
> 2.30.0.280.ga3ce27912f-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3 3/3] iio: proximity: Add a ChromeOS EC MKBP proximity driver
Hi Stephen,
Thank you for your patch.
Missatge de Stephen Boyd del dia dj., 28 de gen.
2021 a les 9:48:
>
> Add support for a ChromeOS EC proximity driver that exposes a "front"
> proximity sensor via the IIO subsystem. The EC decides when front
> proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
> notify the kernel of proximity. Similarly, when proximity detects
> something far away it sets the switch bit to 0. For now this driver
> exposes a single sensor, but it could be expanded in the future via more
> MKBP bits if desired.
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Douglas Anderson
> Cc: Gwendal Grignou
> Signed-off-by: Stephen Boyd
> ---
>
> Changes from v2:
> * Get clock base and use iio time if not boottime
>
> Changes from v1:
> * Sorted includes
> * Renamed to have MKBP everywhere
> * Use last_event_time for timestamp
> * Dropped claim calls
> * Dropped useless dev assignment
>
> drivers/iio/proximity/Kconfig | 11 +
> drivers/iio/proximity/Makefile| 1 +
> .../iio/proximity/cros_ec_mkbp_proximity.c| 245 ++
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/iio/proximity/cros_ec_mkbp_proximity.c
>
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index 12672a0e89ed..7c7203ca3ac6 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -21,6 +21,17 @@ endmenu
>
> menu "Proximity and distance sensors"
>
> +config CROS_EC_MKBP_PROXIMITY
> + tristate "ChromeOS EC MKBP Proximity sensor"
> + depends on CROS_EC
> + help
> + Say Y here to enable the proximity sensor implemented via the
> ChromeOS EC MKBP
> + switches protocol. You must enable one bus option (CROS_EC_I2C or
> CROS_EC_SPI)
> + to use this.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_ec_mkbp_proximity.
> +
> config ISL29501
> tristate "Intersil ISL29501 Time Of Flight sensor"
> depends on I2C
> diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
> index 9c1aca1a8b79..cbdac09433eb 100644
> --- a/drivers/iio/proximity/Makefile
> +++ b/drivers/iio/proximity/Makefile
> @@ -5,6 +5,7 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AS3935) += as3935.o
> +obj-$(CONFIG_CROS_EC_MKBP_PROXIMITY) += cros_ec_mkbp_proximity.o
> obj-$(CONFIG_ISL29501) += isl29501.o
> obj-$(CONFIG_LIDAR_LITE_V2)+= pulsedlight-lidar-lite-v2.o
> obj-$(CONFIG_MB1232) += mb1232.o
> diff --git a/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> new file mode 100644
> index ..c8f33cf11b42
> --- /dev/null
> +++ b/drivers/iio/proximity/cros_ec_mkbp_proximity.c
> @@ -0,0 +1,245 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for cros-ec proximity sensor exposed through MKBP switch
> + *
> + * Copyright 2021 Google LLC.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +struct cros_ec_mkbp_proximity_data {
> + struct cros_ec_device *ec;
> + struct iio_dev *indio_dev;
> + struct mutex lock;
> + struct notifier_block notifier;
> + bool enabled;
> +};
> +
> +static const struct iio_event_spec cros_ec_mkbp_proximity_events[] = {
> + {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_EITHER,
> + .mask_separate = BIT(IIO_EV_INFO_ENABLE),
> + },
> +};
> +
> +static const struct iio_chan_spec cros_ec_mkbp_proximity_chan_spec[] = {
> + {
> + .type = IIO_PROXIMITY,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + .event_spec = cros_ec_mkbp_proximity_events,
> + .num_event_specs = ARRAY_SIZE(cros_ec_mkbp_proximity_events),
> + },
> +};
> +
> +static int cros_ec_mkbp_proximity_parse_state(const void *data)
> +{
> + u32 switches = get_unaligned_le32(data);
> +
> + return !!(switches & BIT(EC_MKBP_FRONT_PROXIMITY));
> +}
> +
> +static int cros_ec_mkbp_proximity_query(struct cros_ec_device *ec_dev,
> + int *state)
> +{
> + struct {
> + struct cros_ec_command msg;
> + union {
> + struct ec_params_mkbp_info params;
> + u32 switches;
> + };
> + } __packed buf = { };
> + struct ec_params_mkbp_info *params = &buf.params;
> + struct cros_ec_command *msg = &buf.msg;
> + u32 *switches = &buf.switches;
> + size_t insize = sizeof(*switches);
> + int ret;
> +
> + msg->command = EC_CMD_MKBP_INFO;
> + msg->version = 1;
Re: [PATCH v3 2/3] dt-bindings: iio: Add cros ec proximity yaml doc
Hi Stephen,
Thank you for your patch. Just a minor comment.
Missatge de Stephen Boyd del dia dj., 28 de gen.
2021 a les 9:45:
>
> Some cros ECs support a front proximity MKBP event via
> 'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
> a node that is a child of the main cros_ec device node. Devices that
> have this ability will describe this in firmware.
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Douglas Anderson
> Cc: Gwendal Grignou
> Cc:
> Cc: Rob Herring
> Signed-off-by: Stephen Boyd
> ---
>
> Changes from v2:
> * None
>
> Changes from v1:
> * Added additionalProperties
> * Included proximity in cros-ec yaml
>
> .../google,cros-ec-mkbp-proximity.yaml| 38 +++
> .../bindings/mfd/google,cros-ec.yaml | 3 ++
> 2 files changed, 41 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
>
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> new file mode 100644
> index ..c3141c2be286
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id:
> http://devicetree.org/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ChromeOS EC MKBP Proximity Sensor
> +
> +maintainers:
> + - Stephen Boyd
> + - Benson Leung
> + - Enric Balletbo i Serra
> +
> +description: |
> + Google's ChromeOS EC sometimes has the ability to detect user proximity.
> + This is implemented on the EC as near/far logic and exposed to the OS
> + via an MKBP switch bit.
> +
> +properties:
> + compatible:
> +const: google,cros-ec-mkbp-proximity
> +
> + label:
> +description: Name for proximity sensor
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
> +additionalProperties: false
> +
> +examples:
> + - |
For this kind of devices it is preferred to see a complete example
rather than pieces spread around different yaml. This helps proper
binding parsing.
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
> +proximity {
> +compatible = "google,cros-ec-mkbp-proximity";
> +label = "proximity-wifi-lte";
> +};
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index 76bf16ee27ec..479a9f15de32 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -94,6 +94,9 @@ properties:
>keyboard-controller:
> $ref: "/schemas/input/google,cros-ec-keyb.yaml#"
>
> + proximity:
> +$ref: "/schemas/iio/proximity/google,cros-ec-mkbp-proximity.yaml#"
> +
>codecs:
> type: object
> additionalProperties: false
> --
> https://chromeos.dev
>
Re: [PATCH v3 1/3] platform/chrome: cros_ec: Add SW_FRONT_PROXIMITY MKBP define
Hi Stephen,
Thank you for your patch. Please cc'me for the patches related to the
chrome/platform subsystem.
Missatge de Stephen Boyd del dia dj., 28 de gen.
2021 a les 9:48:
>
> Some cros ECs support a front proximity MKBP event via
> 'EC_MKBP_FRONT_PROXIMITY'. Add this define so it can be used in a
> future patch.
>
> Cc: Dmitry Torokhov
> Cc: Benson Leung
> Cc: Guenter Roeck
> Cc: Douglas Anderson
> Cc: Gwendal Grignou
> Signed-off-by: Stephen Boyd
Acked-by: Enric Balletbo i Serra
> ---
> include/linux/platform_data/cros_ec_commands.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/platform_data/cros_ec_commands.h
> b/include/linux/platform_data/cros_ec_commands.h
> index 86376779ab31..776e0b2be0e9 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -3457,6 +3457,7 @@ struct ec_response_get_next_event_v1 {
> #define EC_MKBP_LID_OPEN 0
> #define EC_MKBP_TABLET_MODE1
> #define EC_MKBP_BASE_ATTACHED 2
> +#define EC_MKBP_FRONT_PROXIMITY3
>
> /* Run keyboard factory test scanning */
> #define EC_CMD_KEYBOARD_FACTORY_TEST 0x0068
> --
> https://chromeos.dev
>
Re: [PATCH v11 2/9] arm64: dts: mt8183: refine gamma compatible name
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 28 de gen.
2021 a les 8:28:
>
> From: Yongqiang Niu
>
> mt8183 gamma is different with mt8173
> remove mt8173 compatible name for mt8183 gamma
>
Should this patch contain?
Fixes: 91f9c963ce79 ("arm64: dts: mt8183: Add display nodes for MT8183")
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 6c84ccb709af6..9c0073cfad452 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1055,8 +1055,7 @@ aal0: aal@1401 {
> };
>
> gamma0: gamma@14011000 {
> - compatible = "mediatek,mt8183-disp-gamma",
> -"mediatek,mt8173-disp-gamma";
> + compatible = "mediatek,mt8183-disp-gamma";
> reg = <0 0x14011000 0 0x1000>;
> interrupts = ;
> power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> --
> 2.30.0.280.ga3ce27912f-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3] arm64: dts: mediatek: Add mt8192 power domains controller
Hi Weiyi,
Missatge de Weiyi Lu del dia dj., 19 de nov.
2020 a les 14:10:
>
> On Thu, 2020-11-19 at 13:13 +0100, Enric Balletbo Serra wrote:
> > Hi Weiyi,
> >
> > Thank you for the patch
> >
> > Missatge de Weiyi Lu del dia dj., 19 de nov.
> > 2020 a les 11:48:
> > >
> > > Add power domains controller node for SoC mt8192
> > >
> > > Signed-off-by: Weiyi Lu
> > > ---
> > >
> > > Change in v3: None, just rebase dts onto v5.10-rc1 and
> > >V4 of series "Add new driver for SCPSYS power domains
> > > controller"[1]
> > >
> > > [1]
> > > https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
> > >
> > > arch/arm64/boot/dts/mediatek/mt8192.dtsi | 201
> > > +++
> > > 1 file changed, 201 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > > b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > > index 69d45c7..08449eb 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> > > @@ -9,6 +9,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > / {
> > > compatible = "mediatek,mt8192";
> > > @@ -257,6 +258,206 @@
> > > #interrupt-cells = <2>;
> > > };
> > >
> > > + scpsys: syscon@10006000 {
> > > + compatible = "syscon", "simple-mfd";
> > > + reg = <0 0x10006000 0 0x1000>;
> > > + #power-domain-cells = <1>;
> > > +
> > > + /* System Power Manager */
> > > + spm: power-controller {
> > > + compatible =
> > > "mediatek,mt8192-power-controller";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + #power-domain-cells = <1>;
> > > +
> > > + /* power domain of the SoC */
> > > + audio@MT8192_POWER_DOMAIN_AUDIO {
> >
> > If you run the dt_bindings_check it should return some errors, as all
> > these node names should be 'power-domain@'. Which is a bit annoying
> > because then you will get a bunch of errors like this:
> >
> > [1.969110] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [1.976997] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [1.984828] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [1.992657] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.000685] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.008566] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.016395] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.024221] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.032049] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.039874] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.047699] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.055524] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.063352] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> > [2.071176] debugfs: Directory 'power-domain' with parent
> > 'pm_genpd' already present!
> >
> > But that's another problem that should be handled in debugfs system.
> >
>
> Indeed...so I chose to use different name in dts to avoid problems in
> debugfs. It does violate the naming rules.
>
But your binding will not pass (or trigger warnings) the dtb che
Re: [PATCH v3] arm64: dts: mediatek: Add mt8192 power domains controller
Hi Weiyi,
Thank you for the patch
Missatge de Weiyi Lu del dia dj., 19 de nov.
2020 a les 11:48:
>
> Add power domains controller node for SoC mt8192
>
> Signed-off-by: Weiyi Lu
> ---
>
> Change in v3: None, just rebase dts onto v5.10-rc1 and
>V4 of series "Add new driver for SCPSYS power domains controller"[1]
>
> [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
>
> arch/arm64/boot/dts/mediatek/mt8192.dtsi | 201
> +++
> 1 file changed, 201 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> index 69d45c7..08449eb 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "mediatek,mt8192";
> @@ -257,6 +258,206 @@
> #interrupt-cells = <2>;
> };
>
> + scpsys: syscon@10006000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0 0x10006000 0 0x1000>;
> + #power-domain-cells = <1>;
> +
> + /* System Power Manager */
> + spm: power-controller {
> + compatible =
> "mediatek,mt8192-power-controller";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #power-domain-cells = <1>;
> +
> + /* power domain of the SoC */
> + audio@MT8192_POWER_DOMAIN_AUDIO {
If you run the dt_bindings_check it should return some errors, as all
these node names should be 'power-domain@'. Which is a bit annoying
because then you will get a bunch of errors like this:
[1.969110] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.976997] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.984828] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[1.992657] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.000685] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.008566] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.016395] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.024221] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.032049] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.039874] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.047699] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.055524] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.063352] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
[2.071176] debugfs: Directory 'power-domain' with parent
'pm_genpd' already present!
But that's another problem that should be handled in debugfs system.
> + reg = ;
> + clocks = <&topckgen
> CLK_TOP_AUD_INTBUS_SEL>,
> +<&infracfg
> CLK_INFRA_AUDIO_26M_B>,
> +<&infracfg CLK_INFRA_AUDIO>;
> + clock-names = "audio", "audio1",
> "audio2";
> + mediatek,infracfg = <&infracfg>;
> + #power-domain-cells = <0>;
> + };
> +
> + conn@MT8192_POWER_DOMAIN_CONN {
> + reg = ;
> + clocks = <&infracfg
> CLK_INFRA_PMIC_CONN>;
> + clock-names = "conn";
> + mediatek,infracfg = <&infracfg>;
> + #power-domain-cells = <0>;
> + };
> +
> + mfg@MT8192_POWER_DOMAIN_MFG0 {
> + reg = ;
> + clocks = <&topckgen
> CLK_TOP_MFG_PLL_SEL>;
> + clock-names = "mfg";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #power-domain-cells = <1>;
> +
> + mfg1@MT8192_POWER_DOMAIN_MFG1 {
> + reg =
> ;
> + mediatek,infracfg =
> <&infracfg>;
> + #address-cells = <1>;
Re: [PATCH v3] dt-bindings: power: rockchip: Convert to json-schema
Hi Rob, Missatge de Rob Herring del dia dc., 7 d’oct. 2020 a les 17:12: > > On Mon, Sep 21, 2020 at 11:29:51AM +0200, Enric Balletbo i Serra wrote: > > Convert the soc/rockchip/power_domain.txt binding document to json-schema > > and move to the power bindings directory. > > > > Signed-off-by: Enric Balletbo i Serra > > --- > > > > Changes in v3: > > - Fixed tab errors found by bot > > > > Changes in v2: > > - Fixed a warning that says that 'syscon' should not be used alone. > > - Use patternProperties to define a new level for power-domains. > > - Add const values for power-domain-cells, address-cells, etc. > > > > .../power/rockchip,power-controller.yaml | 207 ++ > > .../bindings/soc/rockchip/power_domain.txt| 136 > > 2 files changed, 207 insertions(+), 136 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > > delete mode 100644 > > Documentation/devicetree/bindings/soc/rockchip/power_domain.txt > > > > diff --git > > a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > > b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > > new file mode 100644 > > index ..b23ea37e2a08 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml > > @@ -0,0 +1,207 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/power/rockchip,power-controller.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Rockchip Power Domains > > + > > +maintainers: > > + - Caesar Wang > > + - Heiko Stuebner > > + > > +description: | > > + Rockchip processors include support for multiple power domains which can > > be > > + powered up/down by software based on different application scenes to > > save power. > > + > > + Power domains contained within power-controller node are generic power > > domain > > + providers documented in > > Documentation/devicetree/bindings/power/power-domain.yaml. > > + > > + IP cores belonging to a power domain should contain a 'power-domains' > > + property that is a phandle for the power domain node representing the > > domain. > > + > > +properties: > > + $nodename: > > +const: power-controller > > + > > + compatible: > > +enum: > > + - rockchip,px30-power-controller > > + - rockchip,rk3036-power-controller > > + - rockchip,rk3066-power-controller > > + - rockchip,rk3128-power-controller > > + - rockchip,rk3188-power-controller > > + - rockchip,rk3228-power-controller > > + - rockchip,rk3288-power-controller > > + - rockchip,rk3328-power-controller > > + - rockchip,rk3366-power-controller > > + - rockchip,rk3368-power-controller > > + - rockchip,rk3399-power-controller > > + > > + '#power-domain-cells': > > +const: 1 > > + > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > +patternProperties: > > + "^power-domain@[0-9]+$": > > unit-addresses are hex. > > > +type: object > > +description: | > > + Represents the power domains within the power controller node as > > documented > > + in Documentation/devicetree/bindings/power/power-domain.yaml. > > + > > +properties: > > + > > + '#power-domain-cells': > > +description: > > +Must be 0 for nodes representing a single PM domain and 1 for > > nodes > > +providing multiple PM domains. > > + > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > + reg: > > +description: | > > + Power domain index. Valid values are defined in: > > + "include/dt-bindings/power/px30-power.h" - for PX30 type power > > domain. > > + "include/dt-bindings/power/rk3036-power.h" - for RK3036 type > > power domain. > > + "include/dt-bindings/power/rk3066-power.h" - for RK3066 type > > power domain. > > + "include/dt-bindings/power/rk3128-power.h" - for RK3128 type > > power domain. > > + "include/dt-bindings/power/rk3188-power.h" - for RK3188 type > > power domain. > > + "include/dt-bindings/power/rk3228-power.h" - for RK3228 type > > power domain. > > + "include/dt-bindings/power/rk3288-power.h" - for RK3288 type > > power domain. > > + "include/dt-bindings/power/rk3328-power.h" - for RK3328 type > > power domain. > > + "include/dt-bindings/power/rk3366-power.h" - for RK3366 type > > power domain. > > + "include/dt-bindings/power/rk3368-power.h" - for RK3368 type > > power domain. > > + "include/dt-bindings/power/rk3399-power.h" - for RK3399 type > > power domain. > > +maxItems: 1 > > Range of values? > > > + > > + clocks: > > +description: | > > + A number of phandles to clocks
Re: [PATCH 03/12] arm64: dts: mediatek: Add mt8173 power domain controller
Hi Fabien,
Thank you to look at this.
Missatge de Fabien Parent del dia dv., 18 de
set. 2020 a les 22:24:
>
> Hi Enric,
>
> > - scpsys: power-controller@10006000 {
> > - compatible = "mediatek,mt8173-scpsys";
> > - #power-domain-cells = <1>;
>
> This change generates a lot of warning when compiling the MT8173 device-trees.
>
> Warning (power_domains_property): /soc/mutex@1402: Missing
> property '#power-domain-cells' in node /soc/syscon@10006000 or bad
> phandle (referred from power-domains[0])
I think that there is a mistake in that patch #power-domain-cells =
<1>; should not be removed. Anyway, I talked with Matthias and I'm
going to redefine this part as doesn't really match with the hardware.
We're thinking on something like this:
scpsys: syscon@10006000 {
compatible = "mediatek,mtk-scpsys", "syscon";
reg = ...
power-controller {
compatible = "mediatek,mt8173-power-controller";
#power-domain-cells = <1>;
<- the list of domains ->
Thanks,
Enric
Re: [PATCH 4/6] irqchip/mtk-cirq: Allow modular build
Missatge de Bjorn Andersson del dia dg.,
13 de set. 2020 a les 1:26:
>
> On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
>
> > Switch the driver to a "hybrid probe" model which preserves the
> > built-in behaviour while allowing the driver to be optionnally
> > built as a module for development purposes.
> >
>
> Reviewed-by: Bjorn Andersson
>
> > Signed-off-by: Marc Zyngier
I've tested this on mt8173 and mt8183, and this time, the patches
didn't break booting on these platforms. For MediaTek, right now, only
makes sense the driver to be built-in as other drivers that use it are
not ready for deferring their probe. So,
Tested-by: Enric Balletbo i Serra
Thanks
Enric
> > ---
> > drivers/irqchip/irq-mtk-cirq.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> > index 69ba8ce3c178..43e880b63ed2 100644
> > --- a/drivers/irqchip/irq-mtk-cirq.c
> > +++ b/drivers/irqchip/irq-mtk-cirq.c
> > @@ -295,4 +295,6 @@ static int __init mtk_cirq_of_init(struct device_node
> > *node,
> > return ret;
> > }
> >
> > -IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init);
> > +IRQCHIP_HYBRID_DRIVER_BEGIN(mtk_cirq)
> > +IRQCHIP_MATCH("mediatek,mtk-cirq", mtk_cirq_of_init)
> > +IRQCHIP_HYBRID_DRIVER_END(mtk_cirq)
> > --
> > 2.28.0
> >
Re: [PATCH 5/6] irqchip/mtk-sysirq: Allow modular build
Missatge de Bjorn Andersson del dia dg.,
13 de set. 2020 a les 1:25:
>
> On Sat 12 Sep 07:51 CDT 2020, Marc Zyngier wrote:
>
> > Switch the driver to a "hybrid probe" model which preserves the
> > built-in behaviour while allowing the driver to be optionnally
> > built as a module for development purposes.
> >
>
> Reviewed-by: Bjorn Andersson
>
> > Signed-off-by: Marc Zyngier
I've tested this on mt8173 and mt8183, and this time, the patches
didn't break booting on these platforms. For MediaTek, right now, only
makes sense the driver to be built-in as other drivers that use it are
not ready for deferring their probe. So,
Tested-by: Enric Balletbo i Serra
Thanks
Enric
> > ---
> > drivers/irqchip/irq-mtk-sysirq.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-mtk-sysirq.c
> > b/drivers/irqchip/irq-mtk-sysirq.c
> > index 6ff98b87e5c0..ee45d8f71ec3 100644
> > --- a/drivers/irqchip/irq-mtk-sysirq.c
> > +++ b/drivers/irqchip/irq-mtk-sysirq.c
> > @@ -231,4 +231,6 @@ static int __init mtk_sysirq_of_init(struct device_node
> > *node,
> > kfree(chip_data);
> > return ret;
> > }
> > -IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init);
> > +IRQCHIP_HYBRID_DRIVER_BEGIN(mtk_sysirq)
> > +IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init)
> > +IRQCHIP_HYBRID_DRIVER_END(mtk_sysirq)
> > --
> > 2.28.0
> >
Re: [PATCH] Revert "irqchip/mtk-sysirq: Convert to a platform driver"
Hi Frank,
Missatge de Frank Wunderlich del dia dl., 17 d’ag.
2020 a les 16:58:
>
> From: Frank Wunderlich
>
> This reverts commit f97dbf48ca43009e8b8bcdf07f47fc9f06149b36 which
> breaks bootup of arm/arm64 devices like bananapi-r2/mt7623 and
> bananapi-r64/mt7622
>
> Signed-off-by: Frank Wunderlich
I already answered your BUG report, but, for the record, I think a
proper fix is following his way [1] and probably will be merged soon.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next&id=7828a3ef8646fb2e69ed45616c8453a037ca7867
Thanks,
Enric
> ---
> drivers/irqchip/irq-mtk-sysirq.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-mtk-sysirq.c
> b/drivers/irqchip/irq-mtk-sysirq.c
> index 7299c5ab4d10..6ff98b87e5c0 100644
> --- a/drivers/irqchip/irq-mtk-sysirq.c
> +++ b/drivers/irqchip/irq-mtk-sysirq.c
> @@ -231,6 +231,4 @@ static int __init mtk_sysirq_of_init(struct device_node
> *node,
> kfree(chip_data);
> return ret;
> }
> -IRQCHIP_PLATFORM_DRIVER_BEGIN(mtk_sysirq)
> -IRQCHIP_MATCH("mediatek,mt6577-sysirq", mtk_sysirq_of_init)
> -IRQCHIP_PLATFORM_DRIVER_END(mtk_sysirq)
> +IRQCHIP_DECLARE(mtk_sysirq, "mediatek,mt6577-sysirq", mtk_sysirq_of_init);
> --
> 2.25.1
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [BUG] 5.9-rc1 broken bootup on mt7622/mt7623
Hi Frank, Missatge de Frank Wunderlich del dia dl., 17 d’ag. 2020 a les 16:48: > > Hi > > at least my Bananapi R2/R64 does not bootup (no output on serial console) > with 5.9-rc1 > > made a bisect which points me to this commit: > > commit f97dbf48ca43009e8b8bcdf07f47fc9f06149b36 > Author: Saravana Kannan > Date: Fri Jul 17 17:06:36 2020 -0700 > > irqchip/mtk-sysirq: Convert to a platform driver > > This driver can work as a platform driver. So covert it to a platform > driver. > > Signed-off-by: Saravana Kannan > Signed-off-by: Marc Zyngier > Reviewed-by: Hanks Chen > Link: > https://lore.kernel.org/r/20200718000637.3632841-4-sarava...@google.com > Looks like all Mediatek devices are broken, you should try if this [1] fixes the issue for you. It fixes for me. [1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/irqchip-next&id=7828a3ef8646fb2e69ed45616c8453a037ca7867 Cheers, Enric > drivers/irqchip/irq-mtk-sysirq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > at least on my devices i got 5.9 working by reverting the commit, will send a > revert-Patch > > $ git bisect log > git bisect start > # bad: [d24b5abc4640b46bb356bb5371d244866a5fe0a3] gitignore: add from 5.8 + > itb/mod > git bisect bad d24b5abc4640b46bb356bb5371d244866a5fe0a3 > # good: [bcf876870b95592b52519ed4aafcf9d95999bc9c] Linux 5.8 > git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c > # bad: [8186749621ed6b8fc42644c399e8c755a2b6f630] Merge tag > 'drm-next-2020-08-06' of git://anongit.freedesktop.org/drm/drm > git bisect bad 8186749621ed6b8fc42644c399e8c755a2b6f630 > # bad: [2324d50d051ec0f14a548e78554fb02513d6dcef] Merge tag 'docs-5.9' of > git://git.lwn.net/linux > git bisect bad 2324d50d051ec0f14a548e78554fb02513d6dcef > # good: [92c59e126b21fd212195358a0d296e787e444087] Merge tag > 'arm-defconfig-5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc > git bisect good 92c59e126b21fd212195358a0d296e787e444087 > # good: [d4db4e553249eda9016fab2e363c26e52c47926f] Merge tag 'arm-newsoc-5.9' > of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc > git bisect good d4db4e553249eda9016fab2e363c26e52c47926f > # good: [fd76a74d940ae3d6b8b2395cd12914630c7e1739] Merge tag > 'audit-pr-20200803' of > git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit > git bisect good fd76a74d940ae3d6b8b2395cd12914630c7e1739 > # bad: [95ffa676583b23baed40861d30b65fe31397da00] Merge branch 'parisc-5.9-1' > of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux > git bisect bad 95ffa676583b23baed40861d30b65fe31397da00 > # bad: [f8b036a7fc231fe6e8297daddee5dffdbbf2581f] Merge tag > 'irq-core-2020-08-04' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad f8b036a7fc231fe6e8297daddee5dffdbbf2581f > # good: [4f30a60aa78410496e5ffe632a371c00f0d83a8d] Merge tag > 'close-range-v5.9' of > git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux > git bisect good 4f30a60aa78410496e5ffe632a371c00f0d83a8d > # good: [8d16f5b979660c0fdcfa21a418cc03f1fde60cf7] genirq: Export > irq_chip_retrigger_hierarchy and irq_chip_set_vcpu_affinity_parent > git bisect good 8d16f5b979660c0fdcfa21a418cc03f1fde60cf7 > # bad: [c9c73a05413ea4a465cae1cb3593b01b190a233f] irqchip/loongson-liointc: > Fix misuse of gc->mask_cache > git bisect bad c9c73a05413ea4a465cae1cb3593b01b190a233f > # bad: [f97dbf48ca43009e8b8bcdf07f47fc9f06149b36] irqchip/mtk-sysirq: Convert > to a platform driver > git bisect bad f97dbf48ca43009e8b8bcdf07f47fc9f06149b36 > # bad: [f97dbf48ca43009e8b8bcdf07f47fc9f06149b36] irqchip/mtk-sysirq: Convert > to a platform driver > git bisect bad f97dbf48ca43009e8b8bcdf07f47fc9f06149b36 //needs change from > 762a21fd45e0 as build-fix > # good: [3af9571cd585efafc2facbd8dbd407317ff898cf] irqchip/gic-v4.1: Ensure > accessing the correct RD when writing INVALLR > git bisect good 3af9571cd585efafc2facbd8dbd407317ff898cf > # good: [f8410e626569324cfe831aaecc0504cafc12b471] irqchip: Add > IRQCHIP_PLATFORM_DRIVER_BEGIN/END and IRQCHIP_MATCH helper macros > git bisect good f8410e626569324cfe831aaecc0504cafc12b471 > # good: [5be57099d44550d2c4cf44a86c44df87edb79a57] irqchip/qcom-pdc: Switch > to using IRQCHIP_PLATFORM_DRIVER helper macros > git bisect good 5be57099d44550d2c4cf44a86c44df87edb79a57 > # first bad commit: [f97dbf48ca43009e8b8bcdf07f47fc9f06149b36] > irqchip/mtk-sysirq: Convert to a platform driver > > regards Frank >
Re: [PATCH v2 1/5] dt-bindings: ARM: Mediatek: Document bindings for MT8192
Hi Weiyu, Thanks for the patch, some comments below. I am not sure what maintainers think but your patches, in general, are really big and I'm wondering if wouldn't be better split by functionalities. Will make your series much longer but easy to review in my opinion. Anyway, I'm going to comment a few files but the comments can be applied to other files. Missatge de Weiyi Lu del dia dc., 29 de jul. 2020 a les 10:46: > > This patch adds the binding documentation for apmixedsys, audsys, > camsys-raw, camsys, imgsys, imp_iic_wrap, infracfg, ipesys, mdpsys, > mfgcfg, mmsys, msdc, pericfg, scp-adsp, topckgen, vdecsys-soc, > vdecsys and vencsys for Mediatek MT8192. > > Signed-off-by: Weiyi Lu > --- > .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 + > .../bindings/arm/mediatek/mediatek,audsys.txt | 1 + > .../bindings/arm/mediatek/mediatek,camsys-raw.yaml | 40 > .../bindings/arm/mediatek/mediatek,camsys.txt | 1 + > .../bindings/arm/mediatek/mediatek,imgsys.txt | 2 + > .../arm/mediatek/mediatek,imp_iic_wrap.yaml| 43 > ++ > .../bindings/arm/mediatek/mediatek,infracfg.txt| 1 + > .../bindings/arm/mediatek/mediatek,ipesys.txt | 1 + > .../bindings/arm/mediatek/mediatek,mdpsys.yaml | 38 +++ > .../bindings/arm/mediatek/mediatek,mfgcfg.txt | 1 + > .../bindings/arm/mediatek/mediatek,mmsys.txt | 1 + > .../bindings/arm/mediatek/mediatek,msdc.yaml | 39 > .../bindings/arm/mediatek/mediatek,pericfg.yaml| 1 + > .../bindings/arm/mediatek/mediatek,scp-adsp.yaml | 38 +++ > .../bindings/arm/mediatek/mediatek,topckgen.txt| 1 + > .../arm/mediatek/mediatek,vdecsys-soc.yaml | 38 +++ > .../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 + > .../bindings/arm/mediatek/mediatek,vencsys.txt | 1 + > 18 files changed, 249 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,imp_iic_wrap.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,mdpsys.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,msdc.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,scp-adsp.yaml > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys-soc.yaml > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt > index bd7a0fa..6942ad4 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt > @@ -17,6 +17,7 @@ Required Properties: > - "mediatek,mt8135-apmixedsys" > - "mediatek,mt8173-apmixedsys" > - "mediatek,mt8183-apmixedsys", "syscon" > + - "mediatek,mt8192-apmixedsys", "syscon" > - "mediatek,mt8516-apmixedsys" > - #clock-cells: Must be 1 > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt > index 38309db..fdcb267 100644 > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt > @@ -12,6 +12,7 @@ Required Properties: > - "mediatek,mt7622-audsys", "syscon" > - "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon" > - "mediatek,mt8183-audiosys", "syscon" > + - "mediatek,mt8192-audsys", "syscon" > - "mediatek,mt8516-audsys", "syscon" > - #clock-cells: Must be 1 > > diff --git > a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml > b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml > new file mode 100644 > index 000..db6f425 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys-raw.yaml > @@ -0,0 +1,40 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/mediatek/mediatek,camsys-raw.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek CAMSYS RAW Controller > + > +maintainers: > + - Weiyi Lu > + > +description: > + The Mediatek camsys raw controller provides various clocks to the system. > + It only provides clocks or also provides configuration registers non-clock related? > +properties: > + compatible: > +items: > + - enum: > + - mediatek,mt8192-camsys_rawa > + - mediatek,mt8192-camsys_rawb > + - mediatek,mt8192-camsys_rawc > + - const: syscon > + > + reg: > +maxItems: 1 > + > + '#clock-cells': > +const: 1 > + > +required: > + - compatible
Re: [PATCH v2 5/5] clk: mediatek: Add MT8192 clock support
Hi Weiyi,
Thank you for your patch. Some few comment below, I'll focus on
clk-mt8192-mm file, but I think can apply to other files too.
[snip]
> diff --git a/drivers/clk/mediatek/clk-mt8192-mm.c
> b/drivers/clk/mediatek/clk-mt8192-mm.c
> new file mode 100644
> index 000..02eef24
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt8192-mm.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0
nit: Although is a valid license identifier for the kernel would be
better to use the non-deprecated form by SPDX, GPL-2.0-only
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +// Author: Weiyi Lu
> +
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-gate.h"
> +
> +#include
> +
> +static const struct mtk_gate_regs mm0_cg_regs = {
> + .set_ofs = 0x104,
> + .clr_ofs = 0x108,
> + .sta_ofs = 0x100,
> +};
> +
> +static const struct mtk_gate_regs mm1_cg_regs = {
> + .set_ofs = 0x114,
> + .clr_ofs = 0x118,
> + .sta_ofs = 0x110,
> +};
> +
> +static const struct mtk_gate_regs mm2_cg_regs = {
> + .set_ofs = 0x1a4,
> + .clr_ofs = 0x1a8,
> + .sta_ofs = 0x1a0,
> +};
> +
> +#define GATE_MM0(_id, _name, _parent, _shift) \
> + GATE_MTK(_id, _name, _parent, &mm0_cg_regs, _shift, \
> + &mtk_clk_gate_ops_setclr)
nit: You can take advantage of the new line length limit, which is now
100 characters.
> +
> +#define GATE_MM1(_id, _name, _parent, _shift) \
> + GATE_MTK(_id, _name, _parent, &mm1_cg_regs, _shift, \
> + &mtk_clk_gate_ops_setclr)
> +
ditto
> +#define GATE_MM2(_id, _name, _parent, _shift) \
> + GATE_MTK(_id, _name, _parent, &mm2_cg_regs, _shift, \
> + &mtk_clk_gate_ops_setclr)
> +
ditto
> +static const struct mtk_gate mm_clks[] = {
> + /* MM0 */
> + GATE_MM0(CLK_MM_DISP_MUTEX0, "mm_disp_mutex0", "disp_sel", 0),
> + GATE_MM0(CLK_MM_DISP_CONFIG, "mm_disp_config", "disp_sel", 1),
> + GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "disp_sel", 2),
> + GATE_MM0(CLK_MM_DISP_RDMA0, "mm_disp_rdma0", "disp_sel", 3),
> + GATE_MM0(CLK_MM_DISP_OVL0_2L, "mm_disp_ovl0_2l", "disp_sel", 4),
> + GATE_MM0(CLK_MM_DISP_WDMA0, "mm_disp_wdma0", "disp_sel", 5),
> + GATE_MM0(CLK_MM_DISP_UFBC_WDMA0, "mm_disp_ufbc_wdma0", "disp_sel", 6),
> + GATE_MM0(CLK_MM_DISP_RSZ0, "mm_disp_rsz0", "disp_sel", 7),
> + GATE_MM0(CLK_MM_DISP_AAL0, "mm_disp_aal0", "disp_sel", 8),
> + GATE_MM0(CLK_MM_DISP_CCORR0, "mm_disp_ccorr0", "disp_sel", 9),
> + GATE_MM0(CLK_MM_DISP_DITHER0, "mm_disp_dither0", "disp_sel", 10),
> + GATE_MM0(CLK_MM_SMI_INFRA, "mm_smi_infra", "disp_sel", 11),
> + GATE_MM0(CLK_MM_DISP_GAMMA0, "mm_disp_gamma0", "disp_sel", 12),
> + GATE_MM0(CLK_MM_DISP_POSTMASK0, "mm_disp_postmask0", "disp_sel", 13),
> + GATE_MM0(CLK_MM_DISP_DSC_WRAP0, "mm_disp_dsc_wrap0", "disp_sel", 14),
> + GATE_MM0(CLK_MM_DSI0, "mm_dsi0", "disp_sel", 15),
> + GATE_MM0(CLK_MM_DISP_COLOR0, "mm_disp_color0", "disp_sel", 16),
> + GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "disp_sel", 17),
> + GATE_MM0(CLK_MM_DISP_FAKE_ENG0, "mm_disp_fake_eng0", "disp_sel", 18),
> + GATE_MM0(CLK_MM_DISP_FAKE_ENG1, "mm_disp_fake_eng1", "disp_sel", 19),
> + GATE_MM0(CLK_MM_MDP_TDSHP4, "mm_mdp_tdshp4", "disp_sel", 20),
> + GATE_MM0(CLK_MM_MDP_RSZ4, "mm_mdp_rsz4", "disp_sel", 21),
> + GATE_MM0(CLK_MM_MDP_AAL4, "mm_mdp_aal4", "disp_sel", 22),
> + GATE_MM0(CLK_MM_MDP_HDR4, "mm_mdp_hdr4", "disp_sel", 23),
> + GATE_MM0(CLK_MM_MDP_RDMA4, "mm_mdp_rdma4", "disp_sel", 24),
> + GATE_MM0(CLK_MM_MDP_COLOR4, "mm_mdp_color4", "disp_sel", 25),
> + GATE_MM0(CLK_MM_DISP_Y2R0, "mm_disp_y2r0", "disp_sel", 26),
> + GATE_MM0(CLK_MM_SMI_GALS, "mm_smi_gals", "disp_sel", 27),
> + GATE_MM0(CLK_MM_DISP_OVL2_2L, "mm_disp_ovl2_2l", "disp_sel", 28),
> + GATE_MM0(CLK_MM_DISP_RDMA4, "mm_disp_rdma4", "disp_sel", 29),
> + GATE_MM0(CLK_MM_DISP_DPI0, "mm_disp_dpi0", "disp_sel", 30),
> + /* MM1 */
> + GATE_MM1(CLK_MM_SMI_IOMMU, "mm_smi_iommu", "disp_sel", 0),
> + /* MM2 */
> + GATE_MM2(CLK_MM_DSI_DSI0, "mm_dsi_dsi0", "disp_sel", 0),
> + GATE_MM2(CLK_MM_DPI_DPI0, "mm_dpi_dpi0", "dpi_sel", 8),
> + GATE_MM2(CLK_MM_26MHZ, "mm_26mhz", "clk26m", 24),
> + GATE_MM2(CLK_MM_32KHZ, "mm_32khz", "clk32k", 25),
> +};
> +
> +static int clk_mt8192_mm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->parent->of_node;
> + struct clk_onecell_data *clk_data;
> +
> + clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
mtk_alloc_clk_data can return NULL
if (!clk_data)
return -ENOMEM;
> +
> + mtk_clk_register_gates(node, mm_clks, ARRAY_SIZE(mm_clks),
> + clk_data);
> +
The above function can
Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data
Hi Yongqiang, Missatge de Yongqiang Niu del dia ds., 25 de jul. 2020 a les 5:29: > > On Thu, 2020-07-23 at 11:32 +0200, Enric Balletbo Serra wrote: > > Hi Yongqiang Niu, > > > > Thank you for your patch. > > > > Missatge de Yongqiang Niu del dia dj., 23 > > de jul. 2020 a les 4:05: > > > > > > add mmsys private data > > > > > > > I think this change requires a better explanation of what you are > > doing. Although I'm really uncomfortable with this change, why you > > need to create a new mt2701-mmsys file? > > reason: > 1.there will more and more Mediatek Soc upstream, and the display path > connection function mtk_mmsys_ddp_mout_en, mtk_mmsys_ddp_sel_in and > mtk_mmsys_ddp_sout_sel will complicated more and more, > 2. many of the connection are only used in some SoC, and useless for > other SoC and not readable, > 3. if we add a new SoC connection, we need check is this affect other > Soc, > > > > > Feature: drm/mediatek > > > > Remove this. > next version will remove this > > > > > Signed-off-by: Yongqiang Niu > > > --- > > > drivers/soc/mediatek/Makefile | 1 + > > > drivers/soc/mediatek/mmsys/Makefile | 2 + > > > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 > > > +++ > > > drivers/soc/mediatek/mtk-mmsys.c | 271 > > > +- > > > include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ > > > 5 files changed, 314 insertions(+), 225 deletions(-) > > > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > > > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > > > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > > > index 2afa7b9..b37ac2c 100644 > > > --- a/drivers/soc/mediatek/Makefile > > > +++ b/drivers/soc/mediatek/Makefile > > > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > > > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > > > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > > > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > > > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > > > diff --git a/drivers/soc/mediatek/mmsys/Makefile > > > b/drivers/soc/mediatek/mmsys/Makefile > > > new file mode 100644 > > > index 000..33b0dab > > > --- /dev/null > > > +++ b/drivers/soc/mediatek/mmsys/Makefile > > > @@ -0,0 +1,2 @@ > > > +# SPDX-License-Identifier: GPL-2.0-only > > > +obj-y += mt2701-mmsys.o > > > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > new file mode 100644 > > > index 000..b8e53b0 > > > --- /dev/null > > > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > @@ -0,0 +1,250 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +// > > > +// Copyright (c) 2020 MediaTek Inc. > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > > > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > > > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > > > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > > > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > > > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > > > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > > > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > > > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > > > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > > > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > > > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > > > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > > > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > > > + > > > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > > > +#define DISP_REG_CONFIG_OUT_SEL0x04c > > > +#define DISP_REG_CONFIG_DSI_SEL0x050 > > > +#define DISP_REG_CONFIG_DPI_SEL0x064 > > > + > > > +#define OVL0_MOUT_EN_COLOR00x1 > > > +#define OD_MOUT_EN_RDMA0 0x1 > > > +#define OD1_MOUT_EN_RDMA1 BIT(16) > > > +#define UFOE_MOUT_EN_DSI
Re: [v7, PATCH 1/7] drm/mediatek: move ddp component defint into mtk_mmsys.h
Hi Yongqian Niu,
Thank you for your patch
Missatge de Yongqiang Niu del dia dj., 23
de jul. 2020 a les 4:05:
>
> move ddp component defint into mtk_mmsys.h
>
There is a typo, should be "defines". But why you should move these
defines to mtk-mmsys?
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34
> +
> drivers/soc/mediatek/mtk-mmsys.c| 4 +---
> include/linux/soc/mediatek/mtk-mmsys.h | 33
> 3 files changed, 35 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index debe363..161201f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -7,6 +7,7 @@
> #define MTK_DRM_DDP_COMP_H
>
> #include
> +#include
>
> struct device;
> struct device_node;
> @@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
> MTK_DDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_AAL1,
> - DDP_COMPONENT_BLS,
> - DDP_COMPONENT_CCORR,
> - DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_COLOR1,
> - DDP_COMPONENT_DITHER,
> - DDP_COMPONENT_DPI0,
> - DDP_COMPONENT_DPI1,
> - DDP_COMPONENT_DSI0,
> - DDP_COMPONENT_DSI1,
> - DDP_COMPONENT_DSI2,
> - DDP_COMPONENT_DSI3,
> - DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD0,
> - DDP_COMPONENT_OD1,
> - DDP_COMPONENT_OVL0,
> - DDP_COMPONENT_OVL_2L0,
> - DDP_COMPONENT_OVL_2L1,
> - DDP_COMPONENT_OVL1,
> - DDP_COMPONENT_PWM0,
> - DDP_COMPONENT_PWM1,
> - DDP_COMPONENT_PWM2,
> - DDP_COMPONENT_RDMA0,
> - DDP_COMPONENT_RDMA1,
> - DDP_COMPONENT_RDMA2,
> - DDP_COMPONENT_UFOE,
> - DDP_COMPONENT_WDMA0,
> - DDP_COMPONENT_WDMA1,
> - DDP_COMPONENT_ID_MAX,
> -};
> -
> struct mtk_ddp_comp;
> struct cmdq_pkt;
> struct mtk_ddp_comp_funcs {
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a55f255..36ad66b 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -5,13 +5,11 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
>
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
> -
> #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
> #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
> #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 7bab5d9..2228bf6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -9,6 +9,39 @@
> enum mtk_ddp_comp_id;
> struct device;
>
> +enum mtk_ddp_comp_id {
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_CCORR,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_COLOR1,
> + DDP_COMPONENT_DITHER,
> + DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> + DDP_COMPONENT_DSI0,
> + DDP_COMPONENT_DSI1,
> + DDP_COMPONENT_DSI2,
> + DDP_COMPONENT_DSI3,
> + DDP_COMPONENT_GAMMA,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_OVL_2L0,
> + DDP_COMPONENT_OVL_2L1,
> + DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_PWM0,
> + DDP_COMPONENT_PWM1,
> + DDP_COMPONENT_PWM2,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_UFOE,
> + DDP_COMPONENT_WDMA0,
> + DDP_COMPONENT_WDMA1,
> + DDP_COMPONENT_ID_MAX,
> +};
> +
> void mtk_mmsys_ddp_connect(struct device *dev,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next);
> --
> 1.8.1.1.dirty
Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data
Hi Yongqiang Niu, Thank you for your patch. Missatge de Yongqiang Niu del dia dj., 23 de jul. 2020 a les 4:05: > > add mmsys private data > I think this change requires a better explanation of what you are doing. Although I'm really uncomfortable with this change, why you need to create a new mt2701-mmsys file? > Feature: drm/mediatek Remove this. > Signed-off-by: Yongqiang Niu > --- > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mmsys/Makefile | 2 + > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ > drivers/soc/mediatek/mtk-mmsys.c | 271 > +- > include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ > 5 files changed, 314 insertions(+), 225 deletions(-) > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > index 2afa7b9..b37ac2c 100644 > --- a/drivers/soc/mediatek/Makefile > +++ b/drivers/soc/mediatek/Makefile > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > diff --git a/drivers/soc/mediatek/mmsys/Makefile > b/drivers/soc/mediatek/mmsys/Makefile > new file mode 100644 > index 000..33b0dab > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +obj-y += mt2701-mmsys.o > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > new file mode 100644 > index 000..b8e53b0 > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > @@ -0,0 +1,250 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (c) 2020 MediaTek Inc. > + > +#include > +#include > +#include > +#include > +#include > + > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > + > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > +#define DISP_REG_CONFIG_OUT_SEL0x04c > +#define DISP_REG_CONFIG_DSI_SEL0x050 > +#define DISP_REG_CONFIG_DPI_SEL0x064 > + > +#define OVL0_MOUT_EN_COLOR00x1 > +#define OD_MOUT_EN_RDMA0 0x1 > +#define OD1_MOUT_EN_RDMA1 BIT(16) > +#define UFOE_MOUT_EN_DSI0 0x1 > +#define COLOR0_SEL_IN_OVL0 0x1 > +#define OVL1_MOUT_EN_COLOR10x1 > +#define GAMMA_MOUT_EN_RDMA10x1 > +#define RDMA0_SOUT_DPI00x2 > +#define RDMA0_SOUT_DPI10x3 > +#define RDMA0_SOUT_DSI10x1 > +#define RDMA0_SOUT_DSI20x4 > +#define RDMA0_SOUT_DSI30x5 > +#define RDMA1_SOUT_DPI00x2 > +#define RDMA1_SOUT_DPI10x3 > +#define RDMA1_SOUT_DSI10x1 > +#define RDMA1_SOUT_DSI20x4 > +#define RDMA1_SOUT_DSI30x5 > +#define RDMA2_SOUT_DPI00x2 > +#define RDMA2_SOUT_DPI10x3 > +#define RDMA2_SOUT_DSI10x1 > +#define RDMA2_SOUT_DSI20x4 > +#define RDMA2_SOUT_DSI30x5 > +#define DPI0_SEL_IN_RDMA1 0x1 > +#define DPI0_SEL_IN_RDMA2 0x3 > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) > +#define DSI0_SEL_IN_RDMA1 0x1 > +#define DSI0_SEL_IN_RDMA2 0x4 > +#define DSI1_SEL_IN_RDMA1 0x1 > +#define DSI1_SEL_IN_RDMA2 0x4 > +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) > +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) > +#define DSI3_SEL_IN_RDMA1 (0x1 << 1
Re: [RESEND RESEND PATCH] arm/arm64: defconfig: Update configs to use the new CROS_EC options
Hi arm/arm64 maintainers, Missatge de Enric Balletbo i Serra del dia dj., 5 de març 2020 a les 12:11: > > We refactored the CrOS EC drivers moving part of the code from the MFD > subsystem to the platform chrome subsystem. During this change we needed > to rename some config options, so, update the defconfigs accordingly. > > Signed-off-by: Enric Balletbo i Serra > Acked-by: Krzysztof Kozlowski > Reviewed-by: Gwendal Grignou > Tested-by: Gwendal Grignou > Acked-by: Lee Jones > --- A gentle ping. I'd like to land this if is possible because that way I can remove some legacy code in platform/chrome subsystem. Thanks, Enric > Dear all, > > This is a resend of a resend patch [3]. In some previous discussions > maintainers would prefer to have this merged through the arm-soc tree > but wasn't merged yet and I forget to ping again, hence, sending a new > resend. > > To give some context to some discussions that can arise again (i.e > whether some symbols should be built-in or not) please look at the > previous resends [1] and [2]. > > Thanks, > Enric > > [1] https://lkml.org/lkml/2019/8/23/518 > [2] https://lkml.org/lkml/2019/8/23/475 > [3] https://patchwork.kernel.org/patch/11267741/ > > arch/arm/configs/exynos_defconfig | 4 +++- > arch/arm/configs/multi_v7_defconfig | 5 - > arch/arm/configs/pxa_defconfig | 4 +++- > arch/arm/configs/tegra_defconfig| 2 +- > arch/arm64/configs/defconfig| 5 - > 5 files changed, 15 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index c8e0c14092e8..cb030549dd69 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -160,7 +160,9 @@ CONFIG_DEVFREQ_THERMAL=y > CONFIG_THERMAL_EMULATION=y > CONFIG_WATCHDOG=y > CONFIG_S3C2410_WATCHDOG=y > -CONFIG_MFD_CROS_EC=y > +CONFIG_MFD_CROS_EC_DEV=y > +CONFIG_CHROME_PLATFORMS=y > +CONFIG_CROS_EC=y > CONFIG_MFD_MAX14577=y > CONFIG_MFD_MAX77686=y > CONFIG_MFD_MAX77693=y > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 017d65f86eba..9099787ccf70 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -938,7 +938,7 @@ CONFIG_SERIO_NVEC_PS2=y > CONFIG_NVEC_POWER=y > CONFIG_NVEC_PAZ00=y > CONFIG_STAGING_BOARD=y > -CONFIG_MFD_CROS_EC=m > +CONFIG_MFD_CROS_EC_DEV=m > CONFIG_CROS_EC_I2C=m > CONFIG_CROS_EC_SPI=m > CONFIG_COMMON_CLK_MAX77686=y > @@ -1118,3 +1118,6 @@ CONFIG_CMA_SIZE_MBYTES=64 > CONFIG_PRINTK_TIME=y > CONFIG_MAGIC_SYSRQ=y > CONFIG_DEBUG_FS=y > +CONFIG_CHROME_PLATFORMS=y > +CONFIG_CROS_EC=m > +CONFIG_CROS_EC_CHARDEV=m > diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig > index b817c57f05f1..f1b084ace88d 100644 > --- a/arch/arm/configs/pxa_defconfig > +++ b/arch/arm/configs/pxa_defconfig > @@ -393,7 +393,9 @@ CONFIG_SA1100_WATCHDOG=m > CONFIG_MFD_AS3711=y > CONFIG_MFD_BCM590XX=m > CONFIG_MFD_AXP20X=y > -CONFIG_MFD_CROS_EC=m > +CONFIG_MFD_CROS_EC_DEV=m > +CONFIG_CHROME_PLATFORMS=y > +CONFIG_CROS_EC=m > CONFIG_CROS_EC_I2C=m > CONFIG_CROS_EC_SPI=m > CONFIG_MFD_ASIC3=y > diff --git a/arch/arm/configs/tegra_defconfig > b/arch/arm/configs/tegra_defconfig > index a27592d3b1fa..7bfae67d2016 100644 > --- a/arch/arm/configs/tegra_defconfig > +++ b/arch/arm/configs/tegra_defconfig > @@ -147,7 +147,7 @@ CONFIG_SENSORS_LM95245=y > CONFIG_WATCHDOG=y > CONFIG_TEGRA_WATCHDOG=y > CONFIG_MFD_AS3722=y > -CONFIG_MFD_CROS_EC=y > +CONFIG_MFD_CROS_EC_DEV=y > CONFIG_MFD_MAX8907=y > CONFIG_MFD_STMPE=y > CONFIG_MFD_PALMAS=y > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 905109f6814f..2095e61c8665 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -705,9 +705,12 @@ CONFIG_VIRTIO_BALLOON=y > CONFIG_VIRTIO_MMIO=y > CONFIG_XEN_GNTDEV=y > CONFIG_XEN_GRANT_DEV_ALLOC=y > -CONFIG_MFD_CROS_EC=y > +CONFIG_MFD_CROS_EC_DEV=y > +CONFIG_CHROME_PLATFORMS=y > +CONFIG_CROS_EC=y > CONFIG_CROS_EC_I2C=y > CONFIG_CROS_EC_SPI=y > +CONFIG_CROS_EC_CHARDEV=m > CONFIG_COMMON_CLK_RK808=y > CONFIG_COMMON_CLK_SCPI=y > CONFIG_COMMON_CLK_CS2000_CP=y > -- > 2.25.1 >
Re: [PATCH v8 3/3] PM / AVS: SVS: Introduce SVS engine
Hi Roger, Thank you for your patch. I have the feeling that this driver is complex and difficult to follow and I am wondering if it wouldn't be better if you can send a version that simply adds basic functionality for now. Some comments below. Missatge de Roger Lu del dia dl., 18 de maig 2020 a les 11:25: > > The SVS (Smart Voltage Scaling) engine is a piece > of hardware which is used to calculate optimized > voltage values of several power domains, > e.g. CPU/GPU/CCI, according to chip process corner, > temperatures, and other factors. Then DVFS driver > could apply those optimized voltage values to reduce > power consumption. > > Signed-off-by: Roger Lu > --- > drivers/power/avs/Kconfig | 10 + > drivers/power/avs/Makefile|1 + > drivers/power/avs/mtk_svs.c | 2119 + > include/linux/power/mtk_svs.h | 23 + > 4 files changed, 2153 insertions(+) > create mode 100644 drivers/power/avs/mtk_svs.c > create mode 100644 include/linux/power/mtk_svs.h > > diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig > index cdb4237bfd02..67089ac6040e 100644 > --- a/drivers/power/avs/Kconfig > +++ b/drivers/power/avs/Kconfig > @@ -35,3 +35,13 @@ config ROCKCHIP_IODOMAIN > Say y here to enable support io domains on Rockchip SoCs. It is > necessary for the io domain setting of the SoC to match the > voltage supplied by the regulators. > + > +config MTK_SVS > + bool "MediaTek Smart Voltage Scaling(SVS)" Can't be this a module? Why? In such case, you should use tristate option > + depends on POWER_AVS && MTK_EFUSE && NVMEM > + help > + The SVS engine is a piece of hardware which is used to calculate > + optimized voltage values of several power domains, e.g. > + CPU clusters/GPU/CCI, according to chip process corner, > temperatures, > + and other factors. Then DVFS driver could apply those optimized > voltage > + values to reduce power consumption. > diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile > index 9007d05853e2..231adf078582 100644 > --- a/drivers/power/avs/Makefile > +++ b/drivers/power/avs/Makefile > @@ -2,3 +2,4 @@ > obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o > obj-$(CONFIG_QCOM_CPR) += qcom-cpr.o > obj-$(CONFIG_ROCKCHIP_IODOMAIN)+= rockchip-io-domain.o > +obj-$(CONFIG_MTK_SVS) += mtk_svs.o Will this driver be SoC specific or the idea is to support different SoCs? If the answer to the first question is yes, please name the file with the SoC prefix (i.e mt8183_svs). However, If the answer to the second question is yes, make sure you prefix common functions/structs/defines with a generic prefix mtk_svs but use the SoC prefix for the ones you expect will be different between SoC, i.e mt8183_svs_. This helps the readability of the driver. Also, try to avoid too generic names. > diff --git a/drivers/power/avs/mtk_svs.c b/drivers/power/avs/mtk_svs.c > new file mode 100644 > index ..a4083b3ef175 > --- /dev/null > +++ b/drivers/power/avs/mtk_svs.c > @@ -0,0 +1,2119 @@ > +// SPDX-License-Identifier: GPL-2.0 I suspect you want this only GPLv2 compliant. Use GPL-2.0-only > +/* > + * Copyright (C) 2020 MediaTek Inc. > + */ > + > +#define pr_fmt(fmt)"[mtk_svs] " fmt I don't see any reason to use pr_fmt in this driver. Use dev_* functions instead and remove the above. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* svs 1-line sw id */ > +#define SVS_CPU_LITTLE BIT(0) > +#define SVS_CPU_BIGBIT(1) > +#define SVS_CCIBIT(2) > +#define SVS_GPUBIT(3) > + > +/* svs bank mode support */ > +#define SVSB_MODE_ALL_DISABLE (0) nit: SVS_BMODE_? > +#define SVSB_MODE_INIT01 BIT(1) > +#define SVSB_MODE_INIT02 BIT(2) > +#define SVSB_MODE_MON BIT(3) > + > +/* svs bank init01 condition */ > +#define SVSB_INIT01_VOLT_IGNOREBIT(1) > +#define SVSB_INIT01_VOLT_INC_ONLY BIT(2) > + > +/* svs bank common setting */ > +#define HIGH_TEMP_MAX (U32_MAX) nit: SVS_* > +#define RUNCONFIG_DEFAULT (0x8000) Btw, there is any public datasheet where I can see those addresses and registers and bit fields? > +#define DC_SIGNED_BIT (0x8000) > +#define INTEN_INIT0x (0x5f01) > +#define INTEN_MONVOPEN (0x00ff) > +#define SVSEN_OFF (0x0) > +#define SVSEN_MASK (0x7) > +#define SVSEN_INIT01
Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Chun-Kuang,
Missatge de Chun-Kuang Hu del dia ds., 16 de
maig 2020 a les 12:11:
>
> Hi, Enric:
>
> Enric Balletbo i Serra 於 2020年5月15日 週五
> 上午1:35寫道：
> >
> > Hi again,
> >
> > On 14/5/20 19:12, Enric Balletbo i Serra wrote:
> > > Hi Chun-Kuang,
> > >
> > > On 14/5/20 18:44, Chun-Kuang Hu wrote:
> > >> Hi, Enric:
> > >>
> > >> Enric Balletbo i Serra 於 2020年5月14日 週四
> > >> 下午11:42寫道：
> > >>>
> > >>> Hi Chun-Kuang,
> > >>>
> > >>> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> > >>>> Hi, Enric:
> > >>>>
> > >>>> Enric Balletbo Serra 於 2020年5月14日 週四 上午12:41寫道：
> > >>>>>
> > >>>>> Hi Chun-Kuang,
> > >>>>>
> > >>>>> Missatge de Enric Balletbo i Serra del
> > >>>>> dia dv., 1 de maig 2020 a les 17:25:
> > >>>>>>
> > >>>>>> Use the drm_bridge_connector helper to create a connector for
> > >>>>>> pipelines
> > >>>>>> that use drm_bridge. This allows splitting connector operations
> > >>>>>> across
> > >>>>>> multiple bridges when necessary, instead of having the last bridge in
> > >>>>>> the chain creating the connector and handling all connector
> > >>>>>> operations
> > >>>>>> internally.
> > >>>>>>
> > >>>>>> Signed-off-by: Enric Balletbo i Serra
> > >>>>>> Acked-by: Sam Ravnborg
> > >>>>>
> > >>>>> A gentle ping on this, I think that this one is the only one that
> > >>>>> still needs a review in the series.
> > >>>>
> > >>>> This is what I reply in patch v3:
> > >>>>
> > >>>
> > >>> Sorry for missing this.
> > >>>
> > >>>> I think the panel is wrapped into next_bridge here,
> > >>>>
> > >>>
> > >>> Yes, you can have for example:
> > >>>
> > >>> 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) ->
> > >>> drm_panel_bridge
> > >>> (edp panel)
> > >>>
> > >>> or a
> > >>>
> > >>> 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel)
> > >>>
> > >>> The _first_ one is my use case
> > >>>
> > >>>> if (panel) {
> > >>>
> > >>> This handles the second case, where you attach a dsi panel.
> > >>>
> > >>>> dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
> > >>>>
> > >>>> so the next_bridge is a panel_bridge, in its attach function
> > >>>> panel_bridge_attach(),
> > >>>> according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
> > >>>> it would create connector and attach connector to panel.
> > >>>>
> > >>>> I'm not sure this flag would exist or not, but for both case, it's
> > >>>> strange.
> > >>>> If exist, you create connector in this patch but no where to attach
> > >>>> connector to panel.
> > >>>
> > >>> Yes, in fact, this is transitional patch needed, as once I converted
> > >>> mtk_dpi,
> > >>> mtk_dsi and mtk_hdmi to the new drm_bridge API the
> > >>> drm_bridge_connector_init()
> > >>> will be done in mtk_drm_drv. We will need to call
> > >>> drm_bridge_connector_init for
> > >>> dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi
> > >>> drivers. The
> > >>> graphic controller driver should create connectors and CRTCs, as
> > >>> example you can
> > >>> take a look at drivers/gpu/drm/omapdrm/omap_drv.c
> > >>>
> > >>
> > >> I have such question because I've reviewed omap's driver. In omap's
> > >> driver, after it call drm_bridge_connector_init(), it does this:
> > >>
> > >> if (pipe->output->panel) {
> > >> ret = drm_panel_attach(pipe->output->panel,
> > >> pipe->connector);
> > >> if (ret < 0)
> > >> return ret;
> > >> }
Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Chun-Kuang,
Missatge de Enric Balletbo i Serra del
dia dv., 1 de maig 2020 a les 17:25:
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Sam Ravnborg
A gentle ping on this, I think that this one is the only one that
still needs a review in the series.
Thanks,
Enric
> ---
>
> Changes in v4: None
> Changes in v3:
> - Move the bridge.type line to the patch that adds drm_bridge support.
> (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 4f3bd095c1ee..471fcafdf348 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -183,6 +184,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> + struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> */
> dsi->encoder.possible_crtcs = 1;
>
> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> + if (IS_ERR(dsi->connector)) {
> + DRM_ERROR("Unable to create bridge connector\n");
> + ret = PTR_ERR(dsi->connector);
> + goto err_cleanup_encoder;
> + }
> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> +
> return 0;
>
> err_cleanup_encoder:
> --
> 2.26.2
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v3 5/5] [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality
Hi Eizan,
Missatge de Eizan Miyamoto del dia dj., 7 de maig
2020 a les 12:26:
>
> Since components are registered in a list, the numeric component id that
> specified a location in an array is not necessary.
>
> Signed-off-by: Eizan Miyamoto
It looks good to me, so
Reviewed-by: Enric Balletbo i Serra
> ---
>
> Changes in v3:
> - Removed extra Signed-off-by: tag from commit messages.
> - Removed extra line break in mtk_mdp_core.c
> - Update cover letter with dependent commit
>
> Changes in v2:
> - rebase onto linux-next/master to pick up
> 757570f11fa4b0ce5472a6583de6f06e996a8527
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 +++
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 19 +-
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 9 +--
> 3 files changed, 10 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index da2bdad7a8d1..362fff924aef 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -14,46 +14,6 @@
> #include "mtk_mdp_comp.h"
>
>
> -static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
> - "mdp-rdma",
> - "mdp-rsz",
> - "mdp-wdma",
> - "mdp-wrot",
> -};
> -
> -struct mtk_mdp_comp_match {
> - enum mtk_mdp_comp_type type;
> - int alias_id;
> -};
> -
> -static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX]
> = {
> - { MTK_MDP_RDMA, 0 },
> - { MTK_MDP_RDMA, 1 },
> - { MTK_MDP_RSZ, 0 },
> - { MTK_MDP_RSZ, 1 },
> - { MTK_MDP_RSZ, 2 },
> - { MTK_MDP_WDMA, 0 },
> - { MTK_MDP_WROT, 0 },
> - { MTK_MDP_WROT, 1 },
> -};
> -
> -int mtk_mdp_comp_get_id(struct device *dev, struct device_node *node,
> - enum mtk_mdp_comp_type comp_type)
> -{
> - int id = of_alias_get_id(node, mtk_mdp_comp_stem[comp_type]);
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(mtk_mdp_matches); i++) {
> - if (comp_type == mtk_mdp_matches[i].type &&
> - id == mtk_mdp_matches[i].alias_id)
> - return i;
> - }
> -
> - dev_err(dev, "Failed to get id. type: %d, id: %d\n", comp_type, id);
> -
> - return -EINVAL;
> -}
> -
> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> {
> int i, err;
> @@ -62,8 +22,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = mtk_smi_larb_get(comp->larb_dev);
> if (err)
> dev_err(dev,
> - "failed to get larb, err %d. type:%d id:%d\n",
> - err, comp->type, comp->id);
> + "failed to get larb, err %d. type:%d\n",
> + err, comp->type);
> }
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> @@ -72,8 +32,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = clk_prepare_enable(comp->clk[i]);
> if (err)
> dev_err(dev,
> - "failed to enable clock, err %d. type:%d id:%d
> i:%d\n",
> - err, comp->type, comp->id, i);
> + "failed to enable clock, err %d. type:%d i:%d\n",
> + err, comp->type, i);
> }
> }
>
> @@ -92,21 +52,15 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
> mtk_mdp_comp *comp)
> }
>
> int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> - struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
> + struct mtk_mdp_comp *comp,
> + enum mtk_mdp_comp_type comp_type)
> {
> struct device_node *larb_node;
> struct platform_device *larb_pdev;
> int i;
>
> - if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
> - dev_err(dev, "Invalid comp_id %d\n", comp_id);
> - return -EINVAL;
> - }
> -
> - INIT_LIST_HEAD(&comp->node);
> comp->dev_node = of_node_get(node);
> - comp->id = comp_id;
> - comp->type = mtk_mdp_matches[comp_id].type;
> + comp->type = comp_type;
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> comp->clk[i] = of_clk_get(node, i);
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> index 1f745891c6c3..1bf0242cce46 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> @@ -22,18 +22,6 @@ enum mtk_mdp_comp_type {
> MTK_MDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_mdp_comp_id {
> - MTK_MDP_COMP_RDMA0,
> - MTK_MDP_COMP_RDMA1,
> - MTK_MDP_COMP_RSZ0,
> - MTK_M
Re: [PATCH v2 2/2] [media] mtk-mdp: use pm_runtime in MDP component driver
Hi Eizan,
Thank you for the patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 10:42:
>
> Without this change, the MDP components are not fully integrated into
> the runtime power management subsystem, and the MDP driver does not
> work.
>
> For each of the component device drivers to be able to call
> pm_runtime_get/put_sync() a pointer to the component's device struct
> had to be added to struct mtk_mdp_comp, set by mtk_mdp_comp_init().
>
> Note that the dev argument to mtk_mdp_comp_clock_on/off() has been
> removed. Those functions used to be called from the "master" mdp driver
> in mtk_mdp_core.c, but the component's device pointer no longer
> corresponds to the mdp master device pointer, which is not the right
> device to pass to pm_runtime_put/get_sync() which we had to add to get
> the driver to work properly.
>
> Signed-off-by: Eizan Miyamoto
> ---
>
> Changes in v2:
Ah, I guess this change log corresponds to the first patch.
> - remove empty mtk_mdp_comp_init
> - update documentation for enum mtk_mdp_comp_type
> - remove comma after last element of mtk_mdp_comp_driver_dt_match
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 22 ++-
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 6 +++--
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 6 ++---
> 3 files changed, 23 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index 5b4d482df778..228c58f92c8c 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_mdp_comp.h"
> #include "mtk_mdp_core.h"
> @@ -53,7 +54,7 @@ static const struct of_device_id
> mtk_mdp_comp_driver_dt_match[] = {
> };
> MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
>
> -void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> +void mtk_mdp_comp_clock_on(struct mtk_mdp_comp *comp)
> {
> int i, err;
>
> @@ -62,25 +63,31 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> if (err) {
> enum mtk_mdp_comp_type comp_type =
> (enum mtk_mdp_comp_type)
> - of_device_get_match_data(dev);
> - dev_err(dev,
> + of_device_get_match_data(comp->dev);
> + dev_err(comp->dev,
> "failed to get larb, err %d. type:%d\n",
> err, comp_type);
> }
> }
>
> + err = pm_runtime_get_sync(comp->dev);
> + if (err < 0)
> + dev_err(comp->dev,
> + "failed to runtime get, err %d.\n",
> + err);
Should you really ignore this error? If that's the case I'd just call
pm_runtime_get_sync() without adding the logic to just print an error
message.
> +
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> if (IS_ERR(comp->clk[i]))
> continue;
> err = clk_prepare_enable(comp->clk[i]);
> if (err)
> - dev_err(dev,
> + dev_err(comp->dev,
> "failed to enable clock, err %d. i:%d\n",
> err, i);
Although ignoring errors seems to be a common pattern in this file and
I know you did not introduce this.
> }
> }
>
> -void mtk_mdp_comp_clock_off(struct device *dev, struct mtk_mdp_comp *comp)
> +void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp)
> {
> int i;
>
> @@ -92,6 +99,8 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
> mtk_mdp_comp *comp)
>
> if (comp->larb_dev)
> mtk_smi_larb_put(comp->larb_dev);
> +
> + pm_runtime_put_sync(comp->dev);
> }
>
> static int mtk_mdp_comp_bind(struct device *dev, struct device *master,
> @@ -101,6 +110,7 @@ static int mtk_mdp_comp_bind(struct device *dev, struct
> device *master,
> struct mtk_mdp_dev *mdp = data;
>
> mtk_mdp_register_component(mdp, comp);
> + pm_runtime_enable(dev);
>
> return 0;
> }
> @@ -111,6 +121,7 @@ static void mtk_mdp_comp_unbind(struct device *dev,
> struct device *master,
> struct mtk_mdp_dev *mdp = data;
> struct mtk_mdp_comp *comp = dev_get_drvdata(dev);
>
> + pm_runtime_disable(dev);
> mtk_mdp_unregister_component(mdp, comp);
> }
>
> @@ -129,6 +140,7 @@ int mtk_mdp_comp_init(struct mtk_mdp_comp *comp, struct
> device *dev)
> (enum mtk_mdp_comp_type)of_device_get_match_data(dev);
>
> INIT_LIST_HEAD(&comp->node);
> + comp->dev = dev;
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> comp->clk[i] = of_clk_get(node, i);
> dif
Re: [PATCH v2 1/2] [media] mtk-mdp: add driver to probe mdp components
Hi Eizan,
Thank you for the patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 10:41:
>
> Broadly, this patch (1) adds a driver for various MTK MDP components to
> go alongside the main MTK MDP driver, and (2) hooks them all together
> using the component framework.
>
> (1) Up until now, the MTK MDP driver controls 8 devices in the device
> tree on its own. When running tests for the hardware video decoder, we
> found that the iommus and LARBs were not being properly configured. To
> configure them, a driver for each be added to mtk_mdp_comp so that
> mtk_iommu_add_device() can (eventually) be called from dma_configure()
> inside really_probe().
>
> (2) The integration into the component framework allows us to defer the
> registration with the v4l2 subsystem until all the MDP-related devices
> have been probed, so that the relevant device node does not become
> available until initialization of all the components is complete.
>
> Some notes about how the component framework has been integrated:
>
> - The driver for the rdma0 component serves double duty as the "master"
> (aggregate) driver as well as a component driver. This is a non-ideal
> compromise until a better solution is developed. This device is
> differentiated from the rest by checking for a "mediatek,vpu" property
> in the device node.
>
> - The list of mdp components remains hard-coded as mtk_mdp_comp_dt_ids[]
> in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in
> mtk_mdp_comp.c. This unfortunate duplication of information is
> addressed in a following patch in this series.
>
> - The component driver calls component_add() for each device that is
> probed.
>
> - In mtk_mdp_probe (the "master" device), we scan the device tree for
> any matching nodes against mtk_mdp_comp_dt_ids, and add component
> matches for them. The match criteria is a matching device node
> pointer.
>
> - When the set of components devices that have been probed corresponds
> with the list that is generated by the "master", the callback to
> mtk_mdp_master_bind() is made, which then calls the component bind
> functions.
>
> - Inside mtk_mdp_master_bind(), once all the component bind functions
> have been called, we can then register our device to the v4l2
> subsystem.
>
> - The call to pm_runtime_enable() in the master device is called after
> all the components have been registered by their bind() functions
> called by mtk_mtp_master_bind(). As a result, the list of components
> will not change while power management callbacks mtk_mdp_suspend()/
> resume() are accessing the list of components.
>
> Signed-off-by: Eizan Miyamoto
> ---
>
> Changes in v2: None
>
Not really true :-)
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 150 +--
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 26 +--
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 176 +-
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 1 +
> 4 files changed, 263 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index 362fff924aef..5b4d482df778 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -5,14 +5,53 @@
> */
>
> #include
> +#include
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
>
> #include "mtk_mdp_comp.h"
> -
> +#include "mtk_mdp_core.h"
> +
> +/**
> + * enum mtk_mdp_comp_type - the MDP component
> + * @MTK_MDP_RDMA: Read DMA
> + * @MTK_MDP_RSZ: Reszer
> + * @MTK_MDP_WDMA: Write DMA
> + * @MTK_MDP_WROT: Write DMA with rotation
> + * @MTK_MDP_COMP_TYPE_MAX: Placeholder for num elems in this enum
> + */
> +enum mtk_mdp_comp_type {
> + MTK_MDP_RDMA,
> + MTK_MDP_RSZ,
> + MTK_MDP_WDMA,
> + MTK_MDP_WROT,
> + MTK_MDP_COMP_TYPE_MAX,
> +};
> +
> +static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
> + {
> + .compatible = "mediatek,mt8173-mdp-rdma",
> + .data = (void *)MTK_MDP_RDMA
> + }, {
> + .compatible = "mediatek,mt8173-mdp-rsz",
> + .data = (void *)MTK_MDP_RSZ
> + }, {
> + .compatible = "mediatek,mt8173-mdp-wdma",
> + .data = (void *)MTK_MDP_WDMA
> + }, {
> + .compatible = "mediatek,mt8173-mdp-wrot",
> + .data = (void *)MTK_MDP_WROT
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
>
> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> {
> @@ -20,10 +59,14 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
>
> if (comp->larb_dev) {
> err = mtk_smi_larb_get(comp->larb_dev);
> - if (err)
>
Re: [PATCH v2 5/5] [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality
Hi Eizan,
Thank you for the patch. Two trivial comments
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 7:51:
>
> Since components are registered in a list, the numeric component id that
> specified a location in an array is not necessary.
>
> Signed-off-by: ei...@chromium.org
ditto: Drop the above line.
> Signed-off-by: Eizan Miyamoto
> ---
>
> Changes in v1:
> - rebase onto linux-next/master to pick up
> 757570f11fa4b0ce5472a6583de6f06e996a8527
>
You probably should mention this in the cover-letter or as a comment
here to make the maintainer aware of this dependency.
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 +++
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 19 +-
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 +---
> 3 files changed, 11 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index da2bdad7a8d1..362fff924aef 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -14,46 +14,6 @@
> #include "mtk_mdp_comp.h"
>
>
> -static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
> - "mdp-rdma",
> - "mdp-rsz",
> - "mdp-wdma",
> - "mdp-wrot",
> -};
> -
> -struct mtk_mdp_comp_match {
> - enum mtk_mdp_comp_type type;
> - int alias_id;
> -};
> -
> -static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX]
> = {
> - { MTK_MDP_RDMA, 0 },
> - { MTK_MDP_RDMA, 1 },
> - { MTK_MDP_RSZ, 0 },
> - { MTK_MDP_RSZ, 1 },
> - { MTK_MDP_RSZ, 2 },
> - { MTK_MDP_WDMA, 0 },
> - { MTK_MDP_WROT, 0 },
> - { MTK_MDP_WROT, 1 },
> -};
> -
> -int mtk_mdp_comp_get_id(struct device *dev, struct device_node *node,
> - enum mtk_mdp_comp_type comp_type)
> -{
> - int id = of_alias_get_id(node, mtk_mdp_comp_stem[comp_type]);
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(mtk_mdp_matches); i++) {
> - if (comp_type == mtk_mdp_matches[i].type &&
> - id == mtk_mdp_matches[i].alias_id)
> - return i;
> - }
> -
> - dev_err(dev, "Failed to get id. type: %d, id: %d\n", comp_type, id);
> -
> - return -EINVAL;
> -}
> -
> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> {
> int i, err;
> @@ -62,8 +22,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = mtk_smi_larb_get(comp->larb_dev);
> if (err)
> dev_err(dev,
> - "failed to get larb, err %d. type:%d id:%d\n",
> - err, comp->type, comp->id);
> + "failed to get larb, err %d. type:%d\n",
> + err, comp->type);
> }
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> @@ -72,8 +32,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = clk_prepare_enable(comp->clk[i]);
> if (err)
> dev_err(dev,
> - "failed to enable clock, err %d. type:%d id:%d
> i:%d\n",
> - err, comp->type, comp->id, i);
> + "failed to enable clock, err %d. type:%d i:%d\n",
> + err, comp->type, i);
> }
> }
>
> @@ -92,21 +52,15 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
> mtk_mdp_comp *comp)
> }
>
> int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> - struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
> + struct mtk_mdp_comp *comp,
> + enum mtk_mdp_comp_type comp_type)
> {
> struct device_node *larb_node;
> struct platform_device *larb_pdev;
> int i;
>
> - if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
> - dev_err(dev, "Invalid comp_id %d\n", comp_id);
> - return -EINVAL;
> - }
> -
> - INIT_LIST_HEAD(&comp->node);
> comp->dev_node = of_node_get(node);
> - comp->id = comp_id;
> - comp->type = mtk_mdp_matches[comp_id].type;
> + comp->type = comp_type;
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> comp->clk[i] = of_clk_get(node, i);
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> index 1f745891c6c3..1bf0242cce46 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> @@ -22,18 +22,6 @@ enum mtk_mdp_comp_type {
> MTK_MDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_mdp_comp_id {
> - MTK_MDP_COMP_RDMA0,
> - MTK_MDP_COMP_RDMA1,
> - MTK_MDP_COMP_RSZ0,
> - MT
Re: [PATCH v2 3/5] [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 7:51:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
ditto, remove the above line.
> Signed-off-by: Eizan Miyamoto
> ---
Other than that:
Reviewed-by: Enric Balletbo i Serra
>
> Changes in v1:
> - remove unnecessary error handling labels in favor of err_m2m_register
>
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index 9b24b8d46eb7..17d155219ba2 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -188,8 +188,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> }
>
> mdp->vpu_dev = vpu_get_plat_device(pdev);
> - vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> - VPU_RST_MDP);
> + ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> + VPU_RST_MDP);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register reset handler\n");
> + goto err_m2m_register;
> + }
>
> platform_set_drvdata(pdev, mdp);
>
> --
> 2.26.2.526.g744177e7f7-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v2 2/5] [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dc., 6 de maig
2020 a les 7:51:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
As I commented on the first patch you should drop the above line.
> Signed-off-by: Eizan Miyamoto
Other than that:
Reviewed-by: Enric Balletbo i Serra
> ---
>
> Changes in v1:
> - remove unnecessary error handling labels in favor of err_m2m_register
>
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index aeaed2cf4458..9b24b8d46eb7 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -193,7 +193,11 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mdp);
>
> - vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> + ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
> + goto err_m2m_register;
> + }
>
> pm_runtime_enable(dev);
> dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
> --
> 2.26.2.526.g744177e7f7-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 1/2] [media] mtk-mdp: add driver to probe mdp components
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 9:45:
>
> Broadly, this patch (1) adds a driver for various MTK MDP components to
> go alongside the main MTK MDP driver, and (2) hooks them all together
> using the component framework.
>
> (1) Up until now, the MTK MDP driver controls 8 devices in the device
> tree on its own. When running tests for the hardware video decoder, we
> found that the iommus and LARBs were not being properly configured. To
> configure them, a driver for each be added to mtk_mdp_comp so that
> mtk_iommu_add_device() can (eventually) be called from dma_configure()
> inside really_probe().
>
> (2) The integration into the component framework allows us to defer the
> registration with the v4l2 subsystem until all the MDP-related devices
> have been probed, so that the relevant device node does not become
> available until initialization of all the components is complete.
>
> Some notes about how the component framework has been integrated:
>
> - The driver for the rdma0 component serves double duty as the "master"
> (aggregate) driver as well as a component driver. This is a non-ideal
> compromise until a better solution is developed. This device is
> differentiated from the rest by checking for a "mediatek,vpu" property
> in the device node.
>
> - The list of mdp components remains hard-coded as mtk_mdp_comp_dt_ids[]
> in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in
> mtk_mdp_comp.c. This unfortunate duplication of information is
> addressed in a following patch in this series.
>
> - The component driver calls component_add() for each device that is
> probed.
>
> - In mtk_mdp_probe (the "master" device), we scan the device tree for
> any matching nodes against mtk_mdp_comp_dt_ids, and add component
> matches for them. The match criteria is a matching device node
> pointer.
>
> - When the set of components devices that have been probed corresponds
> with the list that is generated by the "master", the callback to
> mtk_mdp_master_bind() is made, which then calls the component bind
> functions.
>
> - Inside mtk_mdp_master_bind(), once all the component bind functions
> have been called, we can then register our device to the v4l2
> subsystem.
>
> - The call to pm_runtime_enable() in the master device is called after
> all the components have been registered by their bind() functions
> called by mtk_mtp_master_bind(). As a result, the list of components
> will not change while power management callbacks mtk_mdp_suspend()/
> resume() are accessing the list of components.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 164 +++--
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 27 +--
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 171 +-
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 1 +
> 4 files changed, 274 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index 362fff924aef..4c77a582c79a 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -5,14 +5,52 @@
> */
>
> #include
> +#include
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
>
> #include "mtk_mdp_comp.h"
> -
> +#include "mtk_mdp_core.h"
> +
> +/**
> + * enum mtk_mdp_comp_type - the MDP component
> + * @MTK_MDP_RDMA: Read DMA
> + * @MTK_MDP_RSZ: Riszer
Typo?
> + * @MTK_MDP_WDMA: Write DMA
> + * @MTK_MDP_WROT: Write DMA with rotation
You should also describe the enum value 'MTK_MDP_COMP_TYPE_MAX',
otherwise, you will get a kernel-doc warning
> + */
> +enum mtk_mdp_comp_type {
> + MTK_MDP_RDMA,
> + MTK_MDP_RSZ,
> + MTK_MDP_WDMA,
> + MTK_MDP_WROT,
> + MTK_MDP_COMP_TYPE_MAX,
> +};
> +
> +static const struct of_device_id mtk_mdp_comp_driver_dt_match[] = {
> + {
> + .compatible = "mediatek,mt8173-mdp-rdma",
> + .data = (void *)MTK_MDP_RDMA
> + }, {
> + .compatible = "mediatek,mt8173-mdp-rsz",
> + .data = (void *)MTK_MDP_RSZ
> + }, {
> + .compatible = "mediatek,mt8173-mdp-wdma",
> + .data = (void *)MTK_MDP_WDMA
> + }, {
> + .compatible = "mediatek,mt8173-mdp-wrot",
> + .data = (void *)MTK_MDP_WROT
> + },
> + { },
nit: No more fields after the sentinel so you can drop the colon at the end.
> +};
> +MODULE_DEVICE_TABLE(of, mtk_mdp_comp_driver_dt_match);
>
> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> {
> @@ -20,10 +58,14 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
>
> if (comp->larb_dev) {
Re: [PATCH v1 4/5] [media] mtk-mdp: convert mtk_mdp_dev.comp array to list
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:02:
>
> The functions mtk_mdp_register/unregister_component have been created to
> add / remove items from the list of components.
>
> This will eventually enable us to specify a list of components in the
> device tree instead of hardcoding them into this driver.
>
> The list is modified by a single thread at driver probe time, and will
> not be traversed by another thread until the call to pm_runtime_enable
> at the end of probing.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Ditto. Other than that.
Reviewed-by: Enric Balletbo i Serra
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 +
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 +
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 46 +--
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 10 +++-
> 4 files changed, 43 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index facc6104b91f..d4afed1363d5 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -103,6 +103,7 @@ int mtk_mdp_comp_init(struct device *dev, struct
> device_node *node,
> return -EINVAL;
> }
>
> + INIT_LIST_HEAD(&comp->node);
> comp->dev_node = of_node_get(node);
> comp->id = comp_id;
> comp->type = mtk_mdp_matches[comp_id].type;
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> index 3b83bd6e0d8b..1f745891c6c3 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> @@ -36,6 +36,7 @@ enum mtk_mdp_comp_id {
>
> /**
> * struct mtk_mdp_comp - the MDP's function component data
> + * @node: list node to track sibing MDP components
> * @dev_node: component device node
> * @clk: clocks required for component
> * @larb_dev: SMI device required for component
> @@ -43,6 +44,7 @@ enum mtk_mdp_comp_id {
> * @id:component ID
> */
> struct mtk_mdp_comp {
> + struct list_headnode;
> struct device_node *dev_node;
> struct clk *clk[2];
> struct device *larb_dev;
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index f974242663dc..e6e702d9cb69 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -55,19 +55,19 @@ MODULE_DEVICE_TABLE(of, mtk_mdp_of_ids);
> static void mtk_mdp_clock_on(struct mtk_mdp_dev *mdp)
> {
> struct device *dev = &mdp->pdev->dev;
> - int i;
> + struct mtk_mdp_comp *comp_node;
>
> - for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
> - mtk_mdp_comp_clock_on(dev, mdp->comp[i]);
> + list_for_each_entry(comp_node, &mdp->comp_list, node)
> + mtk_mdp_comp_clock_on(dev, comp_node);
> }
>
> static void mtk_mdp_clock_off(struct mtk_mdp_dev *mdp)
> {
> struct device *dev = &mdp->pdev->dev;
> - int i;
> + struct mtk_mdp_comp *comp_node;
>
> - for (i = 0; i < ARRAY_SIZE(mdp->comp); i++)
> - mtk_mdp_comp_clock_off(dev, mdp->comp[i]);
> + list_for_each_entry(comp_node, &mdp->comp_list, node)
> + mtk_mdp_comp_clock_off(dev, comp_node);
> }
>
> static void mtk_mdp_wdt_worker(struct work_struct *work)
> @@ -91,12 +91,25 @@ static void mtk_mdp_reset_handler(void *priv)
> queue_work(mdp->wdt_wq, &mdp->wdt_work);
> }
>
> +void mtk_mdp_register_component(struct mtk_mdp_dev *mdp,
> + struct mtk_mdp_comp *comp)
> +{
> + list_add(&mdp->comp_list, &comp->node);
> +}
> +
> +void mtk_mdp_unregister_component(struct mtk_mdp_dev *mdp,
> + struct mtk_mdp_comp *comp)
> +{
> + list_del(&comp->node);
> +}
> +
> static int mtk_mdp_probe(struct platform_device *pdev)
> {
> struct mtk_mdp_dev *mdp;
> struct device *dev = &pdev->dev;
> struct device_node *node, *parent;
> - int i, ret = 0;
> + struct mtk_mdp_comp *comp, *comp_temp;
> + int ret = 0;
>
> mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
> if (!mdp)
> @@ -104,6 +117,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>
> mdp->id = pdev->id;
> mdp->pdev = pdev;
> + INIT_LIST_HEAD(&mdp->comp_list);
> INIT_LIST_HEAD(&mdp->ctx_list);
>
> mutex_init(&mdp->lock);
> @@ -124,7 +138,6 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> const struct of_device_id *of_id;
> enum mtk_mdp_comp_type comp_type;
> int comp_id;
> - struct mtk_mdp_comp *comp;
>
Re: [PATCH v1 1/5] [media] mtk-mdp: remove mtk_mdp_comp.regs from mtk_mdp_comp.h
Hi Eizan,
Thank you for your patch. One trivial comment below ...
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> These fields are not used and can be removed.
>
> Signed-off-by: ei...@chromium.org
Malformatted Signed-off-by tag. Drop it.
> Signed-off-by: Eizan Miyamoto
Note that the author/seder should match the Signed-off-by, so you
should use your chromium.org account here. Other than that the patch
looks good to me, so
Reviewed-by: Enric Balletbo i Serra
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 1 -
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 2 --
> 2 files changed, 3 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index 14991685adb7..facc6104b91f 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -106,7 +106,6 @@ int mtk_mdp_comp_init(struct device *dev, struct
> device_node *node,
> comp->dev_node = of_node_get(node);
> comp->id = comp_id;
> comp->type = mtk_mdp_matches[comp_id].type;
> - comp->regs = of_iomap(node, 0);
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> comp->clk[i] = of_clk_get(node, i);
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> index 998a4b953025..3b83bd6e0d8b 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> @@ -38,7 +38,6 @@ enum mtk_mdp_comp_id {
> * struct mtk_mdp_comp - the MDP's function component data
> * @dev_node: component device node
> * @clk: clocks required for component
> - * @regs: Mapped address of component registers.
> * @larb_dev: SMI device required for component
> * @type: component type
> * @id:component ID
> @@ -46,7 +45,6 @@ enum mtk_mdp_comp_id {
> struct mtk_mdp_comp {
> struct device_node *dev_node;
> struct clk *clk[2];
> - void __iomem*regs;
> struct device *larb_dev;
> enum mtk_mdp_comp_type type;
> enum mtk_mdp_comp_idid;
> --
> 2.26.2.526.g744177e7f7-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 2/5] [media] mtk-mdp: handle vb2_dma_contig_set_max_seg_size errors during probe
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Same comment as the first patch. You should probably fix your configuration.
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index aeaed2cf4458..c20ac7681c6f 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -193,13 +193,19 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mdp);
>
> - vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> + ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n");
> + goto err_set_max_seg_size;
You don't need to introduce a new label, just goto err_m2m_register
> + }
>
> pm_runtime_enable(dev);
> dev_dbg(dev, "mdp-%d registered successfully\n", mdp->id);
>
> return 0;
>
> +err_set_max_seg_size:
> +
> err_m2m_register:
> v4l2_device_unregister(&mdp->v4l2_dev);
>
> --
> 2.26.2.526.g744177e7f7-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 3/5] [media] mtk-mdp: handle vpu_wdt_reg_handler() errors during probe
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:01:
>
> This is a cleanup to better handle errors during MDP probe.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Ditto
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index c20ac7681c6f..f974242663dc 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -188,8 +188,12 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> }
>
> mdp->vpu_dev = vpu_get_plat_device(pdev);
> - vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> - VPU_RST_MDP);
> + ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp,
> + VPU_RST_MDP);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register reset handler\n");
> + goto err_wdt_reg;
No need to introduce a new label, just goto err_m2m_register
> + }
>
> platform_set_drvdata(pdev, mdp);
>
> @@ -206,6 +210,8 @@ static int mtk_mdp_probe(struct platform_device *pdev)
>
> err_set_max_seg_size:
>
> +err_wdt_reg:
> +
> err_m2m_register:
> v4l2_device_unregister(&mdp->v4l2_dev);
>
> --
> 2.26.2.526.g744177e7f7-goog
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1 5/5] [media] mtk-mdp: Remove mtk_mdp_comp.id and supporting functionality
Hi Eizan,
Thank you for your patch.
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 6:02:
>
> Since components are registered in a list, the numeric component id that
> specified a location in an array is not necessary.
>
> Signed-off-by: ei...@chromium.org
> Signed-off-by: Eizan Miyamoto
Ditto
> ---
>
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 60 +++
This patch will conflict with this one [1]. It is already queued,
please rebase on top of it.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c?id=757570f11fa4b0ce5472a6583de6f06e996a8527
> drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 19 +-
> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 10 +---
> 3 files changed, 11 insertions(+), 78 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> index d4afed1363d5..362fff924aef 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> @@ -14,46 +14,6 @@
> #include "mtk_mdp_comp.h"
>
>
> -static const char * const mtk_mdp_comp_stem[MTK_MDP_COMP_TYPE_MAX] = {
> - "mdp_rdma",
> - "mdp_rsz",
> - "mdp_wdma",
> - "mdp_wrot",
> -};
> -
> -struct mtk_mdp_comp_match {
> - enum mtk_mdp_comp_type type;
> - int alias_id;
> -};
> -
> -static const struct mtk_mdp_comp_match mtk_mdp_matches[MTK_MDP_COMP_ID_MAX]
> = {
> - { MTK_MDP_RDMA, 0 },
> - { MTK_MDP_RDMA, 1 },
> - { MTK_MDP_RSZ, 0 },
> - { MTK_MDP_RSZ, 1 },
> - { MTK_MDP_RSZ, 2 },
> - { MTK_MDP_WDMA, 0 },
> - { MTK_MDP_WROT, 0 },
> - { MTK_MDP_WROT, 1 },
> -};
> -
> -int mtk_mdp_comp_get_id(struct device *dev, struct device_node *node,
> - enum mtk_mdp_comp_type comp_type)
> -{
> - int id = of_alias_get_id(node, mtk_mdp_comp_stem[comp_type]);
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(mtk_mdp_matches); i++) {
> - if (comp_type == mtk_mdp_matches[i].type &&
> - id == mtk_mdp_matches[i].alias_id)
> - return i;
> - }
> -
> - dev_err(dev, "Failed to get id. type: %d, id: %d\n", comp_type, id);
> -
> - return -EINVAL;
> -}
> -
> void mtk_mdp_comp_clock_on(struct device *dev, struct mtk_mdp_comp *comp)
> {
> int i, err;
> @@ -62,8 +22,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = mtk_smi_larb_get(comp->larb_dev);
> if (err)
> dev_err(dev,
> - "failed to get larb, err %d. type:%d id:%d\n",
> - err, comp->type, comp->id);
> + "failed to get larb, err %d. type:%d\n",
> + err, comp->type);
> }
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> @@ -72,8 +32,8 @@ void mtk_mdp_comp_clock_on(struct device *dev, struct
> mtk_mdp_comp *comp)
> err = clk_prepare_enable(comp->clk[i]);
> if (err)
> dev_err(dev,
> - "failed to enable clock, err %d. type:%d id:%d
> i:%d\n",
> - err, comp->type, comp->id, i);
> + "failed to enable clock, err %d. type:%d i:%d\n",
> + err, comp->type, i);
> }
> }
>
> @@ -92,21 +52,15 @@ void mtk_mdp_comp_clock_off(struct device *dev, struct
> mtk_mdp_comp *comp)
> }
>
> int mtk_mdp_comp_init(struct device *dev, struct device_node *node,
> - struct mtk_mdp_comp *comp, enum mtk_mdp_comp_id comp_id)
> + struct mtk_mdp_comp *comp,
> + enum mtk_mdp_comp_type comp_type)
> {
> struct device_node *larb_node;
> struct platform_device *larb_pdev;
> int i;
>
> - if (comp_id < 0 || comp_id >= MTK_MDP_COMP_ID_MAX) {
> - dev_err(dev, "Invalid comp_id %d\n", comp_id);
> - return -EINVAL;
> - }
> -
> - INIT_LIST_HEAD(&comp->node);
> comp->dev_node = of_node_get(node);
> - comp->id = comp_id;
> - comp->type = mtk_mdp_matches[comp_id].type;
> + comp->type = comp_type;
>
> for (i = 0; i < ARRAY_SIZE(comp->clk); i++) {
> comp->clk[i] = of_clk_get(node, i);
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> index 1f745891c6c3..1bf0242cce46 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> @@ -22,18 +22,6 @@ enum mtk_mdp_comp_type {
> MTK_MDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_mdp_comp_id {
> - MTK_MDP_COMP_RDMA0,
> - MTK_MDP_COMP_RDMA1,
> - MTK_MDP_COMP_RSZ0,
> - MTK_MDP_CO
Re: [PATCH v1] [media] mtk-mdp: Remove states for format checks
Hi Eizan,
Thank you for your patch. Two trivial comments, see below ...
Missatge de Eizan Miyamoto del dia dt., 5 de maig
2020 a les 4:07:
>
> From: Francois Buergisser
>
> The mtk-mdp driver uses states to check if the formats have been set
> on the capture and output when turning the streaming on, setting
> controls or setting the selection rectangles.
> Those states are reset when 0 buffers are requested like when checking
> capabilities.
> This patch removes all format checks and set one by default as queues in
> V4L2 are expected to always have a format set.
>
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-streamon.html
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-ctrl.html
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-selection.html
>
> Signed-off-by: Francois Buergisser
> Reviewed-by: Tomasz Figa
I guess that this Reviewed-by comes from a previous Gerrit workflow.
Usually, when you submit a patch to upstream you should remove the
Reviewed-by internally done, so I'd remove it, and ask Tomasz to give
you the Reviewed-by on the upstream patch.
> (cherry picked from commit 1887bb3924d030352df179347c8962248cdb903e)
Also, drop this, only has sense in the context of ChromeOS tree.
> Signed-off-by: Eizan Miyamoto
> ---
Apart from that, the patch looks good to me, so:
Reviewed-by: Enric Balletbo I Serra
>
> drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 2 -
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 90 +++
> 2 files changed, 34 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> index bafcccd71f31..dd130cc218c9 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> @@ -28,8 +28,6 @@
> #define MTK_MDP_FMT_FLAG_CAPTURE BIT(1)
>
> #define MTK_MDP_VPU_INIT BIT(0)
> -#define MTK_MDP_SRC_FMTBIT(1)
> -#define MTK_MDP_DST_FMTBIT(2)
> #define MTK_MDP_CTX_ERROR BIT(5)
>
> /**
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 821f2cf325f0..bb9caaf513bc 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -369,13 +369,6 @@ void mtk_mdp_ctx_state_lock_set(struct mtk_mdp_ctx *ctx,
> u32 state)
> mutex_unlock(&ctx->slock);
> }
>
> -static void mtk_mdp_ctx_state_lock_clear(struct mtk_mdp_ctx *ctx, u32 state)
> -{
> - mutex_lock(&ctx->slock);
> - ctx->state &= ~state;
> - mutex_unlock(&ctx->slock);
> -}
> -
> static bool mtk_mdp_ctx_state_is_set(struct mtk_mdp_ctx *ctx, u32 mask)
> {
> bool ret;
> @@ -726,11 +719,6 @@ static int mtk_mdp_m2m_s_fmt_mplane(struct file *file,
> void *fh,
> ctx->quant = pix_mp->quantization;
> }
>
> - if (V4L2_TYPE_IS_OUTPUT(f->type))
> - mtk_mdp_ctx_state_lock_set(ctx, MTK_MDP_SRC_FMT);
> - else
> - mtk_mdp_ctx_state_lock_set(ctx, MTK_MDP_DST_FMT);
> -
> mtk_mdp_dbg(2, "[%d] type:%d, frame:%dx%d", ctx->id, f->type,
> frame->width, frame->height);
>
> @@ -742,13 +730,6 @@ static int mtk_mdp_m2m_reqbufs(struct file *file, void
> *fh,
> {
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
>
> - if (reqbufs->count == 0) {
> - if (reqbufs->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> - mtk_mdp_ctx_state_lock_clear(ctx, MTK_MDP_SRC_FMT);
> - else
> - mtk_mdp_ctx_state_lock_clear(ctx, MTK_MDP_DST_FMT);
> - }
> -
> return v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
> }
>
> @@ -758,14 +739,6 @@ static int mtk_mdp_m2m_streamon(struct file *file, void
> *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> int ret;
>
> - /* The source and target color format need to be set */
> - if (V4L2_TYPE_IS_OUTPUT(type)) {
> - if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_SRC_FMT))
> - return -EINVAL;
> - } else if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_DST_FMT)) {
> - return -EINVAL;
> - }
> -
> if (!mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_VPU_INIT)) {
> ret = mtk_mdp_vpu_init(&ctx->vpu);
> if (ret < 0) {
> @@ -899,24 +872,21 @@ static int mtk_mdp_m2m_s_selection(struct file *file,
> void *fh,
> frame = &ctx->d_frame;
>
> /* Check to see if scaling ratio is within supported range */
> - if (mtk_mdp_ctx_state_is_set(ctx, MTK_MDP_DST_FMT | MTK_MDP_SRC_FMT))
> {
> - if (V4L2_TYPE_IS_OUTPUT(s->type)) {
> - ret = mtk_mdp_check_scaler_ratio(variant, new_r.width,
> - new_r.height, ctx->d_frame.crop.width,
> -
Re: [PATCH] iommu/rockchip: don't use platform_get_irq to implicitly count irqs
Hi,
Missatge de Heiko Stuebner del dia dc., 25 de set.
2019 a les 20:44:
>
> Till now the Rockchip iommu driver walked through the irq list via
> platform_get_irq() until it encountered an ENXIO error. With the
> recent change to add a central error message, this always results
> in such an error for each iommu on probe and shutdown.
>
> To not confuse people, switch to platform_count_irqs() to get the
> actual number of interrupts before walking through them.
>
> Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to
> platform_get_irq*()")
> Signed-off-by: Heiko Stuebner
> ---
This patch definitely removes the annoying messages on my Samsung
Chromebook Plus like:
rk_iommu ff924000.iommu: IRQ index 1 not found
rk_iommu ff914000.iommu: IRQ index 1 not found
rk_iommu ff903f00.iommu: IRQ index 1 not found
rk_iommu ff8f3f00.iommu: IRQ index 1 not found
rk_iommu ff650800.iommu: IRQ index 1 not found
FWIW, I sent a similar patch [1] to fix this, but can be rejected in
favour of the Heiko's patch. So,
Tested-by: Enric Balletbo i Serra
Thanks,
Enric
[1] https://lkml.org/lkml/2019/10/8/551
> drivers/iommu/rockchip-iommu.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 26290f310f90..4dcbf68dfda4 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -100,6 +100,7 @@ struct rk_iommu {
> struct device *dev;
> void __iomem **bases;
> int num_mmu;
> + int num_irq;
> struct clk_bulk_data *clocks;
> int num_clocks;
> bool reset_disabled;
> @@ -1136,7 +1137,7 @@ static int rk_iommu_probe(struct platform_device *pdev)
> struct rk_iommu *iommu;
> struct resource *res;
> int num_res = pdev->num_resources;
> - int err, i, irq;
> + int err, i;
>
> iommu = devm_kzalloc(dev, sizeof(*iommu), GFP_KERNEL);
> if (!iommu)
> @@ -1163,6 +1164,10 @@ static int rk_iommu_probe(struct platform_device *pdev)
> if (iommu->num_mmu == 0)
> return PTR_ERR(iommu->bases[0]);
>
> + iommu->num_irq = platform_irq_count(pdev);
> + if (iommu->num_irq < 0)
> + return iommu->num_irq;
> +
> iommu->reset_disabled = device_property_read_bool(dev,
> "rockchip,disable-mmu-reset");
>
> @@ -1219,8 +1224,9 @@ static int rk_iommu_probe(struct platform_device *pdev)
>
> pm_runtime_enable(dev);
>
> - i = 0;
> - while ((irq = platform_get_irq(pdev, i++)) != -ENXIO) {
> + for (i = 0; i < iommu->num_irq; i++) {
> + int irq = platform_get_irq(pdev, i);
> +
> if (irq < 0)
> return irq;
>
> @@ -1245,10 +1251,13 @@ static int rk_iommu_probe(struct platform_device
> *pdev)
> static void rk_iommu_shutdown(struct platform_device *pdev)
> {
> struct rk_iommu *iommu = platform_get_drvdata(pdev);
> - int i = 0, irq;
> + int i;
> +
> + for (i = 0; i < iommu->num_irq; i++) {
> + int irq = platform_get_irq(pdev, i);
>
> - while ((irq = platform_get_irq(pdev, i++)) != -ENXIO)
> devm_free_irq(iommu->dev, irq, iommu);
> + }
>
> pm_runtime_force_suspend(&pdev->dev);
> }
> --
> 2.23.0
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v4] platform/chrome: cros_ec_trace: update generating script
Missatge de Enric Balletbo i Serra del dia dj., 29 d’ag. 2019 a les 15:44: > > Hi Tzung-Bi, > > On 29/8/19 6:19, Tzung-Bi Shih wrote: > > Hi Enric and Raul, > > > > Do you have any further concerns on this patch? > > This patch will conflict with [2] which hopefully will be merged on next merge > window through Lee's tree. As this patch is only changing the doc I'm willing > to > wait after [2] lands. It's on my radar and don't need to resend, I'll do the > required changes. > > Best Regards, > Enric I missed the patch link [2] https://lkml.org/lkml/2019/8/23/475
Re: [PATCH] mmc: dw_mmc: Fix occasional hang after tuning on eMMC
Hi,
Missatge de Doug Anderson del dia dt., 9 de
jul. 2019 a les 18:38:
>
> Hi,
>
> On Tue, Jul 9, 2019 at 2:07 AM Krzysztof Kozlowski wrote:
> >
> > On Tue, 9 Jul 2019 at 00:48, Douglas Anderson wrote:
> > >
> > > In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
> > > response errors.") we fixed a tuning-induced hang that I saw when
> > > stress testing tuning on certain SD cards. I won't re-hash that whole
> > > commit, but the summary is that as a normal part of tuning you need to
> > > deal with transfer errors and there were cases where these transfer
> > > errors was putting my system into a bad state causing all future
> > > transfers to fail. That commit fixed handling of the transfer errors
> > > for me.
> > >
> > > In downstream Chrome OS my fix landed and had the same behavior for
> > > all SD/MMC commands. However, it looks like when the commit landed
> > > upstream we limited it to only SD tuning commands. Presumably this
> > > was to try to get around problems that Alim Akhtar reported on exynos
> > > [1].
> > >
> > > Unfortunately while stress testing reboots (and suspend/resume) on
> > > some rk3288-based Chromebooks I found the same problem on the eMMC on
> > > some of my Chromebooks (the ones with Hynix eMMC). Since the eMMC
> > > tuning command is different (MMC_SEND_TUNING_BLOCK_HS200
> > > vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the
> > > same situation.
> > >
> > > I'm hoping that whatever problems exynos was having in the past are
> > > somehow magically fixed now and we can make the behavior the same for
> > > all commands.
> > >
> > > [1]
> > > https://lkml.kernel.org/r/cagoxz53wfnbame0_am0qbqu47kafgmpbvzc8k8y-_j3mdmq...@mail.gmail.com
> > >
> > > Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response
> > > errors.")
> > > Signed-off-by: Douglas Anderson
> > > Cc: Marek Szyprowski
> > > Cc: Alim Akhtar
> > > Cc: Enric Balletbo i Serra
> > > ---
> > > Marek (or anyone else using exynos): is it easy for you to test this
> > > and check if things are still broken when we land this patch? If so,
> > > I guess we could have a quirk to have different behavior for just
> > > Rockchip SoCs but I'd rather avoid that if possible.
> > >
> > > NOTE: I'm not hoping totally in vain here. It is possible that some
> > > of the CTO/DTO timers that landed could be the magic that would get
> > > exynos unstuck.
> >
> > I have eMMC module attached to Odroid U3 (Exynos4412,
> > samsung,exynos4412-dw-mshc). What is the testing procedure? With your
> > patch it boots fine:
> > [3.698637] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> > req 5200Hz, actual 5000HZ div = 0)
> > [3.703900] mmc1: new DDR MMC card at address 0001
> > [3.728458] mmcblk1: mmc1:0001 008G92 7.28 GiB
>
> To really test it, it'd be nice to see some HS200 eMMC cards enumerate
> OK. Specifically the patch adjusts the error handling and the place
> where that happens mostly is during tuning.
>
> I'll also try to find some time today to check a peach_pit or a
> peach_pi. I think I saw one in the pile near my desk so if it isn't
> in too bad of a shape I can give mainline a shot on it.
>
I did a normal boot on peach_pi [1] and odroidxu3 [2] with that patch
applied, and the eMMC attached on both was detected as
[2.294798] mmc0: new HS400 MMC card at address 0001
I can do some stress tests tomorrow on those boards if that helps.
Cheers,
~ Enric
[1]
https://storage.kernelci.org/chrome-platform/for-kernelci/ib-mfd-cros-v5.3-87-g0fe7e9d7d5a3/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5800-peach-pi.html
[2]
https://storage.kernelci.org/chrome-platform/for-kernelci/ib-mfd-cros-v5.3-87-g0fe7e9d7d5a3/arm/multi_v7_defconfig/gcc-8/lab-collabora/boot-exynos5422-odroidxu3.html
> -Doug
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v3] platform/chrome: Expose resume result via debugfs
Hi Evan, Lee,
Missatge de Evan Green del dia dj., 27 de juny
2019 a les 22:46:
>
> For ECs that support it, the EC returns the number of slp_s0
> transitions and whether or not there was a timeout in the resume
> response. Expose the last resume result to usermode via debugfs so
> that usermode can detect and report S0ix timeouts.
>
> Signed-off-by: Evan Green
Acked-by: Enric Balletbo i Serra
Lee, actually this patch depends on some patches from chrome-platform
to apply cleanly. Once is fine with you and if you're happy to have
this merged for 5.3, I can just carry the patch with me, shouldn't be
any conflicts with your current changes or if you prefer I can create
an immutable branch for you.
Thanks,
~ Enric
> ---
>
> Changes in v3:
> - Expose the debugfs file on all EC types (Enric)
>
> Changes in v2:
> - Moved from sysfs to debugfs (Enric)
> - Added documentation (Enric)
>
>
> ---
> Documentation/ABI/testing/debugfs-cros-ec | 22 ++
> drivers/mfd/cros_ec.c | 6 +-
> drivers/platform/chrome/cros_ec_debugfs.c | 5 +
> include/linux/mfd/cros_ec.h | 1 +
> 4 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/debugfs-cros-ec
> b/Documentation/ABI/testing/debugfs-cros-ec
> index 573a82d23c89..1fe0add99a2a 100644
> --- a/Documentation/ABI/testing/debugfs-cros-ec
> +++ b/Documentation/ABI/testing/debugfs-cros-ec
> @@ -32,3 +32,25 @@ Description:
> is used for synchronizing the AP host time with the EC
> log. An error is returned if the command is not supported
> by the EC or there is a communication problem.
> +
> +What: /sys/kernel/debug//last_resume_result
> +Date: June 2019
> +KernelVersion: 5.3
> +Description:
> + Some ECs have a feature where they will track transitions to
> + the (Intel) processor's SLP_S0 line, in order to detect cases
> + where a system failed to go into S0ix. When the system
> resumes,
> + an EC with this feature will return a summary of SLP_S0
> + transitions that occurred. The last_resume_result file returns
> + the most recent response from the AP's resume message to the
> EC.
> +
> + The bottom 31 bits contain a count of the number of SLP_S0
> + transitions that occurred since the suspend message was
> + received. Bit 31 is set if the EC attempted to wake the
> + system due to a timeout when watching for SLP_S0 transitions.
> + Callers can use this to detect a wake from the EC due to
> + S0ix timeouts. The result will be zero if no suspend
> + transitions have been attempted, or the EC does not support
> + this feature.
> +
> + Output will be in the format: "0x%08x\n".
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 5d5c41ac3845..2a9ac5213893 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -102,12 +102,16 @@ static int cros_ec_sleep_event(struct cros_ec_device
> *ec_dev, u8 sleep_event)
>
> /* For now, report failure to transition to S0ix with a warning. */
> if (ret >= 0 && ec_dev->host_sleep_v1 &&
> - (sleep_event == HOST_SLEEP_EVENT_S0IX_RESUME))
> + (sleep_event == HOST_SLEEP_EVENT_S0IX_RESUME)) {
> + ec_dev->last_resume_result =
> + buf.u.resp1.resume_response.sleep_transitions;
> +
> WARN_ONCE(buf.u.resp1.resume_response.sleep_transitions &
> EC_HOST_RESUME_SLEEP_TIMEOUT,
> "EC detected sleep transition timeout. Total slp_s0
> transitions: %d",
> buf.u.resp1.resume_response.sleep_transitions &
> EC_HOST_RESUME_SLEEP_TRANSITIONS_MASK);
> + }
>
> return ret;
> }
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c
> b/drivers/platform/chrome/cros_ec_debugfs.c
> index 7ee060743844..967c78abfdd3 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -447,6 +447,11 @@ static int cros_ec_debugfs_probe(struct platform_device
> *pd)
> debugfs_create_file("uptime", 0444, debug_info->dir, debug_info,
> &cros_ec_uptime_fops);
>
> + debugfs_create_x32("last_resume_result",
> + 0444,
> + debug_info->dir,
> + &ec->ec_dev->last_resume_result);
> +
> ec->debug_info = debug_info;
>
> dev_set_drvdata(&pd->dev, ec);
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 5ddca44be06d..45aba26db964 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -155,6 +155,7 @@ struct cros_ec_device {
> struct ec_r
Re: [PATCH v3 2/2] iio: cros_ec: Extend legacy support to ARM device
Hi, Missatge de Doug Anderson del dia dc., 26 de juny 2019 a les 23:06: > > Hi, > > On Mon, Jun 24, 2019 at 3:53 PM Gwendal Grignou wrote: > > > > -static int read_ec_accel_data(struct cros_ec_accel_legacy_state *st, > > - unsigned long scan_mask, s16 *data) > > +int cros_ec_accel_legacy_read_cmd(struct iio_dev *indio_dev, > > + unsigned long scan_mask, s16 *data) > > As found by 0day (see https://crrev.com/c/1678822), the > cros_ec_accel_legacy_read_cmd() should have been static. > > I presume this will cause less confusion if a maintainer just fixes > this up when landing the patch so Gwendal shouldn't send out a new > version to fix it. ...but if this is not the case then yell! :-) > As probably will go through the chrome-platform tree I'll fix this when I apply the patch. No need to resend. Gwendal, Doug, to have cros-ec-sensors legacy support for ARM in upstream, could you spend 5 min reviewing the following patch? https://lore.kernel.org/patchwork/patch/1094790/ I'll also test it. Thanks, ~ Enric > -Doug
Re: [PATCH v4 1/2] power: supply: add input power and voltage limit properties
Hi Sebastian, Pavel, Missatge de Benson Leung del dia dj., 23 de maig 2019 a les 21:55: > > Hi Enric, > > On Tue, May 07, 2019 at 11:52:47AM +0200, Enric Balletbo i Serra wrote: > > For thermal management strategy you might be interested on limit the > > input power for a power supply. We already have current limit but > > basically what we probably want is to limit power. So, introduce the > > input_power_limit property. > > > > Although the common use case is limit the input power, in some > > specific cases it is the voltage that is problematic (i.e some regulators > > have different efficiencies at higher voltage resulting in more heat). > > So introduce also the input_voltage_limit property. > > > > This happens in one Chromebook and is used on the Pixel C's thermal > > management strategy to effectively limit the input power to 5V 3A when > > the screen is on. When the screen is on, the display, the CPU, and the GPU > > all contribute more heat to the system than while the screen is off, and > > we made a tradeoff to throttle the charger in order to give more of the > > thermal budget to those other components. > > > > So there's nothing fundamentally broken about the hardware that would > > cause the Pixel C to malfunction if we were charging at 9V or 12V instead > > of 5V when the screen is on, i.e. if userspace doesn't change this. > > > > What would happen is that you wouldn't meet Google's skin temperature > > targets on the system if the charger was allowed to run at 9V or 12V with > > the screen on. > > > > For folks hacking on Pixel Cs (which is now outside of Google's official > > support window for Android) and customizing their own kernel and userspace > > this would be acceptable, but we wanted to expose this feature in the > > power supply properties because the feature does exist in the Emedded > > Controller firmware of the Pixel C and all of Google's Chromebooks with > > USB-C made since 2015 in case someone running an up to date kernel wanted > > to limit the charging power for thermal or other reasons. > > > > This patch exposes a new property, similar to input current limit, to > > re-configure the maximum voltage from the external supply at runtime > > based on system-level knowledge or user input. > > > > Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: Guenter Roeck > > Acked-by: Adam Thomson > > Reviewed-by: Benson Leung > We're close to the merge window so I'm wondering if there are more concerns on this patchset? Thanks, ~ Enric > > --- > > > > Changes in v4: > > - Add also input_power_limit. > > > > Changes in v3: > > - Improve commit log and documentation with Benson comments. > > > > Changes in v2: > > - Document the new property in ABI/testing/sysfs-class-power. > > - Add the Reviewed-by Guenter Roeck tag. > > > > Documentation/ABI/testing/sysfs-class-power | 32 + > > Documentation/power/power_supply_class.txt | 4 +++ > > drivers/power/supply/power_supply_sysfs.c | 2 ++ > > include/linux/power_supply.h| 2 ++ > > 4 files changed, 40 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-class-power > > b/Documentation/ABI/testing/sysfs-class-power > > index 5e23e22dce1b..962a27a1daf8 100644 > > --- a/Documentation/ABI/testing/sysfs-class-power > > +++ b/Documentation/ABI/testing/sysfs-class-power > > @@ -331,10 +331,42 @@ Description: > > supply. Normally this is configured based on the type of > > connection made (e.g. A configured SDP should output a maximum > > of 500mA so the input current limit is set to the same value). > > + Use preferably input_power_limit, and for problems that can be > > + solved using power limit use input_current_limit. > > > > Access: Read, Write > > Valid values: Represented in microamps > > > > +What: > > /sys/class/power_supply//input_voltage_limit > > +Date:May 2019 > > +Contact: linux...@vger.kernel.org > > +Description: > > + This entry configures the incoming VBUS voltage limit > > currently > > + set in the supply. Normally this is configured based on > > + system-level knowledge or user input (e.g. This is part of the > > + Pixel C's thermal management strategy to effectively limit the > > + input power to 5V when the screen is on to meet Google's skin > > + temperature targets). Note that this feature should not be > > + used for safety critical things. > > + Use preferably input_power_limit, and for problems that can be > > + solved using power limit use input_voltage_limit. > > + > > + Access: Read, Write > > + Valid values: Represented in microvolts > > + > > +What: > > /sys/class/power_supply//input_power_limit > > +Date:May 2019 > > +Contact: linux...@vger.kerne
Re: [PATCH] ASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates
Hi Mark,
Missatge de Mark Brown del dia dj., 20 de juny
2019 a les 17:42:
>
> On Thu, Jun 20, 2019 at 03:47:08PM +0200, Enric Balletbo i Serra wrote:
> > According to the datasheet the max98357a also supports 32, 44.1 and
> > 88.2 kHz sample rate. This support was also introduced recently by
> > commit fdf34366d324 ("ASoC: max98357a: add missing supported rates").
> > This patch adds support for these rates also for the machine driver so
> > we get rid of the errors like the below and we are able to play files
> > using these sample rates.
>
> Does the machine actually need to validate this at all? The component
> drivers can all apply whatever constraints are needed and do their own
> validation, the machine driver is just getting in the way here.
I think you have reason, I'll test by removing these validation and
respin the patch.
Thanks,
~ Enric
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
Re: [PATCH v7 2/2] iio: cros_ec: Add lid angle driver
Missatge de Gwendal Grignou del dia dv., 14 de
juny 2019 a les 23:56:
>
> On Sat, May 18, 2019 at 2:53 AM Jonathan Cameron wrote:
> >
> > On Fri, 17 May 2019 16:38:56 -0700
> > Gwendal Grignou wrote:
> >
> > > Add a IIO driver that reports the angle between the lid and the base for
> > > ChromeOS convertible device.
> > >
> > > Tested on eve with ToT EC firmware.
> > > Check driver is loaded and lid angle is correct.
> > >
> > > Signed-off-by: Gwendal Grignou
> > Hi Gwendal.
> >
> > Please do list dependencies in patches. I think this one is still
> > dependent on the larger set of MFD changes.
> >
> > For my reference
> >
> > Acked-by: Jonathan Cameron
> >
> > Please do poke if this seems to have gotten lost once the precursors
> > are upstream.
> The large set of MFD changes for update cros_ec_commands.h has landed
> in a immutable branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git branch
> ib-mfd-cros-5.3.
>
Jonathan, if you don't want to deal with the big patchset that this
depends and the immutable branch, I can pick the patch and can go
through the chrome-platform tree. I think it is unlikely have merge
conflicts, as these patches only touch cros-ec iio parts and, anyway,
I'll need to deal with the immutable branch because other patches also
depends on the ib.
Thanks,
~ Enric
> Thanks,
> Gwendal.
>
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > Changes in v7:
> > > - Split patch in two: This is the IIO section.
> > >
> > > Changes in v6:
> > > - Fix lock held in an error path error.
> > >
> > > Changes in v5:
> > > - Remove unnecessary define.
> > > - v4 was the wrong patch file
> > >
> > > Changes in v3:
> > > - Use static channel array, simplify code because index is always 0.
> > >
> > > Changes in v2:
> > > - Fix license, remove driver_module field.
> > >
> > > drivers/iio/common/cros_ec_sensors/Kconfig| 9 ++
> > > drivers/iio/common/cros_ec_sensors/Makefile | 1 +
> > > .../cros_ec_sensors/cros_ec_lid_angle.c | 139 ++
> > > 3 files changed, 149 insertions(+)
> > > create mode 100644 drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > >
> > > diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig
> > > b/drivers/iio/common/cros_ec_sensors/Kconfig
> > > index 135f6825903f..aacc2ab9c34f 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/Kconfig
> > > +++ b/drivers/iio/common/cros_ec_sensors/Kconfig
> > > @@ -20,3 +20,12 @@ config IIO_CROS_EC_SENSORS
> > > Accelerometers, Gyroscope and Magnetometer that are
> > > presented by the ChromeOS EC Sensor hub.
> > > Creates an IIO device for each functions.
> > > +
> > > +config IIO_CROS_EC_SENSORS_LID_ANGLE
> > > + tristate "ChromeOS EC Sensor for lid angle"
> > > + depends on IIO_CROS_EC_SENSORS_CORE
> > > + help
> > > + Module to report the angle between lid and base for some
> > > + convertible devices.
> > > + This module is loaded when the EC can calculate the angle between
> > > the base
> > > + and the lid.
> > > diff --git a/drivers/iio/common/cros_ec_sensors/Makefile
> > > b/drivers/iio/common/cros_ec_sensors/Makefile
> > > index ec716ff2a775..a35ee232ac07 100644
> > > --- a/drivers/iio/common/cros_ec_sensors/Makefile
> > > +++ b/drivers/iio/common/cros_ec_sensors/Makefile
> > > @@ -4,3 +4,4 @@
> > >
> > > obj-$(CONFIG_IIO_CROS_EC_SENSORS_CORE) += cros_ec_sensors_core.o
> > > obj-$(CONFIG_IIO_CROS_EC_SENSORS) += cros_ec_sensors.o
> > > +obj-$(CONFIG_IIO_CROS_EC_SENSORS_LID_ANGLE) += cros_ec_lid_angle.o
> > > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > > b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > > new file mode 100644
> > > index ..876dfd176b0e
> > > --- /dev/null
> > > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_lid_angle.c
> > > @@ -0,0 +1,139 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +
> > > +/*
> > > + * cros_ec_lid_angle - Driver for CrOS EC lid angle sensor.
> > > + *
> > > + * Copyright 2018 Google, Inc
> > > + *
> > > + * This driver uses the cros-ec interface to communicate with the Chrome
> > > OS
> > > + * EC about counter sensors. Counters are presented through
> > > + * iio sysfs.
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define DRV_NAME "cros-ec-lid-angle"
> > > +
> > > +/*
> > > + * One channel for the lid angle, the other for timestamp.
> > > + */
> > > +static const struct iio_chan_spec cros_ec_lid_angle_channels[] = {
> > > + {
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > + .scan_type.realbits = CROS_EC_SENSOR_BITS,
> > > + .scan_type.storagebits = CROS_EC_SENSOR_BITS,
> > > + .scan_type.sign = 'u',
> >
Re: [PATCH v4] platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
Hi Nick, Missatge de Nick Crews del dia dv., 14 de juny 2019 a les 18:25: > > On Thu, Jun 13, 2019 at 10:34 PM Enric Balletbo i Serra > wrote: > > > > On many boards, communication between the kernel and the Embedded > > Controller happens over an LPC bus. In these cases, the kernel config > > CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a > > Microchip Embedded Controller (MEC) that is different from the regular > > EC. On these devices, the same LPC bus is used, but the protocol is > > a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel > > config is enabled. Currently, the kernel decides at compile-time whether > > or not to use the MEC variant, and, when that kernel option is selected > > it breaks the other boards. We would like a kind of runtime detection to > > avoid this. > > > > This patch adds that detection mechanism by probing the protocol at > > runtime, first we assume that a MEC variant is connected, and if the > > protocol fails it fallbacks to the regular EC. This adds a bit of > > overload because we try to read twice on those LPC boards that doesn't > > contain a MEC variant, but is a better solution than having to select the > > EC variant at compile-time. > > > > While here also fix the alignment in Kconfig file for this config option > > replacing the spaces by tabs. > > > > Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: Ezequiel Garcia > > Tested-by: Nick Crews > > --- > > Hi, > > > > This is another attempt to solve the issue to be able to select at > > runtime the CrOS MEC variant. My first thought was check for a device > > ID, the MEC1322 has a register that contains the device ID, however I > > am not sure if we can read that register from the host without > > modifying the firmware. Also, I am not sure if the MEC1322 is the only > > device used that supports that LPC protocol variant, so I ended with a > > more easy solution, check if the protocol fails or not. Some background > > on this issue can be found [1] and [2] > > > > The patch has been tested on: > > - Acer Chromebook R11 (Cyan - MEC variant) > > - Pixel Chromebook 2015 (Samus - non-MEC variant) > > - Dell Chromebook 11 (Wolf - non-MEC variant) > > - Toshiba Chromebook (Leon - non-MEC variant) > > > > Best regards, > > Enric > > > > [1] https://bugs.chromium.org/p/chromium/issues/detail?id=932626 > > [2] > > https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1474254 > > > > Changes in v4: > > - Change the logic to test the protocols as suggested by Nick Crews. > > - Add the proper cros_ec_lpc_mec.h include. (Nick Crews) > > - Fix some const and missing casts. (Nick Crews) > > - Clean up related doc-strings. (Nick Crews) > > > > Changes in v3: > > - Kconfig: Split across multiple lines to keep it under 80 characters. > > - Improve kernel-doc as suggested by Nick Crews. > > - Convert msg in write function to const. > > - Add rb and tb tags. > > > > Changes in v2: > > - Remove global bool to indicate the kind of variant as suggested by > > Ezequiel. > > - Create an internal operations struct to allow different variants. > > > > drivers/platform/chrome/Kconfig | 29 +++-- > > drivers/platform/chrome/Makefile | 2 +- > > drivers/platform/chrome/cros_ec_lpc.c | 78 --- > > drivers/platform/chrome/cros_ec_lpc_mec.h | 14 > > drivers/platform/chrome/cros_ec_lpc_reg.c | 41 > > drivers/platform/chrome/cros_ec_lpc_reg.h | 23 +++ > > drivers/platform/chrome/wilco_ec/Kconfig | 2 +- > > 7 files changed, 98 insertions(+), 91 deletions(-) > > > > diff --git a/drivers/platform/chrome/Kconfig > > b/drivers/platform/chrome/Kconfig > > index 2826f7136f65..453e69733842 100644 > > --- a/drivers/platform/chrome/Kconfig > > +++ b/drivers/platform/chrome/Kconfig > > @@ -83,28 +83,17 @@ config CROS_EC_SPI > > 'pre-amble' bytes before the response actually starts. > > > > config CROS_EC_LPC > > -tristate "ChromeOS Embedded Controller (LPC)" > > -depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) > > -help > > - If you say Y here, you get support for talking to the ChromeOS EC > > - over an LPC bus. This uses a simple byte-level protocol with a > > - checksum. This is used for userspace access only. The kernel > > - typically has its own communication methods. > > - > > - To compile this driver as a module, choose M here: the > > - module will be called cros_ec_lpc. > > - > > -config CROS_EC_LPC_MEC > > - bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant" > > - depends on CROS_EC_LPC > > - default n > > + tristate "ChromeOS Embedded Controller (LPC)" > > + depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) > > help > > - If you say Y here, a variant LPC protocol for the Microchip EC > > - will be used. Note that th
Re: [GIT PULL] Immutable branch between MFD and Cros due for the v5.3 merge window
Hi, Thanks for the ib Lee. Doing my Monday rebase I just noticed we will have a trivial conflict for the merge window. Missatge de Lee Jones del dia dl., 10 de juny 2019 a les 10:20: > > As requested. > > Enjoy! > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: > > Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-cros-v5.3 > > for you to fetch changes up to 3aa6be30da899619c44aa654313ba66eb44e7291: > > mfd: cros_ec: Update I2S API (2019-06-10 09:15:08 +0100) > > > Immutable branch between MFD and Cros due for the v5.3 merge window > > > Gwendal Grignou (30): > mfd: cros_ec: Update license term That's the commit will have problems due commit 9c92ab61914157664a2fbdf926df0eb937838e45 Author: Thomas Gleixner Date: Wed May 29 07:17:56 2019 -0700 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 282 That was introduced in v5.2-rc4 Just to let you know. Enric > mfd: cros_ec: Zero BUILD_ macro > mfd: cros_ec: set comments properly > mfd: cros_ec: add ec_align macros > mfd: cros_ec: Define commands as 4-digit UPPER CASE hex values > mfd: cros_ec: use BIT macro > mfd: cros_ec: Update ACPI interface definition > mfd: cros_ec: move HDMI CEC API definition > mfd: cros_ec: Remove zero-size structs > mfd: cros_ec: Add Flash V2 commands API > mfd: cros_ec: Add PWM_SET_DUTY API > mfd: cros_ec: Add lightbar v2 API > mfd: cros_ec: Expand hash API > mfd: cros_ec: Add EC transport protocol v4 > mfd: cros_ec: Complete MEMS sensor API > mfd: cros_ec: Fix event processing API > mfd: cros_ec: Add fingerprint API > mfd: cros_ec: Fix temperature API > mfd: cros_ec: Complete Power and USB PD API > mfd: cros_ec: Add API for keyboard testing > mfd: cros_ec: Add Hibernate API > mfd: cros_ec: Add Smart Battery Firmware update API > mfd: cros_ec: Add I2C passthru protection API > mfd: cros_ec: Add API for EC-EC communication > mfd: cros_ec: Add API for Touchpad support > mfd: cros_ec: Add API for Fingerprint support > mfd: cros_ec: Add API for rwsig > mfd: cros_ec: Add SKU ID and Secure storage API > mfd: cros_ec: Add Management API entry points > mfd: cros_ec: Update I2S API > > include/linux/mfd/cros_ec_commands.h | 3658 > +++--- > sound/soc/codecs/cros_ec_codec.c |8 +- > 2 files changed, 2915 insertions(+), 751 deletions(-) > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2] platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
Hi, Missatge de Guenter Roeck del dia dv., 7 de juny 2019 a les 22:11: > > On Fri, Jun 7, 2019 at 12:27 PM Nick Crews wrote: > > > > Hi! > > > > On Fri, Jun 7, 2019 at 12:03 PM Ezequiel Garcia > > wrote: > > > > > > On Fri, 2019-06-07 at 12:27 +0200, Enric Balletbo i Serra wrote: > > > > On many boards, communication between the kernel and the Embedded > > > > Controller happens over an LPC bus. In these cases, the kernel config > > > > CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a > > > > Microchip Embedded Controller (MEC) that is different from the regular > > > > EC. On these devices, the same LPC bus is used, but the protocol is > > > > a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel > > > > config is enabled. Currently, the kernel decides at compile-time whether > > > > or not to use the MEC variant, and, when that kernel option is selected > > > > it breaks the other boards. We would like a kind of runtime detection to > > > > avoid this. > > > > > > > > This patch adds that detection mechanism by probing the protocol at > > > > runtime, first we assume that a MEC variant is connected, and if the > > > > protocol fails it fallbacks to the regular EC. This adds a bit of > > > > overload because we try to read twice on those LPC boards that doesn't > > > > contain a MEC variant, but is a better solution than having to select > > > > the > > > > EC variant at compile-time. > > > > > > > > While here also fix the alignment in Kconfig file for this config option > > > > replacing the spaces by tabs. > > > > > > > > Signed-off-by: Enric Balletbo i Serra > > > > --- > > > > Hi, > > > > > > > > This is the second attempt to solve the issue to be able to select at > > > > runtime the CrOS MEC variant. My first thought was check for a device > > > > ID, > > > > the MEC1322 has a register that contains the device ID, however I am not > > > > sure if we can read that register from the host without modifying the > > > > firmware. Also, I am not sure if the MEC1322 is the only device used > > > > that supports that LPC protocol variant, so I ended with a more easy > > > > solution, check if the protocol fails or not. Some background on this > > > > issue can be found [1] and [2] > > > > > > > > The patch has been tested on: > > > > - Acer Chromebook R11 (Cyan - MEC variant) > > > > - Pixel Chromebook 2015 (Samus - non-MEC variant) > > > > - Dell Chromebook 11 (Wolf - non-MEC variant) > > > > - Toshiba Chromebook (Leon - non-MEC variant) > > > > > > > > Nick, could you test the patch for Wilco? > > > > > > > > Best regards, > > > > Enric > > > > > > > > [1] https://bugs.chromium.org/p/chromium/issues/detail?id=932626 > > > > [2] > > > > https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1474254 > > > > > > > > Changes in v2: > > > > - Remove global bool to indicate the kind of variant as suggested by > > > > Ezequiel. > > > > - Create an internal operations struct to allow different variants. > > > > > > > > drivers/platform/chrome/Kconfig | 29 +++-- > > > > drivers/platform/chrome/Makefile | 3 +- > > > > drivers/platform/chrome/cros_ec_lpc.c | 76 --- > > > > drivers/platform/chrome/cros_ec_lpc_reg.c | 39 +++- > > > > drivers/platform/chrome/cros_ec_lpc_reg.h | 26 > > > > drivers/platform/chrome/wilco_ec/Kconfig | 2 +- > > > > 6 files changed, 98 insertions(+), 77 deletions(-) > > > > > > > > diff --git a/drivers/platform/chrome/Kconfig > > > > b/drivers/platform/chrome/Kconfig > > > > index 2826f7136f65..453e69733842 100644 > > > > --- a/drivers/platform/chrome/Kconfig > > > > +++ b/drivers/platform/chrome/Kconfig > > > > @@ -83,28 +83,17 @@ config CROS_EC_SPI > > > > 'pre-amble' bytes before the response actually starts. > > > > > > > > config CROS_EC_LPC > > > > -tristate "ChromeOS Embedded Controller (LPC)" > > > > -depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) > > > > -help > > > > - If you say Y here, you get support for talking to the > > > > ChromeOS EC > > > > - over an LPC bus. This uses a simple byte-level protocol with > > > > a > > > > - checksum. This is used for userspace access only. The kernel > > > > - typically has its own communication methods. > > > > - > > > > - To compile this driver as a module, choose M here: the > > > > - module will be called cros_ec_lpc. > > > > - > > > > -config CROS_EC_LPC_MEC > > > > - bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant" > > > > - depends on CROS_EC_LPC > > > > - default n > > > > + tristate "ChromeOS Embedded Controller (LPC)" > > > > + depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) > > > > help > > > > - If you say Y here, a variant LPC protocol for the Microchip EC > > > > - will be used. Note that this variant is not backward co
Re: [alsa-devel] [RESEND PATCH v3 00/30] Update cros_ec_commands.h
Hi Lee, Missatge de Lee Jones del dia dt., 4 de juny 2019 a les 8:00: > > On Mon, 03 Jun 2019, Gwendal Grignou wrote: > > > The interface between CrosEC embedded controller and the host, > > described by cros_ec_commands.h, as diverged from what the embedded > > controller really support. > > > > The source of thruth is at > > https://chromium.googlesource.com/chromiumos/platform/ec/+/master/include/ec_commands.h > > > > That include file is converted to remove ACPI and Embedded only code. > > > > From now on, cros_ec_commands.h will be automatically generated from > > the file above, do not modify directly. > > > > Fell free to squash the commits below. > > > > v3 resent: Add Fabien's ack. > > Thanks for doing that. > > In future, please ensure *-bys tags are in chronological order with > the first one either being a Suggested-by or your SoB. Reviews, tests > etc usually come *after* first submission. > > I've changed this for you this time, yes in all 30 patches! :) > > Anyway, all applied, thanks. > Could you do an immutable branch with those? I've few patches that depends on those changes and probably I'll have more. Otherwise, I'll wait for those to land. Thanks, Enric > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH v3 1/3] thermal: rockchip: fix up the tsadc pinctrl setting error
Hi all,
As pointed by [1] and [2] this commit, that now is upstream, breaks
veyron (rk3288) and kevin (rk3399) boards. The problem is especially
critical for veyron boards because they don't boot anymore.
I didn't look deep at the problem but I have some concerns about this
patch, see below.
[1] https://www.spinics.net/lists/linux-rockchip/msg24657.html
[2] https://www.spinics.net/lists/linux-rockchip/msg24735.html
Missatge de Daniel Lezcano del dia dt., 30
d’abr. 2019 a les 15:39:
>
> On 30/04/2019 12:09, Elaine Zhang wrote:
> > Explicitly use the pinctrl to set/unset the right mode
> > instead of relying on the pinctrl init mode.
> > And it requires setting the tshut polarity before select pinctrl.
> >
> > When the temperature sensor mode is set to 0, it will automatically
> > reset the board via the Clock-Reset-Unit (CRU) if the over temperature
> > threshold is reached. However, when the pinctrl initializes, it does a
> > transition to "otp_out" which may lead the SoC restart all the time.
> >
> > "otp_out" IO may be connected to the RESET circuit on the hardware.
> > If the IO is in the wrong state, it will trigger RESET.
> > (similar to the effect of pressing the RESET button)
> > which will cause the soc to restart all the time.
> >
> > Signed-off-by: Elaine Zhang
>
> Reviewed-by: Daniel Lezcano
>
>
>
> > ---
> > drivers/thermal/rockchip_thermal.c | 36
> > +---
> > 1 file changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/thermal/rockchip_thermal.c
> > b/drivers/thermal/rockchip_thermal.c
> > index 9c7643d62ed7..6dc7fc516abf 100644
> > --- a/drivers/thermal/rockchip_thermal.c
> > +++ b/drivers/thermal/rockchip_thermal.c
> > @@ -172,6 +172,9 @@ struct rockchip_thermal_data {
> > int tshut_temp;
> > enum tshut_mode tshut_mode;
> > enum tshut_polarity tshut_polarity;
> > + struct pinctrl *pinctrl;
> > + struct pinctrl_state *gpio_state;
> > + struct pinctrl_state *otp_state;
> > };
> >
> > /**
> > @@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct
> > platform_device *pdev)
> > return error;
> > }
> >
> > + thermal->chip->control(thermal->regs, false);
> > +
That's the line that causes the hang. Commenting this makes the veyron
boot again. Probably this needs to go after chip->initialize?
> > error = clk_prepare_enable(thermal->clk);
> > if (error) {
> > dev_err(&pdev->dev, "failed to enable converter clock: %d\n",
> > @@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct
> > platform_device *pdev)
> > thermal->chip->initialize(thermal->grf, thermal->regs,
> > thermal->tshut_polarity);
> >
> > + if (thermal->tshut_mode == TSHUT_MODE_GPIO) {
> > + thermal->pinctrl = devm_pinctrl_get(&pdev->dev);
> > + if (IS_ERR(thermal->pinctrl)) {
> > + dev_err(&pdev->dev, "failed to find thermal
> > pinctrl\n");
> > + return PTR_ERR(thermal->pinctrl);
> > + }
> > +
> > + thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl,
> > +"gpio");
Shouldn't this mode be documented properly in the binding first?
The binding [3] talks about init, default and sleep states but *not*
gpio and otpout. The patch series looks incomplete to me or not using
the proper names.
[3]
https://elixir.bootlin.com/linux/v5.2-rc1/source/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
> > + if (IS_ERR_OR_NULL(thermal->gpio_state)) {
> > + dev_err(&pdev->dev, "failed to find thermal gpio
> > state\n");
> > + return -EINVAL;
> > + }
> > +
> > + thermal->otp_state = pinctrl_lookup_state(thermal->pinctrl,
> > + "otpout");
> > + if (IS_ERR_OR_NULL(thermal->otp_state)) {
> > + dev_err(&pdev->dev, "failed to find thermal otpout
> > state\n");
> > + return -EINVAL;
> > + }
> > +
Same here otpout is not a documented.
As this change is now in mainline and is causing veyron to hang I'd
suggest reverting this change for now. Even fixing the root cause
(maybe the one I pointed above) after this patch we will have the
thermal driver to fail because "gpio" and "otpout" states are not
defined nor documented (a change on this will need some reviews and
acks and time I guess).
Cheers,
Enric
> > + pinctrl_select_state(thermal->pinctrl, thermal->otp_state);
> > + }
> > +
> > for (i = 0; i < thermal->chip->chn_num; i++) {
> > error = rockchip_thermal_register_sensor(pdev, thermal,
> > &thermal->sensors[i],
> > @@ -1337,8 +1366,8 @@ static int __maybe_unused
> > rockchip_thermal_suspend(struct device *dev)
> >
>
Re: [PATCH v6] platform: chrome: Add ChromeOS EC ISHTP driver
Hi, Missatge de Rushikesh S Kadam del dia dc., 15 de maig 2019 a les 12:41: > > This driver implements a slim layer to enable the ChromeOS > EC kernel stack (cros_ec) to communicate with ChromeOS EC > firmware running on the Intel Integrated Sensor Hub (ISH). > > The driver registers a ChromeOS EC MFD device to connect > with cros_ec kernel stack (upper layer), and it registers a > client with the ISH Transport Protocol bus (lower layer) to > talk with the ISH firwmare. See description of the ISHTP > protocol at Documentation/hid/intel-ish-hid.txt > > Signed-off-by: Rushikesh S Kadam > Acked-by: Srinivas Pandruvada > Acked-by: Enric Balletbo i Serra > Reviewed-by: Jett Rink > Tested-by: Jett Rink > --- The following patch is queued to the for-next branch for the autobuilders to play with, if all goes well I'll add the patch for 5.3 when current merge window closes. Thanks, Enric > > Submitting the patch to linux-input@ per the discussion here > https://lkml.org/lkml/2019/5/2/339 > > The patch is baselined to hid git tree, branch for-5.2/ish > https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish > > v6 > - Moved the sanity checks in cros_ec_pkt_xfer_ish() to before >the point we take the lock (Bug fix). > > v5 > - Submitting with all Acked-by & Tested-bys. No other changes. > > v4 > - Coding style related changes. No functional changes. Addresses >review comments on v3. > > v3 > - Made several changes to improve code readability. Replaced >multiple cl_data_to_dev(client_data) with dev variable. Use >reverse Xmas tree for variable defintion where it made sense. >Dropped few debug prints. Add docstring for function >prepare_cros_ec_rx(). > - Fix code in function prepare_cros_ec_rx() under label >end_cros_ec_dev_init_error. > - Recycle buffer in process_recv() on failing to obtain the >semaphore. > - Increase ISHTP TX/RX ring buffer size to 8. > - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and >Kconfig. > - Updated commit message. > > v2 > - Dropped unused "reset" parameter in function cros_ec_init() > - Change driver name to cros_ec_ishtp to be consistent with other >references in the code. > - Fixed a few typos. > > v1 > - Initial version > > drivers/platform/chrome/Kconfig | 13 + > drivers/platform/chrome/Makefile| 1 + > drivers/platform/chrome/cros_ec_ishtp.c | 763 > > 3 files changed, 777 insertions(+) > create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c > > diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig > index 16b1615..5848179 100644 > --- a/drivers/platform/chrome/Kconfig > +++ b/drivers/platform/chrome/Kconfig > @@ -62,6 +62,19 @@ config CROS_EC_I2C > a checksum. Failing accesses will be retried three times to > improve reliability. > > +config CROS_EC_ISHTP > + tristate "ChromeOS Embedded Controller (ISHTP)" > + depends on MFD_CROS_EC > + depends on INTEL_ISH_HID > + help > + If you say Y here, you get support for talking to the ChromeOS EC > + firmware running on Intel Integrated Sensor Hub (ISH), using the > + ISH Transport protocol (ISH-TP). This uses a simple byte-level > + protocol with a checksum. > + > + To compile this driver as a module, choose M here: the > + module will be called cros_ec_ishtp. > + > config CROS_EC_SPI > tristate "ChromeOS Embedded Controller (SPI)" > depends on MFD_CROS_EC && SPI > diff --git a/drivers/platform/chrome/Makefile > b/drivers/platform/chrome/Makefile > index cd591bf..4efe102 100644 > --- a/drivers/platform/chrome/Makefile > +++ b/drivers/platform/chrome/Makefile > @@ -7,6 +7,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o > cros_ec_lightbar.o \ >cros_ec_vbc.o cros_ec_debugfs.o > obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o > obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o > +obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o > obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o > cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o > cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o > diff --git a/drivers/platform/chrome/cros_ec_ishtp.c > b/drivers/platform/chrome/cros_ec_ishtp.c > new file mode 100644 > index 000..e504d25 > --- /dev/null > +++ b/drivers/platform/chrome/cros_ec_ishtp.c > @@ -0,0 +1,763 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// ISHTP interface for ChromeOS Embedded Controller > +// > +// Copyright (c) 2019, Intel Corporation. > +// > +// ISHTP client driver for talking to the Chrome OS EC firmware running > +// on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol > +// (ISH-TP). > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > +
Re: [PATCH v5] platform: chrome: Add ChromeOS EC ISHTP driver
Missatge de Enric Balletbo i Serra del dia dc., 15 de maig 2019 a les 15:00: > > Hi, > > On 4/5/19 15:34, Rushikesh S Kadam wrote: > > This driver implements a slim layer to enable the ChromeOS > > EC kernel stack (cros_ec) to communicate with ChromeOS EC > > firmware running on the Intel Integrated Sensor Hub (ISH). > > > > The driver registers a ChromeOS EC MFD device to connect > > with cros_ec kernel stack (upper layer), and it registers a > > client with the ISH Transport Protocol bus (lower layer) to > > talk with the ISH firwmare. See description of the ISHTP > > protocol at Documentation/hid/intel-ish-hid.txt > > > > Signed-off-by: Rushikesh S Kadam > > Acked-by: Enric Balletbo i Serra > > Acked-by: Srinivas Pandruvada > > Reviewed-by: Jett Rink > > Tested-by: Jett Rink > > --- > > The following patch is queued to the for-next branch for the autobuilders to > play with, if all goes well I'll add the patch for 5.3 when current merge > window > closes. > Actually, I reverted this patch and applied v6. > Thanks, > Enric > > > > > Submitting the patch to linux-input@ per the discussion here > > https://lkml.org/lkml/2019/5/2/339 > > > > The patch is baselined to hid git tree, branch for-5.2/ish > > https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.2/ish > > > > v5 > > - Submitting with all Acked-by & Tested-bys. No other changes. > > > > v4 > > - Coding style related changes. No functional changes. Addresses > >review comments on v3. > > > > v3 > > - Made several changes to improve code readability. Replaced > >multiple cl_data_to_dev(client_data) with dev variable. Use > >reverse Xmas tree for variable defintion where it made sense. > >Dropped few debug prints. Add docstring for function > >prepare_cros_ec_rx(). > > - Fix code in function prepare_cros_ec_rx() under label > >end_cros_ec_dev_init_error. > > - Recycle buffer in process_recv() on failing to obtain the > >semaphore. > > - Increase ISHTP TX/RX ring buffer size to 8. > > - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and > >Kconfig. > > - Updated commit message. > > > > v2 > > - Dropped unused "reset" parameter in function cros_ec_init() > > - Change driver name to cros_ec_ishtp to be consistent with other > >references in the code. > > - Fixed a few typos. > > > > v1 > > - Initial version > > > > drivers/platform/chrome/Kconfig | 13 + > > drivers/platform/chrome/Makefile| 1 + > > drivers/platform/chrome/cros_ec_ishtp.c | 763 > > > > 3 files changed, 777 insertions(+) > > create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c > > > > diff --git a/drivers/platform/chrome/Kconfig > > b/drivers/platform/chrome/Kconfig > > index 16b1615..5848179 100644 > > --- a/drivers/platform/chrome/Kconfig > > +++ b/drivers/platform/chrome/Kconfig > > @@ -62,6 +62,19 @@ config CROS_EC_I2C > > a checksum. Failing accesses will be retried three times to > > improve reliability. > > > > +config CROS_EC_ISHTP > > + tristate "ChromeOS Embedded Controller (ISHTP)" > > + depends on MFD_CROS_EC > > + depends on INTEL_ISH_HID > > + help > > + If you say Y here, you get support for talking to the ChromeOS EC > > + firmware running on Intel Integrated Sensor Hub (ISH), using the > > + ISH Transport protocol (ISH-TP). This uses a simple byte-level > > + protocol with a checksum. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called cros_ec_ishtp. > > + > > config CROS_EC_SPI > > tristate "ChromeOS Embedded Controller (SPI)" > > depends on MFD_CROS_EC && SPI > > diff --git a/drivers/platform/chrome/Makefile > > b/drivers/platform/chrome/Makefile > > index cd591bf..4efe102 100644 > > --- a/drivers/platform/chrome/Makefile > > +++ b/drivers/platform/chrome/Makefile > > @@ -7,6 +7,7 @@ cros_ec_ctl-objs := cros_ec_sysfs.o > > cros_ec_lightbar.o \ > > cros_ec_vbc.o cros_ec_debugfs.o > > obj-$(CONFIG_CROS_EC_CTL)+= cros_ec_ctl.o > > obj-$(CONFIG_CROS_EC_I2C)+= cros_ec_i2c.o > > +obj-$(CONFIG_CROS_EC_ISHTP) += cros_ec_ishtp.o > > obj-$(CONFIG_CROS_EC_SPI)+= cros_ec_spi.o > > cros_ec_lpcs-objs:= cros_ec_lpc.o cros_ec_lpc_reg.o > > cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o > > diff --git a/drivers/platform/chrome/cros_ec_ishtp.c > > b/drivers/platform/chrome/cros_ec_ishtp.c > > new file mode 100644 > > index 000..997503d > > --- /dev/null > > +++ b/drivers/platform/chrome/cros_ec_ishtp.c > > @@ -0,0 +1,763 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +// ISHTP interface for ChromeOS Embedded Controller > > +// > > +// Copyright (c) 2019, Intel Corporation. > > +// > > +// ISHTP client driver for talking to the Chrome OS EC firmware running > >
Re: [PATCH v3 2/2] platform/chrome: wilco_ec: Add USB PowerShare Policy control
Hi Nick,
Thanks for the patch, some few comments below...
Missatge de Nick Crews del dia dc., 17 d’abr.
2019 a les 3:21:
>
> USB PowerShare is a policy which affects charging via the special
> USB PowerShare port (marked with a small lightning bolt or battery icon)
> when in low power states:
> - In S0, the port will always provide power.
> - In S0ix, if power_share is enabled, then power will be supplied to
> the port when on AC or if battery is > 50%. Else no power is supplied.
> - In S5, if power_share is enabled, then power will be supplied to
> the port when on AC. Else no power is supplied.
>
> v3 changes:
> - Drop a silly blank line
> - Use val > 1 instead of val != 0 && val != 1
> v2 changes:
> - Move documentation to Documentation/ABI/testing/sysfs-platform-wilco-ec
> - Zero out reserved bytes in requests.
>
> Signed-off-by: Nick Crews
> ---
> .../ABI/testing/sysfs-platform-wilco-ec | 16
> drivers/platform/chrome/wilco_ec/sysfs.c | 92 +++
> 2 files changed, 108 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-wilco-ec
> b/Documentation/ABI/testing/sysfs-platform-wilco-ec
> index e074c203cd32..0c07d5e0b737 100644
> --- a/Documentation/ABI/testing/sysfs-platform-wilco-ec
> +++ b/Documentation/ABI/testing/sysfs-platform-wilco-ec
> @@ -9,3 +9,19 @@ Description:
> Input should be parseable by kstrtou8() to 0 or 1.
> Output will be either "0\n" or "1\n".
>
> +What: /sys/bus/platform/devices/GOOG000C\:00/usb_power_share
> +Date: April 2019
> +KernelVersion: 5.2
> +Description:
> + Control the USB PowerShare Policy. USB PowerShare is a policy
> + which affects charging via the special USB PowerShare port
> + (marked with a small lightning bolt or battery icon) when in
> + low power states:
> + - In S0, the port will always provide power.
> + - In S0ix, if power_share is enabled, then power will be
> + supplied to the port when on AC or if battery is > 50%.
> + Else no power is supplied.
> + - In S5, if power_share is enabled, then power will be
> supplied
> + to the port when on AC. Else no power is supplied.
> +
So, basically, this is to enable/disable USB Powershare capability. I
think that this is not an uncommon capability can we give it a respin
and see if we can do this generic?
> + Input should be either "0" or "1".
> diff --git a/drivers/platform/chrome/wilco_ec/sysfs.c
> b/drivers/platform/chrome/wilco_ec/sysfs.c
> index 959b5da2eb16..14e1eee95d42 100644
> --- a/drivers/platform/chrome/wilco_ec/sysfs.c
> +++ b/drivers/platform/chrome/wilco_ec/sysfs.c
> @@ -23,6 +23,26 @@ struct boot_on_ac_request {
> u8 reserved7;
> } __packed;
>
> +#define CMD_USB_POWER_SHARE 0x39
> +
> +enum usb_power_share_op {
> + POWER_SHARE_GET = 0,
> + POWER_SHARE_SET = 1,
> +};
> +
> +struct usb_power_share_request {
> + u8 cmd; /* Always CMD_USB_POWER_SHARE */
> + u8 reserved;
> + u8 op; /* One of enum usb_power_share_op */
> + u8 val; /* When setting, either 0 or 1 */
> +} __packed;
> +
> +struct usb_power_share_response {
> + u8 reserved;
> + u8 status; /* Set by EC to 0 on success, other value on failure
> */
> + u8 val; /* When getting, set by EC to either 0 or 1 */
> +} __packed;
> +
> static ssize_t boot_on_ac_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> @@ -57,8 +77,80 @@ static ssize_t boot_on_ac_store(struct device *dev,
>
> static DEVICE_ATTR_WO(boot_on_ac);
>
> +static int send_usb_power_share(struct wilco_ec_device *ec,
> + struct usb_power_share_request *rq,
> + struct usb_power_share_response *rs)
> +{
> + struct wilco_ec_message msg;
> + int ret;
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.type = WILCO_EC_MSG_LEGACY;
> + msg.request_data = rq;
> + msg.request_size = sizeof(*rq);
> + msg.response_data = rs;
> + msg.response_size = sizeof(*rs);
> + ret = wilco_ec_mailbox(ec, &msg);
> + if (ret < 0)
> + return ret;
> + if (rs->status)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static ssize_t usb_power_share_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct wilco_ec_device *ec = dev_get_drvdata(dev);
> + struct usb_power_share_request rq;
> + struct usb_power_share_response rs;
> + int ret;
> +
> + memset(&rq, 0, sizeof(rq));
> + rq.cmd = CMD_USB_POWER_SHARE;
> + rq.op = POWER_SHARE_GET;
> +
> + ret = send_usb_power_share(ec, &rq, &rs);
> +
Re: [PATCH v3 1/2] platform/chrome: wilco_ec: Add Boot on AC support
Hi Nick,
Thanks for the patch, some few comments below...
Missatge de Nick Crews del dia dc., 17 d’abr.
2019 a les 3:22:
>
> Boot on AC is a policy which makes the device boot from S5 when AC
> power is connected. This is useful for users who want to run their
> device headless or with a dock.
>
> v3 changes:
> - Add docstring to wilco_ec_add_sysfs()
> - Tweak a comment
> - Use val > 1 instead of val != 0 && val != 1
> v2 changes:
> - Move documentation to Documentation/ABI/testing/sysfs-platform-wilco-ec
>
> Signed-off-by: Nick Crews
> ---
> .../ABI/testing/sysfs-platform-wilco-ec | 11 +++
> drivers/platform/chrome/wilco_ec/Makefile | 2 +-
> drivers/platform/chrome/wilco_ec/core.c | 9 +++
> drivers/platform/chrome/wilco_ec/sysfs.c | 77 +++
> include/linux/platform_data/wilco-ec.h| 12 +++
> 5 files changed, 110 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-wilco-ec
> create mode 100644 drivers/platform/chrome/wilco_ec/sysfs.c
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-wilco-ec
> b/Documentation/ABI/testing/sysfs-platform-wilco-ec
> new file mode 100644
> index ..e074c203cd32
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform-wilco-ec
> @@ -0,0 +1,11 @@
> +What: /sys/bus/platform/devices/GOOG000C\:00/boot_on_ac
> +Date: April 2019
> +KernelVersion: 5.2
> +Description:
> + Boot on AC is a policy which makes the device boot from S5
> + when AC power is connected. This is useful for users who
> + want to run their device headless or with a dock.
> +
> + Input should be parseable by kstrtou8() to 0 or 1.
> + Output will be either "0\n" or "1\n".
> +
> diff --git a/drivers/platform/chrome/wilco_ec/Makefile
> b/drivers/platform/chrome/wilco_ec/Makefile
> index 063e7fb4ea17..1281dd7737c4 100644
> --- a/drivers/platform/chrome/wilco_ec/Makefile
> +++ b/drivers/platform/chrome/wilco_ec/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -wilco_ec-objs := core.o mailbox.o
> +wilco_ec-objs := core.o mailbox.o sysfs.o
> obj-$(CONFIG_WILCO_EC) += wilco_ec.o
> wilco_ec_debugfs-objs := debugfs.o
> obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o
> diff --git a/drivers/platform/chrome/wilco_ec/core.c
> b/drivers/platform/chrome/wilco_ec/core.c
> index 05e1e2be1c91..abd15d04e57b 100644
> --- a/drivers/platform/chrome/wilco_ec/core.c
> +++ b/drivers/platform/chrome/wilco_ec/core.c
> @@ -89,8 +89,16 @@ static int wilco_ec_probe(struct platform_device *pdev)
> goto unregister_debugfs;
> }
>
> + ret = wilco_ec_add_sysfs(ec);
> + if (ret < 0) {
> + dev_err(dev, "Failed to create sysfs entries: %d", ret);
> + goto unregister_rtc;
> + }
> +
> return 0;
>
> +unregister_rtc:
> + platform_device_unregister(ec->rtc_pdev);
> unregister_debugfs:
> if (ec->debugfs_pdev)
> platform_device_unregister(ec->debugfs_pdev);
> @@ -102,6 +110,7 @@ static int wilco_ec_remove(struct platform_device *pdev)
> {
> struct wilco_ec_device *ec = platform_get_drvdata(pdev);
>
> + wilco_ec_remove_sysfs(ec);
> platform_device_unregister(ec->rtc_pdev);
> if (ec->debugfs_pdev)
> platform_device_unregister(ec->debugfs_pdev);
> diff --git a/drivers/platform/chrome/wilco_ec/sysfs.c
> b/drivers/platform/chrome/wilco_ec/sysfs.c
> new file mode 100644
> index ..959b5da2eb16
> --- /dev/null
> +++ b/drivers/platform/chrome/wilco_ec/sysfs.c
> @@ -0,0 +1,77 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Google LLC
> + *
> + * Sysfs properties to view and modify EC-controlled features on Wilco
> devices.
> + * The entries will appear under /sys/bus/platform/devices/GOOG000C:00/
> + *
> + * See Documentation/ABI/testing/sysfs-platform-wilco-ec for more
> information.
> + */
> +
> +#include
> +#include
> +
> +#define CMD_KB_CMOS0x7C
> +#define SUB_CMD_KB_CMOS_AUTO_ON0x03
> +
> +struct boot_on_ac_request {
> + u8 cmd; /* Always CMD_KB_CMOS */
> + u8 reserved1;
> + u8 sub_cmd; /* Always SUB_CMD_KB_CMOS_AUTO_ON */
> + u8 reserved3to5[3];
> + u8 val; /* Either 0 or 1 */
> + u8 reserved7;
> +} __packed;
> +
> +static ssize_t boot_on_ac_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct wilco_ec_device *ec = dev_get_drvdata(dev);
> + struct boot_on_ac_request rq;
> + struct wilco_ec_message msg;
> + int ret;
> + u8 val;
> +
> + ret = kstrtou8(buf, 10, &val);
> + if (re
Re: [PATCH v4] platform/chrome: mfd/cros_ec_debugfs: Add debugfs entry to retrieve EC uptime.
Hi Tim,
Missatge de Tim Wawrzynczak del dia dj., 2
de maig 2019 a les 18:10:
>
> The new debugfs entry 'uptime' is being made available to userspace so that
> a userspace daemon can synchronize EC logs with host time.
>
> Signed-off-by: Tim Wawrzynczak
> ---
> Enric, is there something I can do to help speed this along? This patch
> is useful for ChromeOS board bringup, and we would like to see it upstreamed
> if at all possible.
>
The last version looks good to me. The patch is in my list but is too
late for the next merge window. Will be one of the first patches I'll
queue for 5.3
Thanks,
Enric
> Also, AFAIK only the cros_ec supports the 'uptime' command for now.
> And yes, the file does need to be seekable; the userspace daemon that
> consumes the file keeps the file open and seeks back to the beginning
> to get the latest uptime value.
> Based on your second response to v3, I kept the separate 'create_uptime'
> function b/c of the logic for checking support for the uptime command.
> Let me know if you'd like me to move all of that logic into _probe.
>
> Changelist from v3:
> 1) Don't check return values of debugfs_* functions.
> 2) Only expose 'uptime' file if EC supports it.
> ---
> Documentation/ABI/testing/debugfs-cros-ec | 10 +++
> drivers/platform/chrome/cros_ec_debugfs.c | 78 +++
> 2 files changed, 88 insertions(+)
> create mode 100644 Documentation/ABI/testing/debugfs-cros-ec
>
> diff --git a/Documentation/ABI/testing/debugfs-cros-ec
> b/Documentation/ABI/testing/debugfs-cros-ec
> new file mode 100644
> index ..24b781c67a4c
> --- /dev/null
> +++ b/Documentation/ABI/testing/debugfs-cros-ec
> @@ -0,0 +1,10 @@
> +What: /sys/kernel/debug/cros_ec/uptime
> +Date: March 2019
> +KernelVersion: 5.1
> +Description:
> + Read-only.
> + Reads the EC's current uptime information
> + (using EC_CMD_GET_UPTIME_INFO) and prints
> + time_since_ec_boot_ms into the file.
> + This is used for synchronizing AP host time
> + with the cros_ec log.
> diff --git a/drivers/platform/chrome/cros_ec_debugfs.c
> b/drivers/platform/chrome/cros_ec_debugfs.c
> index 71308766e891..226545a2150b 100644
> --- a/drivers/platform/chrome/cros_ec_debugfs.c
> +++ b/drivers/platform/chrome/cros_ec_debugfs.c
> @@ -201,6 +201,50 @@ static int cros_ec_console_log_release(struct inode
> *inode, struct file *file)
> return 0;
> }
>
> +static int cros_ec_get_uptime(struct cros_ec_device *ec_dev, u32 *uptime)
> +{
> + struct {
> + struct cros_ec_command msg;
> + struct ec_response_uptime_info resp;
> + } __packed ec_buf;
> + struct ec_response_uptime_info *resp;
> + struct cros_ec_command *msg;
> +
> + msg = &ec_buf.msg;
> + resp = (struct ec_response_uptime_info *)msg->data;
> +
> + msg->command = EC_CMD_GET_UPTIME_INFO;
> + msg->version = 0;
> + msg->insize = sizeof(*resp);
> + msg->outsize = 0;
> +
> + ret = cros_ec_cmd_xfer_status(ec_dev, msg);
> + if (ret < 0)
> + return ret;
> +
> + *uptime = resp->time_since_ec_boot_ms;
> + return 0;
> +}
> +
> +static ssize_t cros_ec_uptime_read(struct file *file,
> + char __user *user_buf,
> + size_t count,
> + loff_t *ppos)
> +{
> + struct cros_ec_debugfs *debug_info = file->private_data;
> + struct cros_ec_device *ec_dev = debug_info->ec->ec_dev;
> + char read_buf[32];
> + int ret;
> + u32 uptime;
> +
> + ret = cros_ec_get_uptime(ec_dev, &uptime);
> + if (ret < 0)
> + return ret;
> +
> + ret = scnprintf(read_buf, sizeof(read_buf), "%u\n", uptime);
> + return simple_read_from_buffer(user_buf, count, ppos, read_buf, ret);
> +}
> +
> static ssize_t cros_ec_pdinfo_read(struct file *file,
>char __user *user_buf,
>size_t count,
> @@ -269,6 +313,13 @@ const struct file_operations cros_ec_pdinfo_fops = {
> .llseek = default_llseek,
> };
>
> +const struct file_operations cros_ec_uptime_fops = {
> + .owner = THIS_MODULE,
> + .open = simple_open,
> + .read = cros_ec_uptime_read,
> + .llseek = default_llseek,
> +};
> +
> static int ec_read_version_supported(struct cros_ec_dev *ec)
> {
> struct ec_params_get_cmd_versions_v1 *params;
> @@ -413,6 +464,29 @@ static int cros_ec_create_pdinfo(struct cros_ec_debugfs
> *debug_info)
> return 0;
> }
>
> +static int cros_ec_create_uptime(struct cros_ec_debugfs *debug_info)
> +{
> + struct cros_ec_debugfs *debug_info = file->private_data;
> + struct cros_ec_device *ec_dev = debug_info->ec->ec_dev;
> + u32 uptime;
> + int ret;
> +
> + /*
> +* If the EC does not support th
Re: [PATCH 2/3] power: supply: Add driver for Microchip UCS1002
> +
> + rdev = devm_regulator_register(dev, info->regulator_descriptor,
> + ®ulator_config);
> + if (IS_ERR(rdev)) {
> + dev_err(dev, "failed to register VBUS regulator\n");
> + return PTR_ERR(rdev);
> + }
> +
> + if (irq_a_det > 0) {
> + ret = devm_request_threaded_irq(dev, irq_a_det, NULL,
> + ucs1002_charger_irq,
> + IRQF_TRIGGER_FALLING |
> + IRQF_TRIGGER_RISING |
> + IRQF_ONESHOT,
> + "ucs1002-a_det", info);
> + if (ret) {
> + dev_err(dev, "failed to request A_DET threaded
> irq\n");
> + return ret;
> + }
> + }
> +
> + if (irq_alert > 0) {
> + ret = devm_request_threaded_irq(dev, irq_alert, NULL,
> + ucs1002_alert_irq,
> + IRQF_TRIGGER_FALLING |
> + IRQF_TRIGGER_RISING |
> + IRQF_ONESHOT,
> + "ucs1002-alert", info);
> + if (ret) {
> + dev_err(dev, "failed to request ALERT threaded
> irq\n");
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +#if IS_ENABLED(CONFIG_OF)
This driver is DT only, this if is not needed.
> +static const struct of_device_id ucs1002_of_match[] = {
> + { .compatible = "microchip,ucs1002", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ucs1002_of_match);
> +#endif
> +
> +static const struct i2c_device_id ucs1002_ids[] = {
> + {"ucs1002", 0},
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(i2c, ucs1002_ids);
> +
> +static struct i2c_driver ucs1002_driver = {
> + .driver = {
> + .name = "ucs1002",
> + .of_match_table = of_match_ptr(ucs1002_of_match),
No need to use of_match_ptr, is DT-only.
> + },
> + .probe = ucs1002_probe,
> +};
> +module_i2c_driver(ucs1002_driver);
> +
> +MODULE_DESCRIPTION("Microchip UCS1002 Programmable USB Port Power
> Controller");
> +MODULE_AUTHOR("Enric Balletbo Serra ");
I'm not sure how much differs this patch from the one I sent 3 years
ago ... but if i'm the author or co-author you should add the
signed-off-by.
[1] https://lkml.org/lkml/2016/3/14/233
[2] https://www.spinics.net/lists/devicetree/msg122745.html
> +MODULE_AUTHOR("Andrey Smirnov ");
> +MODULE_LICENSE("GPL v2");
> --
> 2.20.1
>
Re: [PATCH] PM / devfreq: return PTR_ERR not NULL in try_then_request_governor()
Hi,
Missatge de Steven Price del dia dc., 3 d’abr.
2019 a les 17:26:
>
> The callers of try_then_request_governor() only test for a PTR_ERR using
> IS_ERR(). However in the case that request_module() fails then NULL is
> currently returned which will cause a NULL-pointer dereference in the
> caller.
>
> Instead convert the error we already have to a valid PTR_ERR and return
> it.
>
> Fixes: 23c7b54ca1cd ("PM / devfreq: Fix devfreq_add_device() when drivers are
> built as modules.")
> Signed-off-by: Steven Price
There is already a fix for that. The fix was initially sent in October [2] but
unfortunately, it got lost. I resend and now is queued [1]. Hopefully, the Fixes
tag will help to pick the fix to the proper kernel releases.
Thanks,
Enric
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/commit/?h=for-next&id=b53b0128052ffd687797d5f4deeb76327e7b5711
[2] https://lkml.org/lkml/2018/10/16/744
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 0ae3de76833b..d29f66f0e52a 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -254,7 +254,7 @@ static struct devfreq_governor
> *try_then_request_governor(const char *name)
> /* Restore previous state before return */
> mutex_lock(&devfreq_list_lock);
> if (err)
> - return NULL;
> + return ERR_PTR(err);
>
> governor = find_devfreq_governor(name);
> }
> --
> 2.20.1
>
Re: [PATCH] cros_ec: Add trace event to trace EC commands
Hi,
Many thanks for sending this patch upstream. Looks really interesting.
Some few comments below ...
Please prefix the patch with "chrome/platform: cros_ec_proto: ..."
Missatge de Raul E Rangel del dia dc., 10
d’abr. 2019 a les 22:25:
>
> This is useful to see which EC commands are being executed and when.
>
> To enable:
>
> echo 'cros_ec:*' >> /sys/kernel/debug/tracing/set_event
>
> Example:
>
> /* cros_ec_cmd: version: 0, command: GET_VERSION */
> /* cros_ec_cmd: version: 0, command: GET_PROTOCOL_INFO */
> /* cros_ec_cmd: version: 1, command: GET_CMD_VERSIONS */
> /* cros_ec_cmd: version: 1, command: USB_PD_CONTROL */
>
> Signed-off-by: Raul E Rangel
> ---
>
> drivers/platform/chrome/Makefile| 4 +-
> drivers/platform/chrome/cros_ec_proto.c | 4 +
> drivers/platform/chrome/cros_ec_trace.c | 163
> drivers/platform/chrome/cros_ec_trace.h | 51
> 4 files changed, 221 insertions(+), 1 deletion(-)
> create mode 100644 drivers/platform/chrome/cros_ec_trace.c
> create mode 100644 drivers/platform/chrome/cros_ec_trace.h
>
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index 1e2f0029b597..e542268454a4 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -3,12 +3,14 @@
> obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> obj-$(CONFIG_CHROMEOS_TBMC)+= chromeos_tbmc.o
> +# tell define_trace.h where to find the cros ec trace header
> +CFLAGS_cros_ec_trace.o:= -I$(src)
> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
> obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
> cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o
> cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
> obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpcs.o
> -obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
> +obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o cros_ec_trace.o
> obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
> obj-$(CONFIG_CROS_EC_LIGHTBAR) += cros_ec_lightbar.o
> obj-$(CONFIG_CROS_EC_VBC) += cros_ec_vbc.o
> diff --git a/drivers/platform/chrome/cros_ec_proto.c
> b/drivers/platform/chrome/cros_ec_proto.c
> index 97a068dff192..3d02c8259ac6 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -10,6 +10,8 @@
> #include
> #include
>
> +#include "cros_ec_trace.h"
> +
> #define EC_COMMAND_RETRIES 50
>
> static int prepare_packet(struct cros_ec_device *ec_dev,
> @@ -51,6 +53,8 @@ static int send_command(struct cros_ec_device *ec_dev,
> int ret;
> int (*xfer_fxn)(struct cros_ec_device *ec, struct cros_ec_command
> *msg);
>
> + trace_cros_ec_cmd(msg);
> +
> if (ec_dev->proto_version > 2)
> xfer_fxn = ec_dev->pkt_xfer;
> else
> diff --git a/drivers/platform/chrome/cros_ec_trace.c
> b/drivers/platform/chrome/cros_ec_trace.c
> new file mode 100644
> index ..799c8e2bfd22
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_trace.c
> @@ -0,0 +1,163 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Trace events for the ChromeOS Embedded Controller
> + *
> + * Copyright 2019 Google LLC.
> + */
Use the c++ style here to be coherent with the other cros_ec_*.c files
> +
> +#define ec_cmds \
> + {EC_CMD_PROTO_VERSION, "PROTO_VERSION"}, \
> + {EC_CMD_HELLO, "HELLO"}, \
> + {EC_CMD_GET_VERSION, "GET_VERSION"}, \
> + {EC_CMD_READ_TEST, "READ_TEST"}, \
> + {EC_CMD_GET_BUILD_INFO, "GET_BUILD_INFO"}, \
> + {EC_CMD_GET_CHIP_INFO, "GET_CHIP_INFO"}, \
> + {EC_CMD_GET_BOARD_VERSION, "GET_BOARD_VERSION"}, \
> + {EC_CMD_READ_MEMMAP, "READ_MEMMAP"}, \
> + {EC_CMD_GET_CMD_VERSIONS, "GET_CMD_VERSIONS"}, \
> + {EC_CMD_GET_COMMS_STATUS, "GET_COMMS_STATUS"}, \
> + {EC_CMD_TEST_PROTOCOL, "TEST_PROTOCOL"}, \
> + {EC_CMD_GET_PROTOCOL_INFO, "GET_PROTOCOL_INFO"}, \
> + {EC_CMD_GSV_PAUSE_IN_S5, "GSV_PAUSE_IN_S5"}, \
> + {EC_CMD_GET_FEATURES, "GET_FEATURES"}, \
> + {EC_CMD_GET_SKU_ID, "GET_SKU_ID"}, \
> + {EC_CMD_SET_SKU_ID, "SET_SKU_ID"}, \
> + {EC_CMD_FLASH_INFO, "FLASH_INFO"}, \
> + {EC_CMD_FLASH_READ, "FLASH_READ"}, \
> + {EC_CMD_FLASH_WRITE, "FLASH_WRITE"}, \
> + {EC_CMD_FLASH_ERASE, "FLASH_ERASE"}, \
> + {EC_CMD_FLASH_PROTECT, "FLASH_PROTECT"}, \
> + {EC_CMD_FLASH_REGION_INFO, "FLASH_REGION_INFO"}, \
> + {EC_CMD_VBNV_CONTEXT, "VBNV_CONTEXT"}, \
> + {EC_CMD_FLASH_SPI_INFO, "FLASH_SPI_INFO"}, \
> + {EC_CMD_FLASH_SELECT, "FLASH_SELECT"}, \
> + {EC_CMD_PWM_GET_FAN_TARGET_RPM, "PWM_GET_FAN_TARGET_RPM"}, \
> + {EC_CMD_PWM_SET_FAN_TARGET_RPM, "PWM_SET_FAN_TARGET_RPM"}, \
> + {EC_CMD_PWM_GET_KEYBOARD_BAC
Re: [PATCH v3] platform/chrome: wilco_ec: Add h1_gpio status to debugfs
Hi Nick,
Some comments below ...
Missatge de Nick Crews del dia dj., 11 d’abr.
2019 a les 0:09:
>
> As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
> tests, we need to ensure that the H1 chip is properly setting
> some GPIO lines. The h1_gpio attribute exposes the state
> of the lines:
> - ENTRY_TO_FACT_MODE in BIT(0)
> - SPI_CHROME_SEL in BIT(1)
>
> There are two reasons that I am exposing this in debugfs,
> and not as a GPIO:
> 1. This is only useful for testing, so end users shouldn't ever
> care about this. In fact, if it passes the tests, then the value of
> h1_gpio will always be 2, so it would be really uninteresting for users.
> 2. This GPIO is not connected to, controlled by, or really even related
> to the AP. The GPIO runs between the EC and the H1 security chip.
>
> Changes in v3:
> - Fix documentation to correspond with formatting change in v2.
> Changes in v2:
> - Zero out the unused fields in the request.
> - Format result as "%02x\n" instead of as a decimal.
I don't really mind, but wouldn't be more clear prefix with 0x (0x%02x)?
>
> Signed-off-by: Nick Crews
> ---
> drivers/platform/chrome/wilco_ec/debugfs.c | 64 +-
ABI documentation missing.
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c
> b/drivers/platform/chrome/wilco_ec/debugfs.c
> index 17c4c9068aaf..1b93243c8954 100644
> --- a/drivers/platform/chrome/wilco_ec/debugfs.c
> +++ b/drivers/platform/chrome/wilco_ec/debugfs.c
> @@ -4,7 +4,7 @@
> *
> * Copyright 2019 Google LLC
> *
> - * There is only one attribute used for debugging, called raw.
> + * The raw attribute is very useful for EC debugging.
> * You can write a hexadecimal sentence to raw, and that series of bytes
> * will be sent to the EC. Then, you can read the bytes of response
> * by reading from raw.
> @@ -30,6 +30,16 @@
> * Note that the first 32 bytes of the received MBOX[] will be printed,
> * even if some of the data is junk. It is up to you to know how many of
> * the first bytes of data are the actual response.
> + *
> + * There is also another debugfs attribute, called h1_gpio.
> + * As part of Chrome OS's FAFT (Fully Automated Firmware Testing)
> + * tests, we need to ensure that the H1 chip is properly setting
> + * some GPIO lines. The h1_gpio attribute exposes the state
> + * of the lines:
> + * - ENTRY_TO_FACT_MODE in BIT(0)
> + * - SPI_CHROME_SEL in BIT(1)
> +
> + * Output will formatted with "%02x\n".
> */
>
> #include
> @@ -189,6 +199,56 @@ static const struct file_operations fops_raw = {
> .llseek = no_llseek,
> };
>
> +#define CMD_KB_CHROME 0x88
> +#define SUB_CMD_H1_GPIO0x0A
> +
> +struct h1_gpio_status_request {
> + u8 cmd; /* Always CMD_KB_CHROME */
> + u8 reserved;
> + u8 sub_cmd; /* Always SUB_CMD_H1_GPIO */
> +} __packed;
> +
> +struct hi_gpio_status_response {
> + u8 status; /* 0 if allowed */
> + u8 val; /* BIT(0)=ENTRY_TO_FACT_MODE, BIT(1)=SPI_CHROME_SEL */
> +} __packed;
> +
> +static ssize_t h1_gpio_read(struct file *file, char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct h1_gpio_status_request rq;
> + struct hi_gpio_status_response rs;
> + struct wilco_ec_message msg;
> + char buf[4];
> + int ret;
> +
> + memset(&rq, 0, sizeof(rq));
> + rq.cmd = CMD_KB_CHROME;
> + rq.sub_cmd = SUB_CMD_H1_GPIO;
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.type = WILCO_EC_MSG_LEGACY;
> + msg.request_data = &rq;
> + msg.request_size = sizeof(rq);
> + msg.response_data = &rs;
> + msg.response_size = sizeof(rs);
> + ret = wilco_ec_mailbox(debug_info->ec, &msg);
> + if (ret < 0)
> + return ret;
> + if (rs.status)
> + return -EIO;
> +
> + sprintf(buf, "%02x\n", rs.val);
> +
> + return simple_read_from_buffer(user_buf, count, ppos, buf,
> sizeof(buf));
> +}
> +
> +static const struct file_operations fops_h1_gpio = {
> + .owner = THIS_MODULE,
> + .read = h1_gpio_read,
> + .llseek = no_llseek,
> +};
> +
I think that I'd use the DEFINE_DEBUGFS_ATTRIBUTE here.
> /**
> * wilco_ec_debugfs_probe() - Create the debugfs node
> * @pdev: The platform device, probably created in core.c
> @@ -210,6 +270,8 @@ static int wilco_ec_debugfs_probe(struct platform_device
> *pdev)
> if (!debug_info->dir)
> return 0;
> debugfs_create_file("raw", 0644, debug_info->dir, NULL, &fops_raw);
> + debugfs_create_file("h1_gpio", 0444, debug_info->dir, NULL,
> + &fops_h1_gpio);
>
> return 0;
> }
> --
> 2.20.1
>
Thanks,
Enric
Re: [PATCH] platform/chrome: cros_ec_proto: Also return invalid command in cros_ec_cmd_xfer_status
Hi,
Missatge de Guenter Roeck del dia dc., 3 d’abr.
2019 a les 18:27:
>
> On Wed, Apr 3, 2019 at 6:51 AM Enric Balletbo i Serra
> wrote:
> >
> > The commit 9798ac6d32c1 ("mfd: cros_ec: Add cros_ec_cmd_xfer_status()
> > helper") was introduced to remove duplicated code in several users of
> > the cros_ec_cmd_xfer function. The idea behind that commit is mask all
> > the EC errors as protocol error when the EC command fails, what is
> > really useful because as a user you probably don't care of the exact
> > error reported by the EC, you only want to know if the command succeeded
> > or not.
> >
> > That works for most of the errors returned by the EC, but we might be
> > also interested on report the EC_RES_INVALID_COMMAND, which happens when
> > the command is not supported by the EC. An use case for this is when you
> > need to show/hide a sysfs attribute for a specific command and you don't
> > have a EC feature flag that tells you that the command is supported or
> > not.
> >
Actually, I discarded this patch, I assumed wrongly that this patch
will avoid some boilerplate on the above cases but that's not true
because there is no difference between check that ret == -EINVAL or
check that msg->result == EC_RES_INVALID_COMMAND.
> > While here, also document properly the cros_ec_cmd_xfer_status
> > function.
> >
Also, this function was properly documented in the header, so that is
not needed, my bad.
Thanks,
Enric
> > Signed-off-by: Enric Balletbo i Serra
>
> Reviewed-by: Guenter Roeck
>
> > ---
> >
> > drivers/platform/chrome/cros_ec_proto.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 97a068dff192..a4e0d3a6d891 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -478,6 +478,16 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
> > }
> > EXPORT_SYMBOL(cros_ec_cmd_xfer);
> >
> > +/**
> > + * cros_ec_cmd_xfer_status() - Send EC command.
> > + * @ec_dev: EC device.
> > + * @msg: EC message data for request and response.
> > + *
> > + * Return:
> > + * 0 - OK
> > + * -EINVAL - Invalid command.
> > + * -EPROTO - Protocol error.
> > + */
> > int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> > struct cros_ec_command *msg)
> > {
> > @@ -486,6 +496,11 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device
> > *ec_dev,
> > ret = cros_ec_cmd_xfer(ec_dev, msg);
> > if (ret < 0) {
> > dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> > + } else if (msg->result == EC_RES_INVALID_COMMAND) {
> > + dev_dbg(ec_dev->dev,
> > + "Command %d not supported for this device\n",
> > + msg->command);
> > + return -EINVAL;
> > } else if (msg->result != EC_RES_SUCCESS) {
> > dev_dbg(ec_dev->dev, "Command result (err: %d)\n",
> > msg->result);
> > return -EPROTO;
> > --
> > 2.20.1
> >
Re: [PATCH v7 6/7] platform/chrome: cros_ec: add EC host command support using rpmsg.
Hi,
Missatge de Pi-Hsun Shih del dia dc., 10 d’abr.
2019 a les 9:13:
>
> Hi,
>
> On Thu, Mar 28, 2019 at 7:16 PM Enric Balletbo Serra
> wrote:
> >
> > Hi
> >
> > Thanks for sending this upstream, Some few comments and questions
> > below. Apart from these LGTM.
> >
> > Missatge de Peter Shih del dia dc., 27 de març
> > 2019 a les 6:17:
> > >
> > > From: Pi-Hsun Shih
> > >
> > > Add EC host command support through rpmsg.
> > >
> > > Signed-off-by: Pi-Hsun Shih
> > > ---
> > > ...
> > > diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
> > > b/drivers/platform/chrome/cros_ec_rpmsg.c
> > > new file mode 100644
> > > index ..2ecae806cfc5
> > > --- /dev/null
> > > +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> > > ...
> > > +static int cros_ec_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
> > > + int len, void *priv, u32 src)
> > > +{
> > > + struct cros_ec_device *ec_dev = dev_get_drvdata(&rpdev->dev);
> > > + struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
> > > + struct cros_ec_rpmsg_response *resp;
> > > +
> > > + if (!len) {
> > > + dev_warn(ec_dev->dev, "rpmsg received empty response");
> >
> > Is this is unlikely to happen?
>
> Yes this should not happen unless the firmware is broken. Should I
> change this to `if(unlikely(!len))`, or use dev_err instead ?
>
> >
> > > + return -EINVAL;
> > > + }
> > > +
> > > + resp = data;
> > > + len -= offsetof(struct cros_ec_rpmsg_response, data);
> > > + if (resp->type == HOST_COMMAND_MARK) {
> > > + if (len > ec_dev->din_size) {
> > > + dev_warn(
> > > + ec_dev->dev,
> > > + "received length %d > din_size %d,
> > > truncating",
> > > + len, ec_dev->din_size);
> >
> > How often this warning appears? Should be this a dev_dbg?
>
> This also should not happen unless the firmware is broken, so I think
> it's better to have a warning here when there's something wrong.
>
Ok, fine with me.
> >
> > > + len = ec_dev->din_size;
> > > + }
> > > +
> > > + memcpy(ec_dev->din, resp->data, len);
> > > + complete(&ec_rpmsg->xfer_ack);
> > > + } else if (resp->type == HOST_EVENT_MARK) {
> > > + schedule_work(&ec_rpmsg->host_event_work);
> > > + } else {
> > > + dev_warn(ec_dev->dev, "rpmsg received invalid type = %d",
> > > +resp->type);
> >
> > Is this is unlikely to happen?
>
> Same as above, this should not happen unless the firmware is broken.
>
> >
> > > + return -EINVAL;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev)
> > > +{
> > > + struct device *dev = &rpdev->dev;
> > > + struct cros_ec_device *ec_dev;
> > > + struct cros_ec_rpmsg *ec_rpmsg;
> > > + int ret;
> > > +
> > > + ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
> > > + if (!ec_dev)
> > > + return -ENOMEM;
> > > +
> > > + ec_rpmsg = devm_kzalloc(dev, sizeof(*ec_rpmsg), GFP_KERNEL);
> > > + if (!ec_rpmsg)
> > > + return -ENOMEM;
> > > +
> > > + ec_dev->dev = dev;
> > > + ec_dev->priv = ec_rpmsg;
> > > + ec_dev->cmd_xfer = cros_ec_cmd_xfer_rpmsg;
> > > + ec_dev->pkt_xfer = cros_ec_pkt_xfer_rpmsg;
> > > + ec_dev->phys_name = dev_name(&rpdev->dev);
> > > + ec_dev->din_size = sizeof(struct ec_host_response) +
> > > + sizeof(struct ec_response_get_protocol_info);
> > > + ec_dev->dout_size = sizeof(struct ec_host_request);
> > > + dev_set_drvdata(dev, ec_dev);
> > > +
> > > + ec_rpmsg->rpdev = rpdev;
> > > + init_completion(&ec_rpmsg->xfer_ack);
> > >
Re: [PATCH 1/2] platform/chrome: Add CrOS USB PD logging driver
Missatge de Guenter Roeck del dia dv., 5 d’abr.
2019 a les 23:38:
>
> On Fri, Apr 5, 2019 at 2:09 PM Enric Balletbo Serra
> wrote:
> >
> > Hi Guenter,
> >
> > Missatge de Guenter Roeck del dia dv., 5 d’abr.
> > 2019 a les 21:59:
> > >
> > > Hi Enric,
> > >
> > > On Wed, Apr 3, 2019 at 6:54 AM Enric Balletbo i Serra
> > > wrote:
> > > >
> > > > From: Guenter Roeck
> > > >
> > > > The CrOS USB PD logging feature is logically separate functionality of
> > > > the charge manager, hence has its own driver. The driver logs the event
> > > > data for the USB PD charger available in some ChromeOS Embedded
> > > > Controllers.
> > > >
> > > > Signed-off-by: Guenter Roeck
> > > > [remove APPEND_STRING macro and minor cleanups]
> > > > Signed-off-by: Enric Balletbo i Serra
> > > > ---
> > > >
> > > [ ... ]
> > >
> > > > +
> > > > +static void cros_usbpd_print_log_entry(struct ec_response_pd_log *r,
> > > > + ktime_t tstamp)
> > > > +{
> > > [ ... ]
> > > > +
> > > > + pr_info("PDLOG %d/%02d/%02d %02d:%02d:%02d.%03lld P%d %s\n",
> > > > + rt.tm_year + 1900, rt.tm_mon + 1, rt.tm_mday,
> > > > + rt.tm_hour, rt.tm_min, rt.tm_sec,
> > > > + ktime_to_ms(tstamp) % MSEC_PER_SEC,
> > >
> > > 0day rightfully complains that this introduces a 64-bit divide
> > > operation. I don't know if do_div() works here since it tries to
> > > modify the first parameter. Maybe we need an interim variable to store
> > > ktime_to_ms(tstamp). Something like
> > >
> > > s64 temp = ktime_to_ms(tstamp);
> > > ...
> > > do_div(temp, MSEC_PER_SEC),
> > >
> >
> > I did something similar this afternoon and pushed again for the auto
> > builders to play with.
> >
> > + div_s64_rem(ktime_to_ms(tstamp), MSEC_PER_SEC, &rem);
> >
> > Unfortunately, 0day now reports another error
> >
> > drivers/platform/chrome/cros_usbpd_logger.o: In function
> > `cros_usbpd_print_log_entry':
> > >> cros_usbpd_logger.c:(.text+0x5a0): undefined reference to
> > >> `__aeabi_ldivmod'
> >
>
> I think that may have been with the earlier version of the code. Your
> top of tree doesn't include the SHA that is reported as failing.
>
Oh right, good, thank you for telling me, I guess is time to go to bed
for me :-)
Enric
> Guenter
Re: [PATCH 1/3] platform/chrome: wilco_ec: Standardize mailbox interface
Hi Nick, Missatge de Nick Crews del dia dv., 5 d’abr. 2019 a les 22:09: > > The current API for the wilco EC mailbox interface is bad. > > It assumes that most messages sent to the EC follow a similar structure, > with a command byte in MBOX[0], followed by a junk byte, followed by > actual data. This doesn't happen in several cases, such as setting the > RTC time, using the raw debugfs interface, and reading or writing > properties such as the Peak Shift policy (this last to be submitted soon). > > Similarly for the response message from the EC, the current interface > assumes that the first byte of data is always 0, and the second byte > is unused. However, in both setting and getting the RTC time, in the > debugfs interface, and for reading and writing properties, this isn't > true. > > The current way to resolve this is to use WILCO_EC_FLAG_RAW* flags to > specify when and when not to skip these initial bytes in the sent and > received message. They are confusing and used so much that they are > normal, and not exceptions. In addition, the first byte of > response in the debugfs interface is still always skipped, which is > weird, since this raw interface should be giving the entire result. > > Additionally, sent messages assume the first byte is a command, and so > struct wilco_ec_message contains the "command" field. In setting or > getting properties however, the first byte is not a command, and so this > field has to be filled with a byte that isn't actually a command. This > is again inconsistent. > > wilco_ec_message contains a result field as well, copied from > wilco_ec_response->result. The message result field should be removed: > if the message fails, the cause is already logged, and the callers are > alerted. They will never care about the actual state of the result flag. > > These flags and different cases make the wilco_ec_transfer() function, > used in wilco_ec_mailbox(), really gross, dealing with a bunch of > different cases. It's difficult to figure out what it is doing. > > Finally, making these assumptions about the structure of a message make > it so that the messages do not correspond well with the specification > for the EC's mailbox interface. For instance, this interface > specification may say that MBOX[9] in the received message contains > some information, but the calling code needs to remember that the first > byte of response is always skipped, and because it didn't set the > RESPONSE_RAW flag, the next byte is also skipped, so this information > is actually contained within wilco_ec_message->response_data[7]. This > makes it difficult to maintain this code in the future. > > To fix these problems this patch standardizes the mailbox interface by: > - Removing the WILCO_EC_FLAG_RAW* flags > - Removing the command and reserved_raw bytes from wilco_ec_request > - Removing the mbox0 byte from wilco_ec_response > - Simplifying wilco_ec_transfer() because of these changes > - Gives the callers of wilco_ec_mailbox() the responsibility of exactly > and consistently defining the structure of the mailbox request and > response > - Removing command and result from wilco_ec_message. > > This results in the reduction of total code, and makes it much more > maintainable and understandable. > > Signed-off-by: Nick Crews > Acked-by: Alexandre Belloni > --- > drivers/platform/chrome/wilco_ec/debugfs.c | 43 --- > drivers/platform/chrome/wilco_ec/mailbox.c | 53 -- > drivers/rtc/rtc-wilco-ec.c | 63 +- > include/linux/platform_data/wilco-ec.h | 22 +--- > 4 files changed, 83 insertions(+), 98 deletions(-) > Now I'm confused, isn't this the same patch I picked this morning from you and is already applied in chrome-platform for-next? [snip]
Re: [PATCH 1/2] platform/chrome: Add CrOS USB PD logging driver
Hi Guenter,
Missatge de Guenter Roeck del dia dv., 5 d’abr.
2019 a les 21:59:
>
> Hi Enric,
>
> On Wed, Apr 3, 2019 at 6:54 AM Enric Balletbo i Serra
> wrote:
> >
> > From: Guenter Roeck
> >
> > The CrOS USB PD logging feature is logically separate functionality of
> > the charge manager, hence has its own driver. The driver logs the event
> > data for the USB PD charger available in some ChromeOS Embedded
> > Controllers.
> >
> > Signed-off-by: Guenter Roeck
> > [remove APPEND_STRING macro and minor cleanups]
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> [ ... ]
>
> > +
> > +static void cros_usbpd_print_log_entry(struct ec_response_pd_log *r,
> > + ktime_t tstamp)
> > +{
> [ ... ]
> > +
> > + pr_info("PDLOG %d/%02d/%02d %02d:%02d:%02d.%03lld P%d %s\n",
> > + rt.tm_year + 1900, rt.tm_mon + 1, rt.tm_mday,
> > + rt.tm_hour, rt.tm_min, rt.tm_sec,
> > + ktime_to_ms(tstamp) % MSEC_PER_SEC,
>
> 0day rightfully complains that this introduces a 64-bit divide
> operation. I don't know if do_div() works here since it tries to
> modify the first parameter. Maybe we need an interim variable to store
> ktime_to_ms(tstamp). Something like
>
> s64 temp = ktime_to_ms(tstamp);
> ...
> do_div(temp, MSEC_PER_SEC),
>
I did something similar this afternoon and pushed again for the auto
builders to play with.
+ div_s64_rem(ktime_to_ms(tstamp), MSEC_PER_SEC, &rem);
Unfortunately, 0day now reports another error
drivers/platform/chrome/cros_usbpd_logger.o: In function
`cros_usbpd_print_log_entry':
>> cros_usbpd_logger.c:(.text+0x5a0): undefined reference to `__aeabi_ldivmod'
I'll investigate in more detail Monday morning.
Thanks
- Enric
> Guenter
Re: [PATCH v3 2/2] platform/chrome: Add support for v1 of host sleep event
Missatge de Rajat Jain del dia dj., 4 d’abr. 2019
a les 20:41:
>
> On Wed, Apr 3, 2019 at 2:34 PM Evan Green wrote:
> >
> > Add support in code for the new forms of the host sleep event.
> > Detects the presence of this version of the command at runtime,
> > and use whichever form the EC supports. At this time, always
> > request the default timeout, and only report the failing response
> > via a WARN_ONCE(). Future versions could accept the sleep parameter
> > from outside the driver, and return the response information to
> > usermode or elsewhere.
> >
> > Signed-off-by: Evan Green
> Reviewed-by: Rajat Jain
Acked-by: Enric Balletbo i Serra
>
> >
> > ---
> >
> > Changes in v3:
> > - Consolidated boolean logic for host_sleep_v1 (Guenter)
> >
> > Changes in v2:
> > - Removed unnecessary version assignment (Guenter)
> > - Changed WARN to WARN_ONCE (Guenter)
> > - Fixed C code to use anonymous unions
> > - insize is only bigger for resume events.
> >
> > drivers/mfd/cros_ec.c | 39 +
> > drivers/platform/chrome/cros_ec_proto.c | 6
Lee, how do you want to manage this, do you want to create an
immutable branch? Or do you want I do?
Thanks,
- Enric
> > include/linux/mfd/cros_ec.h | 2 ++
> > 3 files changed, 42 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> > index 6acfe036d522..bd2bcdd4718b 100644
> > --- a/drivers/mfd/cros_ec.c
> > +++ b/drivers/mfd/cros_ec.c
> > @@ -75,20 +75,49 @@ static irqreturn_t ec_irq_thread(int irq, void *data)
> >
> > static int cros_ec_sleep_event(struct cros_ec_device *ec_dev, u8
> > sleep_event)
> > {
> > + int ret;
> > struct {
> > struct cros_ec_command msg;
> > - struct ec_params_host_sleep_event req;
> > + union {
> > + struct ec_params_host_sleep_event req0;
> > + struct ec_params_host_sleep_event_v1 req1;
> > + struct ec_response_host_sleep_event_v1 resp1;
> > + } u;
> > } __packed buf;
> >
> > memset(&buf, 0, sizeof(buf));
> >
> > - buf.req.sleep_event = sleep_event;
> > + if (ec_dev->host_sleep_v1) {
> > + buf.u.req1.sleep_event = sleep_event;
> > + buf.u.req1.suspend_params.sleep_timeout_ms =
> > + EC_HOST_SLEEP_TIMEOUT_DEFAULT;
> > +
> > + buf.msg.outsize = sizeof(buf.u.req1);
> > + if ((sleep_event == HOST_SLEEP_EVENT_S3_RESUME) ||
> > + (sleep_event == HOST_SLEEP_EVENT_S0IX_RESUME))
> > + buf.msg.insize = sizeof(buf.u.resp1);
> > +
> > + buf.msg.version = 1;
> > +
> > + } else {
> > + buf.u.req0.sleep_event = sleep_event;
> > + buf.msg.outsize = sizeof(buf.u.req0);
> > + }
> >
> > buf.msg.command = EC_CMD_HOST_SLEEP_EVENT;
> > - buf.msg.version = 0;
> > - buf.msg.outsize = sizeof(buf.req);
> >
> > - return cros_ec_cmd_xfer(ec_dev, &buf.msg);
> > + ret = cros_ec_cmd_xfer(ec_dev, &buf.msg);
> > +
> > + /* For now, report failure to transition to S0ix with a warning. */
> > + if (ret >= 0 && ec_dev->host_sleep_v1 &&
> > + (sleep_event == HOST_SLEEP_EVENT_S0IX_RESUME))
> > + WARN_ONCE(buf.u.resp1.resume_response.sleep_transitions &
> > + EC_HOST_RESUME_SLEEP_TIMEOUT,
> > + "EC detected sleep transition timeout. Total
> > slp_s0 transitions: %d",
> > + buf.u.resp1.resume_response.sleep_transitions &
> > + EC_HOST_RESUME_SLEEP_TRANSITIONS_MASK);
> > +
> > + return ret;
> > }
> >
> > int cros_ec_register(struct cros_ec_device *ec_dev)
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 97a068dff192..52ca564a64e7 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -414,6 +414,12 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev)
> > else
> > ec_dev->mkbp_event_supported = 1;
> >
> > + /* Probe if host sleep v1 is supported for S0ix failure detection.
> > */
> > + ret = cros_ec_get_host_command_version_mask(ec_dev,
> > + EC_CMD_HOST_SLEEP_EVENT,
> > + &ver_mask);
> > + ec_dev->host_sleep_v1 = (ret >= 0 && (ver_mask & EC_VER_MASK(1)));
> > +
> > /*
> > * Get host event wake mask, assume all events are wake events
> > * if unavailable.
> > diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> > index 8f2a8918bfa3..b6442201f77f 100644
> > --- a/include/linux/mfd/cros_ec.h
> > +++ b/include/linux/mfd/cros_ec.h
> > @@ -120,6 +120,7 @@ st
Re: [PATCH v3 1/2] mfd: cros_ec: Add host_sleep_event_v1 command
Missatge de Rajat Jain del dia dj., 4 d’abr. 2019
a les 20:40:
>
> On Wed, Apr 3, 2019 at 2:34 PM Evan Green wrote:
> >
> > Introduce the command and response structures for the second revision
> > of the host sleep event. These structures are part of a new EC change
> > that enables detection of failure to enter S0ix. The EC waits a
> > kernel-specified timeout (or a default amount of time) for the S0_SLP
> > pin to change, and wakes the system if that change does not occur in
> > time.
> >
> > Signed-off-by: Evan Green
> Reviewed-by: Rajat Jain
Acked-by: Enric Balletbo i Serra
>
> >
> > ---
> >
> > Changes in v3: None
> > Changes in v2:
> > - Made unions anonymous
> > - Replaced reserved union members with a comment
> >
> > include/linux/mfd/cros_ec_commands.h | 57
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/include/linux/mfd/cros_ec_commands.h
> > b/include/linux/mfd/cros_ec_commands.h
> > index fc91082d4c35..1cdb07c0ece1 100644
> > --- a/include/linux/mfd/cros_ec_commands.h
> > +++ b/include/linux/mfd/cros_ec_commands.h
> > @@ -2729,6 +2729,63 @@ struct ec_params_host_sleep_event {
> > uint8_t sleep_event;
> > } __packed;
> >
> > +/*
> > + * Use a default timeout value (CONFIG_SLEEP_TIMEOUT_MS) for detecting
> > sleep
> > + * transition failures
> > + */
> > +#define EC_HOST_SLEEP_TIMEOUT_DEFAULT 0
> > +
> > +/* Disable timeout detection for this sleep transition */
> > +#define EC_HOST_SLEEP_TIMEOUT_INFINITE 0x
> > +
> > +struct ec_params_host_sleep_event_v1 {
> > + /* The type of sleep being entered or exited. */
> > + uint8_t sleep_event;
> > +
> > + /* Padding */
> > + uint8_t reserved;
> > + union {
> > + /* Parameters that apply for suspend messages. */
> > + struct {
> > + /*
> > +* The timeout in milliseconds between when this
> > message
> > +* is received and when the EC will declare sleep
> > +* transition failure if the sleep signal is not
> > +* asserted.
> > +*/
> > + uint16_t sleep_timeout_ms;
> > + } suspend_params;
> > +
> > + /* No parameters for non-suspend messages. */
> > + };
> > +} __packed;
> > +
> > +/* A timeout occurred when this bit is set */
> > +#define EC_HOST_RESUME_SLEEP_TIMEOUT 0x8000
> > +
> > +/*
> > + * The mask defining which bits correspond to the number of sleep
> > transitions,
> > + * as well as the maximum number of suspend line transitions that will be
> > + * reported back to the host.
> > + */
> > +#define EC_HOST_RESUME_SLEEP_TRANSITIONS_MASK 0x7FFF
> > +
> > +struct ec_response_host_sleep_event_v1 {
> > + union {
> > + /* Response fields that apply for resume messages. */
> > + struct {
> > + /*
> > +* The number of sleep power signal transitions that
> > +* occurred since the suspend message. The high bit
> > +* indicates a timeout occurred.
> > +*/
> > + uint32_t sleep_transitions;
> > + } resume_response;
> > +
> > + /* No response fields for non-resume messages. */
> > + };
> > +} __packed;
> > +
> >
> > /*/
> > /* Smart battery pass-through */
> >
> > --
> > 2.20.1
> >
Re: [PATCH v7 6/7] platform/chrome: cros_ec: add EC host command support using rpmsg.
Hi
Thanks for sending this upstream, Some few comments and questions
below. Apart from these LGTM.
Missatge de Peter Shih del dia dc., 27 de març
2019 a les 6:17:
>
> From: Pi-Hsun Shih
>
> Add EC host command support through rpmsg.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> Changes from v6:
> - Make data for response aligned to 4 bytes.
>
> Changes from v5:
> - Change commit title.
> - Add documents for some structs, and fix all warning from
>scripts/kernel-doc.
> - Miscellaneous fixes based on feedback.
>
> Changes from v4:
> - Change from work queue to completion.
> - Change from matching using rpmsg id to device tree compatible, to
>support EC subdevices.
>
> Changes from v3:
> - Add host event support by adding an extra bytes at the start of IPC
>message to indicate the type of the message (host event or host
>command), since there's no additional irq that can be used for host
>event.
>
> Changes from v2:
> - Wait for ipi ack instead of depends on the behavior in mtk-rpmsg.
>
> Changes from v1:
> - Code format fix based on feedback for cros_ec_rpmsg.c.
> - Extract feature detection for SCP into separate patch (Patch 6).
> ---
> drivers/platform/chrome/Kconfig | 9 +
> drivers/platform/chrome/Makefile| 1 +
> drivers/platform/chrome/cros_ec_rpmsg.c | 265
> 3 files changed, 275 insertions(+)
> create mode 100644 drivers/platform/chrome/cros_ec_rpmsg.c
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index 9186d81a51cc..5c48aa6da2f8 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -59,6 +59,15 @@ config CROS_EC_I2C
> a checksum. Failing accesses will be retried three times to
> improve reliability.
>
> +config CROS_EC_RPMSG
> + tristate "ChromeOS Embedded Controller (rpmsg)"
> + depends on MFD_CROS_EC && RPMSG && OF
> + help
> + If you say Y here, you get support for talking to the ChromeOS EC
> + through rpmsg. This uses a simple byte-level protocol with a
> + checksum. Also since there's no addition EC-to-host interrupt, this
> + use a byte in message to distinguish host event from host command.
> +
> config CROS_EC_SPI
> tristate "ChromeOS Embedded Controller (SPI)"
> depends on MFD_CROS_EC && SPI
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index 1e2f0029b597..4b69d795720d 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> obj-$(CONFIG_CHROMEOS_TBMC)+= chromeos_tbmc.o
> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o
> +obj-$(CONFIG_CROS_EC_RPMSG)+= cros_ec_rpmsg.o
> obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o
> cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o
> cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
> diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
> b/drivers/platform/chrome/cros_ec_rpmsg.c
> new file mode 100644
> index ..2ecae806cfc5
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> @@ -0,0 +1,265 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright 2018 Google LLC.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define EC_MSG_TIMEOUT_MS 200
> +#define HOST_COMMAND_MARK 1
> +#define HOST_EVENT_MARK 2
> +
> +/**
> + * struct cros_ec_rpmsg_response - rpmsg message format from from EC.
> + *
> + * @type: The type of message, should be either HOST_COMMAND_MARK or
> + * HOST_EVENT_MARK, representing that the message is a response
> to
> + * host command, or a host event.
> + * @data: ec_host_response for host command.
> + */
> +struct cros_ec_rpmsg_response {
> + u8 type;
> + u8 data[] __aligned(4);
> +};
> +
> +/**
> + * struct cros_ec_rpmsg - information about a EC over rpmsg.
> + *
> + * @rpdev: rpmsg device we are connected to
> + * @xfer_ack: completion for host command transfer.
> + * @host_event_work: Work struct for pending host event.
> + */
> +struct cros_ec_rpmsg {
> + struct rpmsg_device *rpdev;
> + struct completion xfer_ack;
> + struct work_struct host_event_work;
> +};
> +
> +/**
> + * cros_ec_cmd_xfer_rpmsg - Transfer a message over rpmsg and receive the
> reply
> + *
> + * @ec_dev: ChromeOS EC device
> + * @ec_msg: Message to transfer
> + *
> + * This is only used for old EC proto version, and is not supported for this
> + * driver.
> + *
> + * Return: number of bytes of the reply on success or negative error code.
> + */
> +static int cros_ec_cmd_xfer_rpmsg(struct cros_ec_device *ec_dev,
> +
Re: [PATCH v7 7/7] cros_ec: differentiate SCP from EC by feature bit.
Hi,
Thanks for submitting this upstream. Some few comments below.
Please prepend the subsystem for the commit. I.e:
mfd: cros_ec: differentiate SCP from EC by feature bit.
Missatge de Peter Shih del dia dc., 27 de març
2019 a les 6:18:
>
> From: Pi-Hsun Shih
>
> Since a SCP and EC would both exist on a system, and use the cros_ec_dev
Could you also explain what an SCP is?
> driver, we need to differentiate between them for the userspace, or they
> would both be registered at /dev/cros_ec, causing a conflict.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> Changes from v6:
> - No change.
>
> Changes from v5:
> - No change.
>
> Changes from v4:
> - No change.
>
> Changes from v3:
> - No change.
>
> Changes from v2:
> - No change.
>
> Changes from v1:
> - New patch extracted from Patch 5.
> ---
> drivers/mfd/cros_ec_dev.c| 10 ++
> include/linux/mfd/cros_ec.h | 1 +
> include/linux/mfd/cros_ec_commands.h | 2 ++
> 3 files changed, 13 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index d275deaecb12..da2f2145d31d 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -418,6 +418,16 @@ static int ec_device_probe(struct platform_device *pdev)
> device_initialize(&ec->class_dev);
> cdev_init(&ec->cdev, &fops);
>
> + /* check whether this is actually a SCP rather than an EC */
Capitalize the phrase.
> + if (cros_ec_check_features(ec, EC_FEATURE_SCP)) {
> + dev_info(dev, "SCP detected.\n");
dev_info(dev, "CrOS SCP MCU detected.\n")
To be coherent with other messages like this that are already sent upstream.
> + /*
> +* Help userspace differentiating ECs from SCP,
> +* regardless of the probing order.
> +*/
> + ec_platform->ec_name = CROS_EC_DEV_SCP_NAME;
> + }
> +
> /*
> * Add the class device
> * Link to the character device for creating the /dev entry
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 8f2a8918bfa3..a971399bad82 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -24,6 +24,7 @@
>
> #define CROS_EC_DEV_NAME "cros_ec"
> #define CROS_EC_DEV_PD_NAME "cros_pd"
> +#define CROS_EC_DEV_SCP_NAME "cros_scp"
>
> /*
> * The EC is unresponsive for a time after a reboot command. Add a
> diff --git a/include/linux/mfd/cros_ec_commands.h
> b/include/linux/mfd/cros_ec_commands.h
> index fc91082d4c35..3e5da6e93b2f 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
Remove this change and base your work on top of [1]
> @@ -856,6 +856,8 @@ enum ec_feature_code {
> EC_FEATURE_RTC = 27,
> /* EC supports CEC commands */
> EC_FEATURE_CEC = 35,
> + /* The MCU exposes a SCP */
> + EC_FEATURE_SCP = 39,
> };
>
> #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
> --
> 2.21.0.392.gf8f6787159e-goog
>
Thanks,
Enric
[1] https://lkml.org/lkml/2019/2/27/723
