* [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
* Re: [PATCH] KVM: arm/arm64: vgic: Allow more than 256 vcpus for KVM_IRQ_LINE
From: Marc Zyngier @ 2019-08-19 8:46 UTC (permalink / raw)
To: Will Deacon
Cc: Peter Maydell, kvm, Suzuki K Poulose, qemu-arm, James Morse,
linux-arm-kernel, Zenghui Yu, kvmarm, Julien Thierry
In-Reply-To: <20190819074150.jv3dyyxqazoawgds@willie-the-truck>
On 19/08/2019 08:41, Will Deacon wrote:
> On Sun, Aug 18, 2019 at 03:07:10PM +0100, Marc Zyngier wrote:
>> While parts of the VGIC support a large number of vcpus (we
>> bravely allow up to 512), other parts are more limited.
>>
>> One of these limits is visible in the KVM_IRQ_LINE ioctl, which
>> only allows 256 vcpus to be signalled when using the CPU or PPI
>> types. Unfortunately, we've cornered ourselves badly by allocating
>> all the bits in the irq field.
>>
>> Since the irq_type subfield (8 bit wide) is currently only taking
>> the values 0, 1 and 2 (and we have been careful not to allow anything
>> else), let's reduce this field to only 4 bits, and allocate the
>> remaining 4 bits to a vcpu2_index, which acts as a multiplier:
>>
>> vcpu_id = 256 * vcpu2_index + vcpu_index
>>
>> With that, and a new capability (KVM_CAP_ARM_IRQ_LINE_LAYOUT_2)
>> allowing this to be discovered, it becomes possible to inject
>> PPIs to up to 4096 vcpus. But please just don't.
>
> Do you actually need a new capability for this? Older kernels reject
> non-zero upper bits in the 'irq_type', so isn't that enough to probe
> for this directly?
'Probing' is a bit of an overstatement. You'll get an error back when
userspace will try to inject a PPI into a vcpu whose ID is in the new
range. But nothing at VM creation time will indicate the interrupt
injection API supports more than 256 vcpus.
I think userspace should be able to fail the creation of such large VM
immediately, before actually running it.
M.
--
Jazz is not dead, it just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 03/26] m68k, microblaze: remove ioremap_fullcache
From: Geert Uytterhoeven @ 2019-08-19 8:50 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64@vger.kernel.org, Linux-sh list,
Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
Vincent Chen, Linux-Arch, linux-s390,
open list:QUALCOMM HEXAGON..., the arch/x86 maintainers, arcml,
linux-xtensa, Arnd Bergmann, linux-m68k, Openrisc, Greentime Hu,
MTD Maling List, Guan Xuetao, Linux ARM, Michal Simek,
Parisc List, linux-mips, alpha, nios2-dev
In-Reply-To: <20190817073253.27819-4-hch@lst.de>
On Sat, Aug 17, 2019 at 9:41 AM Christoph Hellwig <hch@lst.de> wrote:
> No callers of this function.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> arch/m68k/include/asm/kmap.h | 7 -------
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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:54 UTC (permalink / raw)
To: Ran Wang
Cc: Mark Rutland, Biwen Li, Len Brown, Rafael J. Wysocki,
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: <DB8PR04MB6826475ACA623AE6D63617D7F1A80@DB8PR04MB6826.eurprd04.prod.outlook.com>
On Monday, August 19, 2019 10:33:25 AM CEST Ran Wang wrote:
> 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.
The conflict I mentioned earlier was with another patch series in the works
which is not in 5.3-rc5. However, there are problems with that series and it
is not linux-next now even, so please just base your series on top of -rc5.
_______________________________________________
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 08/26] m68k: simplify ioremap_nocache
From: Geert Uytterhoeven @ 2019-08-19 8:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64@vger.kernel.org, Linux-sh list,
Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
Vincent Chen, Linux-Arch, linux-s390,
open list:QUALCOMM HEXAGON..., the arch/x86 maintainers, arcml,
linux-xtensa, Arnd Bergmann, linux-m68k, Openrisc, Greentime Hu,
MTD Maling List, Guan Xuetao, Linux ARM, Michal Simek,
Parisc List, linux-mips, alpha, nios2-dev
In-Reply-To: <20190817073253.27819-9-hch@lst.de>
Hi Christoph,
On Sat, Aug 17, 2019 at 9:48 AM Christoph Hellwig <hch@lst.de> wrote:
> Just define ioremap_nocache to ioremap instead of duplicating the
> inline. Also defined ioremap_uc in terms of ioremap instead of
> the using a double indirection.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
BTW, shouldn't we get rid of the sole user of ioremap_uc(), too?
Seems to make a difference on x86 only, where it is "strongly uncached"
(whatever that may mean ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: fsl: Add device tree for S32V234-EVB
From: Shawn Guo @ 2019-08-19 8:58 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, Dan Nica,
linux-serial@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
Larisa Ileana Grigore
In-Reply-To: <20190809112853.15846-4-stefan-gabriel.mirea@nxp.com>
On Fri, Aug 09, 2019 at 11:29:12AM +0000, Stefan-gabriel Mirea wrote:
> From: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
>
> Add initial version of device tree for S32V234-EVB, including nodes for the
> 4 Cortex-A53 cores, AIPS bus with UART modules, ARM architected timer and
> Generic Interrupt Controller (GIC).
>
> Keep SoC level separate from board level to let future boards with this SoC
> share common properties, while the dts files will keep board-dependent
> properties.
>
> Signed-off-by: Stoica Cosmin-Stefan <cosmin.stoica@nxp.com>
> Signed-off-by: Mihaela Martinas <Mihaela.Martinas@freescale.com>
> Signed-off-by: Dan Nica <dan.nica@nxp.com>
> Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com>
> Signed-off-by: Phu Luu An <phu.luuan@nxp.com>
> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 2 +
> .../boot/dts/freescale/fsl-s32v234-evb.dts | 24 ++++
The 'fsl-' prefix can be saved here, so that we can distinguish three
families by starting string: imx??? for i.MX, fsl-??? for LayerScape,
and s32??? for S32.
> .../arm64/boot/dts/freescale/fsl-s32v234.dtsi | 130 ++++++++++++++++++
> 3 files changed, 156 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-s32v234-evb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-s32v234.dtsi
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index c043aca66572..3af29b58a833 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -26,3 +26,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
> +
> +dtb-$(CONFIG_ARCH_S32) += fsl-s32v234-evb.dtb
> diff --git a/arch/arm64/boot/dts/freescale/fsl-s32v234-evb.dts b/arch/arm64/boot/dts/freescale/fsl-s32v234-evb.dts
> new file mode 100644
> index 000000000000..92bf6c5563a3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-s32v234-evb.dts
> @@ -0,0 +1,24 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2016-2017 NXP
> + */
> +
> +/dts-v1/;
> +#include "fsl-s32v234.dtsi"
> +
> +/ {
> + compatible = "fsl,s32v234-evb", "fsl,s32v234";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/freescale/fsl-s32v234.dtsi b/arch/arm64/boot/dts/freescale/fsl-s32v234.dtsi
> new file mode 100644
> index 000000000000..6d686d3ba997
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-s32v234.dtsi
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2016-2018 NXP
> + */
> +
> +/memreserve/ 0x80000000 0x00010000;
> +
> +/ {
> + model = "Freescale S32V234";
The 'model' is usually used in board level DTS to describe the board.
> + compatible = "fsl,s32v234";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0 0x0>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x80000000>;
> + next-level-cache = <&cluster0_l2_cache>;
> + };
Please have a newline between nodes.
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0 0x1>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x80000000>;
> + next-level-cache = <&cluster0_l2_cache>;
> + };
> + cpu2: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0 0x100>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x80000000>;
> + next-level-cache = <&cluster1_l2_cache>;
> + };
> + cpu3: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0 0x101>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x80000000>;
> + next-level-cache = <&cluster1_l2_cache>;
> + };
> +
> + cluster0_l2_cache: l2-cache0 {
> + compatible = "cache";
> + };
> +
> + cluster1_l2_cache: l2-cache1 {
> + compatible = "cache";
> + };
> + };
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "simple-bus";
> + interrupt-parent = <&gic>;
> + ranges;
> +
> + aips0: aips-bus@40000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-parent = <&gic>;
> + reg = <0x0 0x40000000 0x0 0x7D000>;
> + ranges;
> +
> + uart0: serial@40053000 {
> + compatible = "fsl,s32-linflexuart";
> + reg = <0x0 0x40053000 0x0 0x1000>;
> + interrupts = <0 59 1>;
Please use GIC_SPI and IRQ_TYPE_xxx defines to make it more readable.
> + status = "disabled";
> + };
> + };
> +
> + aips1: aips-bus@40080000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-parent = <&gic>;
> + reg = <0x0 0x40080000 0x0 0x70000>;
> + ranges;
> +
> + uart1: serial@400bc000 {
> + compatible = "fsl,s32-linflexuart";
> + reg = <0x0 0x400bc000 0x0 0x1000>;
> + interrupts = <0 60 1>;
> + status = "disabled";
> + };
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xf08>,
> + <1 14 0xf08>,
> + <1 11 0xf08>,
> + <1 10 0xf08>;
> + /* clock-frequency might be modified by u-boot, depending on the
> + * chip version.
> + */
> + clock-frequency = <10000000>;
> + };
> +
> + gic: interrupt-controller@7d001000 {
> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0 0x7d001000 0 0x1000>,
> + <0 0x7d002000 0 0x2000>,
> + <0 0x7d004000 0 0x2000>,
> + <0 0x7d006000 0 0x2000>;
> + interrupts = <1 9 0xf04>;
> + };
We usually put these core platform devices prior to 'soc' node.
Shawn
> +};
> --
> 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 18/26] m68k: rename __iounmap and mark it static
From: Geert Uytterhoeven @ 2019-08-19 9:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-ia64@vger.kernel.org, Linux-sh list,
Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
Vincent Chen, Linux-Arch, linux-s390,
open list:QUALCOMM HEXAGON..., the arch/x86 maintainers, arcml,
linux-xtensa, Arnd Bergmann, linux-m68k, Openrisc, Greentime Hu,
MTD Maling List, Guan Xuetao, Linux ARM, Michal Simek,
Parisc List, linux-mips, alpha, nios2-dev
In-Reply-To: <20190817073253.27819-19-hch@lst.de>
Hi Christoph,
On Sat, Aug 17, 2019 at 9:49 AM Christoph Hellwig <hch@lst.de> wrote:
> m68k uses __iounmap as the name for an internal helper that is only
> used for some CPU types. Mark it static and give it a better name.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Thanks for your patch!
> --- a/arch/m68k/mm/kmap.c
> +++ b/arch/m68k/mm/kmap.c
> @@ -52,6 +52,7 @@ static inline void free_io_area(void *addr)
>
> #define IO_SIZE (256*1024)
>
> +static void __free_io_area(void *addr, unsigned long size);
> static struct vm_struct *iolist;
>
> static struct vm_struct *get_io_area(unsigned long size)
> @@ -90,7 +91,7 @@ static inline void free_io_area(void *addr)
> if (tmp->addr == addr) {
> *p = tmp->next;
> /* remove gap added in get_io_area() */
> - __iounmap(tmp->addr, tmp->size - IO_SIZE);
> + __free_io_area(tmp->addr, tmp->size - IO_SIZE);
> kfree(tmp);
> return;
> }
> @@ -249,12 +250,13 @@ void iounmap(void __iomem *addr)
> }
> EXPORT_SYMBOL(iounmap);
>
> +#ifndef CPU_M68040_OR_M68060_ONLY
Cant you move this block up, to avoid adding more #ifdef cluttery?
The rest looks good to me.
> /*
> - * __iounmap unmaps nearly everything, so be careful
> + * __free_io_area unmaps nearly everything, so be careful
> * Currently it doesn't free pointer/page tables anymore but this
> * wasn't used anyway and might be added later.
> */
> -void __iounmap(void *addr, unsigned long size)
> +static void __free_io_area(void *addr, unsigned long size)
> {
> unsigned long virtaddr = (unsigned long)addr;
> pgd_t *pgd_dir;
> @@ -297,6 +299,7 @@ void __iounmap(void *addr, unsigned long size)
>
> flush_tlb_all();
> }
> +#endif /* CPU_M68040_OR_M68060_ONLY */
>
> /*
> * Set new cache mode for some kernel address space.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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 0/9] Exynos Adaptive Supply Voltage support
From: Viresh Kumar @ 2019-08-19 9:09 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <562dd2e7-2b24-8492-d1c1-2dc4973f07be@samsung.com>
On 09-08-19, 17:58, Sylwester Nawrocki wrote:
> Thank you for your suggestions.
>
> For some Exynos SoC variants the algorithm of selecting CPU voltage supply
> is a bit more complex than just selecting a column in the frequency/voltage
> matrix, i.e. selecting a set of voltage values for whole frequency range.
>
> Frequency range could be divided into sub-ranges and to each such a sub-range
> part of different column could be assigned, depending on data fused in
> the CHIPID block registers.
>
> We could create OPP node for each frequency and specify all needed voltages
> as a list of "opp-microvolt-<name>" properties but apart from the fact that
> it would have been quite many properties, e.g. 42 (3 tables * 14 columns),
> only for some SoC types the dev_pm_opp_set_prop_name() approach could be
> used. We would need to be able to set opp-microvolt-* property name
> separately for each frequency (OPP).
>
> Probably most future proof would be a DT binding where we could still
> re-create those Exynos-specific ASV tables from DT. For example add named
> opp-microvolt-* properties or something similar to hold rows of each ASV
> table. But that conflicts with "operating-points-v2" binding, where
> multiple OPP voltage values are described by just named properties and
> multiple entries correspond to min/target/max.
>
> opp_table0 {
> compatible = "...", "operating-points-v2";
> opp-shared;
> opp-2100000000 {
> opp-hz = /bits/ 64 <1800000000>;
> opp-microvolt = <...>;
> opp-microvolt-t1 = <1362500>, <1350000>, ....;
> opp-microvolt-t2 = <1362500>, <1360000>, ....;
> opp-microvolt-t3 = <1362500>, <1340000>, ....;
> };
> ...
> opp-200000000 {
> opp-hz = /bits/ 64 <200000000>;
> opp-microvolt = <...>;
> opp-microvolt-t1 = <900000>, <900000>, ....;
> opp-microvolt-t2 = <900000>, <900000>, ....;
> opp-microvolt-t3 = <900000>, <900000>, ....;
> };
> };
>
> I might be missing some information now on how those Exynos ASV tables
> are used on other SoCs that would need to be supported.
>
> There will be even more data to include when adding support for the Body
> Bias voltage, for each CPU supply voltage we could possibly have
> corresponding Body Bias voltage.
Will something like this help ?
https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@codeaurora.org/
This never got merged but the idea was AVS only.
--
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 v7 0/4] DCMI bridge support
From: Hugues FRUCHET @ 2019-08-19 9:13 UTC (permalink / raw)
To: Hans Verkuil, Alexandre TORGUE, Mauro Carvalho Chehab,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel@vger.kernel.org, Philippe CORNU,
Yannick FERTRE, Benjamin Gaignard,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <0cd073d9-3d25-9e22-f243-f72e395e9e96@xs4all.nl>
Hi Hans, Sakari,
OK to push separately the 80 char fix.
There was pending related changes on st-mipid02 and ov5640 (listed
below), do you think it's possible to take them also ?
media: st-mipid02: add support of V4L2_CID_LINK_FREQ
https://patchwork.linuxtv.org/patch/56969/
State Accepted
[v2,1/3] media: st-mipid02: add support of RGB565
https://patchwork.linuxtv.org/patch/56970/
State Accepted
[v2,2/3] media: st-mipid02: add support of YUYV8 and UYVY8
https://patchwork.linuxtv.org/patch/56971/
State Accepted
[v2,3/3] media: st-mipid02: add support of JPEG
https://patchwork.linuxtv.org/patch/56973/
State Accepted
[v2] media: ov5640: add support of V4L2_CID_LINK_FREQ
https://patchwork.linuxtv.org/patch/57215/
State Changes Requested
=> This change is needed to make it work the whole setup.
=> I don't know what to change here, even if this 384MHz fixed value
seems strange, it works fine on my setup, on my opinion it's better than
nothing. We could come back on this later on when other OV5640 CSI
interfaces will require V4L2_CID_LINK_FREQ value.
Sakari, what do you think about this ?
BR,
Hugues.
On 8/19/19 10:43 AM, Hans Verkuil wrote:
> 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
* Re: [PATCH v2 3/3] arm: Add support for function error injection
From: Leo Yan @ 2019-08-19 9:18 UTC (permalink / raw)
To: Russell King, Oleg Nesterov, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86, Arnd Bergmann, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, Naveen N. Rao,
linux-arm-kernel, linux-kernel, linuxppc-dev, linux-arch, netdev,
bpf, clang-built-linux, Masami Hiramatsu
In-Reply-To: <20190806100015.11256-4-leo.yan@linaro.org>
Hi Russell,
On Tue, Aug 06, 2019 at 06:00:15PM +0800, Leo Yan wrote:
> This patch implements arm specific functions regs_set_return_value() and
> override_function_with_return() to support function error injection.
>
> In the exception flow, it updates pt_regs::ARM_pc with pt_regs::ARM_lr
> so can override the probed function return.
Gentle ping ... Could you review this patch?
Thanks,
Leo.
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/ptrace.h | 5 +++++
> arch/arm/lib/Makefile | 2 ++
> arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> 4 files changed, 27 insertions(+)
> create mode 100644 arch/arm/lib/error-inject.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 33b00579beff..2d3d44a037f6 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -77,6 +77,7 @@ config ARM
> select HAVE_EXIT_THREAD
> select HAVE_FAST_GUP if ARM_LPAE
> select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> + select HAVE_FUNCTION_ERROR_INJECTION if !THUMB2_KERNEL
> select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> select HAVE_GCC_PLUGINS
> diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
> index 91d6b7856be4..3b41f37b361a 100644
> --- a/arch/arm/include/asm/ptrace.h
> +++ b/arch/arm/include/asm/ptrace.h
> @@ -89,6 +89,11 @@ static inline long regs_return_value(struct pt_regs *regs)
> return regs->ARM_r0;
> }
>
> +static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> +{
> + regs->ARM_r0 = rc;
> +}
> +
> #define instruction_pointer(regs) (regs)->ARM_pc
>
> #ifdef CONFIG_THUMB2_KERNEL
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index b25c54585048..8f56484a7156 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -42,3 +42,5 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> CFLAGS_xor-neon.o += $(NEON_FLAGS)
> obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
> endif
> +
> +obj-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
> diff --git a/arch/arm/lib/error-inject.c b/arch/arm/lib/error-inject.c
> new file mode 100644
> index 000000000000..2d696dc94893
> --- /dev/null
> +++ b/arch/arm/lib/error-inject.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include <linux/error-injection.h>
> +#include <linux/kprobes.h>
> +
> +void override_function_with_return(struct pt_regs *regs)
> +{
> + /*
> + * 'regs' represents the state on entry of a predefined function in
> + * the kernel/module and which is captured on a kprobe.
> + *
> + * 'regs->ARM_lr' contains the the link register for the probed
> + * function, when kprobe returns back from exception it will override
> + * the end of probed function and directly return to the predefined
> + * function's caller.
> + */
> + instruction_pointer_set(regs, regs->ARM_lr);
> +}
> +NOKPROBE_SYMBOL(override_function_with_return);
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/26] m68k: simplify ioremap_nocache
From: Christoph Hellwig @ 2019-08-19 9:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-ia64@vger.kernel.org, Linux-sh list,
Linux Kernel Mailing List, Guo Ren, sparclinux, linux-riscv,
Vincent Chen, Christoph Hellwig, Linux-Arch, linux-s390,
open list:QUALCOMM HEXAGON..., the arch/x86 maintainers, arcml,
linux-xtensa, Arnd Bergmann, linux-m68k, Openrisc, Greentime Hu,
MTD Maling List, Guan Xuetao, Linux ARM, Michal Simek,
Parisc List, linux-mips, alpha, nios2-dev
In-Reply-To: <CAMuHMdWyXGjokWi7tn9JHCTz9YMb_vHn6XKeE7KzH5n-54Sy0A@mail.gmail.com>
On Mon, Aug 19, 2019 at 10:56:02AM +0200, Geert Uytterhoeven wrote:
> BTW, shouldn't we get rid of the sole user of ioremap_uc(), too?
> Seems to make a difference on x86 only, where it is "strongly uncached"
> (whatever that may mean ;-)
Yes, we probably should. However that actually seems worth a discussion
so I wanted to defer it until after this already huge series.
Another thing we can do after this series is to kill of ioremap_nocache.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: wifi on Motorola Droid 4 in 5.3-rc2
From: Pavel Machek @ 2019-08-19 9:19 UTC (permalink / raw)
To: Kalle Valo
Cc: Michael Nazzareno Trimarchi, mpartap, Tony Lindgren,
Merlijn Wajer, open list:TI WILINK WIRELES..., kernel list,
Sebastian Reichel, nekit1000, Linux OMAP Mailing List,
linux-arm-kernel
In-Reply-To: <87h86elgaa.fsf@tynnyri.adurom.net>
[-- Attachment #1.1: Type: text/plain, Size: 1718 bytes --]
On Sun 2019-08-18 17:06:05, Kalle Valo wrote:
> Pavel Machek <pavel@ucw.cz> writes:
>
> > On Sun 2019-08-18 12:53:01, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >>
> >> On Sun, Aug 18, 2019 at 12:46 PM Pavel Machek <pavel@ucw.cz> wrote:
> >> >
> >> > Hi!
> >> >
> >> > First, I guess I should mention that this is first time I'm attempting
> >> > to get wifi going on D4.
> >> >
> >> > I'm getting this:
> >> >
> >> > user@devuan:~/g/ofono$ sudo ifconfig wlan0 down
> >> > user@devuan:~/g/ofono$ sudo ifconfig wlan0 up
> >> > user@devuan:~/g/ofono$ sudo iwlist wlan0 scan
> >> > wlan0 Interface doesn't support scanning.
> >> >
> >>
> >> Try to use iw command. iwlist use an obsolete interface that you need
> >> to activate in kernel for back compatibility with old command. Can be
> >> your problem?
> >
> > Let me see ... CONFIG_CFG80211_WEXT was not set.
> >
> > Tried enabling it, and now I got. I remember getting it before,
> > too... let me try few more boots, perhaps it is random.
>
> >From developers' point of view WEXT is ancient and untested, everybody
> should switch to nl80211. So I strongly using iw (which uses nl80211).
> Of course this nothing to do with the wlcore warning you saw, just
> wanted to make you aware the state of wireless extensions.
You may want to add this to Kconfig test... and maybe it would be good
to mention iwconfig there, for easier grepping.
I'm using rather old distro; I'll update, but kernel is expected to be
back-compatible.. and tested :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 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 v2 01/11] dt-bindings: mmc: arasan: Update documentation for SD Card Clock
From: Manish Narani @ 2019-08-19 9:21 UTC (permalink / raw)
To: Ulf Hansson
Cc: mark.rutland@arm.com, kernel@esmil.dk, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, Jolly Shah, tony.xie@rock-chips.com,
philipp.tomsich@theobroma-systems.com, heiko@sntech.de,
Rob Herring, linux-rockchip@lists.infradead.org, Rajan Vaja,
Michal Simek, devicetree@vger.kernel.org, Nava kishore Manne,
scott.branden@broadcom.com, ayaka@soulik.info, mdf@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
adrian.hunter@intel.com, olof@lixom.net,
christoph.muellner@theobroma-systems.com
In-Reply-To: <CAPDyKFostBKYipTkCsDbggsrux7w8BPqARx7fwRsL1XqEEX2NQ@mail.gmail.com>
Hi Uffe,
> -----Original Message-----
> From: Ulf Hansson <ulf.hansson@linaro.org>
> Sent: Thursday, July 25, 2019 6:31 PM
> To: Manish Narani <MNARANI@xilinx.com>
> Cc: Rob Herring <robh@kernel.org>; mark.rutland@arm.com;
> heiko@sntech.de; Michal Simek <michals@xilinx.com>;
> adrian.hunter@intel.com; christoph.muellner@theobroma-systems.com;
> philipp.tomsich@theobroma-systems.com; viresh.kumar@linaro.org;
> scott.branden@broadcom.com; ayaka@soulik.info; kernel@esmil.dk;
> tony.xie@rock-chips.com; Rajan Vaja <RAJANV@xilinx.com>; Jolly Shah
> <JOLLYS@xilinx.com>; Nava kishore Manne <navam@xilinx.com>;
> mdf@kernel.org; olof@lixom.net; linux-mmc@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> Subject: Re: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update
> documentation for SD Card Clock
>
> On Tue, 23 Jul 2019 at 10:23, Manish Narani <MNARANI@xilinx.com> wrote:
> >
> > Hi Rob,
> >
> > Thanks a lot for the review!
> >
> >
> > > -----Original Message-----
> > > From: Rob Herring <robh@kernel.org>
> > > Sent: Tuesday, July 23, 2019 3:24 AM
> > > To: Manish Narani <MNARANI@xilinx.com>
> > > Cc: ulf.hansson@linaro.org; mark.rutland@arm.com; heiko@sntech.de;
> Michal
> > > Simek <michals@xilinx.com>; adrian.hunter@intel.com;
> > > christoph.muellner@theobroma-systems.com; philipp.tomsich@theobroma-
> > > systems.com; viresh.kumar@linaro.org; scott.branden@broadcom.com;
> > > ayaka@soulik.info; kernel@esmil.dk; tony.xie@rock-chips.com; Rajan Vaja
> > > <RAJANV@xilinx.com>; Jolly Shah <JOLLYS@xilinx.com>; Nava kishore
> Manne
> > > <navam@xilinx.com>; mdf@kernel.org; olof@lixom.net; linux-
> > > mmc@vger.kernel.org; devicetree@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> > > rockchip@lists.infradead.org
> > > Subject: Re: [PATCH v2 01/11] dt-bindings: mmc: arasan: Update
> > > documentation for SD Card Clock
> > >
> > > On Mon, Jul 01, 2019 at 10:59:41AM +0530, Manish Narani wrote:
> > > > The clock handling is to be updated in the Arasan SDHCI. As the
> > > > 'devm_clk_register' is deprecated in the clock framework, this needs to
> > > > specify one more clock named 'clk_sdcard' to get the clock in the driver
> > > > via 'devm_clk_get()'. This clock represents the clock from controller to
> > > > the card.
> > >
> > > Please explain why in terms of the binding, not some driver calls.
> > Okay.
> >
> > >
> > >
> > > > Signed-off-by: Manish Narani <manish.narani@xilinx.com>
> > > > ---
> > > > Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 15
> ++++++++++-
> > > ----
> > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > index 1edbb04..15c6397 100644
> > > > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > > > @@ -23,6 +23,10 @@ Required Properties:
> > > > - reg: From mmc bindings: Register location and length.
> > > > - clocks: From clock bindings: Handles to clock inputs.
> > > > - clock-names: From clock bindings: Tuple including "clk_xin" and
> "clk_ahb"
> > > > + Apart from these two there is one more optional clock which
> > > > + is "clk_sdcard". This clock represents output clock from
> > > > + controller and card. This must be specified when #clock-cells
> > > > + is specified.
> > > > - interrupts: Interrupt specifier
> > > >
> > > > Required Properties for "arasan,sdhci-5.1":
> > > > @@ -36,9 +40,10 @@ Optional Properties:
> > > > - clock-output-names: If specified, this will be the name of the card
> clock
> > > > which will be exposed by this device. Required if #clock-cells is
> > > > specified.
> > > > - - #clock-cells: If specified this should be the value <0>. With this
> property
> > > > - in place we will export a clock representing the Card Clock. This clock
> > > > - is expected to be consumed by our PHY. You must also specify
> > > > + - #clock-cells: If specified this should be the value <0>. With this
> > > > + property in place we will export one clock representing the Card
> > > > + Clock. This clock is expected to be consumed by our PHY. You must
> also
> > > > + specify
> > >
> > > specify what?
> > I think this line was already there, I missed to correct it, Will update in v3.
> >
> > >
> > > The 3rd clock input I assume? This statement means any existing users
> > > with 2 clock inputs and #clock-cells are in error now. Is that correct?
> > Yes, this is correct. So far there was only one vendor using '#clock-cells'
> which is Rockchip. I have sent DT patch (02/11) for that also.
> > Here this is needed as earlier implementation isn't correct as suggested by
> Uffe. (https://lkml.org/lkml/2019/6/20/486) .
>
> I am not sure how big of a problem the backwards compatible thingy
> with DT is, in general we must not break it. What do you say Manish?
Though I agree with Uffe on this, there is no other way from my understanding. Please suggest.
>
> As a workaround, would it be possible to use
> of_clk_get_from_provider() somehow to address the compatibility issue?
For this to be used we have to parse 'clkspec' from the DT node and pass the same as an argument to this function. In this case also the DT node needs to be updated, which is same as we have done in this series.
Thanks,
Manish
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: wifi on Motorola Droid 4 in 5.3-rc2
From: Pavel Machek @ 2019-08-19 9:24 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi
Cc: mpartap, Tony Lindgren, Merlijn Wajer,
open list:TI WILINK WIRELES..., kernel list, Sebastian Reichel,
nekit1000, Linux OMAP Mailing List, linux-arm-kernel
In-Reply-To: <CAOf5uwncAHQ-nfFzQhv=T+pyXJ+60_QNT4F11VJg+25GjFFkxQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2506 bytes --]
Hi!
> > [ 13.653778] panel-dsi-cm 58004000.encoder:display: using lookup
> > tables for GPIO lookup
> > [ 13.661834] panel-dsi-cm 58004000.encoder:display: No GPIO consumer
> > te found
> > [ 14.756622] ------------[ cut here ]------------
> > [ 14.761352] WARNING: CPU: 0 PID: 20 at
> > /data/fast/l/k/drivers/net/wireless/ti/wlcore/sdio.c:86
> > wl12xx_sdio_raw_read+0xa8/0x128
> > [ 14.772888] Modules linked in:
> > [ 14.776062] CPU: 0 PID: 20 Comm: kworker/0:1 Tainted: G W
> > 5.3.0-rc4-58571-gdbaece1 #85
> > [ 14.783630] Hardware name: Generic OMAP4 (Flattened Device Tree)
> > [ 14.791381] Workqueue: events request_firmware_work_func
>
> You have a timeout here. Can be that your reset sequence of the wifi
> is not optimal because
> is not responding?
I tried delays and printks... WL12XX_REG_FUSE_BD_ADDR_1 read fails,
and retrying does not really help. If you have idea how to debug/fix
this, let me know...
Best regards,
Pavel
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index 3c9c623..afb294a 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1505,24 +1505,40 @@ static int wl12xx_get_fuse_mac(struct wl1271 *wl)
{
u32 mac1, mac2;
int ret;
-
+
+ mdelay(1);
+ printk("get_fuse_mac: %d\n", __LINE__);
ret = wlcore_set_partition(wl, &wl->ptable[PART_DRPW]);
if (ret < 0)
goto out;
+ mdelay(1);
+ printk("get_fuse_mac: %d\n", __LINE__);
+ ret = wlcore_read32(wl, WL12XX_REG_FUSE_BD_ADDR_1, &mac1);
+ if (ret < 0) {
+ printk("get_fuse_mac: X %d\n", __LINE__);
+ ret = wlcore_read32(wl, WL12XX_REG_FUSE_BD_ADDR_1, &mac1);
+ if (ret < 0) {
+ printk("get_fuse_mac: XX %d\n", __LINE__);
ret = wlcore_read32(wl, WL12XX_REG_FUSE_BD_ADDR_1, &mac1);
if (ret < 0)
goto out;
+ }
+ }
+
+ printk("get_fuse_mac: %d\n", __LINE__);
ret = wlcore_read32(wl, WL12XX_REG_FUSE_BD_ADDR_2, &mac2);
if (ret < 0)
goto out;
+ printk("get_fuse_mac: %d\n", __LINE__);
/* these are the two parts of the BD_ADDR */
wl->fuse_oui_addr = ((mac2 & 0xffff) << 8) +
((mac1 & 0xff000000) >> 24);
wl->fuse_nic_addr = mac1 & 0xffffff;
+ printk("get_fuse_mac: %d\n", __LINE__);
ret = wlcore_set_partition(wl, &wl->ptable[PART_DOWN]);
out:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 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 related
* Re: [PATCH 4/3] pwm: atmel: document known weaknesses of both hardware and software
From: Claudiu.Beznea @ 2019-08-19 9:26 UTC (permalink / raw)
To: uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <20190816093748.11769-1-uwe@kleine-koenig.org>
On 16.08.2019 12:37, Uwe Kleine-König wrote:
> External E-Mail
>
>
> 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.
Are you talking here about the normal polarity (from documentation: By
definition, normal polarity characterizes a signal starts high for the
duration of the duty cycle and goes low for the remainder of the period.)
If yes, this should be solved by playing with CPOL bit of CMR.
> + * - Hardware has to be stopped in general to update settings.
Sama5d2 has duty cycle that could be updated on the fly.
> + *
> + * Software bugs/possible improvements:
> + * - When atmel_pwm_apply() is called with state->enabled=false a change in
> + * state->polarity isn't honored.
I know that when configuring a PWM one should get the current state of the
PWM, change it, then pass it to the driver via pwm_apply_state(). In case
one would call the pwm_apply_state() with state->enabled = false the state
would be stored in PWM specific object (of type struct pwm_device). On the
next apply, with enabled = true, all the PWM parameters would be actually
applied to hardware. So, until enable=true the PWM state would only be
cached by PWM core specific objects (in pwm_apply_state()).
> + * - Instead of sleeping to wait for a completed period, the interrupt
> + * functionality could be used.
> */
>
> #include <linux/clk.h>
>
_______________________________________________
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 1/3] pwm: atmel: Add link to reference manual
From: Claudiu.Beznea @ 2019-08-19 9:26 UTC (permalink / raw)
To: uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-1-uwe@kleine-koenig.org>
On 16.08.2019 00:41, Uwe Kleine-König wrote:
> The reference manual for at least one of the supported variants is
> publicly available. Add a link to it at the top of the driver.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> drivers/pwm/pwm-atmel.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index e5e1eaf372fa..ac3d7a200b9e 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -4,6 +4,9 @@
> *
> * Copyright (C) 2013 Atmel Corporation
> * Bo Shen <voice.shen@atmel.com>
> + *
> + * Reference manual for "atmel,at91sam9rl-pwm":
> + * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
Even SAM9G25 PWM have almost the same registers with AT91SAM9RL, the
datasheet for AT91SAM9RL is located at:
http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
Maybe we should use this one.
I'm not familiar with having reference manuals in this part of the driver
but if we are doing so would it be feasible to also have links for the rest
SoCs that introduces new PWM versions? I'm thinking here at all the
compatibles from atmel_pwm_dt_ids[]:
- atmel,sama5d3-pwm
- atmel,sama5d2-pwm
- microchip,sam9x60-pwm
Although the last one is not already public.
> */
>
> #include <linux/clk.h>
>
_______________________________________________
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 2/3] pwm: atmel: use a constant for maximum prescale value
From: Claudiu.Beznea @ 2019-08-19 9:27 UTC (permalink / raw)
To: uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-2-uwe@kleine-koenig.org>
On 16.08.2019 00:41, Uwe Kleine-König wrote:
> External E-Mail
>
>
> The maximal prescale value is 10 for all supported variants. So drop the
> member in the variant description and introduce a global constant instead.
>
> This reduces the size of the variant descriptions and the .apply() callback
> can be compiled a bit more effectively.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Tested on SAMA5D2_Xplained.
> ---
> drivers/pwm/pwm-atmel.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index ac3d7a200b9e..d7a6d32b5774 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -50,6 +50,8 @@
> #define PWMV2_CPRD 0x0C
> #define PWMV2_CPRDUPD 0x10
>
> +#define PWM_MAX_PRES 10
> +
> struct atmel_pwm_registers {
> u8 period;
> u8 period_upd;
> @@ -59,7 +61,6 @@ struct atmel_pwm_registers {
>
> struct atmel_pwm_config {
> u32 max_period;
> - u32 max_pres;
> };
>
> struct atmel_pwm_data {
> @@ -126,7 +127,7 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
> for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
> (*pres)++;
>
> - if (*pres > atmel_pwm->data->cfg.max_pres) {
> + if (*pres > PWM_MAX_PRES) {
> dev_err(chip->dev, "pres exceeds the maximum value\n");
> return -EINVAL;
> }
> @@ -289,7 +290,6 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
> .cfg = {
> /* 16 bits to keep period and duty. */
> .max_period = 0xffff,
> - .max_pres = 10,
> },
> };
>
> @@ -303,7 +303,6 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
> .cfg = {
> /* 16 bits to keep period and duty. */
> .max_period = 0xffff,
> - .max_pres = 10,
> },
> };
>
> @@ -317,7 +316,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
> .cfg = {
> /* 32 bits to keep period and duty. */
> .max_period = 0xffffffff,
> - .max_pres = 10,
> },
> };
>
>
_______________________________________________
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 3/3] pwm: atmel: replace loop in prescale calculation by ad-hoc calculation
From: Claudiu.Beznea @ 2019-08-19 9:27 UTC (permalink / raw)
To: uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <20190815214133.11134-3-uwe@kleine-koenig.org>
On 16.08.2019 00:41, Uwe Kleine-König wrote:
> External E-Mail
>
>
> The calculated values are the same with the modified algorithm. The only
> difference is that the calculation is a bit more efficient.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Acked-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Tested on SAMA5D2_Xplained.
> ---
> drivers/pwm/pwm-atmel.c | 24 +++++++++++++++++-------
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index d7a6d32b5774..42fe7bc043a8 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -60,7 +60,7 @@ struct atmel_pwm_registers {
> };
>
> struct atmel_pwm_config {
> - u32 max_period;
> + u32 period_bits;
> };
>
> struct atmel_pwm_data {
> @@ -119,17 +119,27 @@ static int atmel_pwm_calculate_cprd_and_pres(struct pwm_chip *chip,
> {
> struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
> unsigned long long cycles = state->period;
> + int shift;
>
> /* Calculate the period cycles and prescale value */
> cycles *= clk_get_rate(atmel_pwm->clk);
> do_div(cycles, NSEC_PER_SEC);
>
> - for (*pres = 0; cycles > atmel_pwm->data->cfg.max_period; cycles >>= 1)
> - (*pres)++;
> + /*
> + * The register for the period length is cfg.period_bits bits wide.
> + * So for each bit the number of clock cycles is wider divide the input
> + * clock frequency by two using pres and shift cprd accordingly.
> + */
> + shift = fls(cycles) - atmel_pwm->data->cfg.period_bits;
>
> - if (*pres > PWM_MAX_PRES) {
> + if (shift > PWM_MAX_PRES) {
> dev_err(chip->dev, "pres exceeds the maximum value\n");
> return -EINVAL;
> + } else if (shift > 0) {
> + *pres = shift;
> + cycles >>= *pres;
> + } else {
> + *pres = 0;
> }
>
> *cprd = cycles;
> @@ -289,7 +299,7 @@ static const struct atmel_pwm_data atmel_sam9rl_pwm_data = {
> },
> .cfg = {
> /* 16 bits to keep period and duty. */
> - .max_period = 0xffff,
> + .period_bits = 16,
> },
> };
>
> @@ -302,7 +312,7 @@ static const struct atmel_pwm_data atmel_sama5_pwm_data = {
> },
> .cfg = {
> /* 16 bits to keep period and duty. */
> - .max_period = 0xffff,
> + .period_bits = 16,
> },
> };
>
> @@ -315,7 +325,7 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
> },
> .cfg = {
> /* 32 bits to keep period and duty. */
> - .max_period = 0xffffffff,
> + .period_bits = 32,
> },
> };
>
>
_______________________________________________
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 1/8] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-08-19 9:28 UTC (permalink / raw)
To: Keerthy, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree, s-anna
In-Reply-To: <6bf4194b-23c0-2de0-3f9c-e99195336dc7@ti.com>
On 08/08/2019 07:35, Keerthy wrote:
>
>
> On 07/08/19 1:18 PM, Tero Kristo wrote:
>> Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
>> of these will act as a power domain controller and potentially as a reset
>> provider.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/prm-inst.txt | 24
>> ++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>> b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>> new file mode 100644
>> index 0000000..e0ae87b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
>> @@ -0,0 +1,24 @@
>> +OMAP PRM instance bindings
>> +
>> +Power and Reset Manager is an IP block on OMAP family of devices which
>> +handle the power domains and their current state, and provide reset
>> +handling for the domains and/or separate IP blocks under the power
>> domain
>> +hierarchy.
>> +
>> +Required properties:
>> +- compatible: Must be one of:
>> + "ti,am3-prm-inst"
>> + "ti,am4-prm-inst"
>> + "ti,omap4-prm-inst"
>> + "ti,omap5-prm-inst"
>> + "ti,dra7-prm-inst"
>> +- reg: Contains PRM instance register address range
>> + (base address and length)
>
> How about reset-cells property, Isn't that a mandatory property?
It is optional, but you are right, should be added to this.
-Tero
>
>> +
>> +Example:
>> +
>> +prm_dsp2: prm@1b00 {
>> + compatible = "ti,dra7-prm-inst";
>> + reg = <0x1b00 0x40>;
>> + #reset-cells = <1>;
>> +};
>>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 2/8] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-08-19 9:32 UTC (permalink / raw)
To: Keerthy, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree, s-anna
In-Reply-To: <3b76f0e0-7530-e7b5-09df-2de9956f30ee@ti.com>
On 08/08/2019 08:26, Keerthy wrote:
>
>
> On 07/08/19 1:18 PM, Tero Kristo wrote:
>> Add initial PRM (Power and Reset Management) driver for TI OMAP class
>> SoCs. Initially this driver only supports reset control, but can be
>> extended to support rest of the functionality, like powerdomain
>> control, PRCM irq support etc.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> arch/arm/mach-omap2/Kconfig | 1 +
>> drivers/soc/ti/Makefile | 1 +
>> drivers/soc/ti/omap_prm.c | 216
>> ++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 218 insertions(+)
>> create mode 100644 drivers/soc/ti/omap_prm.c
>>
>> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> index fdb6743..42ad063 100644
>> --- a/arch/arm/mach-omap2/Kconfig
>> +++ b/arch/arm/mach-omap2/Kconfig
>> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
>> select TI_SYSC
>> select OMAP_IRQCHIP
>> select CLKSRC_TI_32K
>> + select RESET_CONTROLLER
>> help
>> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
>> index b3868d3..788b5cd 100644
>> --- a/drivers/soc/ti/Makefile
>> +++ b/drivers/soc/ti/Makefile
>> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
>> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
>> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
>> obj-$(CONFIG_AMX3_PM) += pm33xx.o
>> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
>> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
>> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
>> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> new file mode 100644
>> index 0000000..7c89eb8
>> --- /dev/null
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -0,0 +1,216 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * OMAP2+ PRM driver
>> + *
>> + * Copyright (C) 2019 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Tero Kristo <t-kristo@ti.com>
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset-controller.h>
>> +#include <linux/delay.h>
>> +
>> +struct omap_rst_map {
>> + s8 rst;
>> + s8 st;
>> +};
>> +
>> +struct omap_prm_data {
>> + u32 base;
>> + const char *name;
>> + u16 pwstctrl;
>> + u16 pwstst;
>> + u16 rstctl;
>> + u16 rstst;
>> + struct omap_rst_map *rstmap;
>> + u8 flags;
>> +};
>> +
>> +struct omap_prm {
>> + const struct omap_prm_data *data;
>> + void __iomem *base;
>> +};
>> +
>> +struct omap_reset_data {
>> + struct reset_controller_dev rcdev;
>> + struct omap_prm *prm;
>> +};
>> +
>> +#define to_omap_reset_data(p) container_of((p), struct
>> omap_reset_data, rcdev)
>> +
>> +#define OMAP_MAX_RESETS 8
>> +#define OMAP_RESET_MAX_WAIT 10000
>> +
>> +#define OMAP_PRM_NO_RSTST BIT(0)
>> +
>> +static const struct of_device_id omap_prm_id_table[] = {
>> + { },
>> +};
>
> This table is blank and we are doing of_match_device against it.
Yes, it gets populated with other patches in series, one entry per soc.
>
>> +
>> +static int omap_reset_status(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>> + u32 v;
>> +
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>> + v &= 1 << id;
>> + v >>= id;
>> +
>> + return v;
>> +}
>> +
>> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>> + u32 v;
>> +
>> + /* assert the reset control line */
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>> + v |= 1 << id;
>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>> +
>> + return 0;
>> +}
>> +
>> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
>> + unsigned long id)
>> +{
>> + struct omap_rst_map *map = reset->prm->data->rstmap;
>> +
>> + while (map && map->rst >= 0) {
>> + if (map->rst == id)
>> + return map->st;
>> +
>> + map++;
>> + }
>> +
>> + return id;
>> +}
>> +
>> +/*
>> + * Note that status will not change until clocks are on, and clocks
>> cannot be
>> + * enabled until reset is deasserted. Consumer drivers must check status
>> + * separately after enabling clocks.
>> + */
>> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
>> + u32 v;
>> + int st_bit = id;
>> + bool has_rstst;
>> +
>> + /* check the current status to avoid de-asserting the line twice */
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>> + if (!(v & BIT(id)))
>> + return -EEXIST;
>> +
>> + has_rstst = !(reset->prm->data->flags & OMAP_PRM_NO_RSTST);
>> +
>> + if (has_rstst) {
>> + st_bit = omap_reset_get_st_bit(reset, id);
>> +
>> + /* Clear the reset status by writing 1 to the status bit */
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
>> + v |= 1 << st_bit;
>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
>> + }
>> +
>> + /* de-assert the reset control line */
>> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctl);
>> + v &= ~(1 << id);
>> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctl);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct reset_control_ops omap_reset_ops = {
>> + .assert = omap_reset_assert,
>> + .deassert = omap_reset_deassert,
>> + .status = omap_reset_status,
>> +};
>> +
>> +static int omap_prm_reset_probe(struct platform_device *pdev,
>> + struct omap_prm *prm)
>> +{
>> + struct omap_reset_data *reset;
>> +
>> + /*
>> + * Check if we have resets. If either rstctl or rstst is
>> + * non-zero, we have reset registers in place. Additionally
>> + * the flag OMAP_PRM_NO_RSTST implies that we have resets.
>> + */
>> + if (!prm->data->rstctl && !prm->data->rstst &&
>> + !(prm->data->flags & OMAP_PRM_NO_RSTST))
>> + return 0;
>> +
>> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
>> + if (!reset)
>> + return -ENOMEM;
>> +
>> + reset->rcdev.owner = THIS_MODULE;
>> + reset->rcdev.ops = &omap_reset_ops;
>> + reset->rcdev.of_node = pdev->dev.of_node;
>> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
>> +
>> + reset->prm = prm;
>> +
>> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
>> +}
>> +
>> +static int omap_prm_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> + const struct omap_prm_data *data;
>> + struct omap_prm *prm;
>> + const struct of_device_id *match;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return -ENODEV;
>> +
>> + match = of_match_device(omap_prm_id_table, &pdev->dev);
>> + if (!match)
>> + return -ENOTSUPP;
>> +
>> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
>> + if (!prm)
>> + return -ENOMEM;
>> +
>> + data = match->data;
>> +
>> + while (data->base != res->start) {
>> + if (!data->base)
>> + return -EINVAL;
>> + data++;
>> + }
>> +
>> + prm->data = data;
>> +
>> + prm->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (!prm->base)
>> + return -ENOMEM;
>> +
>> + return omap_prm_reset_probe(pdev, prm);
>> +}
>> +
>> +static struct platform_driver omap_prm_driver = {
>> + .probe = omap_prm_probe,
>> + .driver = {
>> + .name = KBUILD_MODNAME,
>> + .of_match_table = omap_prm_id_table,
>> + },
>> +};
>> +builtin_platform_driver(omap_prm_driver);
>> +
>> +MODULE_ALIAS("platform:prm");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("omap2+ prm driver");
>
> It is a builtin_platform_driver so do we need the MODULE*?
Well, thats debatable, however some existing drivers do introduce this
even if they are builtin.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 5/8] soc: ti: omap-prm: add omap4 PRM data
From: Tero Kristo @ 2019-08-19 9:32 UTC (permalink / raw)
To: Keerthy, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree, s-anna
In-Reply-To: <643cd090-a4d5-dac6-8395-c01f7fba04ab@ti.com>
On 08/08/2019 08:30, Keerthy wrote:
>
>
> On 07/08/19 1:18 PM, Tero Kristo wrote:
>> Add PRM data for omap4 family of SoCs.
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
>> index 870515e3..9b8d5945 100644
>> --- a/drivers/soc/ti/omap_prm.c
>> +++ b/drivers/soc/ti/omap_prm.c
>> @@ -54,7 +54,27 @@ struct omap_reset_data {
>> #define OMAP_PRM_NO_RSTST BIT(0)
>> +struct omap_prm_data omap4_prm_data[] = {
>> + { .name = "mpu", .base = 0x4a306300, .pwstst = 0x4 },
>> + { .name = "tesla", .base = 0x4a306400, .pwstst = 0x4, .rstctl =
>> 0x10, .rstst = 0x14 },
>> + { .name = "abe", .base = 0x4a306500, .pwstst = 0x4 },
>> + { .name = "always_on_core", .base = 0x4a306600, .pwstst = 0x4 },
>> + { .name = "core", .base = 0x4a306700, .pwstst = 0x4, .rstctl =
>> 0x210, .rstst = 0x214 },
>> + { .name = "ivahd", .base = 0x4a306f00, .pwstst = 0x4, .rstctl =
>> 0x10, .rstst = 0x14 },
>> + { .name = "cam", .base = 0x4a307000, .pwstst = 0x4 },
>> + { .name = "dss", .base = 0x4a307100, .pwstst = 0x4 },
>> + { .name = "gfx", .base = 0x4a307200, .pwstst = 0x4 },
>> + { .name = "l3init", .base = 0x4a307300, .pwstst = 0x4 },
>> + { .name = "l4per", .base = 0x4a307400, .pwstst = 0x4 },
>> + { .name = "cefuse", .base = 0x4a307600, .pwstst = 0x4 },
>> + { .name = "wkup", .base = 0x4a307700, .pwstst = 0x4 },
>> + { .name = "emu", .base = 0x4a307900, .pwstst = 0x4 },
>> + { .name = "device", .base = 0x4a307b00, .rstctl = 0x0, .rstst =
>> 0x4 },
>> + { },
>> +};
>
> So at some point arch/arm/mach-omap2/powerdomains44xx_data.c
> duplicated data will be removed?
Yes, that would be the path forward eventually.
-Tero
>
>> +
>> static const struct of_device_id omap_prm_id_table[] = {
>> + { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
>> { },
>> };
>>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
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 9/9] drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
From: Hans Verkuil @ 2019-08-19 9:32 UTC (permalink / raw)
To: Dariusz Marcinkiewicz, dri-devel, linux-media
Cc: linux-samsung-soc, David Airlie, Seung-Woo Kim, linux-kernel,
Krzysztof Kozlowski, Kyungmin Park, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20190814104520.6001-10-darekm@google.com>
On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> Use the new cec_notifier_conn_(un)register() functions to
> (un)register the notifier for the HDMI connector, and fill in
> the cec_connector_info.
>
> Changes since v2:
> - removed unnecessary call to invalidate phys address before
> deregistering the notifier,
> - use cec_notifier_phys_addr_invalidate instead of setting
> invalid address on a notifier.
>
> Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com>
> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Regards,
Hans
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 31 ++++++++++++++++------------
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index bc1565f1822ab..d532b468d9af5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -852,6 +852,10 @@ static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
>
> static void hdmi_connector_destroy(struct drm_connector *connector)
> {
> + struct hdmi_context *hdata = connector_to_hdmi(connector);
> +
> + cec_notifier_conn_unregister(hdata->notifier);
> +
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> }
> @@ -935,6 +939,7 @@ static int hdmi_create_connector(struct drm_encoder *encoder)
> {
> struct hdmi_context *hdata = encoder_to_hdmi(encoder);
> struct drm_connector *connector = &hdata->connector;
> + struct cec_connector_info conn_info;
> int ret;
>
> connector->interlace_allowed = true;
> @@ -957,6 +962,15 @@ static int hdmi_create_connector(struct drm_encoder *encoder)
> DRM_DEV_ERROR(hdata->dev, "Failed to attach bridge\n");
> }
>
> + cec_fill_conn_info_from_drm(&conn_info, connector);
> +
> + hdata->notifier = cec_notifier_conn_register(hdata->dev, NULL,
> + &conn_info);
> + if (hdata->notifier == NULL) {
> + ret = -ENOMEM;
> + DRM_DEV_ERROR(hdata->dev, "Failed to allocate CEC notifier\n");
> + }
> +
> return ret;
> }
>
> @@ -1528,8 +1542,8 @@ static void hdmi_disable(struct drm_encoder *encoder)
> */
> mutex_unlock(&hdata->mutex);
> cancel_delayed_work(&hdata->hotplug_work);
> - cec_notifier_set_phys_addr(hdata->notifier,
> - CEC_PHYS_ADDR_INVALID);
> + if (hdata->notifier)
> + cec_notifier_phys_addr_invalidate(hdata->notifier);
> return;
> }
>
> @@ -2006,12 +2020,6 @@ static int hdmi_probe(struct platform_device *pdev)
> }
> }
>
> - hdata->notifier = cec_notifier_get(&pdev->dev);
> - if (hdata->notifier == NULL) {
> - ret = -ENOMEM;
> - goto err_hdmiphy;
> - }
> -
> pm_runtime_enable(dev);
>
> audio_infoframe = &hdata->audio.infoframe;
> @@ -2023,7 +2031,7 @@ static int hdmi_probe(struct platform_device *pdev)
>
> ret = hdmi_register_audio_device(hdata);
> if (ret)
> - goto err_notifier_put;
> + goto err_runtime_disable;
>
> ret = component_add(&pdev->dev, &hdmi_component_ops);
> if (ret)
> @@ -2034,8 +2042,7 @@ static int hdmi_probe(struct platform_device *pdev)
> err_unregister_audio:
> platform_device_unregister(hdata->audio.pdev);
>
> -err_notifier_put:
> - cec_notifier_put(hdata->notifier);
> +err_runtime_disable:
> pm_runtime_disable(dev);
>
> err_hdmiphy:
> @@ -2054,12 +2061,10 @@ static int hdmi_remove(struct platform_device *pdev)
> struct hdmi_context *hdata = platform_get_drvdata(pdev);
>
> cancel_delayed_work_sync(&hdata->hotplug_work);
> - cec_notifier_set_phys_addr(hdata->notifier, CEC_PHYS_ADDR_INVALID);
>
> component_del(&pdev->dev, &hdmi_component_ops);
> platform_device_unregister(hdata->audio.pdev);
>
> - cec_notifier_put(hdata->notifier);
> pm_runtime_disable(&pdev->dev);
>
> if (!IS_ERR(hdata->reg_hdmi_en))
>
_______________________________________________
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/9] drm: cec: convert DRM drivers to the new notifier API
From: Hans Verkuil @ 2019-08-19 9:38 UTC (permalink / raw)
To: Dariusz Marcinkiewicz, dri-devel, linux-media
Cc: Kate Stewart, Neil Armstrong, Daniel Vetter, linux-kernel,
Hans Verkuil, Dhinakaran Pandiyan, Sam Ravnborg,
linux-samsung-soc, David Francis, amd-gfx, Jani Nikula,
Jerry (Fangzhi) Zuo, linux-arm-kernel, nouveau, Jonas Karlman,
Leo Li, intel-gfx, Russell King, Sean Paul, Rodrigo Vivi,
linux-tegra, Thomas Gleixner, Allison Randal, Thomas Lim,
Jernej Skrabec, Greg Kroah-Hartman, Douglas Anderson,
Manasi Navare, Alex Deucher, Colin Ian King, Enrico Weigelt,
Laurent Pinchart
In-Reply-To: <20190814104520.6001-1-darekm@google.com>
Hi all,
The patches in this series can be applied independently from each other.
If you maintain one of these drivers and you want to merge it for v5.4
yourself, then please do so and let me know. If you prefer I commit it
to drm-misc, then please review and (hopefully) Ack the patch.
I would really like to get this in for v5.4 so I can get the userspace
bits in for v5.4 as well through the media subsystem.
Dariusz, can you post a v7.1 for patch 5/9 fixing the typo?
Thanks!
Hans
On 8/14/19 12:44 PM, Dariusz Marcinkiewicz wrote:
> This series updates DRM drivers to use new CEC notifier API.
>
> Changes since v6:
> Made CEC notifiers' registration and de-registration symmetric
> in tda998x and dw-hdmi drivers. Also, accidentally dropped one
> patch in v6 (change to drm_dp_cec), brought it back now.
> Changes since v5:
> Fixed a warning about a missing comment for a new member of
> drm_dp_aux_cec struct. Sending to a wider audience,
> including maintainers of respective drivers.
> Changes since v4:
> Addressing review comments.
> Changes since v3:
> Updated adapter flags in dw-hdmi-cec.
> Changes since v2:
> Include all DRM patches from "cec: improve notifier support,
> add connector info connector info" series.
> Changes since v1:
> Those patches delay creation of notifiers until respective
> connectors are constructed. It seems that those patches, for a
> couple of drivers, by adding the delay, introduce a race between
> notifiers' creation and the IRQs handling threads - at least I
> don't see anything obvious in there that would explicitly forbid
> such races to occur. v2 adds a write barrier to make sure IRQ
> threads see the notifier once it is created (replacing the
> WRITE_ONCE I put in v1). The best thing to do here, I believe,
> would be not to have any synchronization and make sure that an IRQ
> only gets enabled after the notifier is created.
> Dariusz Marcinkiewicz (9):
> drm_dp_cec: add connector info support.
> drm/i915/intel_hdmi: use cec_notifier_conn_(un)register
> dw-hdmi-cec: use cec_notifier_cec_adap_(un)register
> tda9950: use cec_notifier_cec_adap_(un)register
> drm: tda998x: use cec_notifier_conn_(un)register
> drm: sti: use cec_notifier_conn_(un)register
> drm: tegra: use cec_notifier_conn_(un)register
> drm: dw-hdmi: use cec_notifier_conn_(un)register
> drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
>
> .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 13 +++---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 +++++++++++++------
> drivers/gpu/drm/drm_dp_cec.c | 25 ++++++----
> drivers/gpu/drm/exynos/exynos_hdmi.c | 31 +++++++------
> drivers/gpu/drm/i2c/tda9950.c | 12 ++---
> drivers/gpu/drm/i2c/tda998x_drv.c | 36 ++++++++++-----
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 ++++--
> drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +-
> drivers/gpu/drm/sti/sti_hdmi.c | 19 +++++---
> drivers/gpu/drm/tegra/output.c | 28 ++++++++---
> include/drm/drm_dp_helper.h | 17 ++++---
> 13 files changed, 155 insertions(+), 94 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][next] misc: xilinx_sdfec: fix spelling mistake: "Schdule" -> "Schedule"
From: Colin King @ 2019-08-19 9:41 UTC (permalink / raw)
To: Derek Kiernan, Dragan Cvetic, Arnd Bergmann, Greg Kroah-Hartman,
Michal Simek, linux-arm-kernel
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in a dev_dbg message, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/misc/xilinx_sdfec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 912e939dec62..b25c58ee618c 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -553,7 +553,7 @@ static int xsdfec_reg2_write(struct xsdfec_dev *xsdfec, u32 nlayers, u32 nmqc,
XSDFEC_REG2_NO_FINAL_PARITY_MASK);
if (max_schedule &
~(XSDFEC_REG2_MAX_SCHEDULE_MASK >> XSDFEC_REG2_MAX_SCHEDULE_LSB))
- dev_dbg(xsdfec->dev, "Max Schdule exceeds 2 bits");
+ dev_dbg(xsdfec->dev, "Max Schedule exceeds 2 bits");
max_schedule = ((max_schedule << XSDFEC_REG2_MAX_SCHEDULE_LSB) &
XSDFEC_REG2_MAX_SCHEDULE_MASK);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/3] pwm: atmel: Add link to reference manual
From: Nicolas.Ferre @ 2019-08-19 9:46 UTC (permalink / raw)
To: Claudiu.Beznea, uwe, thierry.reding
Cc: linux-pwm, alexandre.belloni, Ludovic.Desroches, linux-arm-kernel
In-Reply-To: <488f7c7e-6de5-f860-4a48-8f8a67cdcbc6@microchip.com>
On 19/08/2019 at 11:26, Claudiu Beznea - M18063 wrote:
>
>
> On 16.08.2019 00:41, Uwe Kleine-König wrote:
>> The reference manual for at least one of the supported variants is
>> publicly available. Add a link to it at the top of the driver.
>>
>> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
>> ---
>> drivers/pwm/pwm-atmel.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
>> index e5e1eaf372fa..ac3d7a200b9e 100644
>> --- a/drivers/pwm/pwm-atmel.c
>> +++ b/drivers/pwm/pwm-atmel.c
>> @@ -4,6 +4,9 @@
>> *
>> * Copyright (C) 2013 Atmel Corporation
>> * Bo Shen <voice.shen@atmel.com>
>> + *
>> + * Reference manual for "atmel,at91sam9rl-pwm":
>> + * http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11032-32-bit-ARM926EJ-S-Microcontroller-SAM9G25_Datasheet.pdf
>
> Even SAM9G25 PWM have almost the same registers with AT91SAM9RL, the
> datasheet for AT91SAM9RL is located at:
> http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf
> Maybe we should use this one.
>
> I'm not familiar with having reference manuals in this part of the driver
> but if we are doing so would it be feasible to also have links for the rest
> SoCs that introduces new PWM versions? I'm thinking here at all the
> compatibles from atmel_pwm_dt_ids[]:
> - atmel,sama5d3-pwm
> - atmel,sama5d2-pwm
These documents are listed here:
Documentation/arm/microchip.rst
and must be maintained if URL are out of date. I don't believe that we
should add another reference to them in this driver (and other source code).
Referring to the datasheet pointed out by the microchip.rst file is
certainly the way to go...
Regards,
Nicolas
> - microchip,sam9x60-pwm
>
> Although the last one is not already public.
>
>> */
>>
>> #include <linux/clk.h>
>>
--
Nicolas Ferre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox