* [PATCH 1/2] dt-bindings: serial: add generic DT binding for announcing RTS/CTS lines
From: Erwan Le Ray @ 2020-05-20 13:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Sumit Semwal
Cc: linux-kernel, dri-devel, linaro-mm-sig, Erwan Le Ray,
linux-serial, Fabrice Gasnier, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <20200520133932.30441-1-erwan.leray@st.com>
Add support of generic DT binding for annoucing RTS/CTS lines. The initial
binding 'st,hw-flow-control' is not needed anymore since generic binding
is available, but is kept for backward compatibility.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 75b8521eb7cb..06d5f251ec88 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -35,9 +35,11 @@ properties:
description: label associated with this uart
st,hw-flow-ctrl:
- description: enable hardware flow control
+ description: enable hardware flow control (deprecated)
$ref: /schemas/types.yaml#/definitions/flag
+ uart-has-rtscts: true
+
dmas:
minItems: 1
maxItems: 2
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] add generic DT binding for RTS/CTS
From: Erwan Le Ray @ 2020-05-20 13:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Sumit Semwal
Cc: linux-kernel, dri-devel, linaro-mm-sig, Erwan Le Ray,
linux-serial, Fabrice Gasnier, linux-stm32, linux-arm-kernel,
linux-media
Add support of generic DT binding for annoucing RTS/CTS lines. The initial
binding 'st,hw-flow-control' is not needed anymore since generic binding
is available, but is kept for backward compatibility.
Erwan Le Ray (2):
dt-bindings: serial: add generic DT binding for announcing RTS/CTS
lines
serial: stm32: Use generic DT binding for announcing RTS/CTS lines
Documentation/devicetree/bindings/serial/st,stm32-uart.yaml | 4 +++-
drivers/tty/serial/stm32-usart.c | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 11/11] arm64: tegra: Device tree changes for v5.8-rc1
From: Thierry Reding @ 2020-05-20 13:43 UTC (permalink / raw)
To: arm, soc; +Cc: linux-tegra, linux-arm-kernel, Jon Hunter
In-Reply-To: <20200515145311.1580134-12-thierry.reding@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1527 bytes --]
On Fri, May 15, 2020 at 04:53:11PM +0200, Thierry Reding wrote:
> Hi ARM SoC maintainers,
>
> The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
>
> Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-5.8-arm64-dt
>
> for you to fetch changes up to 74265112c60be0209817c682ba68661c05da1d38:
>
> arm64: tegra: Enable VI I2C on Jetson Nano (2020-05-15 16:28:58 +0200)
Hi Arnd, Olof,
Actually, can you hold off on merging this for a little bit? I'd like to
send out a v2 of this because I noticed that...
> Thanks,
> Thierry
>
> ----------------------------------------------------------------
> arm64: tegra: Device tree changes for v5.8-rc1
>
> This contains a couple of fixes for minor issues, enables XUDC support
> on Tegra194, and enables EMC frequency scaling and video capture on
> Tegra210.
>
> ----------------------------------------------------------------
> Jon Hunter (2):
> arm64: tegra: Fix ethernet phy-mode for Jetson Xavier
> arm64: tegra: Allow the PMIC RTC to wakeup Jetson Xavier
>
> Joseph Lo (1):
> arm64: tegra: Add external memory controller node for Tegra210
... this patch contains some leftover changelog notes that I forgot to
remove.
There's also one fix missing from this that I was meaning to apply for
v5.8 which will enable suspend/resume on Tegra186.
Thanks,
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/15] PCI: brcmstb: Set bus max burst side by chip type
From: Nicolas Saenz Julienne @ 2020-05-20 13:44 UTC (permalink / raw)
To: Jim Quinlan
Cc: Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200519203419.12369-15-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 3389 bytes --]
On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> The proper value of the parameter SCB_MAX_BURST_SIZE varies
> per chip. The 2711 family requires 128B whereas other devices
> can employ 512. The assignment is complicated by the fact
> that the values for this two-bit field have different meanings;
>
> Value Type_Generic Type_7278
>
> 00 Reserved 128B
> 01 128B 256B
> 10 256B 512B
> 11 512B Reserved
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> ---
> drivers/pci/controller/pcie-brcmstb.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c
> b/drivers/pci/controller/pcie-brcmstb.c
> index 7bf945efd71b..0dfa1bbd9764 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -53,7 +53,7 @@
> #define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
> #define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
> #define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
> -#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
> +
> #define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
> #define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
> #define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
> @@ -276,6 +276,7 @@ struct brcm_pcie {
> int num_memc;
> u64 memc_size[PCIE_BRCM_MAX_MEMC];
> u32 hw_rev;
> + const struct of_device_id *of_id;
> };
>
> /*
> @@ -841,7 +842,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> int num_out_wins = 0;
> u16 nlw, cls, lnksta;
> int i, ret, memc;
> - u32 tmp, aspm_support;
> + u32 tmp, burst, aspm_support;
>
> /* Reset the bridge */
> brcm_pcie_bridge_sw_init_set(pcie, 1);
> @@ -857,10 +858,20 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> /* Wait for SerDes to be stable */
> usleep_range(100, 200);
>
> + /*
> + * SCB_MAX_BURST_SIZE is a two bit field. For GENERIC chips it
> + * is encoded as 0=128, 1=256, 2=512, 3=Rsvd, for BCM7278 it
> + * is encoded as 0=Rsvd, 1=128, 2=256, 3=512.
> + */
> + if (strcmp(pcie->of_id->compatible, "brcm,bcm2711-pcie") == 0)
Would it make sense to use pcie->type here? I know GENERIC != BCM2711, but we
could define it and avoid adding redundant info in struct brcm_pcie.
Regards,
Nicolas
> + burst = 0x0; /* 128B */
> + else
> + burst = (pcie->type == BCM7278) ? 0x3 : 0x2; /* 512 bytes */
> +
> /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK);
> u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK);
> - u32p_replace_bits(&tmp, PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128,
> + u32p_replace_bits(&tmp, burst,
> PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK);
> writel(tmp, base + PCIE_MISC_MISC_CTRL);
>
> @@ -1200,6 +1211,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> pcie->reg_offsets = data->offsets;
> pcie->reg_field_info = data->reg_field_info;
> pcie->type = data->type;
> + pcie->of_id = of_id;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> pcie->base = devm_ioremap_resource(&pdev->dev, res);
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] i2c: imx-lpi2c: fix runtime pm imbalance on error
From: Dinghao Liu @ 2020-05-20 13:46 UTC (permalink / raw)
To: dinghao.liu, kjlu
Cc: Dong Aisheng, Shawn Guo, Sascha Hauer, linux-kernel,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel, linux-i2c
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 94743ba581fe..89908c24c8b3 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -260,8 +260,10 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct *lpi2c_imx)
int ret;
ret = pm_runtime_get_sync(lpi2c_imx->adapter.dev.parent);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_autosuspend(lpi2c_imx->adapter.dev.parent);
return ret;
+ }
temp = MCR_RST;
writel(temp, lpi2c_imx->base + LPI2C_MCR);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: pxa: remove Compulab pxa2xx boards
From: Arnd Bergmann @ 2020-05-20 13:49 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Miquel Raynal, igor, Boris Brezillon, linux-mtd, Mike Rapoport,
Linux ARM
In-Reply-To: <87h7waoqin.fsf@belgarion.home>
On Wed, May 20, 2020 at 12:22 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >
> > FB_MBX can still be selected, but there are no boards defining
> > the platform data any more, so I'd like to remove that as well.
> That should be dealt with another time, sorry.
>
> >> -static struct spi_board_info spi_board_info[] __initdata = {
> >> - [0] = {
> >> - .modalias = "rtc-max6902",
> >> - .max_speed_hz = 1000000,
> >> - .bus_num = 1,
> >> - .chip_select = 0,
> >
> > Another last reference, so we can remove that the corresponding driver.
> Another patch serie for this as well.
Ok, no problem, as long as someone remembers to do it.
> > Same here, there is still one more user left (MACH_ZIPIT2), though
> > at some point that might get removed if we decide to drop the handhelds
> > with 32MB RAM or less. That is probably something to be left for
> > another time, but I see that pxa_defconfig produces a 9.5MB kernel
> > image, so this is getting rather tight, and 32MB wasn't much when this
> > got added in 2010.
> Yeah, but no PXA user would ever use the pxa_defconfig kernel :)
> A typical kernel for a PXA board is right now around 4MB, which is very tight
> for 32MB platforms, and just enough for 64MB ones.
Makes sense.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 14/17] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR2 register
From: Suzuki K Poulose @ 2020-05-20 13:56 UTC (permalink / raw)
To: anshuman.khandual, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <1589881254-10082-15-git-send-email-anshuman.khandual@arm.com>
On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
> Enable EVT, BBM, TTL, IDS, ST, NV and CCIDX features bits in ID_AA64MMFR2
> register as per ARM DDI 0487F.a specification.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Please note that there other series addressing TTL. So might
have conflicts.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 15/17] arm64/cpufeature: Add remaining feature bits in ID_AA64DFR0 register
From: Suzuki K Poulose @ 2020-05-20 13:57 UTC (permalink / raw)
To: anshuman.khandual, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <1589881254-10082-16-git-send-email-anshuman.khandual@arm.com>
On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
> Enable MTPMU and TRACEFILT features bits in ID_AA64DFR0 register as per ARM
> DDI 0487F.a specification.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> arch/arm64/include/asm/sysreg.h | 2 ++
> arch/arm64/kernel/cpufeature.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index a572069ccf6e..4bcd21cc2d68 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -766,6 +766,8 @@
> #define ID_AA64MMFR2_CNP_SHIFT 0
>
> /* id_aa64dfr0 */
> +#define ID_AA64DFR0_MTPMU_SHIFT 48
> +#define ID_AA64DFR0_TRACEFILT_SHIFT 40
> #define ID_AA64DFR0_PMSVER_SHIFT 32
> #define ID_AA64DFR0_CTX_CMPS_SHIFT 28
> #define ID_AA64DFR0_WRPS_SHIFT 20
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 6338151f263c..986974be0178 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -366,6 +366,8 @@ static const struct arm64_ftr_bits ftr_id_mmfr0[] = {
> };
>
> static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_MTPMU_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64DFR0_TRACEFILT_SHIFT, 4, 0),
We maske both the fields for KVM in AArch32 ID registers. We should do
the same here.
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 17/17] arm64/cpuinfo: Add ID_MMFR4_EL1 into the cpuinfo_arm64 context
From: Suzuki K Poulose @ 2020-05-20 13:58 UTC (permalink / raw)
To: anshuman.khandual, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <1589881254-10082-18-git-send-email-anshuman.khandual@arm.com>
On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
> ID_MMFR4_EL1 has been missing in the CPU context (i.e cpuinfo_arm64). This
> just adds the register along with other required changes.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: pxa: remove Compulab pxa2xx boards
From: Arnd Bergmann @ 2020-05-20 13:58 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Boris Brezillon, linux-mtd, Mike Rapoport, Linux ARM,
Miquel Raynal
In-Reply-To: <20200520102125.8934-3-robert.jarzmik@free.fr>
On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
> As these boards have been removed from the pxa tree, amend accordingly
> the sound subsystem.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Arnd Bergmann <arnd@arndb.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] arm64/cpufeature: Drop open encodings while extracting parange
From: Marc Zyngier @ 2020-05-20 14:05 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, Catalin Marinas, linux-kernel, James Morse,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <1589360614-1164-1-git-send-email-anshuman.khandual@arm.com>
On Wed, 13 May 2020 14:33:34 +0530
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> Currently there are multiple instances of parange feature width mask open
> encodings while fetching it's value. Even the width mask value (0x7) itself
> is not accurate. It should be (0xf) per ID_AA64MMFR0_EL1.PARange[3:0] as in
> ARM ARM (0487F.a). Replace them with cpuid_feature_extract_unsigned_field()
> which can extract given standard feature (4 bits width i.e 0xf mask) field.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Cc: kvmarm@lists.cs.columbia.edu
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/15] PCI: brcmstb: Set bus max burst side by chip type
From: Jim Quinlan @ 2020-05-20 14:27 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <4a49e7724e9a12e4f128a5e9ff4181da7af40bd3.camel@suse.de>
On Wed, May 20, 2020 at 9:44 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > The proper value of the parameter SCB_MAX_BURST_SIZE varies
> > per chip. The 2711 family requires 128B whereas other devices
> > can employ 512. The assignment is complicated by the fact
> > that the values for this two-bit field have different meanings;
> >
> > Value Type_Generic Type_7278
> >
> > 00 Reserved 128B
> > 01 128B 256B
> > 10 256B 512B
> > 11 512B Reserved
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 18 +++++++++++++++---
> > 1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > b/drivers/pci/controller/pcie-brcmstb.c
> > index 7bf945efd71b..0dfa1bbd9764 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -53,7 +53,7 @@
> > #define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
> > #define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
> > #define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
> > -#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
> > +
> > #define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
> > #define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
> > #define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
> > @@ -276,6 +276,7 @@ struct brcm_pcie {
> > int num_memc;
> > u64 memc_size[PCIE_BRCM_MAX_MEMC];
> > u32 hw_rev;
> > + const struct of_device_id *of_id;
> > };
> >
> > /*
> > @@ -841,7 +842,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> > int num_out_wins = 0;
> > u16 nlw, cls, lnksta;
> > int i, ret, memc;
> > - u32 tmp, aspm_support;
> > + u32 tmp, burst, aspm_support;
> >
> > /* Reset the bridge */
> > brcm_pcie_bridge_sw_init_set(pcie, 1);
> > @@ -857,10 +858,20 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> > /* Wait for SerDes to be stable */
> > usleep_range(100, 200);
> >
> > + /*
> > + * SCB_MAX_BURST_SIZE is a two bit field. For GENERIC chips it
> > + * is encoded as 0=128, 1=256, 2=512, 3=Rsvd, for BCM7278 it
> > + * is encoded as 0=Rsvd, 1=128, 2=256, 3=512.
> > + */
> > + if (strcmp(pcie->of_id->compatible, "brcm,bcm2711-pcie") == 0)
>
> Would it make sense to use pcie->type here? I know GENERIC != BCM2711, but we
> could define it and avoid adding redundant info in struct brcm_pcie.
Yes, that would get rid of the need for keeping of_id around.
Thanks,
Jim
>
> Regards,
> Nicolas
>
> > + burst = 0x0; /* 128B */
> > + else
> > + burst = (pcie->type == BCM7278) ? 0x3 : 0x2; /* 512 bytes */
> > +
> > /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> > u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK);
> > u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK);
> > - u32p_replace_bits(&tmp, PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128,
> > + u32p_replace_bits(&tmp, burst,
> > PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK);
> > writel(tmp, base + PCIE_MISC_MISC_CTRL);
> >
> > @@ -1200,6 +1211,7 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> > pcie->reg_offsets = data->offsets;
> > pcie->reg_field_info = data->reg_field_info;
> > pcie->type = data->type;
> > + pcie->of_id = of_id;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > pcie->base = devm_ioremap_resource(&pdev->dev, res);
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 04/15] PCI: brcmstb: Add compatibily of other chips
From: Jim Quinlan @ 2020-05-20 14:30 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <5a52e39ce99214877e83104b8ea9f95c0d5b4e90.camel@suse.de>
On Wed, May 20, 2020 at 7:51 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Hi Jim,
>
> On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > Add in compatibility strings and code for three Broadcom STB chips.
> > Some of the register locations, shifts, and masks are different
> > for certain chips, requiring the use of different constants based
> > on of_id.
> >
> > We would like to add the following at this time to the match list
> > but we need to wait until the end of this patchset so that
> > everything works.
> >
> > { .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
> > { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
> > { .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
> > { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > drivers/pci/controller/pcie-brcmstb.c | 103 +++++++++++++++++++++++---
> > 1 file changed, 91 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > b/drivers/pci/controller/pcie-brcmstb.c
> > index 73020b4ff090..c1cf4ea7d3d9 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -120,9 +120,8 @@
> > #define PCIE_EXT_SLOT_SHIFT 15
> > #define PCIE_EXT_FUNC_SHIFT 12
> >
> > -#define PCIE_RGR1_SW_INIT_1 0x9210
> > #define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
> > -#define PCIE_RGR1_SW_INIT_1_INIT_MASK 0x2
> > +#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
> >
> > /* PCIe parameters */
> > #define BRCM_NUM_PCIE_OUT_WINS 0x4
> > @@ -152,6 +151,69 @@
> > #define SSC_STATUS_SSC_MASK 0x400
> > #define SSC_STATUS_PLL_LOCK_MASK 0x800
> >
> > +#define IDX_ADDR(pcie) \
> > + (pcie->reg_offsets[EXT_CFG_INDEX])
> > +#define DATA_ADDR(pcie) \
> > + (pcie->reg_offsets[EXT_CFG_DATA])
> > +#define PCIE_RGR1_SW_INIT_1(pcie) \
> > + (pcie->reg_offsets[RGR1_SW_INIT_1])
> > +
> > +enum {
> > + RGR1_SW_INIT_1,
> > + EXT_CFG_INDEX,
> > + EXT_CFG_DATA,
> > +};
> > +
> > +enum {
> > + RGR1_SW_INIT_1_INIT_MASK,
> > + RGR1_SW_INIT_1_INIT_SHIFT,
> > +};
> > +
> > +enum pcie_type {
> > + GENERIC,
> > + BCM7278,
> > +};
> > +
> > +struct pcie_cfg_data {
> > + const int *reg_field_info;
> > + const int *offsets;
> > + const enum pcie_type type;
> > +};
> > +
> > +static const int pcie_reg_field_info[] = {
> > + [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
> > + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
> > +};
> > +
> > +static const int pcie_reg_field_info_bcm7278[] = {
> > + [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
> > + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
> > +};
> > +
> > +static const int pcie_offsets[] = {
> > + [RGR1_SW_INIT_1] = 0x9210,
> > + [EXT_CFG_INDEX] = 0x9000,
> > + [EXT_CFG_DATA] = 0x9004,
> > +};
> > +
> > +static const struct pcie_cfg_data generic_cfg = {
> > + .reg_field_info = pcie_reg_field_info,
> > + .offsets = pcie_offsets,
> > + .type = GENERIC,
> > +};
> > +
> > +static const int pcie_offset_bcm7278[] = {
> > + [RGR1_SW_INIT_1] = 0xc010,
> > + [EXT_CFG_INDEX] = 0x9000,
> > + [EXT_CFG_DATA] = 0x9004,
> > +};
> > +
> > +static const struct pcie_cfg_data bcm7278_cfg = {
> > + .reg_field_info = pcie_reg_field_info_bcm7278,
> > + .offsets = pcie_offset_bcm7278,
> > + .type = BCM7278,
> > +};
>
> It's not essential, but if v2 is due I'd suggest factoring out the bcm2728
> specific structures above, and moving them to patch #15. This will keep a
> clearer division between the patch introducing the infrastructure and the one
> adding the support for a new device.
The problem is that one of the commits needs the 7278 type so it has
to be declared earlier.
>
> > +
> > struct brcm_msi {
> > struct device *dev;
> > void __iomem *base;
> > @@ -176,6 +238,9 @@ struct brcm_pcie {
> > int gen;
> > u64 msi_target_addr;
> > struct brcm_msi *msi;
> > + const int *reg_offsets;
> > + const int *reg_field_info;
> > + enum pcie_type type;
> > };
> >
> > /*
> > @@ -602,20 +667,21 @@ static struct pci_ops brcm_pcie_ops = {
> >
> > static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie, u32
> > val)
> > {
> > - u32 tmp;
> > + u32 tmp, mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
> > + u32 shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
>
> I don't think you need shift here, IIUC u32p_replace_bits() will take care of
> all the masking and shifting internally, moreover, you'd be able to drop the
> shift entry from reg_field_info.
Got it.
>
> > - tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
> > - u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_INIT_MASK);
> > - writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
> > + tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
> > + tmp = (tmp & ~mask) | ((val << shift) & mask);
> > + writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
> > }
>
> Regards,
> Nicolas
>
Thanks!
Jim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value
From: Lukasz Stelmach @ 2020-05-20 14:31 UTC (permalink / raw)
To: Stephan Mueller
Cc: Florian Fainelli, Herbert Xu, Scott Branden, Matthias Brugger,
Greg Kroah-Hartman, Matt Mackall, linux-kernel,
Krzysztof Kozlowski, linux-samsung-soc, Bartlomiej Zolnierkiewicz,
Kukjin Kim, Arnd Bergmann, Stefan Wahren, Ray Jui,
bcm-kernel-feedback-list, Markus Elfring, linux-arm-kernel,
linux-crypto
In-Reply-To: <2041475.ybOAuNAZB8@tauon.chronox.de>
[-- Attachment #1.1: Type: text/plain, Size: 3719 bytes --]
It was <2020-05-20 śro 13:53>, when Stephan Mueller wrote:
> Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach:
>> It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote:
>>> Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach:
>>>> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote:
>>>>> Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
>>>>>
>>>>>> The value was estimaded with ea_iid[1] using on 10485760 bytes
>>>>>> read from the RNG via /dev/hwrng. The min-entropy value
>>>>>> calculated using the most common value estimate (NIST SP
>>>>>> 800-90P[2], section 6.3.1) was 7.964464.
>>>>>
>>>>> I am sorry, but I think I did not make myself clear: testing
>>>>> random numbers post-processing with the statistical tools does NOT
>>>>> give any idea about the entropy rate. Thus, all that was
>>>>> calculated is the proper implementation of the post-processing
>>>>> operation and not the actual noise source.
>>>>>
>>>>> What needs to happen is that we need access to raw, unconditioned
>>>>> data from the noise source that is analyzed with the statistical
>>>>> methods.
>>>>
>>>> I did understand you and I assure you the data I tested were
>>>> obtained directly from RNGs. As I pointed before[1], that is how
>>>> /dev/hwrng works[2].
>>>
>>> I understand that /dev/hwrng pulls the data straight from the
>>> hardware. But the data from the hardware usually is not obtained
>>> straight from the noise source.
>>>
>>> Typically you have a noise source (e.g. a ring oscillator) whose data
>>> is digitized then fed into a compression function like an LFSR or a
>>> hash. Then a cryptographic operation like a CBC-MAC, hash or even a
>>> DRBG is applied to that data when the caller wants to have random
>>> numbers.
[...]
>>> In order to estimate entropy, we need the raw unconditioned data from
>>> the, say, ring oscillator and not from the (cryptographic) output
>>> operation.
>>
>> Can you tell, why it matters in this case? If I understand correctly,
>> the quality field describes not the randomness created by the noise
>> generator but the one delivered by the driver to other software
>> components.
>
> The quality field is used by add_hwgenerator_randomness to increase
> the Linux RNG entropy estimator accordingly. This is the issue.
>
> And giving an entropy rate based on post-processed data is
> meaningless.
>
> The concern is, for example, that you use a DRBG that you seeded with,
> say, a zero buffer. You get perfect random data from it that no
> statistical test can disprove. Yet we know this data stream has zero
> entropy. Thus, we need to get to the source and assess its entropy.
Of course, this makes sense.
>>> That said, the illustrated example is typical for hardware RNGs. Yet
>>> it is never guaranteed to work that way. Thus, if you can point to
>>> architecture documentation of your specific hardware RNGs showing
>>> that the data read from the hardware is pure unconditioned noise
>>> data, then I have no objections to the patch.
>>
>> I can tell for sure that this is the case for exynos-trng[1].
>
> So you are saying that the output for the exynos-trng is straight from
> a ring oscillator without any post-processing of any kind?
>
> If this is the case, I would like to suggest you add that statement to
> the git commit message with that reference. If so, then I would
> withdraw my objection.
Done. I will do some reaserch on iproc-rng200 and I will send v3 with
the altered commit message.
Thank you *very* much for your patience.
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 06/11] net: ethernet: mtk-eth-mac: new driver
From: Arnd Bergmann @ 2020-05-20 14:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, DTML, Stephane Le Provost, Bartosz Golaszewski,
Networking, Sean Wang, linux-kernel@vger.kernel.org, Pedro Tsai,
David S . Miller, Fabien Parent, Rob Herring,
moderated list:ARM/Mediatek SoC..., Andrew Perepech, John Crispin,
Matthias Brugger, Jakub Kicinski, Mark Lee, Linux ARM,
Heiner Kallweit
In-Reply-To: <20200520112523.30995-7-brgl@bgdev.pl>
On Wed, May 20, 2020 at 1:25 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> family. For now we only support full-duplex.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Looks much better, thanks for addressing my feedback. A few more things
about this version:
> ---
> drivers/net/ethernet/mediatek/Kconfig | 6 +
> drivers/net/ethernet/mediatek/Makefile | 1 +
> drivers/net/ethernet/mediatek/mtk_eth_mac.c | 1668 +++++++++++++++++++
> 3 files changed, 1675 insertions(+)
> create mode 100644 drivers/net/ethernet/mediatek/mtk_eth_mac.c
>
> diff --git a/drivers/net/ethernet/mediatek/Kconfig b/drivers/net/ethernet/mediatek/Kconfig
> index 5079b8090f16..5c3793076765 100644
> --- a/drivers/net/ethernet/mediatek/Kconfig
> +++ b/drivers/net/ethernet/mediatek/Kconfig
> @@ -14,4 +14,10 @@ config NET_MEDIATEK_SOC
> This driver supports the gigabit ethernet MACs in the
> MediaTek SoC family.
>
> +config NET_MEDIATEK_MAC
> + tristate "MediaTek Ethernet MAC support"
> + select PHYLIB
> + help
> + This driver supports the ethernet IP on MediaTek MT85** SoCs.
I just noticed how the naming of NET_MEDIATEK_MAC and NET_MEDIATEK_SOC
for two different drivers doing the same thing is really confusing.
Maybe someone can come up with a better name, such as one
based on the soc it first showed up in.
> + struct mtk_mac_ring_desc *desc = &ring->descs[ring->head];
> + unsigned int status;
> +
> + status = desc->status;
> +
> + ring->skbs[ring->head] = desc_data->skb;
> + ring->dma_addrs[ring->head] = desc_data->dma_addr;
> + desc->data_ptr = desc_data->dma_addr;
> +
> + status |= desc_data->len;
> + if (flags)
> + status |= flags;
> + desc->status = status;
> +
> + /* Flush previous modifications before ownership change. */
> + dma_wmb();
> + desc->status &= ~MTK_MAC_DESC_BIT_COWN;
You still do the read-modify-write on the word here, which is
expensive on uncached memory. You have read the value already,
so better use an assignment rather than &=, or (better)
READ_ONCE() and WRITE_ONCE() to prevent the compiler
from adding further accesses.
> +static void mtk_mac_lock(struct mtk_mac_priv *priv)
> +{
> + spin_lock_bh(&priv->lock);
> +}
> +
> +static void mtk_mac_unlock(struct mtk_mac_priv *priv)
> +{
> + spin_unlock_bh(&priv->lock);
> +}
I think open-coding the locks would make this more readable,
and let you use spin_lock() instead of spin_lock_bh() in
those functions that are already in softirq context.
> +static void mtk_mac_intr_enable_tx(struct mtk_mac_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MTK_MAC_REG_INT_MASK,
> + MTK_MAC_BIT_INT_STS_TNTC, 0);
> +}
> +static void mtk_mac_intr_enable_rx(struct mtk_mac_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MTK_MAC_REG_INT_MASK,
> + MTK_MAC_BIT_INT_STS_FNRC, 0);
> +}
These imply reading the irq mask register and then writing it again,
which is much more expensive than just writing it. It's also not
atomic since the regmap does not use a lock.
I don't think you actually need to enable/disable rx and tx separately,
but if you do, then writing to the Ack register as I suggested instead
of updating the mask would let you do this.
> +/* All processing for TX and RX happens in the napi poll callback. */
> +static irqreturn_t mtk_mac_handle_irq(int irq, void *data)
> +{
> + struct mtk_mac_priv *priv;
> + struct net_device *ndev;
> + bool need_napi = false;
> + unsigned int status;
> +
> + ndev = data;
> + priv = netdev_priv(ndev);
> +
> + if (netif_running(ndev)) {
> + status = mtk_mac_intr_read(priv);
> +
> + if (status & MTK_MAC_BIT_INT_STS_TNTC) {
> + mtk_mac_intr_disable_tx(priv);
> + need_napi = true;
> + }
> +
> + if (status & MTK_MAC_BIT_INT_STS_FNRC) {
> + mtk_mac_intr_disable_rx(priv);
> + need_napi = true;
> + }
I think you mixed up the rx and tx bits here: when you get
an rx interrupt, that one is already blocked until it gets
acked and you just need to disable tx until the end of the
poll function.
However, I suspect that the overhead of turning them off
is higher than what you can save, and simply ignoring
the mask with
if (status & (MTK_MAC_BIT_INT_STS_FNRC | MTK_MAC_BIT_INT_STS_TNTC))
napi_schedule(&priv->napi);
would be simpler and faster.
+ /* One of the counters reached 0x8000000 - update stats and
> + * reset all counters.
> + */
> + if (unlikely(status & MTK_MAC_REG_INT_STS_MIB_CNT_TH)) {
> + mtk_mac_intr_disable_stats(priv);
> + schedule_work(&priv->stats_work);
> + }
> + befor
> + mtk_mac_intr_ack_all(priv);
The ack here needs to be dropped, otherwise you can get further
interrupts before the bottom half has had a chance to run.
You might be lucky because you had already disabled the individual
bits earlier, but I don't think that was intentional here.
> +static int mtk_mac_netdev_start_xmit(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + struct mtk_mac_priv *priv = netdev_priv(ndev);
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct device *dev = mtk_mac_get_dev(priv);
> + struct mtk_mac_ring_desc_data desc_data;
> +
> + desc_data.dma_addr = mtk_mac_dma_map_tx(priv, skb);
> + if (dma_mapping_error(dev, desc_data.dma_addr))
> + goto err_drop_packet;
> +
> + desc_data.skb = skb;
> + desc_data.len = skb->len;
> +
> + mtk_mac_lock(priv);
> +
> + mtk_mac_ring_push_head_tx(ring, &desc_data);
> +
> + netdev_sent_queue(ndev, skb->len);
> +
> + if (mtk_mac_ring_full(ring))
> + netif_stop_queue(ndev);
> +
> + mtk_mac_unlock(priv);
> +
> + mtk_mac_dma_resume_tx(priv);
mtk_mac_dma_resume_tx() is an expensive read-modify-write
on an mmio register, so it would make sense to defer it based
on netdev_xmit_more(). (I had missed this in the previous
review)
> +static void mtk_mac_tx_complete_all(struct mtk_mac_priv *priv)
> +{
> + struct mtk_mac_ring *ring = &priv->tx_ring;
> + struct net_device *ndev = priv->ndev;
> + int ret, pkts_compl, bytes_compl;
> + bool wake = false;
> +
> + mtk_mac_lock(priv);
> +
> + for (pkts_compl = 0, bytes_compl = 0;;
> + pkts_compl++, bytes_compl += ret, wake = true) {
> + if (!mtk_mac_ring_descs_available(ring))
> + break;
> +
> + ret = mtk_mac_tx_complete_one(priv);
> + if (ret < 0)
> + break;
> + }
> +
> + netdev_completed_queue(ndev, pkts_compl, bytes_compl);
> +
> + if (wake && netif_queue_stopped(ndev))
> + netif_wake_queue(ndev);
> +
> + mtk_mac_intr_enable_tx(priv);
No need to ack the interrupt here if napi is still active. Just
ack both rx and tx when calling napi_complete().
Some drivers actually use the napi budget for both rx and tx:
if you have more than 'budget' completed tx frames, return
early from this function and skip the napi_complete even
when less than 'budget' rx frames have arrived.
This way you get more fairness between devices and
can run for longer with irqs disabled as long as either rx
or tx is busy.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: dts: imx: imx6qdl-gw: add Gateworks System Controller
From: Tim Harvey @ 2020-05-20 14:37 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
devicetree, Rob Herring
Cc: Tim Harvey, linux-kernel, linux-arm-kernel
Add Gateworks System Controller support to Gateworks Ventana boards:
- add dt bindings for GSC mfd driver and hwmon driver for ADC's and
fan controllers.
- add dt bindings for gpio-keys driver for push-button and interrupt events
from the GSC.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 152 +++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 158 ++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 164 +++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 166 ++++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 146 ++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 152 +++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw553x.dtsi | 140 +++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 164 +++++++++++++++++++++++++++++++--
arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 139 +++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw5904.dtsi | 140 +++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw5907.dtsi | 141 ++++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 159 +++++++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw5912.dtsi | 146 +++++++++++++++++++++++++++++-
arch/arm/boot/dts/imx6qdl-gw5913.dtsi | 152 ++++++++++++++++++++++++++++++-
14 files changed, 2062 insertions(+), 57 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 419a7cd..5fbf7d1 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -19,6 +19,53 @@
bootargs = "console=ttymxc1,115200";
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,6 +149,103 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_an1";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -126,13 +270,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -387,6 +524,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x0001b0b0 /* GSC_IRQ# */
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 60563ff..9f7436d 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -28,6 +28,53 @@
default-brightness-level = <7>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -165,6 +212,109 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+
+ channel@29 {
+ gw,mode = <1>;
+ reg = <0x29>;
+ label = "vdd_an1";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -189,13 +339,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -504,6 +647,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 8942bec..2a5f484 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -28,6 +28,53 @@
default-brightness-level = <7>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -158,6 +205,115 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+
+ channel@26 {
+ gw,mode = <1>;
+ reg = <0x26>;
+ label = "vdd_gps";
+ };
+
+ channel@29 {
+ gw,mode = <1>;
+ reg = <0x29>;
+ label = "vdd_an1";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -182,13 +338,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -486,6 +635,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index c40583d..d25d73d 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -29,6 +29,53 @@
default-brightness-level = <7>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -195,6 +242,117 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+
+ channel@26 {
+ gw,mode = <1>;
+ reg = <0x26>;
+ label = "vdd_gps";
+ };
+ };
+
+ fan-controller@2c {
+ compatible = "gw,gsc-fan";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2c>;
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -219,13 +377,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -571,6 +722,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index c38e86e..90c6d0d 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -63,6 +63,53 @@
bootargs = "console=ttymxc1,115200";
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -167,6 +214,97 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8a";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0b";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -191,13 +329,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -464,6 +595,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
index bb35971..0d563be 100644
--- a/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw552x.dtsi
@@ -20,6 +20,53 @@
bootargs = "console=ttymxc1,115200";
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -92,6 +139,103 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -116,13 +260,6 @@
pagesize = <16>;
};
- gpio: pca9555@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
rtc: ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -305,6 +442,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
index ee85031..7f67180 100644
--- a/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw553x.dtsi
@@ -61,6 +61,53 @@
stdout-path = &uart2;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -130,11 +177,101 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- gpio: pca9555@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8a";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0b";
+ };
+
+ channel@26 {
+ gw,mode = <1>;
+ reg = <0x26>;
+ label = "vdd_an1";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom1: eeprom@50 {
@@ -428,6 +565,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
index 69ca70d..cb20301 100644
--- a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
@@ -88,6 +88,53 @@
default-on;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -243,6 +290,115 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_an1";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+
+ channel@26 {
+ gw,mode = <1>;
+ reg = <0x26>;
+ label = "vdd_gps";
+ };
+
+ channel@29 {
+ gw,mode = <1>;
+ reg = <0x29>;
+ label = "vdd_an2";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
+ };
+
eeprom1: eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
@@ -267,13 +423,6 @@
pagesize = <16>;
};
- pca9555: gpio@23 {
- compatible = "nxp,pca9555";
- reg = <0x23>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
ds1672: rtc@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
@@ -608,6 +757,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0xb0b1
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw5903.dtsi b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
index aee9221..e1bf19e 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
@@ -71,6 +71,53 @@
default-brightness-level = <100>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -183,11 +230,101 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- pca9555: gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_an1";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom1: eeprom@50 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw5904.dtsi b/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
index 76d6cf5..1535ef6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5904.dtsi
@@ -68,6 +68,53 @@
default-brightness-level = <7>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -205,11 +252,101 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- pca9555: gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_an1";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom1: eeprom@50 {
@@ -503,6 +640,7 @@
fsl,pins = <
MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x0001b0b0 /* GSC_IRQ# */
>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw5907.dtsi b/arch/arm/boot/dts/imx6qdl-gw5907.dtsi
index 0bdebdd..81853b5 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5907.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5907.dtsi
@@ -19,6 +19,53 @@
stdout-path = &uart2;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -102,11 +149,101 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_an1";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom@50 {
@@ -133,7 +270,7 @@
pagesize = <16>;
};
- rtc@68 {
+ ds1672@68 {
compatible = "dallas,ds1672";
reg = <0x68>;
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
index 0857de5..2f34623 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
@@ -22,6 +22,53 @@
reg = <0x10000000 0x20000000>;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -111,11 +158,121 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@6 {
+ gw,mode = <0>;
+ reg = <0x06>;
+ label = "temp";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@82 {
+ gw,mode = <2>;
+ reg = <0x82>;
+ label = "vdd_vin";
+ gw,voltage-divider-ohms = <22100 1000>;
+ gw,voltage-offset-microvolt = <800000>;
+ };
+
+ channel@84 {
+ gw,mode = <2>;
+ reg = <0x84>;
+ label = "vdd_5p0";
+ gw,voltage-divider-ohms = <22100 10000>;
+ };
+
+ channel@86 {
+ gw,mode = <2>;
+ reg = <0x86>;
+ label = "vdd_3p3";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@88 {
+ gw,mode = <2>;
+ reg = <0x88>;
+ label = "vdd_2p5";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@8c {
+ gw,mode = <2>;
+ reg = <0x8c>;
+ label = "vdd_3p0";
+ };
+
+ channel@8e {
+ gw,mode = <2>;
+ reg = <0x8e>;
+ label = "vdd_arm";
+ };
+
+ channel@90 {
+ gw,mode = <2>;
+ reg = <0x90>;
+ label = "vdd_soc";
+ };
+
+ channel@92 {
+ gw,mode = <2>;
+ reg = <0x92>;
+ label = "vdd_1p5";
+ };
+
+ channel@98 {
+ gw,mode = <2>;
+ reg = <0x98>;
+ label = "vdd_1p8";
+ };
+
+ channel@9a {
+ gw,mode = <2>;
+ reg = <0x9a>;
+ label = "vdd_1p0";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@9c {
+ gw,mode = <2>;
+ reg = <0x9c>;
+ label = "vdd_an1";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@a2 {
+ gw,mode = <2>;
+ reg = <0xa2>;
+ label = "vdd_gsc";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom@50 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw5912.dtsi b/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
index 8c57fd2..0e2dbc8 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5912.dtsi
@@ -20,6 +20,53 @@
stdout-path = &uart2;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -106,11 +153,108 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ gw,mode = <0>;
+ reg = <0x00>;
+ label = "temp";
+ };
+
+ channel@2 {
+ gw,mode = <1>;
+ reg = <0x02>;
+ label = "vdd_vin";
+ };
+
+ channel@5 {
+ gw,mode = <1>;
+ reg = <0x05>;
+ label = "vdd_3p3";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@b {
+ gw,mode = <1>;
+ reg = <0x0b>;
+ label = "vdd_5p0";
+ };
+
+ channel@e {
+ gw,mode = <1>;
+ reg = <0xe>;
+ label = "vdd_arm";
+ };
+
+ channel@11 {
+ gw,mode = <1>;
+ reg = <0x11>;
+ label = "vdd_soc";
+ };
+
+ channel@14 {
+ gw,mode = <1>;
+ reg = <0x14>;
+ label = "vdd_3p0";
+ };
+
+ channel@17 {
+ gw,mode = <1>;
+ reg = <0x17>;
+ label = "vdd_1p5";
+ };
+
+ channel@1d {
+ gw,mode = <1>;
+ reg = <0x1d>;
+ label = "vdd_1p8";
+ };
+
+ channel@20 {
+ gw,mode = <1>;
+ reg = <0x20>;
+ label = "vdd_1p0";
+ };
+
+ channel@23 {
+ gw,mode = <1>;
+ reg = <0x23>;
+ label = "vdd_2p5";
+ };
+ };
+
+ fan-controller@a {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "gw,gsc-fan";
+ reg = <0x0a>;
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom@50 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw5913.dtsi b/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
index 635c203..5fa79c9 100644
--- a/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw5913.dtsi
@@ -19,6 +19,53 @@
stdout-path = &uart2;
};
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user_pb {
+ label = "user_pb";
+ gpios = <&gsc_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <256>; /* BTN_0 */
+ };
+
+ user_pb1x {
+ label = "user_pb1x";
+ linux,code = <257>; /* BTN_1 */
+ interrupt-parent = <&gsc>;
+ interrupts = <0>;
+ };
+
+ key_erased {
+ label = "key-erased";
+ linux,code = <258>; /* BTN_2 */
+ interrupt-parent = <&gsc>;
+ interrupts = <1>;
+ };
+
+ eeprom_wp {
+ label = "eeprom_wp";
+ linux,code = <259>; /* BTN_3 */
+ interrupt-parent = <&gsc>;
+ interrupts = <2>;
+ };
+
+ tamper {
+ label = "tamper";
+ linux,code = <260>; /* BTN_4 */
+ interrupt-parent = <&gsc>;
+ interrupts = <5>;
+ };
+
+ switch_hold {
+ label = "switch_hold";
+ linux,code = <261>; /* BTN_5 */
+ interrupt-parent = <&gsc>;
+ interrupts = <7>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -87,11 +134,114 @@
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
- gpio@23 {
+ gsc: gsc@20 {
+ compatible = "gw,gsc";
+ reg = <0x20>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <4 GPIO_ACTIVE_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ #size-cells = <0>;
+
+ adc {
+ compatible = "gw,gsc-adc";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@6 {
+ gw,mode = <0>;
+ reg = <0x06>;
+ label = "temp";
+ };
+
+ channel@8 {
+ gw,mode = <1>;
+ reg = <0x08>;
+ label = "vdd_bat";
+ };
+
+ channel@82 {
+ gw,mode = <2>;
+ reg = <0x82>;
+ label = "vdd_vin";
+ gw,voltage-divider-ohms = <22100 1000>;
+ gw,voltage-offset-microvolt = <800000>;
+ };
+
+ channel@84 {
+ gw,mode = <2>;
+ reg = <0x84>;
+ label = "vdd_5p0";
+ gw,voltage-divider-ohms = <22100 10000>;
+ };
+
+ channel@86 {
+ gw,mode = <2>;
+ reg = <0x86>;
+ label = "vdd_3p3";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@88 {
+ gw,mode = <2>;
+ reg = <0x88>;
+ label = "vdd_2p5";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@8c {
+ gw,mode = <2>;
+ reg = <0x8c>;
+ label = "vdd_arm";
+ };
+
+ channel@8e {
+ gw,mode = <2>;
+ reg = <0x8e>;
+ label = "vdd_soc";
+ };
+
+ channel@90 {
+ gw,mode = <2>;
+ reg = <0x90>;
+ label = "vdd_1p5";
+ };
+
+ channel@92 {
+ gw,mode = <2>;
+ reg = <0x92>;
+ label = "vdd_1p0";
+ };
+
+ channel@98 {
+ gw,mode = <2>;
+ reg = <0x98>;
+ label = "vdd_3p0";
+ };
+
+ channel@9a {
+ gw,mode = <2>;
+ reg = <0x9a>;
+ label = "vdd_an1";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+
+ channel@a2 {
+ gw,mode = <2>;
+ reg = <0xa2>;
+ label = "vdd_gsc";
+ gw,voltage-divider-ohms = <10000 10000>;
+ };
+ };
+ };
+
+ gsc_gpio: pca9555@23 {
compatible = "nxp,pca9555";
reg = <0x23>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gsc>;
+ interrupts = <4>;
};
eeprom@50 {
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 04/15] PCI: brcmstb: Add compatibily of other chips
From: Nicolas Saenz Julienne @ 2020-05-20 14:41 UTC (permalink / raw)
To: Jim Quinlan
Cc: Rob Herring, Lorenzo Pieralisi,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, open list,
Florian Fainelli, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <CA+-6iNwE7CkD0r7Z0cKGXxE14Unf7ZGsr4q7Z8dPhgYYXHXHEg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2326 bytes --]
On Wed, 2020-05-20 at 10:30 -0400, Jim Quinlan wrote:
> On Wed, May 20, 2020 at 7:51 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
[...]
> > > +
> > > +static const struct pcie_cfg_data bcm7278_cfg = {
> > > + .reg_field_info = pcie_reg_field_info_bcm7278,
> > > + .offsets = pcie_offset_bcm7278,
> > > + .type = BCM7278,
> > > +};
> >
> > It's not essential, but if v2 is due I'd suggest factoring out the bcm2728
> > specific structures above, and moving them to patch #15. This will keep a
> > clearer division between the patch introducing the infrastructure and the
> > one
> > adding the support for a new device.
> The problem is that one of the commits needs the 7278 type so it has
> to be declared earlier.
Fair enough.
> > > +
> > > struct brcm_msi {
> > > struct device *dev;
> > > void __iomem *base;
> > > @@ -176,6 +238,9 @@ struct brcm_pcie {
> > > int gen;
> > > u64 msi_target_addr;
> > > struct brcm_msi *msi;
> > > + const int *reg_offsets;
> > > + const int *reg_field_info;
> > > + enum pcie_type type;
> > > };
> > >
> > > /*
> > > @@ -602,20 +667,21 @@ static struct pci_ops brcm_pcie_ops = {
> > >
> > > static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
> > > u32
> > > val)
> > > {
> > > - u32 tmp;
> > > + u32 tmp, mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
> > > + u32 shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
> >
> > I don't think you need shift here, IIUC u32p_replace_bits() will take care
> > of
> > all the masking and shifting internally, moreover, you'd be able to drop the
> > shift entry from reg_field_info.
> Got it.
> > > - tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
> > > - u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_INIT_MASK);
> > > - writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
> > > + tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
> > > + tmp = (tmp & ~mask) | ((val << shift) & mask);
> > > + writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
> > > }
> >
> > Regards,
> > Nicolas
> >
> Thanks!
> Jim
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data
From: Rob Herring @ 2020-05-20 14:43 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, Mikko Perttunen, open list:THERMAL, Viresh Kumar,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Jon Hunter,
Timo Alho, bbasu, Catalin Marinas, linux-tegra, Sumit Gupta,
Mikko Perttunen, Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200407100520.GA1720957@ulmo>
On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > On 04-12-19, 10:33, Thierry Reding wrote:
> > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > to the BPMP.
> > >
> > > That said, I'm wondering if perhaps we could just add a compatible
> > > string to the /cpus node for cases like this where we don't have an
> > > actual device representing the CPU complex. There are a number of CPU
> > > frequency drivers that register dummy devices just so that they have
> > > something to bind a driver to.
> > >
> > > If we allow the /cpus node to represent the CPU complex (if no other
> > > "device" does that yet), we can add a compatible string and have the
> > > cpufreq driver match on that.
> > >
> > > Of course this would be slightly difficult to retrofit into existing
> > > drivers because they'd need to remain backwards compatible with existing
> > > device trees. But it would allow future drivers to do this a little more
> > > elegantly. For some SoCs this may not matter, but especially once you
> > > start depending on additional resources this would come in handy.
> > >
> > > Adding Rob and the device tree mailing list for feedback on this idea.
> >
> > Took some time to find this thread, but something around this was
> > suggested by Rafael earlier.
> >
> > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
>
> I gave this a try and came up with the following:
>
> --- >8 ---
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index f4ede86e32b4..e4462f95f0b3 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> };
>
> cpus {
> + compatible = "nvidia,tegra194-ccplex";
> + nvidia,bpmp = <&bpmp>;
Is there more than 1 bpmp? If not you don't need this. Just lookup the
node by compatible.
> +
> #address-cells = <1>;
> #size-cells = <0>;
>
> --- >8 ---
>
> Now I can do something rougly like this, although I have a more complete
> patch locally that also gets rid of all the global variables because we
> now actually have a struct platform_device that we can anchor everything
> at:
>
> --- >8 ---
> static const struct of_device_id tegra194_cpufreq_of_match[] = {
> { .compatible = "nvidia,tegra194-ccplex", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
>
> static struct platform_driver tegra194_ccplex_driver = {
> .driver = {
> .name = "tegra194-cpufreq",
> .of_match_table = tegra194_cpufreq_of_match,
> },
> .probe = tegra194_cpufreq_probe,
> .remove = tegra194_cpufreq_remove,
> };
> module_platform_driver(tegra194_ccplex_driver);
> --- >8 ---
>
> I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> above thread seems to have mostly talked about binding a driver to each
> individual CPU.
>
> But this seems a lot better than having to instantiate a device from
> scratch just so that a driver can bind to it and it allows additional
> properties to be associated with the CCPLEX device.
What additional properties? A continual stream of properties added 1
by 1 would negatively affect my opinion of this.
> Rob, any thoughts on this from a device tree point of view? The /cpus
> bindings don't mention the compatible property, but there doesn't seem
> to be anything in the bindings that would prohibit its use.
What happens when you have more than one cpu related driver in
addition to cpufreq? You may still have to end up creating child
platform devices and then gained very little.
You could solve this without DT changes. You can bind on node names.
The driver probe can then check the parent compatible and return if
not matching. I'm not sure if you could get module auto loading to
work in that case. It would have to be based on the root compatible
(rather than the driver match table) and be able to load multiple
matching modules.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/12] Add cpufreq and cci devfreq for mt8183, and SVS support
From: Matthias Brugger @ 2020-05-20 14:53 UTC (permalink / raw)
To: andrew-sh.cheng, Chanwoo Choi
Cc: Mark Rutland, Nishanth Menon, srv_heupstream, linux-pm,
Stephen Boyd, Viresh Kumar, Mark Brown, Rafael J . Wysocki,
Liam Girdwood, Rob Herring, linux-kernel, Kyungmin Park,
MyungJoo Ham, linux-mediatek, linux-arm-kernel, devicetree
In-Reply-To: <1589958625.23971.2.camel@mtksdaap41>
On 20/05/2020 09:10, andrew-sh.cheng wrote:
> On Wed, 2020-05-20 at 15:24 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> On 5/20/20 2:36 PM, andrew-sh.cheng wrote:
>>> On Wed, 2020-05-20 at 13:10 +0900, Chanwoo Choi wrote:
>>>> Hi Andrew,
>>>>
>>>> Could you explain the base commit of these patches?
>>>> When I tried to apply them to v5.7-rc1 for testing,
>>>> the merge conflict occurs.
>>>>
>>>> Thanks,
>>
>>>> Chanwoo Choi
>>>
>>> Hi Chanwoo Choi,
>>>
>>> My base commit is
>>> commit 8f3d9f354286745c751374f5f1fcafee6b3f3136
>>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>>> Date: Sun Apr 12 12:35:55 2020 -0700
>>>
>>> Linux 5.7-rc1
>>>
>>> Could you show me the conflict error?
>>
>>
>> When I tried to apply first patch with 'git am',
>> the merge conflict occurred.
>>
>> git am \[PATCH\ 01_12\]\ OPP\:\ Allow\ required-opps\ even\ if\ the\ device\ doesn\'t\ have\ power-domains.eml
>> Applying: OPP: Allow required-opps even if the device doesn't have power-domains
>> error: patch failed: drivers/opp/core.c:755
>> error: drivers/opp/core.c: patch does not apply
>> error: patch failed: drivers/opp/of.c:195
>> error: drivers/opp/of.c: patch does not apply
>> Patch failed at 0001 OPP: Allow required-opps even if the device doesn't have power-domains
>> Use 'git am --show-current-patch' to see the failed patch
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>>
>> Regards,
>> Chanwoo Choi
>
> Hi Chanwoo,
>
> I just make a new folder to get code and check.
> Below is my command list.
> Please help check the different with you.
> 505 repo init -u http://gerrit.mediatek.inc:8080/cros-kernel/manifest
> -b upstream
> 506 repo sync -j8
> 507 repo start kern-dev --all
> 508 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 509 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 510 ls
> 511 cd kernel/mediatek/
> 512 git remote add main
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 513 git fetch main
> 514 git checkout v5.7-rc1
> 515 git am
> Add-cpufreq-and-cci-devfreq-for-mt8183-and-SVS-support.patch
> 516 history
>
For reference I just tried with b4.sh [1]:
# b4.sh am -l -o /tmp -n patch 1589958625.23971.2.camel@mtksdaap41
# git am -3 -s /tmp/patch.mbx
Applies without conflicts.
Regards,
Matthias
[1] https://git.kernel.org/pub/scm/utils/b4/b4.git
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/12] OPP: Allow required-opps even if the device doesn't have power-domains
From: Matthias Brugger @ 2020-05-20 14:54 UTC (permalink / raw)
To: Andrew-sh.Cheng, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Rob Herring, Mark Rutland, Rafael J . Wysocki, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mark Brown
Cc: devicetree, Saravana Kannan, srv_heupstream, linux-pm,
linux-kernel, linux-mediatek, linux-arm-kernel
In-Reply-To: <20200520034307.20435-2-andrew-sh.cheng@mediatek.com>
On 20/05/2020 05:42, Andrew-sh.Cheng wrote:
> From: Saravana Kannan <saravanak@google.com>
>
> A Device-A can have a (minimum) performance requirement on another
> Device-B to be able to function correctly. This performance requirement
> on Device-B can also change based on the current performance level of
> Device-A.
>
> The existing required-opps feature fits well to describe this need. So,
> instead of limiting required-opps to point to only PM-domain devices,
> allow it to point to any device.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Please check all patches, they are missing your
Signed-off-by
Regards,
Matthias
> ---
> drivers/opp/core.c | 2 +-
> drivers/opp/of.c | 11 -----------
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index ba43e6a3dc0a..51403c1f2481 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -755,7 +755,7 @@ static int _set_required_opps(struct device *dev,
> return 0;
>
> /* Single genpd case */
> - if (!genpd_virt_devs) {
> + if (!genpd_virt_devs && required_opp_tables[0]->is_genpd) {
> pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
> ret = dev_pm_genpd_set_performance_state(dev, pstate);
> if (ret) {
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 9cd8f0adacae..6d33de668a7b 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -195,17 +195,6 @@ static void _opp_table_alloc_required_tables(struct opp_table *opp_table,
>
> if (IS_ERR(required_opp_tables[i]))
> goto free_required_tables;
> -
> - /*
> - * We only support genpd's OPPs in the "required-opps" for now,
> - * as we don't know how much about other cases. Error out if the
> - * required OPP doesn't belong to a genpd.
> - */
> - if (!required_opp_tables[i]->is_genpd) {
> - dev_err(dev, "required-opp doesn't belong to genpd: %pOF\n",
> - required_np);
> - goto free_required_tables;
> - }
> }
>
> goto put_np;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1] usb: musb: dsps: set MUSB_DA8XX quirk for AM335x
From: Bin Liu @ 2020-05-20 14:55 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Michael Grzeschik, fercerpav, Greg Kroah-Hartman, linux-usb,
linux-kernel, russell, Pengutronix Kernel Team, linux-arm-kernel
In-Reply-To: <20200520044934.hyngdg774ibqai46@pengutronix.de>
On Wed, May 20, 2020 at 06:49:34AM +0200, Oleksij Rempel wrote:
> On Tue, May 19, 2020 at 05:18:51PM -0500, Bin Liu wrote:
> > Hi,
> >
> > On Fri, Mar 27, 2020 at 06:38:49AM +0100, Oleksij Rempel wrote:
> > > Beagle Bone Black has different memory corruptions if kernel is
> > > configured with USB_TI_CPPI41_DMA=y. This issue is reproducible with
> > > ath9k-htc driver (ar9271 based wifi usb controller):
> > >
> > > root@AccessBox:~ iw dev wlan0 set monitor fcsfail otherbss
> > > root@AccessBox:~ ip l s dev wlan0 up
> > > kmemleak: Cannot insert 0xda577e40 into the object search tree (overlaps existing)
> > > CPU: 0 PID: 176 Comm: ip Not tainted 5.5.0 #7
> > > Hardware name: Generic AM33XX (Flattened Device Tree)
> > > [<c0112c14>] (unwind_backtrace) from [<c010dc98>] (show_stack+0x18/0x1c)
> > > [<c010dc98>] (show_stack) from [<c08c7c2c>] (dump_stack+0x84/0x98)
> > > [<c08c7c2c>] (dump_stack) from [<c02c75a8>] (create_object+0x2f8/0x324)
> > > [<c02c75a8>] (create_object) from [<c02b8928>] (kmem_cache_alloc+0x1a8/0x39c)
> > > [<c02b8928>] (kmem_cache_alloc) from [<c072fb68>] (__alloc_skb+0x60/0x174)
> > > [<c072fb68>] (__alloc_skb) from [<bf0c5c58>] (ath9k_wmi_cmd+0x50/0x184 [ath9k_htc])
> > > [<bf0c5c58>] (ath9k_wmi_cmd [ath9k_htc]) from [<bf0cb410>] (ath9k_regwrite_multi+0x54/0x84 [ath9k_htc])
> > > [<bf0cb410>] (ath9k_regwrite_multi [ath9k_htc]) from [<bf0cb7fc>] (ath9k_regwrite+0xf0/0xfc [ath9k_htc])
> > > [<bf0cb7fc>] (ath9k_regwrite [ath9k_htc]) from [<bf1aca78>] (ar5008_hw_process_ini+0x280/0x6c0 [ath9k_hw])
> > > [<bf1aca78>] (ar5008_hw_process_ini [ath9k_hw]) from [<bf1a66ac>] (ath9k_hw_reset+0x270/0x1458 [ath9k_hw])
> > > [<bf1a66ac>] (ath9k_hw_reset [ath9k_hw]) from [<bf0c9588>] (ath9k_htc_start+0xb0/0x22c [ath9k_htc])
> > > [<bf0c9588>] (ath9k_htc_start [ath9k_htc]) from [<bf0eb3c0>] (drv_start+0x4c/0x1e8 [mac80211])
> > > [<bf0eb3c0>] (drv_start [mac80211]) from [<bf104a84>] (ieee80211_do_open+0x480/0x954 [mac80211])
> > > [<bf104a84>] (ieee80211_do_open [mac80211]) from [<c075127c>] (__dev_open+0xdc/0x160)
> > > [<c075127c>] (__dev_open) from [<c07516a8>] (__dev_change_flags+0x1a4/0x204)
> > > [<c07516a8>] (__dev_change_flags) from [<c0751728>] (dev_change_flags+0x20/0x50)
> > > [<c0751728>] (dev_change_flags) from [<c076971c>] (do_setlink+0x2ac/0x978)
> > >
> > > After applying this patch, the system is running in monitor mode without
> > > noticeable issues.
> > >
> > > Suggested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > > ---
> > > drivers/usb/musb/musb_dsps.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> > > index 88923175f71e..c01f9e9e69f5 100644
> > > --- a/drivers/usb/musb/musb_dsps.c
> > > +++ b/drivers/usb/musb/musb_dsps.c
> > > @@ -690,7 +690,7 @@ static void dsps_dma_controller_resume(struct dsps_glue *glue) {}
> > > #endif /* CONFIG_USB_TI_CPPI41_DMA */
> > >
> > > static struct musb_platform_ops dsps_ops = {
> > > - .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
> > > + .quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP | MUSB_DA8XX,
> >
> > The MUSB_DA8XX flag cannot be simply applied to MUSB_DSPS, at least the
> > teardown and autoreq register offsets are different as show in
> > cppi41_dma_controller_create().
>
> ok
>
> > Do you understand what exactly caused the issue?
>
> No.
>
> Disabling DMA support "solve" this issue as well.
>
> Beside, with DMA support, there remains one more crash with different symptoms.
> I can workaround it by disabling CPU Freq governor, or setting it to performance.
>
> > The kernel trace above doesn't provide enuough information.
>
> Do you have any suggestions how to instrument the kernel to get needed
> information? Or, should I try to capture USB traffic before the crash?
First can you please try the following patch instead?
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 7fbb8a307145..26c996f8b2bd 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -614,7 +614,6 @@ static int cppi41_dma_channel_abort(struct dma_channel *channel)
}
/* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
- if (musb->ops->quirks & MUSB_DA8XX)
mdelay(250);
tdbit = 1 << cppi41_channel->port_num;
>
> If it helps, ath9k_htc is a usb wifi adapter. It generates a lot of
> USB traffic on multiple endpoints. Bulk with data packets and Interrupt
> with register accesses, LED blinking... etc.
Do you have a link to the picture or description of the adapter? I'd like
to see if I can buy the same to take a look.
-Bin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/4] counter: Add character device interface
From: kbuild test robot @ 2020-05-20 15:07 UTC (permalink / raw)
To: William Breathitt Gray, jic23
Cc: kamel.bouhara, gwendal, kbuild-all, david, linux-iio,
alexandre.belloni, linux-kernel, clang-built-linux, syednwaris,
linux-stm32, linux-arm-kernel
In-Reply-To: <a722cbc1e59441cd477bf42fd0313eb7abd76e38.1589654470.git.vilhelm.gray@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.7-rc6 next-20200519]
[cannot apply to stm32/stm32-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-character-device-interface/20200517-032530
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 12bf0b632ed090358cbf03e323e5342212d0b2e4
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 135b877874fae96b4372c8a3fbfaa8ff44ff86e3)
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/counter/counter-chrdev.c:632:5: warning: no previous prototype for function 'counter_chrdev_add' [-Wmissing-prototypes]
int counter_chrdev_add(struct counter_device *const counter,
^
drivers/counter/counter-chrdev.c:632:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int counter_chrdev_add(struct counter_device *const counter,
^
static
>> drivers/counter/counter-chrdev.c:652:6: warning: no previous prototype for function 'counter_chrdev_free' [-Wmissing-prototypes]
void counter_chrdev_free(struct counter_device *const counter)
^
drivers/counter/counter-chrdev.c:652:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void counter_chrdev_free(struct counter_device *const counter)
^
static
2 warnings generated.
vim +/counter_chrdev_add +632 drivers/counter/counter-chrdev.c
631
> 632 int counter_chrdev_add(struct counter_device *const counter,
633 const dev_t counter_devt)
634 {
635 struct device *const dev = &counter->dev;
636 struct cdev *const chrdev = &counter->chrdev;
637
638 /* Initialize Counter character device control selection */
639 memset(counter->selection, 0, sizeof(counter->selection));
640
641 /* Initialize Counter character device selected controls list */
642 INIT_LIST_HEAD(&counter->control_list);
643
644 /* Initialize character device */
645 cdev_init(chrdev, &counter_fops);
646 dev->devt = MKDEV(MAJOR(counter_devt), counter->id);
647 cdev_set_parent(chrdev, &dev->kobj);
648
649 return cdev_add(chrdev, dev->devt, 1);
650 }
651
> 652 void counter_chrdev_free(struct counter_device *const counter)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38774 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Rob Herring @ 2020-05-20 15:10 UTC (permalink / raw)
To: Joakim Zhang
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, will@kernel.org,
john.garry@huawei.com, linux-kernel@vger.kernel.org, dl-linux-imx,
shawnguo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB8PR04MB6795A3C57F2B02632D591183E6B60@DB8PR04MB6795.eurprd04.prod.outlook.com>
On Tue, May 19, 2020 at 8:56 PM Joakim Zhang <qiangqing.zhang@nxp.com> wrote:
>
>
> > -----Original Message-----
> > From: Rob Herring <robh@kernel.org>
> > Sent: 2020年5月20日 2:51
> > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > Cc: john.garry@huawei.com; will@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier
> > for userspace
> >
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > The DDR Perf for i.MX8 is a system PMU whose axi id would different
> > > from SoC to SoC. Need expose system PMU identifier for userspace which
> > > refer to /sys/bus/event_source/devices/<PMU DEVICE>/identifier.
> >
> > Why not just expose the AXI ID if that's what's different?
>
> Hi Rob,
>
> Each master has their own AXI ID, such as USB, GPU, VPU etc, it is various from different SoCs. We want to add system PMU support in perf tool, so we want to expose something from perf driver to identify each SoC.
> When we know which SoC it is, we can get each master AXI ID. If this patch can be accepted, /sys/bus/event_source/devices/<PMU DEVICE>/identifier could be a common interface for all system PMUs.
>
> I will change to add a property to identify SoC, to see if it is better. Thanks.
Isn't that what you have already with this patch? My point is you can
already read /proc/device-tree/compatible, read the PMU compatible, or
have an SoC device which exposes SoC info.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 0/3] ARM: imx: move cpu code to drivers/soc/imx
From: Shawn Guo @ 2020-05-20 15:11 UTC (permalink / raw)
To: peng.fan
Cc: linux-arm-kernel, abel.vesa, Anson.Huang, andrew.smirnov,
festevam, s.hauer, linux-kernel, linux-imx, kernel, git,
leonard.crestez, info, cphealy, allison
In-Reply-To: <1589953889-30955-1-git-send-email-peng.fan@nxp.com>
On Wed, May 20, 2020 at 01:51:26PM +0800, peng.fan@nxp.com wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> V3:
> Rebased to latest next tree
> Resolved the conflicts with vf610 soc patch
>
> V2:
> Keep i.MX1/2/3/5 cpu type for completness
> Correct return value in patch 1/3
> use CONFIG_ARM to guard compile soc-imx.c in patch 3/3
>
> V1:
> https://patchwork.kernel.org/cover/11433689/
> RFC version :
> https://patchwork.kernel.org/cover/11336433/
>
> Nothing changed in v1, just rename to formal patches
>
> Shawn,
> The original concern has been eliminated in RFC discussion,
> so this patchset is ready to be in next.
> Thanks.
>
> Follow i.MX8, move the soc device register code to drivers/soc/imx
> to simplify arch/arm/mach-imx/cpu.c
>
> I planned to use similar logic as soc-imx8m.c to restructure soc-imx.c
> and merged the two files into one. But not sure, so still keep
> the logic in cpu.c.
>
> There is one change is the platform devices are not under
> /sys/devices/soc0 after patch 1/4. Actually ARM64 platform
> devices are not under /sys/devices/soc0, such as i.MX8/8M.
> So it should not hurt to let the platform devices under platform dir.
>
> Peng Fan (3):
> ARM: imx: use device_initcall for imx_soc_device_init
> ARM: imx: move cpu definitions into a header
> soc: imx: move cpu code to drivers/soc/imx
Applied all, thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2
From: Jordan Crouse @ 2020-05-20 15:13 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-msm, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Rob Clark, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200520125700.GD25815@willie-the-truck>
On Wed, May 20, 2020 at 01:57:01PM +0100, Will Deacon wrote:
> On Mon, May 18, 2020 at 08:50:27AM -0700, Rob Clark wrote:
> > On Mon, May 18, 2020 at 8:18 AM Will Deacon <will@kernel.org> wrote:
> > > On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> > > > We do in fact need live domain switching, that is really the whole
> > > > point. The GPU CP (command processor/parser) is directly updating
> > > > TTBR0 and triggering TLB flush, asynchronously from the CPU.
> > > >
> > > > And I think the answer about ASID is easy (on current hw).. it must be zero[*].
> > >
> > > Using ASID zero is really bad, because it means that you will end up sharing
> > > TLB entries with whichever device is using context bank 0.
> > >
> > > Is the SMMU only used by the GPU in your SoC?
> > >
> >
> > yes, the snapdragon SoCs have two SMMU instances, one used by the GPU,
> > where ASID0/cb0 is the gpu itself, and another cb is the GMU
> > (basically power control for the gpu), and the second SMMU is
> > everything else.
>
> Right, in which case I'm starting to think that we should treat this GPU
> SMMU instance specially. Give it its own compatible string (looks like you
> need this for HUPCFG anyway) and hook in via arm_smmu_impl_init(). You can
> then set IO_PGTABLE_QUIRK_ARM_TTBR1 when talking to the io-pgtable code
> without having to add a domain attribute.
If we did this via a special GPU SMMU instance then we could also create and
register a dummy TTBR0 instance along with the TTBR1 instance and then we
wouldn't need to worry about the aux domains at all.
> With that. you'll need to find a way to allow the GPU driver to call into
> your own hooks for getting at the TTBR0 tables -- given that you're
> programming these in the hardware, I don't think it makes sense to expose
> that in the IOMMU API, since most devices won't be able to do anything with
> that data. Perhaps you could install a couple of function pointers
> (subdomain_alloc/subdomain_free) in the GPU device when you see it appear
> from the SMMU driver? Alternatively, you could make an io_pgtable_cfg
> available so that the GPU driver can interface with io-pgtable directly.
I don't want to speak for Rob but I think that this is the same direction we've
landed on. If we use the implementation specific code to initialize the base
pagetables then the GPU driver can use io-pgtable directly. We can easily
construct an io_pgtable_cfg. This feature will only be available for opt-in
GPU targets that will have a known configuration.
The only gotcha is TLB maintenance but Rob and I have ideas about coordinating
with the GPU hardware (which has to do a TLBIALL during a switch anyway) and we
can always use the iommu_tlb_flush_all() hammer from software if we really need
it. It might take a bit of thought, but it is doable.
> Yes, it's ugly, but I don't think it's worth trying to abstract this.
I'm not sure how ugly it is. I've always operated under the assumption that the
GPU SMMU was special (though it had generic registers) just because of where it
was and how it it was used. In the long run baking in a implementation specific
solution would probably be preferable to lots of domain attributes and aux
domains that would never be used except by us.
> Thoughts? It's taken me a long time to figure out what's going on here,
> so sorry if it feels like I'm leading you round the houses.
I'll hack on this and try to get something in place. It might be dumber on the
GPU side than we would like but it would at least spur some more conversation.
Jordan
> Will
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox