* [PATCH] ARM: dts: aspeed: remove unhandled fttmr010,pwm-outputs
From: Corentin Labbe @ 2022-01-27 12:19 UTC (permalink / raw)
To: a.kartashev, andrew, joel, robh+dt
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Corentin Labbe
fttmr010,pwm-outputs is not handled by its timer driver, so this
property is useless.
Fixes: 67ac01d03862 ("ARM: dts: aspeed: add device tree for YADRO VEGMAN BMC")
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
arch/arm/boot/dts/aspeed-bmc-vegman.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
index 1a5b25b2ea29..43af63910571 100644
--- a/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
+++ b/arch/arm/boot/dts/aspeed-bmc-vegman.dtsi
@@ -166,7 +166,6 @@ &sdhci1 {
};
&timer {
- fttmr010,pwm-outputs = <5>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_timer5_default>;
#pwm-cells = <3>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: mt8195: add display node for vdosys0
From: AngeloGioacchino Del Regno @ 2022-01-27 12:06 UTC (permalink / raw)
To: jason-jh.lin, Rob Herring, Linus Walleij, Matthias Brugger,
Paolo Bonzini, Sean Christopherson, maciej.szmigiero,
David Matlack, Jing Zhang, Marc Zyngier, Bartosz Golaszewski,
Sean Wang, Tinghan Shen
Cc: devicetree, linux-arm-kernel, linux-mediatek, linux-kernel,
Project_Global_Chrome_Upstream_Group, ryder.lee, wenst,
chunfeng.yun, Seiya Wang, moudy.ho, roy-cw.yeh, nancy.lin,
singo.chang, Macpaul.Lin
In-Reply-To: <20220126093340.18792-1-jason-jh.lin@mediatek.com>
Il 26/01/22 10:33, jason-jh.lin ha scritto:
> Add display node for vdosys0.
>
> Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com>
> ---
> This patch depends on series [1]
> [1] Add Mediatek Soc DRM (vdosys0) support for mt8195
> - https://patchwork.kernel.org/project/linux-mediatek/list/?series=608548
>
> This patch is based on [2][3][4]
> [2] arm64: dts: Add mediatek SoC mt8195 and evaluation board
> - https://patchwork.kernel.org/project/linux-mediatek/patch/20220112114724.1953-4-tinghan.shen@mediatek.com/
> [3] arm64: dts: mt8195: add IOMMU and smi nodes
> - https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26682-15-tinghan.shen@mediatek.com/
> [4] arm64: dts: mt8195: add gce node
> - https://patchwork.kernel.org/project/linux-mediatek/patch/20220126090109.32143-1-jason-jh.lin@mediatek.com/
> ---
> arch/arm64/boot/dts/mediatek/mt8195.dtsi | 123 +++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> index d778ca598d18..cc3a9e898c77 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> @@ -1067,5 +1067,128 @@
> reg = <0 0x1b000000 0 0x1000>;
> #clock-cells = <1>;
> };
> +
> + ovl0: disp_ovl@1c000000 {
Please be consistent with the other SoC DTs: call this ovl@1c000000
> + compatible = "mediatek,mt8195-disp-ovl",
> + "mediatek,mt8192-disp-ovl";
> + reg = <0 0x1c000000 0 0x1000>;
> + interrupts = <GIC_SPI 636 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>;
> + iommus = <&iommu_vdo M4U_PORT_L0_DISP_OVL0_RDMA0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x0000 0x1000>;
> + };
> +
> + rdma0: disp_rdma@1c002000 {
...this is just rdma
> + compatible = "mediatek,mt8195-disp-rdma";
> + reg = <0 0x1c002000 0 0x1000>;
> + interrupts = <GIC_SPI 638 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_RDMA0>;
> + iommus = <&iommu_vdo M4U_PORT_L0_DISP_RDMA0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x2000 0x1000>;
> + };
> +
> + color0: disp_color@1c003000 {
color@...
> + compatible = "mediatek,mt8195-disp-color",
> + "mediatek,mt8173-disp-color";
> + reg = <0 0x1c003000 0 0x1000>;
> + interrupts = <GIC_SPI 639 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_COLOR0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x3000 0x1000>;
> + };
> +
> + ccorr0: disp_ccorr@1c004000 {
ccorr@...
> + compatible = "mediatek,mt8195-disp-ccorr",
> + "mediatek,mt8192-disp-ccorr";
> + reg = <0 0x1c004000 0 0x1000>;
> + interrupts = <GIC_SPI 640 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_CCORR0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x4000 0x1000>;
> + };
> +
> + aal0: disp_aal@1c005000 {
aal@...
> + compatible = "mediatek,mt8195-disp-aal",
> + "mediatek,mt8173-disp-aal";
> + reg = <0 0x1c005000 0 0x1000>;
> + interrupts = <GIC_SPI 641 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_AAL0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x5000 0x1000>;
> + };
> +
> + gamma0: disp_gamma@1c006000 {
gamma@...
> + compatible = "mediatek,mt8195-disp-gamma",
> + "mediatek,mt8173-disp-gamma";
> + reg = <0 0x1c006000 0 0x1000>;
> + interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_GAMMA0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x6000 0x1000>;
> + };
> +
> + dither0: disp_dither@1c007000 {
dither@....
> + compatible = "mediatek,mt8195-disp-dither",
> + "mediatek,mt8183-disp-dither";
> + reg = <0 0x1c007000 0 0x1000>;
> + interrupts = <GIC_SPI 643 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_DITHER0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x7000 0x1000>;
> + };
> +
> + dsc0: disp_dsc_wrap@1c009000 {
dsc@...
> + compatible = "mediatek,mt8195-disp-dsc";
> + reg = <0 0x1c009000 0 0x1000>;
> + interrupts = <GIC_SPI 645 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c00XXXX 0x9000 0x1000>;
> + };
> +
> + merge0: disp_vpp_merge0@1c014000 {
merge@...
> + compatible = "mediatek,mt8195-disp-merge";
> + reg = <0 0x1c014000 0 0x1000>;
> + interrupts = <GIC_SPI 656 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_VPP_MERGE0>;
> + mediatek,gce-client-reg =
> + <&gce0 SUBSYS_1c01XXXX 0x4000 0x1000>;
> + };
> +
> + mutex: disp_mutex0@1c016000 {
mutex@....
> + compatible = "mediatek,mt8195-disp-mutex";
> + reg = <0 0x1c016000 0 0x1000>;
> + reg-names = "vdo0_mutex";
> + interrupts = <GIC_SPI 658 IRQ_TYPE_LEVEL_HIGH 0>;
> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>;
> + clocks = <&vdosys0 CLK_VDO0_DISP_MUTEX0>;
> + clock-names = "vdo0_mutex";
> + mediatek,gce-events =
> + <CMDQ_EVENT_VDO0_DISP_STREAM_DONE_0>;
> + };
> +
> + vdosys0: syscon@1c01a000 {
> + compatible = "mediatek,mt8195-vdosys0", "syscon";
> + reg = <0 0x1c01a000 0 0x1000>;
> + mboxes = <&gce0 0 CMDQ_THR_PRIO_4>;
> + #clock-cells = <1>;
> + };
> +
> + vdosys1: syscon@1c100000 {
> + compatible = "mediatek,mt8195-vdosys1", "syscon";
> + reg = <0 0x1c100000 0 0x1000>;
> + #clock-cells = <1>;
> + };
> };
> };
>
Regards,
Angelo
^ permalink raw reply
* Re: [PATCH V4 3/6] soc: qcom: eud: Add driver support for Embedded USB Debugger(EUD)
From: Souradeep Chowdhury @ 2022-01-27 12:04 UTC (permalink / raw)
To: Greg KH
Cc: linux-arm-msm, linux-usb, devicetree, pure.logic, bjorn.andersson,
robh, linux-kernel, quic_tsoni, quic_psodagud, quic_satyap,
quic_pheragu, quic_rjendra, quic_sibis, quic_saipraka
In-Reply-To: <YfEUmuglZluWwsg2@kroah.com>
On 1/26/2022 3:00 PM, Greg KH wrote:
> On Fri, Jan 21, 2022 at 07:23:48PM +0530, Souradeep Chowdhury wrote:
>> Add support for control peripheral of EUD (Embedded USB Debugger) to
>> listen to events such as USB attach/detach, pet EUD to indicate software
>> is functional.Reusing the platform device kobj, sysfs entry 'enable' is
>> created to enable or disable EUD.
>>
>> To enable the eud the following needs to be done
>> echo 1 > /sys/bus/platform/.../enable
>>
>> To disable eud, following is the command
>> echo 0 > /sys/bus/platform/.../enable
>>
>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> ---
>> Documentation/ABI/testing/sysfs-driver-eud | 9 ++
>> drivers/soc/qcom/Kconfig | 10 ++
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/qcom_eud.c | 250 +++++++++++++++++++++++++++++
> This should go under drivers/usb/ as it's creating a USB generic
> user/kernel api that all future devices of this type must follow.
Ack. Will move this to drivers/usb.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH V4 3/6] soc: qcom: eud: Add driver support for Embedded USB Debugger(EUD)
From: Souradeep Chowdhury @ 2022-01-27 12:01 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-arm-msm, linux-usb, devicetree, pure.logic, greg, robh,
linux-kernel, quic_tsoni, quic_psodagud, quic_satyap,
quic_pheragu, quic_rjendra, quic_sibis, quic_saipraka
In-Reply-To: <YfDSZTZOryQuWIlJ@builder.lan>
On 1/26/2022 10:17 AM, Bjorn Andersson wrote:
> On Fri 21 Jan 07:53 CST 2022, Souradeep Chowdhury wrote:
>
>> Add support for control peripheral of EUD (Embedded USB Debugger) to
>> listen to events such as USB attach/detach, pet EUD to indicate software
>> is functional.Reusing the platform device kobj, sysfs entry 'enable' is
>> created to enable or disable EUD.
>>
>> To enable the eud the following needs to be done
>> echo 1 > /sys/bus/platform/.../enable
>>
>> To disable eud, following is the command
>> echo 0 > /sys/bus/platform/.../enable
>>
>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> ---
>> Documentation/ABI/testing/sysfs-driver-eud | 9 ++
>> drivers/soc/qcom/Kconfig | 10 ++
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/qcom_eud.c | 250 +++++++++++++++++++++++++++++
>> 4 files changed, 270 insertions(+)
>> create mode 100644 Documentation/ABI/testing/sysfs-driver-eud
>> create mode 100644 drivers/soc/qcom/qcom_eud.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud
>> new file mode 100644
>> index 0000000..2381552
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-driver-eud
>> @@ -0,0 +1,9 @@
>> +What: /sys/bus/platform/drivers/eud/.../enable
>> +Date: January 2022
>> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> +Description:
>> + The Enable/Disable sysfs interface for Embedded
>> + USB Debugger(EUD). This enables and disables the
>> + EUD based on a 1 or a 0 value. By enabling EUD,
>> + the user is able to activate the mini-usb hub of
>> + EUD for debug and trace capabilities.
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index e718b87..abc6be0 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -42,6 +42,16 @@ config QCOM_CPR
>> To compile this driver as a module, choose M here: the module will
>> be called qcom-cpr
>>
>> +config QCOM_EUD
>> + tristate "QCOM Embedded USB Debugger(EUD) Driver"
> The indentation looks off here.
Ack
>
>> + select USB_ROLE_SWITCH
>> + help
>> + This module enables support for Qualcomm Technologies, Inc.
>> + Embedded USB Debugger (EUD). The EUD is a control peripheral
>> + which reports VBUS attach/detach events and has USB-based
>> + debug and trace capabilities. On selecting m, the module name
>> + that is built is qcom_eud.ko
>> +
>> config QCOM_GENI_SE
>> tristate "QCOM GENI Serial Engine Driver"
>> depends on ARCH_QCOM || COMPILE_TEST
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 70d5de6..e0c7d2d 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -4,6 +4,7 @@ obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
>> obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
>> obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>> obj-$(CONFIG_QCOM_CPR) += cpr.o
>> +obj-$(CONFIG_QCOM_EUD) += qcom_eud.o
>> obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
>> obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o
>> obj-$(CONFIG_QCOM_OCMEM) += ocmem.o
>> diff --git a/drivers/soc/qcom/qcom_eud.c b/drivers/soc/qcom/qcom_eud.c
>> new file mode 100644
>> index 0000000..a538645
>> --- /dev/null
>> +++ b/drivers/soc/qcom/qcom_eud.c
>> @@ -0,0 +1,250 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/usb/role.h>
>> +
>> +#define EUD_REG_INT1_EN_MASK 0x0024
>> +#define EUD_REG_INT_STATUS_1 0x0044
>> +#define EUD_REG_CTL_OUT_1 0x0074
>> +#define EUD_REG_VBUS_INT_CLR 0x0080
>> +#define EUD_REG_CSR_EUD_EN 0x1014
>> +#define EUD_REG_SW_ATTACH_DET 0x1018
>> +#define EUD_REG_EUD_EN2 0x0000
>> +
>> +#define EUD_ENABLE BIT(0)
>> +#define EUD_INT_PET_EUD BIT(0)
>> +#define EUD_INT_VBUS BIT(2)
>> +#define EUD_INT_SAFE_MODE BIT(4)
>> +#define EUD_INT_ALL (EUD_INT_VBUS|EUD_INT_SAFE_MODE)
>> +
>> +struct eud_chip {
>> + struct device *dev;
>> + struct usb_role_switch *role_sw;
>> + void __iomem *base;
>> + void __iomem *mode_mgr;
>> + unsigned int int_status;
>> + int irq;
>> + bool enabled;
>> + bool usb_attached;
>> +};
>> +
>> +static int enable_eud(struct eud_chip *priv)
>> +{
>> + writel(EUD_ENABLE, priv->base + EUD_REG_CSR_EUD_EN);
>> + writel(EUD_INT_VBUS | EUD_INT_SAFE_MODE,
>> + priv->base + EUD_REG_INT1_EN_MASK);
>> + writel(1, priv->mode_mgr + EUD_REG_EUD_EN2);
>> +
>> + return usb_role_switch_set_role(priv->role_sw, USB_ROLE_DEVICE);
> So we won't get EUD_INT_VBUS when we enable the EUD and can rely on the
> irq handler to set the role?
Yes, in this case it is being explicitly set based on the user input
rather than through irq handler.
In this way we are able to detect if the role is set properly and take
the next steps from the
enable_store method.
>
>> +}
>> +
>> +static void disable_eud(struct eud_chip *priv)
>> +{
>> + writel(0, priv->base + EUD_REG_CSR_EUD_EN);
>> + writel(0, priv->mode_mgr + EUD_REG_EUD_EN2);
>> +}
>> +
>> +static ssize_t enable_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct eud_chip *chip = dev_get_drvdata(dev);
>> +
>> + return sysfs_emit(buf, "%d\n", chip->enabled);
>> +}
>> +
>> +static ssize_t enable_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct eud_chip *chip = dev_get_drvdata(dev);
>> + bool enable;
>> + int ret;
>> +
>> + if (kstrtobool(buf, &enable))
>> + return -EINVAL;
>> +
>> + if (enable) {
>> + ret = enable_eud(chip);
>> + if (!ret)
>> + chip->enabled = enable;
>> + else
>> + disable_eud(chip);
>> + } else {
>> + disable_eud(chip);
>> + }
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(enable);
>> +
>> +static struct attribute *eud_attrs[] = {
>> + &dev_attr_enable.attr,
>> + NULL,
>> +};
>> +ATTRIBUTE_GROUPS(eud);
>> +
>> +static void usb_attach_detach(struct eud_chip *chip)
>> +{
>> + u32 reg;
>> +
>> + /* read ctl_out_1[4] to find USB attach or detach event */
>> + reg = readl(chip->base + EUD_REG_CTL_OUT_1);
>> + chip->usb_attached = reg & EUD_INT_SAFE_MODE;
>> +}
>> +
>> +static void pet_eud(struct eud_chip *chip)
>> +{
>> + u32 reg;
>> + int ret;
>> +
>> + /* When the EUD_INT_PET_EUD in SW_ATTACH_DET is set, the cable has been
>> + * disconnected and we need to detach the pet to check if EUD is in safe
>> + * mode before attaching again.
>> + */
>> + reg = readl(chip->base + EUD_REG_SW_ATTACH_DET);
>> + if (reg & EUD_INT_PET_EUD) {
>> + /* Detach & Attach pet for EUD */
>> + writel(0, chip->base + EUD_REG_SW_ATTACH_DET);
>> + /* Delay to make sure detach pet is done before attach pet */
>> + ret = readl_poll_timeout(chip->base + EUD_REG_SW_ATTACH_DET,
>> + reg, (reg == 0), 1, 100);
>> + if (ret) {
>> + dev_err(chip->dev, "Detach pet failed\n");
>> + return;
>> + }
>> + }
>> + /* Attach pet for EUD */
>> + writel(EUD_INT_PET_EUD, chip->base +EUD_REG_SW_ATTACH_DET);
>> +}
>> +
>> +static irqreturn_t handle_eud_irq(int irq, void *data)
>> +{
>> + struct eud_chip *chip = data;
>> + u32 reg;
>> +
>> + reg = readl(chip->base + EUD_REG_INT_STATUS_1);
>> + switch (reg & EUD_INT_ALL) {
>> + case EUD_INT_VBUS:
>> + chip->int_status = EUD_INT_VBUS;
> The first time that reg & EUD_INT_VBUS is set, you assign int_status
> EUD_INT_VBUS, you never clear it again.
>
> This is also the only path where you wake up the thread, so int_status
> will always be EUD_INT_VBUS when you reach handle_eud_irq_thread().
>
> Which means that int_status serves no purpose and if you're happy with
> how this implementation currently works you can just drop "int_status"
> and the conditional below.
Ack. Will remove the int_status flag as it is not needed.
>
>> + usb_attach_detach(chip);
>> + return IRQ_WAKE_THREAD;
>> + case EUD_INT_SAFE_MODE:
>> + pet_eud(chip);
>> + return IRQ_HANDLED;
>> + default:
>> + return IRQ_NONE;
>> + }
>> +}
>> +
>> +static irqreturn_t handle_eud_irq_thread(int irq, void *data)
>> +{
>> + struct eud_chip *chip = data;
>> + int ret;
>> +
>> + if (chip->int_status == EUD_INT_VBUS) {
>> + if (chip->usb_attached)
>> + ret = usb_role_switch_set_role(chip->role_sw, USB_ROLE_DEVICE);
>> + else
>> + ret = usb_role_switch_set_role(chip->role_sw, USB_ROLE_HOST);
>> + if (ret)
>> + dev_err(chip->dev, "failed to set role switch\n");
>> + }
>> +
>> + /* set and clear vbus_int_clr[0] to clear interrupt */
>> + writel(BIT(0), chip->base + EUD_REG_VBUS_INT_CLR);
>> + writel(0, chip->base + EUD_REG_VBUS_INT_CLR);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int eud_probe(struct platform_device *pdev)
>> +{
>> + struct eud_chip *chip;
>> + struct fwnode_handle *fwnode = pdev->dev.fwnode, *dwc3;
>> + int ret;
>> +
>> + chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
>> + if (!chip)
>> + return -ENOMEM;
>> +
>> + chip->dev = &pdev->dev;
>> +
>> + dwc3 = fwnode_graph_get_next_endpoint(fwnode, NULL);
> This will pick the first endpoint, but if you instead use
>
> chip->role_sw = usb_role_switch_get(&pdev->dev);
>
> you should get whichever port that points to a usb-role-switch node,
> without having to do the fwnode dance (and refcounting, which you forgot
> to release).
Ack
>
>> + if (!dwc3)
>> + return -ENODEV;
>> +
>> + chip->role_sw = fwnode_usb_role_switch_get(dwc3);
>> + if (IS_ERR(chip->role_sw)) {
>> + ret = PTR_ERR(chip->role_sw);
>> + usb_role_switch_put(chip->role_sw);
> You don't need to return the role_sw if it's IS_ERR().
Ack
>
>> + return dev_err_probe(chip->dev, ret,
>> + "failed to get role switch\n");
>> + }
>> +
>> + chip->base = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(chip->base))
> You're not usb_role_switch_put() your role_sw here, or below return
> cases. I would recommend devm_add_action_or_reset() to avoid the hassle
> of adding the necessary cleanup logic.
Ack
>
>> + return PTR_ERR(chip->base);
>> +
>> + chip->mode_mgr = devm_platform_ioremap_resource(pdev, 1);
>> + if (IS_ERR(chip->mode_mgr))
>> + return PTR_ERR(chip->mode_mgr);
>> +
>> + chip->irq = platform_get_irq(pdev, 0);
>> + ret = devm_request_threaded_irq(&pdev->dev, chip->irq, handle_eud_irq,
>> + handle_eud_irq_thread, IRQF_ONESHOT, NULL, chip);
>> + if (ret)
>> + return dev_err_probe(chip->dev, ret, "failed to allocate irq\n");
>> +
>> + enable_irq_wake(chip->irq);
>> +
>> + platform_set_drvdata(pdev, chip);
>> +
>> + return 0;
> Per the updated binding, the EUD would now be a usb-role-switch as well
> and when not enabled should simply propagate the incoming requests. So I
> was expecting this to register as a usb_role_switch as well...
Can you please elaborate on this?
Do I need to define a separate 'usb_role_switch_desc' here and register
using 'usb_role_switch_register'?
Also what should be the set method in this case for usb_role_switch_desc?
>
>> +}
>> +
>> +static int eud_remove(struct platform_device *pdev)
>> +{
>> + struct eud_chip *chip = platform_get_drvdata(pdev);
>> +
>> + if (chip->enabled)
>> + disable_eud(chip);
>> +
>> + device_init_wakeup(&pdev->dev, false);
>> + disable_irq_wake(chip->irq);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id eud_dt_match[] = {
>> + { .compatible = "qcom,sc7280-eud" },
> Do you see any reason for not just adding qcom,eud here? Are there any
> differences from other platforms that has this block that means that we
> need per-platform driver support (the dts should have both
> compatibles still)?
That is correct, this might need driver support for multiple platforms.
>
> Regards,
> Bjorn
>
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, eud_dt_match);
>> +
>> +static struct platform_driver eud_driver = {
>> + .probe = eud_probe,
>> + .remove = eud_remove,
>> + .driver = {
>> + .name = "qcom_eud",
>> + .dev_groups = eud_groups,
>> + .of_match_table = eud_dt_match,
>> + },
>> +};
>> +module_platform_driver(eud_driver);
>> +
>> +MODULE_DESCRIPTION("QTI EUD driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.7.4
>>
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Oleksij Rempel @ 2022-01-27 12:00 UTC (permalink / raw)
To: Greg KH
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree, Andrew Lunn,
Vivien Didelot, Florian Fainelli, Vladimir Oltean
In-Reply-To: <YfKCTG7N86yy74q+@kroah.com>
On Thu, Jan 27, 2022 at 12:30:20PM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> > On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > > Similar to the option to set a netdev name in device tree for switch
> > > > ports by using the property "label" in the DSA framework, this patch
> > > > adds this functionality to the usbnet infrastructure.
> > > >
> > > > This will help to name the interfaces properly throughout supported
> > > > devices. This provides stable interface names which are useful
> > > > especially in embedded use cases.
> > >
> > > Stable interface names are for userspace to set, not the kernel.
> > >
> > > Why would USB care about this? If you need something like this, get it
> > > from the USB device itself, not DT, which should have nothing to do with
> > > USB as USB is a dynamic, self-describing, bus. Unlike DT.
> > >
> > > So I do not think this is a good idea.
> >
> > This is needed for embedded devices with integrated USB Ethernet
> > controller. Currently I have following use cases to solve:
> > - Board with one or multiple USB Ethernet controllers with external PHY.
> > The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
>
> The phy is for the USB controller, not the Ethernet controller, right?
> If for the ethernet controller, ugh, that's a crazy design and I would
> argue a broken one. But whatever, DT should not be used to describe a
> USB device itself.
>
> > - Board with USB Ethernet controller with DSA switch. The USB ethernet
> > controller is attached to the CPU port of DSA switch. In this case,
> > DSA switch is the sub-node of the USB device.
>
> What do you mean exactly by "sub node"? USB does not have such a term.
Here are some examples:
- |
usb@11270000 {
reg = <0x11270000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
ethernet@1 {
compatible = "usb424,ec00";
reg = <1>;
label = "LAN0";
// there is no internal eeprom, so MAC address is taken from
// NVMEM of the SoC.
local-mac-address = [00 00 00 00 00 00];
mdio {
ethernet-phy@4 {
reg = <4>;
// Interrupt is attached to the SoC or the GPIO
// controller of the same USB devices.
interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
// same about reset. It is attached to the SoC
// or GPIO controller of the USB device.
reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
reset-assert-us = <10000>;
reset-deassert-us = <1000>;
// some external clock provider
clocks = <&clk>
qca,smarteee-tw-us-1g = <24>;
qca,clk-out-frequency = <125000000>;
};
};
};
};
- |
usb@11270000 {
reg = <0x11270000 0x1000>;
#address-cells = <1>;
#size-cells = <0>;
usb1@1 {
compatible = "usb424,9514";
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
eth0: ethernet@1 {
compatible = "usb424,ec00";
reg = <1>;
label = "cpu0";
fixed-link {
speed = <1000>;
full-duplex;
};
// managment interface of the switch is attached to the
// MDIO bus of this USB device.
mdio {
switch@0 {
compatible = "microchip,ksz9477";
reg = <0>;
// reset is controlled by the SoC or by the GPIO
// controller of this USB device.
reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
port@3 {
reg = <3>;
label = "lan4";
};
port@4 {
reg = <4>;
label = "lan5";
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <ð0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
};
};
> > The CPU port should have
> > stable name for all device related to this product.
>
> name for who to use? Userspace? Or within the kernel?
>
> Naming is done by userspace, as USB is NOT determinisitic in numbering /
> naming the devices attached to it, by design. If you need to have a
> stable name, do so in userspace please, we have loads of tools that
> already do this there today. Let's not reinvent the wheel.
>
> > Using user space tools to name interfaces would double the maintenance
> > of similar information: DT - describing the HW + udev scripts describing
> > same HW again.
>
> Not for the network name of the device, that belongs in userspace.
>
> Do not be listing USB device ids in a DT file, that way lies madness.
>
> thanks,
>
> greg k-h
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 4/4] MAINTAINERS: add maintainer for ADMV1014 driver
From: Antoniu Miclaus @ 2022-01-27 10:55 UTC (permalink / raw)
To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus
In-Reply-To: <20220127105558.59567-1-antoniu.miclaus@analog.com>
Add myself as maintainer for the ADMV1014 driver.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 170bbbeefc3f..b05148cfd4aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1119,6 +1119,14 @@ W: http://ez.analog.com/community/linux-device-drivers
F: Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml
F: drivers/hwmon/adm1177.c
+ANALOG DEVICES INC ADMV1014 DRIVER
+M: Antoniu Miclaus <antoniu.miclaus@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
+F: drivers/iio/frequency/admv1014.c
+
ANALOG DEVICES INC ADP5061 DRIVER
M: Michael Hennerich <Michael.Hennerich@analog.com>
L: linux-pm@vger.kernel.org
--
2.35.0
^ permalink raw reply related
* [PATCH v4 3/4] Documentation:ABI:testing:admv1014: add ABI docs
From: Antoniu Miclaus @ 2022-01-27 10:55 UTC (permalink / raw)
To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus
In-Reply-To: <20220127105558.59567-1-antoniu.miclaus@analog.com>
Add documentation for the use of the Digital Attenuator gain.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
changes in v4:
- move `in_altvoltage_calibscale` to sysfs-bus-iio
Documentation/ABI/testing/sysfs-bus-iio | 7 ++++++
.../testing/sysfs-bus-iio-frequency-admv1014 | 23 +++++++++++++++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index c551301b33f1..d7d96d3d6b7c 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -476,6 +476,13 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Used in microwave converters to read/write value for the
+ digital attenuator gain (I/Q mode).
+
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014
new file mode 100644
index 000000000000..5bcd96d77f45
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014
@@ -0,0 +1,23 @@
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_coarse
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read/write value for the digital attenuator gain (IF_I) with coarse steps.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_coarse
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read/write value for the digital attenuator gain (IF_Q) with coarse steps.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_fine
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read/write value for the digital attenuator gain (IF_I) with fine steps.
+
+What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_fine
+KernelVersion:
+Contact: linux-iio@vger.kernel.org
+Description:
+ Read/write value for the digital attenuator gain (IF_Q) with fine steps.
--
2.35.0
^ permalink raw reply related
* [PATCH v4 1/4] iio:frequency:admv1014: add support for ADMV1014
From: Antoniu Miclaus @ 2022-01-27 10:55 UTC (permalink / raw)
To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus
The ADMV1014 is a silicon germanium (SiGe), wideband,
microwave downconverter optimized for point to point microwave
radio designs operating in the 24 GHz to 44 GHz frequency range.
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADMV1014.pdf
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
changes in v4:
- make regulators mandatory
- use regulator bulk get/enable
drivers/iio/frequency/Kconfig | 10 +
drivers/iio/frequency/Makefile | 1 +
drivers/iio/frequency/admv1014.c | 820 +++++++++++++++++++++++++++++++
3 files changed, 831 insertions(+)
create mode 100644 drivers/iio/frequency/admv1014.c
diff --git a/drivers/iio/frequency/Kconfig b/drivers/iio/frequency/Kconfig
index 2c9e0559e8a4..493221f42077 100644
--- a/drivers/iio/frequency/Kconfig
+++ b/drivers/iio/frequency/Kconfig
@@ -50,6 +50,16 @@ config ADF4371
To compile this driver as a module, choose M here: the
module will be called adf4371.
+config ADMV1014
+ tristate "Analog Devices ADMV1014 Microwave Downconverter"
+ depends on SPI && COMMON_CLK && 64BIT
+ help
+ Say yes here to build support for Analog Devices ADMV1014
+ 24 GHz to 44 GHz, Wideband, Microwave Downconverter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called admv1014.
+
config ADRF6780
tristate "Analog Devices ADRF6780 Microwave Upconverter"
depends on SPI
diff --git a/drivers/iio/frequency/Makefile b/drivers/iio/frequency/Makefile
index ae3136c79202..5f0348e5eb53 100644
--- a/drivers/iio/frequency/Makefile
+++ b/drivers/iio/frequency/Makefile
@@ -7,4 +7,5 @@
obj-$(CONFIG_AD9523) += ad9523.o
obj-$(CONFIG_ADF4350) += adf4350.o
obj-$(CONFIG_ADF4371) += adf4371.o
+obj-$(CONFIG_ADMV1014) += admv1014.o
obj-$(CONFIG_ADRF6780) += adrf6780.o
diff --git a/drivers/iio/frequency/admv1014.c b/drivers/iio/frequency/admv1014.c
new file mode 100644
index 000000000000..4ae422bd9bf4
--- /dev/null
+++ b/drivers/iio/frequency/admv1014.c
@@ -0,0 +1,820 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ADMV1014 driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/device.h>
+#include <linux/iio/iio.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/notifier.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+#include <linux/units.h>
+
+#include <asm/unaligned.h>
+
+/* ADMV1014 Register Map */
+#define ADMV1014_REG_SPI_CONTROL 0x00
+#define ADMV1014_REG_ALARM 0x01
+#define ADMV1014_REG_ALARM_MASKS 0x02
+#define ADMV1014_REG_ENABLE 0x03
+#define ADMV1014_REG_QUAD 0x04
+#define ADMV1014_REG_LO_AMP_PHASE_ADJUST1 0x05
+#define ADMV1014_REG_MIXER 0x07
+#define ADMV1014_REG_IF_AMP 0x08
+#define ADMV1014_REG_IF_AMP_BB_AMP 0x09
+#define ADMV1014_REG_BB_AMP_AGC 0x0A
+#define ADMV1014_REG_VVA_TEMP_COMP 0x0B
+
+/* ADMV1014_REG_SPI_CONTROL Map */
+#define ADMV1014_PARITY_EN_MSK BIT(15)
+#define ADMV1014_SPI_SOFT_RESET_MSK BIT(14)
+#define ADMV1014_CHIP_ID_MSK GENMASK(11, 4)
+#define ADMV1014_CHIP_ID 0x9
+#define ADMV1014_REVISION_ID_MSK GENMASK(3, 0)
+
+/* ADMV1014_REG_ALARM Map */
+#define ADMV1014_PARITY_ERROR_MSK BIT(15)
+#define ADMV1014_TOO_FEW_ERRORS_MSK BIT(14)
+#define ADMV1014_TOO_MANY_ERRORS_MSK BIT(13)
+#define ADMV1014_ADDRESS_RANGE_ERROR_MSK BIT(12)
+
+/* ADMV1014_REG_ENABLE Map */
+#define ADMV1014_IBIAS_PD_MSK BIT(14)
+#define ADMV1014_P1DB_COMPENSATION_MSK GENMASK(13, 12)
+#define ADMV1014_IF_AMP_PD_MSK BIT(11)
+#define ADMV1014_QUAD_BG_PD_MSK BIT(9)
+#define ADMV1014_BB_AMP_PD_MSK BIT(8)
+#define ADMV1014_QUAD_IBIAS_PD_MSK BIT(7)
+#define ADMV1014_DET_EN_MSK BIT(6)
+#define ADMV1014_BG_PD_MSK BIT(5)
+
+/* ADMV1014_REG_QUAD Map */
+#define ADMV1014_QUAD_SE_MODE_MSK GENMASK(9, 6)
+#define ADMV1014_QUAD_FILTERS_MSK GENMASK(3, 0)
+
+/* ADMV1014_REG_LO_AMP_PHASE_ADJUST1 Map */
+#define ADMV1014_LOAMP_PH_ADJ_I_FINE_MSK GENMASK(15, 9)
+#define ADMV1014_LOAMP_PH_ADJ_Q_FINE_MSK GENMASK(8, 2)
+
+/* ADMV1014_REG_MIXER Map */
+#define ADMV1014_MIXER_VGATE_MSK GENMASK(15, 9)
+#define ADMV1014_DET_PROG_MSK GENMASK(6, 0)
+
+/* ADMV1014_REG_IF_AMP Map */
+#define ADMV1014_IF_AMP_COARSE_GAIN_I_MSK GENMASK(11, 8)
+#define ADMV1014_IF_AMP_FINE_GAIN_Q_MSK GENMASK(7, 4)
+#define ADMV1014_IF_AMP_FINE_GAIN_I_MSK GENMASK(3, 0)
+
+/* ADMV1014_REG_IF_AMP_BB_AMP Map */
+#define ADMV1014_IF_AMP_COARSE_GAIN_Q_MSK GENMASK(15, 12)
+#define ADMV1014_BB_AMP_OFFSET_Q_MSK GENMASK(9, 5)
+#define ADMV1014_BB_AMP_OFFSET_I_MSK GENMASK(4, 0)
+
+/* ADMV1014_REG_BB_AMP_AGC Map */
+#define ADMV1014_BB_AMP_REF_GEN_MSK GENMASK(6, 3)
+#define ADMV1014_BB_AMP_GAIN_CTRL_MSK GENMASK(2, 1)
+#define ADMV1014_BB_SWITCH_HIGH_LOW_CM_MSK BIT(0)
+
+/* ADMV1014_REG_VVA_TEMP_COMP Map */
+#define ADMV1014_VVA_TEMP_COMP_MSK GENMASK(15, 0)
+
+/* ADMV1014 Miscellaneous Defines */
+#define ADMV1014_READ BIT(7)
+#define ADMV1014_REG_ADDR_READ_MSK GENMASK(6, 1)
+#define ADMV1014_REG_ADDR_WRITE_MSK GENMASK(22, 17)
+#define ADMV1014_REG_DATA_MSK GENMASK(16, 1)
+#define ADMV1014_NUM_REGULATORS 9
+
+enum {
+ ADMV1014_IQ_MODE,
+ ADMV1014_IF_MODE
+};
+
+enum {
+ ADMV1014_SE_MODE_POS = 6,
+ ADMV1014_SE_MODE_NEG = 9,
+ ADMV1014_SE_MODE_DIFF = 12
+};
+
+enum {
+ ADMV1014_CALIBSCALE_COARSE,
+ ADMV1014_CALIBSCALE_FINE,
+};
+
+static const int detector_table[] = {0, 1, 2, 4, 8, 16, 32, 64};
+
+struct admv1014_state {
+ struct spi_device *spi;
+ struct clk *clkin;
+ struct notifier_block nb;
+ /* Protect against concurrent accesses to the device and to data*/
+ struct mutex lock;
+ struct regulator_bulk_data regulators[ADMV1014_NUM_REGULATORS];
+ unsigned int input_mode;
+ unsigned int quad_se_mode;
+ unsigned int p1db_comp;
+ bool det_en;
+ u8 data[3] ____cacheline_aligned;
+};
+
+static const int mixer_vgate_table[] = {106, 107, 108, 110, 111, 112, 113, 114,
+ 117, 118, 119, 120, 122, 123, 44, 45};
+
+static int __admv1014_spi_read(struct admv1014_state *st, unsigned int reg,
+ unsigned int *val)
+{
+ int ret;
+ struct spi_transfer t = {0};
+
+ st->data[0] = ADMV1014_READ | FIELD_PREP(ADMV1014_REG_ADDR_READ_MSK, reg);
+ st->data[1] = 0x0;
+ st->data[2] = 0x0;
+
+ t.rx_buf = &st->data[0];
+ t.tx_buf = &st->data[0];
+ t.len = 3;
+
+ ret = spi_sync_transfer(st->spi, &t, 1);
+ if (ret)
+ return ret;
+
+ *val = FIELD_GET(ADMV1014_REG_DATA_MSK, get_unaligned_be24(&st->data[0]));
+
+ return ret;
+}
+
+static int admv1014_spi_read(struct admv1014_state *st, unsigned int reg,
+ unsigned int *val)
+{
+ int ret;
+
+ mutex_lock(&st->lock);
+ ret = __admv1014_spi_read(st, reg, val);
+ mutex_unlock(&st->lock);
+
+ return ret;
+}
+
+static int __admv1014_spi_write(struct admv1014_state *st,
+ unsigned int reg,
+ unsigned int val)
+{
+ put_unaligned_be24(FIELD_PREP(ADMV1014_REG_DATA_MSK, val) |
+ FIELD_PREP(ADMV1014_REG_ADDR_WRITE_MSK, reg), &st->data[0]);
+
+ return spi_write(st->spi, &st->data[0], 3);
+}
+
+static int admv1014_spi_write(struct admv1014_state *st, unsigned int reg,
+ unsigned int val)
+{
+ int ret;
+
+ mutex_lock(&st->lock);
+ ret = __admv1014_spi_write(st, reg, val);
+ mutex_unlock(&st->lock);
+
+ return ret;
+}
+
+static int __admv1014_spi_update_bits(struct admv1014_state *st, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ int ret;
+ unsigned int data, temp;
+
+ ret = __admv1014_spi_read(st, reg, &data);
+ if (ret)
+ return ret;
+
+ temp = (data & ~mask) | (val & mask);
+
+ return __admv1014_spi_write(st, reg, temp);
+}
+
+static int admv1014_spi_update_bits(struct admv1014_state *st, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ int ret;
+
+ mutex_lock(&st->lock);
+ ret = __admv1014_spi_update_bits(st, reg, mask, val);
+ mutex_unlock(&st->lock);
+
+ return ret;
+}
+
+static int admv1014_update_quad_filters(struct admv1014_state *st)
+{
+ unsigned int filt_raw;
+ u64 rate = clk_get_rate(st->clkin);
+
+ if (rate >= (5400 * HZ_PER_MHZ) && rate <= (7000 * HZ_PER_MHZ))
+ filt_raw = 15;
+ else if (rate >= (5400 * HZ_PER_MHZ) && rate <= (8000 * HZ_PER_MHZ))
+ filt_raw = 10;
+ else if (rate >= (6600 * HZ_PER_MHZ) && rate <= (9200 * HZ_PER_MHZ))
+ filt_raw = 5;
+ else
+ filt_raw = 0;
+
+ return __admv1014_spi_update_bits(st, ADMV1014_REG_QUAD,
+ ADMV1014_QUAD_FILTERS_MSK,
+ FIELD_PREP(ADMV1014_QUAD_FILTERS_MSK, filt_raw));
+}
+
+static int admv1014_update_vcm_settings(struct admv1014_state *st)
+{
+ unsigned int i, vcm_mv, vcm_comp, bb_sw_hl_cm;
+ int ret;
+
+ vcm_mv = regulator_get_voltage(st->regulators[0].consumer) / 1000;
+ for (i = 0; i < ARRAY_SIZE(mixer_vgate_table); i++) {
+ vcm_comp = 1050 + (i * 50) + (i / 8 * 50);
+ if (vcm_mv != vcm_comp)
+ continue;
+
+ ret = __admv1014_spi_update_bits(st, ADMV1014_REG_MIXER,
+ ADMV1014_MIXER_VGATE_MSK,
+ FIELD_PREP(ADMV1014_MIXER_VGATE_MSK,
+ mixer_vgate_table[i]));
+ if (ret)
+ return ret;
+
+ bb_sw_hl_cm = ~(i / 8);
+ bb_sw_hl_cm = FIELD_PREP(ADMV1014_BB_SWITCH_HIGH_LOW_CM_MSK, bb_sw_hl_cm);
+
+ return __admv1014_spi_update_bits(st, ADMV1014_REG_BB_AMP_AGC,
+ ADMV1014_BB_AMP_REF_GEN_MSK |
+ ADMV1014_BB_SWITCH_HIGH_LOW_CM_MSK,
+ FIELD_PREP(ADMV1014_BB_AMP_REF_GEN_MSK, i) |
+ bb_sw_hl_cm);
+ }
+
+ return -EINVAL;
+}
+
+static int admv1014_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long info)
+{
+ struct admv1014_state *st = iio_priv(indio_dev);
+ unsigned int data;
+ int ret;
+
+ switch (info) {
+ case IIO_CHAN_INFO_OFFSET:
+ ret = admv1014_spi_read(st, ADMV1014_REG_IF_AMP_BB_AMP, &data);
+ if (ret)
+ return ret;
+
+ if (chan->channel2 == IIO_MOD_I)
+ *val = FIELD_GET(ADMV1014_BB_AMP_OFFSET_I_MSK, data);
+ else
+ *val = FIELD_GET(ADMV1014_BB_AMP_OFFSET_Q_MSK, data);
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_PHASE:
+ ret = admv1014_spi_read(st, ADMV1014_REG_LO_AMP_PHASE_ADJUST1, &data);
+ if (ret)
+ return ret;
+
+ if (chan->channel2 == IIO_MOD_I)
+ *val = FIELD_GET(ADMV1014_LOAMP_PH_ADJ_I_FINE_MSK, data);
+ else
+ *val = FIELD_GET(ADMV1014_LOAMP_PH_ADJ_Q_FINE_MSK, data);
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ ret = admv1014_spi_read(st, ADMV1014_REG_MIXER, &data);
+ if (ret)
+ return ret;
+
+ *val = FIELD_GET(ADMV1014_DET_PROG_MSK, data);
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_CALIBSCALE:
+ ret = admv1014_spi_read(st, ADMV1014_REG_BB_AMP_AGC, &data);
+ if (ret)
+ return ret;
+
+ *val = FIELD_GET(ADMV1014_BB_AMP_GAIN_CTRL_MSK, data);
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int admv1014_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long info)
+{
+ int data;
+ unsigned int msk;
+ struct admv1014_state *st = iio_priv(indio_dev);
+
+ switch (info) {
+ case IIO_CHAN_INFO_OFFSET:
+ if (chan->channel2 == IIO_MOD_I) {
+ msk = ADMV1014_BB_AMP_OFFSET_I_MSK;
+ data = FIELD_PREP(ADMV1014_BB_AMP_OFFSET_I_MSK, val);
+ } else {
+ msk = ADMV1014_BB_AMP_OFFSET_Q_MSK;
+ data = FIELD_PREP(ADMV1014_BB_AMP_OFFSET_Q_MSK, val);
+ }
+
+ return admv1014_spi_update_bits(st, ADMV1014_REG_IF_AMP_BB_AMP, msk, data);
+ case IIO_CHAN_INFO_PHASE:
+ if (chan->channel2 == IIO_MOD_I) {
+ msk = ADMV1014_LOAMP_PH_ADJ_I_FINE_MSK;
+ data = FIELD_PREP(ADMV1014_LOAMP_PH_ADJ_I_FINE_MSK, val);
+ } else {
+ msk = ADMV1014_LOAMP_PH_ADJ_Q_FINE_MSK;
+ data = FIELD_PREP(ADMV1014_LOAMP_PH_ADJ_Q_FINE_MSK, val);
+ }
+
+ return admv1014_spi_update_bits(st, ADMV1014_REG_LO_AMP_PHASE_ADJUST1, msk, data);
+ case IIO_CHAN_INFO_SCALE:
+ return admv1014_spi_update_bits(st, ADMV1014_REG_MIXER,
+ ADMV1014_DET_PROG_MSK,
+ FIELD_PREP(ADMV1014_DET_PROG_MSK, val));
+ case IIO_CHAN_INFO_CALIBSCALE:
+ return admv1014_spi_update_bits(st, ADMV1014_REG_BB_AMP_AGC,
+ ADMV1014_BB_AMP_GAIN_CTRL_MSK,
+ FIELD_PREP(ADMV1014_BB_AMP_GAIN_CTRL_MSK, val));
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t admv1014_read(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ char *buf)
+{
+ struct admv1014_state *st = iio_priv(indio_dev);
+ unsigned int data;
+ int ret;
+
+ switch ((u32)private) {
+ case ADMV1014_CALIBSCALE_COARSE:
+ if (chan->channel2 == IIO_MOD_I) {
+ ret = admv1014_spi_read(st, ADMV1014_REG_IF_AMP, &data);
+ if (ret)
+ return ret;
+
+ data = FIELD_GET(ADMV1014_IF_AMP_COARSE_GAIN_I_MSK, data);
+ } else {
+ ret = admv1014_spi_read(st, ADMV1014_REG_IF_AMP_BB_AMP, &data);
+ if (ret)
+ return ret;
+
+ data = FIELD_GET(ADMV1014_IF_AMP_COARSE_GAIN_Q_MSK, data);
+ }
+ break;
+ case ADMV1014_CALIBSCALE_FINE:
+ ret = admv1014_spi_read(st, ADMV1014_REG_IF_AMP, &data);
+ if (ret)
+ return ret;
+
+ if (chan->channel2 == IIO_MOD_I)
+ data = FIELD_GET(ADMV1014_IF_AMP_FINE_GAIN_I_MSK, data);
+ else
+ data = FIELD_GET(ADMV1014_IF_AMP_FINE_GAIN_Q_MSK, data);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return sysfs_emit(buf, "%u\n", data);
+}
+
+static ssize_t admv1014_write(struct iio_dev *indio_dev,
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf, size_t len)
+{
+ struct admv1014_state *st = iio_priv(indio_dev);
+ unsigned int data, addr, msk;
+ int ret;
+
+ ret = kstrtou32(buf, 10, &data);
+ if (ret)
+ return ret;
+
+ switch ((u32)private) {
+ case ADMV1014_CALIBSCALE_COARSE:
+ if (chan->channel2 == IIO_MOD_I) {
+ addr = ADMV1014_REG_IF_AMP;
+ msk = ADMV1014_IF_AMP_COARSE_GAIN_I_MSK;
+ data = FIELD_PREP(ADMV1014_IF_AMP_COARSE_GAIN_I_MSK, data);
+ } else {
+ addr = ADMV1014_REG_IF_AMP_BB_AMP;
+ msk = ADMV1014_IF_AMP_COARSE_GAIN_Q_MSK;
+ data = FIELD_PREP(ADMV1014_IF_AMP_COARSE_GAIN_Q_MSK, data);
+ }
+ break;
+ case ADMV1014_CALIBSCALE_FINE:
+ addr = ADMV1014_REG_IF_AMP;
+
+ if (chan->channel2 == IIO_MOD_I) {
+ msk = ADMV1014_IF_AMP_FINE_GAIN_I_MSK;
+ data = FIELD_PREP(ADMV1014_IF_AMP_FINE_GAIN_I_MSK, data);
+ } else {
+ msk = ADMV1014_IF_AMP_FINE_GAIN_Q_MSK;
+ data = FIELD_PREP(ADMV1014_IF_AMP_FINE_GAIN_Q_MSK, data);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = admv1014_spi_update_bits(st, addr, msk, data);
+
+ return ret ? ret : len;
+}
+
+static int admv1014_read_avail(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ const int **vals, int *type, int *length,
+ long info)
+{
+ switch (info) {
+ case IIO_CHAN_INFO_SCALE:
+ *vals = detector_table;
+ *type = IIO_VAL_INT;
+ *length = ARRAY_SIZE(detector_table);
+
+ return IIO_AVAIL_LIST;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int admv1014_reg_access(struct iio_dev *indio_dev,
+ unsigned int reg,
+ unsigned int write_val,
+ unsigned int *read_val)
+{
+ struct admv1014_state *st = iio_priv(indio_dev);
+
+ if (read_val)
+ return admv1014_spi_read(st, reg, read_val);
+ else
+ return admv1014_spi_write(st, reg, write_val);
+}
+
+static const struct iio_info admv1014_info = {
+ .read_raw = admv1014_read_raw,
+ .write_raw = admv1014_write_raw,
+ .read_avail = &admv1014_read_avail,
+ .debugfs_reg_access = &admv1014_reg_access,
+};
+
+static const char * const admv1014_reg_name[] = {
+ "vcm", "vcc-if-bb", "vcc-vga", "vcc-vva", "vcc-lna-3p3", "vcc-lna-1p5",
+ "vcc-bg", "vcc-quad", "vcc-mixer"
+};
+
+static int admv1014_freq_change(struct notifier_block *nb, unsigned long action, void *data)
+{
+ struct admv1014_state *st = container_of(nb, struct admv1014_state, nb);
+ int ret;
+
+ if (action == POST_RATE_CHANGE) {
+ mutex_lock(&st->lock);
+ ret = notifier_from_errno(admv1014_update_quad_filters(st));
+ mutex_unlock(&st->lock);
+ return ret;
+ }
+
+ return NOTIFY_OK;
+}
+
+#define _ADMV1014_EXT_INFO(_name, _shared, _ident) { \
+ .name = _name, \
+ .read = admv1014_read, \
+ .write = admv1014_write, \
+ .private = _ident, \
+ .shared = _shared, \
+}
+
+static const struct iio_chan_spec_ext_info admv1014_ext_info[] = {
+ _ADMV1014_EXT_INFO("calibscale_coarse", IIO_SEPARATE, ADMV1014_CALIBSCALE_COARSE),
+ _ADMV1014_EXT_INFO("calibscale_fine", IIO_SEPARATE, ADMV1014_CALIBSCALE_FINE),
+ { }
+};
+
+#define ADMV1014_CHAN_IQ(_channel, rf_comp) { \
+ .type = IIO_ALTVOLTAGE, \
+ .modified = 1, \
+ .output = 0, \
+ .indexed = 1, \
+ .channel2 = IIO_MOD_##rf_comp, \
+ .channel = _channel, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PHASE) | \
+ BIT(IIO_CHAN_INFO_OFFSET), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_CALIBSCALE) \
+ }
+
+#define ADMV1014_CHAN_IF(_channel, rf_comp) { \
+ .type = IIO_ALTVOLTAGE, \
+ .modified = 1, \
+ .output = 0, \
+ .indexed = 1, \
+ .channel2 = IIO_MOD_##rf_comp, \
+ .channel = _channel, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_PHASE) | \
+ BIT(IIO_CHAN_INFO_OFFSET) \
+ }
+
+#define ADMV1014_CHAN_POWER(_channel) { \
+ .type = IIO_POWER, \
+ .output = 0, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_SCALE), \
+ .info_mask_shared_by_type_available = BIT(IIO_CHAN_INFO_SCALE) \
+ }
+
+#define ADMV1014_CHAN_CALIBSCALE(_channel, rf_comp, _admv1014_ext_info) { \
+ .type = IIO_ALTVOLTAGE, \
+ .modified = 1, \
+ .output = 0, \
+ .indexed = 1, \
+ .channel2 = IIO_MOD_##rf_comp, \
+ .channel = _channel, \
+ .ext_info = _admv1014_ext_info \
+ }
+
+static const struct iio_chan_spec admv1014_channels_iq[] = {
+ ADMV1014_CHAN_IQ(0, I),
+ ADMV1014_CHAN_IQ(0, Q),
+ ADMV1014_CHAN_POWER(0)
+};
+
+static const struct iio_chan_spec admv1014_channels_if[] = {
+ ADMV1014_CHAN_IF(0, I),
+ ADMV1014_CHAN_IF(0, Q),
+ ADMV1014_CHAN_CALIBSCALE(0, I, admv1014_ext_info),
+ ADMV1014_CHAN_CALIBSCALE(0, Q, admv1014_ext_info),
+ ADMV1014_CHAN_POWER(0)
+};
+
+static void admv1014_clk_disable(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static void admv1014_powerdown(void *data)
+{
+ unsigned int enable_reg, enable_reg_msk;
+
+ /* Disable all components in the Enable Register */
+ enable_reg_msk = ADMV1014_IBIAS_PD_MSK |
+ ADMV1014_IF_AMP_PD_MSK |
+ ADMV1014_QUAD_BG_PD_MSK |
+ ADMV1014_BB_AMP_PD_MSK |
+ ADMV1014_QUAD_IBIAS_PD_MSK |
+ ADMV1014_BG_PD_MSK;
+
+ enable_reg = FIELD_PREP(ADMV1014_IBIAS_PD_MSK, 1) |
+ FIELD_PREP(ADMV1014_IF_AMP_PD_MSK, 1) |
+ FIELD_PREP(ADMV1014_QUAD_BG_PD_MSK, 1) |
+ FIELD_PREP(ADMV1014_BB_AMP_PD_MSK, 1) |
+ FIELD_PREP(ADMV1014_QUAD_IBIAS_PD_MSK, 1) |
+ FIELD_PREP(ADMV1014_BG_PD_MSK, 1);
+
+ admv1014_spi_update_bits(data, ADMV1014_REG_ENABLE,
+ enable_reg_msk, enable_reg);
+}
+
+static int admv1014_init(struct admv1014_state *st)
+{
+ int ret;
+ unsigned int chip_id, enable_reg, enable_reg_msk;
+ struct spi_device *spi = st->spi;
+
+ ret = regulator_bulk_enable(ADMV1014_NUM_REGULATORS, st->regulators);
+ if (ret) {
+ dev_err(&spi->dev, "Failed to enable regulators");
+ goto error_disable_reg;
+ }
+
+ ret = clk_prepare_enable(st->clkin);
+ if (ret)
+ goto error_disable_reg;
+
+ ret = devm_add_action_or_reset(&spi->dev, admv1014_clk_disable, st->clkin);
+ if (ret)
+ goto error_disable_reg;
+
+ st->nb.notifier_call = admv1014_freq_change;
+ ret = devm_clk_notifier_register(&spi->dev, st->clkin, &st->nb);
+ if (ret)
+ goto error_disable_reg;
+
+ ret = devm_add_action_or_reset(&spi->dev, admv1014_powerdown, st);
+ if (ret)
+ goto error_disable_reg;
+
+ /* Perform a software reset */
+ ret = __admv1014_spi_update_bits(st, ADMV1014_REG_SPI_CONTROL,
+ ADMV1014_SPI_SOFT_RESET_MSK,
+ FIELD_PREP(ADMV1014_SPI_SOFT_RESET_MSK, 1));
+ if (ret) {
+ dev_err(&spi->dev, "ADMV1014 SPI software reset failed.\n");
+ goto error_disable_reg;
+ }
+
+ ret = __admv1014_spi_update_bits(st, ADMV1014_REG_SPI_CONTROL,
+ ADMV1014_SPI_SOFT_RESET_MSK,
+ FIELD_PREP(ADMV1014_SPI_SOFT_RESET_MSK, 0));
+ if (ret) {
+ dev_err(&spi->dev, "ADMV1014 SPI software reset disable failed.\n");
+ goto error_disable_reg;
+ }
+
+ ret = __admv1014_spi_write(st, ADMV1014_REG_VVA_TEMP_COMP, 0x727C);
+ if (ret) {
+ dev_err(&spi->dev, "Writing default Temperature Compensation value failed.\n");
+ goto error_disable_reg;
+ }
+
+ ret = __admv1014_spi_read(st, ADMV1014_REG_SPI_CONTROL, &chip_id);
+ if (ret)
+ goto error_disable_reg;
+
+ chip_id = (chip_id & ADMV1014_CHIP_ID_MSK) >> 4;
+ if (chip_id != ADMV1014_CHIP_ID) {
+ dev_err(&spi->dev, "Invalid Chip ID.\n");
+ ret = -EINVAL;
+ goto error_disable_reg;
+ }
+
+ ret = __admv1014_spi_update_bits(st, ADMV1014_REG_QUAD,
+ ADMV1014_QUAD_SE_MODE_MSK,
+ FIELD_PREP(ADMV1014_QUAD_SE_MODE_MSK,
+ st->quad_se_mode));
+ if (ret) {
+ dev_err(&spi->dev, "Writing Quad SE Mode failed.\n");
+ goto error_disable_reg;
+ }
+
+ ret = admv1014_update_quad_filters(st);
+ if (ret) {
+ dev_err(&spi->dev, "Update Quad Filters failed.\n");
+ goto error_disable_reg;
+ }
+
+ ret = admv1014_update_vcm_settings(st);
+ if (ret) {
+ dev_err(&spi->dev, "Update VCM Settings failed.\n");
+ goto error_disable_reg;
+ }
+
+ enable_reg_msk = ADMV1014_P1DB_COMPENSATION_MSK |
+ ADMV1014_IF_AMP_PD_MSK |
+ ADMV1014_BB_AMP_PD_MSK |
+ ADMV1014_DET_EN_MSK;
+
+ enable_reg = FIELD_PREP(ADMV1014_P1DB_COMPENSATION_MSK, st->p1db_comp ? 3 : 0) |
+ FIELD_PREP(ADMV1014_IF_AMP_PD_MSK, !(st->input_mode)) |
+ FIELD_PREP(ADMV1014_BB_AMP_PD_MSK, st->input_mode) |
+ FIELD_PREP(ADMV1014_DET_EN_MSK, st->det_en);
+
+ ret = __admv1014_spi_update_bits(st, ADMV1014_REG_ENABLE, enable_reg_msk, enable_reg);
+ if (ret)
+ goto error_disable_reg;
+
+ return 0;
+
+error_disable_reg:
+ regulator_bulk_disable(ADMV1014_NUM_REGULATORS, st->regulators);
+
+ return ret;
+}
+
+static int admv1014_properties_parse(struct admv1014_state *st)
+{
+ const char *str;
+ unsigned int i;
+ struct spi_device *spi = st->spi;
+ int ret;
+
+ st->det_en = device_property_read_bool(&spi->dev, "adi,detector-enable");
+
+ st->p1db_comp = device_property_read_bool(&spi->dev, "adi,p1db-compensation-enable");
+
+ str = "iq";
+ device_property_read_string(&spi->dev, "adi,input-mode", &str);
+
+ if (!strcmp(str, "iq"))
+ st->input_mode = ADMV1014_IQ_MODE;
+ else if (!strcmp(str, "if"))
+ st->input_mode = ADMV1014_IF_MODE;
+ else
+ return -EINVAL;
+
+ str = "diff";
+ device_property_read_string(&spi->dev, "adi,quad-se-mode", &str);
+
+ if (!strcmp(str, "diff"))
+ st->quad_se_mode = ADMV1014_SE_MODE_DIFF;
+ else if (!strcmp(str, "se-pos"))
+ st->quad_se_mode = ADMV1014_SE_MODE_POS;
+ else if (!strcmp(str, "se-neg"))
+ st->quad_se_mode = ADMV1014_SE_MODE_NEG;
+ else
+ return -EINVAL;
+
+ for (i = 0; i < ADMV1014_NUM_REGULATORS; ++i)
+ st->regulators[i].supply = admv1014_reg_name[i];
+
+ ret = devm_regulator_bulk_get(&st->spi->dev, ADMV1014_NUM_REGULATORS,
+ st->regulators);
+ if (ret) {
+ dev_err(&spi->dev, "Failed to request regulators");
+ return ret;
+ }
+
+ st->clkin = devm_clk_get(&spi->dev, "lo_in");
+ if (IS_ERR(st->clkin))
+ return dev_err_probe(&spi->dev, PTR_ERR(st->clkin),
+ "failed to get the LO input clock\n");
+
+ return 0;
+}
+
+static int admv1014_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct admv1014_state *st;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+
+ ret = admv1014_properties_parse(st);
+ if (ret)
+ return ret;
+
+ indio_dev->info = &admv1014_info;
+ indio_dev->name = "admv1014";
+
+ if (st->input_mode == ADMV1014_IQ_MODE) {
+ indio_dev->channels = admv1014_channels_iq;
+ indio_dev->num_channels = ARRAY_SIZE(admv1014_channels_iq);
+ } else {
+ indio_dev->channels = admv1014_channels_if;
+ indio_dev->num_channels = ARRAY_SIZE(admv1014_channels_if);
+ }
+
+ st->spi = spi;
+
+ mutex_init(&st->lock);
+
+ ret = admv1014_init(st);
+ if (ret)
+ return ret;
+
+ return devm_iio_device_register(&spi->dev, indio_dev);
+}
+
+static const struct spi_device_id admv1014_id[] = {
+ { "admv1014", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(spi, admv1014_id);
+
+static const struct of_device_id admv1014_of_match[] = {
+ { .compatible = "adi,admv1014" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, admv1014_of_match);
+
+static struct spi_driver admv1014_driver = {
+ .driver = {
+ .name = "admv1014",
+ .of_match_table = admv1014_of_match,
+ },
+ .probe = admv1014_probe,
+ .id_table = admv1014_id,
+};
+module_spi_driver(admv1014_driver);
+
+MODULE_AUTHOR("Antoniu Miclaus <antoniu.miclaus@analog.com");
+MODULE_DESCRIPTION("Analog Devices ADMV1014");
+MODULE_LICENSE("GPL v2");
--
2.35.0
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings:iio:frequency: add admv1014 binding
From: Antoniu Miclaus @ 2022-01-27 10:55 UTC (permalink / raw)
To: jic23, robh+dt, linux-iio, devicetree, linux-kernel; +Cc: Antoniu Miclaus
In-Reply-To: <20220127105558.59567-1-antoniu.miclaus@analog.com>
Add device tree bindings for the ADMV1014 Upconverter.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
changes in v4:
- add all regulators in the dts example
.../bindings/iio/frequency/adi,admv1014.yaml | 137 ++++++++++++++++++
1 file changed, 137 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
new file mode 100644
index 000000000000..fe352c01dd94
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/frequency/adi,admv1014.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADMV1014 Microwave Downconverter
+
+maintainers:
+ - Antoniu Miclaus <antoniu.miclaus@analog.com>
+
+description: |
+ Wideband, microwave downconverter optimized for point to point microwave
+ radio designs operating in the 24 GHz to 44 GHz frequency range.
+
+ https://www.analog.com/en/products/admv1014.html
+
+properties:
+ compatible:
+ enum:
+ - adi,admv1014
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 1000000
+
+ clocks:
+ minItems: 1
+
+ clock-names:
+ items:
+ - const: lo_in
+ description:
+ External clock that provides the Local Oscilator input.
+
+ vcm-supply:
+ description:
+ Common-mode voltage regulator.
+
+ vcc-if-bb-supply:
+ description:
+ BB and IF supply voltage regulator.
+
+ vcc-vga-supply:
+ description:
+ RF Amplifier supply voltage regulator.
+
+ vcc-vva-supply:
+ description:
+ VVA Control Circuit supply voltage regulator.
+
+ vcc-lna-3p3-supply:
+ description:
+ Low Noise Amplifier 3.3V supply voltage regulator.
+
+ vcc-lna-1p5-supply:
+ description:
+ Low Noise Amplifier 1.5V supply voltage regulator.
+
+ vcc-bg-supply:
+ description:
+ Band Gap Circuit supply voltage regulator.
+
+ vcc-quad-supply:
+ description:
+ Quadruple supply voltage regulator.
+
+ vcc-mixer-supply:
+ description:
+ Mixer supply voltage regulator.
+
+ adi,input-mode:
+ description:
+ Select the input mode.
+ iq - in-phase quadrature (I/Q) input
+ if - complex intermediate frequency (IF) input
+ enum: [iq, if]
+
+ adi,detector-enable:
+ description:
+ Digital Rx Detector Enable. The Square Law Detector output is
+ available at output pin VDET.
+ type: boolean
+
+ adi,p1db-compensation-enable:
+ description:
+ Turn on bits to optimize P1dB.
+ type: boolean
+
+ adi,quad-se-mode:
+ description:
+ Switch the LO path from differential to single-ended operation.
+ se-neg - Single-Ended Mode, Negative Side Disabled.
+ se-pos - Single-Ended Mode, Positive Side Disabled.
+ diff - Differential Mode.
+ enum: [se-neg, se-pos, diff]
+
+ '#clock-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - vcm-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ admv1014@0{
+ compatible = "adi,admv1014";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ clocks = <&admv1014_lo>;
+ clock-names = "lo_in";
+ vcm-supply = <&vcm>;
+ vcc-if-bb-supply = <&vcc_if_bb>;
+ vcc-vga-supply = <&vcc_vga>;
+ vcc-vva-supply = <&vcc_vva>;
+ vcc-lna-3p3-supply = <&vcc_lna_3p3>;
+ vcc-lna-1p5-supply = <&vcc_lna_1p5>;
+ vcc-bg-supply = <&vcc_bg>;
+ vcc-quad-supply = <&vcc_quad>;
+ vcc-mixer-supply = <&vcc_mixer>;
+ adi,quad-se-mode = "diff";
+ adi,detector-enable;
+ adi,p1db-compensation-enable;
+ };
+ };
+...
--
2.35.0
^ permalink raw reply related
* Re: [PATCH v3 01/12] misc: fastrpc: separate fastrpc device from channel context
From: Dan Carpenter @ 2022-01-27 11:33 UTC (permalink / raw)
To: kbuild, Srinivas Kandagatla, robh+dt, gregkh
Cc: lkp, kbuild-all, devicetree, ekangupt, bkumar, linux-kernel,
srini, bjorn.andersson, linux-arm-msm, Srinivas Kandagatla
In-Reply-To: <20220126135304.16340-2-srinivas.kandagatla@linaro.org>
Hi Srinivas,
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 515a2f507491e7c3818e74ef4f4e088c1fecb190
config: openrisc-randconfig-m031-20220124 (https://download.01.org/0day-ci/archive/20220127/202201271857.MGiOkhFo-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 11.2.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
drivers/misc/fastrpc.c:1636 fastrpc_device_register() warn: passing devm_ allocated variable to kfree. 'fdev'
vim +/fdev +1636 drivers/misc/fastrpc.c
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1620 static int fastrpc_device_register(struct device *dev, struct fastrpc_channel_ctx *cctx,
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1621 const char *domain)
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1622 {
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1623 struct fastrpc_device *fdev;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1624 int err;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1625
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1626 fdev = devm_kzalloc(dev, sizeof(*fdev), GFP_KERNEL);
^^^^^^^^^^^^^^^^^^^
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1627 if (!fdev)
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1628 return -ENOMEM;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1629
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1630 fdev->cctx = cctx;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1631 fdev->miscdev.minor = MISC_DYNAMIC_MINOR;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1632 fdev->miscdev.fops = &fastrpc_fops;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1633 fdev->miscdev.name = devm_kasprintf(dev, GFP_KERNEL, "fastrpc-%s", domain);
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1634 err = misc_register(&fdev->miscdev);
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1635 if (err)
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 @1636 kfree(fdev);
^^^^^^^^^^^
Double free
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1637 else
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1638 cctx->fdevice = fdev;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1639
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1640 return err;
99d9d7a1c5f2dae Srinivas Kandagatla 2022-01-26 1641 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Greg KH @ 2022-01-27 11:30 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <20220127112305.GC9150@pengutronix.de>
On Thu, Jan 27, 2022 at 12:23:05PM +0100, Oleksij Rempel wrote:
> On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> > On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > > Similar to the option to set a netdev name in device tree for switch
> > > ports by using the property "label" in the DSA framework, this patch
> > > adds this functionality to the usbnet infrastructure.
> > >
> > > This will help to name the interfaces properly throughout supported
> > > devices. This provides stable interface names which are useful
> > > especially in embedded use cases.
> >
> > Stable interface names are for userspace to set, not the kernel.
> >
> > Why would USB care about this? If you need something like this, get it
> > from the USB device itself, not DT, which should have nothing to do with
> > USB as USB is a dynamic, self-describing, bus. Unlike DT.
> >
> > So I do not think this is a good idea.
>
> This is needed for embedded devices with integrated USB Ethernet
> controller. Currently I have following use cases to solve:
> - Board with one or multiple USB Ethernet controllers with external PHY.
> The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
The phy is for the USB controller, not the Ethernet controller, right?
If for the ethernet controller, ugh, that's a crazy design and I would
argue a broken one. But whatever, DT should not be used to describe a
USB device itself.
> - Board with USB Ethernet controller with DSA switch. The USB ethernet
> controller is attached to the CPU port of DSA switch. In this case,
> DSA switch is the sub-node of the USB device.
What do you mean exactly by "sub node"? USB does not have such a term.
> The CPU port should have
> stable name for all device related to this product.
name for who to use? Userspace? Or within the kernel?
Naming is done by userspace, as USB is NOT determinisitic in numbering /
naming the devices attached to it, by design. If you need to have a
stable name, do so in userspace please, we have loads of tools that
already do this there today. Let's not reinvent the wheel.
> Using user space tools to name interfaces would double the maintenance
> of similar information: DT - describing the HW + udev scripts describing
> same HW again.
Not for the network name of the device, that belongs in userspace.
Do not be listing USB device ids in a DT file, that way lies madness.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v1 2/4] dt-bindings: net: add schema for Microchip/SMSC LAN95xx USB Ethernet controllers
From: Oleksij Rempel @ 2022-01-27 11:28 UTC (permalink / raw)
To: Greg KH
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <YfJ6/xdacR59Jvq+@kroah.com>
On Thu, Jan 27, 2022 at 11:59:11AM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 11:49:03AM +0100, Oleksij Rempel wrote:
> > Create initial schema for Microchip/SMSC LAN95xx USB Ethernet controllers and
> > import all currently supported USB IDs form drivers/net/usb/smsc95xx.c
>
> That is a loosing game to play. There is a reason that kernel drivers
> only require a device id in 1 place, instead of multiple places like
> other operating systems. Please do not go back and make the same
> mistakes others have.
>
> Not to mention that I think overall this is a bad idea anyway. USB
> devices are self-describing, don't add them to DT.
This patch set is the pre-step before making it even more complicated
with description of external PHYs and DSA switches. I assume, it is
preferable to have schema to be able to automatically validate it.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 2/2] iommu/mediatek: Add mt8186 iommu support
From: AngeloGioacchino Del Regno @ 2022-01-27 11:28 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125093244.18230-3-yong.wu@mediatek.com>
Il 25/01/22 10:32, Yong Wu ha scritto:
> Add mt8186 iommu supports.
>
> Signed-off-by: Anan Sun <anan.sun@mediatek.com>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index be36e73e4bcc..a3124f48f9e1 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -160,6 +160,7 @@ enum mtk_iommu_plat {
> M4U_MT8167,
> M4U_MT8173,
> M4U_MT8183,
> + M4U_MT8186,
> M4U_MT8192,
> M4U_MT8195,
> };
> @@ -1401,6 +1402,21 @@ static const struct mtk_iommu_plat_data mt8183_data = {
> .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> };
>
> +static const struct mtk_iommu_plat_data mt8186_data_mm = {
> + .m4u_plat = M4U_MT8186,
> + .flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
> + WR_THROT_EN | IOVA_34_EN | NOT_STD_AXI_MODE |
> + MTK_IOMMU_TYPE_MM,
> + .larbid_remap = {{0}, {1, MTK_INVALID_LARBID, 8}, {4}, {7}, {2}, {9, 11, 19, 20},
> + {MTK_INVALID_LARBID, 14, 16},
> + {MTK_INVALID_LARBID, 13, MTK_INVALID_LARBID, 17}},
> + .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> + .banks_num = 1,
> + .banks_enable = {true},
> + .iova_region = mt8192_multi_dom,
> + .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
> +};
> +
> static const struct mtk_iommu_plat_data mt8192_data = {
> .m4u_plat = M4U_MT8192,
> .flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
> @@ -1470,6 +1486,7 @@ static const struct of_device_id mtk_iommu_of_ids[] = {
> { .compatible = "mediatek,mt8167-m4u", .data = &mt8167_data},
> { .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
> { .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
> + { .compatible = "mediatek,mt8186-iommu-mm", .data = &mt8186_data_mm},
Hello!
Is there any particular reason why this compatible is not "mediatek,mt8186-m4u"?
Thanks,
Angelo
> { .compatible = "mediatek,mt8192-m4u", .data = &mt8192_data},
> { .compatible = "mediatek,mt8195-iommu-infra", .data = &mt8195_data_infra},
> { .compatible = "mediatek,mt8195-iommu-vdo", .data = &mt8195_data_vdo},
>
^ permalink raw reply
* Re: [PATCH v4 35/35] iommu/mediatek: mt8195: Enable multi banks for infra iommu
From: AngeloGioacchino Del Regno @ 2022-01-27 11:25 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-36-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Enable the multi-bank functions for infra-iommu. We put PCIE in bank0
> and USB in the last bank(bank4). and we don't use the other banks
> currently, disable them.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v4 34/35] iommu/mediatek: Backup/restore regsiters for multi banks
From: AngeloGioacchino Del Regno @ 2022-01-27 11:24 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-35-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Each bank has some independent registers. thus backup/restore them for
> each a bank when suspend and resume.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH net-next v1 4/4] usbnet: add support for label from device tree
From: Oleksij Rempel @ 2022-01-27 11:23 UTC (permalink / raw)
To: Greg KH
Cc: Oliver Neukum, David S. Miller, Jakub Kicinski, Rob Herring,
kernel, linux-kernel, linux-usb, netdev, devicetree
In-Reply-To: <YfJ6lhZMAEmetdad@kroah.com>
On Thu, Jan 27, 2022 at 11:57:26AM +0100, Greg KH wrote:
> On Thu, Jan 27, 2022 at 11:49:05AM +0100, Oleksij Rempel wrote:
> > Similar to the option to set a netdev name in device tree for switch
> > ports by using the property "label" in the DSA framework, this patch
> > adds this functionality to the usbnet infrastructure.
> >
> > This will help to name the interfaces properly throughout supported
> > devices. This provides stable interface names which are useful
> > especially in embedded use cases.
>
> Stable interface names are for userspace to set, not the kernel.
>
> Why would USB care about this? If you need something like this, get it
> from the USB device itself, not DT, which should have nothing to do with
> USB as USB is a dynamic, self-describing, bus. Unlike DT.
>
> So I do not think this is a good idea.
This is needed for embedded devices with integrated USB Ethernet
controller. Currently I have following use cases to solve:
- Board with one or multiple USB Ethernet controllers with external PHY.
The PHY need devicetree to describe IRQ, clock sources, label on board, etc.
- Board with USB Ethernet controller with DSA switch. The USB ethernet
controller is attached to the CPU port of DSA switch. In this case,
DSA switch is the sub-node of the USB device. The CPU port should have
stable name for all device related to this product.
Using user space tools to name interfaces would double the maintenance
of similar information: DT - describing the HW + udev scripts describing
same HW again.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v4 32/35] iommu/mediatek: Get the proper bankid for multi banks
From: AngeloGioacchino Del Regno @ 2022-01-27 11:21 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-33-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> We preassign some ports in a special bank via the new defined
> banks_portmsk. Put it in the plat_data means it is not expected to be
> adjusted dynamically.
>
> If the iommu id in the iommu consumer's dtsi node is inside this
> banks_portmsk, then we switch it to this special iommu bank, and
> initialise the IOMMU bank HW.
>
> Each a bank has the independent pgtable(4GB iova range). Each a bank
> is a independent iommu domain/group. Currently we don't separate different
> iova ranges inside a bank.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 39 ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 22586d1aed72..c6de9304bbc6 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -191,6 +191,7 @@ struct mtk_iommu_plat_data {
>
> u8 banks_num;
> bool banks_enable[MTK_IOMMU_BANK_MAX];
> + unsigned int banks_portmsk[MTK_IOMMU_BANK_MAX];
I would prefer to see u32 here instead... but maybe that's just a
personal preference, it doesn't really matter.
In any case:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 07/27] drm/rockchip: dw_hdmi: Use auto-generated tables
From: Sascha Hauer @ 2022-01-27 11:20 UTC (permalink / raw)
To: Doug Anderson
Cc: dri-devel, Linux ARM, open list:ARM/Rockchip SoC...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sascha Hauer, Andy Yan, Benjamin Gaignard, Michael Riesch,
Sandy Huang, Heiko Stübner, Peter Geis, Yakir Yang,
Stéphane Marchesin
In-Reply-To: <CAD=FV=U7W_oWjS_gCurAkNdkcuHQGn-XH=-VwP2MSG9zO92ySg@mail.gmail.com>
On Wed, Jan 26, 2022 at 07:54:53AM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Jan 26, 2022 at 6:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > From: Douglas Anderson <dianders at chromium.org>
> >
> > The previous tables for mpll_cfg and curr_ctrl were created using the
> > 20-pages of example settings provided by the PHY vendor. Those
> > example settings weren't particularly dense, so there were places
> > where we were guessing what the settings would be for 10-bit and
> > 12-bit (not that we use those anyway). It was also always a lot of
> > extra work every time we wanted to add a new clock rate since we had
> > to cross-reference several tables.
> >
> > In <http://crosreview.com/285855> I've gone through the work to figure
>
> The `crosreview.com` syntax doesn't seem to work anymore. Could maybe
> update to https://crrev.com/c/285855 ?
did that, thanks.
>
> > out how to generate this table automatically. Let's now use the
> > automatically generated table and then we'll never need to look at it
> > again.
> >
> > We only support 8-bit mode right now and only support a small number
> > of clock rates and and I've verified that the only 8-bit rate that was
> > affected was 148.5. That mode appears to have been wrong in the old
> > table.
> >
> > Changes since v3:
> > - new patch
> >
> > Signed-off-by: Douglas Anderson <dianders at chromium.org>
> > Signed-off-by: Yakir Yang <ykk at rock-chips.com>
>
> Should probably change the "at" to "@" ?
yes.
>
> > Reviewed-by: Stéphane Marchesin <marcheu at chromium.org>
>
> In general shouldn't carry downstream reviews when posting upstream
> unless you're certain that the person intended it...
>
>
> It's been a long time, but in general I think I was fairly confident
> in the numbers that my script pumped out, at least given the caveat of
> no pixel repetition and 8-bit only. That being said, I didn't have any
> inside knowledge of the hardware and just figured out formulas that
> seemed to match the table that I had. YMMV.
Rockchip adopted this patch for their downstream Kernel, so they haven't
been able to come up with better values. Given that you created this
patch for a fairly old SoC and the values are still usable on rk3568 I
think that's the way to go.
>
> I'll also say that when I did a rebase of veyron (rk3288-based
> Chromebook) to 4.19 about 2.5 years ago, I ended up squashing several
> of these patches into 1. That can be found at
> <https://crrev.com/c/1661056>. That also has details about why some of
> these patches never made it upstream. The main reason, at least in the
> case of rk3288, was the PLL sharing problem that nobody ever solved.
> rk3288 didn't have quite enough PLLs and thus, if you were using both
> VOPs, one of the VOPs was going to be severely limited in what pixel
> clocks it could make. There was no framework deciding which VOP should
> be limited and how the system should react to this...
>
>
> In any case, I'm pretty far disconnected from all this stuff now, but
> I wish you the best of luck in trying to get it all solved!
Nah, sorry, I won't get that all solved ;)
I am not that interested in rk3288, my main concern is the rk3568. That
one has two spare PLLs for three heads instead of one PLL for two heads,
so the problem is less pressing.
I'll stick to this version of the patch instead of the combined one
because this patch seems to be correct regardless of the PLL problem.
Thanks for the link though, it gives me some insights why things are the
way they are currently.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v4 29/35] iommu/mediatek: Add mtk_iommu_bank_data structure
From: AngeloGioacchino Del Regno @ 2022-01-27 11:17 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-30-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Prepare for supporting multi-banks for the IOMMU HW, No functional change.
>
> Add a new structure(mtk_iommu_bank_data) for each a bank. Each a bank have
> the independent HW base/IRQ/tlb-range ops, and each a bank has its special
> iommu-domain(independent pgtable), thus, also move the domain information
> into it.
>
> In previous SoC, we have only one bank which could be treated as bank0(
> bankid always is 0 for the previous SoC).
>
> After adding this structure, the tlb operations and irq could use
> bank_data as parameter.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* [PATCH v20 3/3] arm64: defconfig: Add CONFIG_KEYBOARD_MT6779=m
From: Mattijs Korpershoek @ 2022-01-27 11:15 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch, Rob Herring,
Matthias Brugger, Fengping Yu, Yingjoe Chen
Cc: Mattijs Korpershoek, Fabien Parent, Kevin Hilman, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20220127111526.3716689-1-mkorpershoek@baylibre.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
Add Mediatek matrix keypad support in defconfig.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f2e2b9bdd702..099a9e68711c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -390,6 +390,7 @@ CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SNVS_PWRKEY=m
CONFIG_KEYBOARD_IMX_SC_KEY=m
CONFIG_KEYBOARD_CROS_EC=y
+CONFIG_KEYBOARD_MT6779=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
CONFIG_TOUCHSCREEN_GOODIX=m
--
2.32.0
^ permalink raw reply related
* [PATCH v20 2/3] Input: mt6779-keypad - Add MediaTek keypad driver
From: Mattijs Korpershoek @ 2022-01-27 11:15 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch, Rob Herring,
Matthias Brugger, Fengping Yu, Yingjoe Chen
Cc: Mattijs Korpershoek, Fabien Parent, Kevin Hilman, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20220127111526.3716689-1-mkorpershoek@baylibre.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
This patch adds matrix keypad support for Mediatek SoCs.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
---
drivers/input/keyboard/Kconfig | 12 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mt6779-keypad.c | 218 +++++++++++++++++++++++++
3 files changed, 231 insertions(+)
create mode 100644 drivers/input/keyboard/mt6779-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 0c607da9ee10..03a9530f620e 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -779,6 +779,18 @@ config KEYBOARD_BCM
To compile this driver as a module, choose M here: the
module will be called bcm-keypad.
+config KEYBOARD_MT6779
+ tristate "MediaTek Keypad Support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select REGMAP_MMIO
+ select INPUT_MATRIXKMAP
+ help
+ Say Y here if you want to use the keypad on MediaTek SoCs.
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mt6779-keypad.
+
config KEYBOARD_MTK_PMIC
tristate "MediaTek PMIC keys support"
depends on MFD_MT6397
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index e3c8648f834e..721936e90290 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_KEYBOARD_MATRIX) += matrix_keypad.o
obj-$(CONFIG_KEYBOARD_MAX7359) += max7359_keypad.o
obj-$(CONFIG_KEYBOARD_MCS) += mcs_touchkey.o
obj-$(CONFIG_KEYBOARD_MPR121) += mpr121_touchkey.o
+obj-$(CONFIG_KEYBOARD_MT6779) += mt6779-keypad.o
obj-$(CONFIG_KEYBOARD_MTK_PMIC) += mtk-pmic-keys.o
obj-$(CONFIG_KEYBOARD_NEWTON) += newtonkbd.o
obj-$(CONFIG_KEYBOARD_NOMADIK) += nomadik-ske-keypad.o
diff --git a/drivers/input/keyboard/mt6779-keypad.c b/drivers/input/keyboard/mt6779-keypad.c
new file mode 100644
index 000000000000..369366f18fd2
--- /dev/null
+++ b/drivers/input/keyboard/mt6779-keypad.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 MediaTek Inc.
+ * Author Fengping Yu <fengping.yu@mediatek.com>
+ */
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define MTK_KPD_NAME "mt6779-keypad"
+#define MTK_KPD_MEM 0x0004
+#define MTK_KPD_DEBOUNCE 0x0018
+#define MTK_KPD_DEBOUNCE_MASK GENMASK(13, 0)
+#define MTK_KPD_DEBOUNCE_MAX_MS 256
+#define MTK_KPD_NUM_MEMS 5
+#define MTK_KPD_NUM_BITS 136 /* 4*32+8 MEM5 only use 8 BITS */
+
+struct mt6779_keypad {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct clk *clk;
+ void __iomem *base;
+ u32 n_rows;
+ u32 n_cols;
+ DECLARE_BITMAP(keymap_state, MTK_KPD_NUM_BITS);
+};
+
+static const struct regmap_config mt6779_keypad_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 36,
+};
+
+static irqreturn_t mt6779_keypad_irq_handler(int irq, void *dev_id)
+{
+ struct mt6779_keypad *keypad = dev_id;
+ unsigned short *keycode = keypad->input_dev->keycode;
+ DECLARE_BITMAP(new_state, MTK_KPD_NUM_BITS);
+ DECLARE_BITMAP(change, MTK_KPD_NUM_BITS);
+ int bit_nr;
+ int pressed;
+ unsigned short code;
+ int row, col;
+ int row_shift = get_count_order(keypad->n_cols);
+
+ regmap_bulk_read(keypad->regmap, MTK_KPD_MEM,
+ new_state, MTK_KPD_NUM_MEMS);
+
+ bitmap_xor(change, new_state, keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ for_each_set_bit(bit_nr, change, MTK_KPD_NUM_BITS) {
+ /* For 32bits register, only bits [15:0] use to indicate key status */
+ if (bit_nr % 32 >= 16)
+ continue;
+
+ /* 1: not pressed, 0: pressed */
+ pressed = !test_bit(bit_nr, new_state);
+ dev_dbg(&keypad->input_dev->dev, "%s",
+ pressed ? "pressed" : "released");
+
+ row = bit_nr / 32;
+ col = bit_nr % 32;
+
+ code = keycode[MATRIX_SCAN_CODE(row, col, row_shift)];
+
+ input_report_key(keypad->input_dev, code, pressed);
+ input_sync(keypad->input_dev);
+
+ dev_dbg(&keypad->input_dev->dev,
+ "report Linux keycode = %d\n", code);
+ }
+
+ bitmap_copy(keypad->keymap_state, new_state, MTK_KPD_NUM_BITS);
+
+ return IRQ_HANDLED;
+}
+
+static void mt6779_keypad_clk_disable(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
+static int mt6779_keypad_pdrv_probe(struct platform_device *pdev)
+{
+ struct mt6779_keypad *keypad;
+ unsigned int irq;
+ u32 debounce;
+ bool wakeup;
+ int error;
+
+ keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
+ if (!keypad)
+ return -ENOMEM;
+
+ keypad->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(keypad->base))
+ return PTR_ERR(keypad->base);
+
+ keypad->regmap = devm_regmap_init_mmio(&pdev->dev,
+ keypad->base,
+ &mt6779_keypad_regmap_cfg);
+ if (IS_ERR(keypad->regmap)) {
+ dev_err(&pdev->dev,
+ "regmap init failed:%pe\n", keypad->regmap);
+ return PTR_ERR(keypad->regmap);
+ }
+
+ bitmap_fill(keypad->keymap_state, MTK_KPD_NUM_BITS);
+
+ keypad->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!keypad->input_dev) {
+ dev_err(&pdev->dev, "Failed to allocate input dev\n");
+ return -ENOMEM;
+ }
+
+ keypad->input_dev->name = MTK_KPD_NAME;
+ keypad->input_dev->id.bustype = BUS_HOST;
+
+ error = matrix_keypad_parse_properties(&pdev->dev, &keypad->n_rows,
+ &keypad->n_cols);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to parse keypad params\n");
+ return error;
+ }
+
+ if (device_property_read_u32(&pdev->dev, "debounce-delay-ms",
+ &debounce))
+ debounce = 16;
+
+ if (debounce > MTK_KPD_DEBOUNCE_MAX_MS) {
+ dev_err(&pdev->dev, "Debounce time exceeds the maximum allowed time %dms\n",
+ MTK_KPD_DEBOUNCE_MAX_MS);
+ return -EINVAL;
+ }
+
+ wakeup = device_property_read_bool(&pdev->dev, "wakeup-source");
+
+ dev_dbg(&pdev->dev, "n_row=%d n_col=%d debounce=%d\n",
+ keypad->n_rows, keypad->n_cols, debounce);
+
+ error = matrix_keypad_build_keymap(NULL, NULL,
+ keypad->n_rows,
+ keypad->n_cols,
+ NULL,
+ keypad->input_dev);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to build keymap\n");
+ return error;
+ }
+
+ regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
+ (debounce * 32) & MTK_KPD_DEBOUNCE_MASK);
+
+ keypad->clk = devm_clk_get(&pdev->dev, "kpd");
+ if (IS_ERR(keypad->clk))
+ return PTR_ERR(keypad->clk);
+
+ error = clk_prepare_enable(keypad->clk);
+ if (error) {
+ dev_err(&pdev->dev, "cannot prepare/enable keypad clock\n");
+ return error;
+ }
+
+ error = devm_add_action_or_reset(&pdev->dev, mt6779_keypad_clk_disable, keypad->clk);
+ if (error)
+ return error;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ error = devm_request_threaded_irq(&pdev->dev, irq,
+ NULL, mt6779_keypad_irq_handler,
+ IRQF_ONESHOT,
+ MTK_KPD_NAME, keypad);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
+ irq, error);
+ return error;
+ }
+
+ error = input_register_device(keypad->input_dev);
+ if (error) {
+ dev_err(&pdev->dev, "Failed to register device\n");
+ return error;
+ }
+
+ error = device_init_wakeup(&pdev->dev, wakeup);
+ if (error)
+ dev_warn(&pdev->dev, "device_init_wakeup fail\n");
+
+ return 0;
+}
+
+static const struct of_device_id mt6779_keypad_of_match[] = {
+ { .compatible = "mediatek,mt6779-keypad" },
+ { .compatible = "mediatek,mt6873-keypad" },
+ { /* sentinel */ }
+};
+
+static struct platform_driver mt6779_keypad_pdrv = {
+ .probe = mt6779_keypad_pdrv_probe,
+ .driver = {
+ .name = MTK_KPD_NAME,
+ .of_match_table = mt6779_keypad_of_match,
+ },
+};
+module_platform_driver(mt6779_keypad_pdrv);
+
+MODULE_AUTHOR("Mediatek Corporation");
+MODULE_DESCRIPTION("MTK Keypad (KPD) Driver");
+MODULE_LICENSE("GPL");
--
2.32.0
^ permalink raw reply related
* [PATCH v20 1/3] dt-bindings: input: Add bindings for Mediatek matrix keypad
From: Mattijs Korpershoek @ 2022-01-27 11:15 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch, Rob Herring,
Matthias Brugger, Fengping Yu, Yingjoe Chen
Cc: Mattijs Korpershoek, Fabien Parent, Kevin Hilman, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <20220127111526.3716689-1-mkorpershoek@baylibre.com>
From: "fengping.yu" <fengping.yu@mediatek.com>
This patch add devicetree bindings for Mediatek matrix keypad driver.
Signed-off-by: fengping.yu <fengping.yu@mediatek.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
---
.../input/mediatek,mt6779-keypad.yaml | 77 +++++++++++++++++++
1 file changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
diff --git a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
new file mode 100644
index 000000000000..b1770640f94b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/mediatek,mt6779-keypad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek's Keypad Controller device tree bindings
+
+maintainers:
+ - Fengping Yu <fengping.yu@mediatek.com>
+
+allOf:
+ - $ref: "/schemas/input/matrix-keymap.yaml#"
+
+description: |
+ Mediatek's Keypad controller is used to interface a SoC with a matrix-type
+ keypad device. The keypad controller supports multiple row and column lines.
+ A key can be placed at each intersection of a unique row and a unique column.
+ The keypad controller can sense a key-press and key-release and report the
+ event using a interrupt to the cpu.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt6779-keypad
+ - items:
+ - enum:
+ - mediatek,mt6873-keypad
+ - const: mediatek,mt6779-keypad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: kpd
+
+ wakeup-source:
+ description: use any event on keypad as wakeup event
+ type: boolean
+
+ debounce-delay-ms:
+ maximum: 256
+ default: 16
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/input/input.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ keyboard@10010000 {
+ compatible = "mediatek,mt6779-keypad";
+ reg = <0 0x10010000 0 0x1000>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_FALLING>;
+ clocks = <&clk26m>;
+ clock-names = "kpd";
+ };
+ };
--
2.32.0
^ permalink raw reply related
* [PATCH v20 0/3] Add matrix keypad driver support for Mediatek SoCs
From: Mattijs Korpershoek @ 2022-01-27 11:15 UTC (permalink / raw)
To: Dmitry Torokhov, Andy Shevchenko, Marco Felsch, Rob Herring,
Matthias Brugger, Fengping Yu, Yingjoe Chen
Cc: Mattijs Korpershoek, Fabien Parent, Kevin Hilman, linux-input,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
Dear all,
This is a follow-up on an abandoned series, see [1]
Since Dmitry seemed generally happy with the driver, I applied his rename
recommendations.
Thus, I have made the following:
* All Reviewed-By: tags were kept
* Applied Marco's Reviewed-By: on the bindings (since he approved v10)
* Fengping is still the maintainer since he is the original author of this driver
Please tell me if you would rather have me do things differently.
[1] https://lore.kernel.org/all/20200909072159.14888-1-fengping.yu@mediatek.com/
v19 -> v20:
bindings: use dual license
bindings: fixed 2 indentation issues found by yamllint
bindings: drop clock-names description
bindings: use standard keyboard node name for example
bindings: use default: keyword for default values
use debounce-delay-ms property instead of mediatek,debounce-us
fengping.yu (3):
dt-bindings: input: Add bindings for Mediatek matrix keypad
Input: mt6779-keypad - Add MediaTek keypad driver
arm64: defconfig: Add CONFIG_KEYBOARD_MT6779=m
.../input/mediatek,mt6779-keypad.yaml | 77 +++++++
arch/arm64/configs/defconfig | 1 +
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/mt6779-keypad.c | 218 ++++++++++++++++++
5 files changed, 309 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml
create mode 100644 drivers/input/keyboard/mt6779-keypad.c
base-commit: 87a0b2fafc09766d8c55461a18345a1cfb10a7fe
--
2.32.0
^ permalink raw reply
* Re: [PATCH v4 27/35] iommu/mediatek: Remove mtk_iommu.h
From: AngeloGioacchino Del Regno @ 2022-01-27 11:15 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-28-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> Currently there is only compare_of/release_of/a suspend structure in the
> header file. I think it is no need to keep a header file only for these.
> Move these into the c file and rm this header file.
>
> I think there should be a common helper for compare_of and release_of.
> There is many copy in drm, it should be another topic.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.c | 25 ++++++++++++++++++++-
> drivers/iommu/mtk_iommu.h | 42 ------------------------------------
> drivers/iommu/mtk_iommu_v1.c | 21 +++++++++++++++---
> 3 files changed, 42 insertions(+), 46 deletions(-)
> delete mode 100644 drivers/iommu/mtk_iommu.h
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 80c1e5a75868..f88c7bb235bf 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -14,6 +14,7 @@
> #include <linux/io.h>
> #include <linux/iommu.h>
> #include <linux/iopoll.h>
> +#include <linux/io-pgtable.h>
> #include <linux/list.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
> @@ -30,7 +31,7 @@
> #include <asm/barrier.h>
> #include <soc/mediatek/smi.h>
>
> -#include "mtk_iommu.h"
> +#include <dt-bindings/memory/mtk-memory-port.h>
>
> #define REG_MMU_PT_BASE_ADDR 0x000
> #define MMU_PT_ADDR_MASK GENMASK(31, 7)
> @@ -166,6 +167,17 @@ struct mtk_iommu_iova_region {
> unsigned long long size;
> };
>
> +struct mtk_iommu_suspend_reg {
> + u32 misc_ctrl;
> + u32 dcm_dis;
> + u32 ctrl_reg;
> + u32 int_control0;
> + u32 int_main_control;
> + u32 ivrp_paddr;
> + u32 vld_pa_rng;
> + u32 wr_len_ctrl;
> +};
> +
> struct mtk_iommu_plat_data {
> enum mtk_iommu_plat m4u_plat;
> u32 flags;
> @@ -219,6 +231,17 @@ struct mtk_iommu_domain {
> struct mutex mutex; /* Protect "data" in this structure */
> };
>
> +/* TODO: A common helper is expected. */
> +static inline int compare_of(struct device *dev, void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +static inline void release_of(struct device *dev, void *data)
> +{
> + of_node_put(data);
> +}
> +
Since it's just one line, at this point you should also open-code these,
as in you can then remove the two helper functions entirely.
So, please do that.
> static inline int mtk_iommu_bind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> deleted file mode 100644
> index d332f9769f83..000000000000
> --- a/drivers/iommu/mtk_iommu.h
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0-only */
> -/*
> - * Copyright (c) 2015-2016 MediaTek Inc.
> - * Author: Honghui Zhang <honghui.zhang@mediatek.com>
> - */
> -
> -#ifndef _MTK_IOMMU_H_
> -#define _MTK_IOMMU_H_
> -
> -#include <linux/device.h>
> -#include <linux/io.h>
> -#include <linux/io-pgtable.h>
> -#include <linux/iommu.h>
> -#include <linux/spinlock.h>
> -#include <soc/mediatek/smi.h>
> -#include <dt-bindings/memory/mtk-memory-port.h>
> -
> -struct mtk_iommu_suspend_reg {
> - union {
> - u32 standard_axi_mode;/* v1 */
> - u32 misc_ctrl;/* v2 */
> - };
> - u32 dcm_dis;
> - u32 ctrl_reg;
> - u32 int_control0;
> - u32 int_main_control;
> - u32 ivrp_paddr;
> - u32 vld_pa_rng;
> - u32 wr_len_ctrl;
> -};
> -
> -static inline int compare_of(struct device *dev, void *data)
> -{
> - return dev->of_node == data;
> -}
> -
> -static inline void release_of(struct device *dev, void *data)
> -{
> - of_node_put(data);
> -}
> -
> -#endif
> diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
> index b762a05328d4..23c3bc175153 100644
> --- a/drivers/iommu/mtk_iommu_v1.c
> +++ b/drivers/iommu/mtk_iommu_v1.c
> @@ -7,7 +7,6 @@
> *
> * Based on driver/iommu/mtk_iommu.c
> */
> -#include <linux/memblock.h>
> #include <linux/bug.h>
> #include <linux/clk.h>
> #include <linux/component.h>
> @@ -28,10 +27,9 @@
> #include <linux/spinlock.h>
> #include <asm/barrier.h>
> #include <asm/dma-iommu.h>
> -#include <linux/init.h>
> +#include <dt-bindings/memory/mtk-memory-port.h>
> #include <dt-bindings/memory/mt2701-larb-port.h>
> #include <soc/mediatek/smi.h>
> -#include "mtk_iommu.h"
>
> #define REG_MMU_PT_BASE_ADDR 0x000
>
> @@ -87,6 +85,13 @@
> */
> #define M2701_IOMMU_PGT_SIZE SZ_4M
>
> +struct mtk_iommu_suspend_reg {
> + u32 standard_axi_mode;
> + u32 dcm_dis;
> + u32 ctrl_reg;
> + u32 int_control0;
> +};
> +
> struct mtk_iommu_data {
> void __iomem *base;
> int irq;
> @@ -110,6 +115,16 @@ struct mtk_iommu_domain {
> struct mtk_iommu_data *data;
> };
>
> +static inline int compare_of(struct device *dev, void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +static inline void release_of(struct device *dev, void *data)
> +{
> + of_node_put(data);
> +}
> +
....And the same comment applies here too.
> static inline int mtk_iommu_bind(struct device *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
>
^ permalink raw reply
* Re: [PATCH v4 08/35] iommu/mediatek: Use kmalloc for protect buffer
From: AngeloGioacchino Del Regno @ 2022-01-27 11:08 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, youlin.pei, anan.sun, xueqi.zhang, yen-chang.chen,
mingyuan.ma, yf.wang, libo.kang, chengci.xu
In-Reply-To: <20220125085634.17972-9-yong.wu@mediatek.com>
Il 25/01/22 09:56, Yong Wu ha scritto:
> No need zero for the protect buffer that is only accessed by the IOMMU HW
> translation fault happened.
>
> Signed-off-by: Yong Wu <yong.wu@mediatek.com>
I would rather keep this a devm_kzalloc instead... the cost is very minimal and
this will be handy when new hardware will be introduced, as it may require a bigger
buffer: in that case, "older" platforms will use only part of it and we may get
garbage data at the end.
Regards,
Angelo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox