Re: [PATCH v2 1/2] platform/chrome: cros_ec: Add Type C hard reset

2021-04-20 Thread Enric Balletbo i Serra
Hi Prashant,

On 16/4/21 20:27, Prashant Malani wrote:
> 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
> 
> Change-Id: I52a36e725d945665814d4e59ddd1e76a3692db9f

Please remember to remove the ChromeOS specific tags and add properly the 
Signed-off

Thanks,
 Enric

> ---
> v2 is the first version the patch was introduced.
> 
>  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 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_DONEBIT(0)
>  #define PD_STATUS_EVENT_SOP_PRIME_DISC_DONE  BIT(1)
> +#define PD_STATUS_EVENT_HARD_RESET   BIT(2)
>  
>  struct ec_params_typec_status {
>   uint8_t port;
> 


Re: [PATCH 3/3] arm64: dts: mt8183-kukui: fix dtbs_check warnings

2021-04-15 Thread Enric Balletbo i Serra
Hi Matthias,

On 15/4/21 9:47, Matthias Brugger wrote:
> Hi Nicolas,
> 
> On 15/04/2021 02:29, Nicolas Boichat wrote:
>> On Wed, Apr 14, 2021 at 10:46 PM  wrote:
>>>
>>> From: Matthias Brugger 
>>>
>>> The dsi children don't have any reg property,
>>
>> Confused, see below.
>>
>>> so we don't need address and
>>> size cells. This makes dtbs_check happy.
>>>
>>> CC: Hsin-Yi Wang 
>>> CC: Enric Balletbo i Serra 
>>> CC: Nicolas Boichat 
>>> Signed-off-by: Matthias Brugger 
>>>
>>> ---
>>>
>>>  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
>>> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> index ff56bcfa3370..f4dca6a33168 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>>> @@ -251,8 +251,7 @@  {
>>>
>>>   {
>>> status = "okay";
>>> -   #address-cells = <1>;
>>> -   #size-cells = <0>;
>>> +
>>> panel: panel@0 {
>>> /* compatible will be set in board dts */
>>> reg = <0>;
>>
>> ^^ isn't that... a reg property?
>>
> 
> Yes, that's my fault. I'm not quite sure why we would need this reg property. 
> In
> any case also we have it present "dtbs_check W=1" throws the following 
> warning:
> mediatek/mt8183.dtsi:1234.22-1246.5: Warning (avoid_unnecessary_addr_size):
> /soc/dsi@14014000: unnecessary #address-cells/#size-cells without "ranges" or
> child "reg" property
> 
> 
> Can you have a look at that?
> 

I think it is needed reg. See at
Documentation/devicetree/bindings/display/dsi-controller.yaml

Regards,
Enric

> Regards,
> Matthias
> 
>>> --
>>> 2.30.2
>>>


[RESEND PATCH 2/2] arm64: defconfig: Enable options to support panel display for Mediatek Chromebooks

2021-03-31 Thread Enric Balletbo i Serra
There are some Mediatek based Chromebooks supported in the kernel. Enable the
required config options to have the panel display working on both devices.
This was tested on the ACER Chromebook R13 (MT8173) and the Lenovo
Ideapad Duet (MT8183), but should also enable display support for similar
devices.

Signed-off-by: Enric Balletbo i Serra 
---
This is only a resend rebased on top of mainline to fix some trivial
conflicts.

 arch/arm64/configs/defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7b4be3807b6d..f2dc42c9b932 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -686,6 +686,7 @@ CONFIG_DRM_MSM=m
 CONFIG_DRM_TEGRA=m
 CONFIG_DRM_PANEL_LVDS=m
 CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
 CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m
 CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
 CONFIG_DRM_PANEL_SITRONIX_ST7703=m
@@ -693,6 +694,7 @@ CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m
 CONFIG_DRM_DISPLAY_CONNECTOR=m
 CONFIG_DRM_NWL_MIPI_DSI=m
 CONFIG_DRM_LONTIUM_LT9611=m
+CONFIG_DRM_PARADE_PS8640=m
 CONFIG_DRM_SII902X=m
 CONFIG_DRM_SIMPLE_BRIDGE=m
 CONFIG_DRM_THINE_THC63LVD1024=m
@@ -707,6 +709,8 @@ CONFIG_DRM_VC4=m
 CONFIG_DRM_ETNAVIV=m
 CONFIG_DRM_HISI_HIBMC=m
 CONFIG_DRM_HISI_KIRIN=m
+CONFIG_DRM_MEDIATEK=m
+CONFIG_DRM_MEDIATEK_HDMI=m
 CONFIG_DRM_MXSFB=m
 CONFIG_DRM_MESON=m
 CONFIG_DRM_PL111=m
@@ -979,6 +983,7 @@ CONFIG_ROCKCHIP_IOMMU=y
 CONFIG_TEGRA_IOMMU_SMMU=y
 CONFIG_ARM_SMMU=y
 CONFIG_ARM_SMMU_V3=y
+CONFIG_MTK_IOMMU=y
 CONFIG_QCOM_IOMMU=y
 CONFIG_REMOTEPROC=y
 CONFIG_QCOM_Q6V5_MSS=m
@@ -1051,6 +1056,8 @@ CONFIG_PWM_BCM2835=m
 CONFIG_PWM_CROS_EC=m
 CONFIG_PWM_IMX27=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_MTK_DISP=m
+CONFIG_PWM_MEDIATEK=m
 CONFIG_PWM_RCAR=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
@@ -1095,6 +1102,7 @@ CONFIG_QCOM_L3_PMU=y
 CONFIG_NVMEM_IMX_OCOTP=y
 CONFIG_NVMEM_IMX_OCOTP_SCU=y
 CONFIG_QCOM_QFPROM=y
+CONFIG_MTK_EFUSE=y
 CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_UNIPHIER_EFUSE=y
-- 
2.30.2



[RESEND PATCH 1/2] arm64: defconfig: Allow mt8173-based boards to boot from usb

2021-03-31 Thread Enric Balletbo i Serra
Enable the option necessary to boot mt8173-based boards to boot from
usb devices, like its phy and the regulators needed to have proper
support.

Signed-off-by: Enric Balletbo i Serra 
---
This is only a resend rebased on top of mainline to fix some trivial
conflicts.

 arch/arm64/configs/defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d612f633b771..7b4be3807b6d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -448,6 +448,7 @@ CONFIG_I2C_GPIO=m
 CONFIG_I2C_IMX=y
 CONFIG_I2C_IMX_LPI2C=y
 CONFIG_I2C_MESON=y
+CONFIG_I2C_MT65XX=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_OMAP=y
 CONFIG_I2C_OWL=y
@@ -594,6 +595,7 @@ CONFIG_MFD_EXYNOS_LPASS=m
 CONFIG_MFD_HI6421_PMIC=y
 CONFIG_MFD_HI655X_PMIC=y
 CONFIG_MFD_MAX77620=y
+CONFIG_MFD_MT6397=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
@@ -611,6 +613,8 @@ CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_MAX77620=y
 CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MP8859=y
+CONFIG_REGULATOR_MT6358=y
+CONFIG_REGULATOR_MT6397=y
 CONFIG_REGULATOR_PCA9450=y
 CONFIG_REGULATOR_PF8X00=y
 CONFIG_REGULATOR_PFUZE100=y
@@ -787,6 +791,7 @@ CONFIG_USB_RENESAS_USBHS_HCD=m
 CONFIG_USB_RENESAS_USBHS=m
 CONFIG_USB_ACM=m
 CONFIG_USB_STORAGE=y
+CONFIG_USB_MTU3=y
 CONFIG_USB_MUSB_HDRC=y
 CONFIG_USB_MUSB_SUNXI=y
 CONFIG_USB_DWC3=y
@@ -988,6 +993,7 @@ CONFIG_OWL_PM_DOMAINS=y
 CONFIG_RASPBERRYPI_POWER=y
 CONFIG_FSL_DPAA=y
 CONFIG_FSL_MC_DPIO=y
+CONFIG_MTK_PMIC_WRAP=y
 CONFIG_QCOM_AOSS_QMP=y
 CONFIG_QCOM_COMMAND_DB=y
 CONFIG_QCOM_GENI_SE=y
@@ -1064,6 +1070,7 @@ CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_HISTB_COMBPHY=y
 CONFIG_PHY_HISI_INNO_USB2=y
 CONFIG_PHY_MVEBU_CP110_COMPHY=y
+CONFIG_PHY_MTK_TPHY=y
 CONFIG_PHY_QCOM_QMP=m
 CONFIG_PHY_QCOM_QUSB2=m
 CONFIG_PHY_QCOM_USB_HS=y
-- 
2.30.2



Re: [PATCH] platform/chrome: cros_ec_typec: fix clang -Wformat warning

2021-03-31 Thread Enric Balletbo i Serra
On Mon, 22 Mar 2021 12:55:55 +0100, Arnd Bergmann wrote:
> Clang warns about using the %h format modifier to truncate an
> integer:
> 
> drivers/platform/chrome/cros_ec_typec.c:1031:3: error: format specifies type 
> 'unsigned char' but the argument has type 'unsigned int' [-Werror,-Wformat]
> typec->pd_ctrl_ver);
> ^~
> include/linux/dev_printk.h:131:47: note: expanded from macro 'dev_dbg'
> dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
> ~~~ ^~~
> 
> [...]

Applied, thanks!

[1/1] platform/chrome: cros_ec_typec: fix clang -Wformat warning
  commit: c6e939c63c80c26460b25cf1150ebe8396e8adcf

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH] platform/chrome: wilco_ec: convert stream-like files from nonseekable_open -> stream_open

2021-03-31 Thread Enric Balletbo i Serra
On Sun, 7 Feb 2021 17:08:38 +0800, Yang Li wrote:
> Eliminate the following coccicheck warning:
> ./drivers/platform/chrome/wilco_ec/telemetry.c:259:1-17: WARNING:
> telem_fops: .read() and .write() have stream semantic; safe to change
> nonseekable_open -> stream_open.

Applied, thanks!

[1/1] platform/chrome: wilco_ec: convert stream-like files from 
nonseekable_open -> stream_open
  commit: dbc334fb411f2e87ca0e812dc7ba13464aa89504

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH] platform/chrome: cros_ec_typec: Check for device within remove function

2021-03-31 Thread Enric Balletbo i Serra
On Thu, 18 Mar 2021 18:51:03 -0700, Prashant Malani wrote:
> In a couple of call sites, we use the same pattern of checking for a
> partner or cable device before attempting to remove it. Simplify this by
> moving those checks into the remove functions.

Applied, thanks!

[1/1] platform/chrome: cros_ec_typec: Check for device within remove function
  commit: 639ff208cb37c5a3f0198e62d04962b677d25c9c

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH 10/12] platform/chrome: chromeos_laptop - Prepare complete software nodes

2021-03-30 Thread Enric Balletbo i Serra
Hi Heikki,

Thank you for your patch.

On 29/3/21 12:50, Heikki Krogerus wrote:
> The older device property API is going to be removed soon
> and that will affect also I2C subystem. Supplying complete
> software nodes instead of only the properties in them for
> the I2C devices.
> 
> Signed-off-by: Heikki Krogerus 
> Cc: Benson Leung 
> Cc: Enric Balletbo i Serra 

Acked-by: Enric Balletbo i Serra 

