* Re: [PATCH 1/4] arm64: dts: ls1088a: Fix incorrect I2C clock divider
From: Shawn Guo @ 2019-08-19 7:43 UTC (permalink / raw)
To: Chuanhua Han
Cc: mark.rutland, devicetree, linux-kernel, leoyang.li, robh+dt,
linux-arm-kernel
In-Reply-To: <20190806084223.23543-1-chuanhua.han@nxp.com>
On Tue, Aug 06, 2019 at 04:42:20PM +0800, Chuanhua Han wrote:
> Ls1088a platform, the i2c input clock is actually platform pll CLK / 8
> (this is the hardware connection), other clock divider can not get the
> correct i2c clock, resulting in the output of SCL pin clock is not
> accurate.
>
> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
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] ARM: dts: imx7d: cl-som-imx7: make ethernet work again
From: Shawn Guo @ 2019-08-19 7:51 UTC (permalink / raw)
To: André Draszik
Cc: Mark Rutland, devicetree, linux-arm-kernel, Sascha Hauer,
linux-kernel, Rob Herring, Igor Grinberg, Pengutronix Kernel Team,
Fabio Estevam, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190809031227.3319-1-git@andred.net>
On Fri, Aug 09, 2019 at 04:12:27AM +0100, André Draszik wrote:
> Recent changes to the atheros at803x driver caused
> ethernet to stop working on this board.
> In particular commit 6d4cd041f0af
> ("net: phy: at803x: disable delay only for RGMII mode")
> and commit cd28d1d6e52e
> ("net: phy: at803x: Disable phy delay for RGMII mode")
> fix the AR8031 driver to configure the phy's (RX/TX)
> delays as per the 'phy-mode' in the device tree.
>
> This now prevents ethernet from working on this board.
>
> It used to work before those commits, because the
> AR8031 comes out of reset with RX delay enabled, and
> the at803x driver didn't touch the delay configuration
> at all when "rgmii" mode was selected, and because
> arch/arm/mach-imx/mach-imx7d.c:ar8031_phy_fixup()
> unconditionally enables TX delay.
>
> Since above commits ar8031_phy_fixup() also has no
> effect anymore, and the end-result is that all delays
> are disabled in the phy, no ethernet.
>
> Update the device tree to restore functionality.
>
> Signed-off-by: André Draszik <git@andred.net>
> CC: Ilya Ledvich <ilya@compulab.co.il>
> CC: Igor Grinberg <grinberg@compulab.co.il>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Mark Rutland <mark.rutland@arm.com>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Pengutronix Kernel Team <kernel@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: NXP Linux Team <linux-imx@nxp.com>
> CC: devicetree@vger.kernel.org
> CC: linux-arm-kernel@lists.infradead.org
Applied, 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] ARM: imx: stop adjusting ar8031 phy tx delay
From: Shawn Guo @ 2019-08-19 7:51 UTC (permalink / raw)
To: André Draszik
Cc: Kate Stewart, Greg Kroah-Hartman, Sascha Hauer, linux-kernel,
Russell King, NXP Linux Team, Pengutronix Kernel Team,
Thomas Gleixner, Leonard Crestez, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190809031256.3594-1-git@andred.net>
On Fri, Aug 09, 2019 at 04:12:56AM +0100, André Draszik wrote:
> Recent changes to the Atheros at803x driver cause
> the approach taken here to stop working because
> commit 6d4cd041f0af
> ("net: phy: at803x: disable delay only for RGMII mode")
> and commit cd28d1d6e52e
> ("net: phy: at803x: Disable phy delay for RGMII mode")
> fix the AR8031 driver to configure the phy's (RX/TX)
> delays as per the 'phy-mode' in the device tree.
>
> In particular, the phy tx (and rx) delays are updated
> again as per the 'phy-mode' *after* the code in here
> runs.
>
> Things worked before above commits, because the AR8031
> comes out of reset with RX delay enabled, and the
> at803x driver didn't touch the delay configuration at
> all when "rgmii" mode was selected.
>
> It appears the code in here tries to make device
> trees work that incorrectly specify "rgmii", but
> that can't work any more and it is imperative since
> above commits to have the phy-mode configured
> correctly in the device tree.
>
> I suspect there are a few imx7d based boards using
> the ar8031 phy and phy-mode = "rgmii", but given I
> don't know which ones exactly, I am not in a
> position to update the respective device trees.
>
> Hence this patch is simply removing the superfluous
> code from the imx7d initialisation. An alternative
> could be to add a warning instead, but that would
> penalize all boards that have been updated already.
>
> Signed-off-by: André Draszik <git@andred.net>
> CC: Russell King <linux@armlinux.org.uk>
> CC: Shawn Guo <shawnguo@kernel.org>
> CC: Sascha Hauer <s.hauer@pengutronix.de>
> CC: Pengutronix Kernel Team <kernel@pengutronix.de>
> CC: Fabio Estevam <festevam@gmail.com>
> CC: NXP Linux Team <linux-imx@nxp.com>
> CC: Kate Stewart <kstewart@linuxfoundation.org>
> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Leonard Crestez <leonard.crestez@nxp.com>
> CC: linux-arm-kernel@lists.infradead.org
Applied, 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 0/2] ARM: psci: cpuidle: defconfig updates
From: Shawn Guo @ 2019-08-19 7:57 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Mark Rutland, Ulf Hansson, Catalin Marinas, Daniel Lezcano, soc,
Sudeep Holla, Will Deacon, LAKML
In-Reply-To: <20190814125239.6270-1-lorenzo.pieralisi@arm.com>
On Wed, Aug 14, 2019 at 01:52:37PM +0100, Lorenzo Pieralisi wrote:
> Rerouting defconfig updates related to this patch series:
>
> https://lore.kernel.org/linux-arm-kernel/cover.1565348376.git.lorenzo.pieralisi@arm.com/
>
> to arm-soc, as agreed in:
>
> https://lore.kernel.org/linux-arm-kernel/58d9677db3510ed106fe23118090c84f78a44102.1565348376.git.lorenzo.pieralisi@arm.com/
>
> Patches [1-6] are already queued in the ARM64 tree.
>
> Please consider pulling these defconfig changes, thank you very much.
We, platform maintainers, also send arch/arm64/configs/defconfig changes
to arm-soc folk. So I applied both patches to IMX tree and will send
them to arm-soc for 5.4 inclusion.
Shawn
>
> Cc: Will Deacon <will@kernel.org>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
>
> Lorenzo Pieralisi (2):
> arm64: defconfig: Enable the PSCI CPUidle driver
> ARM: imx_v6_v7_defconfig: Enable the PSCI CPUidle driver
>
> arch/arm/configs/imx_v6_v7_defconfig | 1 +
> arch/arm64/configs/defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> --
> 2.21.0
>
_______________________________________________
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 4/5] arm64: perf: Enable pmu counter direct access for perf event on armv8
From: Raphael Gault @ 2019-08-19 7:59 UTC (permalink / raw)
To: kbuild test robot
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, linux-kernel, acme, mingo, kbuild-all,
linux-arm-kernel
In-Reply-To: <201908182002.KAH4UW2w%lkp@intel.com>
Hi,
On 8/18/19 1:37 PM, kbuild test robot wrote:
> Hi Raphael,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3-rc4 next-20190816]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
This patchset was based on linux-next/master and note linus
Thanks,
--
Raphael Gault
_______________________________________________
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] efi/arm: fix allocation failure when reserving the kernel base
From: Chester Lin @ 2019-08-19 7:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Juergen Gross, Joey Lee, linux-efi@vger.kernel.org,
guillaume.gardet@arm.com, Ard Biesheuvel, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, Chester Lin, geert@linux-m68k.org,
ren_guo@c-sky.com, Gary Lin, akpm@linux-foundation.org,
mingo@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190815133738.GA2483@rapoport-lnx>
Hi Mike and Ard,
On Thu, Aug 15, 2019 at 04:37:39PM +0300, Mike Rapoport wrote:
> On Thu, Aug 15, 2019 at 02:32:50PM +0300, Ard Biesheuvel wrote:
> > (adding Mike)
> >
> > On Thu, 15 Aug 2019 at 14:28, Chester Lin <clin@suse.com> wrote:
> > >
> > > Hi Ard,
> > >
> > > On Thu, Aug 15, 2019 at 10:59:43AM +0300, Ard Biesheuvel wrote:
> > > > On Sun, 4 Aug 2019 at 10:57, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > > > >
> > > > > Hello Chester,
> > > > >
> > > > > On Fri, 2 Aug 2019 at 08:40, Chester Lin <clin@suse.com> wrote:
> > > > > >
> > > > > > In some cases the arm32 efistub could fail to allocate memory for
> > > > > > uncompressed kernel. For example, we got the following error message when
> > > > > > verifying EFI stub on Raspberry Pi-2 [kernel-5.2.1 + grub-2.04] :
> > > > > >
> > > > > > EFI stub: Booting Linux Kernel...
> > > > > > EFI stub: ERROR: Unable to allocate memory for uncompressed kernel.
> > > > > > EFI stub: ERROR: Failed to relocate kernel
> > > > > >
> > > > > > After checking the EFI memory map we found that the first page [0 - 0xfff]
> > > > > > had been reserved by Raspberry Pi-2's firmware, and the efistub tried to
> > > > > > set the dram base at 0, which was actually in a reserved region.
> > > > > >
> > > > >
> > > > > This by itself is a violation of the Linux boot protocol for 32-bit
> > > > > ARM when using the decompressor. The decompressor rounds down its own
> > > > > base address to a multiple of 128 MB, and assumes the whole area is
> > > > > available for the decompressed kernel and related data structures.
> > > > > (The first TEXT_OFFSET bytes are no longer used in practice, which is
> > > > > why putting a reserved region of 4 KB bytes works at the moment, but
> > > > > this is fragile). Note that the decompressor does not look at any DT
> > > > > or EFI provided memory maps *at all*.
> > > > >
> > > > > So unfortunately, this is not something we can fix in the kernel, but
> > > > > we should fix it in the bootloader or in GRUB, so it does not put any
> > > > > reserved regions in the first 128 MB of memory,
> > > > >
> > > >
> > > > OK, perhaps we can fix this by taking TEXT_OFFSET into account. The
> > > > ARM boot protocol docs are unclear about whether this memory should be
> > > > used or not, but it is no longer used for its original purpose (page
> > > > tables), and the RPi loader already keeps data there.
> > > >
> > > > Can you check whether the following patch works for you?
> > > >
> > > > diff --git a/drivers/firmware/efi/libstub/Makefile
> > > > b/drivers/firmware/efi/libstub/Makefile
> > > > index 0460c7581220..ee0661ddb25b 100644
> > > > --- a/drivers/firmware/efi/libstub/Makefile
> > > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > > @@ -52,6 +52,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o
> > > > string.o random.o \
> > > >
> > > > lib-$(CONFIG_ARM) += arm32-stub.o
> > > > lib-$(CONFIG_ARM64) += arm64-stub.o
> > > > +CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > > CFLAGS_arm64-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> > > >
> > > > #
> > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > index e8f7aefb6813..66ff0c8ec269 100644
> > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > @@ -204,7 +204,7 @@ efi_status_t
> > > > handle_kernel_image(efi_system_table_t *sys_table,
> > > > * loaded. These assumptions are made by the decompressor,
> > > > * before any memory map is available.
> > > > */
> > > > - dram_base = round_up(dram_base, SZ_128M);
> > > > + dram_base = round_up(dram_base, SZ_128M) + TEXT_OFFSET;
> > > >
> > > > status = reserve_kernel_base(sys_table, dram_base, reserve_addr,
> > > > reserve_size);
> > > >
> > >
> > > I tried your patch on rpi2 and got the following panic. Just a reminder that I
> > > have replaced some log messages with "......" since it might be too long to
> > > post all.
> > >
> >
> > OK. Good to know that this change helps you to get past the EFI stub boot issue.
> >
> > > In this case the kernel failed to reserve cma, which should hit the issue of
> > > memblock_limit=0x1000 as I had mentioned in my patch description. The first
> > > block [0-0xfff] was scanned in adjust_lowmem_bounds(), but it did not align
> > > with PMD_SIZE so the cma reservation failed because the memblock.current_limit
> > > was extremely low. That's why I expand the first reservation from 1 PAGESIZE to
> > > 1 PMD_SIZE in my patch in order to avoid this issue. Please kindly let me know
> > > if any suggestion, thank you.
>
>
> > This looks like it is a separate issue. The memblock/cma code should
> > not choke on a reserved page of memory at 0x0.
> >
> > Perhaps Russell or Mike (cc'ed) have an idea how to address this?
>
> Presuming that the last memblock dump comes from the end of
> arm_memblock_init() with the this memory map
>
> memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
>
> adjust_lowmem_bounds() will set the memblock_limit (and respectively global
> memblock.current_limit) to 0x1000 and any further memblock_alloc*() will
> happily fail.
>
> I believe that the assumption for memblock_limit calculations was that the
> first bank has several megs at least.
>
> I wonder if this hack would help:
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index d9a0038..948e5b9 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1206,7 +1206,7 @@ void __init adjust_lowmem_bounds(void)
> * allocated when mapping the start of bank 0, which
> * occurs before any free memory is mapped.
> */
> - if (!memblock_limit) {
> + if (memblock_limit < PMD_SIZE) {
> if (!IS_ALIGNED(block_start, PMD_SIZE))
> memblock_limit = block_start;
> else if (!IS_ALIGNED(block_end, PMD_SIZE))
>
I applied this patch as well and it works well on rpi-2 model B.
> > > boot-log:
> > > --------
> > >
> > > Loading Linux test ...
> > > EFI stub: Booting Linux Kernel...
> > > EFI stub: Using DTB from configuration table
> > > EFI stub: Exiting boot services and installing virtual address map...
> > > Uncompressing Linux... done, booting the kernel.
> > > [ 0.000000] Booting Linux on physical CPU 0xf00
> > > [ 0.000000] Linux version 5.2.1-lpae (chester@linux-8mug) (......)
> > > [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
> > > [ 0.000000] CPU: div instructions available: patching division code
> > > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > > [ 0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B Rev 1.1
> > > [ 0.000000] printk: bootconsole [earlycon0] enabled
> > > [ 0.000000] Memory policy: Data cache writealloc
> > > [ 0.000000] efi: Getting EFI parameters from FDT:
> > > [ 0.000000] efi: System Table: 0x000000003df757c0
> > > [ 0.000000] efi: MemMap Address: 0x000000002c1c5040
> > > [ 0.000000] efi: MemMap Size: 0x000003c0
> > > [ 0.000000] efi: MemMap Desc. Size: 0x00000028
> > > [ 0.000000] efi: MemMap Desc. Version: 0x00000001
> > > [ 0.000000] efi: EFI v2.70 by Das U-Boot
> > > [ 0.000000] efi: SMBIOS=0x3cb62000 MEMRESERVE=0x3cb3d040
> > > [ 0.000000] memblock_reserve: [0x000000003cb3d040-0x000000003cb3d04f] efi_config_parse_tables+0x25c/0x2d8
> > > [ 0.000000] efi: Processing EFI memory map:
> > > [ 0.000000] MEMBLOCK configuration:
> > > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x0000000000000010
> > > [ 0.000000] memory.cnt = 0x1
> > > [ 0.000000] memory[0x0] [0x0000000000000000-0x000000003dffffff], 0x000000003e000000 bytes flags: 0x0
> > > [ 0.000000] reserved.cnt = 0x1
> > > [ 0.000000] reserved[0x0] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > > [ 0.000000] memblock_remove: [0x0000000000000000-0xfffffffffffffffe] reserve_regions+0x68/0x23c
> > > [ 0.000000] efi: 0x000000000000-0x000000000fff [Reserved | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000000000-0x0000000000000fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000000001000-0x000000307fff [Conventional Memory| | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000001000-0x0000000000307fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000000308000-0x000002307fff [Boot Data | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000000308000-0x0000000002307fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000002308000-0x000002a93fff [Loader Data | | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000002308000-0x0000000002a93fff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x000002a94000-0x000007cf5fff [Conventional Memory| | | | | | | | |WB| | | ]
> > > [ 0.000000] memblock_add: [0x0000000002a94000-0x0000000007cf5fff] early_init_dt_add_memory_arch+0x164/0x178
> > > ......
> > > ......
> > > [ 0.000000] memblock_add: [0x000000003df76000-0x000000003dffffff] early_init_dt_add_memory_arch+0x164/0x178
> > > [ 0.000000] efi: 0x00003f100000-0x00003f100fff [Memory Mapped I/O |RUN| | | | | | | | | | | ]
> > > [ 0.000000] memblock_reserve: [0x000000002c1c5000-0x000000002c1c5fff] efi_init+0xd8/0x1c8
> > > [ 0.000000] memblock_reserve: [0x0000000000400000-0x0000000001df2cef] arm_memblock_init+0x44/0x19c
> > > [ 0.000000] memblock_reserve: [0x0000000000303000-0x0000000000307fff] arm_mm_memblock_reserve+0x30/0x38
> > > [ 0.000000] memblock_reserve: [0x0000000007cf6000-0x0000000007cfc5c4] early_init_dt_reserve_memory_arch+0x2c/0x30
> > > [ 0.000000] cma: Failed to reserve 64 MiB
> > > [ 0.000000] MEMBLOCK configuration:
> > > [ 0.000000] memory size = 0x000000003e000000 reserved size = 0x00000000019ff2c5
> > > [ 0.000000] memory.cnt = 0xa
> > > [ 0.000000] memory[0x0] [0x0000000000000000-0x0000000000000fff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x1] [0x0000000000001000-0x0000000007ef5fff], 0x0000000007ef5000 bytes flags: 0x0
> > > [ 0.000000] memory[0x2] [0x0000000007ef6000-0x0000000007f09fff], 0x0000000000014000 bytes flags: 0x4
> > > [ 0.000000] memory[0x3] [0x0000000007f0a000-0x000000003cb3efff], 0x0000000034c35000 bytes flags: 0x0
> > > [ 0.000000] memory[0x4] [0x000000003cb3f000-0x000000003cb3ffff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x5] [0x000000003cb40000-0x000000003cb5ffff], 0x0000000000020000 bytes flags: 0x0
> > > [ 0.000000] memory[0x6] [0x000000003cb60000-0x000000003cb68fff], 0x0000000000009000 bytes flags: 0x4
> > > [ 0.000000] memory[0x7] [0x000000003cb69000-0x000000003df74fff], 0x000000000140c000 bytes flags: 0x0
> > > [ 0.000000] memory[0x8] [0x000000003df75000-0x000000003df75fff], 0x0000000000001000 bytes flags: 0x4
> > > [ 0.000000] memory[0x9] [0x000000003df76000-0x000000003dffffff], 0x000000000008a000 bytes flags: 0x0
> > > [ 0.000000] reserved.cnt = 0x5
> > > [ 0.000000] reserved[0x0] [0x0000000000303000-0x0000000000307fff], 0x0000000000005000 bytes flags: 0x0
> > > [ 0.000000] reserved[0x1] [0x0000000000400000-0x0000000001df2cef], 0x00000000019f2cf0 bytes flags: 0x0
> > > [ 0.000000] reserved[0x2] [0x0000000007cf6000-0x0000000007cfc5c4], 0x00000000000065c5 bytes flags: 0x0
> > > [ 0.000000] reserved[0x3] [0x000000002c1c5000-0x000000002c1c5fff], 0x0000000000001000 bytes flags: 0x0
> > > [ 0.000000] reserved[0x4] [0x000000003cb3d040-0x000000003cb3d04f], 0x0000000000000010 bytes flags: 0x0
> > > [ 0.000000] memblock_alloc_try_nid: 4096 bytes align=0x1000 nid=-1 from=0x0000000000000000 max_addr=0x0000000000000000 early_alloc+0x44/0x70
> > > [ 0.000000] Kernel panic - not syncing: early_alloc: Failed to allocate 4096 bytes align=0x1000
> > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.2.1-lpae #1 openSUSE Tumbleweed (unreleased)
> > > [ 0.000000] Hardware name: BCM2835
> > > [ 0.000000] Backtrace:
> > > [ 0.000000] [<c043fafc>] (dump_backtrace) from [<c043fd84>] (show_stack+0x20/0x24)
> > > [ 0.000000] r7:c1800000 r6:00000000 r5:600001d3 r4:c1901ba0
> > > [ 0.000000] [<c043fd64>] (show_stack) from [<c0df9400>] (dump_stack+0xd0/0x104)
> > > [ 0.000000] [<c0df9330>] (dump_stack) from [<c048061c>] (panic+0xf8/0x32c)
> > > [ 0.000000] r10:c0307000 r9:c0001000 r8:00000003 r7:00000000 r6:00000000 r5:c181df04
> > > [ 0.000000] r4:c192b8d8 r3:00000001
> > > [ 0.000000] [<c0480528>] (panic) from [<c1609728>] (early_alloc+0x60/0x70)
> > > [ 0.000000] r3:00001000 r2:00001000 r1:c10037e8 r0:c12fe64c
> > > [ 0.000000] r7:00000000
> > > [ 0.000000] [<c16096c8>] (early_alloc) from [<c1609114>] (arm_pte_alloc+0x34/0x94)
> > > [ 0.000000] r7:00000000 r6:00000000 r4:c0307000
> > > [ 0.000000] [<c16090e0>] (arm_pte_alloc) from [<c1609384>] (__create_mapping+0x210/0x2c0)
> > > [ 0.000000] r9:c0001000 r8:c0001000 r7:00000001 r6:c13f22e0 r5:c0200000 r4:c0400000
> > > [ 0.000000] [<c1609174>] (__create_mapping) from [<c160951c>] (create_mapping+0xe8/0x108)
> > > [ 0.000000] r10:c0400000 r9:c16a2110 r8:c19c7a80 r7:00000000 r6:00400000 r5:c13f2000
> > > [ 0.000000] r4:c1801ef0
> > > [ 0.000000] [<c1609434>] (create_mapping) from [<c1609f50>] (paging_init+0x350/0x75c)
> > > [ 0.000000] r4:c1842d40
> > >
> > >
> > > > >
> > > > > > grub> lsefimmap
> > > > > > Type Physical start - end #Pages Size Attributes
> > > > > > reserved 0000000000000000-0000000000000fff 00000001 4KiB WB
> > > > > > conv-mem 0000000000001000-0000000007ef5fff 00007ef5 130004KiB WB
> > > > > > RT-data 0000000007ef6000-0000000007f09fff 00000014 80KiB RT WB
> > > > > > conv-mem 0000000007f0a000-000000002d871fff 00025968 615840KiB WB
> > > > > > .....
> > > > > >
> > > > > > To avoid a reserved address, we have to ignore the memory regions which are
> > > > > > marked as EFI_RESERVED_TYPE, and only conventional memory regions can be
> > > > > > chosen. If the region before the kernel base is unaligned, it will be
> > > > > > marked as EFI_RESERVED_TYPE and let kernel ignore it so that memblock_limit
> > > > > > will not be sticked with a very low address such as 0x1000.
> > > > > >
> > > >
> > > > This is a separate issue, so it should be handled in a separate patch.
> > > >
> > > > > > Signed-off-by: Chester Lin <clin@suse.com>
> > > > > > ---
> > > > > > arch/arm/mm/mmu.c | 3 ++
> > > > > > drivers/firmware/efi/libstub/arm32-stub.c | 43 ++++++++++++++++++-----
> > > > > > 2 files changed, 37 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > > > > index f3ce34113f89..909b11ba48d8 100644
> > > > > > --- a/arch/arm/mm/mmu.c
> > > > > > +++ b/arch/arm/mm/mmu.c
> > > > > > @@ -1184,6 +1184,9 @@ void __init adjust_lowmem_bounds(void)
> > > > > > phys_addr_t block_start = reg->base;
> > > > > > phys_addr_t block_end = reg->base + reg->size;
> > > > > >
> > > > > > + if (memblock_is_nomap(reg))
> > > > > > + continue;
> > > > > > +
> > > > > > if (reg->base < vmalloc_limit) {
> > > > > > if (block_end > lowmem_limit)
> > > > > > /*
> > > > > > diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > index e8f7aefb6813..10d33d36df00 100644
> > > > > > --- a/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > +++ b/drivers/firmware/efi/libstub/arm32-stub.c
> > > > > > @@ -128,7 +128,7 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > >
> > > > > > for (l = 0; l < map_size; l += desc_size) {
> > > > > > efi_memory_desc_t *desc;
> > > > > > - u64 start, end;
> > > > > > + u64 start, end, spare, kernel_base;
> > > > > >
> > > > > > desc = (void *)memory_map + l;
> > > > > > start = desc->phys_addr;
> > > > > > @@ -144,27 +144,52 @@ static efi_status_t reserve_kernel_base(efi_system_table_t *sys_table_arg,
> > > > > > case EFI_BOOT_SERVICES_DATA:
> > > > > > /* Ignore types that are released to the OS anyway */
> > > > > > continue;
> > > > > > -
> > > > > > + case EFI_RESERVED_TYPE:
> > > > > > + /* Ignore reserved regions */
> > > > > > + continue;
> > > > > > case EFI_CONVENTIONAL_MEMORY:
> > > > > > /*
> > > > > > * Reserve the intersection between this entry and the
> > > > > > * region.
> > > > > > */
> > > > > > start = max(start, (u64)dram_base);
> > > > > > - end = min(end, (u64)dram_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > > + kernel_base = round_up(start, PMD_SIZE);
> > > > > > + spare = kernel_base - start;
> > > > > > + end = min(end, kernel_base + MAX_UNCOMP_KERNEL_SIZE);
> > > > > > +
> > > > > > + status = efi_call_early(allocate_pages,
> > > > > > + EFI_ALLOCATE_ADDRESS,
> > > > > > + EFI_LOADER_DATA,
> > > > > > + MAX_UNCOMP_KERNEL_SIZE / EFI_PAGE_SIZE,
> > > > > > + &kernel_base);
> > > > > > + if (status != EFI_SUCCESS) {
> > > > > > + pr_efi_err(sys_table_arg,
> > > > > > + "reserve_kernel_base: alloc failed.\n");
> > > > > > + goto out;
> > > > > > + }
> > > > > > + *reserve_addr = kernel_base;
> > > > > >
> > > > > > + if (!spare)
> > > > > > + break;
> > > > > > + /*
> > > > > > + * If there's a gap between start and kernel_base,
> > > > > > + * it needs be reserved so that the memblock_limit
> > > > > > + * will not fall on a very low address when running
> > > > > > + * adjust_lowmem_bounds(), wchich could eventually
> > > > > > + * cause CMA reservation issue.
> > > > > > + */
> > > > > > status = efi_call_early(allocate_pages,
> > > > > > EFI_ALLOCATE_ADDRESS,
> > > > > > - EFI_LOADER_DATA,
> > > > > > - (end - start) / EFI_PAGE_SIZE,
> > > > > > + EFI_RESERVED_TYPE,
> > > > > > + spare / EFI_PAGE_SIZE,
> > > > > > &start);
> > > > > > if (status != EFI_SUCCESS) {
> > > > > > pr_efi_err(sys_table_arg,
> > > > > > - "reserve_kernel_base(): alloc failed.\n");
> > > > > > + "reserve spare-region failed\n");
> > > > > > goto out;
> > > > > > }
> > > > > > - break;
> > > > > >
> > > > > > + break;
> > > > > > case EFI_LOADER_CODE:
> > > > > > case EFI_LOADER_DATA:
> > > > > > /*
> > > > > > @@ -220,7 +245,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > > *image_size = image->image_size;
> > > > > > status = efi_relocate_kernel(sys_table, image_addr, *image_size,
> > > > > > *image_size,
> > > > > > - dram_base + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > > + *reserve_addr + MAX_UNCOMP_KERNEL_SIZE, 0);
> > > > > > if (status != EFI_SUCCESS) {
> > > > > > pr_efi_err(sys_table, "Failed to relocate kernel.\n");
> > > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > > @@ -233,7 +258,7 @@ efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
> > > > > > * in memory. The kernel determines the base of DRAM from the
> > > > > > * address at which the zImage is loaded.
> > > > > > */
> > > > > > - if (*image_addr + *image_size > dram_base + ZIMAGE_OFFSET_LIMIT) {
> > > > > > + if (*image_addr + *image_size > *reserve_addr + ZIMAGE_OFFSET_LIMIT) {
> > > > > > pr_efi_err(sys_table, "Failed to relocate kernel, no low memory available.\n");
> > > > > > efi_free(sys_table, *reserve_size, *reserve_addr);
> > > > > > *reserve_size = 0;
> > > > > > --
> > > > > > 2.22.0
> > > > > >
> > > >
> >
>
> --
> Sincerely yours,
> Mike.
>
>
_______________________________________________
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] soc: amlogic: meson-gx-socinfo: Add of_node_put() before return
From: Neil Armstrong @ 2019-08-19 8:05 UTC (permalink / raw)
To: Nishka Dasgupta, khilman, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190819072706.31732-1-nishkadg.linux@gmail.com>
On 19/08/2019 09:27, Nishka Dasgupta wrote:
> The variable np in function meson_gx_socinfo_init takes the return value
> of of_find_compatible_node, which gets a node but does not put it. If
> this node is not put it may cause a memory leak. Hence put np after its
> usefulness has been exhausted.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
> drivers/soc/amlogic/meson-gx-socinfo.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
> index bca34954518e..13695a72c695 100644
> --- a/drivers/soc/amlogic/meson-gx-socinfo.c
> +++ b/drivers/soc/amlogic/meson-gx-socinfo.c
> @@ -138,8 +138,10 @@ static int __init meson_gx_socinfo_init(void)
> }
>
> /* check if chip-id is available */
> - if (!of_property_read_bool(np, "amlogic,has-chip-id"))
> + if (!of_property_read_bool(np, "amlogic,has-chip-id")) {
> + of_node_put(np);
> return -ENODEV;
> + }
>
> /* node should be a syscon */
> regmap = syscon_node_to_regmap(np);
>
Thanks !
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Would need :
Fixes: a9daaba2965e ("soc: Add Amlogic SoC Information driver")
Neil
_______________________________________________
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 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Uwe Kleine-König @ 2019-08-19 8:10 UTC (permalink / raw)
To: Alexandre Belloni
Cc: linux-pwm, Ludovic Desroches, Thierry Reding, Claudiu Beznea,
linux-arm-kernel
In-Reply-To: <20190816204357.GG3545@piout.net>
[-- Attachment #1.1.1: Type: text/plain, Size: 1775 bytes --]
Hello Alexandre,
On 8/16/19 10:43 PM, Alexandre Belloni wrote:
> On 16/08/2019 11:37:48+0200, Uwe Kleine-König wrote:
>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
>> ---
>> drivers/pwm/pwm-atmel.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
>> index 42fe7bc043a8..1ddb93db9627 100644
>> --- a/drivers/pwm/pwm-atmel.c
>> +++ b/drivers/pwm/pwm-atmel.c
>> @@ -7,6 +7,16 @@
>> *
>> * Reference manual for "atmel,at91sam9rl-pwm":
>> * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
>> + *
>> + * Limitations:
>> + * - Periods start with the inactive level.
>> + * - Hardware has to be stopped in general to update settings.
>> + *
>> + * Software bugs/possible improvements:
>> + * - When atmel_pwm_apply() is called with state->enabled=false a change in
>> + * state->polarity isn't honored.
>> + * - Instead of sleeping to wait for a completed period, the interrupt
>> + * functionality could be used.
>
> This is definitively not trivial to do right. The main reason it is not
> done so is that reading PWM_ISR will clear all the bits so it is
> necessary to be very careful to avoid race conditions. I'm not sure it
> is worth the effort.
I didn't intend to claim it is easy or even that it should be
implemented. This was just what I noticed while reading through driver
and manual. I thought it was a good idea to document that in case
someone finds time and motivation to work on this driver.
The first issue pointed out should however be easy to fix and IMHO is a
real bug. (Though it's a corner case that hardly ever triggers.)
Best regards
Uwe
[-- Attachment #1.2: OpenPGP digital signature --]
[-- 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: [PATCH v6 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Sakari Ailus @ 2019-08-19 8:10 UTC (permalink / raw)
To: Hugues FRUCHET
Cc: Yannick FERTRE, Alexandre TORGUE, Mickael GUENE,
linux-kernel@vger.kernel.org, Philippe CORNU, Hans Verkuil,
Benjamin Gaignard, Mauro Carvalho Chehab,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <ceec05d1-5791-4ba6-e2a8-3a5fd8b89955@st.com>
On Mon, Aug 19, 2019 at 07:40:53AM +0000, Hugues FRUCHET wrote:
> Hi Sakari,
>
> OK, I will change.
>
> Have you some other remarks on this serie in order that I group changes
> in the next version ?
No other comments.
Thanks.
--
Sakari Ailus
sakari.ailus@linux.intel.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 v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-08-19 8:14 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Rutland, Biwen Li, Len Brown, Greg Kroah-Hartman,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
devicetree@vger.kernel.org, Rob Herring, Pavel Machek,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4158639.B12JYek7R7@kreacher>
Hi Rafael,
On Monday, August 05, 2019 17:59, Rafael J. Wysocki wrote:
>
> On Wednesday, July 24, 2019 9:47:20 AM CEST Ran Wang wrote:
> > Some user might want to go through all registered wakeup sources and
> > doing things accordingly. For example, SoC PM driver might need to do
> > HW programming to prevent powering down specific IP which wakeup
> > source depending on. So add this API to help walk through all
> > registered wakeup source objects on that list and return them one by one.
> >
> > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > ---
> > Change in v5:
> > - Update commit message, add decription of walk through all wakeup
> > source objects.
> > - Add SCU protection in function wakeup_source_get_next().
> > - Rename wakeup_source member 'attached_dev' to 'dev' and move it
> up
> > (before wakeirq).
> >
> > Change in v4:
> > - None.
> >
> > Change in v3:
> > - Adjust indentation of *attached_dev;.
> >
> > Change in v2:
> > - None.
> >
> > drivers/base/power/wakeup.c | 24 ++++++++++++++++++++++++
> > include/linux/pm_wakeup.h | 3 +++
> > 2 files changed, 27 insertions(+)
> >
> > diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> > index ee31d4f..2fba891 100644
> > --- a/drivers/base/power/wakeup.c
> > +++ b/drivers/base/power/wakeup.c
> > @@ -14,6 +14,7 @@
> > #include <linux/suspend.h>
> > #include <linux/seq_file.h>
> > #include <linux/debugfs.h>
> > +#include <linux/of_device.h>
> > #include <linux/pm_wakeirq.h>
> > #include <trace/events/power.h>
> >
> > @@ -226,6 +227,28 @@ void wakeup_source_unregister(struct
> wakeup_source *ws)
> > }
> > }
> > EXPORT_SYMBOL_GPL(wakeup_source_unregister);
> > +/**
> > + * wakeup_source_get_next - Get next wakeup source from the list
> > + * @ws: Previous wakeup source object, null means caller want first one.
> > + */
> > +struct wakeup_source *wakeup_source_get_next(struct wakeup_source
> > +*ws) {
> > + struct list_head *ws_head = &wakeup_sources;
> > + struct wakeup_source *next_ws = NULL;
> > + int idx;
> > +
> > + idx = srcu_read_lock(&wakeup_srcu);
> > + if (ws)
> > + next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
> > + struct wakeup_source, entry);
> > + else
> > + next_ws = list_entry_rcu(ws_head->next,
> > + struct wakeup_source, entry);
> > + srcu_read_unlock(&wakeup_srcu, idx);
> > +
>
> This is incorrect.
>
> The SRCU cannot be unlocked until the caller of this is done with the object
> returned by it, or that object can be freed while it is still being accessed.
Thanks for the comment. Looks like I was not fully understanding your point on
v4 discussion. So I will implement 3 APIs by referring wakeup_sources_stats_seq_start/next/stop()
> Besides, this patch conflicts with some general wakeup sources changes in the
> works, so it needs to be deferred and rebased on top of those changes.
Could you please tell me which is the right code base I should developing on?
I just tried applying v5 patch on latest git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git branch master (d1abaeb Linux 5.3-rc5)
and no conflict encountered.
Thanks & Regards,
Ran
_______________________________________________
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 2/6] arm64: Introduce config for S32
From: Shawn Guo @ 2019-08-19 8:14 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, corbet@lwn.net,
gregkh@linuxfoundation.org, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
Cosmin Stefan Stoica, robh+dt@kernel.org,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190809112853.15846-3-stefan-gabriel.mirea@nxp.com>
On Fri, Aug 09, 2019 at 11:29:10AM +0000, Stefan-gabriel Mirea wrote:
> From: Mihaela Martinas <Mihaela.Martinas@freescale.com>
>
> Add configuration option for the Freescale S32 platform family in
> Kconfig.platforms. For starters, the only SoC supported will be Treerunner
> (S32V234), with a single execution target: the S32V234-EVB (rev 29288)
> board.
>
> Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com>
> Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
> ---
> arch/arm64/Kconfig.platforms | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4778c775de1b..a9a6152d37eb 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -210,6 +210,11 @@ config ARCH_ROCKCHIP
> This enables support for the ARMv8 based Rockchip chipsets,
> like the RK3368.
>
> +config ARCH_S32
> + bool "Freescale S32 SoC Family"
So you still want to use 'Freescale' than 'NXP' here?
> + help
> + This enables support for the Freescale S32 family of processors.
Shawn
> +
> config ARCH_SEATTLE
> bool "AMD Seattle SoC Family"
> help
> --
> 2.22.0
>
_______________________________________________
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 v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Rafael J. Wysocki @ 2019-08-19 8:20 UTC (permalink / raw)
To: Ran Wang
Cc: Mark Rutland, Biwen Li, Len Brown, Greg Kroah-Hartman,
linux-pm@vger.kernel.org, Rafael J. Wysocki,
linux-kernel@vger.kernel.org, Leo Li, devicetree@vger.kernel.org,
Rob Herring, Pavel Machek, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB8PR04MB682632A586827032F8D6EA2DF1A80@DB8PR04MB6826.eurprd04.prod.outlook.com>
On Mon, Aug 19, 2019 at 10:15 AM Ran Wang <ran.wang_1@nxp.com> wrote:
>
> Hi Rafael,
>
> On Monday, August 05, 2019 17:59, Rafael J. Wysocki wrote:
> >
> > On Wednesday, July 24, 2019 9:47:20 AM CEST Ran Wang wrote:
> > > Some user might want to go through all registered wakeup sources and
> > > doing things accordingly. For example, SoC PM driver might need to do
> > > HW programming to prevent powering down specific IP which wakeup
> > > source depending on. So add this API to help walk through all
> > > registered wakeup source objects on that list and return them one by one.
> > >
> > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > ---
> > > Change in v5:
> > > - Update commit message, add decription of walk through all wakeup
> > > source objects.
> > > - Add SCU protection in function wakeup_source_get_next().
> > > - Rename wakeup_source member 'attached_dev' to 'dev' and move it
> > up
> > > (before wakeirq).
> > >
> > > Change in v4:
> > > - None.
> > >
> > > Change in v3:
> > > - Adjust indentation of *attached_dev;.
> > >
> > > Change in v2:
> > > - None.
> > >
> > > drivers/base/power/wakeup.c | 24 ++++++++++++++++++++++++
> > > include/linux/pm_wakeup.h | 3 +++
> > > 2 files changed, 27 insertions(+)
> > >
> > > diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> > > index ee31d4f..2fba891 100644
> > > --- a/drivers/base/power/wakeup.c
> > > +++ b/drivers/base/power/wakeup.c
> > > @@ -14,6 +14,7 @@
> > > #include <linux/suspend.h>
> > > #include <linux/seq_file.h>
> > > #include <linux/debugfs.h>
> > > +#include <linux/of_device.h>
> > > #include <linux/pm_wakeirq.h>
> > > #include <trace/events/power.h>
> > >
> > > @@ -226,6 +227,28 @@ void wakeup_source_unregister(struct
> > wakeup_source *ws)
> > > }
> > > }
> > > EXPORT_SYMBOL_GPL(wakeup_source_unregister);
> > > +/**
> > > + * wakeup_source_get_next - Get next wakeup source from the list
> > > + * @ws: Previous wakeup source object, null means caller want first one.
> > > + */
> > > +struct wakeup_source *wakeup_source_get_next(struct wakeup_source
> > > +*ws) {
> > > + struct list_head *ws_head = &wakeup_sources;
> > > + struct wakeup_source *next_ws = NULL;
> > > + int idx;
> > > +
> > > + idx = srcu_read_lock(&wakeup_srcu);
> > > + if (ws)
> > > + next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
> > > + struct wakeup_source, entry);
> > > + else
> > > + next_ws = list_entry_rcu(ws_head->next,
> > > + struct wakeup_source, entry);
> > > + srcu_read_unlock(&wakeup_srcu, idx);
> > > +
> >
> > This is incorrect.
> >
> > The SRCU cannot be unlocked until the caller of this is done with the object
> > returned by it, or that object can be freed while it is still being accessed.
>
> Thanks for the comment. Looks like I was not fully understanding your point on
> v4 discussion. So I will implement 3 APIs by referring wakeup_sources_stats_seq_start/next/stop()
>
> > Besides, this patch conflicts with some general wakeup sources changes in the
> > works, so it needs to be deferred and rebased on top of those changes.
>
> Could you please tell me which is the right code base I should developing on?
> I just tried applying v5 patch on latest git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git branch master (d1abaeb Linux 5.3-rc5)
> and no conflict encountered.
It is better to use the most recent -rc from Linus (5.3-rc5 as of
today) as the base unless your patches depend on some changes that are
not in there.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V3, 2/2] media: i2c: Add Omnivision OV02A10 camera sensor driver
From: Sakari Ailus @ 2019-08-19 8:30 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190819034331.13098-3-dongchun.zhu@mediatek.com>
Hi Dongchun,
Thanks for the update.
On Mon, Aug 19, 2019 at 11:43:31AM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch adds a V4L2 sub-device driver for OV02A10 image sensor.
> The OV02A10 is a 1/5" CMOS sensor from Omnivision,
> which supports output format: 10-bit Raw.
> The OV02A10 has a single MIPI lane interface and use the I2C bus
> for control and the CSI-2 bus for data.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> MAINTAINERS | 1 +
> drivers/media/i2c/Kconfig | 11 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/ov02a10.c | 1018 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 1031 insertions(+)
> create mode 100644 drivers/media/i2c/ov02a10.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 41734fb..4b714a2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11821,6 +11821,7 @@ M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> +F: drivers/media/i2c/ov02a10.c
> F: Documentation/devicetree/bindings/media/i2c/ov02a10.txt
>
> OMNIVISION OV2680 SENSOR DRIVER
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 79ce9ec..d063a82 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -617,6 +617,17 @@ config VIDEO_IMX355
> To compile this driver as a module, choose M here: the
> module will be called imx355.
>
> +config VIDEO_OV02A10
> + tristate "OmniVision OV02A10 sensor support"
> + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + help
> + This is a Video4Linux2 sensor driver for the OmniVision
> + OV02A10 camera.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ov02a10.
> +
> config VIDEO_OV2640
> tristate "OmniVision OV2640 sensor support"
> depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index fd4ea86..f34a7ac 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
> +obj-$(CONFIG_VIDEO_OV02A10) += ov02a10.o
> obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
> obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
> obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
> diff --git a/drivers/media/i2c/ov02a10.c b/drivers/media/i2c/ov02a10.c
> new file mode 100644
> index 0000000..ff5460a
> --- /dev/null
> +++ b/drivers/media/i2c/ov02a10.c
> @@ -0,0 +1,1018 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regulator/consumer.h>
> +#include <media/media-entity.h>
> +#include <media/v4l2-async.h>
> +#include <media/v4l2-ctrls.h>
> +#include <media/v4l2-subdev.h>
> +
> +#define CHIP_ID 0x2509
> +#define OV02A10_REG_CHIP_ID_H 0x02
> +#define OV02A10_REG_CHIP_ID_L 0x03
> +#define OV02A10_ID(_msb, _lsb) ((_msb) << 8 | (_lsb))
> +
> +/* Bit[1] vertical upside down */
> +/* Bit[0] horizontal mirror */
> +#define REG_MIRROR_FLIP_CONTROL 0x3f
> +
> +/* Orientation */
> +#define REG_CONFIG_MIRROR_FLIP 0x03
> +
> +#define REG_PAGE_SWITCH 0xfd
> +#define REG_GLOBAL_EFFECTIVE 0x01
> +#define REG_ENABLE BIT(0)
> +
> +#define REG_SC_CTRL_MODE 0xac
> +#define SC_CTRL_MODE_STANDBY 0x00
> +#define SC_CTRL_MODE_STREAMING 0x01
> +
> +#define OV02A10_REG_EXPOSURE_H 0x03
> +#define OV02A10_REG_EXPOSURE_L 0x04
> +#define OV02A10_EXPOSURE_MIN 4
> +#define OV02A10_EXPOSURE_STEP 1
> +
> +#define OV02A10_REG_VTS_H 0x05
> +#define OV02A10_REG_VTS_L 0x06
> +#define OV02A10_VTS_MAX 0x209f
> +#define OV02A10_VTS_MIN 0x04cf
> +#define OV02A10_BASIC_LINE 1224
> +
> +#define OV02A10_REG_GAIN 0x24
> +#define OV02A10_GAIN_MIN 0x10
> +#define OV02A10_GAIN_MAX 0xf8
> +#define OV02A10_GAIN_STEP 0x01
> +#define OV02A10_GAIN_DEFAULT 0x40
> +
> +#define REG_NULL 0xff
> +
> +#define OV02A10_LANES 1
> +#define OV02A10_BITS_PER_SAMPLE 10
> +
> +static const char * const ov02a10_supply_names[] = {
> + "dovdd", /* Digital I/O power */
> + "avdd", /* Analog power */
> + "dvdd", /* Digital core power */
> +};
> +
> +#define OV02A10_NUM_SUPPLIES ARRAY_SIZE(ov02a10_supply_names)
> +
> +struct regval {
> + u16 addr;
> + u8 val;
> +};
> +
> +struct ov02a10_mode {
> + u32 width;
> + u32 height;
> + u32 exp_def;
> + u32 hts_def;
> + u32 vts_def;
> + const struct regval *reg_list;
> +};
> +
> +struct ov02a10 {
> + struct clk *xvclk;
> + struct gpio_desc *powerdown_gpio;
> + struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[OV02A10_NUM_SUPPLIES];
> +
> + bool streaming;
> + bool upside_down;
> +
> + /*
> + * Serialize control access, get/set format, get selection
> + * and start streaming.
> + */
> + struct mutex mutex;
> + struct v4l2_subdev subdev;
> + struct media_pad pad;
> + struct v4l2_ctrl *anal_gain;
> + struct v4l2_ctrl *exposure;
> + struct v4l2_ctrl *hblank;
> + struct v4l2_ctrl *vblank;
> + struct v4l2_ctrl *hflip;
> + struct v4l2_ctrl *vflip;
> + struct v4l2_ctrl *test_pattern;
> + struct v4l2_mbus_framefmt fmt;
> + struct v4l2_ctrl_handler ctrl_handler;
> +
> + const struct ov02a10_mode *cur_mode;
> +};
> +
> +#define to_ov02a10(sd) container_of(sd, struct ov02a10, subdev)
> +
> +static inline void msleep_range(unsigned int delay_base)
> +{
> + usleep_range(delay_base * 1000, delay_base * 1000 + 500);
> +}
> +
> +/* MIPI color bar enable output */
> +static const struct regval ov02a10_test_pattern_enable_regs[] = {
> + {0xfd, 0x01},
> + {0x0d, 0x00},
> + {0xb6, 0x01},
> + {0x01, 0x01},
> + {0xfd, 0x01},
> + {0xac, 0x01},
> + {REG_NULL, 0x00}
> +};
> +
> +/* MIPI color bar disable output */
> +static const struct regval ov02a10_test_pattern_disable_regs[] = {
> + {0xfd, 0x01},
> + {0x0d, 0x00},
> + {0xb6, 0x00},
> + {0x01, 0x01},
> + {0xfd, 0x01},
> + {0xac, 0x01},
> + {REG_NULL, 0x00}
> +};
> +
> +/*
> + * xvclk 24Mhz
> + * pclk 39Mhz
> + * linelength 934(0x3a6)
> + * framelength 1390(0x56e)
> + * grabwindow_width 1600
> + * grabwindow_height 1200
> + * max_framerate 30fps
> + * mipi_datarate per lane 780Mbps
> + */
> +static const struct regval ov02a10_1600x1200_regs[] = {
> + {0xfd, 0x01},
> + {0xac, 0x00},
> + {0xfd, 0x00},
> + {0x2f, 0x29},
> + {0x34, 0x00},
> + {0x35, 0x21},
> + {0x30, 0x15},
> + {0x33, 0x01},
> + {0xfd, 0x01},
> + {0x44, 0x00},
> + {0x2a, 0x4c},
> + {0x2b, 0x1e},
> + {0x2c, 0x60},
> + {0x25, 0x11},
> + {0x03, 0x01},
> + {0x04, 0xae},
> + {0x09, 0x00},
> + {0x0a, 0x02},
> + {0x06, 0xa6},
> + {0x31, 0x00},
> + {0x24, 0x40},
> + {0x01, 0x01},
> + {0xfb, 0x73},
> + {0xfd, 0x01},
> + {0x16, 0x04},
> + {0x1c, 0x09},
> + {0x21, 0x42},
> + {0x12, 0x04},
> + {0x13, 0x10},
> + {0x11, 0x40},
> + {0x33, 0x81},
> + {0xd0, 0x00},
> + {0xd1, 0x01},
> + {0xd2, 0x00},
> + {0x50, 0x10},
> + {0x51, 0x23},
> + {0x52, 0x20},
> + {0x53, 0x10},
> + {0x54, 0x02},
> + {0x55, 0x20},
> + {0x56, 0x02},
> + {0x58, 0x48},
> + {0x5d, 0x15},
> + {0x5e, 0x05},
> + {0x66, 0x66},
> + {0x68, 0x68},
> + {0x6b, 0x00},
> + {0x6c, 0x00},
> + {0x6f, 0x40},
> + {0x70, 0x40},
> + {0x71, 0x0a},
> + {0x72, 0xf0},
> + {0x73, 0x10},
> + {0x75, 0x80},
> + {0x76, 0x10},
> + {0x84, 0x00},
> + {0x85, 0x10},
> + {0x86, 0x10},
> + {0x87, 0x00},
> + {0x8a, 0x22},
> + {0x8b, 0x22},
> + {0x19, 0xf1},
> + {0x29, 0x01},
> + {0xfd, 0x01},
> + {0x9d, 0xd6},
> + {0xa0, 0x29},
> + {0xa1, 0x03},
> + {0xad, 0x62},
> + {0xae, 0x00},
> + {0xaf, 0x85},
> + {0xb1, 0x01},
> + {0x8e, 0x06},
> + {0x8f, 0x40},
> + {0x90, 0x04},
> + {0x91, 0xb0},
> + {0x45, 0x01},
> + {0x46, 0x00},
> + {0x47, 0x6c},
> + {0x48, 0x03},
> + {0x49, 0x8b},
> + {0x4a, 0x00},
> + {0x4b, 0x07},
> + {0x4c, 0x04},
> + {0x4d, 0xb7},
> + {0xf0, 0x40},
> + {0xf1, 0x40},
> + {0xf2, 0x40},
> + {0xf3, 0x40},
> + {0x3f, 0x00},
> + {0xfd, 0x01},
> + {0x05, 0x00},
> + {0x06, 0xa6},
> + {0xfd, 0x01},
> + {REG_NULL, 0x00}
> +};
> +
> +#define OV02A10_LINK_FREQ_390MHZ 390000000
> +static const s64 link_freq_menu_items[] = {
> + OV02A10_LINK_FREQ_390MHZ
> +};
> +
> +static const char * const ov02a10_test_pattern_menu[] = {
> + "Disabled",
> + "Color Bar",
> +};
> +
> +static const struct ov02a10_mode supported_modes[] = {
> + {
> + .width = 1600,
> + .height = 1200,
> + .exp_def = 0x01ae,
> + .hts_def = 0x03a6,
> + .vts_def = 0x056e,
> + .reg_list = ov02a10_1600x1200_regs,
> + },
> +};
> +
> +/* Write a register */
> +static int ov02a10_write_reg(struct ov02a10 *ov02a10, u8 addr, u8 val)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + u8 buf[2] = {addr, val};
> + int ret;
> +
> + ret = i2c_master_send(client, buf, 2);
> +
> + if (ret != 2) {
> + dev_err(&client->dev, "%s: error: reg=%x, val=%x\n",
> + __func__, addr, val);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int ov02a10_write_array(struct ov02a10 *ov02a10,
> + const struct regval *regs)
> +{
> + u32 i;
unsigned int, please.
> + int ret;
> +
> + for (i = 0; regs[i].addr != REG_NULL; i++) {
> + ret = ov02a10_write_reg(ov02a10, regs[i].addr, regs[i].val);
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/* Read a register */
> +static int ov02a10_read_reg(struct ov02a10 *ov02a10, u8 reg, u8 *val)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + u8 data = reg;
> + struct i2c_msg msg = {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &data,
> + };
> + int ret;
> +
> + ret = i2c_transfer(client->adapter, &msg, 1);
> + if (ret < 0)
> + goto err_wr;
> +
> + msg.flags = I2C_M_RD;
> + ret = i2c_transfer(client->adapter, &msg, 1);
> + if (ret < 0)
> + goto err_rd;
> +
> + *val = data;
> + return 0;
> +
> +err_rd:
> + dev_err(&client->dev, "i2c_transfer --I2C_M_RD failed\n");
> +err_wr:
> + dev_err(&client->dev, "read error: reg=0x%02x: %d\n", reg, ret);
> + return ret;
> +}
> +
> +static void ov02a10_fill_fmt(const struct ov02a10_mode *mode,
> + struct v4l2_mbus_framefmt *fmt)
> +{
> + fmt->width = mode->width;
> + fmt->height = mode->height;
> + fmt->field = V4L2_FIELD_NONE;
> +}
> +
> +static int ov02a10_set_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *fmt)
> +{
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> + struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> + mutex_lock(&ov02a10->mutex);
> +
> + if (ov02a10->streaming) {
> + mutex_unlock(&ov02a10->mutex);
> + return -EBUSY;
> + }
> +
> + /* Only one sensor mode supported */
> + mbus_fmt->code = ov02a10->fmt.code;
> + ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> + ov02a10->fmt = fmt->format;
> +
> + mutex_unlock(&ov02a10->mutex);
> +
> + return 0;
> +}
> +
> +static int ov02a10_get_fmt(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_format *fmt)
> +{
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> + struct v4l2_mbus_framefmt *mbus_fmt = &fmt->format;
> +
> + mutex_lock(&ov02a10->mutex);
> +
> + fmt->format = ov02a10->fmt;
> + mbus_fmt->code = ov02a10->fmt.code;
> + ov02a10_fill_fmt(ov02a10->cur_mode, mbus_fmt);
> +
> + mutex_unlock(&ov02a10->mutex);
> +
> + return 0;
> +}
> +
> +static int ov02a10_enum_mbus_code(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_mbus_code_enum *code)
> +{
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> + if (code->index >= ARRAY_SIZE(supported_modes) || !(code->index))
This doesn't make sense. The supported modes, should more be added in the
future, are presumably using the same mbus code. If you only have one, then
non-zero code->index would result in -EINVAL (and not zero code->index).
> + return -EINVAL;
> +
> + code->code = ov02a10->fmt.code;
> +
> + return 0;
> +}
> +
> +static int ov02a10_enum_frame_sizes(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_frame_size_enum *fse)
> +{
> + if (fse->index >= ARRAY_SIZE(supported_modes) || !(fse->index))
> + return -EINVAL;
> +
> + fse->min_width = supported_modes[fse->index].width;
> + fse->max_width = supported_modes[fse->index].width;
> + fse->max_height = supported_modes[fse->index].height;
> + fse->min_height = supported_modes[fse->index].height;
> +
> + return 0;
> +}
> +
> +static int __ov02a10_power_on(struct ov02a10 *ov02a10)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + struct device *dev = &client->dev;
> + int ret;
> +
> + ret = clk_prepare_enable(ov02a10->xvclk);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable xvclk\n");
> + return ret;
> + }
> +
> + /* Note: set 0 is high, set 1 is low */
> + gpiod_set_value_cansleep(ov02a10->reset_gpio, 1);
> + gpiod_set_value_cansleep(ov02a10->powerdown_gpio, 0);
> +
> + ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable regulators\n");
> + goto disable_clk;
> + }
> + msleep_range(7);
This has some potential of clashing with more generic functions in the
future. Please use usleep_range directly, or msleep.
> +
> + gpiod_set_value_cansleep(ov02a10->powerdown_gpio, 1);
> + msleep_range(10);
> +
> + gpiod_set_value_cansleep(ov02a10->reset_gpio, 0);
> + msleep_range(10);
> +
> + return 0;
> +
> +disable_clk:
> + clk_disable_unprepare(ov02a10->xvclk);
> +
> + return ret;
> +}
> +
> +static void __ov02a10_power_off(struct ov02a10 *ov02a10)
> +{
> + clk_disable_unprepare(ov02a10->xvclk);
> + gpiod_set_value_cansleep(ov02a10->reset_gpio, 1);
> + gpiod_set_value_cansleep(ov02a10->powerdown_gpio, 1);
> + regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> +}
> +
> +static int __ov02a10_start_stream(struct ov02a10 *ov02a10)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + int ret;
> +
> + /* Apply default values of current mode */
> + ret = ov02a10_write_array(ov02a10, ov02a10->cur_mode->reg_list);
> + if (ret)
> + return ret;
> +
> + /* Apply customized values from user */
> + ret = __v4l2_ctrl_handler_setup(ov02a10->subdev.ctrl_handler);
> + if (ret)
> + return ret;
> +
> + /* Set orientation to 180 degree */
> + if (ov02a10->upside_down) {
> + ret = ov02a10_write_reg(ov02a10, REG_MIRROR_FLIP_CONTROL,
> + REG_CONFIG_MIRROR_FLIP);
> + if (ret) {
> + dev_err(&client->dev, "%s failed to set orientation\n",
> + __func__);
> + return ret;
> + }
> + ret = ov02a10_write_reg(ov02a10, REG_GLOBAL_EFFECTIVE,
> + REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + }
> +
> + /* Set stream on register */
> + return ov02a10_write_reg(ov02a10,
> + REG_SC_CTRL_MODE, SC_CTRL_MODE_STREAMING);
> +}
> +
> +static int __ov02a10_stop_stream(struct ov02a10 *ov02a10)
> +{
> + return ov02a10_write_reg(ov02a10,
> + REG_SC_CTRL_MODE, SC_CTRL_MODE_STANDBY);
> +}
> +
> +static int ov02a10_entity_init_cfg(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg)
> +{
> + struct v4l2_subdev_format fmt = { 0 };
> +
> + fmt.which = cfg ? V4L2_SUBDEV_FORMAT_TRY : V4L2_SUBDEV_FORMAT_ACTIVE;
> + fmt.format.width = 1600;
> + fmt.format.height = 1200;
> +
> + ov02a10_set_fmt(subdev, cfg, &fmt);
> +
> + return 0;
> +}
> +
> +static int ov02a10_s_stream(struct v4l2_subdev *sd, int on)
> +{
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + int ret = 0;
> +
> + mutex_lock(&ov02a10->mutex);
> +
> + if (ov02a10->streaming == on)
> + goto unlock_and_return;
> +
> + if (on) {
> + ret = pm_runtime_get_sync(&client->dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(&client->dev);
> + goto unlock_and_return;
> + }
> +
> + ret = __ov02a10_start_stream(ov02a10);
> + if (ret) {
> + __ov02a10_stop_stream(ov02a10);
> + ov02a10->streaming = !on;
> + goto err_rpm_put;
> + }
> + } else {
> + __ov02a10_stop_stream(ov02a10);
> + pm_runtime_put(&client->dev);
> + }
> +
> + ov02a10->streaming = on;
> + mutex_unlock(&ov02a10->mutex);
> +
> + return ret;
> +
> +err_rpm_put:
> + pm_runtime_put(&client->dev);
> +unlock_and_return:
> + mutex_unlock(&ov02a10->mutex);
> +
> + return ret;
> +}
> +
> +static int ov02a10_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> +{
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> + struct v4l2_mbus_framefmt *try_fmt = v4l2_subdev_get_try_format(sd,
> + fh->pad,
> + 0);
> +
> + mutex_lock(&ov02a10->mutex);
> + /* Initialize try_fmt */
> + try_fmt->code = ov02a10->fmt.code;
> + ov02a10_fill_fmt(&supported_modes[0], try_fmt);
> +
> + mutex_unlock(&ov02a10->mutex);
No need for the mutex: the supported values are static and there is no
parallel access to try_fmt.
Btw. you don't need to do this here as you have init_cfg implemented, i.e.
you can omit the open callback.
> +
> + return 0;
> +}
> +
> +static int __maybe_unused ov02a10_runtime_resume(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> + return __ov02a10_power_on(ov02a10);
> +}
> +
> +static int __maybe_unused ov02a10_runtime_suspend(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> + __ov02a10_power_off(ov02a10);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops ov02a10_pm_ops = {
> + SET_RUNTIME_PM_OPS(ov02a10_runtime_suspend,
> + ov02a10_runtime_resume, NULL)
> +};
> +
> +static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, s32 value)
> +{
> + if (value)
> + return ov02a10_write_array(ov02a10,
> + ov02a10_test_pattern_enable_regs);
> +
> + return ov02a10_write_array(ov02a10,
> + ov02a10_test_pattern_disable_regs);
Fits on previous line.
> +}
> +
> +static int ov02a10_set_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct ov02a10 *ov02a10 = container_of(ctrl->handler,
> + struct ov02a10, ctrl_handler);
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + s64 max_expo;
> + int ret;
> +
> + /* Propagate change of current control to all related controls */
> + if (ctrl->id == V4L2_CID_VBLANK) {
> + /* Update max exposure while meeting expected vblanking */
> + max_expo = ov02a10->cur_mode->height + ctrl->val - 4;
> + __v4l2_ctrl_modify_range(ov02a10->exposure,
> + ov02a10->exposure->minimum, max_expo,
> + ov02a10->exposure->step,
> + ov02a10->exposure->default_value);
> + }
> +
> + /* V4L2 controls values will be applied only when power is already up */
> + if (!pm_runtime_get_if_in_use(&client->dev))
> + return 0;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_EXPOSURE:
> + ret = ov02a10_write_reg(ov02a10, REG_PAGE_SWITCH, REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + ret = ov02a10_write_reg(ov02a10, OV02A10_REG_EXPOSURE_H,
> + ((ctrl->val >> 8) & 0xFF));
> + if (!ret) {
> + ret = ov02a10_write_reg(ov02a10, OV02A10_REG_EXPOSURE_L,
> + (ctrl->val & 0xFF));
> + if (ret < 0)
> + return ret;
> + }
> + ret = ov02a10_write_reg(ov02a10, REG_GLOBAL_EFFECTIVE,
> + REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + break;
> + case V4L2_CID_ANALOGUE_GAIN:
> + ret = ov02a10_write_reg(ov02a10, REG_PAGE_SWITCH, REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + ret = ov02a10_write_reg(ov02a10, OV02A10_REG_GAIN,
> + (ctrl->val & 0xFF));
> + if (ret < 0)
> + return ret;
> + ret = ov02a10_write_reg(ov02a10, REG_GLOBAL_EFFECTIVE,
> + REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + break;
> + case V4L2_CID_VBLANK:
> + ret = ov02a10_write_reg(ov02a10, REG_PAGE_SWITCH, REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + ret = ov02a10_write_reg(ov02a10, OV02A10_REG_VTS_H,
> + (((ctrl->val +
> + ov02a10->cur_mode->height -
> + OV02A10_BASIC_LINE) >> 8)
> + & 0xFF));
> + if (!ret) {
> + ret = ov02a10_write_reg(ov02a10, OV02A10_REG_VTS_L,
> + ((ctrl->val +
> + ov02a10->cur_mode->height -
> + OV02A10_BASIC_LINE) & 0xFF));
> + if (ret < 0)
> + return ret;
> + }
> + ret = ov02a10_write_reg(ov02a10, REG_GLOBAL_EFFECTIVE,
> + REG_ENABLE);
> + if (ret < 0)
> + return ret;
> + break;
> + case V4L2_CID_TEST_PATTERN:
> + ret = ov02a10_set_test_pattern(ov02a10, ctrl->val);
> + if (ret < 0)
> + return ret;
> + break;
> + default:
> + dev_warn(&client->dev, "%s Unhandled id:0x%x, val:0x%x\n",
> + __func__, ctrl->id, ctrl->val);
> + ret = -EINVAL;
> + break;
> + };
> +
> + pm_runtime_put(&client->dev);
> +
> + return ret;
> +}
> +
> +static const struct v4l2_subdev_video_ops ov02a10_video_ops = {
> + .s_stream = ov02a10_s_stream,
> +};
> +
> +static const struct v4l2_subdev_pad_ops ov02a10_pad_ops = {
> + .init_cfg = ov02a10_entity_init_cfg,
> + .enum_mbus_code = ov02a10_enum_mbus_code,
> + .enum_frame_size = ov02a10_enum_frame_sizes,
> + .get_fmt = ov02a10_get_fmt,
> + .set_fmt = ov02a10_set_fmt,
> +};
> +
> +static const struct v4l2_subdev_ops ov02a10_subdev_ops = {
> + .video = &ov02a10_video_ops,
> + .pad = &ov02a10_pad_ops,
> +};
> +
> +static const struct media_entity_operations ov02a10_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +
> +static const struct v4l2_subdev_internal_ops ov02a10_internal_ops = {
> + .open = ov02a10_open,
> +};
> +
> +static const struct v4l2_ctrl_ops ov02a10_ctrl_ops = {
> + .s_ctrl = ov02a10_set_ctrl,
> +};
> +
> +static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + const struct ov02a10_mode *mode;
> + struct v4l2_ctrl_handler *handler;
> + struct v4l2_ctrl *ctrl;
> + u64 exposure_max;
> + u32 pixel_rate, h_blank;
> + int ret;
> +
> + handler = &ov02a10->ctrl_handler;
> + mode = ov02a10->cur_mode;
> + ret = v4l2_ctrl_handler_init(handler, 10);
> + if (ret)
> + return ret;
An extra newline here, please.
> + handler->lock = &ov02a10->mutex;
> +
> + ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ,
> + 0, 0, link_freq_menu_items);
> + if (ctrl)
> + ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + pixel_rate = (link_freq_menu_items[0] * 2 * OV02A10_LANES) /
> + OV02A10_BITS_PER_SAMPLE;
Please use do_div(). The values are static so the compiler may not emit the
instructions for division but better be safe than sorry.
> + v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE,
> + 0, pixel_rate, 1, pixel_rate);
> +
> + h_blank = mode->hts_def - mode->width;
> + ov02a10->hblank = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_HBLANK,
> + h_blank, h_blank, 1, h_blank);
> + if (ov02a10->hblank)
> + ov02a10->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> + ov02a10->vblank = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> + V4L2_CID_VBLANK, mode->vts_def -
> + mode->height,
> + OV02A10_VTS_MAX - mode->height, 1,
> + mode->vts_def - mode->height);
> +
> + exposure_max = mode->vts_def - 4;
> + ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> + V4L2_CID_EXPOSURE,
> + OV02A10_EXPOSURE_MIN,
> + exposure_max,
> + OV02A10_EXPOSURE_STEP,
> + mode->exp_def);
> +
> + ov02a10->anal_gain = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> + V4L2_CID_ANALOGUE_GAIN,
> + OV02A10_GAIN_MIN,
> + OV02A10_GAIN_MAX,
> + OV02A10_GAIN_STEP,
> + OV02A10_GAIN_DEFAULT);
> +
> + ov02a10->test_pattern =
> + v4l2_ctrl_new_std_menu_items(handler,
Indentation. If some of the arguments slip over 80 I guess we can live with
that.
> + &ov02a10_ctrl_ops,
> + V4L2_CID_TEST_PATTERN,
> + ARRAY_SIZE(ov02a10_test_pattern_menu) -
> + 1, 0, 0, ov02a10_test_pattern_menu);
> +
> + if (handler->error) {
> + ret = handler->error;
> + dev_err(&client->dev,
> + "Failed to init controls(%d)\n", ret);
Fits on the previous line.
> + goto err_free_handler;
> + }
> +
> + ov02a10->subdev.ctrl_handler = handler;
> +
> + return 0;
> +
> +err_free_handler:
> + v4l2_ctrl_handler_free(handler);
> +
> + return ret;
> +}
> +
> +static int ov02a10_check_sensor_id(struct ov02a10 *ov02a10)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + u16 id;
> + u8 pid = 0;
> + u8 ver = 0;
> + int ret;
> +
> + /* Check sensor revision */
> + ret = ov02a10_read_reg(ov02a10, OV02A10_REG_CHIP_ID_H, &pid);
> + if (ret)
> + return ret;
> +
> + ret = ov02a10_read_reg(ov02a10, OV02A10_REG_CHIP_ID_L, &ver);
> + if (ret)
> + return ret;
> +
> + id = OV02A10_ID(pid, ver);
> + if (id != CHIP_ID) {
> + dev_err(&client->dev, "Unexpected sensor id(%04x)\n", id);
> + return ret;
> + }
> +
> + dev_info(&client->dev, "Detected OV%04X sensor\n", id);
> +
> + return 0;
> +}
> +
> +static int ov02a10_configure_regulators(struct ov02a10 *ov02a10)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> + unsigned int i;
> +
> + for (i = 0; i < OV02A10_NUM_SUPPLIES; i++)
> + ov02a10->supplies[i].supply = ov02a10_supply_names[i];
> +
> + return devm_regulator_bulk_get(&client->dev,
> + OV02A10_NUM_SUPPLIES,
> + ov02a10->supplies);
> +}
> +
> +static int ov02a10_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct ov02a10 *ov02a10;
> + u32 rotation;
> + u32 xclk_freq;
> + int ret;
> +
> + ov02a10 = devm_kzalloc(dev, sizeof(*ov02a10), GFP_KERNEL);
> + if (!ov02a10)
> + return -ENOMEM;
> +
> + v4l2_i2c_subdev_init(&ov02a10->subdev, client, &ov02a10_subdev_ops);
> + ov02a10->fmt.code = MEDIA_BUS_FMT_SBGGR10_1X10;
> +
> + /* Optional indication of physical rotation of sensor */
> + ret = fwnode_property_read_u32(dev_fwnode(dev), "rotation",
> + &rotation);
> + if (!ret) {
> + switch (rotation) {
> + case 180:
> + ov02a10->upside_down = true;
> + ov02a10->fmt.code = MEDIA_BUS_FMT_SRGGB10_1X10;
> + break;
> + case 0:
> + break;
> + default:
> + dev_warn(dev, "%u degrees rotation is not supported, ignoring...\n",
> + rotation);
> + }
> + }
> +
Please also check that the link frequencies in DT match with what the
driver expects. See e.g. drivers/media/i2c/ov8856.c driver for an example.
> + /* Get system clock (xvclk) */
> + ov02a10->xvclk = devm_clk_get(dev, "xvclk");
> + if (IS_ERR(ov02a10->xvclk)) {
> + dev_err(dev, "Failed to get xvclk\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32(dev->of_node, "clock-frequency", &xclk_freq);
> + if (ret) {
> + dev_err(dev, "Failed to get xclk frequency\n");
> + return ret;
> + }
> +
> + /* External clock must be 24MHz, allow 1% tolerance */
> + if (xclk_freq < 23760000 || xclk_freq > 24240000) {
> + dev_err(dev, "external clock frequency %u is not supported\n",
> + xclk_freq);
> + return -EINVAL;
> + }
> + dev_dbg(dev, "external clock frequency %u\n", xclk_freq);
> +
> + ret = clk_set_rate(ov02a10->xvclk, xclk_freq);
> + if (ret) {
> + dev_err(dev, "Failed to set xvclk frequency (24MHz)\n");
> + return ret;
> + }
> +
> + ov02a10->powerdown_gpio = devm_gpiod_get(dev, "powerdown",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(ov02a10->powerdown_gpio)) {
> + dev_err(dev, "Failed to get powerdown-gpios\n");
> + return -EINVAL;
> + }
> +
> + ov02a10->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ov02a10->reset_gpio)) {
> + dev_err(dev, "Failed to get reset-gpios\n");
> + return -EINVAL;
> + }
> +
> + ret = ov02a10_configure_regulators(ov02a10);
> + if (ret) {
> + dev_err(dev, "Failed to get power regulators\n");
> + return ret;
> + }
> +
> + mutex_init(&ov02a10->mutex);
> + ov02a10->cur_mode = &supported_modes[0];
> + ret = ov02a10_initialize_controls(ov02a10);
> + if (ret) {
> + dev_err(dev, "Failed to initialize controls\n");
> + goto err_destroy_mutex;
> + }
> +
> + ret = __ov02a10_power_on(ov02a10);
> + if (ret)
> + goto err_free_handler;
> +
> + ret = ov02a10_check_sensor_id(ov02a10);
> + if (ret)
> + goto err_power_off;
> +
> + ov02a10->subdev.internal_ops = &ov02a10_internal_ops;
> + ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> + ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
> + ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> + ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
> + ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
> + if (ret < 0) {
> + dev_err(dev, "failed to init entity pads: %d", ret);
> + goto err_power_off;
> + }
> +
> + ret = v4l2_async_register_subdev(&ov02a10->subdev);
> + if (ret) {
> + dev_err(dev, "failed to register V4L2 subdev: %d",
> + ret);
> + goto err_clean_entity;
> + }
> +
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> + pm_runtime_idle(dev);
> +
> + dev_info(dev, "ov02a10 probe --\n");
This isn't very informative. The driver already prints errors when probing
fails and otherwise it succeeds. Please remove.
> + return 0;
> +
> +err_clean_entity:
> + media_entity_cleanup(&ov02a10->subdev.entity);
> +err_power_off:
> + __ov02a10_power_off(ov02a10);
> +err_free_handler:
> + v4l2_ctrl_handler_free(ov02a10->subdev.ctrl_handler);
> +err_destroy_mutex:
> + mutex_destroy(&ov02a10->mutex);
> +
> + return ret;
> +}
> +
> +static int ov02a10_remove(struct i2c_client *client)
> +{
> + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> + struct ov02a10 *ov02a10 = to_ov02a10(sd);
> +
> + v4l2_async_unregister_subdev(sd);
> + media_entity_cleanup(&sd->entity);
> + v4l2_ctrl_handler_free(sd->ctrl_handler);
> + pm_runtime_disable(&client->dev);
> + if (!pm_runtime_status_suspended(&client->dev))
> + __ov02a10_power_off(ov02a10);
> + pm_runtime_set_suspended(&client->dev);
> + mutex_destroy(&ov02a10->mutex);
> +
> + return 0;
> +}
> +
> +#if IS_ENABLED(CONFIG_OF)
> +static const struct of_device_id ov02a10_of_match[] = {
> + { .compatible = "ovti,ov02a10" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ov02a10_of_match);
> +#endif
> +
> +static struct i2c_driver ov02a10_i2c_driver = {
> + .driver = {
> + .name = "ov02a10",
> + .pm = &ov02a10_pm_ops,
> + .of_match_table = ov02a10_of_match,
> + },
> + .probe_new = &ov02a10_probe,
> + .remove = &ov02a10_remove,
> +};
> +
> +module_i2c_driver(ov02a10_i2c_driver);
> +
> +MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
> +MODULE_DESCRIPTION("OmniVision OV02A10 sensor driver");
> +MODULE_LICENSE("GPL v2");
--
Kind regards,
Sakari Ailus
sakari.ailus@linux.intel.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 v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-08-19 8:33 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mark Rutland, Biwen Li, Len Brown, Greg Kroah-Hartman,
linux-pm@vger.kernel.org, Rafael J. Wysocki,
linux-kernel@vger.kernel.org, Leo Li, devicetree@vger.kernel.org,
Rob Herring, Pavel Machek, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAJZ5v0i58p-GsswzMGEsgD5OXDqJ_G5zXDYf8jq8JJbWxZv+nQ@mail.gmail.com>
Hi Rafael,
On Monday, August 19, 2019 16:20, Rafael J. Wysocki wrote:
>
> On Mon, Aug 19, 2019 at 10:15 AM Ran Wang <ran.wang_1@nxp.com> wrote:
> >
> > Hi Rafael,
> >
> > On Monday, August 05, 2019 17:59, Rafael J. Wysocki wrote:
> > >
> > > On Wednesday, July 24, 2019 9:47:20 AM CEST Ran Wang wrote:
> > > > Some user might want to go through all registered wakeup sources
> > > > and doing things accordingly. For example, SoC PM driver might
> > > > need to do HW programming to prevent powering down specific IP
> > > > which wakeup source depending on. So add this API to help walk
> > > > through all registered wakeup source objects on that list and return them
> one by one.
> > > >
> > > > Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> > > > ---
> > > > Change in v5:
> > > > - Update commit message, add decription of walk through all wakeup
> > > > source objects.
> > > > - Add SCU protection in function wakeup_source_get_next().
> > > > - Rename wakeup_source member 'attached_dev' to 'dev' and move
> > > > it
> > > up
> > > > (before wakeirq).
> > > >
> > > > Change in v4:
> > > > - None.
> > > >
> > > > Change in v3:
> > > > - Adjust indentation of *attached_dev;.
> > > >
> > > > Change in v2:
> > > > - None.
> > > >
> > > > drivers/base/power/wakeup.c | 24 ++++++++++++++++++++++++
> > > > include/linux/pm_wakeup.h | 3 +++
> > > > 2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/drivers/base/power/wakeup.c
> > > > b/drivers/base/power/wakeup.c index ee31d4f..2fba891 100644
> > > > --- a/drivers/base/power/wakeup.c
> > > > +++ b/drivers/base/power/wakeup.c
> > > > @@ -14,6 +14,7 @@
> > > > #include <linux/suspend.h>
> > > > #include <linux/seq_file.h>
> > > > #include <linux/debugfs.h>
> > > > +#include <linux/of_device.h>
> > > > #include <linux/pm_wakeirq.h>
> > > > #include <trace/events/power.h>
> > > >
> > > > @@ -226,6 +227,28 @@ void wakeup_source_unregister(struct
> > > wakeup_source *ws)
> > > > }
> > > > }
> > > > EXPORT_SYMBOL_GPL(wakeup_source_unregister);
> > > > +/**
> > > > + * wakeup_source_get_next - Get next wakeup source from the list
> > > > + * @ws: Previous wakeup source object, null means caller want first one.
> > > > + */
> > > > +struct wakeup_source *wakeup_source_get_next(struct wakeup_source
> > > > +*ws) {
> > > > + struct list_head *ws_head = &wakeup_sources;
> > > > + struct wakeup_source *next_ws = NULL;
> > > > + int idx;
> > > > +
> > > > + idx = srcu_read_lock(&wakeup_srcu);
> > > > + if (ws)
> > > > + next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
> > > > + struct wakeup_source, entry);
> > > > + else
> > > > + next_ws = list_entry_rcu(ws_head->next,
> > > > + struct wakeup_source, entry);
> > > > + srcu_read_unlock(&wakeup_srcu, idx);
> > > > +
> > >
> > > This is incorrect.
> > >
> > > The SRCU cannot be unlocked until the caller of this is done with
> > > the object returned by it, or that object can be freed while it is still being
> accessed.
> >
> > Thanks for the comment. Looks like I was not fully understanding your
> > point on
> > v4 discussion. So I will implement 3 APIs by referring
> > wakeup_sources_stats_seq_start/next/stop()
> >
> > > Besides, this patch conflicts with some general wakeup sources
> > > changes in the works, so it needs to be deferred and rebased on top of those
> changes.
> >
> > Could you please tell me which is the right code base I should developing on?
> > I just tried applying v5 patch on latest
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git branch master
> (d1abaeb Linux 5.3-rc5) and no conflict encountered.
>
> It is better to use the most recent -rc from Linus (5.3-rc5 as of
> today) as the base unless your patches depend on some changes that are not in
> there.
OK, So I need to implement on latest git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git branch master, am I right?
However, I just checked v5.3-rc5 code and found it has the same HEAD (d1abaeb Linux 5.3-rc5
on which I did not observe v5 patch apply conflict, did I miss something? Thanks.
Regards,
Ran
_______________________________________________
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 RESEND V2 3/7] cpufreq: Use imx-cpufreq-dt for i.MX8MN's speed grading
From: Viresh Kumar @ 2019-08-19 8:37 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd, shawnguo,
s.hauer, rjw, linux-kernel, linux-clk, robh+dt, Linux-imx, kernel,
leonard.crestez, festevam, mturquette, linux-arm-kernel
In-Reply-To: <1566109945-11149-3-git-send-email-Anson.Huang@nxp.com>
On 18-08-19, 02:32, Anson Huang wrote:
> Add i.MX8MN to blacklist, so that imx-cpufreq-dt driver can handle
> speed grading bits just like other i.MX8M SoCs.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> No changes.
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index ec2057d..febcec8 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -109,6 +109,7 @@ static const struct of_device_id blacklist[] __initconst = {
> { .compatible = "fsl,imx7d", },
> { .compatible = "fsl,imx8mq", },
> { .compatible = "fsl,imx8mm", },
> + { .compatible = "fsl,imx8mn", },
>
> { .compatible = "marvell,armadaxp", },
>
Applied. Thanks.
--
viresh
_______________________________________________
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 RESEND V2 4/7] cpufreq: imx-cpufreq-dt: Add i.MX8MN support
From: Viresh Kumar @ 2019-08-19 8:37 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd, shawnguo,
s.hauer, rjw, linux-kernel, linux-clk, robh+dt, Linux-imx, kernel,
leonard.crestez, festevam, mturquette, linux-arm-kernel
In-Reply-To: <1566109945-11149-4-git-send-email-Anson.Huang@nxp.com>
On 18-08-19, 02:32, Anson Huang wrote:
> i.MX8MN has different speed grading definition as below, it has 4 bits
> to define speed grading, add support for it.
>
> SPEED_GRADE[3:0] MHz
> 0000 2300
> 0001 2200
> 0010 2100
> 0011 2000
> 0100 1900
> 0101 1800
> 0110 1700
> 0111 1600
> 1000 1500
> 1001 1400
> 1010 1300
> 1011 1200
> 1100 1100
> 1101 1000
> 1110 900
> 1111 800
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> No changes.
> ---
> drivers/cpufreq/imx-cpufreq-dt.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Applied. Thanks.
--
viresh
_______________________________________________
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 13/19] dt-bindings: phy: Add Marvell COMPHY clocks
From: Miquel Raynal @ 2019-08-19 8:40 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Lunn, Jason Cooper, devicetree, Antoine Tenart,
Grzegorz Jaszczyk, Gregory Clement, Russell King,
Kishon Vijay Abraham I, Nadav Haklai, Thomas Petazzoni,
Maxime Chevallier, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190812212946.GA6120@bogus>
Hi Rob,
Rob Herring <robh@kernel.org> wrote on Mon, 12 Aug 2019 15:29:46 -0600:
> On Wed, 31 Jul 2019 14:21:20 +0200, Miquel Raynal wrote:
> > Marvell CP110 COMPHY block is fed by 3 clocks. Describe each of them in the
> > bindings.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > .../devicetree/bindings/phy/phy-mvebu-comphy.txt | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
>
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
>
> If a tag was not added on purpose, please state why and what changed.
Oops, I know I know, I just forgot to add manually your Reviewed-by.
If the maintainers can add it manually it's great; avoiding to resend
19 patches for that sounds sane :)
Thanks,
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 2/4] media: stm32-dcmi: trace the supported fourcc/mbus_code
From: Hugues Fruchet @ 2019-08-19 8:41 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1566204081-19051-1-git-send-email-hugues.fruchet@st.com>
Add a trace of the set of supported fourcc/mbus_code which
intersect between DCMI and source sub-device.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b462f71..db01210 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -1447,12 +1447,21 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
/* Code supported, have we got this fourcc yet? */
for (j = 0; j < num_fmts; j++)
if (sd_fmts[j]->fourcc ==
- dcmi_formats[i].fourcc)
+ dcmi_formats[i].fourcc) {
/* Already available */
+ dev_dbg(dcmi->dev, "Skipping fourcc/code: %4.4s/0x%x\n",
+ (char *)&sd_fmts[j]->fourcc,
+ mbus_code.code);
break;
- if (j == num_fmts)
+ }
+ if (j == num_fmts) {
/* New */
sd_fmts[num_fmts++] = dcmi_formats + i;
+ dev_dbg(dcmi->dev,
+ "Supported fourcc/code: %4.4s/0x%x\n",
+ (char *)&sd_fmts[num_fmts - 1]->fourcc,
+ sd_fmts[num_fmts - 1]->mbus_code);
+ }
}
mbus_code.index++;
}
--
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
* [PATCH v7 0/4] DCMI bridge support
From: Hugues Fruchet @ 2019-08-19 8:41 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
This patch serie allows to connect non-parallel camera sensor to
DCMI thanks to a bridge connected in between such as STMIPID02 [1].
Media controller support is introduced first, then support of
several sub-devices within pipeline with dynamic linking
between them.
In order to keep backward compatibility with applications
relying on V4L2 interface only, format set on video node
is propagated to all sub-devices connected to camera interface.
[1] https://www.spinics.net/lists/devicetree/msg278002.html
===========
= history =
===========
version 7:
- minor fix on 80 char trace message
version 6:
- As per Sakari remark: add a FIXME explaining that this
version only supports subdevices which expose RGB & YUV
"parallel form" mbus code (_2X8)
- Add some trace around subdev_call(s_fmt) error & format
changes to debug subdev which only expose serial mbus code
- Conform to "<name>":<pad index> when tracing subdev infos
version 5:
- Remove remaining Change-Id
- Add Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
version 4:
- Also drop subdev nodes registry as suggested by Hans:
https://www.spinics.net/lists/arm-kernel/msg743375.html
version 3:
- Drop media device registry to not expose media controller
interface to userspace as per Laurent' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
- Prefer "source" instead of "sensor" and keep it in
dcmi_graph_entity struct, move asd as first member
of struct as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153119.html
- Drop dcmi_graph_deinit() as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
version 2:
- Fix bus_info not consistent between media and V4L:
https://www.spinics.net/lists/arm-kernel/msg717676.html
- Propagation of format set on video node to the sub-devices
chain connected on camera interface
version 1:
- Initial submission
Hugues Fruchet (4):
media: stm32-dcmi: improve sensor subdev naming
media: stm32-dcmi: trace the supported fourcc/mbus_code
media: stm32-dcmi: add media controller support
media: stm32-dcmi: add support of several sub-devices
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 318 +++++++++++++++++++++++++-----
2 files changed, 268 insertions(+), 52 deletions(-)
--
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
* [PATCH v7 3/4] media: stm32-dcmi: add media controller support
From: Hugues Fruchet @ 2019-08-19 8:41 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1566204081-19051-1-git-send-email-hugues.fruchet@st.com>
Add media controller support to dcmi in order
to walk within remote subdevices pipeline.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 52 ++++++++++++++++++++++++-------
2 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8a19654..de7e21f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -121,7 +121,7 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF
+ depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index db01210..9293949 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -169,6 +169,9 @@ struct stm32_dcmi {
/* Ensure DMA operations atomicity */
struct mutex dma_lock;
+
+ struct media_device mdev;
+ struct media_pad vid_cap_pad;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -1560,14 +1563,6 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
return ret;
}
- ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
- if (ret) {
- dev_err(dcmi->dev, "Failed to register video device\n");
- return ret;
- }
-
- dev_dbg(dcmi->dev, "Device registered as %s\n",
- video_device_node_name(dcmi->vdev));
return 0;
}
@@ -1760,10 +1755,19 @@ static int dcmi_probe(struct platform_device *pdev)
q = &dcmi->queue;
+ dcmi->v4l2_dev.mdev = &dcmi->mdev;
+
+ /* Initialize media device */
+ strscpy(dcmi->mdev.model, DRV_NAME, sizeof(dcmi->mdev.model));
+ snprintf(dcmi->mdev.bus_info, sizeof(dcmi->mdev.bus_info),
+ "platform:%s", DRV_NAME);
+ dcmi->mdev.dev = &pdev->dev;
+ media_device_init(&dcmi->mdev);
+
/* Initialize the top-level structure */
ret = v4l2_device_register(&pdev->dev, &dcmi->v4l2_dev);
if (ret)
- goto err_dma_release;
+ goto err_media_device_cleanup;
dcmi->vdev = video_device_alloc();
if (!dcmi->vdev) {
@@ -1783,6 +1787,25 @@ static int dcmi_probe(struct platform_device *pdev)
V4L2_CAP_READWRITE;
video_set_drvdata(dcmi->vdev, dcmi);
+ /* Media entity pads */
+ dcmi->vid_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&dcmi->vdev->entity,
+ 1, &dcmi->vid_cap_pad);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to init media entity pad\n");
+ goto err_device_release;
+ }
+ dcmi->vdev->entity.flags |= MEDIA_ENT_FL_DEFAULT;
+
+ ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to register video device\n");
+ goto err_media_entity_cleanup;
+ }
+
+ dev_dbg(dcmi->dev, "Device registered as %s\n",
+ video_device_node_name(dcmi->vdev));
+
/* Buffer queue */
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_READ | VB2_DMABUF;
@@ -1798,12 +1821,12 @@ static int dcmi_probe(struct platform_device *pdev)
ret = vb2_queue_init(q);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to initialize vb2 queue\n");
- goto err_device_release;
+ goto err_media_entity_cleanup;
}
ret = dcmi_graph_init(dcmi);
if (ret < 0)
- goto err_device_release;
+ goto err_media_entity_cleanup;
/* Reset device */
ret = reset_control_assert(dcmi->rstc);
@@ -1830,11 +1853,14 @@ static int dcmi_probe(struct platform_device *pdev)
err_cleanup:
v4l2_async_notifier_cleanup(&dcmi->notifier);
+err_media_entity_cleanup:
+ media_entity_cleanup(&dcmi->vdev->entity);
err_device_release:
video_device_release(dcmi->vdev);
err_device_unregister:
v4l2_device_unregister(&dcmi->v4l2_dev);
-err_dma_release:
+err_media_device_cleanup:
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
return ret;
@@ -1848,7 +1874,9 @@ static int dcmi_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_async_notifier_cleanup(&dcmi->notifier);
+ media_entity_cleanup(&dcmi->vdev->entity);
v4l2_device_unregister(&dcmi->v4l2_dev);
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
--
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
* [PATCH v7 4/4] media: stm32-dcmi: add support of several sub-devices
From: Hugues Fruchet @ 2019-08-19 8:41 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1566204081-19051-1-git-send-email-hugues.fruchet@st.com>
Add support of several sub-devices within pipeline instead
of a single one.
This allows to support a CSI-2 camera sensor connected
through a CSI-2 to parallel bridge.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 217 +++++++++++++++++++++++++++---
1 file changed, 198 insertions(+), 19 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index 9293949..5bfbc07 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -172,6 +172,7 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
+ struct media_pipeline pipeline;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -583,6 +584,144 @@ static void dcmi_buf_queue(struct vb2_buffer *vb)
spin_unlock_irq(&dcmi->irqlock);
}
+static struct media_entity *dcmi_find_source(struct stm32_dcmi *dcmi)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct media_pad *pad;
+
+ /* Walk searching for entity having no sink */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ }
+
+ return entity;
+}
+
+static int dcmi_pipeline_s_fmt(struct stm32_dcmi *dcmi,
+ struct v4l2_subdev_pad_config *pad_cfg,
+ struct v4l2_subdev_format *format)
+{
+ struct media_entity *entity = &dcmi->entity.source->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *sink_pad = NULL;
+ struct media_pad *src_pad = NULL;
+ struct media_pad *pad = NULL;
+ struct v4l2_subdev_format fmt = *format;
+ bool found = false;
+ int ret;
+
+ /*
+ * Starting from sensor subdevice, walk within
+ * pipeline and set format on each subdevice
+ */
+ while (1) {
+ unsigned int i;
+
+ /* Search if current entity has a source pad */
+ for (i = 0; i < entity->num_pads; i++) {
+ pad = &entity->pads[i];
+ if (pad->flags & MEDIA_PAD_FL_SOURCE) {
+ src_pad = pad;
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ break;
+
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ /* Propagate format on sink pad if any, otherwise source pad */
+ if (sink_pad)
+ pad = sink_pad;
+
+ dev_dbg(dcmi->dev, "\"%s\":%d pad format set to 0x%x %ux%u\n",
+ subdev->name, pad->index, format->format.code,
+ format->format.width, format->format.height);
+
+ fmt.pad = pad->index;
+ ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
+ if (ret < 0) {
+ dev_err(dcmi->dev, "%s: Failed to set format 0x%x %ux%u on \"%s\":%d pad (%d)\n",
+ __func__, format->format.code,
+ format->format.width, format->format.height,
+ subdev->name, pad->index, ret);
+ return ret;
+ }
+
+ if (fmt.format.code != format->format.code ||
+ fmt.format.width != format->format.width ||
+ fmt.format.height != format->format.height) {
+ dev_dbg(dcmi->dev, "\"%s\":%d pad format has been changed to 0x%x %ux%u\n",
+ subdev->name, pad->index, fmt.format.code,
+ fmt.format.width, fmt.format.height);
+ }
+
+ /* Walk to next entity */
+ sink_pad = media_entity_remote_pad(src_pad);
+ if (!sink_pad || !is_media_entity_v4l2_subdev(sink_pad->entity))
+ break;
+
+ entity = sink_pad->entity;
+ }
+ *format = fmt;
+
+ return 0;
+}
+
+static int dcmi_pipeline_s_stream(struct stm32_dcmi *dcmi, int state)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *pad;
+ int ret;
+
+ /* Start/stop all entities within pipeline */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ ret = v4l2_subdev_call(subdev, video, s_stream, state);
+ if (ret < 0 && ret != -ENOIOCTLCMD) {
+ dev_err(dcmi->dev, "%s: \"%s\" failed to %s streaming (%d)\n",
+ __func__, subdev->name,
+ state ? "start" : "stop", ret);
+ return ret;
+ }
+
+ dev_dbg(dcmi->dev, "\"%s\" is %s\n",
+ subdev->name, state ? "started" : "stopped");
+ }
+
+ return 0;
+}
+
+static int dcmi_pipeline_start(struct stm32_dcmi *dcmi)
+{
+ return dcmi_pipeline_s_stream(dcmi, 1);
+}
+
+static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
+{
+ dcmi_pipeline_s_stream(dcmi, 0);
+}
+
static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
@@ -597,14 +736,17 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
goto err_release_buffers;
}
- /* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
- if (ret && ret != -ENOIOCTLCMD) {
- dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
- __func__);
+ ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
+ if (ret < 0) {
+ dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
+ __func__, ret);
goto err_pm_put;
}
+ ret = dcmi_pipeline_start(dcmi);
+ if (ret)
+ goto err_media_pipeline_stop;
+
spin_lock_irq(&dcmi->irqlock);
/* Set bus width */
@@ -676,7 +818,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
if (ret) {
dev_err(dcmi->dev, "%s: Start streaming failed, cannot start capture\n",
__func__);
- goto err_subdev_streamoff;
+ goto err_pipeline_stop;
}
/* Enable interruptions */
@@ -687,8 +829,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
-err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
+err_pipeline_stop:
+ dcmi_pipeline_stop(dcmi);
+
+err_media_pipeline_stop:
+ media_pipeline_stop(&dcmi->vdev->entity);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,13 +858,10 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
struct dcmi_buf *buf, *node;
- int ret;
- /* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
- if (ret && ret != -ENOIOCTLCMD)
- dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
- __func__, ret);
+ dcmi_pipeline_stop(dcmi);
+
+ media_pipeline_stop(&dcmi->vdev->entity);
spin_lock_irq(&dcmi->irqlock);
@@ -937,8 +1079,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.source, pad,
- set_fmt, NULL, &format);
+ ret = dcmi_pipeline_s_fmt(dcmi, NULL, &format);
if (ret < 0)
return ret;
@@ -1412,6 +1553,12 @@ static int dcmi_set_default_fmt(struct stm32_dcmi *dcmi)
return 0;
}
+/*
+ * FIXME: For the time being we only support subdevices
+ * which expose RGB & YUV "parallel form" mbus code (_2X8).
+ * Nevertheless, this allows to support serial source subdevices
+ * and serial to parallel bridges which conform to this.
+ */
static const struct dcmi_format dcmi_formats[] = {
{
.fourcc = V4L2_PIX_FMT_RGB565,
@@ -1538,7 +1685,20 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
+ /*
+ * Now that the graph is complete,
+ * we search for the source subdevice
+ * in order to expose it through V4L2 interface
+ */
+ dcmi->entity.source =
+ media_entity_to_v4l2_subdev(dcmi_find_source(dcmi));
+ if (!dcmi->entity.source) {
+ dev_err(dcmi->dev, "Source subdevice not found\n");
+ return -ENODEV;
+ }
+
dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
+
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1583,12 +1743,31 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
struct v4l2_async_subdev *asd)
{
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
+ unsigned int ret;
+ int src_pad;
- dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
+ dev_dbg(dcmi->dev, "Subdev \"%s\" bound\n", subdev->name);
- dcmi->entity.source = subdev;
+ /*
+ * Link this sub-device to DCMI, it could be
+ * a parallel camera sensor or a bridge
+ */
+ src_pad = media_entity_get_fwnode_pad(&subdev->entity,
+ subdev->fwnode,
+ MEDIA_PAD_FL_SOURCE);
+
+ ret = media_create_pad_link(&subdev->entity, src_pad,
+ &dcmi->vdev->entity, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ dev_err(dcmi->dev, "Failed to create media pad link with subdev \"%s\"\n",
+ subdev->name);
+ else
+ dev_dbg(dcmi->dev, "DCMI is now linked to \"%s\"\n",
+ subdev->name);
- return 0;
+ return ret;
}
static const struct v4l2_async_notifier_operations dcmi_graph_notify_ops = {
--
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
* [PATCH v7 1/4] media: stm32-dcmi: improve sensor subdev naming
From: Hugues Fruchet @ 2019-08-19 8:41 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1566204081-19051-1-git-send-email-hugues.fruchet@st.com>
Rename "subdev" entity struct field to "source"
to prepare for several subdev support.
Move asd field on top of entity struct.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 46 +++++++++++++++----------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b9dad0a..b462f71 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -100,10 +100,10 @@ enum state {
#define OVERRUN_ERROR_THRESHOLD 3
struct dcmi_graph_entity {
- struct device_node *node;
-
struct v4l2_async_subdev asd;
- struct v4l2_subdev *subdev;
+
+ struct device_node *remote_node;
+ struct v4l2_subdev *source;
};
struct dcmi_format {
@@ -595,7 +595,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
}
/* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD) {
dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
__func__);
@@ -685,7 +685,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,7 +713,7 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
int ret;
/* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
if (ret && ret != -ENOIOCTLCMD)
dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
__func__, ret);
@@ -857,7 +857,7 @@ static int dcmi_try_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -934,7 +934,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
set_fmt, NULL, &format);
if (ret < 0)
return ret;
@@ -991,7 +991,7 @@ static int dcmi_get_sensor_format(struct stm32_dcmi *dcmi,
};
int ret;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_fmt, NULL, &fmt);
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_fmt, NULL, &fmt);
if (ret)
return ret;
@@ -1020,7 +1020,7 @@ static int dcmi_set_sensor_format(struct stm32_dcmi *dcmi,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -1043,7 +1043,7 @@ static int dcmi_get_sensor_bounds(struct stm32_dcmi *dcmi,
/*
* Get sensor bounds first
*/
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_selection,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_selection,
NULL, &bounds);
if (!ret)
*r = bounds.r;
@@ -1224,7 +1224,7 @@ static int dcmi_enum_framesizes(struct file *file, void *fh,
fse.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, enum_frame_size,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, enum_frame_size,
NULL, &fse);
if (ret)
return ret;
@@ -1241,7 +1241,7 @@ static int dcmi_g_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_s_parm(struct file *file, void *priv,
@@ -1249,7 +1249,7 @@ static int dcmi_s_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_enum_frameintervals(struct file *file, void *fh,
@@ -1271,7 +1271,7 @@ static int dcmi_enum_frameintervals(struct file *file, void *fh,
fie.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
enum_frame_interval, NULL, &fie);
if (ret)
return ret;
@@ -1291,7 +1291,7 @@ MODULE_DEVICE_TABLE(of, stm32_dcmi_of_match);
static int dcmi_open(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
int ret;
if (mutex_lock_interruptible(&dcmi->lock))
@@ -1322,7 +1322,7 @@ static int dcmi_open(struct file *file)
static int dcmi_release(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
bool fh_singular;
int ret;
@@ -1433,7 +1433,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
{
const struct dcmi_format *sd_fmts[ARRAY_SIZE(dcmi_formats)];
unsigned int num_fmts = 0, i, j;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_mbus_code_enum mbus_code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
@@ -1479,7 +1479,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
static int dcmi_framesizes_init(struct stm32_dcmi *dcmi)
{
unsigned int num_fsize = 0;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_frame_size_enum fse = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
.code = dcmi->sd_format->mbus_code,
@@ -1526,7 +1526,7 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
- dcmi->vdev->ctrl_handler = dcmi->entity.subdev->ctrl_handler;
+ dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1582,7 +1582,7 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
- dcmi->entity.subdev = subdev;
+ dcmi->entity.source = subdev;
return 0;
}
@@ -1608,7 +1608,7 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
return -EINVAL;
/* Remote node to connect */
- dcmi->entity.node = remote;
+ dcmi->entity.remote_node = remote;
dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
@@ -1631,7 +1631,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
&dcmi->entity.asd);
if (ret) {
dev_err(dcmi->dev, "Failed to add subdev notifier\n");
- of_node_put(dcmi->entity.node);
+ of_node_put(dcmi->entity.remote_node);
return ret;
}
--
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: Best representation for TDM devices
From: Maxime Ripard @ 2019-08-19 8:41 UTC (permalink / raw)
To: Mark Brown; +Cc: Ali Burak Parım, linux-arm-kernel
In-Reply-To: <20190814160234.GG4640@sirena.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 2015 bytes --]
Hi Mark,
On Wed, Aug 14, 2019 at 05:02:34PM +0100, Mark Brown wrote:
> On Wed, Aug 14, 2019 at 12:53:24PM +0200, Ali Burak Parım wrote:
> > On Thu, 1 Aug 2019 at 13:48, Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Aug 01, 2019 at 01:43:06PM +0200, Ali Burak Parım wrote:
> > > > On Thu, Jul 25, 2019 at 03:01:12PM +0200, Maxime Ripard wrote:
>
> > > > Hardware is a custom board I designed with 4 PDM output microphones
> > > > and 2 adau7002 devices as the codec for PDM-to-PCM. We want to do
> > > > signal processing with this board. Therefore having separate streams for
> > > > each microphone is crucial to the application though I am not sure where
> > > > we should implement this exactly.
>
> > > What is this processing - are the streams from these microphones
> > > logically related in any way (eg, is this a microphone array)? There's
>
> > Yes, it is a microphone array application for speech enhancement. Thus,
> > signal levels and physical time delays are important.
>
> > > probably going to be some overlap in the input signals at least. If you
> > > need to for example correlate different microphones then that's
> > > relevant.
>
> > Yes, we correlate different microphone signals in some of our algorithms.
>
> OK, in that case I'd recommend providing them to userspace as a single
> four channel stream - keeping everything bundled together as long as
> possible to make it easier to keep the processing synced up.
Ok, that's what I had in mind as well :)
However, it looks like we can only capture as many channels as the max
being exposed by the codec on the link?
Any attempt at capturing something with 4 channels here using arecord
was either reduced to two channels (the amount of channels provided by
the adau7002 driver), or just refused by the ALSA core.
Is there anything that we need to configure / work on to enable this?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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 v7 0/4] DCMI bridge support
From: Hans Verkuil @ 2019-08-19 8:43 UTC (permalink / raw)
To: Hugues Fruchet, Alexandre Torgue, Mauro Carvalho Chehab,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, linux-stm32, linux-arm-kernel, linux-media
In-Reply-To: <1566204081-19051-1-git-send-email-hugues.fruchet@st.com>
On 8/19/19 10:41 AM, Hugues Fruchet wrote:
> This patch serie allows to connect non-parallel camera sensor to
> DCMI thanks to a bridge connected in between such as STMIPID02 [1].
>
> Media controller support is introduced first, then support of
> several sub-devices within pipeline with dynamic linking
> between them.
> In order to keep backward compatibility with applications
> relying on V4L2 interface only, format set on video node
> is propagated to all sub-devices connected to camera interface.
>
> [1] https://www.spinics.net/lists/devicetree/msg278002.html
>
> ===========
> = history =
> ===========
> version 7:
> - minor fix on 80 char trace message
v6 is already in a pending PR. I don't really want to make a new
PR just for a 80 char warning.
It can always be done in a follow-up patch.
Regards,
Hans
>
> version 6:
> - As per Sakari remark: add a FIXME explaining that this
> version only supports subdevices which expose RGB & YUV
> "parallel form" mbus code (_2X8)
> - Add some trace around subdev_call(s_fmt) error & format
> changes to debug subdev which only expose serial mbus code
> - Conform to "<name>":<pad index> when tracing subdev infos
>
> version 5:
> - Remove remaining Change-Id
> - Add Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>
> version 4:
> - Also drop subdev nodes registry as suggested by Hans:
> https://www.spinics.net/lists/arm-kernel/msg743375.html
>
> version 3:
> - Drop media device registry to not expose media controller
> interface to userspace as per Laurent' suggestion:
> https://www.spinics.net/lists/linux-media/msg153417.html
> - Prefer "source" instead of "sensor" and keep it in
> dcmi_graph_entity struct, move asd as first member
> of struct as per Sakari' suggestion:
> https://www.spinics.net/lists/linux-media/msg153119.html
> - Drop dcmi_graph_deinit() as per Sakari' suggestion:
> https://www.spinics.net/lists/linux-media/msg153417.html
>
> version 2:
> - Fix bus_info not consistent between media and V4L:
> https://www.spinics.net/lists/arm-kernel/msg717676.html
> - Propagation of format set on video node to the sub-devices
> chain connected on camera interface
>
> version 1:
> - Initial submission
>
> Hugues Fruchet (4):
> media: stm32-dcmi: improve sensor subdev naming
> media: stm32-dcmi: trace the supported fourcc/mbus_code
> media: stm32-dcmi: add media controller support
> media: stm32-dcmi: add support of several sub-devices
>
> drivers/media/platform/Kconfig | 2 +-
> drivers/media/platform/stm32/stm32-dcmi.c | 318 +++++++++++++++++++++++++-----
> 2 files changed, 268 insertions(+), 52 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] soc: ixp4xx: Protect IXP4xx SoC drivers by ARCH_IXP4XX || COMPILE_TEST
From: Geert Uytterhoeven @ 2019-08-19 8:00 UTC (permalink / raw)
To: Linus Walleij, Imre Kaloz, Krzysztof Halasa
Cc: Geert Uytterhoeven, linux-arm-kernel, Arnd Bergmann, linux-kernel
The move of the IXP4xx SoC drivers exposed their config options on all
platforms.
Fix this by wrapping them inside an ARCH_IXP4XX or COMPILE_TEST block.
Fixes: fcf2d8978cd538a5 ("ARM: ixp4xx: Move NPE and QMGR to drivers/soc")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
v2:
- Rebased on top of commit ec8f24b7faaf3d47 ("treewide: Add SPDX
license identifier - Makefile/Kconfig").
---
drivers/soc/ixp4xx/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/soc/ixp4xx/Kconfig b/drivers/soc/ixp4xx/Kconfig
index de2e62c3310a37d0..e3eb19b85fa4b358 100644
--- a/drivers/soc/ixp4xx/Kconfig
+++ b/drivers/soc/ixp4xx/Kconfig
@@ -1,4 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
+if ARCH_IXP4XX || COMPILE_TEST
+
menu "IXP4xx SoC drivers"
config IXP4XX_QMGR
@@ -15,3 +17,5 @@ config IXP4XX_NPE
and is automatically selected by Ethernet and HSS drivers.
endmenu
+
+endif
--
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
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