* [PATCH/RFT 2/2] arm64: dts: renesas: r8a77965: Add PCIe device nodes
From: Simon Horman @ 2018-06-11 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528373494-18503-3-git-send-email-ykaneko0929@gmail.com>
On Thu, Jun 07, 2018 at 09:11:34PM +0900, Yoshihiro Kaneko wrote:
> From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
>
> This patch adds PCIe{0,1} device nodes to R8A77965 SoC.
>
> Based on a similar patches of the R8A7796 device tree
> by Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>.
>
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Hi,
This looks fine to me but I will wait to see if there are other reviews
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v7 2/2] ARM: dts: imx: Add basic dts support for imx6sll EVK board
From: Shawn Guo @ 2018-06-11 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527234127-11991-2-git-send-email-ping.bai@nxp.com>
On Fri, May 25, 2018 at 03:42:07PM +0800, Bai Ping wrote:
> Add dts file support for imx6sll EVK board.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Dong Aisheng <Aisheng.dong@nxp.com>
> ---
> change v3->v4
> - update the license indentifier
> - remove leading zero of node
> - remove unused pin from hog group
> change v4->v5
> - use generic name for device node
> - remove unnecessary hog pin group
> change v5->v6
> - no
> change v6->v7
> - move the iomuxc node to the end of dts file
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 4 +
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx6sll-evk.dts | 317 ++++++++++++++++++++++++++
> 3 files changed, 323 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6sll-evk.dts
<snip>
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX6SLL_PAD_I2C1_SCL__I2C1_SCL 0x4001b8b1
> + MX6SLL_PAD_I2C1_SDA__I2C1_SDA 0x4001b8b1
> + >;
> + };
> +};
> +
> +
The new blank line at EOF should be dropped.
I fixed it up and applied both patches.
Shawn
^ permalink raw reply
* [PATCH/RFT 1/2] PCI: rcar: Add compatible string for r8a77965
From: Simon Horman @ 2018-06-11 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528373494-18503-2-git-send-email-ykaneko0929@gmail.com>
On Thu, Jun 07, 2018 at 09:11:33PM +0900, Yoshihiro Kaneko wrote:
> This patch adds support for r8a77965 (R-Car M3-N)
>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index 1fb614e..dd71cfe 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -8,6 +8,7 @@ compatible: "renesas,pcie-r8a7743" for the R8A7743 SoC;
> "renesas,pcie-r8a7793" for the R8A7793 SoC;
> "renesas,pcie-r8a7795" for the R8A7795 SoC;
> "renesas,pcie-r8a7796" for the R8A7796 SoC;
> + "renesas,pcie-r8a77965" for the R8A77965 SoC;
> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 or
> RZ/G1 compatible device.
> "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v1] ARM: imx: add imx7d-m4
From: Shawn Guo @ 2018-06-11 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93e7b7ef-1bc0-2871-da2c-65ab3f070c07@pengutronix.de>
On Mon, Jun 11, 2018 at 10:02:53AM +0200, Oleksij Rempel wrote:
> Hi all,
>
> this patch was send 05.04.2018. Any comments?
>
> @Shawn, can you please take it?
Honestly I'm not sure how useful it will be. If we can have some i.MX
developers ACK on it, I will be more comfortable to take it.
Shawn
>
> On 05.04.2018 13:51, Oleksij Rempel wrote:
> > Provide basic support for Cortex-M4 located on NXP iMX7D.
> > This code was tested in combination with imx-rproc driver
> > which will upload with specially formatted ELF image containing
> > kernel, device and CPIO rootfs.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> > ---
> > arch/arm/boot/dts/Makefile | 2 +-
> > arch/arm/mach-imx/Kconfig | 33 +++++++++++++++++++++------------
> > arch/arm/mach-imx/Makefile | 3 ++-
> > arch/arm/mach-imx/mach-imx7d-cm4.c | 21 +++++++++++++++++++++
> > 4 files changed, 45 insertions(+), 14 deletions(-)
> > create mode 100644 arch/arm/mach-imx/mach-imx7d-cm4.c
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 852452515bea..d49bb9a58aee 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -527,7 +527,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> > imx6ul-tx6ul-0011.dtb \
> > imx6ul-tx6ul-mainboard.dtb \
> > imx6ull-14x14-evk.dtb
> > -dtb-$(CONFIG_SOC_IMX7D) += \
> > +dtb-$(CONFIG_SOC_IMX7D_CA7) += \
> > imx7d-cl-som-imx7.dtb \
> > imx7d-colibri-emmc-eval-v3.dtb \
> > imx7d-colibri-eval-v3.dtb \
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 782699e67600..101c8599d952 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -528,18 +528,6 @@ config SOC_IMX6UL
> > help
> > This enables support for Freescale i.MX6 UltraLite processor.
> >
> > -config SOC_IMX7D
> > - bool "i.MX7 Dual support"
> > - select PINCTRL_IMX7D
> > - select ARM_GIC
> > - select HAVE_ARM_ARCH_TIMER
> > - select HAVE_IMX_ANATOP
> > - select HAVE_IMX_MMDC
> > - select HAVE_IMX_SRC
> > - select IMX_GPCV2
> > - help
> > - This enables support for Freescale i.MX7 Dual processor.
> > -
> > config SOC_LS1021A
> > bool "Freescale LS1021A support"
> > select ARM_GIC
> > @@ -554,6 +542,27 @@ comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
> >
> > if ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
> >
> > +config SOC_IMX7D_CA7
> > + bool
> > + select ARM_GIC
> > + select HAVE_ARM_ARCH_TIMER
> > + select HAVE_IMX_ANATOP
> > + select HAVE_IMX_MMDC
> > + select HAVE_IMX_SRC
> > + select IMX_GPCV2
> > +
> > +config SOC_IMX7D_CM4
> > + bool
> > + select ARMV7M_SYSTICK
> > +
> > +config SOC_IMX7D
> > + bool "i.MX7 Dual support"
> > + select PINCTRL_IMX7D
> > + select SOC_IMX7D_CA7 if ARCH_MULTI_V7
> > + select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M
> > + help
> > + This enables support for Freescale i.MX7 Dual processor.
> > +
> > config SOC_VF610
> > bool "Vybrid Family VF610 support"
> > select ARM_GIC if ARCH_MULTI_V7
> > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> > index 8ff71058207d..68640f100ef3 100644
> > --- a/arch/arm/mach-imx/Makefile
> > +++ b/arch/arm/mach-imx/Makefile
> > @@ -80,7 +80,8 @@ obj-$(CONFIG_SOC_IMX6Q) += mach-imx6q.o
> > obj-$(CONFIG_SOC_IMX6SL) += mach-imx6sl.o
> > obj-$(CONFIG_SOC_IMX6SX) += mach-imx6sx.o
> > obj-$(CONFIG_SOC_IMX6UL) += mach-imx6ul.o
> > -obj-$(CONFIG_SOC_IMX7D) += mach-imx7d.o
> > +obj-$(CONFIG_SOC_IMX7D_CA7) += mach-imx7d.o
> > +obj-$(CONFIG_SOC_IMX7D_CM4) += mach-imx7d-cm4.o
> >
> > ifeq ($(CONFIG_SUSPEND),y)
> > AFLAGS_suspend-imx6.o :=-Wa,-march=armv7-a
> > diff --git a/arch/arm/mach-imx/mach-imx7d-cm4.c b/arch/arm/mach-imx/mach-imx7d-cm4.c
> > new file mode 100644
> > index 000000000000..c36dea79aeb8
> > --- /dev/null
> > +++ b/arch/arm/mach-imx/mach-imx7d-cm4.c
> > @@ -0,0 +1,21 @@
> > +/*
> > + * Copyright 2017 Pengutronix
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <asm/v7m.h>
> > +#include <asm/mach/arch.h>
> > +
> > +static const char * const imx7d_cm4_dt_compat[] __initconst = {
> > + "fsl,imx7d-cm4",
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(IMX7D, "Freescale i.MX7 Dual Cortex-M4 (Device Tree)")
> > + .dt_compat = imx7d_cm4_dt_compat,
> > + .restart = armv7m_restart,
> > +MACHINE_END
> >
>
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Simon Horman @ 2018-06-11 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4069170.tduNOXLj45@avalon>
On Fri, Jun 08, 2018 at 05:27:19PM +0300, Laurent Pinchart wrote:
> Hi Sergei,
>
> On Thursday, 7 June 2018 23:17:03 EEST Sergei Shtylyov wrote:
> > Hello!
> >
> > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
> > 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
> > DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
> > connected to the LVDS output. These patches depend on the Thine THC63LVD1024
> > driver and the R8A77980 LVDS support patch in order to work, and R8A77980
> > GPIO DT patches in order to apply/compile...
> >
> > [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
> > [2/5] arm64: dts: renesas: r8a77980: add VSPD support
> > [3/5] arm64: dts: renesas: r8a77980: add DU support
> > [4/5] arm64: dts: renesas: r8a77980: add LVDS support
>
> Based on the recent request of the ARM SoC maintainers to avoid a plethora of
> small patches, I think you can squash 1/5 to 4/5 all together.
Agreed.
Seregi could you please post a v2 with patches 1 - 4 squashed and the
register range for VSPD0 reduced to 0x5000? Thanks!
> > [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
^ permalink raw reply
* [PATCH v1] ARM: imx: add imx7d-m4
From: Oleksij Rempel @ 2018-06-11 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180405115134.8036-1-o.rempel@pengutronix.de>
Hi all,
this patch was send 05.04.2018. Any comments?
@Shawn, can you please take it?
On 05.04.2018 13:51, Oleksij Rempel wrote:
> Provide basic support for Cortex-M4 located on NXP iMX7D.
> This code was tested in combination with imx-rproc driver
> which will upload with specially formatted ELF image containing
> kernel, device and CPIO rootfs.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> arch/arm/boot/dts/Makefile | 2 +-
> arch/arm/mach-imx/Kconfig | 33 +++++++++++++++++++++------------
> arch/arm/mach-imx/Makefile | 3 ++-
> arch/arm/mach-imx/mach-imx7d-cm4.c | 21 +++++++++++++++++++++
> 4 files changed, 45 insertions(+), 14 deletions(-)
> create mode 100644 arch/arm/mach-imx/mach-imx7d-cm4.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 852452515bea..d49bb9a58aee 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -527,7 +527,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
> imx6ul-tx6ul-0011.dtb \
> imx6ul-tx6ul-mainboard.dtb \
> imx6ull-14x14-evk.dtb
> -dtb-$(CONFIG_SOC_IMX7D) += \
> +dtb-$(CONFIG_SOC_IMX7D_CA7) += \
> imx7d-cl-som-imx7.dtb \
> imx7d-colibri-emmc-eval-v3.dtb \
> imx7d-colibri-eval-v3.dtb \
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 782699e67600..101c8599d952 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -528,18 +528,6 @@ config SOC_IMX6UL
> help
> This enables support for Freescale i.MX6 UltraLite processor.
>
> -config SOC_IMX7D
> - bool "i.MX7 Dual support"
> - select PINCTRL_IMX7D
> - select ARM_GIC
> - select HAVE_ARM_ARCH_TIMER
> - select HAVE_IMX_ANATOP
> - select HAVE_IMX_MMDC
> - select HAVE_IMX_SRC
> - select IMX_GPCV2
> - help
> - This enables support for Freescale i.MX7 Dual processor.
> -
> config SOC_LS1021A
> bool "Freescale LS1021A support"
> select ARM_GIC
> @@ -554,6 +542,27 @@ comment "Cortex-A/Cortex-M asymmetric multiprocessing platforms"
>
> if ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M
>
> +config SOC_IMX7D_CA7
> + bool
> + select ARM_GIC
> + select HAVE_ARM_ARCH_TIMER
> + select HAVE_IMX_ANATOP
> + select HAVE_IMX_MMDC
> + select HAVE_IMX_SRC
> + select IMX_GPCV2
> +
> +config SOC_IMX7D_CM4
> + bool
> + select ARMV7M_SYSTICK
> +
> +config SOC_IMX7D
> + bool "i.MX7 Dual support"
> + select PINCTRL_IMX7D
> + select SOC_IMX7D_CA7 if ARCH_MULTI_V7
> + select SOC_IMX7D_CM4 if ARM_SINGLE_ARMV7M
> + help
> + This enables support for Freescale i.MX7 Dual processor.
> +
> config SOC_VF610
> bool "Vybrid Family VF610 support"
> select ARM_GIC if ARCH_MULTI_V7
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 8ff71058207d..68640f100ef3 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -80,7 +80,8 @@ obj-$(CONFIG_SOC_IMX6Q) += mach-imx6q.o
> obj-$(CONFIG_SOC_IMX6SL) += mach-imx6sl.o
> obj-$(CONFIG_SOC_IMX6SX) += mach-imx6sx.o
> obj-$(CONFIG_SOC_IMX6UL) += mach-imx6ul.o
> -obj-$(CONFIG_SOC_IMX7D) += mach-imx7d.o
> +obj-$(CONFIG_SOC_IMX7D_CA7) += mach-imx7d.o
> +obj-$(CONFIG_SOC_IMX7D_CM4) += mach-imx7d-cm4.o
>
> ifeq ($(CONFIG_SUSPEND),y)
> AFLAGS_suspend-imx6.o :=-Wa,-march=armv7-a
> diff --git a/arch/arm/mach-imx/mach-imx7d-cm4.c b/arch/arm/mach-imx/mach-imx7d-cm4.c
> new file mode 100644
> index 000000000000..c36dea79aeb8
> --- /dev/null
> +++ b/arch/arm/mach-imx/mach-imx7d-cm4.c
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright 2017 Pengutronix
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <asm/v7m.h>
> +#include <asm/mach/arch.h>
> +
> +static const char * const imx7d_cm4_dt_compat[] __initconst = {
> + "fsl,imx7d-cm4",
> + NULL,
> +};
> +
> +DT_MACHINE_START(IMX7D, "Freescale i.MX7 Dual Cortex-M4 (Device Tree)")
> + .dt_compat = imx7d_cm4_dt_compat,
> + .restart = armv7m_restart,
> +MACHINE_END
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180611/6e28fea3/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: am437x: make edt-ft5x06 a wakeup source for imx6 boards
From: Tony Lindgren @ 2018-06-11 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611074420.GF16091@dragon>
* Shawn Guo <shawnguo@kernel.org> [180611 07:47]:
> On Wed, May 23, 2018 at 10:30:13AM +0200, Daniel Mack wrote:
> > The touchscreen driver no longer configures the device as wakeup source by
> > default. A "wakeup-source" property is needed.
> >
> > Signed-off-by: Daniel Mack <daniel@zonque.org>
>
> This is not an imx6 board, and I have to leave it to relevant platform
> maintainer. The patch subject should be fixed to drop 'imx6'.
Daniel, can you please resend after -rc1?
Thanks,
Tony
^ permalink raw reply
* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Geert Uytterhoeven @ 2018-06-11 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611051340.9024-1-m.szyprowski@samsung.com>
Hi Marek,
Thanks for your patch!
On Mon, Jun 11, 2018 at 7:14 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
> they should be cleared on allocation. In case of IOMMU-based dma-mapping
> implementation such buffer clearing was missing in the code path for
> DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
Is it? The memory is allocated using dma_alloc_from_contiguous(..., gfp),
and __iommu_alloc_attrs() has
/*
* Some drivers rely on this, and we probably don't want the
* possibility of stale kernel data being read by devices anyway.
*/
gfp |= __GFP_ZERO;
at the top, before the allocation.
If cma_alloc() (called from dma_alloc_from_contiguous()) doesn't honor
__GFP_ZERO, I think cma_alloc() should be fixed instead.
> more information on clearing buffers allocated by dma_alloc_* functions,
> see commit 44176bb38fa4 ("arm64: dma-mapping: always clear allocated
6829e274a623
> buffers").
>
> Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-11 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASgetmPKKS8AhYXqSSEFCi+q0ASZ68M0SECJT5EbAU4XQ@mail.gmail.com>
Hi,
On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Maxime,
>
>
> 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> Hi Mike, Stephen,
>>
>> Please merge the following changes for the next merge window, thanks!
>>
>> Maxime
>>
>> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>
>> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>
>> are available in the Git repository at:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>>
>> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>>
>> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>>
>> ----------------------------------------------------------------
>> Allwinner clock changes for 4.18
>>
>> Not a lot of changes for this release, but two quite important features
>> were added: the H6 PRCM clock support, and the needed changes to the R40
>> clock driver to allow for the EMAC to operate.
>>
>> ----------------------------------------------------------------
>> Icenowy Zheng (3):
>> clk: sunxi-ng: add support for H6 PRCM CCU
>> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>>
>
>
>
> Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> not included in the pull request?
>
>
> You said "I've picked it up"
> https://patchwork.kernel.org/patch/10348031/
It looks like it was accidentally dropped after a rebase.
Not quite sure what happened there. Maxime?
ChenYu
^ permalink raw reply
* [PATCH 04/24] 32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
From: Arnd Bergmann @ 2018-06-11 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180609074227.GA6810@yury-thinkpad>
On Sat, Jun 9, 2018 at 9:42 AM, Yury Norov <ynorov@caviumnetworks.com> wrote:
> On Fri, Jun 08, 2018 at 06:32:07PM +0100, Catalin Marinas wrote:
>> On Wed, May 16, 2018 at 11:18:49AM +0300, Yury Norov wrote:
>> > diff --git a/arch/Kconfig b/arch/Kconfig
>> > index 76c0b54443b1..ee079244dc3c 100644
>> > --- a/arch/Kconfig
>> > +++ b/arch/Kconfig
>> > @@ -264,6 +264,21 @@ config ARCH_THREAD_STACK_ALLOCATOR
>> > config ARCH_WANTS_DYNAMIC_TASK_STRUCT
>> > bool
>> >
>> > +config ARCH_32BIT_OFF_T
>> > + bool
>> > + depends on !64BIT
>> > + help
>> > + All new 32-bit architectures should have 64-bit off_t type on
>> > + userspace side which corresponds to the loff_t kernel type. This
>> > + is the requirement for modern ABIs. Some existing architectures
>> > + already have 32-bit off_t. This option is enabled for all such
>> > + architectures explicitly. Namely: arc, arm, blackfin, cris, frv,
>> > + h8300, hexagon, m32r, m68k, metag, microblaze, mips32, mn10300,
>> > + nios2, openrisc, parisc32, powerpc32, score, sh, sparc, tile32,
>> > + unicore32, x86_32 and xtensa. This is the complete list. Any
>> > + new 32-bit architecture should declare 64-bit off_t type on user
>> > + side and so should not enable this option.
>>
>> Do you know if this is the case for riscv and nds32, merged in the
>> meantime? If not, I suggest you drop this patch altogether and just
>> define force_o_largefile() for arm64/ilp32 as we don't seem to stick to
>> "all new 32-bit architectures should have 64-bit off_t".
>
> I wrote this patch at request of Arnd Bergmann. This is actually his
> words that all new 32-bit architectures should have 64-bit off_t. So
> I was surprized when riscv was merged with 32-bit off_t (and I didn't
> follow nds32).
>
> If this rule is still in force, we'd better add new exceptions to this
> patch. Otherwise, we can drop it.
>
> Arnd, could you please comment it?
I completely forgot about it and had assumed that it was merged long
ago, sorry about that.
Arnd
^ permalink raw reply
* [PATCH 2/2] ARM: dts: am437x: make edt-ft5x06 a wakeup source for imx6 boards
From: Shawn Guo @ 2018-06-11 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523083013.7570-2-daniel@zonque.org>
On Wed, May 23, 2018 at 10:30:13AM +0200, Daniel Mack wrote:
> The touchscreen driver no longer configures the device as wakeup source by
> default. A "wakeup-source" property is needed.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
This is not an imx6 board, and I have to leave it to relevant platform
maintainer. The patch subject should be fixed to drop 'imx6'.
Shawn
> ---
> arch/arm/boot/dts/am437x-sk-evm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> index 4118802b7fea..f17ed89da06b 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -537,6 +537,8 @@
>
> touchscreen-size-x = <480>;
> touchscreen-size-y = <272>;
> +
> + wakeup-source;
> };
>
> tlv320aic3106: tlv320aic3106 at 1b {
> --
> 2.14.3
>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6: make edt-ft5x06 a wakeup source for imx6 boards
From: Shawn Guo @ 2018-06-11 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180523083013.7570-1-daniel@zonque.org>
On Wed, May 23, 2018 at 10:30:12AM +0200, Daniel Mack wrote:
> The touchscreen driver no longer configures the device as wakeup source by
> default. A "wakeup-source" property is needed.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Hans Verkuil @ 2018-06-11 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANb2CJFXhY+mzEV7AnM5EQcvqyeAH7G=t3Bi_9_d9_+_Kce9RQ@mail.gmail.com>
On 11/06/18 08:44, Keiichi Watanabe wrote:
> Hi, Hans.
> Thank you for the review.
> Your idea sounds good.
>
> However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum
> breaks both of s5p-mfc and venus drivers. This is because they call
> 'v4l2_ctrl_new_std' for it. For menu controls,
> 'v4l2_ctrl_new_std_menu' must be used.
>
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678
> https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133
>
> I can fix them within the commit for adding VP8_PROFILE control, but
> cannot confirm that it works on real devices since I don't have them.
> What should I do?
Fix it in both drivers with a Cc to stanimir.varbanov at linaro.org (venus) and
s.nawrocki at samsung.com (s5p) to let them test/ack the patch.
Venus is no problem, the s5p driver can decide to keep the old INT control
since it has been in use for such a long time, but that is up to Sylwester to
decide.
Regards,
Hans
>
> Best regards,
> Keiichi
> On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>>
>>
>>
>> Le ven. 8 juin 2018 08:56, Stanimir Varbanov <stanimir.varbanov@linaro.org> a ?crit :
>>>
>>> Hi Hans,
>>>
>>> On 06/08/2018 12:29 PM, Hans Verkuil wrote:
>>>> On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
>>>>> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
>>>>> profile for VP9 encoder and querying for supported profiles by VP9 encoder
>>>>> or decoder.
>>>>>
>>>>> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
>>>>> used for querying since it is not a menu control but an integer
>>>>> control, which cannot return an arbitrary set of supported profiles.
>>>>>
>>>>> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
>>>>> with controls for other codec profiles. (e.g. H264)
>>>>
>>>> Please ignore my reply to patch 2/2. I looked at this a bit more and what you
>>>> should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
>>>>
>>>> All other codec profile controls are all enums, so the fact that VPX_PROFILE
>>>> isn't is a bug. Changing the type should not cause any problems since the same
>>>> control value is used when you set the control.
>>>>
>>>> Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
>>>> as an integer type control, so the s5p-mfc driver should not be affected by
>>>> changing the type of this control.
>>>>
>>>> Stanimir: this will slightly change the venus driver, but since it is a very
>>>> recent driver I think we can get away with changing the core type of the
>>>> VPX_PROFILE control. I think that's better than ending up with two controls
>>>> that do the same thing.
>>>
>>> I agree. Actually the changes shouldn't be so much in venus driver.
>>
>>
>> Also fine on userspace side, since profiles enumeration isn't implemented yet in FFMPEG, GStreamer, Chrome
>>
>>
>>>
>>> --
>>> regards,
>>> Stan
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <89d55b0b-fe9e-793b-2694-25755ac2bc15@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:48]:
> Hi,
>
> On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> >> Great. I thought I completely misunderstood you. But I don't see what
> >> adding another function will accomplish. A QUIRK flag used in the same
> >> function would work well enough>
> > Fine with me as long as the function stays simple for both
> > syss and sysc reset.
> >
>
>
> In general a reset status bit being in sysstatus is the norm and it
> being in sysconfig should be the "quirk" for which a flag needs to be
> added. What do you think?
Sure makes sense to me.
> As an aside, naming bitshifts by the name of the platform they were
> originally added in seems weird. There should be some generic mask
> saying "soft reset is the 0th bit". Currently I am using
> SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
> different sysconfig types we have.
Sure we could have a macro for that.
Regards,
Tony
^ permalink raw reply
* [RFC PATCH] iio: adc: at91-sama5d2_adc: add support for oversampling resolution
From: Eugen Hristev @ 2018-06-11 6:52 UTC (permalink / raw)
To: linux-arm-kernel
This is implements oversampling support for the SAMA5D2 ADC
device.
Enabling oversampling : OSR can improve resolution from 12 bits to
13 or 14 bits.
To not modify the scan element of the buffer , from 12 bits to 13 or 14,
I have added the extra bit(s) as MICRO values to the INT value from the
conversion.
Special care was required for the triggered buffer scenario (+ DMA).
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Hello Jonathan,
I marked this patch as RFC because I am not confident in the best way to handle
this oversampling support.
I modified the return value of the channels to use IIO_VALUE_INT_PLUS_MICRO
instead of IIO_VALUE_INT, so I can add an extra bit or two bits in there to the
INT value (0/500000 or 0/250000/500000/7500000) .
You know of a better way to add this support?
Looks like the iio channel spec cannot be modified at
runtime. Would be best if the real bits in the channel spec would be changed to
13 or 14, but then, the buffer would be confused, as the buffer spec is now
le:u12/16>>0 so how can I change that to reflect oversampling, or,
IIO_VALUE_INT_PLUS_MICRO ?
And I am not sure how to handle this w.r.t ABI and userspace changes.
At this moment I added the micro values just to the software trigger readings,
and triggered buffer + DMA does not provide the extra bits, but, I need
to shift all values with 2 bits to the right . The code is rather ugly
right now, but I can change it to look prettier if this is the proper way
to do it.
Thanks for all the feedback,
Eugen
drivers/iio/adc/at91-sama5d2_adc.c | 198 ++++++++++++++++++++++++++++++++-----
1 file changed, 172 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
index 58c4c2b..f1a89b7 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -130,6 +130,15 @@
#define AT91_SAMA5D2_OVER 0x3c
/* Extended Mode Register */
#define AT91_SAMA5D2_EMR 0x40
+/* Extended Mode Register - Oversampling rate */
+#define AT91_SAMA5D2_EMR_OSR(V) ((V) << 16)
+#define AT91_SAMA5D2_EMR_OSR_MASK GENMASK(17, 16)
+#define AT91_SAMA5D2_EMR_OSR_0SAMPLES 0
+#define AT91_SAMA5D2_EMR_OSR_4SAMPLES 1
+#define AT91_SAMA5D2_EMR_OSR_16SAMPLES 2
+
+/* Extended Mode Register - Averaging on single trigger event */
+#define AT91_SAMA5D2_EMR_ASTE(V) ((V) << 20)
/* Compare Window Register */
#define AT91_SAMA5D2_CWR 0x44
/* Channel Gain Register */
@@ -248,6 +257,14 @@
#define AT91_HWFIFO_MAX_SIZE_STR "128"
#define AT91_HWFIFO_MAX_SIZE 128
+/* Possible values for oversampling ratio, and the string equivalent */
+#define AT91_OSR_0SAMPLES 0
+#define AT91_OSR_0SAMPLES_STR "0"
+#define AT91_OSR_4SAMPLES 4
+#define AT91_OSR_4SAMPLES_STR "4"
+#define AT91_OSR_16SAMPLES 16
+#define AT91_OSR_16SAMPLES_STR "16"
+
#define AT91_SAMA5D2_CHAN_SINGLE(num, addr) \
{ \
.type = IIO_VOLTAGE, \
@@ -261,7 +278,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num, \
.indexed = 1, \
}
@@ -281,7 +299,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num"-CH"#num2, \
.indexed = 1, \
}
@@ -299,7 +318,8 @@
.storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = name, \
}
#define AT91_SAMA5D2_CHAN_PRESSURE(num, name) \
@@ -313,7 +333,8 @@
.storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = name, \
}
@@ -384,6 +405,7 @@ struct at91_adc_state {
const struct iio_chan_spec *chan;
bool conversion_done;
u32 conversion_value;
+ unsigned int oversampling_ratio;
struct at91_adc_soc_info soc_info;
wait_queue_head_t wq_data_available;
struct at91_adc_dma dma_st;
@@ -475,6 +497,76 @@ static inline int at91_adc_of_xlate(struct iio_dev *indio_dev,
return at91_adc_chan_xlate(indio_dev, iiospec->args[0]);
}
+static void at91_adc_config_emr(struct at91_adc_state *st)
+{
+ /* configure the extended mode register */
+ unsigned int emr = at91_adc_readl(st, AT91_SAMA5D2_EMR);
+
+ /* select oversampling per single trigger event */
+ emr |= AT91_SAMA5D2_EMR_ASTE(1);
+
+ /* delete leftover content if it's the case */
+ emr &= ~AT91_SAMA5D2_EMR_OSR_MASK;
+
+ /* select oversampling ratio from configuration */
+ switch (st->oversampling_ratio) {
+ case AT91_OSR_0SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_0SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ case AT91_OSR_4SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_4SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ case AT91_OSR_16SAMPLES:
+ emr |= AT91_SAMA5D2_EMR_OSR(AT91_SAMA5D2_EMR_OSR_16SAMPLES) &
+ AT91_SAMA5D2_EMR_OSR_MASK;
+ break;
+ };
+
+ at91_adc_writel(st, AT91_SAMA5D2_EMR, emr);
+}
+
+static int at91_adc_adjust_val_osr(struct at91_adc_state *st, int *val,
+ int *val2)
+{
+ u8 extra_bits;
+
+ switch (st->oversampling_ratio) {
+ case AT91_OSR_4SAMPLES:
+ /* in this case we need to report 1 extra bit */
+ extra_bits = *val & 0x1;
+ if (extra_bits)
+ *val2 = 500000;
+ else
+ *val2 = 0;
+ *val >>= 1; /* keep just 12 bits */
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AT91_OSR_16SAMPLES:
+ /* in this case we need to report 2 extra bits */
+ extra_bits = *val & 0x3;
+ switch (extra_bits) {
+ case 0:
+ *val2 = 0;
+ break;
+ case 1:
+ *val2 = 250000;
+ break;
+ case 2:
+ *val2 = 500000;
+ break;
+ case 3:
+ *val2 = 750000;
+ break;
+ };
+ *val >>= 2; /* keep just 12 bits */
+ return IIO_VAL_INT_PLUS_MICRO;
+ };
+
+ return IIO_VAL_INT;
+}
+
static int at91_adc_configure_touch(struct at91_adc_state *st, bool state)
{
u32 clk_khz = st->current_sample_rate / 1000;
@@ -916,6 +1008,9 @@ static void at91_adc_trigger_handler_nodma(struct iio_dev *indio_dev,
{
struct at91_adc_state *st = iio_priv(indio_dev);
int i = 0;
+ /* micro value for oversampling data */
+ int micro;
+ int val;
u8 bit;
for_each_set_bit(bit, indio_dev->active_scan_mask,
@@ -936,7 +1031,9 @@ static void at91_adc_trigger_handler_nodma(struct iio_dev *indio_dev,
* Thus, emit a warning.
*/
if (chan->type == IIO_VOLTAGE) {
- st->buffer[i] = at91_adc_readl(st, chan->address);
+ val = at91_adc_readl(st, chan->address);
+ at91_adc_adjust_val_osr(st, &val, µ);
+ st->buffer[i] = val;
} else {
st->buffer[i] = 0;
WARN(true, "This trigger cannot handle this type of channel");
@@ -954,6 +1051,9 @@ static void at91_adc_trigger_handler_dma(struct iio_dev *indio_dev)
s64 ns = iio_get_time_ns(indio_dev);
s64 interval;
int sample_index = 0, sample_count, sample_size;
+ /* micro value for oversampling data */
+ int micro;
+ int val, j;
u32 status = at91_adc_readl(st, AT91_SAMA5D2_ISR);
/* if we reached this point, we cannot sample faster */
@@ -972,6 +1072,17 @@ static void at91_adc_trigger_handler_dma(struct iio_dev *indio_dev)
interval = div_s64((ns - st->dma_st.dma_ts), sample_count);
while (transferred_len >= sample_size) {
+ /*
+ * for all the values in the current sample,
+ * adjust the values inside the buffer for oversampling
+ */
+ for (j = 0; j < sample_size / 2; j++) {
+ /* buffer is byte-based. we need the whole value */
+ val = *((u16 *)&st->dma_st.rx_buf[st->dma_st.buf_idx + j * 2]);
+ at91_adc_adjust_val_osr(st, &val, µ);
+ *((u16 *)&st->dma_st.rx_buf[st->dma_st.buf_idx + j * 2]) = val;
+ }
+
iio_push_to_buffers_with_timestamp(indio_dev,
(st->dma_st.rx_buf + st->dma_st.buf_idx),
(st->dma_st.dma_ts + interval * sample_index));
@@ -1190,8 +1301,10 @@ static irqreturn_t at91_adc_interrupt(int irq, void *private)
return IRQ_HANDLED;
}
+
static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan, int *val)
+ struct iio_chan_spec const *chan, int *val,
+ int *val2)
{
struct at91_adc_state *st = iio_priv(indio_dev);
u32 cor = 0;
@@ -1212,7 +1325,7 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
mutex_unlock(&st->lock);
iio_device_release_direct_mode(indio_dev);
- return ret;
+ return at91_adc_adjust_val_osr(st, val, val2);
}
if (chan->type == IIO_PRESSURE) {
ret = iio_device_claim_direct_mode(indio_dev);
@@ -1225,7 +1338,7 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
mutex_unlock(&st->lock);
iio_device_release_direct_mode(indio_dev);
- return ret;
+ return at91_adc_adjust_val_osr(st, val, val2);
}
/* in this case we have a voltage channel */
@@ -1254,9 +1367,9 @@ static int at91_adc_read_info_raw(struct iio_dev *indio_dev,
if (ret > 0) {
*val = st->conversion_value;
+ ret = at91_adc_adjust_val_osr(st, val, val2);
if (chan->scan_type.sign == 's')
*val = sign_extend32(*val, 11);
- ret = IIO_VAL_INT;
st->conversion_done = false;
}
@@ -1280,7 +1393,7 @@ static int at91_adc_read_raw(struct iio_dev *indio_dev,
switch (mask) {
case IIO_CHAN_INFO_RAW:
- return at91_adc_read_info_raw(indio_dev, chan, val);
+ return at91_adc_read_info_raw(indio_dev, chan, val, val2);
case IIO_CHAN_INFO_SCALE:
*val = st->vref_uv / 1000;
if (chan->differential)
@@ -1292,6 +1405,10 @@ static int at91_adc_read_raw(struct iio_dev *indio_dev,
*val = at91_adc_get_sample_freq(st);
return IIO_VAL_INT;
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ *val = st->oversampling_ratio;
+ return IIO_VAL_INT;
+
default:
return -EINVAL;
}
@@ -1303,16 +1420,28 @@ static int at91_adc_write_raw(struct iio_dev *indio_dev,
{
struct at91_adc_state *st = iio_priv(indio_dev);
- if (mask != IIO_CHAN_INFO_SAMP_FREQ)
- return -EINVAL;
+ switch (mask) {
+ case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
+ if ((val != AT91_OSR_0SAMPLES) && (val != AT91_OSR_4SAMPLES) &&
+ (val != AT91_OSR_16SAMPLES))
+ return -EINVAL;
+ /* if no change, optimize out */
+ if (val == st->oversampling_ratio)
+ return 0;
+ st->oversampling_ratio = val;
+ /* update ratio */
+ at91_adc_config_emr(st);
+ return 0;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ if (val < st->soc_info.min_sample_rate ||
+ val > st->soc_info.max_sample_rate)
+ return -EINVAL;
- if (val < st->soc_info.min_sample_rate ||
- val > st->soc_info.max_sample_rate)
+ at91_adc_setup_samp_freq(st, val);
+ return 0;
+ default:
return -EINVAL;
-
- at91_adc_setup_samp_freq(st, val);
-
- return 0;
+ };
}
static void at91_adc_dma_init(struct platform_device *pdev)
@@ -1446,14 +1575,6 @@ static int at91_adc_update_scan_mode(struct iio_dev *indio_dev,
return 0;
}
-static const struct iio_info at91_adc_info = {
- .read_raw = &at91_adc_read_raw,
- .write_raw = &at91_adc_write_raw,
- .update_scan_mode = &at91_adc_update_scan_mode,
- .of_xlate = &at91_adc_of_xlate,
- .hwfifo_set_watermark = &at91_adc_set_watermark,
-};
-
static void at91_adc_hw_init(struct at91_adc_state *st)
{
at91_adc_writel(st, AT91_SAMA5D2_CR, AT91_SAMA5D2_CR_SWRST);
@@ -1466,6 +1587,9 @@ static void at91_adc_hw_init(struct at91_adc_state *st)
AT91_SAMA5D2_MR_TRANSFER(2) | AT91_SAMA5D2_MR_ANACH);
at91_adc_setup_samp_freq(st, st->soc_info.min_sample_rate);
+
+ /* configure extended mode register */
+ at91_adc_config_emr(st);
}
static ssize_t at91_adc_get_fifo_state(struct device *dev,
@@ -1496,6 +1620,19 @@ static IIO_DEVICE_ATTR(hwfifo_watermark, 0444,
static IIO_CONST_ATTR(hwfifo_watermark_min, "2");
static IIO_CONST_ATTR(hwfifo_watermark_max, AT91_HWFIFO_MAX_SIZE_STR);
+static IIO_CONST_ATTR(oversampling_ratio_available,
+ AT91_OSR_0SAMPLES_STR " " AT91_OSR_4SAMPLES_STR " "
+ AT91_OSR_16SAMPLES_STR);
+
+static struct attribute *at91_adc_attributes[] = {
+ &iio_const_attr_oversampling_ratio_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group at91_adc_attribute_group = {
+ .attrs = at91_adc_attributes,
+};
+
static const struct attribute *at91_adc_fifo_attributes[] = {
&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
@@ -1504,6 +1641,15 @@ static const struct attribute *at91_adc_fifo_attributes[] = {
NULL,
};
+static const struct iio_info at91_adc_info = {
+ .attrs = &at91_adc_attribute_group,
+ .read_raw = &at91_adc_read_raw,
+ .write_raw = &at91_adc_write_raw,
+ .update_scan_mode = &at91_adc_update_scan_mode,
+ .of_xlate = &at91_adc_of_xlate,
+ .hwfifo_set_watermark = &at91_adc_set_watermark,
+};
+
static int at91_adc_probe(struct platform_device *pdev)
{
struct iio_dev *indio_dev;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611062904.GO5738@atomide.com>
Hi,
On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
>> Great. I thought I completely misunderstood you. But I don't see what
>> adding another function will accomplish. A QUIRK flag used in the same
>> function would work well enough>
> Fine with me as long as the function stays simple for both
> syss and sysc reset.
>
In general a reset status bit being in sysstatus is the norm and it
being in sysconfig should be the "quirk" for which a flag needs to be
added. What do you think?
As an aside, naming bitshifts by the name of the platform they were
originally added in seems weird. There should be some generic mask
saying "soft reset is the 0th bit". Currently I am using
SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many
different sysconfig types we have.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-11 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKQmDh8MnArB1jCD6STh9FgLX+H4ZsEnH+coOJe-4A=FNPGshA@mail.gmail.com>
Hi, Hans.
Thank you for the review.
Your idea sounds good.
However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum
breaks both of s5p-mfc and venus drivers. This is because they call
'v4l2_ctrl_new_std' for it. For menu controls,
'v4l2_ctrl_new_std_menu' must be used.
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133
I can fix them within the commit for adding VP8_PROFILE control, but
cannot confirm that it works on real devices since I don't have them.
What should I do?
Best regards,
Keiichi
On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
>
>
> Le ven. 8 juin 2018 08:56, Stanimir Varbanov <stanimir.varbanov@linaro.org> a ?crit :
>>
>> Hi Hans,
>>
>> On 06/08/2018 12:29 PM, Hans Verkuil wrote:
>> > On 05/30/2018 09:16 AM, Keiichi Watanabe wrote:
>> >> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
>> >> profile for VP9 encoder and querying for supported profiles by VP9 encoder
>> >> or decoder.
>> >>
>> >> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
>> >> used for querying since it is not a menu control but an integer
>> >> control, which cannot return an arbitrary set of supported profiles.
>> >>
>> >> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
>> >> with controls for other codec profiles. (e.g. H264)
>> >
>> > Please ignore my reply to patch 2/2. I looked at this a bit more and what you
>> > should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum.
>> >
>> > All other codec profile controls are all enums, so the fact that VPX_PROFILE
>> > isn't is a bug. Changing the type should not cause any problems since the same
>> > control value is used when you set the control.
>> >
>> > Sylwester: I see that s5p-mfc uses this control, but it is explicitly added
>> > as an integer type control, so the s5p-mfc driver should not be affected by
>> > changing the type of this control.
>> >
>> > Stanimir: this will slightly change the venus driver, but since it is a very
>> > recent driver I think we can get away with changing the core type of the
>> > VPX_PROFILE control. I think that's better than ending up with two controls
>> > that do the same thing.
>>
>> I agree. Actually the changes shouldn't be so much in venus driver.
>
>
> Also fine on userspace side, since profiles enumeration isn't implemented yet in FFMPEG, GStreamer, Chrome
>
>
>>
>> --
>> regards,
>> Stan
^ permalink raw reply
* [PATCH] ARM: dts: imx6q: Use correct SDMA script for SPI5 core
From: Shawn Guo @ 2018-06-11 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180522174509.18154-1-sean.nyekjaer@prevas.dk>
On Tue, May 22, 2018 at 07:45:09PM +0200, Sean Nyekjaer wrote:
> According to the reference manual the shp_2_mcu / mcu_2_shp
> scripts must be used for devices connected through the SPBA.
>
> This fixes an issue we saw with DMA transfers.
> Sometimes the SPI controller RX FIFO was not empty after a DMA
> transfer and the driver got stuck in the next PIO transfer when
> it read one word more than expected.
>
> commit dd4b487b32a35 ("ARM: dts: imx6: Use correct SDMA script
> for SPI cores") is fixing the same issue but only for SPI1 - 4.
>
> Fixes: 677940258dd8e ("ARM: dts: imx6q: enable dma for ecspi5")
> Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Applied, thanks.
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f460481f-85a9-2a41-a894-6f25122dee8a@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:28]:
> Great. I thought I completely misunderstood you. But I don't see what
> adding another function will accomplish. A QUIRK flag used in the same
> function would work well enough.
Fine with me as long as the function stays simple for both
syss and sysc reset.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611060957.GN5738@atomide.com>
On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>>>> Hi,
>>>>
>>>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>>>> +static int sysc_reset(struct sysc *ddata)
>>>>>> +{
>>>>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>>>> + int val = sysc_read(ddata, offset);
>>>>>> +
>>>>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>>>> + sysc_write(ddata, offset, val);
>>>>>> +
>>>>>> + /* Poll on reset status */
>>>>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
>>>>>> +
>>>>>> + return readl_poll_timeout(ddata->module_va + offset, val,
>>>>>> + (val & ddata->cfg.syss_mask) == 0x0,
>>>>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
>>>>>> + }
>>>>>> +
>>>>>> + return 0;
>>>>>> +}
>>>>>
>>>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>>>> read the right register?
>>>>
>>>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>>>> the register. Are there layouts in which the reset status bit is in the
>>>> sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
>
> Yup.
>
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
>
> Yes
>
Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.
Regards,
Faiz
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Tony Lindgren @ 2018-06-11 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acdfef83-8778-e8f4-e423-ed04a9a8a649@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [180611 06:09]:
> Hi Tony,
>
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
> >>>> +static int sysc_reset(struct sysc *ddata)
> >>>> +{
> >>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
> >>>> + int val = sysc_read(ddata, offset);
> >>>> +
> >>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
> >>>> + sysc_write(ddata, offset, val);
> >>>> +
> >>>> + /* Poll on reset status */
> >>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
> >>>> +
> >>>> + return readl_poll_timeout(ddata->module_va + offset, val,
> >>>> + (val & ddata->cfg.syss_mask) == 0x0,
> >>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
> >>>> + }
> >>>> +
> >>>> + return 0;
> >>>> +}
> >>>
> >>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> >>> addition to SYSC_QUIRK_RESET status to make it easy to
> >>> read the right register?
> >>
> >> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> >> the register. Are there layouts in which the reset status bit is in the
> >> sysconfig register rather than the sysstatus register?
> >
> > Yes we can have reset status bit in either syss or syssconfig register.
>
> You mean sysstatus and sysconfig right?
Yup.
> > We detect that in sysc_init_syss_mask() but we should also set something
> > at that point to make it clear which reset to use. But as we don't need
> > the quirk flag, it's probably set a function pointer after the detection.
> > So how about let's have two functions sysc_reset() and sysc_syss_reset()
> > and then we can implement sysc_syss_reset() in a separate patch after
> > testing it when we have a non-platform data using example for
> > sysc_syss_reset().
> >
>
> Shouldn't the function I add be called sysc_syss_reset()? The reset
> status bit is in the sysstatus.
Yes
Tony
^ permalink raw reply
* [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
From: Faiz Abbas @ 2018-06-11 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608062158.GI5738@atomide.com>
Hi Tony,
On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas <faiz_abbas@ti.com> [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas <faiz_abbas@ti.com> [180606 06:14]:
>>>> +static int sysc_reset(struct sysc *ddata)
>>>> +{
>>>> + int offset = ddata->offsets[SYSC_SYSCONFIG];
>>>> + int val = sysc_read(ddata, offset);
>>>> +
>>>> + val |= (0x1 << ddata->cap->regbits->srst_shift);
>>>> + sysc_write(ddata, offset, val);
>>>> +
>>>> + /* Poll on reset status */
>>>> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>>>> + offset = ddata->offsets[SYSC_SYSSTATUS];
>>>> +
>>>> + return readl_poll_timeout(ddata->module_va + offset, val,
>>>> + (val & ddata->cfg.syss_mask) == 0x0,
>>>> + 100, MAX_MODULE_SOFTRESET_WAIT);
>>>> + }
>>>> +
>>>> + return 0;
>>>> +}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
>
> Yes we can have reset status bit in either syss or syssconfig register.
You mean sysstatus and sysconfig right?
> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
>
Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.
Thanks,
Faiz
^ permalink raw reply
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Kuninori Morimoto @ 2018-06-11 5:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <007401d40146$9ddaaec0$d9900c40$@socionext.com>
Hi Katsuhiro
> > > This patch moves headphone and microphone detection to probe() of
> > > snd_soc_card from init() of snd_soc_dai_link. This is because init()
> > > is called (and an input device /dev/input/eventX is created too)
> > > twice or above if simple card has two or more DAI links.
(snip)
> It seems if simple card has multiple DAI links, it creates multiple input
> devices.
>
> For example simple card has 3-links, 3 input devices /dev/input/event0,
> event1, event2 are created. Is it correct?
Oh, I see, fair enough.
I'm sorry, it was my English skill error.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* [PATCH] arm: Initialize hrtimer-based broadcast clockevent
From: Jan Kiszka @ 2018-06-11 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <35966a15-8312-5ba9-ef76-33a6cfda1f32@siemens.com>
On 2018-04-04 17:54, Jan Kiszka wrote:
> On 2018-03-01 07:04, Jan Kiszka wrote:
>> On 2018-01-22 07:06, Jan Kiszka wrote:
>>> Analogously to 9358d755bd5c, this registers a broadcast clockevent in
>>> case no hardware broadcast timer is available and the per-CPU timers can
>>> be stopped in deep power states.
>>>
>>> Partitions of the Jailhouse hypervisor fall in this category.
>>> Registering the workaround timer allows to enter high-resolution mode in
>>> that case.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>> arch/arm/kernel/time.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
>>> index 629f8e9981f1..0a45d861ef8e 100644
>>> --- a/arch/arm/kernel/time.c
>>> +++ b/arch/arm/kernel/time.c
>>> @@ -12,6 +12,7 @@
>>> * reading the RTC at bootup, etc...
>>> */
>>> #include <linux/clk-provider.h>
>>> +#include <linux/clockchips.h>
>>> #include <linux/clocksource.h>
>>> #include <linux/errno.h>
>>> #include <linux/export.h>
>>> @@ -121,5 +122,7 @@ void __init time_init(void)
>>> of_clk_init(NULL);
>>> #endif
>>> timer_probe();
>>> +
>>> + tick_setup_hrtimer_broadcast();
>>> }
>>> }
>>>
>>
>> Gentle ping, just to avoid that this falls through the cracks because
>> it's so small.
>>
>
> 2nd ping. Should this patch be routed via ARM or rather some tip/timers
> tree?
>
3rd try: Could someone have a look at this and merge it - or at least
ack it in order to move forward?
Thanks,
Jan
^ permalink raw reply
* [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
From: Katsuhiro Suzuki @ 2018-06-11 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvq96gnm.wl-kuninori.morimoto.gx@renesas.com>
Hello Morimoto-san,
> -----Original Message-----
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Sent: Monday, June 11, 2018 2:27 PM
> To: Suzuki, Katsuhiro <suzuki.katsuhiro@socionext.com>
> Cc: Mark Brown <broonie@kernel.org>; alsa-devel at alsa-project.org; Masami
Hiramatsu
> <masami.hiramatsu@linaro.org>; Jassi Brar <jaswinder.singh@linaro.org>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to
soc_card
> probe
>
>
> Hi Katsuhiro-san
>
> > This patch moves headphone and microphone detection to probe() of
> > snd_soc_card from init() of snd_soc_dai_link. This is because init()
> > is called (and an input device /dev/input/eventX is created too)
> > twice or above if simple card has two or more DAI links.
> >
> > Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
>
> or above ?
>
It seems if simple card has multiple DAI links, it creates multiple input
devices.
For example simple card has 3-links, 3 input devices /dev/input/event0,
event1, event2 are created. Is it correct?
> > - ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX);
> > - if (ret < 0)
> > - return ret;
> > -
> > - ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
> > - if (ret < 0)
> > - return ret;
> (snip)
> > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> > + if (ret < 0)
> > + return ret;
>
> I think we want to keep "PREFIX" ?
>
Oops... Thank you. I'll fix it.
Regards,
--
Katsuhiro Suzuki
>
> Best regards
> ---
> Kuninori Morimoto
^ 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