> ---
>  drivers/platform/chrome/chromeos_laptop.c | 100 +-
>  1 file changed, 60 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/platform/chrome/chromeos_laptop.c 
> b/drivers/platform/chrome/chromeos_laptop.c
> index 472a03daa8693..4e14b4d6635d7 100644
> --- a/drivers/platform/chrome/chromeos_laptop.c
> +++ b/drivers/platform/chrome/chromeos_laptop.c
> @@ -52,12 +52,15 @@ struct i2c_peripheral {
>   enum i2c_adapter_type type;
>   u32 pci_devid;
>  
> + const struct property_entry *properties;
> +
>   struct i2c_client *client;
>  };
>  
>  struct acpi_peripheral {
>   char hid[ACPI_ID_LEN];
> - const struct property_entry *properties;
> + struct software_node swnode;
> + struct i2c_client *client;
>  };
>  
>  struct chromeos_laptop {
> @@ -68,7 +71,7 @@ struct chromeos_laptop {
>   struct i2c_peripheral *i2c_peripherals;
>   unsigned int num_i2c_peripherals;
>  
> - const struct acpi_peripheral *acpi_peripherals;
> + struct acpi_peripheral *acpi_peripherals;
>   unsigned int num_acpi_peripherals;
>  };
>  
> @@ -161,7 +164,7 @@ static void chromeos_laptop_check_adapter(struct 
> i2c_adapter *adapter)
>  
>  static bool chromeos_laptop_adjust_client(struct i2c_client *client)
>  {
> - const struct acpi_peripheral *acpi_dev;
> + struct acpi_peripheral *acpi_dev;
>   struct acpi_device_id acpi_ids[2] = { };
>   int i;
>   int error;
> @@ -175,8 +178,7 @@ static bool chromeos_laptop_adjust_client(struct 
> i2c_client *client)
>   memcpy(acpi_ids[0].id, acpi_dev->hid, ACPI_ID_LEN);
>  
>   if (acpi_match_device(acpi_ids, >dev)) {
> - error = device_add_properties(>dev,
> -   acpi_dev->properties);
> + error = device_add_software_node(>dev, 
> _dev->swnode);
>   if (error) {
>   dev_err(>dev,
>   "failed to add properties: %d\n",
> @@ -184,6 +186,8 @@ static bool chromeos_laptop_adjust_client(struct 
> i2c_client *client)
>   break;
>   }
>  
> + acpi_dev->client = client;
> +
>   return true;
>   }
>   }
> @@ -193,15 +197,28 @@ static bool chromeos_laptop_adjust_client(struct 
> i2c_client *client)
>  
>  static void chromeos_laptop_detach_i2c_client(struct i2c_client *client)
>  {
> + struct acpi_peripheral *acpi_dev;
>   struct i2c_peripheral *i2c_dev;
>   int i;
>  
> - for (i = 0; i < cros_laptop->num_i2c_peripherals; i++) {
> - i2c_dev = _laptop->i2c_peripherals[i];
> + if (has_acpi_companion(>dev))
> + for (i = 0; i < cros_laptop->num_acpi_peripherals; i++) {
> + acpi_dev = _laptop->acpi_peripherals[i];
>  
> - if (i2c_dev->client == client)
> - i2c_dev->client = NULL;
> - }
> + if (acpi_dev->client == client) {
> + acpi_dev->client = NULL;
> + return;
> + }
> + }
> + else
> + for (i = 0; i < cros_laptop->num_i2c_peripherals; i++) {
> + i2c_dev = _laptop->i2c_peripherals[i];
> +
> + if (i2c_dev->client == client) {
> + i2c_dev->client = NULL;
> + return;
> + }
> + }
>  }
>  
>  static int chromeos_laptop_i2c_notifier_call(struct notifier_block *nb,
> @@ -302,28 +319,26 @@ static struct i2c_peripheral 
> chromebook_pixel_peripherals[] __initdata = {
>   .board_info = {
>   I2C_BOARD_INFO("atmel_mxt_ts",
>   ATMEL_TS_I2C_ADDR),
> - .properties =
> - chromebook_atmel_touchscreen_props,
>   .flags  = I2C_CLIENT_WAKE,
>   },
>   .dmi_name

Re: [PATCH] drm/mediatek: Add missing MODULE_DEVICE_TABLE()

2021-03-30 Thread Enric Balletbo i Serra
Hi,

On 3/2/21 12:07, Enric Balletbo i Serra wrote:
> From: Boris Brezillon 
> 
> This patch adds the missing MODULE_DEVICE_TABLE definitions on different
> Mediatek drivers which generates correct modalias for automatic loading
> when these drivers are compiled as an external module.
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Enric Balletbo i Serra 

A gentle ping for someone to review this patchset :-)

Thanks,
  Enric

> ---
> 
>  drivers/gpu/drm/mediatek/mtk_cec.c  | 2 ++
>  drivers/gpu/drm/mediatek/mtk_dpi.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 1 +
>  drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
>  drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 1 +
>  6 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
> b/drivers/gpu/drm/mediatek/mtk_cec.c
> index cb29b649fcdb..3b86e626e459 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -7,6 +7,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -247,6 +248,7 @@ static const struct of_device_id mtk_cec_of_ids[] = {
>   { .compatible = "mediatek,mt8173-cec", },
>   {}
>  };
> +MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
>  
>  struct platform_driver mtk_cec_driver = {
>   .probe = mtk_cec_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 52f11a63a330..2680370652fd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -822,6 +822,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
>   },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
>  
>  struct platform_driver mtk_dpi_driver = {
>   .probe = mtk_dpi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 5f49a809689b..e4645c8ae1c0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -470,6 +470,7 @@ static const struct of_device_id mtk_drm_of_ids[] = {
> .data = _mmsys_driver_data},
>   { }
>  };
> +MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
>  
>  static int mtk_drm_probe(struct platform_device *pdev)
>  {
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0527480c07be..c71ce62d1bec 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1193,6 +1193,7 @@ static const struct of_device_id mtk_dsi_of_match[] = {
> .data = _dsi_driver_data },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
>  
>  struct platform_driver mtk_dsi_driver = {
>   .probe = mtk_dsi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 8ee55f9e2954..b4696a9d73f7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1818,6 +1818,7 @@ static const struct of_device_id mtk_drm_hdmi_of_ids[] 
> = {
>   },
>   {}
>  };
> +MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
>  
>  static struct platform_driver mtk_hdmi_driver = {
>   .probe = mtk_drm_hdmi_probe,
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c 
> b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> index 62dbad5675bb..6207eac88550 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
> @@ -335,6 +335,7 @@ static const struct of_device_id mtk_hdmi_ddc_match[] = {
>   { .compatible = "mediatek,mt8173-hdmi-ddc", },
>   {},
>  };
> +MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
>  
>  struct platform_driver mtk_hdmi_ddc_driver = {
>   .probe = mtk_hdmi_ddc_probe,
> 


Re: [PATCH] soc: mediatek: mmsys: Add mt8183 mmsys routing table

2021-03-30 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for your patch.

On 23/3/21 6:51, Hsin-Yi Wang wrote:
> mt8183 has different routing registers than mt8173.
> 
> Signed-off-by: Hsin-Yi Wang 

I applied the patches on top of the mmsys routing patches and I have display
working on my Lenovo IdeaPad Duet. So

Tested-by: Enric Balletbo i Serra 

> ---
> This patch is based on series ("soc: mediatek: Prepare MMSYS for DDP routing 
> using tables")[1]
> and tested with mt8183 krand and mt8183 juniper device.
> The register value is referenced from [2].
> 
> [1] 
> https://patchwork.kernel.org/project/linux-mediatek/cover/20210317181711.795245-1-enric.balle...@collabora.com/
> [2] 
> https://patchwork.kernel.org/project/linux-mediatek/patch/1609815993-22744-6-git-send-email-yongqiang@mediatek.com/
> ---
>  drivers/soc/mediatek/mtk-mmsys.c |  2 ++
>  drivers/soc/mediatek/mtk-mmsys.h | 47 
>  2 files changed, 49 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c 
> b/drivers/soc/mediatek/mtk-mmsys.c
> index c46d8ab8b0c2..16bb55b0463a 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -40,6 +40,8 @@ static const struct mtk_mmsys_driver_data 
> mt8173_mmsys_driver_data = {
>  
>  static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
>   .clk_driver = "clk-mt8183-mm",
> + .routes = mmsys_mt8183_routing_table,
> + .num_routes = ARRAY_SIZE(mmsys_mt8183_routing_table),
>  };
>  
>  struct mtk_mmsys {
> diff --git a/drivers/soc/mediatek/mtk-mmsys.h 
> b/drivers/soc/mediatek/mtk-mmsys.h
> index a760a34e6eca..c55baf5932b8 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.h
> +++ b/drivers/soc/mediatek/mtk-mmsys.h
> @@ -66,6 +66,28 @@
>  #define DPI_SEL_IN_BLS   0x0
>  #define DSI_SEL_IN_RDMA  0x1
>  
> +#define MT8183_DISP_OVL0_MOUT_EN 0xf00
> +#define MT8183_DISP_OVL0_2L_MOUT_EN  0xf04
> +#define MT8183_DISP_OVL1_2L_MOUT_EN  0xf08
> +#define MT8183_DISP_DITHER0_MOUT_EN  0xf0c
> +#define MT8183_DISP_PATH0_SEL_IN 0xf24
> +#define MT8183_DISP_DSI0_SEL_IN  0xf2c
> +#define MT8183_DISP_DPI0_SEL_IN  0xf30
> +#define MT8183_DISP_RDMA0_SOUT_SEL_IN0xf50
> +#define MT8183_DISP_RDMA1_SOUT_SEL_IN0xf54
> +
> +#define MT8183_OVL0_MOUT_EN_OVL0_2L  BIT(4)
> +#define MT8183_OVL0_2L_MOUT_EN_DISP_PATH0BIT(0)
> +#define MT8183_OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> +#define MT8183_DITHER0_MOUT_IN_DSI0  BIT(0)
> +#define MT8183_DISP_PATH0_SEL_IN_OVL0_2L 0x1
> +#define MT8183_DSI0_SEL_IN_RDMA0 0x1
> +#define MT8183_DSI0_SEL_IN_RDMA1 0x3
> +#define MT8183_DPI0_SEL_IN_RDMA0 0x1
> +#define MT8183_DPI0_SEL_IN_RDMA1 0x2
> +#define MT8183_RDMA0_SOUT_COLOR0 0x1
> +#define MT8183_RDMA1_SOUT_DSI0   0x1
> +
>  struct mtk_mmsys_routes {
>   u32 from_comp;
>   u32 to_comp;
> @@ -212,4 +234,29 @@ static const struct mtk_mmsys_routes 
> mmsys_default_routing_table[] = {
>   }
>  };
>  
> +static const struct mtk_mmsys_routes mmsys_mt8183_routing_table[] = {
> + {
> + DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> + MT8183_DISP_OVL0_MOUT_EN, MT8183_OVL0_MOUT_EN_OVL0_2L
> + }, {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + MT8183_DISP_OVL0_2L_MOUT_EN, MT8183_OVL0_2L_MOUT_EN_DISP_PATH0
> + }, {
> + DDP_COMPONENT_OVL_2L1, DDP_COMPONENT_RDMA1,
> + MT8183_DISP_OVL1_2L_MOUT_EN, MT8183_OVL1_2L_MOUT_EN_RDMA1
> + }, {
> + DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> + MT8183_DISP_DITHER0_MOUT_EN, MT8183_DITHER0_MOUT_IN_DSI0
> + }, {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + MT8183_DISP_PATH0_SEL_IN, MT8183_DISP_PATH0_SEL_IN_OVL0_2L
> + }, {
> + DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
> + MT8183_DISP_DPI0_SEL_IN, MT8183_DPI0_SEL_IN_RDMA1
> + }, {
> + DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> + MT8183_DISP_RDMA0_SOUT_SEL_IN, MT8183_RDMA0_SOUT_COLOR0
> + }
> +};
> +
>  #endif /* __SOC_MEDIATEK_MTK_MMSYS_H */
> 


Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema

2021-03-24 Thread 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

Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema

2021-03-24 Thread Enric Balletbo i Serra
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-

Re: [PATCH v4 2/4] dt-bindings: power: rockchip: Convert to json-schema

2021-03-24 Thread 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]+$":


> +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:
> +maxItems: 1
> +description: |
> +  Power domain index. Valid values are defined in
> +  "include/dt-bindings/power/px30-power.h"
> +  "include/dt-bindings/power/rk3036-power.h"
> +  "include/dt-bindings/power/rk3066-power.h"
> +  "include/dt-bindings/power/rk3128-power.h"
> +  "include/dt-bindings/power/rk3188-power.h"
> +  "include/dt-bindings/power/rk3228-power.h"
> +  "include/dt-bindings/power/rk3288-power.h"
> +  "include

Re: [PATCH v4 2/4] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-juniper

2021-03-19 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for your patch.

On 19/3/21 4:52, Hsin-Yi Wang wrote:
> mt8183-kukui-jacuzzi-juniper board also known as Acer Chromebook Spin 311,
> using mediatek mt8183 SoC.
> 
> Signed-off-by: Hsin-Yi Wang 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml 
> b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index a86716cdd408..edee2c3f8620 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -129,6 +129,11 @@ properties:
>  items:
>- const: google,damu
>- const: mediatek,mt8183
> +  - description: Google Juniper (Acer Chromebook Spin 311)
> +items:
> +  - const: google,juniper-sku16
> +  - const: google,juniper
> +  - const: mediatek,mt8183
>  
>  additionalProperties: true
>  
> 


Re: [PATCH] arm64: dts: mt8173: fix wrong power-domain phandle of pmic

2021-03-18 Thread Enric Balletbo i Serra
Hi Chunfeng Yun,

Thank you for the patch.

On 18/3/21 7:18, Chunfeng Yun wrote:
> Due to power domain controller is added, the power domain's
> phanle is also changed from 'scpsys' to 'spm', but forget to
> modify pmic node's
> 
> Fixes: 8b6562644df9 ("arm64: dts: mediatek: Add mt8173 power domain 
> controller")
> Signed-off-by: Chunfeng Yun 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 6dffada2e66b..28aa634c9780 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -294,7 +294,7 @@
>  
>   {
>   /* Only MT8173 E1 needs USB power domain */
> - power-domains = < MT8173_POWER_DOMAIN_USB>;
> + power-domains = < MT8173_POWER_DOMAIN_USB>;
>  
>   pmic: mt6397 {
>   compatible = "mediatek,mt6397";
> 


[PATCH v2 2/2] soc: mediatek: mmsys: Use an array for setting the routing registers

2021-03-17 Thread Enric Balletbo i Serra
From: CK Hu 

Actually, setting the registers for routing, use multiple 'if-else' for 
different
routes, but this code would be more and more complicated while we
support more and more SoCs. Change that and use a table per SoC so the
code will be more portable and clear.

Signed-off-by: CK Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Use a default table for mt2701, mt2712 and mt8173.
- Remove the mask field from routes struct as is not needed.

 drivers/soc/mediatek/mtk-mmsys.c | 273 +++
 drivers/soc/mediatek/mtk-mmsys.h | 215 
 2 files changed, 240 insertions(+), 248 deletions(-)
 create mode 100644 drivers/soc/mediatek/mtk-mmsys.h

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index da2de8f6969e..c46d8ab8b0c2 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -10,79 +10,18 @@
 #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 << 16)
-#define DSI3_SEL_IN_RDMA2  (0x4 << 16)
-#define COLOR1_SEL_IN_OVL1 0x1
-
-#define OVL_MOUT_EN_RDMA   0x1
-#define BLS_TO_DSI_RDMA1_TO_DPI1   0x8
-#define BLS_TO_DPI_RDMA1_TO_DSI0x2
-#define DSI_SEL_IN_BLS 0x0
-#define DPI_SEL_IN_BLS 0x0
-#define DSI_SEL_IN_RDMA0x1
-
-struct mtk_mmsys_driver_data {
-   const char *clk_driver;
-};
+#include "mtk-mmsys.h"
 
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.clk_driver = "clk-mt2701-mm",
+   .routes = mmsys_default_routing_table,
+   .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
 };
 
 static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
.clk_driver = "clk-mt2712-mm",
+   .routes = mmsys_default_routing_table,
+   .num_routes = ARRAY_SIZE(mmsys_default_routing_table),
 };
 
 static const struct mtk_mmsys_driver_data mt6779_mmsys_driver_da

[PATCH v2 0/2] soc: mediatek: Prepare MMSYS for DDP routing using tables

2021-03-17 Thread Enric Balletbo i Serra
Dear all,

This is the second version of this series intended to prepare the
mtk-mmsys driver to allow different DDP (Data Display Path) routing
tables per SoC. Note that the series has been tested only on MT8173 platform,
for MT2701 and MT2712 based devices we're using a default routing table
that should just work.

Thanks,
  Enric

Changes in v2:
- Use a default table for mt2701, mt2712 and mt8173.
- Remove the mask field from routes struct as is not needed.

CK Hu (2):
  soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
  soc: mediatek: mmsys: Use an array for setting the routing registers

 drivers/soc/mediatek/mtk-mmsys.c | 300 +--
 drivers/soc/mediatek/mtk-mmsys.h | 215 ++
 2 files changed, 257 insertions(+), 258 deletions(-)
 create mode 100644 drivers/soc/mediatek/mtk-mmsys.h

-- 
2.30.2



[PATCH v2 1/2] soc: mediatek: mmsys: Create struct mtk_mmsys to store context data

2021-03-17 Thread Enric Balletbo i Serra
From: CK Hu 

Apart from the driver data, in order to extend the driver to support more
and more SoCs, we will need to store other configuration data. So, create
a mtk_mmsys struct to encapsulate all that information.

Signed-off-by: CK Hu 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Chun-Kuang Hu 
---

Changes in v2: None

 drivers/soc/mediatek/mtk-mmsys.c | 47 ++--
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 18f93979e14a..da2de8f6969e 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -101,6 +101,11 @@ static const struct mtk_mmsys_driver_data 
mt8183_mmsys_driver_data = {
.clk_driver = "clk-mt8183-mm",
 };
 
+struct mtk_mmsys {
+   void __iomem *regs;
+   const struct mtk_mmsys_driver_data *data;
+};
+
 static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next,
  unsigned int *addr)
@@ -259,21 +264,21 @@ void mtk_mmsys_ddp_connect(struct device *dev,
   enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next)
 {
-   void __iomem *config_regs = dev_get_drvdata(dev);
+   struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
unsigned int addr, value, reg;
 
value = mtk_mmsys_ddp_mout_en(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
+   reg = readl_relaxed(mmsys->regs + addr) | value;
+   writel_relaxed(reg, mmsys->regs + addr);
}
 
-   mtk_mmsys_ddp_sout_sel(config_regs, cur, next);
+   mtk_mmsys_ddp_sout_sel(mmsys->regs, cur, next);
 
value = mtk_mmsys_ddp_sel_in(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
+   reg = readl_relaxed(mmsys->regs + addr) | value;
+   writel_relaxed(reg, mmsys->regs + addr);
}
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_connect);
@@ -282,44 +287,46 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
 {
-   void __iomem *config_regs = dev_get_drvdata(dev);
+   struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
unsigned int addr, value, reg;
 
value = mtk_mmsys_ddp_mout_en(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
+   reg = readl_relaxed(mmsys->regs + addr) & ~value;
+   writel_relaxed(reg, mmsys->regs + addr);
}
 
value = mtk_mmsys_ddp_sel_in(cur, next, );
if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
+   reg = readl_relaxed(mmsys->regs + addr) & ~value;
+   writel_relaxed(reg, mmsys->regs + addr);
}
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
 
 static int mtk_mmsys_probe(struct platform_device *pdev)
 {
-   const struct mtk_mmsys_driver_data *data;
struct device *dev = >dev;
struct platform_device *clks;
struct platform_device *drm;
-   void __iomem *config_regs;
+   struct mtk_mmsys *mmsys;
int ret;
 
-   config_regs = devm_platform_ioremap_resource(pdev, 0);
-   if (IS_ERR(config_regs)) {
-   ret = PTR_ERR(config_regs);
+   mmsys = devm_kzalloc(dev, sizeof(*mmsys), GFP_KERNEL);
+   if (!mmsys)
+   return -ENOMEM;
+
+   mmsys->regs = devm_platform_ioremap_resource(pdev, 0);
+   if (IS_ERR(mmsys->regs)) {
+   ret = PTR_ERR(mmsys->regs);
dev_err(dev, "Failed to ioremap mmsys registers: %d\n", ret);
return ret;
}
 
-   platform_set_drvdata(pdev, config_regs);
-
-   data = of_device_get_match_data(>dev);
+   mmsys->data = of_device_get_match_data(>dev);
+   platform_set_drvdata(pdev, mmsys);
 
-   clks = platform_device_register_data(>dev, data->clk_driver,
+   clks = platform_device_register_data(>dev, 
mmsys->data->clk_driver,
 PLATFORM_DEVID_AUTO, NULL, 0);
if (IS_ERR(clks))
return PTR_ERR(clks);
-- 
2.30.2



Re: [PATCH v2 2/2] arm64: dts: mt8183: Add kukui-jacuzzi-damu board

2021-03-17 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for the patch.

On 15/3/21 12:41, Hsin-Yi Wang wrote:
> Damu is known as ASUS Chromebook Flip CM3.
> 
> Signed-off-by: Hsin-Yi Wang 
> ---
> v1->v2: fix pp3300_panel regulator property
> ---
>  arch/arm64/boot/dts/mediatek/Makefile |   1 +
>  .../mediatek/mt8183-kukui-jacuzzi-damu.dts|  35 ++
>  .../dts/mediatek/mt8183-kukui-jacuzzi.dtsi| 482 ++
>  3 files changed, 518 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
> b/arch/arm64/boot/dts/mediatek/Makefile
> index deba27ab7657..554105d2c389 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-damu.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku0.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
> new file mode 100644
> index ..d697336440d1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi-damu.dts
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-jacuzzi.dtsi"
> +
> +/ {
> + model = "Google damu board";
> + compatible = "google,damu", "mediatek,mt8183";
> +};
> +
> +_thermal {
> + sustainable-power = <4500>; /* milliwatts */
> +};

This node is not upstream for MT8183, so fails to build, you should remove this.

> +
> + {
> + status = "okay";
> +
> + compatible = "hid-over-i2c";
> + reg = <0x10>;
> + interrupt-parent = <>;
> + interrupts = <155 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + post-power-on-delay-ms = <10>;
> + hid-descr-addr = <0x0001>;
> +};
> +
> +_wifi {
> + qcom,ath10k-calibration-variant = "GO_DAMU";
> +};
> +
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> new file mode 100644
> index ..d8826c82bcda
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi
> @@ -0,0 +1,482 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2021 Google LLC
> + */
> +
> +#include "mt8183-kukui.dtsi"
> +
> +/ {
> + panel: panel {
> + compatible = "auo,b116xw03";
> + power-supply = <_panel>;
> + ddc-i2c-bus = <>;
> + backlight = <_lcd0>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + pp1200_mipibrdg: pp1200-mipibrdg {
> + compatible = "regulator-fixed";
> + regulator-name = "pp1200_mipibrdg";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mipibrdg_en>;
> +
> + enable-active-high;
> + regulator-boot-on;
> +
> + gpio = < 54 GPIO_ACTIVE_HIGH>;
> + };
> +
> + pp1800_mipibrdg: pp1800-mipibrdg {
> + compatible = "regulator-fixed";
> + regulator-name = "pp1800_mipibrdg";
> + pinctrl-names = "default";
> + pinctrl-0 = <_lcd_en>;
> +
> + enable-active-high;
> + regulator-boot-on;
> +
> + gpio = < 36 GPIO_ACTIVE_HIGH>;
> + };
> +
> + pp3300_panel: pp3300-panel {
> + compatible = "regulator-fixed";
> + regulator-name = "pp3300_panel";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_panel_pins>;
> +
> + enable-active-high;
> + regulator-boot-on;
> +
> + gpio = < 35 GPIO_ACTIVE_HIGH>;
> + };
> +
> + vddio_mipibrdg: vddio-mipibrdg {
> + compatible = "regulator-fixed";
> + regulator-name = "vddio_mipibrdg";
> + pinctrl-names = "default";
> + pinctrl-0 = <_mipibrdg_en>;
> +
> + enable-active-high;
> + regulator-boot-on;
> +
> + gpio = < 37 GPIO_ACTIVE_HIGH>;
> + };
> +
> + volume_buttons: volume-buttons {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_button_pins>;
> +
> + volume_down {
> +

Re: [PATCH v2 1/2] dt-bindings: arm64: dts: mediatek: Add mt8183-kukui-jacuzzi-damu

2021-03-17 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for the patch.

On 15/3/21 12:41, Hsin-Yi Wang wrote:
> mt8183-kukui-jacuzzi-damu board also known as ASUS Chromebook Flip CM3,
> using mediatek mt8183 SoC.
> 
> 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 93b3bdf6eaeb..a86716cdd408 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -125,6 +125,10 @@ properties:
>- google,krane-sku176
>- const: google,krane
>- const: mediatek,mt8183
> +  - description: Google Damu (ASUS Chromebook Flip CM3)
> +items:
> +  - const: google,damu
> +  - const: mediatek,mt8183
>  
>  additionalProperties: true
>  
> 


Re: [PATCH 04/23] ASoC: cros_ec_codec: remove null pointer dereference warning

2021-03-15 Thread Enric Balletbo i Serra
Hi Pierre-Louis,

Thank you for you patch.

On 12/3/21 19:22, Pierre-Louis Bossart wrote:
> Cppcheck complains of a possible issue:
> 
> sound/soc/codecs/cros_ec_codec.c:98:10: warning: Possible null pointer
> dereference: in [nullPointer]
>   memcpy(in, msg->data, insize);
>  ^
> sound/soc/codecs/cros_ec_codec.c:162:34: note: Calling function
> 'send_ec_host_command', 5th argument 'NULL' value is 0
>(uint8_t *), sizeof(p), NULL, 0);
>  ^
> sound/soc/codecs/cros_ec_codec.c:98:10: note: Null pointer dereference
>   memcpy(in, msg->data, insize);
>  ^
> 
> In practice the access to the pointer is protected by another
> argument, but this is likely to fool other static analysis tools. Add
> a test to avoid doing the memcpy if the pointer is NULL or the size is
> zero.
> 
> Signed-off-by: Pierre-Louis Bossart 

Looks good to me, so

Acked-by: Enric Balletbo i Serra 


> ---
>  sound/soc/codecs/cros_ec_codec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/cros_ec_codec.c 
> b/sound/soc/codecs/cros_ec_codec.c
> index c4772f82485a..a201d652aca2 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -94,7 +94,7 @@ static int send_ec_host_command(struct cros_ec_device 
> *ec_dev, uint32_t cmd,
>   if (ret < 0)
>   goto error;
>  
> - if (insize)
> + if (in && insize)
>   memcpy(in, msg->data, insize);
>  
>   ret = 0;
> 


[PATCH] soc: mediatek: pm-domains: Fix missing error code in scpsys_add_subdomain()

2021-03-03 Thread Enric Balletbo i Serra
Adding one power domain in scpsys_add_subdomain is missing to assign an
error code when it fails. Fix that assigning an error code to 'ret',
this also fixes the follwowing smatch warning.

  drivers/soc/mediatek/mtk-pm-domains.c:492 scpsys_add_subdomain() warn: 
missing error code 'ret'

Fixes: dd65030295e2 ("soc: mediatek: pm-domains: Don't print an error if child 
domain is deferred")
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mtk-pm-domains.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 694d6ea6de1d..0af00efa0ef8 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -491,8 +491,9 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, 
struct device_node *paren
 
child_pd = scpsys_add_one_domain(scpsys, child);
if (IS_ERR(child_pd)) {
-   dev_err_probe(scpsys->dev, PTR_ERR(child_pd),
- "%pOF: failed to get child domain id\n", 
child);
+   ret = PTR_ERR(child_pd);
+   dev_err_probe(scpsys->dev, ret, "%pOF: failed to get 
child domain id\n",
+ child);
goto err_put_node;
}
 
-- 
2.30.1



Re: [PATCH 1/2] iio: cros_ec: do an early exit if not physical_device case

2021-03-02 Thread Enric Balletbo i Serra
Hi all,

On 21/2/21 17:29, Jonathan Cameron wrote:
> On Mon, 23 Nov 2020 16:40:16 +0200
> Alexandru Ardelean  wrote:
> 
>> This whole code-block was put under one big if() condition/block.
>> This change does an early return if the 'physical_device' boolean is false,
>> thus unindenting the block by one level.
>>
>> No other functional change has been done.
>>
>> Signed-off-by: Alexandru Ardelean 
> @Gwendal, others  This series from Alex has been outstanding for a while
> but may well still apply.
> Ideally looking for an ack.
> 

This looks good to me.

Acked-by: Enric Balletbo i Serra 

Thanks,
 Enric

> Thanks,
> 
> Jonathan
>  
>> ---
>>  .../cros_ec_sensors/cros_ec_sensors_core.c| 161 +-
>>  1 file changed, 81 insertions(+), 80 deletions(-)
>>
>> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c 
>> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>> index 5c6c4e6fec9b..9470014936f2 100644
>> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
>> @@ -287,89 +287,90 @@ int cros_ec_sensors_core_init(struct platform_device 
>> *pdev,
>>  
>>  indio_dev->name = pdev->name;
>>  
>> -if (physical_device) {
>> -state->param.cmd = MOTIONSENSE_CMD_INFO;
>> -state->param.info.sensor_num = sensor_platform->sensor_num;
>> -ret = cros_ec_motion_send_host_cmd(state, 0);
>> -if (ret) {
>> -dev_warn(dev, "Can not access sensor info\n");
>> +if (!physical_device)
>> +return 0;
>> +
>> +state->param.cmd = MOTIONSENSE_CMD_INFO;
>> +state->param.info.sensor_num = sensor_platform->sensor_num;
>> +ret = cros_ec_motion_send_host_cmd(state, 0);
>> +if (ret) {
>> +dev_warn(dev, "Can not access sensor info\n");
>> +return ret;
>> +}
>> +state->type = state->resp->info.type;
>> +state->loc = state->resp->info.location;
>> +
>> +/* Set sign vector, only used for backward compatibility. */
>> +memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
>> +
>> +for (i = CROS_EC_SENSOR_X; i < CROS_EC_SENSOR_MAX_AXIS; i++)
>> +state->calib[i].scale = MOTION_SENSE_DEFAULT_SCALE;
>> +
>> +/* 0 is a correct value used to stop the device */
>> +if (state->msg->version < 3) {
>> +get_default_min_max_freq(state->resp->info.type,
>> + [1],
>> + [2],
>> + >fifo_max_event_count);
>> +} else {
>> +frequencies[1] = state->resp->info_3.min_frequency;
>> +frequencies[2] = state->resp->info_3.max_frequency;
>> +state->fifo_max_event_count =
>> +state->resp->info_3.fifo_max_event_count;
>> +}
>> +for (i = 0; i < ARRAY_SIZE(frequencies); i++) {
>> +state->frequencies[2 * i] = frequencies[i] / 1000;
>> +state->frequencies[2 * i + 1] =
>> +(frequencies[i] % 1000) * 1000;
>> +}
>> +
>> +if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE_FIFO)) {
>> +/*
>> + * Create a software buffer, feed by the EC FIFO.
>> + * We can not use trigger here, as events are generated
>> + * as soon as sample_frequency is set.
>> + */
>> +struct iio_buffer *buffer;
>> +
>> +buffer = devm_iio_kfifo_allocate(dev);
>> +if (!buffer)
>> +return -ENOMEM;
>> +
>> +iio_device_attach_buffer(indio_dev, buffer);
>> +indio_dev->modes = INDIO_BUFFER_SOFTWARE;
>> +
>> +ret = cros_ec_sensorhub_register_push_data(
>> +sensor_hub, sensor_platform->sensor_num,
>> +indio_dev, push_data);
>> +if (ret)
>>  return ret;
>> -}
>> -state->type = state->resp->info.type;
>> -state->loc = state->resp->info.location;
>>  
>> -/* Set sign vector, only used for backward compatibility. */
>> -memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
>> + 

[PATCH 2/4] soc: mediatek: pm-domains: Add a power domain names for mt8183

2021-02-25 Thread Enric Balletbo i Serra
Add the power domains names for the mt8183 SoC. This removes the debugfs
errors like the following:

  debugfs: Directory 'power-domain' with parent 'pm_genpd' already present!

Fixes: eb9fa767fbe1 ("soc: mediatek: pm-domains: Add support for mt8183")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mt8183-pm-domains.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/soc/mediatek/mt8183-pm-domains.h 
b/drivers/soc/mediatek/mt8183-pm-domains.h
index aa5230e6c12f..98a9940d05fb 100644
--- a/drivers/soc/mediatek/mt8183-pm-domains.h
+++ b/drivers/soc/mediatek/mt8183-pm-domains.h
@@ -12,12 +12,14 @@
 
 static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
[MT8183_POWER_DOMAIN_AUDIO] = {
+   .name = "audio",
.sta_mask = PWR_STATUS_AUDIO,
.ctl_offs = 0x0314,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8183_POWER_DOMAIN_CONN] = {
+   .name = "conn",
.sta_mask = PWR_STATUS_CONN,
.ctl_offs = 0x032c,
.sram_pdn_bits = 0,
@@ -28,12 +30,14 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
.sta_mask = PWR_STATUS_MFG_ASYNC,
.ctl_offs = 0x0334,
.sram_pdn_bits = 0,
.sram_pdn_ack_bits = 0,
},
[MT8183_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
.sta_mask = PWR_STATUS_MFG,
.ctl_offs = 0x0338,
.sram_pdn_bits = GENMASK(8, 8),
@@ -41,18 +45,21 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
.caps = MTK_SCPD_DOMAIN_SUPPLY,
},
[MT8183_POWER_DOMAIN_MFG_CORE0] = {
+   .name = "mfg_core0",
.sta_mask = BIT(7),
.ctl_offs = 0x034c,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8183_POWER_DOMAIN_MFG_CORE1] = {
+   .name = "mfg_core1",
.sta_mask = BIT(20),
.ctl_offs = 0x0310,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8183_POWER_DOMAIN_MFG_2D] = {
+   .name = "mfg_2d",
.sta_mask = PWR_STATUS_MFG_2D,
.ctl_offs = 0x0348,
.sram_pdn_bits = GENMASK(8, 8),
@@ -65,6 +72,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_DISP] = {
+   .name = "disp",
.sta_mask = PWR_STATUS_DISP,
.ctl_offs = 0x030c,
.sram_pdn_bits = GENMASK(8, 8),
@@ -83,6 +91,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_CAM] = {
+   .name = "cam",
.sta_mask = BIT(25),
.ctl_offs = 0x0344,
.sram_pdn_bits = GENMASK(9, 8),
@@ -105,6 +114,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_ISP] = {
+   .name = "isp",
.sta_mask = PWR_STATUS_ISP,
.ctl_offs = 0x0308,
.sram_pdn_bits = GENMASK(9, 8),
@@ -127,6 +137,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
.sta_mask = BIT(31),
.ctl_offs = 0x0300,
.sram_pdn_bits = GENMASK(8, 8),
@@ -139,6 +150,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_VENC] = {
+   .name = "venc",
.sta_mask = PWR_STATUS_VENC,
.ctl_offs = 0x0304,
.sram_pdn_bits = GENMASK(11, 8),
@@ -151,6 +163,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_VPU_TOP] = {
+   .name = "vpu_top",
.sta_mask = BIT(26),
.ctl_offs = 0x0324,
.sram_pdn_bits = GENMASK(8, 8),
@@ -177,6 +190,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8183[] = {
},
},
[MT8183_POWER_DOMAIN_VPU_CORE0] = {
+   .name = "vpu_core0",
.sta_mask = BIT(27),
.ctl_offs = 0x33c,

[PATCH 4/4] soc: mediatek: pm-domains: Add a power domain names for mt8167

2021-02-25 Thread Enric Balletbo i Serra
Add the power domains names for the mt8167 SoC.

Fixes: 207f13b419a6 ("soc: mediatek: pm-domains: Add support for mt8167")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mt8167-pm-domains.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/soc/mediatek/mt8167-pm-domains.h 
b/drivers/soc/mediatek/mt8167-pm-domains.h
index ad0b8dfa0527..15559ddf26e4 100644
--- a/drivers/soc/mediatek/mt8167-pm-domains.h
+++ b/drivers/soc/mediatek/mt8167-pm-domains.h
@@ -15,6 +15,7 @@
 
 static const struct scpsys_domain_data scpsys_domain_data_mt8167[] = {
[MT8167_POWER_DOMAIN_MM] = {
+   .name = "mm",
.sta_mask = PWR_STATUS_DISP,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
@@ -26,6 +27,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8167[] = {
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT8167_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
.sta_mask = PWR_STATUS_VDEC,
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(8, 8),
@@ -33,6 +35,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8167[] = {
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT8167_POWER_DOMAIN_ISP] = {
+   .name = "isp",
.sta_mask = PWR_STATUS_ISP,
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
@@ -40,6 +43,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8167[] = {
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT8167_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
.sta_mask = MT8167_PWR_STATUS_MFG_ASYNC,
.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
.sram_pdn_bits = 0,
@@ -50,18 +54,21 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8167[] = {
},
},
[MT8167_POWER_DOMAIN_MFG_2D] = {
+   .name = "mfg_2d",
.sta_mask = MT8167_PWR_STATUS_MFG_2D,
.ctl_offs = SPM_MFG_2D_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8167_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
.sta_mask = PWR_STATUS_MFG,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8167_POWER_DOMAIN_CONN] = {
+   .name = "conn",
.sta_mask = PWR_STATUS_CONN,
.ctl_offs = SPM_CONN_PWR_CON,
.sram_pdn_bits = GENMASK(8, 8),
-- 
2.30.0



[PATCH 3/4] soc: mediatek: pm-domains: Add a power domain names for mt8192

2021-02-25 Thread Enric Balletbo i Serra
Add the power domains names for the mt8192 SoC.

Fixes: a49d5e7a89d6 ("soc: mediatek: pm-domains: Add support for mt8192")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mt8192-pm-domains.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/soc/mediatek/mt8192-pm-domains.h 
b/drivers/soc/mediatek/mt8192-pm-domains.h
index 0fdf6dc6231f..543dda70de01 100644
--- a/drivers/soc/mediatek/mt8192-pm-domains.h
+++ b/drivers/soc/mediatek/mt8192-pm-domains.h
@@ -12,6 +12,7 @@
 
 static const struct scpsys_domain_data scpsys_domain_data_mt8192[] = {
[MT8192_POWER_DOMAIN_AUDIO] = {
+   .name = "audio",
.sta_mask = BIT(21),
.ctl_offs = 0x0354,
.sram_pdn_bits = GENMASK(8, 8),
@@ -24,6 +25,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_CONN] = {
+   .name = "conn",
.sta_mask = PWR_STATUS_CONN,
.ctl_offs = 0x0304,
.sram_pdn_bits = 0,
@@ -45,12 +47,14 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
.caps = MTK_SCPD_KEEP_DEFAULT_OFF,
},
[MT8192_POWER_DOMAIN_MFG0] = {
+   .name = "mfg0",
.sta_mask = BIT(2),
.ctl_offs = 0x0308,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_MFG1] = {
+   .name = "mfg1",
.sta_mask = BIT(3),
.ctl_offs = 0x030c,
.sram_pdn_bits = GENMASK(8, 8),
@@ -75,36 +79,42 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_MFG2] = {
+   .name = "mfg2",
.sta_mask = BIT(4),
.ctl_offs = 0x0310,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_MFG3] = {
+   .name = "mfg3",
.sta_mask = BIT(5),
.ctl_offs = 0x0314,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_MFG4] = {
+   .name = "mfg4",
.sta_mask = BIT(6),
.ctl_offs = 0x0318,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_MFG5] = {
+   .name = "mfg5",
.sta_mask = BIT(7),
.ctl_offs = 0x031c,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_MFG6] = {
+   .name = "mfg6",
.sta_mask = BIT(8),
.ctl_offs = 0x0320,
.sram_pdn_bits = GENMASK(8, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8192_POWER_DOMAIN_DISP] = {
+   .name = "disp",
.sta_mask = BIT(20),
.ctl_offs = 0x0350,
.sram_pdn_bits = GENMASK(8, 8),
@@ -133,6 +143,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_IPE] = {
+   .name = "ipe",
.sta_mask = BIT(14),
.ctl_offs = 0x0338,
.sram_pdn_bits = GENMASK(8, 8),
@@ -149,6 +160,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_ISP] = {
+   .name = "isp",
.sta_mask = BIT(12),
.ctl_offs = 0x0330,
.sram_pdn_bits = GENMASK(8, 8),
@@ -165,6 +177,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_ISP2] = {
+   .name = "isp2",
.sta_mask = BIT(13),
.ctl_offs = 0x0334,
.sram_pdn_bits = GENMASK(8, 8),
@@ -181,6 +194,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_MDP] = {
+   .name = "mdp",
.sta_mask = BIT(19),
.ctl_offs = 0x034c,
.sram_pdn_bits = GENMASK(8, 8),
@@ -197,6 +211,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8192[] = {
},
},
[MT8192_POWER_DOMAIN_VENC] = {
+   .name = "venc",
.sta_mask = BIT(17),
 

[PATCH 1/4] soc: mediatek: pm-domains: Add a meaningful power domain name

2021-02-25 Thread Enric Balletbo i Serra
Add the power domains names to the power domain struct so we
have meaningful name for every power domain. This also removes the
following debugfs error message.

  [2.242068] debugfs: Directory 'power-domain' with parent 'pm_genpd' 
already present!
  [2.249949] debugfs: Directory 'power-domain' with parent 'pm_genpd' 
already present!
  [2.257784] debugfs: Directory 'power-domain' with parent 'pm_genpd' 
already present!
  ...

Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power domains")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mt8173-pm-domains.h | 10 ++
 drivers/soc/mediatek/mtk-pm-domains.c|  6 +-
 drivers/soc/mediatek/mtk-pm-domains.h|  2 ++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mt8173-pm-domains.h 
b/drivers/soc/mediatek/mt8173-pm-domains.h
index 3e8ee5dabb43..654c717e5467 100644
--- a/drivers/soc/mediatek/mt8173-pm-domains.h
+++ b/drivers/soc/mediatek/mt8173-pm-domains.h
@@ -12,24 +12,28 @@
 
 static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
[MT8173_POWER_DOMAIN_VDEC] = {
+   .name = "vdec",
.sta_mask = PWR_STATUS_VDEC,
.ctl_offs = SPM_VDE_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
},
[MT8173_POWER_DOMAIN_VENC] = {
+   .name = "venc",
.sta_mask = PWR_STATUS_VENC,
.ctl_offs = SPM_VEN_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8173_POWER_DOMAIN_ISP] = {
+   .name = "isp",
.sta_mask = PWR_STATUS_ISP,
.ctl_offs = SPM_ISP_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
},
[MT8173_POWER_DOMAIN_MM] = {
+   .name = "mm",
.sta_mask = PWR_STATUS_DISP,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
@@ -40,18 +44,21 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
},
},
[MT8173_POWER_DOMAIN_VENC_LT] = {
+   .name = "venc_lt",
.sta_mask = PWR_STATUS_VENC_LT,
.ctl_offs = SPM_VEN2_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8173_POWER_DOMAIN_AUDIO] = {
+   .name = "audio",
.sta_mask = PWR_STATUS_AUDIO,
.ctl_offs = SPM_AUDIO_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(15, 12),
},
[MT8173_POWER_DOMAIN_USB] = {
+   .name = "usb",
.sta_mask = PWR_STATUS_USB,
.ctl_offs = SPM_USB_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
@@ -59,18 +66,21 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
.sta_mask = PWR_STATUS_MFG_ASYNC,
.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = 0,
},
[MT8173_POWER_DOMAIN_MFG_2D] = {
+   .name = "mfg_2d",
.sta_mask = PWR_STATUS_MFG_2D,
.ctl_offs = SPM_MFG_2D_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(13, 12),
},
[MT8173_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
.sta_mask = PWR_STATUS_MFG,
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(13, 8),
diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index b7f697666bdd..694d6ea6de1d 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -438,7 +438,11 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
*scpsys, struct device_no
goto err_unprepare_subsys_clocks;
}
 
-   pd->genpd.name = node->name;
+   if (!pd->data->name)
+   pd->genpd.name = node->name;
+   else
+   pd->genpd.name = pd->data->name;
+
pd->genpd.power_off = scpsys_power_off;
pd->genpd.power_on = scpsys_power_on;
 
diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
b/drivers/soc/mediatek/mtk-pm-domains.h
index 141dc76054e6..21a4e113bbec 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.h
+++ b/drivers/soc/mediatek/mtk-pm-domains.h
@@ -76,6 +76,7 @@ str

[PATCH] media: hantro: Auto generate the AXI ID to avoid conflicts

2021-02-25 Thread Enric Balletbo i Serra
The AXI ID is an AXI bus configuration for improve bus performance. If
read and write operations use different ID the operations can be
paralleled, whereas when they have the same ID the operations will be
serialized. Right now, the write ID is fixed to 0 but we can set it to
0xff to get auto generated ID to avoid possible conflicts.

This change has no functional changes, but seems reasonable to let the
hardware to autogenerate the ID instead of hardcoding in software.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/staging/media/hantro/hantro_g1_h264_dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/hantro/hantro_g1_h264_dec.c 
b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
index 845bef73d218..090088cd98ea 100644
--- a/drivers/staging/media/hantro/hantro_g1_h264_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_h264_dec.c
@@ -30,7 +30,7 @@ static void set_params(struct hantro_ctx *ctx)
u32 reg;
 
/* Decoder control register 0. */
-   reg = G1_REG_DEC_CTRL0_DEC_AXI_WR_ID(0x0);
+   reg = G1_REG_DEC_CTRL0_DEC_AXI_WR_ID(0xff);
if (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD)
reg |= G1_REG_DEC_CTRL0_SEQ_MBAFF_E;
if (sps->profile_idc > 66) {
-- 
2.30.0



[PATCH v6] dt-bindings: power: rockchip: Convert to json-schema

2021-02-25 Thread Enric Balletbo i Serra
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 
Reviewed-by: Rob Herring 
---

Changes in v6:
- Add "rockchip," prefix to the qos compatible name. (Johan Jonker)

Changes in v5:
- Fix space warnings reported by bot.
- Add the Rob's Reviewed-by tag.
- Fix license.

Changes in v4:
- Use hex for unit-addresses.
- Use space between compatibles in the example.
- Define child nodes for nested power domains even are duplicated but
  more clear that adding a regex scaped to be a valid URI.

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  | 283 ++
 .../bindings/soc/rockchip/power_domain.txt| 136 -
 2 files changed, 283 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 ..3f4005be200b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml
@@ -0,0 +1,283 @@
+# 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:
+  - 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-9a-f]+$":
+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
+
+  clocks:
+description: |
+  A number of phandles to clocks that need to be enabled while power 
domain
+  switches state.
+
+  pm_qos:
+description: |
+  A number of phandles to qos blocks which need to be saved and 
restore

[PATCH 1/2] arm64: defconfig: Allow mt8173-based boards to boot from usb

2021-02-09 Thread Enric Balletbo i Serra
Enable the option necessary to boot mt8173-based boards to boot from
usb devices, like its phy and the regulators needed to have proper
support.

Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm64/configs/defconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 01aa3eee90e8..30db9b50efaa 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -444,6 +444,7 @@ CONFIG_I2C_GPIO=m
 CONFIG_I2C_IMX=y
 CONFIG_I2C_IMX_LPI2C=y
 CONFIG_I2C_MESON=y
+CONFIG_I2C_MT65XX=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_OMAP=y
 CONFIG_I2C_OWL=y
@@ -586,6 +587,7 @@ CONFIG_MFD_EXYNOS_LPASS=m
 CONFIG_MFD_HI6421_PMIC=y
 CONFIG_MFD_HI655X_PMIC=y
 CONFIG_MFD_MAX77620=y
+CONFIG_MFD_MT6397=y
 CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_RK808=y
 CONFIG_MFD_SEC_CORE=y
@@ -602,6 +604,8 @@ CONFIG_REGULATOR_HI6421V530=y
 CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_MAX77620=y
 CONFIG_REGULATOR_MAX8973=y
+CONFIG_REGULATOR_MT6358=y
+CONFIG_REGULATOR_MT6397=y
 CONFIG_REGULATOR_PCA9450=y
 CONFIG_REGULATOR_PFUZE100=y
 CONFIG_REGULATOR_PWM=y
@@ -765,6 +769,7 @@ CONFIG_USB_RENESAS_USBHS_HCD=m
 CONFIG_USB_RENESAS_USBHS=m
 CONFIG_USB_ACM=m
 CONFIG_USB_STORAGE=y
+CONFIG_USB_MTU3=y
 CONFIG_USB_MUSB_HDRC=y
 CONFIG_USB_MUSB_SUNXI=y
 CONFIG_USB_DWC3=y
@@ -958,6 +963,7 @@ CONFIG_OWL_PM_DOMAINS=y
 CONFIG_RASPBERRYPI_POWER=y
 CONFIG_FSL_DPAA=y
 CONFIG_FSL_MC_DPIO=y
+CONFIG_MTK_PMIC_WRAP=y
 CONFIG_QCOM_AOSS_QMP=y
 CONFIG_QCOM_COMMAND_DB=y
 CONFIG_QCOM_GENI_SE=y
@@ -1032,6 +1038,7 @@ CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_HISTB_COMBPHY=y
 CONFIG_PHY_HISI_INNO_USB2=y
 CONFIG_PHY_MVEBU_CP110_COMPHY=y
+CONFIG_PHY_MTK_TPHY=y
 CONFIG_PHY_QCOM_QMP=m
 CONFIG_PHY_QCOM_QUSB2=m
 CONFIG_PHY_QCOM_USB_HS=y
-- 
2.30.0



[PATCH 2/2] arm64: defconfig: Enable options to support panel display for Mediatek Chromebooks

2021-02-09 Thread Enric Balletbo i Serra
There are some Mediatek based Chromebooks supported in the kernel. Enable the
required config options to have the panel display working on both devices.
This was tested on the ACER Chromebook R13 (MT8173) and the Lenovo
Ideapad Duet (MT8183), but should also enable display support for similar
devices.

Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm64/configs/defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 30db9b50efaa..7f4d70d24bb5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -676,6 +676,7 @@ CONFIG_DRM_MSM=m
 CONFIG_DRM_TEGRA=m
 CONFIG_DRM_PANEL_LVDS=m
 CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m
 CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m
 CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
 CONFIG_DRM_PANEL_SITRONIX_ST7703=m
@@ -683,6 +684,7 @@ CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m
 CONFIG_DRM_DISPLAY_CONNECTOR=m
 CONFIG_DRM_NWL_MIPI_DSI=m
 CONFIG_DRM_LONTIUM_LT9611=m
+CONFIG_DRM_PARADE_PS8640=m
 CONFIG_DRM_SII902X=m
 CONFIG_DRM_SIMPLE_BRIDGE=m
 CONFIG_DRM_THINE_THC63LVD1024=m
@@ -696,6 +698,8 @@ CONFIG_DRM_VC4=m
 CONFIG_DRM_ETNAVIV=m
 CONFIG_DRM_HISI_HIBMC=m
 CONFIG_DRM_HISI_KIRIN=m
+CONFIG_DRM_MEDIATEK=m
+CONFIG_DRM_MEDIATEK_HDMI=m
 CONFIG_DRM_MXSFB=m
 CONFIG_DRM_MESON=m
 CONFIG_DRM_PL111=m
@@ -949,6 +953,7 @@ CONFIG_ROCKCHIP_IOMMU=y
 CONFIG_TEGRA_IOMMU_SMMU=y
 CONFIG_ARM_SMMU=y
 CONFIG_ARM_SMMU_V3=y
+CONFIG_MTK_IOMMU=y
 CONFIG_QCOM_IOMMU=y
 CONFIG_REMOTEPROC=y
 CONFIG_QCOM_Q6V5_MSS=m
@@ -1019,6 +1024,8 @@ CONFIG_PWM=y
 CONFIG_PWM_BCM2835=m
 CONFIG_PWM_CROS_EC=m
 CONFIG_PWM_MESON=m
+CONFIG_PWM_MTK_DISP=m
+CONFIG_PWM_MEDIATEK=m
 CONFIG_PWM_RCAR=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
@@ -1063,6 +1070,7 @@ CONFIG_QCOM_L3_PMU=y
 CONFIG_NVMEM_IMX_OCOTP=y
 CONFIG_NVMEM_IMX_OCOTP_SCU=y
 CONFIG_QCOM_QFPROM=y
+CONFIG_MTK_EFUSE=y
 CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_UNIPHIER_EFUSE=y
-- 
2.30.0



[PATCH] drm/mediatek: Add missing MODULE_DEVICE_TABLE()

2021-02-03 Thread Enric Balletbo i Serra
From: Boris Brezillon 

This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.

Signed-off-by: Boris Brezillon 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_cec.c  | 2 ++
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_dsi.c  | 1 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 1 +
 drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 1 +
 6 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c 
b/drivers/gpu/drm/mediatek/mtk_cec.c
index cb29b649fcdb..3b86e626e459 100644
--- a/drivers/gpu/drm/mediatek/mtk_cec.c
+++ b/drivers/gpu/drm/mediatek/mtk_cec.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -247,6 +248,7 @@ static const struct of_device_id mtk_cec_of_ids[] = {
{ .compatible = "mediatek,mt8173-cec", },
{}
 };
+MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
 
 struct platform_driver mtk_cec_driver = {
.probe = mtk_cec_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 52f11a63a330..2680370652fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -822,6 +822,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
},
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
 
 struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 5f49a809689b..e4645c8ae1c0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -470,6 +470,7 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _mmsys_driver_data},
{ }
 };
+MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
 
 static int mtk_drm_probe(struct platform_device *pdev)
 {
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 0527480c07be..c71ce62d1bec 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -1193,6 +1193,7 @@ static const struct of_device_id mtk_dsi_of_match[] = {
  .data = _dsi_driver_data },
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_dsi_of_match);
 
 struct platform_driver mtk_dsi_driver = {
.probe = mtk_dsi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 8ee55f9e2954..b4696a9d73f7 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1818,6 +1818,7 @@ static const struct of_device_id mtk_drm_hdmi_of_ids[] = {
},
{}
 };
+MODULE_DEVICE_TABLE(of, mtk_drm_hdmi_of_ids);
 
 static struct platform_driver mtk_hdmi_driver = {
.probe = mtk_drm_hdmi_probe,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index 62dbad5675bb..6207eac88550 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -335,6 +335,7 @@ static const struct of_device_id mtk_hdmi_ddc_match[] = {
{ .compatible = "mediatek,mt8173-hdmi-ddc", },
{},
 };
+MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_match);
 
 struct platform_driver mtk_hdmi_ddc_driver = {
.probe = mtk_hdmi_ddc_probe,
-- 
2.30.0



[PATCH] phy: mediatek: Add missing MODULE_DEVICE_TABLE()

2021-02-03 Thread Enric Balletbo i Serra
From: Boris Brezillon 

This patch adds the missing MODULE_DEVICE_TABLE definitions on different
Mediatek phy drivers which generates correct modalias for automatic loading
when these drivers are compiled as an external module.

Signed-off-by: Boris Brezillon 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/phy/mediatek/phy-mtk-hdmi.c | 1 +
 drivers/phy/mediatek/phy-mtk-mipi-dsi.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c 
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index 45be8aa724f3..8313bd517e4c 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -201,6 +201,7 @@ static const struct of_device_id mtk_hdmi_phy_match[] = {
},
{},
 };
+MODULE_DEVICE_TABLE(of, mtk_hdmi_phy_match);
 
 static struct platform_driver mtk_hdmi_phy_driver = {
.probe = mtk_hdmi_phy_probe,
diff --git a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c 
b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
index 18c481251f04..9c7815bb9000 100644
--- a/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
+++ b/drivers/phy/mediatek/phy-mtk-mipi-dsi.c
@@ -233,6 +233,7 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
  .data = _mipitx_data },
{ },
 };
+MODULE_DEVICE_TABLE(of, mtk_mipi_tx_match);
 
 struct platform_driver mtk_mipi_tx_driver = {
.probe = mtk_mipi_tx_probe,
-- 
2.30.0



[PATCH] clk: mediatek: Select all the MT8183 clocks by default

2021-02-03 Thread Enric Balletbo i Serra
If MT8183 SoC support is enabled, almost all machines will use topckgen,
apmixedsys, infracfg, mcucfg and subsystem clocks, so it feels wrong to
require each one to select that symbols manually.

Instead, enable it whenever COMMON_CLK_MT8183_* is disabled as
a simplification. This would add few KB in the kernel image size but
will make the life a bit easier to the users, anyway you'll need to probably
enable all of them if you want to have proper support for that SoC.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/clk/mediatek/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index ce8475098b31..886e2d9fced5 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -426,66 +426,77 @@ config COMMON_CLK_MT8183
 config COMMON_CLK_MT8183_AUDIOSYS
bool "Clock driver for MediaTek MT8183 audiosys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 audiosys clocks.
 
 config COMMON_CLK_MT8183_CAMSYS
bool "Clock driver for MediaTek MT8183 camsys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 camsys clocks.
 
 config COMMON_CLK_MT8183_IMGSYS
bool "Clock driver for MediaTek MT8183 imgsys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 imgsys clocks.
 
 config COMMON_CLK_MT8183_IPU_CORE0
bool "Clock driver for MediaTek MT8183 ipu_core0"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 ipu_core0 clocks.
 
 config COMMON_CLK_MT8183_IPU_CORE1
bool "Clock driver for MediaTek MT8183 ipu_core1"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 ipu_core1 clocks.
 
 config COMMON_CLK_MT8183_IPU_ADL
bool "Clock driver for MediaTek MT8183 ipu_adl"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 ipu_adl clocks.
 
 config COMMON_CLK_MT8183_IPU_CONN
bool "Clock driver for MediaTek MT8183 ipu_conn"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 ipu_conn clocks.
 
 config COMMON_CLK_MT8183_MFGCFG
bool "Clock driver for MediaTek MT8183 mfgcfg"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 mfgcfg clocks.
 
 config COMMON_CLK_MT8183_MMSYS
bool "Clock driver for MediaTek MT8183 mmsys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 mmsys clocks.
 
 config COMMON_CLK_MT8183_VDECSYS
bool "Clock driver for MediaTek MT8183 vdecsys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 vdecsys clocks.
 
 config COMMON_CLK_MT8183_VENCSYS
bool "Clock driver for MediaTek MT8183 vencsys"
depends on COMMON_CLK_MT8183
+   default COMMON_CLK_MT8183
help
  This driver supports MediaTek MT8183 vencsys clocks.
 
-- 
2.30.0



Re: [GIT PULL] Immutable Branch between platform/chrome and USB for v5.12 merge window

2021-02-02 Thread Enric Balletbo i Serra
Hi,

On 2/2/21 9:06, Benson Leung wrote:
> Hi Greg,
> 
> The following changes since commit 29b01295a829fba7399ee84afff4e64660e49f04:
> 
>   usb: typec: Add typec_partner_set_pd_revision (2021-02-01 15:31:34 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git 
> tags/tag-ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12
> 
> for you to fetch changes up to 0371616d8bef6926e9aa05757f35b901268d3724:
> 
>   platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected 
> (2021-02-01 23:49:54 -0800)
> 
> 
> cros-ec-typec changes for usb for v5.12
> 
> Chrome OS EC Type-C driver features implemented this round:
> * Registration of cable plug information
> * Support for SOP' plug registration and altmodes
> * Support for reporting number of altmodes supported by partners and plugs
> * Send mux configuration ack to EC via a new host command
> * Reporting SOP' and Partner PD revisions
> 
> 
> Benson Leung (4):
>   Merge remote-tracking branch 'origin/cros-ec-typec-for-5.12' into 
> ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12
>   platform/chrome: cros_ec_typec: Report SOP' PD revision from status
>   platform/chrome: cros_ec_typec: Set Partner PD revision from status
>   platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected
> 
> Prashant Malani (8):
>   platform/chrome: cros_ec_typec: Make disc_done flag partner-only
>   platform/chrome: cros_ec_typec: Factor out PD identity parsing
>   platform/chrome: cros_ec_typec: Rename discovery struct
>   platform/chrome: cros_ec_typec: Register cable
>   platform/chrome: cros_ec_typec: Store cable plug type
>   platform/chrome: cros_ec_typec: Set partner num_altmodes
>   platform/chrome: cros_ec_typec: Register SOP' cable plug
>   platform/chrome: cros_ec_typec: Register plug altmodes
> 
> Utkarsh Patel (2):
>   platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported()
>   platform/chrome: cros_ec_typec: Send mux configuration acknowledgment 
> to EC
> 
>  drivers/platform/chrome/cros_ec_typec.c| 269 
> +
>  include/linux/platform_data/cros_ec_commands.h |  17 ++
>  2 files changed, 243 insertions(+), 43 deletions(-)
> 
> Thanks so much!
> Benson
> 


FWIW this looks good to me. It'd make more easy if all this goes through Greg's
tree instead of our chrome/platform tree. Not sure if is really needed but:

Acked-by: Enric Balletbo i Serra 

Thanks,
  Enric



Re: [PATCH 0/6] usb: typec: and platform/chrome: Add PD revision numbers

2021-02-01 Thread Enric Balletbo i Serra
Hi all,

On 1/2/21 15:37, Enric Balletbo i Serra wrote:
> Hi all,
> 
> On 29/1/21 7:14, Benson Leung wrote:
>> USB Power Delivery has a 3 entity handshake (port, cable, partner), and as
>> of USB PD R3.0, each entity may independently support either Revision 2 or
>> Revision 3 signaling and protocol. In order for userspace and the kernel
>> to properly process the data objects received from a particular SOP*, we
>> must know to which revision of the spec each conforms.
>>
>> This series adds individual version numbers for the partner and the cable,
>> and exposes them in the appropriate sysfs in /sys/class/typec.
>>
>> I provide as a first implementation of this, platform/chrome's cros_ec_typec
>> driver, whose underlying status messages convey the SOP and SOP' revisions
>> already.
>>
>> Thanks,
>> Benson
>>
>> Benson Leung (6):
>>   usb: typec: Standardize PD Revision format with Type-C Revision
>>   usb: typec: Provide PD Specification Revision for cable and partner
>>   usb: typec: Add typec_partner_set_pd_revision
>>   platform/chrome: cros_ec_typec: Report SOP' PD revision from status
>>   platform/chrome: cros_ec_typec: Set Partner PD revision from status
>>   platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected
>>
> 
> I acked the above chrome/platform patches in case Greg wants to pick up the 
> full
> series through his usb tree, I think is what makes more sense. They look good 
> to
> me from the chrome/platform side.
> 

Sorry, just noticed that the platform/chrome patches depends on some patches
that we have already queued for 5.12. So we will pick up these patches and take
care to not merge before the specific usb type-c bits. So forget about the 
above.

Thanks,
 Enric


> Thanks,
>   Enric
> 
>>  Documentation/ABI/testing/sysfs-class-typec | 20 ++-
>>  drivers/platform/chrome/cros_ec_typec.c | 26 +++--
>>  drivers/usb/typec/class.c   | 59 +++--
>>  include/linux/usb/typec.h   | 11 
>>  4 files changed, 108 insertions(+), 8 deletions(-)
>>


Re: [PATCH 0/6] usb: typec: and platform/chrome: Add PD revision numbers

2021-02-01 Thread Enric Balletbo i Serra
Hi all,

On 29/1/21 7:14, Benson Leung wrote:
> USB Power Delivery has a 3 entity handshake (port, cable, partner), and as
> of USB PD R3.0, each entity may independently support either Revision 2 or
> Revision 3 signaling and protocol. In order for userspace and the kernel
> to properly process the data objects received from a particular SOP*, we
> must know to which revision of the spec each conforms.
> 
> This series adds individual version numbers for the partner and the cable,
> and exposes them in the appropriate sysfs in /sys/class/typec.
> 
> I provide as a first implementation of this, platform/chrome's cros_ec_typec
> driver, whose underlying status messages convey the SOP and SOP' revisions
> already.
> 
> Thanks,
> Benson
> 
> Benson Leung (6):
>   usb: typec: Standardize PD Revision format with Type-C Revision
>   usb: typec: Provide PD Specification Revision for cable and partner
>   usb: typec: Add typec_partner_set_pd_revision
>   platform/chrome: cros_ec_typec: Report SOP' PD revision from status
>   platform/chrome: cros_ec_typec: Set Partner PD revision from status
>   platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected
> 

I acked the above chrome/platform patches in case Greg wants to pick up the full
series through his usb tree, I think is what makes more sense. They look good to
me from the chrome/platform side.

Thanks,
  Enric

>  Documentation/ABI/testing/sysfs-class-typec | 20 ++-
>  drivers/platform/chrome/cros_ec_typec.c | 26 +++--
>  drivers/usb/typec/class.c   | 59 +++--
>  include/linux/usb/typec.h   | 11 
>  4 files changed, 108 insertions(+), 8 deletions(-)
> 


Re: [PATCH 6/6] platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected

2021-02-01 Thread Enric Balletbo i Serra
Hi Benson,

On 29/1/21 7:14, Benson Leung wrote:
> When SOP Discovery is done, set the opmode to PD if status indicates
> SOP is connected.
> 
> SOP connected indicates a PD contract is in place, and is a solid
> indication we have transitioned to PD power negotiation, either as
> source or sink.
> 
> Signed-off-by: Benson Leung 

Acked-by: Enric Balletbo i Serra 

> ---
>  drivers/platform/chrome/cros_ec_typec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
> b/drivers/platform/chrome/cros_ec_typec.c
> index 6bc6fafd54a4..a7778258d0a0 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -900,6 +900,9 @@ static void cros_typec_handle_status(struct 
> cros_typec_data *typec, int port_num
>   dev_err(typec->dev, "Couldn't parse SOP Disc data, 
> port: %d\n", port_num);
>   else
>   typec->ports[port_num]->sop_disc_done = true;
> +
> + if (resp.sop_connected)
> + typec_set_pwr_opmode(typec->ports[port_num]->port, 
> TYPEC_PWR_MODE_PD);
>   }
>  
>   if (resp.events & PD_STATUS_EVENT_SOP_PRIME_DISC_DONE &&
> 


Re: [PATCH 5/6] platform/chrome: cros_ec_typec: Set Partner PD revision from status

2021-02-01 Thread Enric Balletbo i Serra
Hi Benson,

On 29/1/21 7:14, Benson Leung wrote:
> Status provides sop_revision. Process it, and set it using the new
> setter in the typec class.
> 
> Signed-off-by: Benson Leung 

Acked-by: Enric Balletbo i Serra 

> ---
>  drivers/platform/chrome/cros_ec_typec.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
> b/drivers/platform/chrome/cros_ec_typec.c
> index 30600e9454e1..6bc6fafd54a4 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -824,7 +824,7 @@ static int cros_typec_handle_sop_prime_disc(struct 
> cros_typec_data *typec, int p
>   return ret;
>  }
>  
> -static int cros_typec_handle_sop_disc(struct cros_typec_data *typec, int 
> port_num)
> +static int cros_typec_handle_sop_disc(struct cros_typec_data *typec, int 
> port_num, u16 pd_revision)
>  {
>   struct cros_typec_port *port = typec->ports[port_num];
>   struct ec_response_typec_discovery *sop_disc = port->disc_data;
> @@ -842,6 +842,12 @@ static int cros_typec_handle_sop_disc(struct 
> cros_typec_data *typec, int port_nu
>   goto disc_exit;
>   }
>  
> + ret = typec_partner_set_pd_revision(port->partner, pd_revision);
> + if (ret < 0) {
> + dev_err(typec->dev, "Failed to update partner PD revision, 
> port: %d\n", port_num);
> + goto disc_exit;
> + }
> +
>   memset(sop_disc, 0, EC_PROTO2_MAX_RESPONSE_SIZE);
>   ret = cros_typec_ec_command(typec, 0, EC_CMD_TYPEC_DISCOVERY, , 
> sizeof(req),
>   sop_disc, EC_PROTO2_MAX_RESPONSE_SIZE);
> @@ -885,7 +891,11 @@ static void cros_typec_handle_status(struct 
> cros_typec_data *typec, int port_num
>  
>   /* Handle any events appropriately. */
>   if (resp.events & PD_STATUS_EVENT_SOP_DISC_DONE && 
> !typec->ports[port_num]->sop_disc_done) {
> - ret = cros_typec_handle_sop_disc(typec, port_num);
> + u16 sop_revision;
> +
> + /* Convert BCD to the format preferred by the TypeC framework */
> + sop_revision = (le16_to_cpu(resp.sop_revision) & 0xff00) >> 4;
> + ret = cros_typec_handle_sop_disc(typec, port_num, sop_revision);
>   if (ret < 0)
>   dev_err(typec->dev, "Couldn't parse SOP Disc data, 
> port: %d\n", port_num);
>   else
> 


Re: [PATCH 4/6] platform/chrome: cros_ec_typec: Report SOP' PD revision from status

2021-02-01 Thread Enric Balletbo i Serra
Hi Benson,

On 29/1/21 7:14, Benson Leung wrote:
> cros_typec_handle_sop_prime_disc now takes the PD revision provided
> by the EC_CMD_TYPEC_STATUS command response for the SOP'.
> 
> Attach the properly formatted pd_revision to the cable desc before
> registering the cable.
> 
> Signed-off-by: Benson Leung 

Acked-by: Enric Balletbo i Serra 

> ---
>  drivers/platform/chrome/cros_ec_typec.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
> b/drivers/platform/chrome/cros_ec_typec.c
> index e724a5eaef1c..30600e9454e1 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -748,7 +748,7 @@ static void cros_typec_parse_pd_identity(struct 
> usb_pd_identity *id,
>   id->vdo[i - 3] = disc->discovery_vdo[i];
>  }
>  
> -static int cros_typec_handle_sop_prime_disc(struct cros_typec_data *typec, 
> int port_num)
> +static int cros_typec_handle_sop_prime_disc(struct cros_typec_data *typec, 
> int port_num, u16 pd_revision)
>  {
>   struct cros_typec_port *port = typec->ports[port_num];
>   struct ec_response_typec_discovery *disc = port->disc_data;
> @@ -794,6 +794,7 @@ static int cros_typec_handle_sop_prime_disc(struct 
> cros_typec_data *typec, int p
>   }
>  
>   c_desc.identity = >c_identity;
> + c_desc.pd_revision = pd_revision;
>  
>   port->cable = typec_register_cable(port->port, _desc);
>   if (IS_ERR(port->cable)) {
> @@ -893,7 +894,11 @@ static void cros_typec_handle_status(struct 
> cros_typec_data *typec, int port_num
>  
>   if (resp.events & PD_STATUS_EVENT_SOP_PRIME_DISC_DONE &&
>   !typec->ports[port_num]->sop_prime_disc_done) {
> - ret = cros_typec_handle_sop_prime_disc(typec, port_num);
> + u16 sop_prime_revision;
> +
> + /* Convert BCD to the format preferred by the TypeC framework */
> + sop_prime_revision = (le16_to_cpu(resp.sop_prime_revision) & 
> 0xff00) >> 4;
> + ret = cros_typec_handle_sop_prime_disc(typec, port_num, 
> sop_prime_revision);
>   if (ret < 0)
>   dev_err(typec->dev, "Couldn't parse SOP' Disc data, 
> port: %d\n", port_num);
>   else
> 


Re: [PATCH v2 0/2] platform: chrome: Simplify interrupt path

2021-01-26 Thread Enric Balletbo i Serra
On Thu, 21 Jan 2021 21:46:35 -0800, Gwendal Grignou wrote:
> rrespective of the transport (i2c, spi, ish, rpmsg), have all cros ec
> interrupt stack call the threaded part (bottom half) of the interrupt
> handler.
> Fix an issue where EC could be stuck if it sends a message while the AP
> is not powered on.
> 
> Changes since v1:
> - fix merging issue and function comments syntax.
> 
> [...]

Applied, thanks!

[1/2] platform: cros_ec: Call interrupt bottom half in ISH or RPMSG mode
  commit: 24c69043be1725606e876b47d496a0f9f87d176a
[2/2] platform: cros_ec: Call interrupt bottom half at probe time
  commit: 4daeb395f1754340927d8d58269593e4e3b6afcd

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH v2 1/2] platform/chrome: cros_ec: Add host command to keep AP off after EC reset.

2021-01-20 Thread Enric Balletbo i Serra
On Mon, 21 Dec 2020 12:12:23 +0800, Pi-Hsun Shih wrote:
> Add command to EC_CMD_REBOOT_EC to reset EC but don't boot AP.

Applied, thanks!

[1/2] platform/chrome: cros_ec: Add host command to keep AP off after EC reset.
  commit: 8e7a76ad8f51fd9aaabf8feeea54b22f4e4873d8
[2/2] platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot.
  commit: 91b9694542179f2f2325a5c4f86c4e7f9be277d3

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH 1/2] platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT

2021-01-20 Thread Enric Balletbo i Serra
On Wed, 9 Dec 2020 22:03:54 +, Evan Benn wrote:
> The host_event_code enum is 1-based, use EC_HOST_EVENT_MASK not BIT to
> generate the intended mask. This patch changes the behaviour of the
> mask, a following patch will restore the intended behaviour:
> 'Add LID and BATTERY to default mask'

Applied, thanks!

[1/2] platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT
  commit: 9eb4f16a67245f7155148d9a400e0eab3cb0fe7b
[2/2] platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask
  commit: b33539f0d9f341a765c6b9dc63f00e253c8595aa

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH] platform/chrome: Constify static attribute_group structs

2021-01-20 Thread Enric Balletbo i Serra
On Sat, 9 Jan 2021 01:17:48 +0100, Rikard Falkeborn wrote:
> The only usage of these is to print their name in a dev_err-message, and
> to pass their address to sysfs_create_group() and sysfs_remove_group(),
> both which takes pointers to const. Make them const to allow the compiler
> to put them in read-only memory.

Applied, thanks!

[1/1] platform/chrome: Constify static attribute_group structs
  commit: ed07d774c4b2793be4d2bfc62cf69c3e55667f5a

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH v7 2/2] ASoC: cros_ec_codec: Reset I2S RX when probing

2021-01-19 Thread Enric Balletbo i Serra
Hi Yu-Hsuan,

Thanks to apply the nit, but you can maintain the reviewed tag.

On 15/1/21 8:53, Yu-Hsuan Hsu wrote:
> It is not guaranteed that I2S RX is disabled when the kernel booting.
> For example, if the kernel crashes while it is enabled, it will keep
> enabled until the next time EC reboots. Reset I2S RX when probing to
> fix this issue.
> 
> Signed-off-by: Yu-Hsuan Hsu 

Reviewed-by: Enric Balletbo i Serra 


> ---
> Updated the info message.
> 
>  sound/soc/codecs/cros_ec_codec.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/sound/soc/codecs/cros_ec_codec.c 
> b/sound/soc/codecs/cros_ec_codec.c
> index f33a2a9654e7..c4772f82485a 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -1011,6 +1011,18 @@ static int cros_ec_codec_platform_probe(struct 
> platform_device *pdev)
>   }
>   priv->ec_capabilities = r.capabilities;
>  
> + /* Reset EC codec i2s rx. */
> + p.cmd = EC_CODEC_I2S_RX_RESET;
> + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX,
> +(uint8_t *), sizeof(p), NULL, 0);
> + if (ret == -ENOPROTOOPT) {
> + dev_info(dev,
> +  "Missing reset command. Please update EC firmware.\n");
> + } else if (ret) {
> + dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret);
> + return ret;
> + }
> +
>   platform_set_drvdata(pdev, priv);
>  
>   ret = devm_snd_soc_register_component(dev, _rx_component_driver,
> 


Re: [PATCH v7 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET

2021-01-19 Thread Enric Balletbo i Serra
Hi Yu-Hsuan,

On 15/1/21 8:53, Yu-Hsuan Hsu wrote:
> Add the new command EC_CODEC_I2S_RX_RESET in ec_codec_i2s_rx_subcmd,
> which is used for resetting the EC codec.
> 
> Signed-off-by: Yu-Hsuan Hsu 

Please carry the tags when sending newer versions if nothing changed. This patch
was already

Acked-by: Enric Balletbo i Serra 

Mark I'm fine if both patches go through your tree.


> ---
>  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..95889ada83a3 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -4600,6 +4600,7 @@ enum ec_codec_i2s_rx_subcmd {
>   EC_CODEC_I2S_RX_SET_SAMPLE_DEPTH = 0x2,
>   EC_CODEC_I2S_RX_SET_DAIFMT = 0x3,
>   EC_CODEC_I2S_RX_SET_BCLK = 0x4,
> + EC_CODEC_I2S_RX_RESET = 0x5,
>   EC_CODEC_I2S_RX_SUBCMD_COUNT,
>  };
>  
> 


Re: [PATCH v6 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET

2021-01-14 Thread Enric Balletbo i Serra
Hi,

On 14/1/21 7:54, Yu-Hsuan Hsu wrote:
> Add the new command EC_CODEC_I2S_RX_RESET in ec_codec_i2s_rx_subcmd,
> which is used for resetting the EC codec.
> 
> Signed-off-by: Yu-Hsuan Hsu 

For if Mark wants to take this patch through his tree.

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..95889ada83a3 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -4600,6 +4600,7 @@ enum ec_codec_i2s_rx_subcmd {
>   EC_CODEC_I2S_RX_SET_SAMPLE_DEPTH = 0x2,
>   EC_CODEC_I2S_RX_SET_DAIFMT = 0x3,
>   EC_CODEC_I2S_RX_SET_BCLK = 0x4,
> + EC_CODEC_I2S_RX_RESET = 0x5,
>   EC_CODEC_I2S_RX_SUBCMD_COUNT,
>  };
>  
> 


Re: [PATCH v6 2/2] ASoC: cros_ec_codec: Reset I2S RX when probing

2021-01-14 Thread Enric Balletbo i Serra
Hi Yu-Hsuan,

On 14/1/21 7:54, Yu-Hsuan Hsu wrote:
> It is not guaranteed that I2S RX is disabled when the kernel booting.
> For example, if the kernel crashes while it is enabled, it will keep
> enabled until the next time EC reboots. Reset I2S RX when probing to
> fix this issue.
> 
> Signed-off-by: Yu-Hsuan Hsu 
> ---
> Returns the error code when it fails to reset.
> 
>  sound/soc/codecs/cros_ec_codec.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/sound/soc/codecs/cros_ec_codec.c 
> b/sound/soc/codecs/cros_ec_codec.c
> index f33a2a9654e7..40e437aa1d55 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -1011,6 +1011,18 @@ static int cros_ec_codec_platform_probe(struct 
> platform_device *pdev)
>   }
>   priv->ec_capabilities = r.capabilities;
>  
> + /* Reset EC codec i2s rx. */
> + p.cmd = EC_CODEC_I2S_RX_RESET;
> + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX,
> +(uint8_t *), sizeof(p), NULL, 0);
> + if (ret == -ENOPROTOOPT) {
> + dev_info(dev,
> +  "Command not found. Please update the EC firmware.\n");

Nitpicking a bit. I'd add which command is not found to give more information to
the user that gets into that path. Command not found is too generic for me.

But,

Reviewed-by: Enric Balletbo i Serra 

> + } else if (ret) {
> + dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret);
> + return ret;
> + }
> +
>   platform_set_drvdata(pdev, priv);
>  
>   ret = devm_snd_soc_register_component(dev, _rx_component_driver,
> 


Re: [PATCH 2/3] soc: mediatek: pm-domains: Add domain regulator supply

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for the patch.

On 10/1/21 2:49, Nicolas Boichat wrote:
> On Thu, Jan 7, 2021 at 6:49 PM Hsin-Yi Wang  wrote:
>>
>> Some power domains (eg. mfg) needs to turn on power supply before power
>> on.
>>
>> Signed-off-by: Hsin-Yi Wang 
> 
> Reviewed-by: Nicolas Boichat 
> 

Reviewed-by: Enric Balletbo i Serra 


>> ---
>>  drivers/soc/mediatek/mt8183-pm-domains.h |  1 +
>>  drivers/soc/mediatek/mtk-pm-domains.c| 36 +++-
>>  drivers/soc/mediatek/mtk-pm-domains.h|  1 +
>>  3 files changed, 37 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/mediatek/mt8183-pm-domains.h 
>> b/drivers/soc/mediatek/mt8183-pm-domains.h
>> index 8d996c5d2682d..aa5230e6c12f8 100644
>> --- a/drivers/soc/mediatek/mt8183-pm-domains.h
>> +++ b/drivers/soc/mediatek/mt8183-pm-domains.h
>> @@ -38,6 +38,7 @@ static const struct scpsys_domain_data 
>> scpsys_domain_data_mt8183[] = {
>> .ctl_offs = 0x0338,
>> .sram_pdn_bits = GENMASK(8, 8),
>> .sram_pdn_ack_bits = GENMASK(12, 12),
>> +   .caps = MTK_SCPD_DOMAIN_SUPPLY,
>> },
>> [MT8183_POWER_DOMAIN_MFG_CORE0] = {
>> .sta_mask = BIT(7),
>> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
>> b/drivers/soc/mediatek/mtk-pm-domains.c
>> index fb70cb3b07b36..ae255aa7b1a97 100644
>> --- a/drivers/soc/mediatek/mtk-pm-domains.c
>> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> [snip]
>> @@ -275,6 +295,7 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
>> *scpsys, struct device_no
>>  {
>> const struct scpsys_domain_data *domain_data;
>> struct scpsys_domain *pd;
>> +   struct device_node *np = scpsys->dev->of_node;
>> struct property *prop;
>> const char *clk_name;
>> int i, ret, num_clks;
>> @@ -307,6 +328,19 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
>> *scpsys, struct device_no
>> pd->data = domain_data;
>> pd->scpsys = scpsys;
>>
>> +   if (MTK_SCPD_CAPS(pd, MTK_SCPD_DOMAIN_SUPPLY)) {
>> +   /* Find regulator in current power domain node */
>> +   scpsys->dev->of_node = node;
>> +   pd->supply = devm_regulator_get(scpsys->dev, "domain");
>> +   scpsys->dev->of_node = np;
> 
> This pattern is a bit strange to me. But Hsin-Yi pointed out that
> there are precedents:
> https://elixir.bootlin.com/linux/v5.11-rc2/source/drivers/iio/adc/rcar-gyroadc.c#L397
> .

nit: Strange to me too. Maybe it needs a better comment/explanation and/or use
child/parent as a temporal of_node names to make a bit more readable. Looks like
[devm_]regulator_get only accepts a device as argument and will look into child
nodes.


> 
>> +   if (IS_ERR(pd->supply)) {
>> +   dev_err_probe(scpsys->dev, PTR_ERR(pd->supply),
>> + "%pOF: failed to get power supply.\n",
>> + node);
>> +   return ERR_CAST(pd->supply);
>> +   }
>> +   }
>> +
>> pd->infracfg = syscon_regmap_lookup_by_phandle_optional(node, 
>> "mediatek,infracfg");
>> if (IS_ERR(pd->infracfg))
>> return ERR_CAST(pd->infracfg);
>> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
>> b/drivers/soc/mediatek/mtk-pm-domains.h
>> index a2f4d8f97e058..b2770b5266dba 100644
>> --- a/drivers/soc/mediatek/mtk-pm-domains.h
>> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
>> @@ -7,6 +7,7 @@
>>  #define MTK_SCPD_FWAIT_SRAMBIT(1)
>>  #define MTK_SCPD_SRAM_ISO  BIT(2)
>>  #define MTK_SCPD_KEEP_DEFAULT_OFF  BIT(3)
>> +#define MTK_SCPD_DOMAIN_SUPPLY BIT(4)
>>  #define MTK_SCPD_CAPS(_scpd, _x)   ((_scpd)->data->caps & (_x))
>>
>>  #define SPM_VDE_PWR_CON0x0210
>> --
>> 2.29.2.729.g45daf8777d-goog
>>
>>
>> ___
>> Linux-mediatek mailing list
>> linux-media...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-mediatek


[PATCH] soc: mediatek: pm-domains: Don't print an error if child domain is deferred

2021-01-13 Thread Enric Balletbo i Serra
Child domains can be deferred by the core because one of its resources
is not available yet, in such case, it will print an error, but
later it will succeed to probe. Fix that using the dev_err_probe()
function so it only prints an error on a real error.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/mtk-pm-domains.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index ae255aa7b1a9..8055fb019ba6 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -480,8 +480,8 @@ static int scpsys_add_subdomain(struct scpsys *scpsys, 
struct device_node *paren
 
child_pd = scpsys_add_one_domain(scpsys, child);
if (IS_ERR(child_pd)) {
-   ret = PTR_ERR(child_pd);
-   dev_err(scpsys->dev, "%pOF: failed to get child domain 
id\n", child);
+   dev_err_probe(scpsys->dev, PTR_ERR(child_pd),
+ "%pOF: failed to get child domain id\n", 
child);
goto err_put_node;
}
 
-- 
2.29.2



[PATCH] arm64: dts: mt8183: Add missing power-domain for pwm0 node

2021-01-13 Thread Enric Balletbo i Serra
The MT8183 display PWM device will not work until the associated
power-domain is enabled. Add the power-domain reference to the node
allows the display PWM driver to operate and the backlight turn on.

Fixes: f15722c0fef0 ("arm64: dts: mt8183: Add pwm and backlight node")
Signed-off-by: Enric Balletbo i Serra 
---

 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 bda283fa9245..8471c973dfd5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -661,6 +661,7 @@ pwm0: pwm@1100e000 {
compatible = "mediatek,mt8183-disp-pwm";
reg = <0 0x1100e000 0 0x1000>;
interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
#pwm-cells = <2>;
clocks = < CLK_TOP_MUX_DISP_PWM>,
< CLK_INFRA_DISP_PWM>;
-- 
2.29.2



Re: [PATCH 1/3] dt-bindings: power: Add domain regulator supply

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for the patch.

On 7/1/21 11:49, Hsin-Yi Wang wrote:
> Some power domains (eg. mfg) needs to turn on power supply before power
> on.
> 
> Signed-off-by: Hsin-Yi Wang 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  .../bindings/power/mediatek,power-controller.yaml| 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
> b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> index d14cb9bac8497..e529586af5a12 100644
> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> @@ -82,6 +82,9 @@ patternProperties:
>be specified by order, adding first the BASIC clocks followed by 
> the
>SUSBSYS clocks.
>  
> +  domain-supply:
> +description: domain regulator supply.
> +
>mediatek,infracfg:
>  $ref: /schemas/types.yaml#/definitions/phandle
>  description: phandle to the device containing the INFRACFG register 
> range.
> @@ -130,6 +133,9 @@ patternProperties:
>be specified by order, adding first the BASIC clocks followed 
> by the
>SUSBSYS clocks.
>  
> +  domain-supply:
> +description: domain regulator supply.
> +
>mediatek,infracfg:
>  $ref: /schemas/types.yaml#/definitions/phandle
>  description: phandle to the device containing the INFRACFG 
> register range.
> @@ -178,6 +184,9 @@ patternProperties:
>be specified by order, adding first the BASIC clocks 
> followed by the
>SUSBSYS clocks.
>  
> +  domain-supply:
> +description: domain regulator supply.
> +
>mediatek,infracfg:
>  $ref: /schemas/types.yaml#/definitions/phandle
>  description: phandle to the device containing the INFRACFG 
> register range.
> 


Re: [PATCH v4 3/3] dt-bindings: arm64: dts: mediatek: Add krane sku0

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

On 13/1/21 12:04, Hsin-Yi Wang wrote:
> Krane-sku0 is similar to krane-sku176 but using a different panel
> source.
> 
> Signed-off-by: Hsin-Yi Wang 

Reviewed-by: Enric Balletbo i Serra 

> ---
>  Documentation/devicetree/bindings/arm/mediatek.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml 
> b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 53f0d4e3ea982..93b3bdf6eaeb7 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -120,7 +120,9 @@ properties:
>- const: mediatek,mt8183
>- description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
>  items:
> -  - const: google,krane-sku176
> +  - enum:
> +  - google,krane-sku0
> +  - google,krane-sku176
>- const: google,krane
>- const: mediatek,mt8183
>  
> 


Re: [PATCH v4 1/3] arm64: dts: mt8183: config dsi node

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

On 13/1/21 12:03, Hsin-Yi Wang wrote:
> Config dsi node for mt8183 kukui. Set panel and ports.
> 
> Several kukui boards share the same panel property and only compatible
> is different. So compatible will be set in board dts for comparison
> convenience.
> 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Nicolas Boichat 

Tested on my Lenovo Ideapad Duet. Display is working.

Tested-by: Enric Balletbo i Serra 

> ---
> change:
> v4: add backlight and enable mipi_tx0
> ---
>  .../mediatek/mt8183-kukui-krane-sku176.dts|  5 +++
>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 42 +++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> index 47113e275cb52..721d16f9c3b4f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> @@ -16,3 +16,8 @@ / {
>   model = "MediaTek krane sku176 board";
>   compatible = "google,krane-sku176", "google,krane", "mediatek,mt8183";
>  };
> +
> + {
> +status = "okay";
> +compatible = "boe,tv101wum-nl6";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index bf2ad1294dd30..da1e947587074 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -249,6 +249,36 @@  {
>   proc-supply = <_vproc11_reg>;
>  };
>  
> + {
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel: panel@0 {
> + /* compatible will be set in board dts */
> + reg = <0>;
> + enable-gpios = < 45 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> + avdd-supply = <_lcd>;
> + avee-supply = <_lcd>;
> + pp1800-supply = <_lcd>;
> + backlight = <_lcd0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + ports {
> + port {
> + dsi_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> @@ -290,6 +320,10 @@  {
>   clock-frequency = <10>;
>  };
>  
> +_tx0 {
> + status = "okay";
> +};
> +
>   {
>   status = "okay";
>   pinctrl-names = "default", "state_uhs";
> @@ -547,6 +581,14 @@ pins_clk {
>   };
>   };
>  
> + panel_pins_default: panel_pins_default {
> + panel_reset {
> + pinmux = ;
> + output-low;
> + bias-pull-up;
> + };
> + };
> +
>   pwm0_pin_default: pwm0_pin_default {
>   pins1 {
>   pinmux = ;
> 


Re: [PATCH v3 2/2] arm64: dts: mt8183: Add krane-sku0 board.

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for your patch.

On 13/1/21 7:28, Hsin-Yi Wang wrote:
> Similar to krane-sku176 but using a different panel source.
> 
> Signed-off-by: Hsin-Yi Wang 
> ---
> change:
> v3: fix yaml
> ---
>  .../devicetree/bindings/arm/mediatek.yaml |  4 +++-

I think the binding should be a separate patch? (Rob to confirm). Other than 
that.

Reviewed-by: Enric Balletbo i Serra 

>  arch/arm64/boot/dts/mediatek/Makefile |  1 +
>  .../dts/mediatek/mt8183-kukui-krane-sku0.dts  | 23 +++
>  3 files changed, 27 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml 
> b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 53f0d4e3ea982..93b3bdf6eaeb7 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -120,7 +120,9 @@ properties:
>- const: mediatek,mt8183
>- description: Google Krane (Lenovo IdeaPad Duet, 10e,...)
>  items:
> -  - const: google,krane-sku176
> +  - enum:
> +  - google,krane-sku0
> +  - google,krane-sku176
>- const: google,krane
>- const: mediatek,mt8183
>  
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 18f7b46c4095b..deba27ab76574 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-krane-sku0.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-kukui-krane-sku176.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8192-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8516-pumpkin.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
> new file mode 100644
> index 0..fb5ee91b6fe0e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright 2019 Google LLC
> + *
> + * Device-tree for Krane sku0.
> + *
> + * SKU is a 8-bit value (0x00 == 0):
> + *  - Bits 7..4: Panel ID: 0x0 (AUO)
> + *  - Bits 3..0: SKU ID:   0x0 (default)
> + */
> +
> +/dts-v1/;
> +#include "mt8183-kukui-krane.dtsi"
> +
> +/ {
> + model = "MediaTek krane sku0 board";
> + compatible = "google,krane-sku0", "google,krane", "mediatek,mt8183";
> +};
> +
> + {
> + status = "okay";
> + compatible = "auo,kd101n80-45na";
> +};
> 


Re: [PATCH v3 1/2] arm64: dts: mt8183: config dsi node

2021-01-13 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for the patch.

On 13/1/21 7:28, Hsin-Yi Wang wrote:
> Config dsi node for mt8183 kukui. Set panel and ports.
> 
> Several kukui boards share the same panel property and only compatible
> is different. So compatible will be set in board dts for comparison
> convenience.
> 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Nicolas Boichat 
> ---
>  .../mediatek/mt8183-kukui-krane-sku176.dts|  5 +++
>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 37 +++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> index 47113e275cb52..721d16f9c3b4f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> @@ -16,3 +16,8 @@ / {
>   model = "MediaTek krane sku176 board";
>   compatible = "google,krane-sku176", "google,krane", "mediatek,mt8183";
>  };
> +
> + {
> +status = "okay";
> +compatible = "boe,tv101wum-nl6";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index bf2ad1294dd30..c5f41b94f154e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -249,6 +249,35 @@  {
>   proc-supply = <_vproc11_reg>;
>  };
>  
> + {
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel: panel@0 {
> + /* compatible will be set in board dts */
> + reg = <0>;
> + enable-gpios = < 45 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> + avdd-supply = <_lcd>;
> + avee-supply = <_lcd>;
> + pp1800-supply = <_lcd>;

It'd make sense to add also the backlight here?

+   backlight = <_lcd0>;

> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> +
> + ports {
> + port {
> + dsi_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +

I think you should enable the MIPI TX to have DSI and panel working?

+_tx0 {
+   status = "okay";
+};


>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> @@ -547,6 +576,14 @@ pins_clk {
>   };
>   };
>  
> + panel_pins_default: panel_pins_default {
> + panel_reset {
> + pinmux = ;
> + output-low;
> + bias-pull-up;
> + };
> + };
> +
>   pwm0_pin_default: pwm0_pin_default {
>   pins1 {
>   pinmux = ;
> 


Re: [PATCH v5] ASoC: cros_ec_codec: Reset I2S RX when probing

2021-01-13 Thread Enric Balletbo i Serra
Hi Yu-Hsun,

Thank you for your patch. Some comments below.


On 13/1/21 9:17, Yu-Hsuan Hsu wrote:
> It is not guaranteed that I2S RX is disabled when the kernel booting.
> For example, if the kernel crashes while it is enabled, it will keep
> enabled until the next time EC reboots. Reset I2S RX when probing to
> fix this issue.
> 
> Signed-off-by: Yu-Hsuan Hsu 
> ---
> This patch checks the return value. If it is -ENOPROTOOPT
> (EC_RES_INVALID_VERSION), it will ask clients to update EC firmware.
> 
> Previous patches
> 
> v1: 
> https://patchwork.kernel.org/project/alsa-devel/patch/20200708071117.3070707-1-yuhs...@chromium.org/
> 
> v2: 
> https://patchwork.kernel.org/project/alsa-devel/patch/20200716170914.3623060-1-yuhs...@chromium.org/
> 
> v3: 
> https://patchwork.kernel.org/project/alsa-devel/patch/20210106050559.1459027-1-yuhs...@chromium.org/
> 
> v4: 
> https://patchwork.kernel.org/project/alsa-devel/patch/20210107085942.2891525-2-yuhs...@chromium.org/
> 
>  include/linux/platform_data/cros_ec_commands.h |  1 +

Sorry if I confused you with my last comments, but this should be a separate 
patch.

>  sound/soc/codecs/cros_ec_codec.c   | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/include/linux/platform_data/cros_ec_commands.h 
> b/include/linux/platform_data/cros_ec_commands.h
> index 86376779ab31..95889ada83a3 100644
> --- a/include/linux/platform_data/cros_ec_commands.h
> +++ b/include/linux/platform_data/cros_ec_commands.h
> @@ -4600,6 +4600,7 @@ enum ec_codec_i2s_rx_subcmd {
>   EC_CODEC_I2S_RX_SET_SAMPLE_DEPTH = 0x2,
>   EC_CODEC_I2S_RX_SET_DAIFMT = 0x3,
>   EC_CODEC_I2S_RX_SET_BCLK = 0x4,
> + EC_CODEC_I2S_RX_RESET = 0x5,
>   EC_CODEC_I2S_RX_SUBCMD_COUNT,
>  };
>  
> diff --git a/sound/soc/codecs/cros_ec_codec.c 
> b/sound/soc/codecs/cros_ec_codec.c
> index f33a2a9654e7..d35c57724b45 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -1011,6 +1011,17 @@ static int cros_ec_codec_platform_probe(struct 
> platform_device *pdev)
>   }
>   priv->ec_capabilities = r.capabilities;
>  
> + /* Reset EC codec i2s rx. */
> + p.cmd = EC_CODEC_I2S_RX_RESET;
> + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX,
> +(uint8_t *), sizeof(p), NULL, 0);
> + if (ret == -ENOPROTOOPT) {
> + dev_info(dev,
> +  "Command not found. Please update the EC firmware.\n");
> + } else if (ret) {
> + dev_err(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret);

On an error you should return the error and don't continue.

Thanks,
  Enric

> + }
> +
>   platform_set_drvdata(pdev, priv);
>  
>   ret = devm_snd_soc_register_component(dev, _rx_component_driver,
> 


Re: [PATCH 1/2] cros_ec_commands: Add EC_CODEC_I2S_RX_RESET

2021-01-12 Thread Enric Balletbo i Serra
Hi,

On 12/1/21 15:10, Mark Brown wrote:
> On Mon, Jan 11, 2021 at 05:52:31PM -0800, Guenter Roeck wrote:
>> On Mon, Jan 11, 2021 at 4:42 PM Mark Brown  wrote:
> 
>>> TBH that seems like a big enough change to split out from this and done
>>> as a separate series, I'd be perfectly happy to apply your original
>>> change.  I guess part of doing that sync up should ideally be to
>>> refactor things so that it can be done mechanically in future.
> 
>> Being able to do it mechanically was the idea for introducing the script.
>> Unfortunately it doesn't help to have such a script if people don't use it.
> 
> Looking at the issues Yu-Hsuan mentions and briefly at the code I guess
> there's some updates needed with the script for namespacing around at
> least pd_ to avoid the need for hand massaging things, that'll put
> people off using the script.
> 

I even didn't know about that script :-(, or forget about it, assuming the files
are async again, I think I'm fine on only introduce that line of code instead of
a full sync (and lets think how we can do better work on this and solve in the
chrome-platform tree). I have some comments on patch 2, though.

Cheers,
  Enric


Re: [PATCH 2/2] ASoC: cros_ec_codec: Reset I2S RX when probing

2021-01-12 Thread Enric Balletbo i Serra
Hi Yu-Hsuan,

Thank you for the patch.

On 7/1/21 9:59, Yu-Hsuan Hsu wrote:
> It is not guaranteed that I2S RX is disabled when the kernel booting.
> For example, if the kernel crashes while it is enabled, it will keep
> enabled until the next time EC reboots. Reset I2S RX when probing to
> fix this issue.
> 
> Signed-off-by: Yu-Hsuan Hsu 

If I am not mistaken this is the four version of this patchset (see [1]). Please
prefix your patches with the proper version and maintain a changelog for them,
otherwise makes difficult to follow all the discussions already done.

[1]
v1: https://lkml.org/lkml/2020/7/8/173
v2: https://mailman.alsa-project.org/pipermail/alsa-devel/2020-July/170933.html
v3:
https://patchwork.kernel.org/project/alsa-devel/patch/20210106050559.1459027-1-yuhs...@chromium.org/
v4: https://patchwork.kernel.org/project/alsa-devel/list/?series=410441

> ---
>  sound/soc/codecs/cros_ec_codec.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/sound/soc/codecs/cros_ec_codec.c 
> b/sound/soc/codecs/cros_ec_codec.c
> index f33a2a9654e7..28b3e2c48c86 100644
> --- a/sound/soc/codecs/cros_ec_codec.c
> +++ b/sound/soc/codecs/cros_ec_codec.c
> @@ -1011,6 +1011,13 @@ static int cros_ec_codec_platform_probe(struct 
> platform_device *pdev)
>   }
>   priv->ec_capabilities = r.capabilities;
>  
> + /* Reset EC codec i2s rx. */
> + p.cmd = EC_CODEC_I2S_RX_RESET;
> + ret = send_ec_host_command(priv->ec_device, EC_CMD_EC_CODEC_I2S_RX,
> +(uint8_t *), sizeof(p), NULL, 0);
> + if (ret)
> + dev_warn(dev, "failed to EC_CODEC_I2S_RESET: %d\n", ret);
> +

My comment in the first version is still valid, I guess. This command was
introduced later and with an old firmware I suspect this message will appear on
every boot, right? So, to solve the issue and get rid of this warn you're forced
to upgrade the firmware. Would make sense to handle returned error value to warn
when the firmware needs to be updated and error and break when is really an 
error?

We have mapped ec error codes to linux error codes. So, it should be possible 
now.

Thanks,
 Enric

>   platform_set_drvdata(pdev, priv);
>  
>   ret = devm_snd_soc_register_component(dev, _rx_component_driver,
> 


Re: [PATCH 2/2] platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot.

2020-12-18 Thread Enric Balletbo i Serra
Hi Pi-Hsun,

Thank you for your patch. I don't accept patches with an empty commit
description. Can you add it? (maybe you could just explain more what cold-ap-off
means here. Apart from this, the patch LGTM.

Thanks,
  Enric


On 17/12/20 9:14, Pi-Hsun Shih wrote:
> Signed-off-by: Pi-Hsun Shih 
> ---
>  drivers/platform/chrome/cros_ec_sysfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_sysfs.c 
> b/drivers/platform/chrome/cros_ec_sysfs.c
> index f521a5c65091..8210fb10e839 100644
> --- a/drivers/platform/chrome/cros_ec_sysfs.c
> +++ b/drivers/platform/chrome/cros_ec_sysfs.c
> @@ -28,7 +28,7 @@ static ssize_t reboot_show(struct device *dev,
>   int count = 0;
>  
>   count += scnprintf(buf + count, PAGE_SIZE - count,
> -"ro|rw|cancel|cold|disable-jump|hibernate");
> +
> "ro|rw|cancel|cold|disable-jump|hibernate|cold-ap-off");
>   count += scnprintf(buf + count, PAGE_SIZE - count,
>  " [at-shutdown]\n");
>   return count;
> @@ -46,6 +46,7 @@ static ssize_t reboot_store(struct device *dev,
>   {"cancel",   EC_REBOOT_CANCEL, 0},
>   {"ro",   EC_REBOOT_JUMP_RO, 0},
>   {"rw",   EC_REBOOT_JUMP_RW, 0},
> + {"cold-ap-off",  EC_REBOOT_COLD_AP_OFF, 0},
>   {"cold", EC_REBOOT_COLD, 0},
>   {"disable-jump", EC_REBOOT_DISABLE_JUMP, 0},
>   {"hibernate",EC_REBOOT_HIBERNATE, 0},
> 


Re: [PATCH 2/2] platform/chrome: cros_ec_spi: Drop bits_per_word assignment

2020-12-04 Thread Enric Balletbo i Serra
Hi Stephen,

Thank you for your patch.

On 3/12/20 2:16, Stephen Boyd wrote:
> This is already handed by default in spi_setup() if the bits_per_word is
> 0, so just drop it to shave off a line.
> 
> Cc: Simon Glass 
> Cc: Gwendal Grignou 
> Cc: Douglas Anderson 
> Cc: Alexandru M Stan 
> Signed-off-by: Stephen Boyd 

Acked-by: Enric Balletbo i Serra 

> ---
>  drivers/platform/chrome/cros_ec_spi.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_spi.c 
> b/drivers/platform/chrome/cros_ec_spi.c
> index f9df218fc2bb..14c4046fa04d 100644
> --- a/drivers/platform/chrome/cros_ec_spi.c
> +++ b/drivers/platform/chrome/cros_ec_spi.c
> @@ -741,7 +741,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>   struct cros_ec_spi *ec_spi;
>   int err;
>  
> - spi->bits_per_word = 8;
>   spi->rt = true;
>   err = spi_setup(spi);
>   if (err < 0)
> 


Re: [PATCH 1/2] platform/chrome: cros_ec_spi: Don't overwrite spi::mode

2020-12-04 Thread Enric Balletbo i Serra
Hi Stephen,

Thank you for your patch.

On 3/12/20 2:16, Stephen Boyd wrote:
> There isn't any need to overwrite the mode here in the driver with what
> has been detected by the firmware, such as DT or ACPI. In fact, if we
> use the SPI CS gpio descriptor feature we will overwrite the mode with
> SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly
> SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle
> when the device is probed when it shouldn't change, confusing the driver
> and making it fail to probe. Drop the assignment and let the spi core
> take care of it.
> 
> Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver")
> Cc: Simon Glass 
> Cc: Gwendal Grignou 
> Cc: Douglas Anderson 
> Cc: Alexandru M Stan 
> Signed-off-by: Stephen Boyd 
> ---

Acked-by: Enric Balletbo i Serra 

>  drivers/platform/chrome/cros_ec_spi.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_spi.c 
> b/drivers/platform/chrome/cros_ec_spi.c
> index dfa1f816a45f..f9df218fc2bb 100644
> --- a/drivers/platform/chrome/cros_ec_spi.c
> +++ b/drivers/platform/chrome/cros_ec_spi.c
> @@ -742,7 +742,6 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>   int err;
>  
>   spi->bits_per_word = 8;
> - spi->mode = SPI_MODE_0;
>   spi->rt = true;
>   err = spi_setup(spi);
>   if (err < 0)
> 


Re: [PATCH] spi: spi-geni-qcom: Use the new method of gpio CS control

2020-12-04 Thread Enric Balletbo i Serra
Hi,

On 4/12/20 1:10, Stephen Boyd wrote:
> Quoting Doug Anderson (2020-12-03 12:06:10)
>> On Wed, Dec 2, 2020 at 4:47 PM Stephen Boyd  wrote:
>>>
>>> And that is wrong. With even more investigation and Doug's eagle eyes it
>>> seems that the cros-ec driver is overriding the spi::mode to clear out
>>> the SPI_CS_HIGH bit that the spi core sets in there when using the gpio
>>> descriptors. I'll send a patch for cros-ec-spi shortly.
>>
>> So do we need any coordinating here, are we OK w/ trogdor devices
>> being broken for a short period of time?
>>
>> I think the device tree changes switching to use GPIO for chip select
>> is already queued in linux-next.  That means if we land this patch
>> before the fix to cros_ec [1] then we'll end up in a broken state.
>> Would we be able to do some quick landing to get the cros-ec fix into
>> v5.10 and then target the SPI patch for 5.11?
> 
> I don't think it really matters if the two patches meet up in linux-next
> or cros-ec is fast tracked, but it would be bad if this patch was merged
> without the cros-ec one. One option would be to apply the cros-ec fix to
> the spi tree along with this patch (or vice versa) so that a bisection
> hole isn't created. Or this patch can wait for a while until cros-ec is
> fixed. I'm not the maintainer here so it's really up to Mark and
> Enric/Benson.
> 

I am fine either way. I'm fine with pick all the patches and go through the
chrome/platform tree if Mark is agree (I think this patch has no other
dependencies and the patch applies cleanly to my tree) or all can go through the
Mark's tree. If I need to an IB I can also do it without problems.

I'll leave Mark to decide who has much experience solving this kind of problems.

Thanks,
 Enric


>>
>> [1] https://lore.kernel.org/r/20201203011649.1405292-2-swb...@chromium.org/


[PATCH] soc: mediatek: mmsys: Specify HAS_IOMEM dependency for MTK_MMSYS

2020-12-03 Thread Enric Balletbo i Serra
Because mtk-mmsys uses the 'devm_platform_ioremap_resource' function, it
should depend on HAS_IOMEM.

Fixes: cc6576029aed ("soc: mediatek: mmsys: Use 
devm_platform_ioremap_resource()")
Reported-by: kernel test robot 
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/soc/mediatek/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 67cef12dc585..90ba6134e861 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -59,6 +59,7 @@ config MTK_SCPSYS_PM_DOMAINS
 config MTK_MMSYS
bool "MediaTek MMSYS Support"
default ARCH_MEDIATEK
+   depends on HAS_IOMEM
help
  Say yes here to add support for the MediaTek Multimedia
  Subsystem (MMSYS).
-- 
2.29.2



[PATCH] drm/mediatek: Use correct aliases name for ovl

2020-11-27 Thread Enric Balletbo i Serra
Aliases property name must include only lowercase and '-', so fix this
in the driver, so we're not tempted to do "ovl_2l0 = _2l0" in the
device-tree instead of the right one which is "ovl-2l0 = _2l0".

Fixes: dd8feb2262d9 ("drm/mediatek: add component OVL_2L1")
Fixes: b17bdd0d7a73 ("drm/mediatek: add component OVL_2L0")
Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8eba44be3a8a..3064eac1a750 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -359,7 +359,7 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
 
 static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_OVL] = "ovl",
-   [MTK_DISP_OVL_2L] = "ovl_2l",
+   [MTK_DISP_OVL_2L] = "ovl-2l",
[MTK_DISP_RDMA] = "rdma",
[MTK_DISP_WDMA] = "wdma",
[MTK_DISP_COLOR] = "color",
-- 
2.29.2



[PATCH 1/3] arm64: dts: mt8183: Add dsi node

2020-11-27 Thread Enric Balletbo i Serra
From: Jitao Shi 

Add dsi and mipitx nodes to the MT8183.

Signed-off-by: Jitao Shi 
Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 31 
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 7839480df075..da7212e21fdf 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -892,10 +892,27 @@ mmc1: mmc@1124 {
status = "disabled";
};
 
+   mipi_tx0: mipi-dphy@11e5 {
+   compatible = "mediatek,mt8183-mipi-tx";
+   reg = <0 0x11e5 0 0x1000>;
+   clocks = < CLK_APMIXED_MIPID0_26M>;
+   clock-names = "ref_clk";
+   #clock-cells = <0>;
+   #phy-cells = <0>;
+   clock-output-names = "mipi_tx0_pll";
+   nvmem-cells = <_tx_calibration>;
+   nvmem-cell-names = "calibration-data";
+   };
+
efuse: efuse@11f1 {
compatible = "mediatek,mt8183-efuse",
 "mediatek,efuse";
reg = <0 0x11f1 0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   mipi_tx_calibration: calib@190 {
+   reg = <0x190 0xc>;
+   };
};
 
u3phy: usb-phy@11f4 {
@@ -937,6 +954,20 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
 
+   dsi0: dsi@14014000 {
+   compatible = "mediatek,mt8183-dsi";
+   reg = <0 0x14014000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   mediatek,syscon-dsi = < 0x140>;
+   clocks = < CLK_MM_DSI0_MM>,
+< CLK_MM_DSI0_IF>,
+<_tx0>;
+   clock-names = "engine", "digital", "hs";
+   phys = <_tx0>;
+   phy-names = "dphy";
+   };
+
smi_common: smi@14019000 {
compatible = "mediatek,mt8183-smi-common", "syscon";
reg = <0 0x14019000 0 0x1000>;
-- 
2.29.2



[PATCH 3/3] arm64: dts: mt8183: Add display nodes for MT8183

2020-11-27 Thread Enric Balletbo i Serra
Add display subsystem device nodes to allow video output.

Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 114 +++
 1 file changed, 114 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index ba9ff192cda3..34d83f517b07 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,11 @@ aliases {
i2c9 = 
i2c10 = 
i2c11 = 
+   ovl0 = 
+   ovl-2l0 = _2l0;
+   ovl-2l1 = _2l1;
+   rdma0 = 
+   rdma1 = 
};
 
cpus {
@@ -964,6 +970,107 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
 
+   ovl0: ovl@14008000 {
+   compatible = "mediatek,mt8183-disp-ovl";
+   reg = <0 0x14008000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL0>;
+   iommus = < M4U_PORT_DISP_OVL0>;
+   mediatek,larb = <>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x8000 
0x1000>;
+   };
+
+   ovl_2l0: ovl@14009000 {
+   compatible = "mediatek,mt8183-disp-ovl-2l";
+   reg = <0 0x14009000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL0_2L>;
+   iommus = < M4U_PORT_DISP_2L_OVL0_LARB0>;
+   mediatek,larb = <>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x9000 
0x1000>;
+   };
+
+   ovl_2l1: ovl@1400a000 {
+   compatible = "mediatek,mt8183-disp-ovl-2l";
+   reg = <0 0x1400a000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL1_2L>;
+   iommus = < M4U_PORT_DISP_2L_OVL1_LARB0>;
+   mediatek,larb = <>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xa000 
0x1000>;
+   };
+
+   rdma0: rdma@1400b000 {
+   compatible = "mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400b000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_RDMA0>;
+   iommus = < M4U_PORT_DISP_RDMA0>;
+   mediatek,larb = <>;
+   mediatek,rdma_fifo_size = <5120>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xb000 
0x1000>;
+   };
+
+   rdma1: rdma@1400c000 {
+   compatible = "mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_RDMA1>;
+   iommus = < M4U_PORT_DISP_RDMA1>;
+   mediatek,larb = <>;
+   mediatek,rdma_fifo_size = <2048>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xc000 
0x1000>;
+   };
+
+   color0: color@1400e000 {
+   compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+   reg = <0 0x1400e000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_COLOR0>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xe000 
0x1000>;
+   };
+
+   ccorr0: ccorr@1400f000 {
+   compatible = "mediatek,mt8183-disp-ccorr";
+   reg = <0 0x1400f000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_CCORR0>;
+   };
+
+   aal0: aal@1401 {
+   compatible = "mediatek,mt8183-disp-aal",
+  

[PATCH 0/3] arm64: dts: mediatek: Add dsi and display support for MT8183 based boards

2020-11-27 Thread Enric Balletbo i Serra
Dear all,

The following patches add the required nodes to enable dsi and display
support for MT8183 based boards. The patches were tested on a Lenovo
Ideapad Duet with an out-of-tree patch that enables the display for that
board.

The patches depends on [1].

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013

Enric Balletbo i Serra (2):
  arm64: dts: mt8183: Add iommu and larb nodes
  arm64: dts: mt8183: Add display nodes for MT8183

Jitao Shi (1):
  arm64: dts: mt8183: Add dsi node

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 224 +++
 1 file changed, 224 insertions(+)

-- 
2.29.2



[PATCH 2/3] arm64: dts: mt8183: Add iommu and larb nodes

2020-11-27 Thread Enric Balletbo i Serra
Add iommu and larb nodes to the MT8183.

Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 79 
 1 file changed, 79 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index da7212e21fdf..ba9ff192cda3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -521,6 +522,15 @@ systimer: timer@10017000 {
clock-names = "clk13m";
};
 
+   iommu: iommu@10205000 {
+   compatible = "mediatek,mt8183-m4u";
+   reg = <0 0x10205000 0 0x1000>;
+   interrupts = ;
+   mediatek,larbs = <   
+   >;
+   #iommu-cells = <1>;
+   };
+
gce: mailbox@10238000 {
compatible = "mediatek,mt8183-gce";
reg = <0 0x10238000 0 0x4000>;
@@ -968,6 +978,16 @@ dsi0: dsi@14014000 {
phy-names = "dphy";
};
 
+   larb0: larb@14017000 {
+   compatible = "mediatek,mt8183-smi-larb";
+   reg = <0 0x14017000 0 0x1000>;
+   mediatek,smi = <_common>;
+   clocks = < CLK_MM_SMI_LARB0>,
+< CLK_MM_SMI_LARB0>;
+   power-domains = < MT8183_POWER_DOMAIN_DISP>;
+   clock-names = "apb", "smi";
+   };
+
smi_common: smi@14019000 {
compatible = "mediatek,mt8183-smi-common", "syscon";
reg = <0 0x14019000 0 0x1000>;
@@ -984,18 +1004,57 @@ imgsys: syscon@1502 {
#clock-cells = <1>;
};
 
+   larb5: larb@15021000 {
+   compatible = "mediatek,mt8183-smi-larb";
+   reg = <0 0x15021000 0 0x1000>;
+   mediatek,smi = <_common>;
+   clocks = < CLK_IMG_LARB5>, < 
CLK_IMG_LARB5>,
+< CLK_MM_GALS_IMG2MM>;
+   clock-names = "apb", "smi", "gals";
+   power-domains = < MT8183_POWER_DOMAIN_ISP>;
+   };
+
+   larb2: larb@1502f000 {
+   compatible = "mediatek,mt8183-smi-larb";
+   reg = <0 0x1502f000 0 0x1000>;
+   mediatek,smi = <_common>;
+   clocks = < CLK_IMG_LARB2>, < 
CLK_IMG_LARB2>,
+< CLK_MM_GALS_IPU2MM>;
+   clock-names = "apb", "smi", "gals";
+   power-domains = < MT8183_POWER_DOMAIN_ISP>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt8183-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb1: larb@1601 {
+   compatible = "mediatek,mt8183-smi-larb";
+   reg = <0 0x1601 0 0x1000>;
+   mediatek,smi = <_common>;
+   clocks = < CLK_VDEC_VDEC>, < 
CLK_VDEC_LARB1>;
+   clock-names = "apb", "smi";
+   power-domains = < MT8183_POWER_DOMAIN_VDEC>;
+   };
+
vencsys: syscon@1700 {
compatible = "mediatek,mt8183-vencsys", "syscon";
reg = <0 0x1700 0 0x1000>;
#clock-cells = <1>;
};
 
+   larb4: larb@1701 {
+   compatible = "mediatek,mt8183-smi-larb";
+   reg = <0 0x1701 0 0x1000>;
+   mediatek,smi = <_common>;
+   clocks = < CLK_VENC_LARB>,
+< CLK_VENC_LARB>;
+   clock-names = "apb", "smi";
+   power-domains = < MT8183_POWER_DOMAIN_VENC>;
+   };
+
ipu_conn: syscon@1900 {
compatible = "mediatek,mt8183-ipu_conn", "syscon";
reg = <0 0x19

Re: [PATCH v4 01/16] dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains controller

2020-11-27 Thread Enric Balletbo i Serra
Hi Weiyi,

On 27/11/20 3:24, Weiyi Lu wrote:
> On Fri, 2020-10-30 at 12:36 +0100, Enric Balletbo i Serra wrote:
>> The System Control Processor System (SCPSYS) has several power management
>> related tasks in the system. Add the bindings to define the power
>> domains for the SCPSYS power controller.
>>
>> Co-developed-by: Matthias Brugger 
>> Signed-off-by: Matthias Brugger 
>> Signed-off-by: Enric Balletbo i Serra 
>> Reviewed-by: Rob Herring 
>> ---
>>
>> Changes in v4:
>> - Fix indentation warnings reported by yamllint
>>
>> Changes in v3:
>> - Use hex for unit-addresses.
>> - Define child nodes for nested power domains even are duplicated, but
>>   more clear than adding a regex scaped to be a valid URI.
>>
>> Changes in v2:
>> - Use generic node names (power-domain).
>> - Define valid values for common properties like #power-domain-cells.
>>
>>  .../power/mediatek,power-controller.yaml  | 289 ++
>>  1 file changed, 289 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
>> b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> new file mode 100644
>> index ..73b8988bd063
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
>> @@ -0,0 +1,289 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/power/mediatek,power-controller.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Mediatek Power Domains Controller
>> +
>> +maintainers:
>> +  - Weiyi Lu 
>> +  - Matthias Brugger 
>> +
>> +description: |
>> +  Mediatek processors include support for multiple power domains which can 
>> be
>> +  powered up/down by software based on different application scenes to save 
>> power.
>> +
>> +  IP cores belonging to a power domain should contain a 'power-domains'
>> +  property that is a phandle for SCPSYS node representing the domain.
>> +
>> +properties:
>> +  $nodename:
>> +const: power-controller
>> +
>> +  compatible:
>> +enum:
>> +  - mediatek,mt8173-power-controller
>> +
>> +  '#power-domain-cells':
>> +const: 1
>> +
>> +  '#address-cells':
>> +const: 1
>> +
>> +  '#size-cells':
>> +const: 0
>> +
>> +patternProperties:
>> +  "^power-domain@[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.
>> +
>> +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/mt8173-power.h" - for MT8173 type 
>> power domain.
>> +maxItems: 1
>> +
>> +  clocks:
>> +description: |
>> +  A number of phandles to clocks that need to be enabled during 
>> domain
>> +  power-up sequencing.
>> +
>> +  clock-names:
>> +description: |
>> +  List of names of clocks, in order to match the power-up sequencing
>> +  for each power domain we need to group the clocks by name. BASIC
>> +  clocks need to be enabled before enabling the corresponding power
>> +  domain, and should not have a '-' in their name (i.e mm, mfg, 
>> venc).
>> +  SUSBYS clocks need to be enabled before releasing the bus 
>> protection,
>> +  and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
>> +
>> +  In order to follow properly the power-up sequencing, the clocks 
>> must
>> +  be specified by order, adding first the BASIC clocks followed by 
>> the
>> +  SUSBSYS clocks.
>> +
>> +  mediatek,infracfg:
>> +$

Re: [PATCH] arm64: dts: mt8183: Add pwm and backlight node

2020-11-25 Thread Enric Balletbo i Serra
Hi Hsin-Yi,

Thank you for your patch.

On 24/11/20 5:12, Hsin-Yi Wang wrote:
> Add pwm to mt8183 and backlight to mt8183-kukui.
> 
> Signed-off-by: Hsin-Yi Wang 
> ---

Picked the patch and checked that pwm for the backlight is working as expected
on my Lenovo Ideapad Duet.

Tested-by: Enric Balletbo i Serra 

>  .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 28 +++
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 10 +++
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> index 85f7c33ba4461..bf2ad1294dd30 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> @@ -19,6 +19,17 @@ chosen {
>   stdout-path = "serial0:115200n8";
>   };
>  
> + backlight_lcd0: backlight_lcd0 {
> + compatible = "pwm-backlight";
> + pwms = < 0 50>;
> + power-supply = <_pp5000>;
> + enable-gpios = < 176 0>;
> + brightness-levels = <0 1023>;
> + num-interpolated-steps = <1023>;
> + default-brightness-level = <576>;
> + status = "okay";
> + };
> +
>   memory@4000 {
>   device_type = "memory";
>   reg = <0 0x4000 0 0x8000>;
> @@ -536,6 +547,17 @@ pins_clk {
>   };
>   };
>  
> + pwm0_pin_default: pwm0_pin_default {
> + pins1 {
> + pinmux = ;
> + output-high;
> + bias-pull-up;
> + };
> + pins2 {
> + pinmux = ;
> + };
> + };
> +
>   scp_pins: scp {
>   pins_scp_uart {
>   pinmux = ,
> @@ -670,6 +692,12 @@ pins_wifi_wakeup {
>   };
>  };
>  
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin_default>;
> +};
> +
>   {
>   status = "okay";
>   pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index 08a914d3a6435..a974bad899365 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -479,6 +479,16 @@ spi0: spi@1100a000 {
>   status = "disabled";
>   };
>  
> + pwm0: pwm@1100e000 {
> + compatible = "mediatek,mt8183-disp-pwm";
> + reg = <0 0x1100e000 0 0x1000>;
> + interrupts = ;
> + #pwm-cells = <2>;
> + clocks = < CLK_TOP_MUX_DISP_PWM>,
> + < CLK_INFRA_DISP_PWM>;
> + clock-names = "main", "mm";
> + };
> +
>   i2c3: i2c@1100f000 {
>   compatible = "mediatek,mt8183-i2c";
>   reg = <0 0x1100f000 0 0x1000>,
> 


Re: [PATCH v2 6/8] platform/chrome: cros_ec_typec: Use Thunderbolt 3 cable discover mode VDO in USB4 mode

2020-11-17 Thread Enric Balletbo i Serra



On 13/11/20 21:25, Utkarsh Patel wrote:
> Configure Thunderbolt3/USB4 cable generation value by filing Thunderbolt 3
> cable discover mode VDO to support rounded and non-rounded Thunderbolt3/
> USB4 cables.
> While we are here use Thunderbolt 3 cable discover mode VDO to fill active
> cable plug link training value.
> 
> Suggested-by: Heikki Krogerus 
> Signed-off-by: Utkarsh Patel 

Acked-by: Enric Balletbo i Serra 

> 
> --
> Changes in v2:
> - No change.
> --
> ---
>  drivers/platform/chrome/cros_ec_typec.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
> b/drivers/platform/chrome/cros_ec_typec.c
> index 8111ed1fc574..b7416e82c3b3 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -514,8 +514,18 @@ static int cros_typec_enable_usb4(struct cros_typec_data 
> *typec,
>   else if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_CABLE)
>   data.eudo |= EUDO_CABLE_TYPE_RE_TIMER << EUDO_CABLE_TYPE_SHIFT;
>  
> - data.active_link_training = !!(pd_ctrl->control_flags &
> -USB_PD_CTRL_ACTIVE_LINK_UNIDIR);
> + /*
> +  * This driver does not have access to the identity information or
> +  * capabilities of the cable, so we don't know is it a real USB4 or
> +  * TBT3 cable. Therefore pretending that it's always TBT3 cable by
> +  * filling the TBT3 Cable VDO.
> +  */
> + data.tbt_cable_vdo = TBT_MODE;
> +
> + if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
> + data.tbt_cable_vdo |= TBT_CABLE_LINK_TRAINING;
> +
> + data.tbt_cable_vdo |= TBT_SET_CABLE_ROUNDED(pd_ctrl->cable_gen);
>  
>   port->state.alt = NULL;
>   port->state.data = 
> 


Re: [PATCH v2 2/8] platform/chrome: cros_ec_typec: Correct the Thunderbolt rounded/non-rounded cable support

2020-11-17 Thread Enric Balletbo i Serra



On 13/11/20 21:24, Utkarsh Patel wrote:
> Thunderbolt rounded/non-rounded cable support is two bits value. Correcting
> it as per the Thunderbolt 3 cable discover mode VDO changes done in the
> Thunderbolt 3 alternate mode header.
> 
> Signed-off-by: Utkarsh Patel 

Acked-by: Enric Balletbo i Serra 

> --
> Changes in v2:
> - Removed the fixes tag as there is no functional implication.
> --
> ---
>  drivers/platform/chrome/cros_ec_typec.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
> b/drivers/platform/chrome/cros_ec_typec.c
> index 31be31161350..8111ed1fc574 100644
> --- a/drivers/platform/chrome/cros_ec_typec.c
> +++ b/drivers/platform/chrome/cros_ec_typec.c
> @@ -438,8 +438,7 @@ static int cros_typec_enable_tbt(struct cros_typec_data 
> *typec,
>   if (pd_ctrl->control_flags & USB_PD_CTRL_ACTIVE_LINK_UNIDIR)
>   data.cable_mode |= TBT_CABLE_LINK_TRAINING;
>  
> - if (pd_ctrl->cable_gen)
> - data.cable_mode |= TBT_CABLE_ROUNDED;
> + data.cable_mode |= TBT_SET_CABLE_ROUNDED(pd_ctrl->cable_gen);
>  
>   /* Enter Mode VDO */
>   data.enter_vdo = TBT_SET_CABLE_SPEED(pd_ctrl->cable_speed);
> 


Re: [PATCH v2 0/7] platform/chrome: cros_ec_typec: Register partner PD information

2020-11-13 Thread Enric Balletbo i Serra
On Thu, 29 Oct 2020 15:27:28 -0700, Prashant Malani wrote:
> This series adds support to retrieve Type C PD(Power Delivery) Discovery
> information from the Chrome OS EC, and register this information with
> the Type C connector class framework.
> 
> There are also a couple of patches which fix minor bugs with the
> existing cros-ec-typec driver.
> 
> [...]

Applied, thanks!

[1/7] platform/chrome: cros_ec_typec: Relocate set_port_params_v*() functions
  commit: 0498710be002b35bcb43895c4133a4c4bbfd837e
[2/7] platform/chrome: cros_ec_typec: Fix remove partner logic
  commit: 7ab5a673f4ce65875c76e9812d2e6da063b87fb7
[3/7] platform/chrome: cros_ec_typec: Clear partner identity on device removal
  commit: 514acf1cefd020eb21d7c180050a8d66b723d2d8
[4/7] platform/chrome: cros_ec: Import Type C host commands
  commit: cd2c40ff90b0e385c18f881ab5e17f7137864223
[5/7] platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS
  commit: 80f8cef60d79f23c02e546ba3de2fce84d5e8bdb
[6/7] platform/chrome: cros_ec_typec: Parse partner PD ID VDOs
  commit: f6f668118918f533676e51f3214f5a104562b59c
[7/7] platform/chrome: cros_ec_typec: Register partner altmodes
  commit: de0f49487db3667f5204dcec6d3482c9bd1a0a30

Best regards,
-- 
Enric Balletbo i Serra 


Re: [PATCH] platform/chrome: Don't treat RTC events as wakeup sources

2020-11-13 Thread Enric Balletbo i Serra
On Fri, 30 Oct 2020 16:25:23 -0700, Stephen Boyd wrote:
> The EC sends an RTC host event when the RTC fires, but we don't need to
> treat that as a wakeup event here. The RTC class already properly
> handles activating and deactivating a wakeup source in rtc_update_irq()
> by calling pm_stay_awake() at the start of processing and pm_relax()
> once all expired RTC timers have been processed. This reduces one wakeup
> increment but not much else. I noticed this while debugging RTC wakeups
> and how they always incremented the wakeup count by two instead of one
> because this is duplicated.

Applied, thanks!

[1/1] platform/chrome: Don't treat RTC events as wakeup sources
  commit: 853c1a789f5fe8e783586a5c2dcc2ad1b57ac20f

Best regards,
-- 
Enric Balletbo i Serra 


[PATCH v2] mfd: syscon: Add syscon_regmap_lookup_by_phandle_optional() function.

2020-11-10 Thread Enric Balletbo i Serra
This adds syscon_regmap_lookup_by_phandle_optional() function to get an
optional regmap.

It behaves the same as syscon_regmap_lookup_by_phandle() except where
there is no regmap phandle. In this case, instead of returning -ENODEV,
the function returns NULL. This makes error checking simpler when the
regmap phandle is optional.

Suggested-by: Nicolas Boichat 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Matthias Brugger 
---

Changes in v2:
- Add Matthias r-b tag.
- Add the explanation from the patch description to the code.
- Return NULL instead of -ENOTSUPP when regmap helpers are not enabled.

 drivers/mfd/syscon.c   | 18 ++
 include/linux/mfd/syscon.h | 11 +++
 2 files changed, 29 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index ca465794ea9c..c6f139b2e0c0 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -255,6 +255,24 @@ struct regmap *syscon_regmap_lookup_by_phandle_args(struct 
device_node *np,
 }
 EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_args);
 
+/*
+ * It behaves the same as syscon_regmap_lookup_by_phandle() except where
+ * there is no regmap phandle. In this case, instead of returning -ENODEV,
+ * the function returns NULL.
+ */
+struct regmap *syscon_regmap_lookup_by_phandle_optional(struct device_node *np,
+   const char *property)
+{
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_phandle(np, property);
+   if (IS_ERR(regmap) && PTR_ERR(regmap) == -ENODEV)
+   return NULL;
+
+   return regmap;
+}
+EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle_optional);
+
 static int syscon_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
diff --git a/include/linux/mfd/syscon.h b/include/linux/mfd/syscon.h
index 7f20e9b502a5..fecc2fa2a364 100644
--- a/include/linux/mfd/syscon.h
+++ b/include/linux/mfd/syscon.h
@@ -28,6 +28,9 @@ extern struct regmap *syscon_regmap_lookup_by_phandle_args(
const char *property,
int arg_count,
unsigned int *out_args);
+extern struct regmap *syscon_regmap_lookup_by_phandle_optional(
+   struct device_node *np,
+   const char *property);
 #else
 static inline struct regmap *device_node_to_regmap(struct device_node *np)
 {
@@ -59,6 +62,14 @@ static inline struct regmap 
*syscon_regmap_lookup_by_phandle_args(
 {
return ERR_PTR(-ENOTSUPP);
 }
+
+static inline struct regmap *syscon_regmap_lookup_by_phandle_optional(
+   struct device_node *np,
+   const char *property)
+{
+   return NULL;
+}
+
 #endif
 
 #endif /* __LINUX_MFD_SYSCON_H__ */
-- 
2.28.0



Re: [PATCH v2 2/2] platform/chrome: cros_ec_typec: Set partner num_altmodes

2020-11-10 Thread Enric Balletbo i Serra
Hi,

On 10/11/20 11:50, Heikki Krogerus wrote:
> On Mon, Nov 09, 2020 at 10:15:36PM -0800, Prashant Malani wrote:
>> Set the number of altmodes available for a registered partner using the
>> Type C connector class framework routine.
>>
>> Signed-off-by: Prashant Malani 
> 
> Reviewed-by: Heikki Krogerus 
> 

Acked-by: Enric Balletbo i Serra 

Heikki, would you like to take these two through your tree? It'd help if you can
create an inmutable branch so I can pick other cros_ec_typec patches on top of 
it.

Thanks,
 Enric

>> ---
>>
>> Changes in v2:
>> - Patch introduced for the first time in v2.
>>
>>  drivers/platform/chrome/cros_ec_typec.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/platform/chrome/cros_ec_typec.c 
>> b/drivers/platform/chrome/cros_ec_typec.c
>> index ce031a10eb1b..743a28426f98 100644
>> --- a/drivers/platform/chrome/cros_ec_typec.c
>> +++ b/drivers/platform/chrome/cros_ec_typec.c
>> @@ -621,6 +621,7 @@ static int cros_typec_register_altmodes(struct 
>> cros_typec_data *typec, int port_
>>  struct cros_typec_altmode_node *node;
>>  struct typec_altmode_desc desc;
>>  struct typec_altmode *amode;
>> +int num_altmodes = 0;
>>  int ret = 0;
>>  int i, j;
>>  
>> @@ -647,9 +648,16 @@ static int cros_typec_register_altmodes(struct 
>> cros_typec_data *typec, int port_
>>  
>>  node->amode = amode;
>>  list_add_tail(>list, >partner_mode_list);
>> +num_altmodes++;
>>  }
>>  }
>>  
>> +ret = typec_partner_set_num_altmodes(port->partner, num_altmodes);
>> +if (ret < 0) {
>> +dev_err(typec->dev, "Unable to set partner num_altmodes for 
>> port: %d\n", port_num);
>> +goto err_cleanup;
>> +}
>> +
>>  return 0;
>>  
>>  err_cleanup:
>> -- 
>> 2.29.2.222.g5d2a92d10f8-goog
> 
> thanks,
> 


Re: [PATCH 0/4] soc: mediatek: Prepare MMSYS for DDP routing using tables

2020-11-04 Thread Enric Balletbo i Serra
Hi Matthias,

On 6/10/20 21:33, Enric Balletbo i Serra wrote:
> Dear all,
> 
> The following series are intended to prepare the mtk-mmsys driver to
> allow different DDP (Data Display Path) routing tables per SoC. Note
> that the series has been tested only on MT8173 platform and could break
> the display on MT2701 and MT2712 based devices. I kindly ask for someone
> having these devices to provide a tested routing table (unfortunately I
> didn't have enough documentation to figure out this myself).
> 
> For the other devices (MT8183, MT6779 and MT6797) DRM support is not in
> mainline yet so nothing will break.
> 
> Thanks,
>   Enric
> 
> 
> CK Hu (2):
>   soc: mediatek: mmsys: Create struct mtk_mmsys to store context data
>   soc: mediatek: mmsys: Use an array for setting the routing registers
> 
> Enric Balletbo i Serra (1):
>   soc: mediatek: mmsys: Use devm_platform_ioremap_resource()
> 
> Yongqiang Niu (1):
>   soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h
> 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  34 +-
>  drivers/soc/mediatek/mtk-mmsys.c| 429 +++-
>  include/linux/soc/mediatek/mtk-mmsys.h  |  33 ++
>  3 files changed, 263 insertions(+), 233 deletions(-)
> 

Although the patches 3 and 4 are controversial, and I'll work on it, I am
wondering if 1 and 2 are ready to be picked, as they are independent, so I can
send next version without these two patches.

Thanks,
  Enric




Re: [PATCH] drm/mediatek: mtk_dpi: Fix unused variable 'mtk_dpi_encoder_funcs'

2020-11-04 Thread Enric Balletbo i Serra
Hi

On 5/10/20 18:22, Enric Balletbo i Serra wrote:
> Commit f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
> introduced the following build warning with W=1
> 
>  drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: unused variable 
> 'mtk_dpi_encoder_funcs' [-Wunused-const-variable]
>  static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> 
> This struct is and the 'mtk_dpi_encoder_destroy()' are not needed
> anymore, so remove them.
> 
> Fixes: f89c696e7f63 ("drm/mediatek: mtk_dpi: Convert to bridge driver")
> Reported-by: kernel test robot 
> Signed-off-by: Enric Balletbo i Serra 
> ---

A gentle ping on this small fix. Thanks,

  Enric

> 
>  drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 589ef33a1780..2609d917e3f9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -522,15 +522,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   return 0;
>  }
>  
> -static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> - .destroy = mtk_dpi_encoder_destroy,
> -};
> -
>  static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
>enum drm_bridge_attach_flags flags)
>  {
> 


Re: [PATCH v2 2/2] soc: mediatek: pm-domains: Add support for mt8167

2020-10-30 Thread Enric Balletbo i Serra
s/soc/mediatek/mtk-pm-domains.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  
> +#include "mt8167-pm-domains.h"
>  #include "mt8173-pm-domains.h"
>  #include "mt8183-pm-domains.h"
>  #include "mt8192-pm-domains.h"
> @@ -515,6 +516,10 @@ static void scpsys_domain_cleanup(struct scpsys *scpsys)
>  }
>  
>  static const struct of_device_id scpsys_of_match[] = {
> + {
> + .compatible = "mediatek,mt8167-power-controller",
> + .data = _scpsys_data,
> + },
>   {
>   .compatible = "mediatek,mt8173-power-controller",
>   .data = _scpsys_data,
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index eda453f55126..7c1e1a7209f1 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -14,6 +14,7 @@
>  #define SPM_VEN_PWR_CON  0x0230
>  #define SPM_ISP_PWR_CON  0x0238
>  #define SPM_DIS_PWR_CON  0x023c
> +#define SPM_CONN_PWR_CON 0x0280
>  #define SPM_VEN2_PWR_CON 0x0298
>  #define SPM_AUDIO_PWR_CON0x029c
>  #define SPM_MFG_2D_PWR_CON   0x02c0
> diff --git a/include/linux/soc/mediatek/infracfg.h 
> b/include/linux/soc/mediatek/infracfg.h
> index e7842debc05d..4615a228da51 100644
> --- a/include/linux/soc/mediatek/infracfg.h
> +++ b/include/linux/soc/mediatek/infracfg.h
> @@ -123,6 +123,14 @@
>  #define MT8173_TOP_AXI_PROT_EN_MFG_M1BIT(22)
>  #define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
>  
> +#define MT8167_TOP_AXI_PROT_EN_MM_EMIBIT(1)
> +#define MT8167_TOP_AXI_PROT_EN_MCU_MFG       BIT(2)
> +#define MT8167_TOP_AXI_PROT_EN_CONN_EMI  BIT(4)
> +#define MT8167_TOP_AXI_PROT_EN_MFG_EMI   BIT(5)
> +#define MT8167_TOP_AXI_PROT_EN_CONN_MCU  BIT(8)
> +#define MT8167_TOP_AXI_PROT_EN_MCU_CONN  BIT(9)
> +#define MT8167_TOP_AXI_PROT_EN_MCU_MMBIT(11)
> +
>  #define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
>  #define MT2701_TOP_AXI_PROT_EN_CONN_MBIT(2)
>  #define MT2701_TOP_AXI_PROT_EN_CONN_SBIT(8)
> 

Reviewed-by: Enric Balletbo i Serra 

Thanks,
 Enric


Re: [PATCH v2 1/2] dt-bindings: power: Add MT8167 power domains

2020-10-30 Thread Enric Balletbo i Serra
Hi Fabien,

Thank you for the patch and base it on [0]

On 27/10/20 14:11, Fabien Parent wrote:
> Add power domains dt-bindings for MT8167.
> 
> Signed-off-by: Fabien Parent 
> ---
> 
> This patch depends on the SCPSYS PM domains driver [0].
> 
> v2:
>   * Implement on top of new SCPSYS PM domains driver [0]
> 
> [0] https://patchwork.kernel.org/project/linux-mediatek/list/?series=370737
> 
>  .../power/mediatek,power-controller.yaml   |  2 ++
>  include/dt-bindings/power/mt8167-power.h   | 18 ++
>  2 files changed, 20 insertions(+)
>  create mode 100644 include/dt-bindings/power/mt8167-power.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
> b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> index 0318ffb1133c..73e5452c3a5d 100644
> --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
> @@ -23,6 +23,7 @@ properties:
>  
>compatible:
>  enum:
> +  - mediatek,mt8167-power-controller
>- mediatek,mt8173-power-controller
>- mediatek,mt8183-power-controller
>- mediatek,mt8192-power-controller
> @@ -59,6 +60,7 @@ patternProperties:
>reg:
>  description: |
>Power domain index. Valid values are defined in:
> +  "include/dt-bindings/power/mt8167-power.h" - for MT8167 type 
> power domain.
>"include/dt-bindings/power/mt8173-power.h" - for MT8173 type 
> power domain.
>"include/dt-bindings/power/mt8183-power.h" - for MT8183 type 
> power domain.
>"include/dt-bindings/power/mt8192-power.h" - for MT8192 type 
> power domain.
> diff --git a/include/dt-bindings/power/mt8167-power.h 
> b/include/dt-bindings/power/mt8167-power.h
> new file mode 100644
> index ..7e3babfc2eef
> --- /dev/null
> +++ b/include/dt-bindings/power/mt8167-power.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + *
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_MT8167_POWER_H
> +#define _DT_BINDINGS_POWER_MT8167_POWER_H
> +
> +#define MT8167_POWER_DOMAIN_MM   0
> +#define MT8167_POWER_DOMAIN_DISP 0

Is that correct? Both domains have the same index?

> +#define MT8167_POWER_DOMAIN_VDEC 1
> +#define MT8167_POWER_DOMAIN_ISP  2
> +#define MT8167_POWER_DOMAIN_CONN 3
> +#define MT8167_POWER_DOMAIN_MFG_ASYNC4
> +#define MT8167_POWER_DOMAIN_MFG_2D   5
> +#define MT8167_POWER_DOMAIN_MFG  6
> +
> +#endif /* _DT_BINDINGS_POWER_MT8167_POWER_H */
> 


[PATCH v4 09/16] soc: mediatek: pm-domains: Allow bus protection to ignore clear ack

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

In some cases the hardware does not create an acknowledgment of the
bus protection clearing. Add a flag to the bus protection indicating
that a clear event will be ignored.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/soc/mediatek/mtk-pm-domains.c |  3 +++
 drivers/soc/mediatek/mtk-pm-domains.h | 23 ++-
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 88dec58aedd9..03279a999dfc 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -161,6 +161,9 @@ static int _scpsys_bus_protect_disable(const struct 
scpsys_bus_prot_data *bpd,
else
regmap_write(regmap, bpd[i].bus_prot_clr, mask);
 
+   if (bpd[i].ignore_clr_ack)
+   continue;
+
ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
   val, !(val & mask),
   MTK_POLL_DELAY_US, 
MTK_POLL_TIMEOUT);
diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
b/drivers/soc/mediatek/mtk-pm-domains.h
index 20df5689739b..809d2d43f01d 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.h
+++ b/drivers/soc/mediatek/mtk-pm-domains.h
@@ -35,19 +35,23 @@
 
 #define SPM_MAX_BUS_PROT_DATA  5
 
-#define _BUS_PROT(_mask, _set, _clr, _sta, _update) {  \
-   .bus_prot_mask = (_mask),   \
-   .bus_prot_set = _set,   \
-   .bus_prot_clr = _clr,   \
-   .bus_prot_sta = _sta,   \
-   .bus_prot_reg_update = _update, \
+#define _BUS_PROT(_mask, _set, _clr, _sta, _update, _ignore) { \
+   .bus_prot_mask = (_mask),   \
+   .bus_prot_set = _set,   \
+   .bus_prot_clr = _clr,   \
+   .bus_prot_sta = _sta,   \
+   .bus_prot_reg_update = _update, \
+   .ignore_clr_ack = _ignore,  \
}
 
-#define BUS_PROT_WR(_mask, _set, _clr, _sta)   \
-   _BUS_PROT(_mask, _set, _clr, _sta, false)
+#define BUS_PROT_WR(_mask, _set, _clr, _sta)   \
+   _BUS_PROT(_mask, _set, _clr, _sta, false, false)
+
+#define BUS_PROT_WR_IGN(_mask, _set, _clr, _sta)   \
+   _BUS_PROT(_mask, _set, _clr, _sta, false, true)
 
 #define BUS_PROT_UPDATE(_mask, _set, _clr, _sta)   \
-   _BUS_PROT(_mask, _set, _clr, _sta, true)
+   _BUS_PROT(_mask, _set, _clr, _sta, true, false)
 
 #define BUS_PROT_UPDATE_TOPAXI(_mask)  \
BUS_PROT_UPDATE(_mask,  \
@@ -61,6 +65,7 @@ struct scpsys_bus_prot_data {
u32 bus_prot_clr;
u32 bus_prot_sta;
bool bus_prot_reg_update;
+   bool ignore_clr_ack;
 };
 
 #define MAX_SUBSYS_CLKS 10
-- 
2.28.0



[PATCH v4 00/16] soc: mediatek: pm-domains: Add new driver for SCPSYS power domains controller

2020-10-30 Thread Enric Balletbo i Serra
Dear all,

This is a new driver with the aim to deprecate the mtk-scpsys driver.
The problem with that driver is that, in order to support more Mediatek
SoCs you need to add some logic to handle properly the power-up
sequence of newer Mediatek SoCs, doesn't handle parent-child power
domains and need to hardcode all the clocks in the driver itself. The
result is that the driver is getting bigger and bigger every time a
new SoC needs to be supported.

All this information can be getted from a properly defined binding, so
can be cleaner and smaller, hence, we implemented a new driver. For
now, only MT8173 and MT8183 is supported but should be fairly easy to
add support for new SoCs.

Three important notes:

1. This patch depends now on [1] to build correctly.

2. Support for MT8183 is not ready to land yet because has some
   dependencies, i.e mmsys support is still missing.

3. Support for MT8192. I picked the patches [2] from Weiyi Lu and
   adapted to this new series. I posted only for reference due that this
   new version has some changes that affects that patchset.

Only patches from 1 to 9 are ready, the others are provided for reference and 
test.

[1] https://lore.kernel.org/patchwork/patch/1328096/
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=368821

Best regards,
  Enric

Enric Balletbo i Serra (5):
  dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains
controller
  soc: mediatek: Add MediaTek SCPSYS power domains
  arm64: dts: mediatek: Add mt8173 power domain controller
  dt-bindings: power: Add MT8183 power domains
  arm64: dts: mediatek: Add smi_common node for MT8183

Matthias Brugger (8):
  soc: mediatek: pm-domains: Add bus protection protocol
  soc: mediatek: pm_domains: Make bus protection generic
  soc: mediatek: pm-domains: Add SMI block as bus protection block
  soc: mediatek: pm-domains: Add extra sram control
  soc: mediatek: pm-domains: Add subsystem clocks
  soc: mediatek: pm-domains: Allow bus protection to ignore clear ack
  soc: mediatek: pm-domains: Add support for mt8183
  arm64: dts: mediatek: Add mt8183 power domains controller

Weiyi Lu (3):
  dt-bindings: power: Add MT8192 power domains
  soc: mediatek: pm-domains: Add default power off flag
  soc: mediatek: pm-domains: Add support for mt8192

 .../power/mediatek,power-controller.yaml  | 293 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi  | 164 +++--
 arch/arm64/boot/dts/mediatek/mt8183.dtsi  | 172 +
 drivers/soc/mediatek/Kconfig  |  12 +
 drivers/soc/mediatek/Makefile |   1 +
 drivers/soc/mediatek/mt8173-pm-domains.h  |  94 +++
 drivers/soc/mediatek/mt8183-pm-domains.h  | 221 +++
 drivers/soc/mediatek/mt8192-pm-domains.h  | 292 +
 drivers/soc/mediatek/mtk-infracfg.c   |   5 -
 drivers/soc/mediatek/mtk-pm-domains.c | 614 ++
 drivers/soc/mediatek/mtk-pm-domains.h | 102 +++
 include/dt-bindings/power/mt8183-power.h  |  26 +
 include/dt-bindings/power/mt8192-power.h  |  32 +
 include/linux/soc/mediatek/infracfg.h | 107 +++
 14 files changed, 2081 insertions(+), 54 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
 create mode 100644 drivers/soc/mediatek/mt8173-pm-domains.h
 create mode 100644 drivers/soc/mediatek/mt8183-pm-domains.h
 create mode 100644 drivers/soc/mediatek/mt8192-pm-domains.h
 create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c
 create mode 100644 drivers/soc/mediatek/mtk-pm-domains.h
 create mode 100644 include/dt-bindings/power/mt8183-power.h
 create mode 100644 include/dt-bindings/power/mt8192-power.h

-- 
2.28.0



[PATCH v4 06/16] soc: mediatek: pm-domains: Add SMI block as bus protection block

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

Apart from the infracfg block, the SMI block is used to enable the bus
protection for some power domains. Add support for this block.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Use the new syscon_regmap_lookup_by_phandle_optional() wrapper.

Changes in v3:
- Do not reuse bpd for 2 different things.
- Disable pd->smi first and after that pd->infracfg.
- Rename BUT_PROT_UPDATE_MT8173 to BUS_PROT_UPDATE_TOPAXI as in all the
  other SoCs TOPAXI is mapped to the same address.

Changes in v2: None

 drivers/soc/mediatek/mt8173-pm-domains.h | 18 -
 drivers/soc/mediatek/mtk-pm-domains.c| 23 +++---
 drivers/soc/mediatek/mtk-pm-domains.h| 25 
 3 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/drivers/soc/mediatek/mt8173-pm-domains.h 
b/drivers/soc/mediatek/mt8173-pm-domains.h
index 72b3acaf74fb..3e8ee5dabb43 100644
--- a/drivers/soc/mediatek/mt8173-pm-domains.h
+++ b/drivers/soc/mediatek/mt8173-pm-domains.h
@@ -34,10 +34,9 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .bp_infracfg[0] = {
-   .bus_prot_reg_update = true,
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
-   MT8173_TOP_AXI_PROT_EN_MM_M1,
+   .bp_infracfg = {
+   BUS_PROT_UPDATE_TOPAXI(MT8173_TOP_AXI_PROT_EN_MM_M0 |
+  MT8173_TOP_AXI_PROT_EN_MM_M1),
},
},
[MT8173_POWER_DOMAIN_VENC_LT] = {
@@ -76,12 +75,11 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(13, 8),
.sram_pdn_ack_bits = GENMASK(21, 16),
-   .bp_infracfg[0] = {
-   .bus_prot_reg_update = true,
-   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
-   MT8173_TOP_AXI_PROT_EN_MFG_M0 |
-   MT8173_TOP_AXI_PROT_EN_MFG_M1 |
-   MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
+   .bp_infracfg = {
+   BUS_PROT_UPDATE_TOPAXI(MT8173_TOP_AXI_PROT_EN_MFG_S |
+  MT8173_TOP_AXI_PROT_EN_MFG_M0 |
+  MT8173_TOP_AXI_PROT_EN_MFG_M1 |
+  
MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT),
},
},
 };
diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 6122701d018f..8a21847464c2 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -32,6 +32,7 @@ struct scpsys_domain {
int num_clks;
struct clk_bulk_data *clks;
struct regmap *infracfg;
+   struct regmap *smi;
 };
 
 struct scpsys {
@@ -99,9 +100,9 @@ static int _scpsys_bus_protect_enable(const struct 
scpsys_bus_prot_data *bpd, st
if (bpd[i].bus_prot_reg_update)
regmap_set_bits(regmap, bpd[i].bus_prot_set, mask);
else
-   regmap_write(regmap, INFRA_TOPAXI_PROTECTEN_SET, mask);
+   regmap_write(regmap, bpd[i].bus_prot_set, mask);
 
-   ret = regmap_read_poll_timeout(regmap, INFRA_TOPAXI_PROTECTSTA1,
+   ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
   val, (val & mask) == mask,
   MTK_POLL_DELAY_US, 
MTK_POLL_TIMEOUT);
if (ret)
@@ -116,8 +117,10 @@ static int scpsys_bus_protect_enable(struct scpsys_domain 
*pd)
int ret;
 
ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
+   if (ret)
+   return ret;
 
-   return ret;
+   return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi);
 }
 
 static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
@@ -134,9 +137,9 @@ static int _scpsys_bus_protect_disable(const struct 
scpsys_bus_prot_data *bpd,
if (bpd[i].bus_prot_reg_update)
regmap_clear_bits(regmap, bpd[i].bus_prot_clr, mask);
else
-   regmap_write(regmap, INFRA_TOPAXI_PROTECTEN_CLR, mask);
+   regmap_write(regmap, bpd[i].bus_prot_clr, mask);
 
-   ret = regmap_read_poll_timeout(regmap, INFRA_TOPAXI_PROTECTSTA1,
+   ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,

[PATCH v4 01/16] dt-bindings: power: Add bindings for the Mediatek SCPSYS power domains controller

2020-10-30 Thread Enric Balletbo i Serra
The System Control Processor System (SCPSYS) has several power management
related tasks in the system. Add the bindings to define the power
domains for the SCPSYS power controller.

Co-developed-by: Matthias Brugger 
Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
Reviewed-by: Rob Herring 
---

Changes in v4:
- Fix indentation warnings reported by yamllint

Changes in v3:
- Use hex for unit-addresses.
- Define child nodes for nested power domains even are duplicated, but
  more clear than adding a regex scaped to be a valid URI.

Changes in v2:
- Use generic node names (power-domain).
- Define valid values for common properties like #power-domain-cells.

 .../power/mediatek,power-controller.yaml  | 289 ++
 1 file changed, 289 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/mediatek,power-controller.yaml

diff --git 
a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
new file mode 100644
index ..73b8988bd063
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -0,0 +1,289 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/mediatek,power-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Power Domains Controller
+
+maintainers:
+  - Weiyi Lu 
+  - Matthias Brugger 
+
+description: |
+  Mediatek processors include support for multiple power domains which can be
+  powered up/down by software based on different application scenes to save 
power.
+
+  IP cores belonging to a power domain should contain a 'power-domains'
+  property that is a phandle for SCPSYS node representing the domain.
+
+properties:
+  $nodename:
+const: power-controller
+
+  compatible:
+enum:
+  - mediatek,mt8173-power-controller
+
+  '#power-domain-cells':
+const: 1
+
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+patternProperties:
+  "^power-domain@[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.
+
+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/mt8173-power.h" - for MT8173 type 
power domain.
+maxItems: 1
+
+  clocks:
+description: |
+  A number of phandles to clocks that need to be enabled during domain
+  power-up sequencing.
+
+  clock-names:
+description: |
+  List of names of clocks, in order to match the power-up sequencing
+  for each power domain we need to group the clocks by name. BASIC
+  clocks need to be enabled before enabling the corresponding power
+  domain, and should not have a '-' in their name (i.e mm, mfg, venc).
+  SUSBYS clocks need to be enabled before releasing the bus protection,
+  and should contain a '-' in their name (i.e mm-0, isp-0, cam-0).
+
+  In order to follow properly the power-up sequencing, the clocks must
+  be specified by order, adding first the BASIC clocks followed by the
+  SUSBSYS clocks.
+
+  mediatek,infracfg:
+$ref: /schemas/types.yaml#definitions/phandle
+description: phandle to the device containing the INFRACFG register 
range.
+
+  mediatek,smi:
+$ref: /schemas/types.yaml#definitions/phandle
+description: phandle to the device containing the SMI register range.
+
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+type: object
+description: |
+  Represents a power domain child within a power domain parent node.
+
+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:
+maxItems: 1
+
+  clocks:
+description: |
+  A number of phandles to clocks that need to be enabled during 
domain
+  power-up sequencing.
+
+  clock-names:
+description: |
+  List of names of clocks, in order to match the power-up 
sequencing
+  for each power domain we need to group the clocks by name. BASIC
+  clocks need

[PATCH v4 02/16] soc: mediatek: Add MediaTek SCPSYS power domains

2020-10-30 Thread Enric Balletbo i Serra
The System Control Processor System (SCPSYS) has several power management
related tasks in the system. This driver implements support to handle
the different power domains supported in order to meet high performance
and low power requirements.

Co-developed-by: Matthias Brugger 
Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Use a boolean for scpsys_domain_is_on().
- Disable the SRAM in the scpsys_power_on() error path.
- Use the regmap_[clear|set]_bits helpers.
- Use the new syscon_regmap_lookup_by_phandle_optional() helper.
- Rename domains variable from scpsys_soc_data struct to avoid
  confusions.
- Check that domain data sta_mask is set.

Changes in v3:
- Return only a boolean for scpsys_domain_is_on()
- Use regmap_update_bits API when possible.
- Add some logic to make sure scpsys->domains[id] == NULL or != NULL
  when needed.
- Return the child node for scpsys_add_one_domain() call.
- Remove unneded zeroing num_clks variable.
- Move the soc specific data to separate include files.

Changes in v2:
- Get base address from parent syscon. We have now a scpsys syscon node
  and a child for the SPM (System Power Manager).
- Use regmap API to acces de base address.

 drivers/soc/mediatek/Kconfig |  13 +
 drivers/soc/mediatek/Makefile|   1 +
 drivers/soc/mediatek/mt8173-pm-domains.h |  96 +
 drivers/soc/mediatek/mtk-pm-domains.c| 456 +++
 drivers/soc/mediatek/mtk-pm-domains.h|  65 
 5 files changed, 631 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8173-pm-domains.h
 create mode 100644 drivers/soc/mediatek/mtk-pm-domains.c
 create mode 100644 drivers/soc/mediatek/mtk-pm-domains.h

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd790ec..68d800f9e4a5 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -44,6 +44,19 @@ config MTK_SCPSYS
  Say yes here to add support for the MediaTek SCPSYS power domain
  driver.
 
+config MTK_SCPSYS_PM_DOMAINS
+   bool "MediaTek SCPSYS generic power domain"
+   default ARCH_MEDIATEK
+   depends on PM
+   depends on MTK_INFRACFG
+   select PM_GENERIC_DOMAINS
+   select REGMAP
+   help
+ Say y here to enable power domain support.
+ In order to meet high performance and low power requirements, the 
System
+ Control Processor System (SCPSYS) has several power management related
+ tasks in the system.
+
 config MTK_MMSYS
bool "MediaTek MMSYS Support"
default ARCH_MEDIATEK
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 069625c118c2..905b4faa624d 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -3,5 +3,6 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
 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/mt8173-pm-domains.h 
b/drivers/soc/mediatek/mt8173-pm-domains.h
new file mode 100644
index ..5f2b5d4ad02b
--- /dev/null
+++ b/drivers/soc/mediatek/mt8173-pm-domains.h
@@ -0,0 +1,96 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8173_PM_DOMAINS_H
+#define __SOC_MEDIATEK_MT8173_PM_DOMAINS_H
+
+#include "mtk-pm-domains.h"
+#include 
+
+/*
+ * MT8173 power domain support
+ */
+
+static const struct scpsys_domain_data scpsys_domain_data_mt8173[] = {
+   [MT8173_POWER_DOMAIN_VDEC] = {
+   .sta_mask = PWR_STATUS_VDEC,
+   .ctl_offs = SPM_VDE_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8173_POWER_DOMAIN_VENC] = {
+   .sta_mask = PWR_STATUS_VENC,
+   .ctl_offs = SPM_VEN_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   },
+   [MT8173_POWER_DOMAIN_ISP] = {
+   .sta_mask = PWR_STATUS_ISP,
+   .ctl_offs = SPM_ISP_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   },
+   [MT8173_POWER_DOMAIN_MM] = {
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = SPM_DIS_PWR_CON,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .bp_infracfg = {
+   .bus_prot_reg_update = true,
+   .bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
+   MT8173_TOP_AXI_PROT_EN_MM_M1,
+   },
+   },
+   [MT8173_POWER_DOMAIN_VENC_LT] = {
+   .sta_mask = PWR_STATUS_VENC_LT,
+  

[PATCH v4 05/16] soc: mediatek: pm_domains: Make bus protection generic

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

Bus protection is not exclusively done by calling the infracfg misc driver.
Make the calls for setting and clearing the bus protection generic so
that we can use other blocks for it as well.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Remove bpd variable from scpsys_bus_protect_[enable|disable]()
- Remove dependency of Kconfig symbol MTK_INFRACFG

Changes in v3: None
Changes in v2: None

 drivers/soc/mediatek/Kconfig  |  1 -
 drivers/soc/mediatek/mtk-infracfg.c   |  5 ---
 drivers/soc/mediatek/mtk-pm-domains.c | 57 +--
 include/linux/soc/mediatek/infracfg.h |  5 +++
 4 files changed, 49 insertions(+), 19 deletions(-)

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 68d800f9e4a5..67cef12dc585 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -48,7 +48,6 @@ config MTK_SCPSYS_PM_DOMAINS
bool "MediaTek SCPSYS generic power domain"
default ARCH_MEDIATEK
depends on PM
-   depends on MTK_INFRACFG
select PM_GENERIC_DOMAINS
select REGMAP
help
diff --git a/drivers/soc/mediatek/mtk-infracfg.c 
b/drivers/soc/mediatek/mtk-infracfg.c
index 4a123796aad3..0590b68e0d78 100644
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ b/drivers/soc/mediatek/mtk-infracfg.c
@@ -12,11 +12,6 @@
 #define MTK_POLL_DELAY_US   10
 #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
 
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1   0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
 /**
  * mtk_infracfg_set_bus_protection - enable bus protection
  * @infracfg: The infracfg regmap
diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 06a16e45356a..6122701d018f 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -86,18 +86,24 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
MTK_POLL_TIMEOUT);
 }
 
-static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
+static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd, 
struct regmap *regmap)
 {
-   const struct scpsys_bus_prot_data *bpd = pd->data->bp_infracfg;
int i, ret;
 
for (i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
-   if (!bpd[i].bus_prot_mask)
+   u32 val, mask = bpd[i].bus_prot_mask;
+
+   if (!mask)
break;
 
-   ret = mtk_infracfg_set_bus_protection(pd->infracfg,
- bpd[i].bus_prot_mask,
- 
bpd[i].bus_prot_reg_update);
+   if (bpd[i].bus_prot_reg_update)
+   regmap_set_bits(regmap, bpd[i].bus_prot_set, mask);
+   else
+   regmap_write(regmap, INFRA_TOPAXI_PROTECTEN_SET, mask);
+
+   ret = regmap_read_poll_timeout(regmap, INFRA_TOPAXI_PROTECTSTA1,
+  val, (val & mask) == mask,
+  MTK_POLL_DELAY_US, 
MTK_POLL_TIMEOUT);
if (ret)
return ret;
}
@@ -105,18 +111,34 @@ static int scpsys_bus_protect_enable(struct scpsys_domain 
*pd)
return 0;
 }
 
-static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
+static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
+{
+   int ret;
+
+   ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
+
+   return ret;
+}
+
+static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
+  struct regmap *regmap)
 {
-   const struct scpsys_bus_prot_data *bpd = pd->data->bp_infracfg;
int i, ret;
 
-   for (i = SPM_MAX_BUS_PROT_DATA; i > 0; i--) {
-   if (!bpd[i].bus_prot_mask)
+   for (i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
+   u32 val, mask = bpd[i].bus_prot_mask;
+
+   if (!mask)
continue;
 
-   ret = mtk_infracfg_clear_bus_protection(pd->infracfg,
-   bpd[i].bus_prot_mask,
-   
bpd[i].bus_prot_reg_update);
+   if (bpd[i].bus_prot_reg_update)
+   regmap_clear_bits(regmap, bpd[i].bus_prot_clr, mask);
+   else
+   regmap_write(regmap, INFRA_TOPAXI_PROTECTEN_CLR, mask);
+
+   ret = regmap_read_poll_timeout(regmap, INFRA_TOPAXI_PROTECTSTA1,
+  val, !(val & mask),
+  MTK_POLL

[PATCH v4 13/16] arm64: dts: mediatek: Add mt8183 power domains controller

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

Add power domains controller node for SoC mt8183

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 162 +++
 1 file changed, 162 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c06778d21c4f..3e01592409cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "mt8183-pinfunc.h"
@@ -316,6 +317,167 @@ pio: pinctrl@10005000 {
#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,mt8183-power-controller";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+   /* power domain of the SoC */
+   power-domain@MT8183_POWER_DOMAIN_AUDIO {
+   reg = ;
+   clocks = < 
CLK_TOP_MUX_AUD_INTBUS>,
+< CLK_INFRA_AUDIO>,
+< 
CLK_INFRA_AUDIO_26M_BCLK>;
+   clock-names = "audio", "audio1", 
"audio2";
+   #power-domain-cells = <0>;
+   };
+
+   power-domain@MT8183_POWER_DOMAIN_CONN {
+   reg = ;
+   mediatek,infracfg = <>;
+   #power-domain-cells = <0>;
+   };
+
+   power-domain@MT8183_POWER_DOMAIN_MFG_ASYNC {
+   reg = ;
+   clocks =  < CLK_TOP_MUX_MFG>;
+   clock-names = "mfg";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+   power-domain@MT8183_POWER_DOMAIN_MFG {
+   reg = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+   
power-domain@MT8183_POWER_DOMAIN_MFG_CORE0 {
+   reg = 
;
+   #power-domain-cells = 
<0>;
+   };
+
+   
power-domain@MT8183_POWER_DOMAIN_MFG_CORE1 {
+   reg = 
;
+   #power-domain-cells = 
<0>;
+   };
+
+   
power-domain@MT8183_POWER_DOMAIN_MFG_2D {
+   reg = 
;
+   mediatek,infracfg = 
<>;
+   #power-domain-cells = 
<0>;
+   };
+   };
+   };
+
+   power-domain@MT8183_POWER_DOMAIN_DISP {
+   reg = ;
+   clocks = < CLK_TOP_MUX_MM>,
+< CLK_MM_SMI_COMMON>,
+< CLK_MM_SMI_LARB0>,
+< CLK_MM_SMI_LARB1>,
+< CLK_MM_GALS_COMM0>,
+< CLK_MM_GALS_COMM1>,
+< CLK_MM_GALS_CCU2MM>,
+ 

[PATCH v4 10/16] dt-bindings: power: Add MT8183 power domains

2020-10-30 Thread Enric Balletbo i Serra
Add power domains dt-bindings for MT8183.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../power/mediatek,power-controller.yaml  |  2 ++
 include/dt-bindings/power/mt8183-power.h  | 26 +++
 2 files changed, 28 insertions(+)
 create mode 100644 include/dt-bindings/power/mt8183-power.h

diff --git 
a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 73b8988bd063..8cae43412327 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -24,6 +24,7 @@ properties:
   compatible:
 enum:
   - mediatek,mt8173-power-controller
+  - mediatek,mt8183-power-controller
 
   '#power-domain-cells':
 const: 1
@@ -58,6 +59,7 @@ patternProperties:
 description: |
   Power domain index. Valid values are defined in:
   "include/dt-bindings/power/mt8173-power.h" - for MT8173 type 
power domain.
+  "include/dt-bindings/power/mt8183-power.h" - for MT8183 type 
power domain.
 maxItems: 1
 
   clocks:
diff --git a/include/dt-bindings/power/mt8183-power.h 
b/include/dt-bindings/power/mt8183-power.h
new file mode 100644
index ..d1ab387ba8c7
--- /dev/null
+++ b/include/dt-bindings/power/mt8183-power.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Weiyi Lu 
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT8183_POWER_H
+#define _DT_BINDINGS_POWER_MT8183_POWER_H
+
+#define MT8183_POWER_DOMAIN_AUDIO  0
+#define MT8183_POWER_DOMAIN_CONN   1
+#define MT8183_POWER_DOMAIN_MFG_ASYNC  2
+#define MT8183_POWER_DOMAIN_MFG3
+#define MT8183_POWER_DOMAIN_MFG_CORE0  4
+#define MT8183_POWER_DOMAIN_MFG_CORE1  5
+#define MT8183_POWER_DOMAIN_MFG_2D 6
+#define MT8183_POWER_DOMAIN_DISP   7
+#define MT8183_POWER_DOMAIN_CAM8
+#define MT8183_POWER_DOMAIN_ISP9
+#define MT8183_POWER_DOMAIN_VDEC   10
+#define MT8183_POWER_DOMAIN_VENC   11
+#define MT8183_POWER_DOMAIN_VPU_TOP12
+#define MT8183_POWER_DOMAIN_VPU_CORE0  13
+#define MT8183_POWER_DOMAIN_VPU_CORE1  14
+
+#endif /* _DT_BINDINGS_POWER_MT8183_POWER_H */
-- 
2.28.0



[PATCH v4 14/16] dt-bindings: power: Add MT8192 power domains

2020-10-30 Thread Enric Balletbo i Serra
From: Weiyi Lu 

Add power domains dt-bindings for MT8192.

Signed-off-by: Weiyi Lu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../power/mediatek,power-controller.yaml  |  2 ++
 include/dt-bindings/power/mt8192-power.h  | 32 +++
 2 files changed, 34 insertions(+)
 create mode 100644 include/dt-bindings/power/mt8192-power.h

diff --git 
a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml 
b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
index 8cae43412327..fd12bafe3548 100644
--- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
+++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml
@@ -25,6 +25,7 @@ properties:
 enum:
   - mediatek,mt8173-power-controller
   - mediatek,mt8183-power-controller
+  - mediatek,mt8192-power-controller
 
   '#power-domain-cells':
 const: 1
@@ -60,6 +61,7 @@ patternProperties:
   Power domain index. Valid values are defined in:
   "include/dt-bindings/power/mt8173-power.h" - for MT8173 type 
power domain.
   "include/dt-bindings/power/mt8183-power.h" - for MT8183 type 
power domain.
+  "include/dt-bindings/power/mt8192-power.h" - for MT8192 type 
power domain.
 maxItems: 1
 
   clocks:
diff --git a/include/dt-bindings/power/mt8192-power.h 
b/include/dt-bindings/power/mt8192-power.h
new file mode 100644
index ..4eaa53d7270a
--- /dev/null
+++ b/include/dt-bindings/power/mt8192-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2020 MediaTek Inc.
+ * Author: Weiyi Lu 
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT8192_POWER_H
+#define _DT_BINDINGS_POWER_MT8192_POWER_H
+
+#define MT8192_POWER_DOMAIN_AUDIO  0
+#define MT8192_POWER_DOMAIN_CONN   1
+#define MT8192_POWER_DOMAIN_MFG0   2
+#define MT8192_POWER_DOMAIN_MFG1   3
+#define MT8192_POWER_DOMAIN_MFG2   4
+#define MT8192_POWER_DOMAIN_MFG3   5
+#define MT8192_POWER_DOMAIN_MFG4   6
+#define MT8192_POWER_DOMAIN_MFG5   7
+#define MT8192_POWER_DOMAIN_MFG6   8
+#define MT8192_POWER_DOMAIN_DISP   9
+#define MT8192_POWER_DOMAIN_IPE10
+#define MT8192_POWER_DOMAIN_ISP11
+#define MT8192_POWER_DOMAIN_ISP2   12
+#define MT8192_POWER_DOMAIN_MDP13
+#define MT8192_POWER_DOMAIN_VENC   14
+#define MT8192_POWER_DOMAIN_VDEC   15
+#define MT8192_POWER_DOMAIN_VDEC2  16
+#define MT8192_POWER_DOMAIN_CAM17
+#define MT8192_POWER_DOMAIN_CAM_RAWA   18
+#define MT8192_POWER_DOMAIN_CAM_RAWB   19
+#define MT8192_POWER_DOMAIN_CAM_RAWC   20
+
+#endif /* _DT_BINDINGS_POWER_MT8192_POWER_H */
-- 
2.28.0



[PATCH v4 15/16] soc: mediatek: pm-domains: Add default power off flag

2020-10-30 Thread Enric Balletbo i Serra
From: Weiyi Lu 

For some power domain, like conn on MT8192, it should be default OFF.
Because the power on/off control relies the function of connectivity chip
and its firmware. And if project choose other chip vendor solution,
those necessary connectivity functions will not provided.

Signed-off-by: Weiyi Lu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Check via scpsys_domain_is_on() if a power domain is on when removing.

Changes in v3: None
Changes in v2: None

 drivers/soc/mediatek/mtk-pm-domains.c | 25 ++---
 drivers/soc/mediatek/mtk-pm-domains.h |  1 +
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 8703d50cd2b7..c3b85b69f2f7 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -377,10 +377,16 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
*scpsys, struct device_no
 * software.  The unused domains will be switched off during
 * late_init time.
 */
-   ret = scpsys_power_on(>genpd);
-   if (ret < 0) {
-   dev_err(scpsys->dev, "%pOF: failed to power on domain: %d\n", 
node, ret);
-   goto err_unprepare_clocks;
+   if (MTK_SCPD_CAPS(pd, MTK_SCPD_KEEP_DEFAULT_OFF)) {
+   if (scpsys_domain_is_on(pd))
+   dev_warn(scpsys->dev,
+"%pOF: A default off power domain has been 
ON\n", node);
+   } else {
+   ret = scpsys_power_on(>genpd);
+   if (ret < 0) {
+   dev_err(scpsys->dev, "%pOF: failed to power on domain: 
%d\n", node, ret);
+   goto err_unprepare_clocks;
+   }
}
 
if (scpsys->domains[id]) {
@@ -394,7 +400,11 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
*scpsys, struct device_no
pd->genpd.power_off = scpsys_power_off;
pd->genpd.power_on = scpsys_power_on;
 
-   pm_genpd_init(>genpd, NULL, false);
+   if (MTK_SCPD_CAPS(pd, MTK_SCPD_KEEP_DEFAULT_OFF))
+   pm_genpd_init(>genpd, NULL, true);
+   else
+   pm_genpd_init(>genpd, NULL, false);
+
scpsys->domains[id] = >genpd;
 
return scpsys->pd_data.domains[id];
@@ -467,6 +477,9 @@ static void scpsys_remove_one_domain(struct scpsys_domain 
*pd)
 {
int ret;
 
+   if (scpsys_domain_is_on(pd))
+   scpsys_power_off(>genpd);
+
/*
 * We're in the error cleanup already, so we only complain,
 * but won't emit another error on top of the original one.
@@ -477,8 +490,6 @@ static void scpsys_remove_one_domain(struct scpsys_domain 
*pd)
"failed to remove domain '%s' : %d - state may be 
inconsistent\n",
pd->genpd.name, ret);
 
-   scpsys_power_off(>genpd);
-
clk_bulk_unprepare(pd->num_clks, pd->clks);
clk_bulk_put(pd->num_clks, pd->clks);
 
diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
b/drivers/soc/mediatek/mtk-pm-domains.h
index 2c745f11b422..a2f4d8f97e05 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.h
+++ b/drivers/soc/mediatek/mtk-pm-domains.h
@@ -6,6 +6,7 @@
 #define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
 #define MTK_SCPD_FWAIT_SRAMBIT(1)
 #define MTK_SCPD_SRAM_ISO  BIT(2)
+#define MTK_SCPD_KEEP_DEFAULT_OFF  BIT(3)
 #define MTK_SCPD_CAPS(_scpd, _x)   ((_scpd)->data->caps & (_x))
 
 #define SPM_VDE_PWR_CON0x0210
-- 
2.28.0



[PATCH v4 16/16] soc: mediatek: pm-domains: Add support for mt8192

2020-10-30 Thread Enric Balletbo i Serra
From: Weiyi Lu 

Add the needed board data to support mt8192 SoC.

Signed-off-by: Weiyi Lu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Adapt scpsys_soc_data struct to the changes done in previous patches.

Changes in v3: None
Changes in v2: None

 drivers/soc/mediatek/mt8192-pm-domains.h | 292 +++
 drivers/soc/mediatek/mtk-pm-domains.c|   5 +
 include/linux/soc/mediatek/infracfg.h|  56 +
 3 files changed, 353 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8192-pm-domains.h

diff --git a/drivers/soc/mediatek/mt8192-pm-domains.h 
b/drivers/soc/mediatek/mt8192-pm-domains.h
new file mode 100644
index ..0fdf6dc6231f
--- /dev/null
+++ b/drivers/soc/mediatek/mt8192-pm-domains.h
@@ -0,0 +1,292 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8192_PM_DOMAINS_H
+#define __SOC_MEDIATEK_MT8192_PM_DOMAINS_H
+
+#include "mtk-pm-domains.h"
+#include 
+
+/*
+ * MT8192 power domain support
+ */
+
+static const struct scpsys_domain_data scpsys_domain_data_mt8192[] = {
+   [MT8192_POWER_DOMAIN_AUDIO] = {
+   .sta_mask = BIT(21),
+   .ctl_offs = 0x0354,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_2_AUDIO,
+   MT8192_TOP_AXI_PROT_EN_2_SET,
+   MT8192_TOP_AXI_PROT_EN_2_CLR,
+   MT8192_TOP_AXI_PROT_EN_2_STA1),
+   },
+   },
+   [MT8192_POWER_DOMAIN_CONN] = {
+   .sta_mask = PWR_STATUS_CONN,
+   .ctl_offs = 0x0304,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_CONN,
+   MT8192_TOP_AXI_PROT_EN_SET,
+   MT8192_TOP_AXI_PROT_EN_CLR,
+   MT8192_TOP_AXI_PROT_EN_STA1),
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_CONN_2ND,
+   MT8192_TOP_AXI_PROT_EN_SET,
+   MT8192_TOP_AXI_PROT_EN_CLR,
+   MT8192_TOP_AXI_PROT_EN_STA1),
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_1_CONN,
+   MT8192_TOP_AXI_PROT_EN_1_SET,
+   MT8192_TOP_AXI_PROT_EN_1_CLR,
+   MT8192_TOP_AXI_PROT_EN_1_STA1),
+   },
+   .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
+   },
+   [MT8192_POWER_DOMAIN_MFG0] = {
+   .sta_mask = BIT(2),
+   .ctl_offs = 0x0308,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8192_POWER_DOMAIN_MFG1] = {
+   .sta_mask = BIT(3),
+   .ctl_offs = 0x030c,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_1_MFG1,
+   MT8192_TOP_AXI_PROT_EN_1_SET,
+   MT8192_TOP_AXI_PROT_EN_1_CLR,
+   MT8192_TOP_AXI_PROT_EN_1_STA1),
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_2_MFG1,
+   MT8192_TOP_AXI_PROT_EN_2_SET,
+   MT8192_TOP_AXI_PROT_EN_2_CLR,
+   MT8192_TOP_AXI_PROT_EN_2_STA1),
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_MFG1,
+   MT8192_TOP_AXI_PROT_EN_SET,
+   MT8192_TOP_AXI_PROT_EN_CLR,
+   MT8192_TOP_AXI_PROT_EN_STA1),
+   BUS_PROT_WR(MT8192_TOP_AXI_PROT_EN_2_MFG1_2ND,
+   MT8192_TOP_AXI_PROT_EN_2_SET,
+   MT8192_TOP_AXI_PROT_EN_2_CLR,
+   MT8192_TOP_AXI_PROT_EN_2_STA1),
+   },
+   },
+   [MT8192_POWER_DOMAIN_MFG2] = {
+   .sta_mask = BIT(4),
+   .ctl_offs = 0x0310,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8192_POWER_DOMAIN_MFG3] = {
+   .sta_mask = BIT(5),
+   .ctl_offs = 0x0314,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8192_POWER_DOMAIN_MFG4] = {
+   .sta_mask = BIT(6),
+   .ctl_offs = 0x0318,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8192_POWER_D

[PATCH v4 11/16] soc: mediatek: pm-domains: Add support for mt8183

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

Add the needed board data to support mt8183 SoC.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Adapt the scpsys_soc_data struct to the changes done in previous
  patches.

Changes in v3:
- Do not remove mmsys from of_device_id. That's part of another
  patchset.
- Move the soc specific data to separate include files.

Changes in v2:
- Do not use hardcoded values for triplets set, clear and status in
  infracfg and SMI.

 drivers/soc/mediatek/mt8183-pm-domains.h | 221 +++
 drivers/soc/mediatek/mtk-pm-domains.c|   5 +
 drivers/soc/mediatek/mtk-pm-domains.h|   1 +
 include/linux/soc/mediatek/infracfg.h|  46 +
 4 files changed, 273 insertions(+)
 create mode 100644 drivers/soc/mediatek/mt8183-pm-domains.h

diff --git a/drivers/soc/mediatek/mt8183-pm-domains.h 
b/drivers/soc/mediatek/mt8183-pm-domains.h
new file mode 100644
index ..8d996c5d2682
--- /dev/null
+++ b/drivers/soc/mediatek/mt8183-pm-domains.h
@@ -0,0 +1,221 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __SOC_MEDIATEK_MT8183_PM_DOMAINS_H
+#define __SOC_MEDIATEK_MT8183_PM_DOMAINS_H
+
+#include "mtk-pm-domains.h"
+#include 
+
+/*
+ * MT8183 power domain support
+ */
+
+static const struct scpsys_domain_data scpsys_domain_data_mt8183[] = {
+   [MT8183_POWER_DOMAIN_AUDIO] = {
+   .sta_mask = PWR_STATUS_AUDIO,
+   .ctl_offs = 0x0314,
+   .sram_pdn_bits = GENMASK(11, 8),
+   .sram_pdn_ack_bits = GENMASK(15, 12),
+   },
+   [MT8183_POWER_DOMAIN_CONN] = {
+   .sta_mask = PWR_STATUS_CONN,
+   .ctl_offs = 0x032c,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_CONN, 
MT8183_TOP_AXI_PROT_EN_SET,
+   MT8183_TOP_AXI_PROT_EN_CLR, 
MT8183_TOP_AXI_PROT_EN_STA1),
+   },
+   },
+   [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
+   .sta_mask = PWR_STATUS_MFG_ASYNC,
+   .ctl_offs = 0x0334,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   },
+   [MT8183_POWER_DOMAIN_MFG] = {
+   .sta_mask = PWR_STATUS_MFG,
+   .ctl_offs = 0x0338,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8183_POWER_DOMAIN_MFG_CORE0] = {
+   .sta_mask = BIT(7),
+   .ctl_offs = 0x034c,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8183_POWER_DOMAIN_MFG_CORE1] = {
+   .sta_mask = BIT(20),
+   .ctl_offs = 0x0310,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT8183_POWER_DOMAIN_MFG_2D] = {
+   .sta_mask = PWR_STATUS_MFG_2D,
+   .ctl_offs = 0x0348,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_1_MFG, 
MT8183_TOP_AXI_PROT_EN_1_SET,
+   MT8183_TOP_AXI_PROT_EN_1_CLR, 
MT8183_TOP_AXI_PROT_EN_STA1_1),
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_MFG, 
MT8183_TOP_AXI_PROT_EN_SET,
+   MT8183_TOP_AXI_PROT_EN_CLR, 
MT8183_TOP_AXI_PROT_EN_STA1),
+   },
+   },
+   [MT8183_POWER_DOMAIN_DISP] = {
+   .sta_mask = PWR_STATUS_DISP,
+   .ctl_offs = 0x030c,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_1_DISP, 
MT8183_TOP_AXI_PROT_EN_1_SET,
+   MT8183_TOP_AXI_PROT_EN_1_CLR, 
MT8183_TOP_AXI_PROT_EN_STA1_1),
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_DISP, 
MT8183_TOP_AXI_PROT_EN_SET,
+   MT8183_TOP_AXI_PROT_EN_CLR, 
MT8183_TOP_AXI_PROT_EN_STA1),
+   },
+   .bp_smi = {
+   BUS_PROT_WR(MT8183_SMI_COMMON_SMI_CLAMP_DISP,
+   MT8183_SMI_COMMON_CLAMP_EN_SET,
+   MT8183_SMI_COMMON_CLAMP_EN_CLR,
+   MT8183_SMI_COMMON_CLAMP_EN),
+   },
+   },
+   [MT8183_POWER_DOMAIN_CAM] = {
+   .sta_mask = BIT(25),
+   .ctl_offs = 0x0344,
+   .sram_pdn_bits = GENMASK(9, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   .bp_infracfg = {
+   BUS_PROT_WR(MT8183_TOP_AXI_PROT_EN_MM_CAM, 
MT8183_TOP_AXI_PROT

[PATCH v4 03/16] arm64: dts: mediatek: Add mt8173 power domain controller

2020-10-30 Thread Enric Balletbo i Serra
Add power domain controller node for SoC mt8173.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add a scpsys syscon node as parent and a SPM (System Power Manager) as
  a child.

 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 164 ---
 1 file changed, 115 insertions(+), 49 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 5e046f9d48ce..7fa870e4386a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -450,16 +450,82 @@ pins1 {
};
};
 
-   scpsys: power-controller@10006000 {
-   compatible = "mediatek,mt8173-scpsys";
-   #power-domain-cells = <1>;
+   scpsys: syscon@10006000 {
+   compatible = "syscon", "simple-mfd";
reg = <0 0x10006000 0 0x1000>;
-   clocks = <>,
-< CLK_TOP_MM_SEL>,
-< CLK_TOP_VENC_SEL>,
-< CLK_TOP_VENC_LT_SEL>;
-   clock-names = "mfg", "mm", "venc", "venc_lt";
-   infracfg = <>;
+   #power-domain-cells = <1>;
+
+   /* System Power Manager */
+   spm: power-controller {
+   compatible = "mediatek,mt8173-power-controller";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+   /* power domains of the SoC */
+   power-domain@MT8173_POWER_DOMAIN_VDEC {
+   reg = ;
+   clocks = < CLK_TOP_MM_SEL>;
+   clock-names = "mm";
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_VENC {
+   reg = ;
+   clocks = < CLK_TOP_MM_SEL>,
+< CLK_TOP_VENC_SEL>;
+   clock-names = "mm", "venc";
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_ISP {
+   reg = ;
+   clocks = < CLK_TOP_MM_SEL>;
+   clock-names = "mm";
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_MM {
+   reg = ;
+   clocks = < CLK_TOP_MM_SEL>;
+   clock-names = "mm";
+   #power-domain-cells = <0>;
+   mediatek,infracfg = <>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_VENC_LT {
+   reg = ;
+   clocks = < CLK_TOP_MM_SEL>,
+< 
CLK_TOP_VENC_LT_SEL>;
+   clock-names = "mm", "venclt";
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_AUDIO {
+   reg = ;
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_USB {
+   reg = ;
+   #power-domain-cells = <0>;
+   };
+   power-domain@MT8173_POWER_DOMAIN_MFG_ASYNC {
+   reg = ;
+   clocks = <>;
+   clock-names = "mfg";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #power-domain-cells = <1>;
+
+

[PATCH v4 07/16] soc: mediatek: pm-domains: Add extra sram control

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

For some power domains like vpu_core on MT8183 whose sram need to do clock
and internal isolation while power on/off sram. We add a cap
"MTK_SCPD_SRAM_ISO" to judge if we need to do the extra sram isolation
control or not.

Signed-off-by: Weiyi Lu 
Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
Seires-changes: 4
- Use the regmap_[clear|set]_bits helpers.

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Nit, split readl(ctl_addr) | pd->data->sram_pdn_bits in two lines.
- Use regmap API

 drivers/soc/mediatek/mtk-pm-domains.c | 23 +--
 drivers/soc/mediatek/mtk-pm-domains.h |  1 +
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index 8a21847464c2..a6f25933dbf0 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -24,6 +24,8 @@
 #define PWR_ON_BIT BIT(2)
 #define PWR_ON_2ND_BIT BIT(3)
 #define PWR_CLK_DIS_BITBIT(4)
+#define PWR_SRAM_CLKISO_BITBIT(5)
+#define PWR_SRAM_ISOINT_B_BIT  BIT(6)
 
 struct scpsys_domain {
struct generic_pm_domain genpd;
@@ -65,12 +67,23 @@ static int scpsys_sram_enable(struct scpsys_domain *pd)
u32 pdn_ack = pd->data->sram_pdn_ack_bits;
struct scpsys *scpsys = pd->scpsys;
unsigned int tmp;
+   int ret;
 
regmap_clear_bits(scpsys->base, pd->data->ctl_offs, 
pd->data->sram_pdn_bits);
 
/* Either wait until SRAM_PDN_ACK all 1 or 0 */
-   return regmap_read_poll_timeout(scpsys->base, pd->data->ctl_offs, tmp,
-   (tmp & pdn_ack) == 0, 
MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+   ret = regmap_read_poll_timeout(scpsys->base, pd->data->ctl_offs, tmp,
+  (tmp & pdn_ack) == 0, MTK_POLL_DELAY_US, 
MTK_POLL_TIMEOUT);
+   if (ret < 0)
+   return ret;
+
+   if (MTK_SCPD_CAPS(pd, MTK_SCPD_SRAM_ISO)) {
+   regmap_set_bits(scpsys->base, pd->data->ctl_offs, 
PWR_SRAM_ISOINT_B_BIT);
+   udelay(1);
+   regmap_clear_bits(scpsys->base, pd->data->ctl_offs, 
PWR_SRAM_CLKISO_BIT);
+   }
+
+   return 0;
 }
 
 static int scpsys_sram_disable(struct scpsys_domain *pd)
@@ -79,6 +92,12 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
struct scpsys *scpsys = pd->scpsys;
unsigned int tmp;
 
+   if (MTK_SCPD_CAPS(pd, MTK_SCPD_SRAM_ISO)) {
+   regmap_set_bits(scpsys->base, pd->data->ctl_offs, 
PWR_SRAM_CLKISO_BIT);
+   udelay(1);
+   regmap_clear_bits(scpsys->base, pd->data->ctl_offs, 
PWR_SRAM_ISOINT_B_BIT);
+   }
+
regmap_set_bits(scpsys->base, pd->data->ctl_offs, 
pd->data->sram_pdn_bits);
 
/* Either wait until SRAM_PDN_ACK all 1 or 0 */
diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
b/drivers/soc/mediatek/mtk-pm-domains.h
index c2defbdcdf31..f190a0d9e592 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.h
+++ b/drivers/soc/mediatek/mtk-pm-domains.h
@@ -5,6 +5,7 @@
 
 #define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
 #define MTK_SCPD_FWAIT_SRAMBIT(1)
+#define MTK_SCPD_SRAM_ISO  BIT(2)
 #define MTK_SCPD_CAPS(_scpd, _x)   ((_scpd)->data->caps & (_x))
 
 #define SPM_VDE_PWR_CON0x0210
-- 
2.28.0



[PATCH v4 12/16] arm64: dts: mediatek: Add smi_common node for MT8183

2020-10-30 Thread Enric Balletbo i Serra
The SMI (Smart Multimedia Interface) Common is a bridge between the m4u
(Multimedia Memory Management Unit) and the Multimedia HW. This block is
needed to support different multimedia features, like display, video
decode, and camera. Also is needed to control the power domains of such
HW blocks.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 9cfd961c45eb..c06778d21c4f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -765,6 +765,16 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
 
+   smi_common: smi@14019000 {
+   compatible = "mediatek,mt8183-smi-common", "syscon";
+   reg = <0 0x14019000 0 0x1000>;
+   clocks = < CLK_MM_SMI_COMMON>,
+< CLK_MM_SMI_COMMON>,
+< CLK_MM_GALS_COMM0>,
+< CLK_MM_GALS_COMM1>;
+   clock-names = "apb", "smi", "gals0", "gals1";
+   };
+
imgsys: syscon@1502 {
compatible = "mediatek,mt8183-imgsys", "syscon";
reg = <0 0x1502 0 0x1000>;
-- 
2.28.0



[PATCH v4 04/16] soc: mediatek: pm-domains: Add bus protection protocol

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

Bus protection will need to update more then one register
in infracfg. Add support for several operations.

Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4:
- Define SPM_MAX_BUS_PROT_DATA to 5 to be compatible with MT8192
- Disable the bus protection in the reverse order for 
scpsys_bus_protect_disable().

Changes in v3: None
Changes in v2: None

 drivers/soc/mediatek/mt8173-pm-domains.h |  4 +--
 drivers/soc/mediatek/mtk-pm-domains.c| 36 +---
 drivers/soc/mediatek/mtk-pm-domains.h|  4 ++-
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/drivers/soc/mediatek/mt8173-pm-domains.h 
b/drivers/soc/mediatek/mt8173-pm-domains.h
index 5f2b5d4ad02b..72b3acaf74fb 100644
--- a/drivers/soc/mediatek/mt8173-pm-domains.h
+++ b/drivers/soc/mediatek/mt8173-pm-domains.h
@@ -34,7 +34,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
.sram_pdn_ack_bits = GENMASK(12, 12),
-   .bp_infracfg = {
+   .bp_infracfg[0] = {
.bus_prot_reg_update = true,
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
MT8173_TOP_AXI_PROT_EN_MM_M1,
@@ -76,7 +76,7 @@ static const struct scpsys_domain_data 
scpsys_domain_data_mt8173[] = {
.ctl_offs = SPM_MFG_PWR_CON,
.sram_pdn_bits = GENMASK(13, 8),
.sram_pdn_ack_bits = GENMASK(21, 16),
-   .bp_infracfg = {
+   .bp_infracfg[0] = {
.bus_prot_reg_update = true,
.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
MT8173_TOP_AXI_PROT_EN_MFG_M0 |
diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index f8e88308f2e0..06a16e45356a 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -88,24 +88,40 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
 
 static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
 {
-   const struct scpsys_bus_prot_data *bp_data = >data->bp_infracfg;
+   const struct scpsys_bus_prot_data *bpd = pd->data->bp_infracfg;
+   int i, ret;
 
-   if (!bp_data->bus_prot_mask)
-   return 0;
+   for (i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
+   if (!bpd[i].bus_prot_mask)
+   break;
 
-   return mtk_infracfg_set_bus_protection(pd->infracfg, 
bp_data->bus_prot_mask,
-  bp_data->bus_prot_reg_update);
+   ret = mtk_infracfg_set_bus_protection(pd->infracfg,
+ bpd[i].bus_prot_mask,
+ 
bpd[i].bus_prot_reg_update);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
 }
 
 static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
 {
-   const struct scpsys_bus_prot_data *bp_data = >data->bp_infracfg;
+   const struct scpsys_bus_prot_data *bpd = pd->data->bp_infracfg;
+   int i, ret;
 
-   if (!bp_data->bus_prot_mask)
-   return 0;
+   for (i = SPM_MAX_BUS_PROT_DATA; i > 0; i--) {
+   if (!bpd[i].bus_prot_mask)
+   continue;
 
-   return mtk_infracfg_clear_bus_protection(pd->infracfg, 
bp_data->bus_prot_mask,
-bp_data->bus_prot_reg_update);
+   ret = mtk_infracfg_clear_bus_protection(pd->infracfg,
+   bpd[i].bus_prot_mask,
+   
bpd[i].bus_prot_reg_update);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
 }
 
 static int scpsys_power_on(struct generic_pm_domain *genpd)
diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
b/drivers/soc/mediatek/mtk-pm-domains.h
index 7c479021d404..125880a58170 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.h
+++ b/drivers/soc/mediatek/mtk-pm-domains.h
@@ -32,6 +32,8 @@
 #define PWR_STATUS_AUDIO   BIT(24)
 #define PWR_STATUS_USB BIT(25)
 
+#define SPM_MAX_BUS_PROT_DATA  5
+
 struct scpsys_bus_prot_data {
u32 bus_prot_mask;
bool bus_prot_reg_update;
@@ -52,7 +54,7 @@ struct scpsys_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u8 caps;
-   const struct scpsys_bus_prot_data bp_infracfg;
+   const struct scpsys_bus_prot_data bp_infracfg[SPM_MAX_BUS_PROT_DATA];
 };
 
 struct scpsys_soc_data {
-- 
2.28.0



[PATCH v4 08/16] soc: mediatek: pm-domains: Add subsystem clocks

2020-10-30 Thread Enric Balletbo i Serra
From: Matthias Brugger 

For the bus protection operations, some subsystem clocks need to be enabled
before releasing the protection. This patch identifies the subsystem clocks
by it's name.

Suggested-by: Weiyi Lu 
[Adapted the patch to the mtk-pm-domains driver]
Signed-off-by: Matthias Brugger 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v4: None
Changes in v3:
- Prepare the basic clocks before we prepare the subsystem clocks.

Changes in v2:
- Use dev_err_probe if getting clocks fails, so an error is not printed
  if is deferred.

 drivers/soc/mediatek/mtk-pm-domains.c | 81 +++
 drivers/soc/mediatek/mtk-pm-domains.h |  2 +
 2 files changed, 72 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pm-domains.c 
b/drivers/soc/mediatek/mtk-pm-domains.c
index a6f25933dbf0..88dec58aedd9 100644
--- a/drivers/soc/mediatek/mtk-pm-domains.c
+++ b/drivers/soc/mediatek/mtk-pm-domains.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2020 Collabora Ltd.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,8 @@ struct scpsys_domain {
struct scpsys *scpsys;
int num_clks;
struct clk_bulk_data *clks;
+   int num_subsys_clks;
+   struct clk_bulk_data *subsys_clks;
struct regmap *infracfg;
struct regmap *smi;
 };
@@ -204,9 +207,13 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
regmap_clear_bits(scpsys->base, pd->data->ctl_offs, PWR_ISO_BIT);
regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_RST_B_BIT);
 
+   ret = clk_bulk_enable(pd->num_subsys_clks, pd->subsys_clks);
+   if (ret)
+   goto err_pwr_ack;
+
ret = scpsys_sram_enable(pd);
if (ret < 0)
-   goto err_pwr_ack;
+   goto err_disable_subsys_clks;
 
ret = scpsys_bus_protect_disable(pd);
if (ret < 0)
@@ -216,6 +223,8 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
 
 err_disable_sram:
scpsys_sram_disable(pd);
+err_disable_subsys_clks:
+   clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
 err_pwr_ack:
clk_bulk_disable(pd->num_clks, pd->clks);
return ret;
@@ -236,6 +245,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
if (ret < 0)
return ret;
 
+   clk_bulk_disable(pd->num_subsys_clks, pd->subsys_clks);
+
/* subsys power off */
regmap_clear_bits(scpsys->base, pd->data->ctl_offs, PWR_RST_B_BIT);
regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_ISO_BIT);
@@ -259,7 +270,11 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
*scpsys, struct device_no
 {
const struct scpsys_domain_data *domain_data;
struct scpsys_domain *pd;
-   int i, ret;
+   struct property *prop;
+   const char *clk_name;
+   int i, ret, num_clks;
+   struct clk *clk;
+   int clk_ind = 0;
u32 id;
 
ret = of_property_read_u32(node, "reg", );
@@ -295,25 +310,62 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
*scpsys, struct device_no
if (IS_ERR(pd->smi))
return ERR_CAST(pd->smi);
 
-   pd->num_clks = of_clk_get_parent_count(node);
-   if (pd->num_clks > 0) {
+   num_clks = of_clk_get_parent_count(node);
+   if (num_clks > 0) {
+   /* Calculate number of subsys_clks */
+   of_property_for_each_string(node, "clock-names", prop, 
clk_name) {
+   char *subsys;
+
+   subsys = strchr(clk_name, '-');
+   if (subsys)
+   pd->num_subsys_clks++;
+   else
+   pd->num_clks++;
+   }
+
pd->clks = devm_kcalloc(scpsys->dev, pd->num_clks, 
sizeof(*pd->clks), GFP_KERNEL);
if (!pd->clks)
return ERR_PTR(-ENOMEM);
+
+   pd->subsys_clks = devm_kcalloc(scpsys->dev, pd->num_subsys_clks,
+  sizeof(*pd->subsys_clks), 
GFP_KERNEL);
+   if (!pd->subsys_clks)
+   return ERR_PTR(-ENOMEM);
+
}
 
for (i = 0; i < pd->num_clks; i++) {
-   pd->clks[i].clk = of_clk_get(node, i);
-   if (IS_ERR(pd->clks[i].clk)) {
-   dev_err(scpsys->dev, "%pOF: failed to get clk at index 
%d\n",
-   node, i);
-   return ERR_PTR(-EINVAL);
+   clk = of_clk_get(node, i);
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   dev_err_probe(scpsys->dev, ret,
+ "%pOF: failed to get clk at index %d: 
%d\n", node

Re: [PATCH v3 15/16] soc: mediatek: pm-domains: Add default power off flag

2020-10-30 Thread Enric Balletbo i Serra
Hi Weilyi and Matthias,

On 29/10/20 15:51, Matthias Brugger wrote:
> 
> 
> On 27/10/2020 12:18, Weiyi Lu wrote:
>> On Tue, 2020-10-27 at 11:53 +0100, Matthias Brugger wrote:
>>>
>>> On 26/10/2020 18:55, Enric Balletbo i Serra wrote:
>>>> From: Weiyi Lu 
>>>>
>>>> For some power domain, like conn on MT8192, it should be default OFF.
>>>> Because the power on/off control relies the function of connectivity chip
>>>> and its firmware. And if project choose other chip vendor solution,
>>>> those necessary connectivity functions will not provided.
>>>>
>>>> Signed-off-by: Weiyi Lu 
>>>> Signed-off-by: Enric Balletbo i Serra 
>>>> ---
>>>>
>>>> Changes in v3: None
>>>> Changes in v2: None
>>>>
>>>>    drivers/soc/mediatek/mtk-pm-domains.c | 23 +--
>>>>    drivers/soc/mediatek/mtk-pm-domains.h |  1 +
>>>>    2 files changed, 18 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c
>>>> b/drivers/soc/mediatek/mtk-pm-domains.c
>>>> index 63993076a544..fe0e955076a0 100644
>>>> --- a/drivers/soc/mediatek/mtk-pm-domains.c
>>>> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
>>>> @@ -378,10 +378,16 @@ generic_pm_domain *scpsys_add_one_domain(struct 
>>>> scpsys
>>>> *scpsys, struct device_no
>>>>     * software.  The unused domains will be switched off during
>>>>     * late_init time.
>>>>     */
>>>> -    ret = scpsys_power_on(>genpd);
>>>> -    if (ret < 0) {
>>>> -    dev_err(scpsys->dev, "%pOF: failed to power on domain: %d\n", 
>>>> node,
>>>> ret);
>>>> -    goto err_unprepare_clocks;
>>>> +    if (MTK_SCPD_CAPS(pd, MTK_SCPD_KEEP_DEFAULT_OFF)) {
>>>> +    if (scpsys_domain_is_on(pd))
>>>> +    dev_warn(scpsys->dev,
>>>> + "%pOF: A default off power domain has been ON\n", node);
>>>> +    } else {
>>>> +    ret = scpsys_power_on(>genpd);
>>>> +    if (ret < 0) {
>>>> +    dev_err(scpsys->dev, "%pOF: failed to power on domain: %d\n",
>>>> node, ret);
>>>> +    goto err_unprepare_clocks;
>>>> +    }
>>>>    }
>>>>       if (scpsys->domains[id]) {
>>>> @@ -395,7 +401,11 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys
>>>> *scpsys, struct device_no
>>>>    pd->genpd.power_off = scpsys_power_off;
>>>>    pd->genpd.power_on = scpsys_power_on;
>>>>    -    pm_genpd_init(>genpd, NULL, false);
>>>> +    if (MTK_SCPD_CAPS(pd, MTK_SCPD_KEEP_DEFAULT_OFF))
>>>> +    pm_genpd_init(>genpd, NULL, true);
>>>> +    else
>>>> +    pm_genpd_init(>genpd, NULL, false);
>>>> +
>>>>    scpsys->domains[id] = >genpd;
>>>>       return scpsys->pd_data.domains[id];
>>>> @@ -478,7 +488,8 @@ static void scpsys_remove_one_domain(struct
>>>> scpsys_domain *pd)
>>>>    "failed to remove domain '%s' : %d - state may be
>>>> inconsistent\n",
>>>>    pd->genpd.name, ret);
>>>>    -    scpsys_power_off(>genpd);
>>>> +    if (!MTK_SCPD_CAPS(pd, MTK_SCPD_KEEP_DEFAULT_OFF))
>>>> +    scpsys_power_off(>genpd);
>>>
>>> OK, so you merged Weiyi's patches in this series :)
>>>
>>> So same comment here: Does it really hurt if we turn-off a already 
>>> turned-off
>>> power domain? Or can we get rid of this check?
>>>
>>
>> We do need this check here. If you try to turn-off this power domain,
>> you might make the clock or regulator reference count unbalanced.
>>
> 
> Correct. Could we check via scpsys_domain_is_on() instead? I'd like to avoid
> MTK_SCPD_KEEP_DEFAULT_OFF use here.
> 

So, I'm using scpsys_domain_is_on() now for this check and moved before
pm_genpd_remove call. I'll let you both to decide if is fine or not.

> Regards,
> Matthias
> 
>>> Regards,
>>> Matthias
>>>
>>>>       clk_bulk_unprepare(pd->num_clks, pd->clks);
>>>>    clk_bulk_put(pd->num_clks, pd->clks);
>>>> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h
>>>> b/drivers/soc/mediatek/mtk-pm-domains.h
>>>> index 2ad213be84a5..0fa6a938b40c 100644
>>>> --- a/drivers/soc/mediatek/mtk-pm-domains.h
>>>> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
>>>> @@ -6,6 +6,7 @@
>>>>    #define MTK_SCPD_ACTIVE_WAKEUP    BIT(0)
>>>>    #define MTK_SCPD_FWAIT_SRAM    BIT(1)
>>>>    #define MTK_SCPD_SRAM_ISO    BIT(2)
>>>> +#define MTK_SCPD_KEEP_DEFAULT_OFF    BIT(3)
>>>>    #define MTK_SCPD_CAPS(_scpd, _x)    ((_scpd)->data->caps & (_x))
>>>>       #define SPM_VDE_PWR_CON    0x0210
>>>>
>>


Re: [PATCH v3 06/16] soc: mediatek: pm-domains: Add SMI block as bus protection block

2020-10-30 Thread Enric Balletbo i Serra
Hi Nicolas,

Thank you for your comments.

On 27/10/20 3:44, Nicolas Boichat wrote:
> On Tue, Oct 27, 2020 at 1:55 AM Enric Balletbo i Serra
>  wrote:
>>
>> From: Matthias Brugger 
>>
>> Apart from the infracfg block, the SMI block is used to enable the bus
>> protection for some power domains. Add support for this block.
>>
>> Signed-off-by: Matthias Brugger 
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>
>> Changes in v3:
>> - Do not reuse bpd for 2 different things.
>> - Disable pd->smi first and after that pd->infracfg.
>> - Rename BUT_PROT_UPDATE_MT8173 to BUS_PROT_UPDATE_TOPAXI as in all the
>>   other SoCs TOPAXI is mapped to the same address.
>>
> [snip]
>>  static int scpsys_power_on(struct generic_pm_domain *genpd)
>> @@ -266,6 +271,10 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys 
>> *scpsys, struct device_no
>> if (IS_ERR(pd->infracfg))
>> pd->infracfg = NULL;
>>
>> +   pd->smi = syscon_regmap_lookup_by_phandle(node, "mediatek,smi");
>> +   if (IS_ERR(pd->smi))
>> +   pd->smi = NULL;
> 
> This is the second time I see this pattern, I think.
> 
> Do we want to create a new syscon_regmap_lookup_by_phandle_optional wrapper?
> 

I think could be useful, yes. So I sent a patch to add this wrapper, let's see
what the MFD maintainers think.

> Also, are we ok with ignoring all errors? I agree we can ignore
> -ENODEV if optional, but I'm not sure about the others.
> 

Right, we shouldn't ignore the other errors.

>> +
>> pd->num_clks = of_clk_get_parent_count(node);
>> if (pd->num_clks > 0) {
>> pd->clks = devm_kcalloc(scpsys->dev, pd->num_clks, 
>> sizeof(*pd->clks), GFP_KERNEL);
>> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h 
>> b/drivers/soc/mediatek/mtk-pm-domains.h
>> index e428fe23a7e3..7b1abcfc4ba3 100644
>> --- a/drivers/soc/mediatek/mtk-pm-domains.h
>> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
>> @@ -34,8 +34,31 @@
>>
>>  #define SPM_MAX_BUS_PROT_DATA  3
>>
>> +#define _BUS_PROT(_mask, _set, _clr, _sta, _update) {  \
>> +   .bus_prot_mask = (_mask),   \
>> +   .bus_prot_set = _set,   \
>> +   .bus_prot_clr = _clr,   \
>> +   .bus_prot_sta = _sta,   \
>> +   .bus_prot_reg_update = _update, \
>> +   }
>> +
>> +#define BUS_PROT_WR(_mask, _set, _clr, _sta)   \
>> +   _BUS_PROT(_mask, _set, _clr, _sta, false)
>> +
>> +#define BUS_PROT_UPDATE(_mask, _set, _clr, _sta)   \
>> +   _BUS_PROT(_mask, _set, _clr, _sta, true)
>> +
>> +#define BUS_PROT_UPDATE_TOPAXI(_mask)  \
>> +   BUS_PROT_UPDATE(_mask,  \
>> +   INFRA_TOPAXI_PROTECTEN, \
>> +   INFRA_TOPAXI_PROTECTEN_CLR, \
>> +   INFRA_TOPAXI_PROTECTSTA1)
>> +
>>  struct scpsys_bus_prot_data {
>> u32 bus_prot_mask;
>> +   u32 bus_prot_set;
>> +   u32 bus_prot_clr;
>> +   u32 bus_prot_sta;
>> bool bus_prot_reg_update;
>>  };
>>
>> @@ -47,6 +70,7 @@ struct scpsys_bus_prot_data {
>>   * @sram_pdn_ack_bits: The mask for sram power control acked bits.
>>   * @caps: The flag for active wake-up action.
>>   * @bp_infracfg: bus protection for infracfg subsystem
>> + * @bp_smi: bus protection for smi subsystem
>>   */
>>  struct scpsys_domain_data {
>> u32 sta_mask;
>> @@ -55,6 +79,7 @@ struct scpsys_domain_data {
>> u32 sram_pdn_ack_bits;
>> u8 caps;
>> const struct scpsys_bus_prot_data bp_infracfg[SPM_MAX_BUS_PROT_DATA];
>> +   const struct scpsys_bus_prot_data bp_smi[SPM_MAX_BUS_PROT_DATA];
>>  };
>>
>>  struct scpsys_soc_data {
>> --
>> 2.28.0
>>


  1   2   3   4   5   6   7   8   9   10   >