* Re: [PATCH] ARM: pass -msoft-float to gcc earlier
From: Nick Desaulniers @ 2020-05-20 16:19 UTC (permalink / raw)
To: Szabolcs Nagy, Arnd Bergmann
Cc: Linus Walleij, Russell King, LKML, Masahiro Yamada, nd, Linux ARM
In-Reply-To: <20200520083631.GJ27289@arm.com>
On Wed, May 20, 2020 at 1:36 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 05/19/2020 17:38, Nick Desaulniers wrote:
> > sorry, hit tab/enter too soon...
> >
> > On Tue, May 19, 2020 at 5:37 PM Nick Desaulniers
> > <ndesaulniers@google.com> wrote:
> > >
> > > On Tue, May 19, 2020 at 3:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > >
> > > > Szabolcs Nagy ran into a kernel build failure with a custom gcc
> > > > toochain that sets -mfpu=auto -mfloat-abi=hard:
> > > >
> > > > /tmp/ccmNdcdf.s:1898: Error: selected processor does not support `cpsid i' in ARM mode
> > > >
> > > > The problem is that $(call cc-option, -march=armv7-a) fails before the
> > > > kernel overrides the gcc options to also pass -msoft-float.
> > >
> > > The call to `$(call cc-option, -march=armv7-a) is th
> >
> > The call to `$(call cc-option, -march=armv7-a) is the one that fails or...?
>
> the flag -march=armv7-a is invalid if the float abi
> is hard and no fpu is specified (since gcc-8).
>
> either an fpu should be specified or -march=armv7-a+fp
> (my toolchain was configured with the latter and it does
> not work if the kernel overrides it with -march=armv7-a)
>
> because of this cc-option failure the kernel goes on to
> pass nonsense flags everywhere (-march=armv5t) and some
> compilation eventually fails with an asm error.
Cool, thanks for the additional info. Arnd, if you wanted to include
more of that snippet the commit message when submitting, I wouldn't
complain. :)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
> > > >
> > > > Move the option to the beginning the Makefile, before we call
> > >
> > > beginning of the
> > >
> > > > cc-option for the first time.
> > > >
> > > > Reported-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
> > > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87302
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Moving this looks harmless enough, though it's not clear to me how the
> > > failure you're describing would occur. I don't see calls to as-instr
> > > in arch/arm/Makefile. Which object is being built before -msoft-float
> > > is being set?
> >
> > ... ^
> >
> > >
> > > > ---
> > > > arch/arm/Makefile | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > > > index 7d5cd0f85461..e428ea6eb0fa 100644
> > > > --- a/arch/arm/Makefile
> > > > +++ b/arch/arm/Makefile
> > > > @@ -16,6 +16,8 @@ LDFLAGS_vmlinux += --be8
> > > > KBUILD_LDFLAGS_MODULE += --be8
> > > > endif
> > > >
> > > > +KBUILD_CFLAGS += -msoft-float
> > > > +
> > > > ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
> > > > KBUILD_LDS_MODULE += $(srctree)/arch/arm/kernel/module.lds
> > > > endif
> > > > @@ -135,7 +137,7 @@ AFLAGS_ISA :=$(CFLAGS_ISA)
> > > > endif
> > > >
> > > > # Need -Uarm for gcc < 3.x
> > > > -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> > > > +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -Uarm
> > > > KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> > > >
> > > > CHECKFLAGS += -D__arm__
> > > > --
> > > > 2.26.2
> > > >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers
>
> --
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips
From: Bjorn Helgaas @ 2020-05-20 16:15 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Ulf Hansson,
Heikki Krogerus, Saravana Kannan, Rob Herring, Greg Kroah-Hartman,
Rafael J. Wysocki, Suzuki K Poulose, Julien Grall, open list,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list:DMA MAPPING HELPERS, Stefano Stabellini,
open list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:ARM PORT,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Dan Williams, Robin Murphy, Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200519203419.12369-1-james.quinlan@broadcom.com>
On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
>
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible. This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller. This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.
>
> [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
>
> Jim Quinlan (15):
> PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
> ahci_brcm: fix use of BCM7216 reset controller
> dt-bindings: PCI: Add bindings for more Brcmstb chips
> PCI: brcmstb: Add compatibily of other chips
> PCI: brcmstb: Add suspend and resume pm_ops
> PCI: brcmstb: Asserting PERST is different for 7278
> PCI: brcmstb: Add control of rescal reset
> of: Include a dev param in of_dma_get_range()
> device core: Add ability to handle multiple dma offsets
> dma-direct: Invoke dma offset func if needed
> arm: dma-mapping: Invoke dma offset func if needed
> PCI: brcmstb: Set internal memory viewport sizes
> PCI: brcmstb: Accommodate MSI for older chips
> PCI: brcmstb: Set bus max burst side by chip type
> PCI: brcmstb: add compatilbe chips to match list
If you have occasion to post a v2 for other reasons,
s/PCIE_BRCMSTB depends on ARCH_BRCMSTB/Allow PCIE_BRCMSTB on ARCH_BRCMSTB also/
s/ahci_brcm: fix use of BCM7216 reset controller/ata: ahci_brcm: Fix .../
s/Add compatibily of other chips/Add bcm7278 register info/
s/Asserting PERST is different for 7278/Add bcm7278 PERST support/
s/Set bus max burst side/Set bus max burst size/
s/add compatilbe chips.*/Add bcm7211, bcm7216, bcm7445, bcm7278 to match list/
Rewrap commit logs to use full 75 character lines (to allow for the 4
spaces added by git log).
In commit logs, s/This commit// (use imperative mood instead).
In "Accommodate MSI for older chips" commit log, s/commont/common/.
> .../bindings/pci/brcm,stb-pcie.yaml | 40 +-
> arch/arm/include/asm/dma-mapping.h | 17 +-
> drivers/ata/ahci_brcm.c | 14 +-
> drivers/of/address.c | 54 ++-
> drivers/of/device.c | 2 +-
> drivers/of/of_private.h | 8 +-
> drivers/pci/controller/Kconfig | 4 +-
> drivers/pci/controller/pcie-brcmstb.c | 403 +++++++++++++++---
> include/linux/device.h | 9 +-
> include/linux/dma-direct.h | 16 +
> include/linux/dma-mapping.h | 44 ++
> kernel/dma/Kconfig | 12 +
> 12 files changed, 542 insertions(+), 81 deletions(-)
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [next] i2c: mediatek: Use div_u64 for 64-bit division to fix 32-bit kernels
From: Randy Dunlap @ 2020-05-20 16:15 UTC (permalink / raw)
To: qii.wang, wsa
Cc: devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-i2c, linux-arm-kernel
In-Reply-To: <1589970713-19944-1-git-send-email-qii.wang@mediatek.com>
On 5/20/20 3:31 AM, qii.wang@mediatek.com wrote:
> From: Qii Wang <qii.wang@mediatek.com>
>
> Use div_u64 for 64-bit division, and change sample_ns type to
> unsigned int. Otherwise, the module will reference __udivdi3
> under 32-bit kernels, which is not allowed in kernel space.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
thanks.
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index 7020618..deef69e 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -551,7 +551,8 @@ static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
> const struct i2c_spec_values *spec;
> unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
> unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
> - long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
> + unsigned int sample_ns = div_u64(1000000000ULL * (sample_cnt + 1),
> + clk_src);
>
> if (!i2c->dev_comp->timing_adjust)
> return 0;
>
--
~Randy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: clock_gettime64 vdso bug on 32-bit arm, rpi-4
From: Rich Felker @ 2020-05-20 16:08 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: nd, Arnd Bergmann, Stephen Boyd, Will Deacon,
Russell King - ARM Linux, Linux Kernel Mailing List,
Adhemerval Zanella, Thomas Gleixner, Vincenzo Frascino,
Jack Schmidt, Linux ARM
In-Reply-To: <20200520154128.GA24483@arm.com>
On Wed, May 20, 2020 at 04:41:29PM +0100, Szabolcs Nagy wrote:
> The 05/19/2020 22:31, Arnd Bergmann wrote:
> > On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
> > <adhemerval.zanella@linaro.org> wrote:
> > > On 19/05/2020 16:54, Arnd Bergmann wrote:
> > > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call last
> > > > month: https://github.com/richfelker/musl-cross-make/issues/96 and
> > > > https://github.com/raspberrypi/linux/issues/3579
> > > >
> > > > As Will Deacon pointed out, this was never reported on the mailing list,
> > > > so I'll try to summarize what we know, so this can hopefully be resolved soon.
> > > >
> > > > - This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi patched
> > > > kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
> > > > clock_gettime64(CLOCK_REALTIME)
> > >
> > > Does it happen with other clocks as well?
> >
> > Unclear.
> >
> > > > - The kernel tree is at https://github.com/raspberrypi/linux/, but I could
> > > > see no relevant changes compared to a mainline kernel.
> > >
> > > Is this bug reproducible with mainline kernel or mainline kernel can't be
> > > booted on bcm2711?
> >
> > Mainline linux-5.6 should boot on that machine but might not have
> > all the other features, so I think users tend to use the raspberry pi
> > kernel sources for now.
> >
> > > > - From the report, I see that the returned time value is larger than the
> > > > expected time, by 3.4 to 14.5 million seconds in four samples, my
> > > > guess is that a random number gets added in at some point.
> > >
> > > What kind code are you using to reproduce it? It is threaded or issue
> > > clock_gettime from signal handlers?
> >
> > The reproducer is very simple without threads or signals,
> > see the start of https://github.com/richfelker/musl-cross-make/issues/96
> >
> > It does rely on calling into the musl wrapper, not the direct vdso
> > call.
> >
> > > > - From other sources, I found that the Raspberry Pi clocksource runs
> > > > at 54 MHz, with a mask value of 0xffffffffffffff. From these numbers
> > > > I would expect that reading a completely random hardware register
> > > > value would result in an offset up to 1.33 billion seconds, which is
> > > > around factor 100 more than the error we see, though similar.
> > > >
> > > > - The test case calls the musl clock_gettime() function, which falls back to
> > > > the clock_gettime64() syscall on kernels prior to 5.5, or to the 32-bit
> > > > clock_gettime() prior to Linux-5.1. As reported in the bug, Linux-4.19 does
> > > > not show the bug.
> > > >
> > > > - The behavior was not reproduced on the same user space in qemu,
> > > > though I cannot tell whether the exact same kernel binary was used.
> > > >
> > > > - glibc-2.31 calls the same clock_gettime64() vdso function on arm to
> > > > implement clock_gettime(), but earlier versions did not. I have not
> > > > seen any reports of this bug, which could be explained by users
> > > > generally being on older versions.
> > > >
> > > > - As far as I can tell, there are no reports of this bug from other users,
> > > > and so far nobody could reproduce it.
>
> note: i could not reproduce it in qemu-system with these configs:
>
> qemu-system-aarch64 + arm64 kernel + compat vdso
> qemu-system-aarch64 + kvm accel (on cortex-a72) + 32bit arm kernel
> qemu-system-arm + cpu max + 32bit arm kernel
>
> so i think it's something specific to that user's setup
> (maybe rpi hw bug or gcc miscompiled the vdso or something
> with that particular linux, i built my own linux 5.6 because
> i did not know the exact kernel version where the bug was seen)
>
> i don't have access to rpi (or other cortex-a53 where i
> can install my own kernel) so this is as far as i got.
If we have a binary of the kernel that's known to be failing on the
hardware, it would be useful to dump its vdso and examine the
disassembly to see if it was miscompiled.
Rich
_______________________________________________
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] i2c: pxa: implement generic i2c bus recovery
From: Wolfram Sang @ 2020-05-20 15:59 UTC (permalink / raw)
To: Russell King
Cc: Andrew Lunn, Jason Cooper, devicetree, Gregory Clement,
Vladimir Vid, Rob Herring, linux-i2c, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <E1jYnlI-0002Nw-83@rmk-PC.armlinux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 279 bytes --]
On Wed, May 13, 2020 at 10:33:12AM +0100, Russell King wrote:
> Implement generic GPIO-based I2C bus recovery for the PXA I2C driver.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied to for-next, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Mike Rapoport @ 2020-05-20 15:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-mtd, Boris Brezillon, Robert Jarzmik, Linux ARM,
Miquel Raynal
In-Reply-To: <CAK8P3a2+auSWBROZR-hobM_qSWtKiG1DRYP3Y7uvbCy_ZLy+gg@mail.gmail.com>
On Wed, May 20, 2020 at 05:21:51PM +0200, Arnd Bergmann wrote:
> On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> >
> > As these boards have no more users nor testers, and patching them has
> > become a burden, be that because of the PCI part or the MTD NAND
> > support, let's remove them.
> >
> > The cm-x300 will for now remain and represent Compulab boards at its
> > best in the PXA department.
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
I've not been PXA development for a while, so FWIW
Acked-by: Mike Rapoport <rppt@kernel.org>
> Should we take the series through the soc tree? If so, please
> send them to soc@kernel.org if there are no objections;
> or along with other patches you might have in the pull requests.
>
> Arnd
--
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] ARM: dts: bcm: HR2: Fix PPI interrupt types
From: Florian Fainelli @ 2020-05-20 15:56 UTC (permalink / raw)
To: Hamish Martin, robh+dt, rjui, sbranden; +Cc: devicetree, linux-arm-kernel
In-Reply-To: <20200520043042.7281-1-hamish.martin@alliedtelesis.co.nz>
On 5/19/2020 9:30 PM, Hamish Martin wrote:
> These error messages are output when booting on a BCM HR2 system:
> GIC: PPI11 is secure or misconfigured
> GIC: PPI13 is secure or misconfigured
>
> Per ARM documentation these interrupts are triggered on a rising edge.
> See ARM Cortex A-9 MPCore Technical Reference Manual, Revision r4p1,
> Section 3.3.8 Interrupt Configuration Registers.
>
> The same issue was resolved for NSP systems in commit 5f1aa51c7a1e
> ("ARM: dts: NSP: Fix PPI interrupt types").
>
> Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Thanks Hamish, this should also have a:
Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")
I will take care of adding it while applying, thanks!
> ---
> arch/arm/boot/dts/bcm-hr2.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
> index 6142c672811e..5e5f5ca3c86f 100644
> --- a/arch/arm/boot/dts/bcm-hr2.dtsi
> +++ b/arch/arm/boot/dts/bcm-hr2.dtsi
> @@ -75,7 +75,7 @@ a9pll: arm_clk@0 {
> timer@20200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x20200 0x100>;
> - interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>;
> clocks = <&periph_clk>;
> };
>
> @@ -83,7 +83,7 @@ twd-timer@20600 {
> compatible = "arm,cortex-a9-twd-timer";
> reg = <0x20600 0x20>;
> interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) |
> - IRQ_TYPE_LEVEL_HIGH)>;
> + IRQ_TYPE_EDGE_RISING)>;
> clocks = <&periph_clk>;
> };
>
> @@ -91,7 +91,7 @@ twd-watchdog@20620 {
> compatible = "arm,cortex-a9-twd-wdt";
> reg = <0x20620 0x20>;
> interrupts = <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) |
> - IRQ_TYPE_LEVEL_HIGH)>;
> + IRQ_TYPE_EDGE_RISING)>;
> clocks = <&periph_clk>;
> };
>
>
--
Florian
_______________________________________________
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] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
From: Catalin Marinas @ 2020-05-20 15:47 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, Suzuki K Poulose, Anshuman Khandual, linux-kernel,
Mark Brown, linux-arm-kernel
In-Reply-To: <20200520122012.GA25815@willie-the-truck>
On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
> > There is no way to proceed when requested register could not be searched in
> > arm64_ftr_reg[]. Requesting for a non present register would be an error as
> > well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
> > rather than checking for return value and doing the same in some individual
> > callers.
> >
> > But there are some callers that dont BUG_ON() upon search failure. It adds
> > an argument 'failsafe' that provides required switch between callers based
> > on whether they could proceed or not.
> >
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > ---
> > Applies on next-20200518 that has recent cpufeature changes from Will.
> >
> > arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
> > 1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index bc5048f152c1..62767cc540c3 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
> > * - NULL on failure. It is upto the caller to decide
> > * the impact of a failure.
> > */
> > -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
> > +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
>
> Generally, I'm not a big fan of boolean arguments because they are really
> opaque at the callsite. It also seems bogus to me that we don't trust the
> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
> which seems to mean "I promise to check the result isn't NULL before
> dereferencing it."
>
> So I don't see how this patch improves anything. I'd actually be more
> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
> have the callers handle NULL by returning early, getting rid of all the
> BUG_ONs in here. Sure, the system might end up in a funny state, but we
> WARN()d about it and tried to keep going (and Linus has some strong opinions
> on this too).
Such WARN can be triggered by the user via emulate_sys_reg(), so we
can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 3/5] ARM: dts: add Protonic VT7 board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, Robin van der Gracht, linux-kernel,
Oleksij Rempel, NXP Linux Team, Pengutronix Kernel Team,
David Jander, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
The Protonic VT7 is a mid-class ISObus Virtual Terminal with a 7 inch
touchscreen display.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtvt7.dts | 411 ++++++++++++++++++++++++++++
2 files changed, 412 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8ce744f1cbfc9..66ee89e7929f9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtvt7.dts b/arch/arm/boot/dts/imx6dl-prtvt7.dts
new file mode 100644
index 0000000000000..083eb72f5fc3d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtvt7.dts
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2016 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic VT7";
+ compatible = "prt,prtvt7", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x20000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm1 0 500000>;
+ brightness-levels = <0 20 81 248 1000>;
+ default-brightness-level = <20>;
+ num-interpolated-steps = <21>;
+ power-supply = <®_bl_12v0>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ esc {
+ label = "GPIO Key ESC";
+ linux,code = <KEY_ESC>;
+ gpios = <&gpio_pca 0 GPIO_ACTIVE_LOW>;
+ };
+
+ up {
+ label = "GPIO Key UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio_pca 1 GPIO_ACTIVE_LOW>;
+ };
+
+ down {
+ label = "GPIO Key DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio_pca 4 GPIO_ACTIVE_LOW>;
+ };
+
+ enter {
+ label = "GPIO Key Enter";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio_pca 3 GPIO_ACTIVE_LOW>;
+ };
+
+ cycle {
+ label = "GPIO Key CYCLE";
+ linux,code = <KEY_CYCLEWINDOWS>;
+ gpios = <&gpio_pca 2 GPIO_ACTIVE_LOW>;
+ };
+
+ f1 {
+ label = "GPIO Key F1";
+ linux,code = <KEY_F1>;
+ gpios = <&gpio_pca 14 GPIO_ACTIVE_LOW>;
+ };
+
+ f2 {
+ label = "GPIO Key F2";
+ linux,code = <KEY_F2>;
+ gpios = <&gpio_pca 13 GPIO_ACTIVE_LOW>;
+ };
+
+ f3 {
+ label = "GPIO Key F3";
+ linux,code = <KEY_F3>;
+ gpios = <&gpio_pca 12 GPIO_ACTIVE_LOW>;
+ };
+
+ f4 {
+ label = "GPIO Key F4";
+ linux,code = <KEY_F4>;
+ gpios = <&gpio_pca 11 GPIO_ACTIVE_LOW>;
+ };
+
+ f5 {
+ label = "GPIO Key F5";
+ linux,code = <KEY_F5>;
+ gpios = <&gpio_pca 10 GPIO_ACTIVE_LOW>;
+ };
+
+ f6 {
+ label = "GPIO Key F6";
+ linux,code = <KEY_F6>;
+ gpios = <&gpio_pca 5 GPIO_ACTIVE_LOW>;
+ };
+
+ f7 {
+ label = "GPIO Key F7";
+ linux,code = <KEY_F7>;
+ gpios = <&gpio_pca 6 GPIO_ACTIVE_LOW>;
+ };
+
+ f8 {
+ label = "GPIO Key F8";
+ linux,code = <KEY_F8>;
+ gpios = <&gpio_pca 7 GPIO_ACTIVE_LOW>;
+ };
+
+ f9 {
+ label = "GPIO Key F9";
+ linux,code = <KEY_F9>;
+ gpios = <&gpio_pca 8 GPIO_ACTIVE_LOW>;
+ };
+
+ f10 {
+ label = "GPIO Key F10";
+ linux,code = <KEY_F10>;
+ gpios = <&gpio_pca 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_bl_12v0: regulator-bl-12v0 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_bl_12v0>;
+ regulator-name = "bl-12v0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+};
+
+&i2c1 {
+ sgtl5000: codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_codec>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+&i2c3 {
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ gpio_pca: gpio@74 {
+ compatible = "nxp,pca9539";
+ reg = <0x74>;
+ interrupts-extended = <&gpio4 5 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+};
+
+&ipu1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu1_csi0>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "i2s-slave";
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
+ >;
+ };
+
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_codec: codecgrp {
+ fsl,pins = <
+ /* AUDIO_nRESET */
+ MX6QDL_PAD_CSI0_VSYNC__GPIO5_IO21 0x1f0b0
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ipu1_csi0: ipu1csi0grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x1b0b0
+ MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x1b0b0
+ MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+ /* ITU656_nRESET */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ /* ITU656_nPDN */
+ MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20 0x1b0b0
+ >;
+ };
+
+ pinctrl_ipu1_disp: ipudisp1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0xb0
+ MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00 0xb0
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0xb0
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0xb0
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0xb0
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0xb0
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0xb0
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0xb0
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0xb0
+
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0xb0
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0xb0
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0xb0
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0xb0
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0xb0
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0xb0
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0xb0
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0xb0
+
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0xb0
+ MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0xb0
+ MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0xb0
+ MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0xb0
+ MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0xb0
+ MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0xb0
+ MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0xb0
+ MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0xb0
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_reg_bl_12v0: 12blgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+ >;
+ };
+};
--
2.26.2
_______________________________________________
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 v8 1/5] ARM: dts: add Protonic PRTI6Q board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, linux-kernel, Oleksij Rempel,
NXP Linux Team, Pengutronix Kernel Team, David Jander,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Protonic PRTI6Q is a development board and a base class for different
specific customer application boards based on the i.MX6 family of SoCs,
developed by Protonic Holland.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-prti6q.dts | 541 ++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 165 ++++++++
3 files changed, 707 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd992013973..206a36a50575e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -538,6 +538,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-nymph.dtb \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
+ imx6q-prti6q.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prti6q.dts b/arch/arm/boot/dts/imx6q-prti6q.dts
new file mode 100644
index 0000000000000..d8ea9a3f415a8
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prti6q.dts
@@ -0,0 +1,541 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/sound/fsl-imx-audmux.h>
+
+/ {
+ model = "Protonic PRTI6Q board";
+ compatible = "prt,prti6q", "fsl,imx6q";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0xf0000000>;
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm1 0 5000000>;
+ brightness-levels = <0 16 64 255>;
+ num-interpolated-steps = <16>;
+ default-brightness-level = <16>;
+ power-supply = <®_3v3>;
+ enable-gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ };
+
+ can_osc: can-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-debug1 {
+ function = LED_FUNCTION_SD;
+ gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "disk-activity";
+ };
+ };
+
+ panel {
+ compatible = "kyo,tcg121xglp";
+ backlight = <&backlight_lcd>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ enable-active-high;
+ gpio = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "regulator-WL12xx";
+ startup-delay-us = <70000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "prti6q-sgtl5000";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Line", "Line In Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "External Speaker", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&ssi1>;
+ system-clock-frequency = <0>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ bitclock-master;
+ frame-master;
+ };
+ };
+
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-in;
+ spdif-out;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+
+ mux_ssi1 {
+ fsl,audmux-port = <0>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN 0
+ IMX_AUDMUX_V2_PTCR_TFSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TCSEL(2) 0
+ IMX_AUDMUX_V2_PTCR_TFSDIR 0
+ IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2)
+ >;
+ };
+
+ mux_pins3 {
+ fsl,audmux-port = <2>;
+ fsl,port-config = <
+ IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0)
+ 0 IMX_AUDMUX_V2_PDCR_TXRXEN
+ >;
+ };
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can2>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>, <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>;
+ status = "okay";
+
+ can@0 {
+ compatible = "microchip,mcp2515";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can3>;
+ clocks = <&can_osc>;
+ interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <5000000>;
+ };
+
+ adc@1 {
+ compatible = "ti,adc128s052";
+ reg = <1>;
+ spi-max-frequency = <2000000>;
+ vref-supply = <®_3v3>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ phy-handle = <&rgmii_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Microchip KSZ9031RNX PHY */
+ rgmii_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <300>;
+ };
+ };
+};
+
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ ddc-i2c-bus = <&i2c2>;
+ status = "okay";
+};
+
+&i2c1 {
+ sgtl5000: audio-codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 201>;
+ VDDA-supply = <®_3v3>;
+ VDDIO-supply = <®_3v3>;
+ VDDD-supply = <®_1v8>;
+ };
+};
+
+/* DDC */
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* can2_l */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can2_h */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&spdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif>;
+ status = "okay";
+};
+
+&ssi1 {
+ #sound-dai-cells = <0>;
+ fsl,mode = "ac97-slave";
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbotg {
+ pinctrl-0 = <&pinctrl_usbotg &pinctrl_usbotg_id>;
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ non-removable;
+ vmmc-supply = <®_wifi>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ status = "okay";
+
+ wifi {
+ compatible = "ti,wl1271";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi>;
+ interrupts-extended = <&gpio1 30 IRQ_TYPE_LEVEL_HIGH>;
+ ref-clock-frequency = "38400000";
+ tcxo-clock-frequency = "19200000";
+ };
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1 0x030b0
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28 0x1b0b0
+ >;
+ };
+
+ pinctrl_can2: can2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x80000000
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x80000000
+ >;
+ };
+
+ pinctrl_can3: can3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+ MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+ MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+ MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi2_cs: ecspi2csgrp {
+ fsl,pins = <
+ /* ADC128S022 CS */
+ MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x10030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x10030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x10030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x10030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x10030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x10030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x10030
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x10030
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x10030
+
+ /* Phy reset */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x1b0b1
+ >;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <
+ /* NOTE: DDC is done via I2C2, so DON'T
+ * configure DDC pins for HDMI!
+ */
+ MX6QDL_PAD_EIM_A25__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ /* DDC */
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__PWM1_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_spdif: spdifgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_16__SPDIF_IN 0x1b0b0
+ MX6QDL_PAD_GPIO_19__SPDIF_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D26__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D27__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D28__UART2_DTE_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D29__UART2_DTE_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg_id: usbotgidgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x1f058
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ /* WL12xx IRQ */
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x10880
+ >;
+ };
+
+ pinctrl_wifi_npd: wifinpd {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1b8b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6qdl-prti6q.dtsi b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
new file mode 100644
index 0000000000000..b9ac70b9a4513
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ chosen {
+ stdout-path = &uart4;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "h1-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usb_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "otg-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ temperature-sensor@70 {
+ compatible = "ti,tmp103";
+ reg = <0x70>;
+ };
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "utmi";
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can1: can1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x80000000
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x80000000
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001f8b1
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001f8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x170f9
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ MX6QDL_PAD_GPIO_1__GPIO1_IO01 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17099
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10099
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17099
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17099
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17099
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17099
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17099
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17099
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17099
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17099
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__USB_OTG_OC 0x1b0b0
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
+ >;
+ };
+};
--
2.26.2
_______________________________________________
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: clock_gettime64 vdso bug on 32-bit arm, rpi-4
From: Szabolcs Nagy @ 2020-05-20 15:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: nd, Rich Felker, Stephen Boyd, Will Deacon,
Russell King - ARM Linux, Linux Kernel Mailing List,
Adhemerval Zanella, Thomas Gleixner, Vincenzo Frascino,
Jack Schmidt, Linux ARM
In-Reply-To: <CAK8P3a3fxs+14ZdCRmt_GwJGv3Aipm1r9sAHH6aVj2UrWBNuQQ@mail.gmail.com>
The 05/19/2020 22:31, Arnd Bergmann wrote:
> On Tue, May 19, 2020 at 10:24 PM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
> > On 19/05/2020 16:54, Arnd Bergmann wrote:
> > > Jack Schmidt reported a bug for the arm32 clock_gettimeofday64 vdso call last
> > > month: https://github.com/richfelker/musl-cross-make/issues/96 and
> > > https://github.com/raspberrypi/linux/issues/3579
> > >
> > > As Will Deacon pointed out, this was never reported on the mailing list,
> > > so I'll try to summarize what we know, so this can hopefully be resolved soon.
> > >
> > > - This happened reproducibly on Linux-5.6 on a 32-bit Raspberry Pi patched
> > > kernel running on a 64-bit Raspberry Pi 4b (bcm2711) when calling
> > > clock_gettime64(CLOCK_REALTIME)
> >
> > Does it happen with other clocks as well?
>
> Unclear.
>
> > > - The kernel tree is at https://github.com/raspberrypi/linux/, but I could
> > > see no relevant changes compared to a mainline kernel.
> >
> > Is this bug reproducible with mainline kernel or mainline kernel can't be
> > booted on bcm2711?
>
> Mainline linux-5.6 should boot on that machine but might not have
> all the other features, so I think users tend to use the raspberry pi
> kernel sources for now.
>
> > > - From the report, I see that the returned time value is larger than the
> > > expected time, by 3.4 to 14.5 million seconds in four samples, my
> > > guess is that a random number gets added in at some point.
> >
> > What kind code are you using to reproduce it? It is threaded or issue
> > clock_gettime from signal handlers?
>
> The reproducer is very simple without threads or signals,
> see the start of https://github.com/richfelker/musl-cross-make/issues/96
>
> It does rely on calling into the musl wrapper, not the direct vdso
> call.
>
> > > - From other sources, I found that the Raspberry Pi clocksource runs
> > > at 54 MHz, with a mask value of 0xffffffffffffff. From these numbers
> > > I would expect that reading a completely random hardware register
> > > value would result in an offset up to 1.33 billion seconds, which is
> > > around factor 100 more than the error we see, though similar.
> > >
> > > - The test case calls the musl clock_gettime() function, which falls back to
> > > the clock_gettime64() syscall on kernels prior to 5.5, or to the 32-bit
> > > clock_gettime() prior to Linux-5.1. As reported in the bug, Linux-4.19 does
> > > not show the bug.
> > >
> > > - The behavior was not reproduced on the same user space in qemu,
> > > though I cannot tell whether the exact same kernel binary was used.
> > >
> > > - glibc-2.31 calls the same clock_gettime64() vdso function on arm to
> > > implement clock_gettime(), but earlier versions did not. I have not
> > > seen any reports of this bug, which could be explained by users
> > > generally being on older versions.
> > >
> > > - As far as I can tell, there are no reports of this bug from other users,
> > > and so far nobody could reproduce it.
note: i could not reproduce it in qemu-system with these configs:
qemu-system-aarch64 + arm64 kernel + compat vdso
qemu-system-aarch64 + kvm accel (on cortex-a72) + 32bit arm kernel
qemu-system-arm + cpu max + 32bit arm kernel
so i think it's something specific to that user's setup
(maybe rpi hw bug or gcc miscompiled the vdso or something
with that particular linux, i built my own linux 5.6 because
i did not know the exact kernel version where the bug was seen)
i don't have access to rpi (or other cortex-a53 where i
can install my own kernel) so this is as far as i got.
> > >
> > > - The current musl git tree has been patched to not call clock_gettime64
> > > on ARM because of this problem, so it cannot be used for reproducing it.
> >
> > So should glibc follow musl and remove arm clock_gettime6y4 vDSO support
> > or this bug is localized to an specific kernel version running on an
> > specific hardware?
>
> I hope we can figure out what is actually going on soon, there is probably
> no need to change glibc before we have.
>
> Arnd
--
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 0/5] mainline Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, linux-kernel, Oleksij Rempel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
changes v8:
- resend correct changes
changes v7:
- VT7: reorder node alphabetically
- VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
- VT7: remove panel and TS nodes. This drivers are currently not
mainline.
- prti6q.dtsi: move reg_1v8 to prti6q.dts
- prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
every board file.
changes v6:
- move fsl.yaml changes to separate patch
- remove partitions, they are provided by the bootloader
- update flash compatible
- rename can3 to can
- fix fsl,mode
- fix interrupt in the wlan node on PRTI6Q
changes v5:
- PRTI6Q: remove status from the pwm-backlight node
- drop the vendor-prefixes patch, it is already taken by Rob
- add Reviewed-by: Rob Herring <robh@kernel.org>
changes v4:
- VT7: fix typo
changes v3:
- move compatible to the start of node
- move status to the end
- use generic names in compatible
- refactor dts/dtsi
- use alphabet order for pinctrl and phandels
- remove unused or currently not supported nodes
changes v2:
- squash PRTI6Q patches
Oleksij Rempel (5):
ARM: dts: add Protonic PRTI6Q board
ARM: dts: add Protonic WD2 board
ARM: dts: add Protonic VT7 board
ARM: dts: add Protonic RVT board
dt-bindings: arm: fsl: add different Protonic boards
.../devicetree/bindings/arm/fsl.yaml | 4 +
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++
arch/arm/boot/dts/imx6dl-prtvt7.dts | 411 +++++++++++++
arch/arm/boot/dts/imx6q-prti6q.dts | 541 ++++++++++++++++++
arch/arm/boot/dts/imx6q-prtwd2.dts | 188 ++++++
arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 165 ++++++
7 files changed, 1495 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 2/5] ARM: dts: add Protonic WD2 board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, linux-kernel, Oleksij Rempel,
NXP Linux Team, Pengutronix Kernel Team, David Jander,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Add support for the Protonic WD2 board, which is an internal development
platform for low-cost agricultural Virtual Terminals based on COTS tablets
and web applications.
It inherits from the PRTI6Q base class.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +++++++++++++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 206a36a50575e..8ce744f1cbfc9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -539,6 +539,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-pico-pi.dtb \
imx6q-pistachio.dtb \
imx6q-prti6q.dtb \
+ imx6q-prtwd2.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
diff --git a/arch/arm/boot/dts/imx6q-prtwd2.dts b/arch/arm/boot/dts/imx6q-prtwd2.dts
new file mode 100644
index 0000000000000..fd9f457a273e2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-prtwd2.dts
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2018 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Protonic WD2 board";
+ compatible = "prt,prtwd2", "fsl,imx6q";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x20000000>;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+
+ usdhc2_wifi_pwrseq: usdhc2_wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wifi_npd>;
+ reset-gpios = <&gpio6 10 GPIO_ACTIVE_LOW>;
+ };
+
+ /* PRTWD2 rev 1 bitbang I2C for Ethernet Switch */
+ i2c@4 {
+ compatible = "i2c-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ sda-gpios = <&gpio1 22 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio1 31 GPIO_ACTIVE_HIGH>;
+ i2c-gpio,delay-us = <20>; /* ~10 kHz */
+ i2c-gpio,scl-output-only;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ clocks = <&clks IMX6QDL_CLK_ENET>,
+ <&clks IMX6QDL_CLK_ENET>;
+ clock-names = "ipg", "ahb";
+ status = "okay";
+
+ fixed-link {
+ speed = <100>;
+ pause;
+ full-duplex;
+ };
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* V in */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* I charge */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* V bus */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+
+ /* nc */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <1>;
+ ti,datarate = <3>;
+ };
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ non-removable;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc2_wifi_pwrseq>;
+ pm-ignore-notify;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_eth_chg>;
+
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ /* MX6QDL_ENET_PINGRP4 */
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x130b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0
+ /* Phy reset */
+ MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22 0x1b0b0
+ /* nINTRP */
+ MX6QDL_PAD_CSI0_DAT5__GPIO5_IO23 0x1b0b0
+
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x10030
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x10030
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__GPIO1_IO22 0x1f8b0
+ MX6QDL_PAD_ENET_MDC__GPIO1_IO31 0x1f8b0
+ >;
+ };
+
+ pinctrl_usb_eth_chg: usbethchggrp {
+ fsl,pins = <
+ /* USB charging control */
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x130b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x130b0
+ MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x130b0
+ MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x130b0
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_wifi_npd: wifinpd {
+ fsl,pins = <
+ /* WL_REG_ON */
+ MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x13069
+ >;
+ };
+};
--
2.26.2
_______________________________________________
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 v8 4/5] ARM: dts: add Protonic RVT board
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, Rob Herring, linux-kernel, Oleksij Rempel,
NXP Linux Team, Pengutronix Kernel Team, David Jander,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Protonic RVT is an internal development platform for a wireless ISObus
Virtual Terminal based on COTS tablets, and the predecessor of the WD2
platform.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++++++++++++++++++++++++
2 files changed, 183 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 66ee89e7929f9..89842a034e4ba 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -450,6 +450,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-pico-hobbit.dtb \
imx6dl-pico-nymph.dtb \
imx6dl-pico-pi.dtb \
+ imx6dl-prtrvt.dtb \
imx6dl-prtvt7.dtb \
imx6dl-rex-basic.dtb \
imx6dl-riotboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-prtrvt.dts b/arch/arm/boot/dts/imx6dl-prtrvt.dts
new file mode 100644
index 0000000000000..b7721e52a463a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-prtrvt.dts
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2014 Protonic Holland
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-prti6q.dtsi"
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Protonic RVT board";
+ compatible = "prt,prtrvt", "fsl,imx6dl";
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x10000000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds>;
+
+ led-debug0 {
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&can1 {
+ pinctrl-0 = <&pinctrl_can1 &pinctrl_can1phy>;
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+
+ nfc@0 {
+ compatible = "ti,trf7970a";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc>;
+ spi-max-frequency = <2000000>;
+ interrupts-extended = <&gpio5 14 IRQ_TYPE_LEVEL_LOW>;
+ ti,enable-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>,
+ <&gpio5 11 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_3v3>;
+ vin-voltage-override = <3100000>;
+ autosuspend-delay = <30000>;
+ irq-status-read-quirk;
+ en2-rf-quirk;
+ t5t-rmb-extra-byte-quirk;
+ status = "okay";
+ };
+};
+
+&i2c3 {
+ adc@49 {
+ compatible = "ti,ads1015";
+ reg = <0x49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* nc */
+ channel@4 {
+ reg = <4>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* nc */
+ channel@5 {
+ reg = <5>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_l */
+ channel@6 {
+ reg = <6>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+
+ /* can1_h */
+ channel@7 {
+ reg = <7>;
+ ti,gain = <3>;
+ ti,datarate = <3>;
+ };
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&usbh1 {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
+
+&iomuxc {
+ pinctrl_can1phy: can1phy {
+ fsl,pins = <
+ /* CAN1_SR */
+ MX6QDL_PAD_KEY_COL3__GPIO4_IO12 0x13070
+ /* CAN1_TERM */
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
+ MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
+ MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
+ /* CS */
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x000b1
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x000b1
+ >;
+ };
+
+ pinctrl_leds: ledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ >;
+ };
+
+ pinctrl_nfc: nfcgrp {
+ fsl,pins = <
+ /* NFC_ASK_OOK */
+ MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09 0x100b1
+ /* NFC_PWR_EN */
+ MX6QDL_PAD_DISP0_DAT16__GPIO5_IO10 0x100b1
+ /* NFC_EN2 */
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x100b1
+ /* NFC_EN */
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x100b1
+ /* NFC_MOD */
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x100b1
+ /* NFC_IRQ */
+ MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14 0x100b1
+ >;
+ };
+};
--
2.26.2
_______________________________________________
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 v8 5/5] dt-bindings: arm: fsl: add different Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:41 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, linux-kernel, Oleksij Rempel, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520154116.12909-1-o.rempel@pengutronix.de>
Add Protonic PRTI6Q, WD2, RVT, VT7 boards.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index cd3fbe7e39487..a1657505b3357 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -119,6 +119,8 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
+ - prt,prti6q # Protonic PRTI6Q board
+ - prt,prtwd2 # Protonic WD2 board
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
@@ -170,6 +172,8 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
+ - prt,prtrvt # Protonic RVT board
+ - prt,prtvt7 # Protonic VT7 board
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
--
2.26.2
_______________________________________________
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: [TEGRA194_CPUFREQ Patch 1/3] firmware: tegra: adding function to get BPMP data
From: Thierry Reding @ 2020-05-20 15:38 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Mikko Perttunen, open list:THERMAL, Viresh Kumar,
Rafael J. Wysocki, linux-kernel@vger.kernel.org, Jon Hunter,
Timo Alho, bbasu, Catalin Marinas, linux-tegra, Sumit Gupta,
Mikko Perttunen, Will Deacon,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+rMYAZ=ub0U7qdHSsWgbQugodhvigFCxrFm49HwrCmAQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7097 bytes --]
On Wed, May 20, 2020 at 08:43:03AM -0600, Rob Herring wrote:
> On Tue, Apr 7, 2020 at 4:05 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Dec 04, 2019 at 03:21:38PM +0530, Viresh Kumar wrote:
> > > On 04-12-19, 10:33, Thierry Reding wrote:
> > > > Yeah, the code that registers this device is in drivers/base/cpu.c in
> > > > register_cpu(). It even retrieves the device tree node for the CPU from
> > > > device tree and stores it in cpu->dev.of_node, so we should be able to
> > > > just pass &cpu->dev to tegra_bpmp_get() in order to retrieve a reference
> > > > to the BPMP.
> > > >
> > > > That said, I'm wondering if perhaps we could just add a compatible
> > > > string to the /cpus node for cases like this where we don't have an
> > > > actual device representing the CPU complex. There are a number of CPU
> > > > frequency drivers that register dummy devices just so that they have
> > > > something to bind a driver to.
> > > >
> > > > If we allow the /cpus node to represent the CPU complex (if no other
> > > > "device" does that yet), we can add a compatible string and have the
> > > > cpufreq driver match on that.
> > > >
> > > > Of course this would be slightly difficult to retrofit into existing
> > > > drivers because they'd need to remain backwards compatible with existing
> > > > device trees. But it would allow future drivers to do this a little more
> > > > elegantly. For some SoCs this may not matter, but especially once you
> > > > start depending on additional resources this would come in handy.
> > > >
> > > > Adding Rob and the device tree mailing list for feedback on this idea.
> > >
> > > Took some time to find this thread, but something around this was
> > > suggested by Rafael earlier.
> > >
> > > https://lore.kernel.org/lkml/8139001.Q4eV8YG1Il@vostro.rjw.lan/
> >
> > I gave this a try and came up with the following:
> >
> > --- >8 ---
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index f4ede86e32b4..e4462f95f0b3 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -1764,6 +1764,9 @@ bpmp_thermal: thermal {
> > };
> >
> > cpus {
> > + compatible = "nvidia,tegra194-ccplex";
> > + nvidia,bpmp = <&bpmp>;
>
> Is there more than 1 bpmp? If not you don't need this. Just lookup the
> node by compatible.
There no SoCs currently than need to differentiate between multiple
BPMPs, so yes, it would be possible to look up the node by compatible.
But we also used to assume that PCs would only ever come with a single
GPU or audio card and that's always caused a lot of work to clean up
when it turned out to no longer be true.
Also, we already have a couple of devices referencing the BPMP by
phandle like this, so having this in a CCPLEX node would keep things
consistent.
One of the reasons why we initially did it this way was also so that we
could make the dependencies explicit within device tree. If we look up
by compatible string, then the driver is the only one with the knowledge
about where to get at it. If we have the explicit reference we at least
have a chance of determining the dependency by just looking at the
device tree.
> > +
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > --- >8 ---
> >
> > Now I can do something rougly like this, although I have a more complete
> > patch locally that also gets rid of all the global variables because we
> > now actually have a struct platform_device that we can anchor everything
> > at:
> >
> > --- >8 ---
> > static const struct of_device_id tegra194_cpufreq_of_match[] = {
> > { .compatible = "nvidia,tegra194-ccplex", },
> > { /* sentinel */ }
> > };
> > MODULE_DEVICE_TABLE(of, tegra194_cpufreq_of_match);
> >
> > static struct platform_driver tegra194_ccplex_driver = {
> > .driver = {
> > .name = "tegra194-cpufreq",
> > .of_match_table = tegra194_cpufreq_of_match,
> > },
> > .probe = tegra194_cpufreq_probe,
> > .remove = tegra194_cpufreq_remove,
> > };
> > module_platform_driver(tegra194_ccplex_driver);
> > --- >8 ---
> >
> > I don't think that's exactly what Rafael (Cc'ed) had in mind, since the
> > above thread seems to have mostly talked about binding a driver to each
> > individual CPU.
> >
> > But this seems a lot better than having to instantiate a device from
> > scratch just so that a driver can bind to it and it allows additional
> > properties to be associated with the CCPLEX device.
>
> What additional properties? A continual stream of properties added 1
> by 1 would negatively affect my opinion of this.
I don't expect there would be many. I think there's an earlier
generation of Tegra that requires a regulator and I can imagine that's
pretty common. But other than that I would expect this to be a fairly
narrow set of properties.
> > Rob, any thoughts on this from a device tree point of view? The /cpus
> > bindings don't mention the compatible property, but there doesn't seem
> > to be anything in the bindings that would prohibit its use.
>
> What happens when you have more than one cpu related driver in
> addition to cpufreq? You may still have to end up creating child
> platform devices and then gained very little.
That's only if you absolutely want to stick with the "one driver per
subsystem" model. I personally think that's completely obsolete these
days. If you have a CPU complex device that can do both CPU frequency
scaling and put the CPU into idle states, for example, then there is
really no reason to artificially split that into two separate drivers
just to match the subsystems that we have.
Most subsystems that I've come across work just fine if a single driver
registers with multiple subsystems.
I also know that some people like it better when things are nicely split
up into multiple drivers. But I really don't see how that simplifies
things. In fact in my opinion that makes things only more complicated
because you have additional boilerplate and then you need to be extra
careful about how these different drivers are ordered, and you need to
take extra precautions when sharing things like clocks and register
regions.
> You could solve this without DT changes. You can bind on node names.
> The driver probe can then check the parent compatible and return if
> not matching. I'm not sure if you could get module auto loading to
> work in that case. It would have to be based on the root compatible
> (rather than the driver match table) and be able to load multiple
> matching modules.
That sounds like it would get very complicated for something this
simple. Having a compatible string in /cpus seemed like the most logical
option because it would basically just work out of the box and the same
way we're used to from other devices.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/4] iommu/amd: Use pci_ats_supported()
From: Jean-Philippe Brucker @ 2020-05-20 15:22 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, Joerg Roedel, ashok.raj, will, hch,
alex.williamson, robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200520152201.3309416-1-jean-philippe@linaro.org>
The pci_ats_supported() function checks if a device supports ATS and is
allowed to use it. In addition to checking that the device has an ATS
capability and that the global pci=noats is not set
(pci_ats_disabled()), it also checks if a device is untrusted.
A device is untrusted if it is plugged into an external-facing port such
as Thunderbolt and could be spoofing an existing device to exploit
weaknesses in the IOMMU configuration. By calling pci_ats_supported() we
keep DTE[I]=0 for untrusted devices and abort transactions with
Pretranslated Addresses.
Reviewed-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/amd_iommu.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 1dc3718560d0..8b7a9e811d33 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -313,16 +313,15 @@ static struct iommu_group *acpihid_device_group(struct device *dev)
static bool pci_iommuv2_capable(struct pci_dev *pdev)
{
static const int caps[] = {
- PCI_EXT_CAP_ID_ATS,
PCI_EXT_CAP_ID_PRI,
PCI_EXT_CAP_ID_PASID,
};
int i, pos;
- if (pci_ats_disabled())
+ if (!pci_ats_supported(pdev))
return false;
- for (i = 0; i < 3; ++i) {
+ for (i = 0; i < 2; ++i) {
pos = pci_find_ext_capability(pdev, caps[i]);
if (pos == 0)
return false;
@@ -3150,11 +3149,8 @@ int amd_iommu_device_info(struct pci_dev *pdev,
memset(info, 0, sizeof(*info));
- if (!pci_ats_disabled()) {
- pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS);
- if (pos)
- info->flags |= AMD_IOMMU_DEVICE_FLAG_ATS_SUP;
- }
+ if (pci_ats_supported(pdev))
+ info->flags |= AMD_IOMMU_DEVICE_FLAG_ATS_SUP;
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PRI);
if (pos)
--
2.26.2
_______________________________________________
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 v2 4/4] iommu/vt-d: Use pci_ats_supported()
From: Jean-Philippe Brucker @ 2020-05-20 15:22 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, hch, alex.williamson,
robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200520152201.3309416-1-jean-philippe@linaro.org>
The pci_ats_supported() helper checks if a device supports ATS and is
allowed to use it. By checking the ATS capability it also integrates the
pci_ats_disabled() check from pci_ats_init(). Simplify the vt-d checks.
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/intel-iommu.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0182cff2c7ac..ed21ce6d1238 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1454,8 +1454,7 @@ static void iommu_enable_dev_iotlb(struct device_domain_info *info)
!pci_reset_pri(pdev) && !pci_enable_pri(pdev, 32))
info->pri_enabled = 1;
#endif
- if (!pdev->untrusted && info->ats_supported &&
- pci_ats_page_aligned(pdev) &&
+ if (info->ats_supported && pci_ats_page_aligned(pdev) &&
!pci_enable_ats(pdev, VTD_PAGE_SHIFT)) {
info->ats_enabled = 1;
domain_update_iotlb(info->domain);
@@ -2611,10 +2610,8 @@ static struct dmar_domain *dmar_insert_one_dev_info(struct intel_iommu *iommu,
if (dev && dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(info->dev);
- if (!pdev->untrusted &&
- !pci_ats_disabled() &&
- ecap_dev_iotlb_support(iommu->ecap) &&
- pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_ATS) &&
+ if (ecap_dev_iotlb_support(iommu->ecap) &&
+ pci_ats_supported(pdev) &&
dmar_find_matched_atsr_unit(pdev))
info->ats_supported = 1;
--
2.26.2
_______________________________________________
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 v2 3/4] iommu/arm-smmu-v3: Use pci_ats_supported()
From: Jean-Philippe Brucker @ 2020-05-20 15:22 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, hch, alex.williamson,
robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200520152201.3309416-1-jean-philippe@linaro.org>
The new pci_ats_supported() function checks if a device supports ATS and
is allowed to use it.
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/iommu/arm-smmu-v3.c | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 82508730feb7..c5730557dbe3 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2652,26 +2652,20 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
}
}
-#ifdef CONFIG_PCI_ATS
static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
{
- struct pci_dev *pdev;
+ struct device *dev = master->dev;
struct arm_smmu_device *smmu = master->smmu;
- struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- if (!(smmu->features & ARM_SMMU_FEAT_ATS) || !dev_is_pci(master->dev) ||
- !(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
+ if (!(smmu->features & ARM_SMMU_FEAT_ATS))
return false;
- pdev = to_pci_dev(master->dev);
- return !pdev->untrusted && pdev->ats_cap;
-}
-#else
-static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
-{
- return false;
+ if (!(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS))
+ return false;
+
+ return dev_is_pci(dev) && pci_ats_supported(to_pci_dev(dev));
}
-#endif
static void arm_smmu_enable_ats(struct arm_smmu_master *master)
{
--
2.26.2
_______________________________________________
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 v2 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement
From: Jean-Philippe Brucker @ 2020-05-20 15:21 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, ashok.raj, will, hch, alex.williamson,
robin.murphy, dwmw2, baolu.lu
IOMMU drivers currently check themselves if a device is untrusted
(plugged into an external-facing port) before enabling ATS. Move the
check to drivers/pci. The only functional change should be to the AMD
IOMMU driver. With this change all IOMMU drivers block 'Translated' PCIe
transactions and Translation Requests from untrusted devices.
Since v1 [1] I added tags, addressed comments on patches 1 and 3, and
fixed a regression in patch 3.
[1] https://lore.kernel.org/linux-iommu/20200515104359.1178606-1-jean-philippe@linaro.org/
Jean-Philippe Brucker (4):
PCI/ATS: Only enable ATS for trusted devices
iommu/amd: Use pci_ats_supported()
iommu/arm-smmu-v3: Use pci_ats_supported()
iommu/vt-d: Use pci_ats_supported()
include/linux/pci-ats.h | 3 +++
drivers/iommu/amd_iommu.c | 12 ++++--------
drivers/iommu/arm-smmu-v3.c | 20 +++++++-------------
drivers/iommu/intel-iommu.c | 9 +++------
drivers/pci/ats.c | 18 +++++++++++++++++-
5 files changed, 34 insertions(+), 28 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/4] PCI/ATS: Only enable ATS for trusted devices
From: Jean-Philippe Brucker @ 2020-05-20 15:22 UTC (permalink / raw)
To: linux-pci, linux-arm-kernel, iommu, joro, bhelgaas
Cc: Jean-Philippe Brucker, Joerg Roedel, ashok.raj, will, hch,
alex.williamson, robin.murphy, dwmw2, baolu.lu
In-Reply-To: <20200520152201.3309416-1-jean-philippe@linaro.org>
Add pci_ats_supported(), which checks whether a device has an ATS
capability, and whether it is trusted. A device is untrusted if it is
plugged into an external-facing port such as Thunderbolt and could be
spoofing an existing device to exploit weaknesses in the IOMMU
configuration. PCIe ATS is one such weaknesses since it allows
endpoints to cache IOMMU translations and emit transactions with
'Translated' Address Type (10b) that partially bypass the IOMMU
translation.
The SMMUv3 and VT-d IOMMU drivers already disallow ATS and transactions
with 'Translated' Address Type for untrusted devices. Add the check to
pci_enable_ats() to let other drivers (AMD IOMMU for now) benefit from
it.
By checking ats_cap, the pci_ats_supported() helper also returns whether
ATS was globally disabled with pci=noats, and could later include more
things, for example whether the whole PCIe hierarchy down to the
endpoint supports ATS.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
include/linux/pci-ats.h | 3 +++
drivers/pci/ats.c | 18 +++++++++++++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index d08f0869f121..f75c307f346d 100644
--- a/include/linux/pci-ats.h
+++ b/include/linux/pci-ats.h
@@ -6,11 +6,14 @@
#ifdef CONFIG_PCI_ATS
/* Address Translation Service */
+bool pci_ats_supported(struct pci_dev *dev);
int pci_enable_ats(struct pci_dev *dev, int ps);
void pci_disable_ats(struct pci_dev *dev);
int pci_ats_queue_depth(struct pci_dev *dev);
int pci_ats_page_aligned(struct pci_dev *dev);
#else /* CONFIG_PCI_ATS */
+static inline bool pci_ats_supported(struct pci_dev *d)
+{ return false; }
static inline int pci_enable_ats(struct pci_dev *d, int ps)
{ return -ENODEV; }
static inline void pci_disable_ats(struct pci_dev *d) { }
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 390e92f2d8d1..b761c1f72f67 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -30,6 +30,22 @@ void pci_ats_init(struct pci_dev *dev)
dev->ats_cap = pos;
}
+/**
+ * pci_ats_supported - check if the device can use ATS
+ * @dev: the PCI device
+ *
+ * Returns true if the device supports ATS and is allowed to use it, false
+ * otherwise.
+ */
+bool pci_ats_supported(struct pci_dev *dev)
+{
+ if (!dev->ats_cap)
+ return false;
+
+ return (dev->untrusted == 0);
+}
+EXPORT_SYMBOL_GPL(pci_ats_supported);
+
/**
* pci_enable_ats - enable the ATS capability
* @dev: the PCI device
@@ -42,7 +58,7 @@ int pci_enable_ats(struct pci_dev *dev, int ps)
u16 ctrl;
struct pci_dev *pdev;
- if (!dev->ats_cap)
+ if (!pci_ats_supported(dev))
return -EINVAL;
if (WARN_ON(dev->ats_enabled))
--
2.26.2
_______________________________________________
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 V1 RESEND 1/3] perf/imx_ddr: Add system PMU identifier for userspace
From: Rob Herring @ 2020-05-20 15:23 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, devicetree, John Garry, Joakim Zhang,
linux-kernel@vger.kernel.org, NXP Linux Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200520073304.GA23534@willie-the-truck>
On Wed, May 20, 2020 at 1:33 AM Will Deacon <will@kernel.org> wrote:
>
> On Tue, May 19, 2020 at 12:51:25PM -0600, Rob Herring wrote:
> > On Tue, May 12, 2020 at 03:31:13PM +0800, Joakim Zhang wrote:
> > > +static ssize_t ddr_perf_identifier_show(struct device *dev,
> > > + struct device_attribute *attr,
> > > + char *page)
> > > +{
> > > + struct ddr_pmu *pmu = dev_get_drvdata(dev);
> > > +
> > > + return sprintf(page, "%s\n", pmu->devtype_data->identifier);
> >
> > Why do we need yet another way to identify the SoC from userspace?
>
> I also really dislike this. What's the preferred way to identify the SoC
> from userspace?
/proc/cpuinfo? ;)
For an non-firmware specific case, I'd say soc_device should be. I'd
guess ACPI systems don't use it and for them it's dmidecode typically.
The other problem I have with soc_device is it is optional.
> It's needed so that the perf userspace tool can describe
> perf events that are supported for the PMU, as this isn't probe-able
> directly from the hardware. We have the same issue with the SMMUv3 PMCG [1],
> and so we need to solve the problem for both DT and ACPI.
>
> Will
>
> [1] https://lore.kernel.org/r/1587120634-19666-1-git-send-email-john.garry@huawei.com
At a minimum, it seems like 'identifier' should be moved into the perf
core if that's an attr we want to keep.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] ARM: pxa: remove Compulab pxa2xx boards
From: Arnd Bergmann @ 2020-05-20 15:21 UTC (permalink / raw)
To: Robert Jarzmik
Cc: Boris Brezillon, linux-mtd, Mike Rapoport, Linux ARM,
Miquel Raynal
In-Reply-To: <20200520102125.8934-1-robert.jarzmik@free.fr>
On Wed, May 20, 2020 at 12:21 PM Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>
> As these boards have no more users nor testers, and patching them has
> become a burden, be that because of the PCI part or the MTD NAND
> support, let's remove them.
>
> The cm-x300 will for now remain and represent Compulab boards at its
> best in the PXA department.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Should we take the series through the soc tree? If so, please
send them to soc@kernel.org if there are no objections;
or along with other patches you might have in the pull requests.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/5] mainline Protonic boards
From: Oleksij Rempel @ 2020-05-20 15:19 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Sascha Hauer, Shawn Guo
Cc: devicetree, linux-kernel, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200520092937.15797-1-o.rempel@pengutronix.de>
[-- Attachment #1.1: Type: text/plain, Size: 2638 bytes --]
Please ignore this version, i used wrong commit hash to format-patch.
On Wed, May 20, 2020 at 11:29:32AM +0200, Oleksij Rempel wrote:
> changes v7:
> - VT7: reorder node alphabetically
> - VT7: rename "reg_12v_bl: regulator-bl-12v" to "reg_bl_12v0: regulator-bl-12v0"
> - VT7: remove panel and TS nodes. This drivers are currently not
> mainline.
> - prti6q.dtsi: move reg_1v8 to prti6q.dts
> - prti6q.dtsi: remove pinctrl from the can1 node. It is done on almost
> every board file.
>
> changes v6:
> - move fsl.yaml changes to separate patch
> - remove partitions, they are provided by the bootloader
> - update flash compatible
> - rename can3 to can
> - fix fsl,mode
> - fix interrupt in the wlan node on PRTI6Q
>
> changes v5:
> - PRTI6Q: remove status from the pwm-backlight node
> - drop the vendor-prefixes patch, it is already taken by Rob
> - add Reviewed-by: Rob Herring <robh@kernel.org>
>
> changes v4:
> - VT7: fix typo
>
> changes v3:
> - move compatible to the start of node
> - move status to the end
> - use generic names in compatible
> - refactor dts/dtsi
> - use alphabet order for pinctrl and phandels
> - remove unused or currently not supported nodes
>
> changes v2:
> - squash PRTI6Q patches
>
> Oleksij Rempel (5):
> ARM: dts: add Protonic PRTI6Q board
> ARM: dts: add Protonic WD2 board
> ARM: dts: add Protonic VT7 board
> ARM: dts: add Protonic RVT board
> dt-bindings: arm: fsl: add different Protonic boards
>
> .../devicetree/bindings/arm/fsl.yaml | 4 +
> arch/arm/boot/dts/Makefile | 4 +
> arch/arm/boot/dts/imx6dl-prtrvt.dts | 182 ++++++
> arch/arm/boot/dts/imx6dl-prtvt7.dts | 472 ++++++++++++++++
> arch/arm/boot/dts/imx6q-prti6q.dts | 529 ++++++++++++++++++
> arch/arm/boot/dts/imx6q-prtwd2.dts | 188 +++++++
> arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 174 ++++++
> 7 files changed, 1553 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-prtrvt.dts
> create mode 100644 arch/arm/boot/dts/imx6dl-prtvt7.dts
> create mode 100644 arch/arm/boot/dts/imx6q-prti6q.dts
> create mode 100644 arch/arm/boot/dts/imx6q-prtwd2.dts
> create mode 100644 arch/arm/boot/dts/imx6qdl-prti6q.dtsi
>
> --
> 2.26.2
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2
From: Jordan Crouse @ 2020-05-20 15:13 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-msm, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Rob Clark, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200520125700.GD25815@willie-the-truck>
On Wed, May 20, 2020 at 01:57:01PM +0100, Will Deacon wrote:
> On Mon, May 18, 2020 at 08:50:27AM -0700, Rob Clark wrote:
> > On Mon, May 18, 2020 at 8:18 AM Will Deacon <will@kernel.org> wrote:
> > > On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> > > > We do in fact need live domain switching, that is really the whole
> > > > point. The GPU CP (command processor/parser) is directly updating
> > > > TTBR0 and triggering TLB flush, asynchronously from the CPU.
> > > >
> > > > And I think the answer about ASID is easy (on current hw).. it must be zero[*].
> > >
> > > Using ASID zero is really bad, because it means that you will end up sharing
> > > TLB entries with whichever device is using context bank 0.
> > >
> > > Is the SMMU only used by the GPU in your SoC?
> > >
> >
> > yes, the snapdragon SoCs have two SMMU instances, one used by the GPU,
> > where ASID0/cb0 is the gpu itself, and another cb is the GMU
> > (basically power control for the gpu), and the second SMMU is
> > everything else.
>
> Right, in which case I'm starting to think that we should treat this GPU
> SMMU instance specially. Give it its own compatible string (looks like you
> need this for HUPCFG anyway) and hook in via arm_smmu_impl_init(). You can
> then set IO_PGTABLE_QUIRK_ARM_TTBR1 when talking to the io-pgtable code
> without having to add a domain attribute.
If we did this via a special GPU SMMU instance then we could also create and
register a dummy TTBR0 instance along with the TTBR1 instance and then we
wouldn't need to worry about the aux domains at all.
> With that. you'll need to find a way to allow the GPU driver to call into
> your own hooks for getting at the TTBR0 tables -- given that you're
> programming these in the hardware, I don't think it makes sense to expose
> that in the IOMMU API, since most devices won't be able to do anything with
> that data. Perhaps you could install a couple of function pointers
> (subdomain_alloc/subdomain_free) in the GPU device when you see it appear
> from the SMMU driver? Alternatively, you could make an io_pgtable_cfg
> available so that the GPU driver can interface with io-pgtable directly.
I don't want to speak for Rob but I think that this is the same direction we've
landed on. If we use the implementation specific code to initialize the base
pagetables then the GPU driver can use io-pgtable directly. We can easily
construct an io_pgtable_cfg. This feature will only be available for opt-in
GPU targets that will have a known configuration.
The only gotcha is TLB maintenance but Rob and I have ideas about coordinating
with the GPU hardware (which has to do a TLBIALL during a switch anyway) and we
can always use the iommu_tlb_flush_all() hammer from software if we really need
it. It might take a bit of thought, but it is doable.
> Yes, it's ugly, but I don't think it's worth trying to abstract this.
I'm not sure how ugly it is. I've always operated under the assumption that the
GPU SMMU was special (though it had generic registers) just because of where it
was and how it it was used. In the long run baking in a implementation specific
solution would probably be preferable to lots of domain attributes and aux
domains that would never be used except by us.
> Thoughts? It's taken me a long time to figure out what's going on here,
> so sorry if it feels like I'm leading you round the houses.
I'll hack on this and try to get something in place. It might be dumber on the
GPU side than we would like but it would at least spur some more conversation.
Jordan
> Will
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox