* [PATCH v4 5/5] arm64: atomics: remove atomic_ll_sc compilation unit
From: Andrew Murray @ 2019-08-28 17:50 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Peter Zijlstra, Ard.Biesheuvel
Cc: Mark Rutland, Boqun Feng, linux-arm-kernel
In-Reply-To: <20190828175009.15457-1-andrew.murray@arm.com>
We no longer fall back to out-of-line atomics on systems with
CONFIG_ARM64_LSE_ATOMICS where ARM64_HAS_LSE_ATOMICS is not set. Let's
remove the now unused compilation unit which provided these symbols.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
---
arch/arm64/lib/Makefile | 19 -------------------
arch/arm64/lib/atomic_ll_sc.c | 3 ---
2 files changed, 22 deletions(-)
delete mode 100644 arch/arm64/lib/atomic_ll_sc.c
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 33c2a4abda04..f10809ef1690 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -11,25 +11,6 @@ CFLAGS_REMOVE_xor-neon.o += -mgeneral-regs-only
CFLAGS_xor-neon.o += -ffreestanding
endif
-# Tell the compiler to treat all general purpose registers (with the
-# exception of the IP registers, which are already handled by the caller
-# in case of a PLT) as callee-saved, which allows for efficient runtime
-# patching of the bl instruction in the caller with an atomic instruction
-# when supported by the CPU. Result and argument registers are handled
-# correctly, based on the function prototype.
-lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
-CFLAGS_atomic_ll_sc.o := -ffixed-x1 -ffixed-x2 \
- -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6 \
- -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9 \
- -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12 \
- -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15 \
- -fcall-saved-x18 -fomit-frame-pointer
-CFLAGS_REMOVE_atomic_ll_sc.o := $(CC_FLAGS_FTRACE)
-GCOV_PROFILE_atomic_ll_sc.o := n
-KASAN_SANITIZE_atomic_ll_sc.o := n
-KCOV_INSTRUMENT_atomic_ll_sc.o := n
-UBSAN_SANITIZE_atomic_ll_sc.o := n
-
lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o
obj-$(CONFIG_CRC32) += crc32.o
diff --git a/arch/arm64/lib/atomic_ll_sc.c b/arch/arm64/lib/atomic_ll_sc.c
deleted file mode 100644
index b0c538b0da28..000000000000
--- a/arch/arm64/lib/atomic_ll_sc.c
+++ /dev/null
@@ -1,3 +0,0 @@
-#include <asm/atomic.h>
-#define __ARM64_IN_ATOMIC_IMPL
-#include <asm/atomic_ll_sc.h>
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 0/3] arm64: meson-sm1: add support for the SM1 based VIM3L
From: Kevin Hilman @ 2019-08-28 17:55 UTC (permalink / raw)
To: Neil Armstrong
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190828141816.16328-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This patchset adds support for the Amlogic SM1 based Khadas VIM3L variant.
>
> The S903D3 package variant of SM1 is pin-to-pin compatible with the
> S922X and A311d, so only internal DT changes are needed :
> - DVFS support is different
> - Audio support not yet available for SM1
>
> This patchset moved all the non-g12b nodes to meson-khadas-vim3.dtsi
> and add the sm1 specific nodes into meson-sm1-khadas-vim3l.dts.
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Basic boot test + suspend/resume test OK on my vim3L (thanks to Khadas
for the board!)
> Display has a color conversion bug on SM1 by using a more recent vendor
> bootloader on the SM1 based VIM3, this is out of scope of this patchset
> and will be fixed in the drm/meson driver.
>
> Dependencies:
> - patch 1,2: None
> - patch 3: Depends on the "arm64: meson-sm1: add support for DVFS" patchset at [1]
I tested in my integ branch where this series is applied, but I'm not
seeing any OPPs created (/sys/devices/system/cpu/cpufreq/)
Kevin
_______________________________________________
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: xen: mm: use __GPF_DMA32 for arm64
From: Stefano Stabellini @ 2019-08-28 18:09 UTC (permalink / raw)
To: Peng Fan
Cc: sstabellini@kernel.org, linux@armlinux.org.uk,
linux-kernel@vger.kernel.org, dl-linux-imx, van.freenix@gmail.com,
xen-devel@lists.xenproject.org, Robin Murphy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR04MB4481386D2C54AEA6987E1B1588A30@AM0PR04MB4481.eurprd04.prod.outlook.com>
On Wed, 28 Aug 2019, Peng Fan wrote:
> Hi Robin,
>
> > Subject: Re: [PATCH] arm: xen: mm: use __GPF_DMA32 for arm64
> >
> > On 09/07/2019 09:22, Peng Fan wrote:
> > > arm64 shares some code under arch/arm/xen, including mm.c.
> > > However ZONE_DMA is removed by commit
> > > ad67f5a6545("arm64: replace ZONE_DMA with ZONE_DMA32").
> > > So to ARM64, need use __GFP_DMA32.
Hi Peng,
Sorry for being so late in replying, this email got lost in the noise.
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > arch/arm/xen/mm.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index
> > > e1d44b903dfc..a95e76d18bf9 100644
> > > --- a/arch/arm/xen/mm.c
> > > +++ b/arch/arm/xen/mm.c
> > > @@ -27,7 +27,7 @@ unsigned long xen_get_swiotlb_free_pages(unsigned
> > > int order)
> > >
> > > for_each_memblock(memory, reg) {
> > > if (reg->base < (phys_addr_t)0xffffffff) {
> > > - flags |= __GFP_DMA;
> > > + flags |= __GFP_DMA | __GFP_DMA32;
> >
> > Given the definition of GFP_ZONE_BAD, I'm not sure this combination of flags
> > is strictly valid, but rather is implicitly reliant on only one of those zones ever
> > actually existing. As such, it seems liable to blow up if the plans to add
> > ZONE_DMA to arm64[1] go ahead.
>
> How about this, or do you have any suggestions?
> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
> index d33b77e9add3..f61c29a4430f 100644
> --- a/arch/arm/xen/mm.c
> +++ b/arch/arm/xen/mm.c
> @@ -28,7 +28,11 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
>
> for_each_memblock(memory, reg) {
> if (reg->base < (phys_addr_t)0xffffffff) {
> +#ifdef CONFIG_ARM64
> + flags |= __GFP_DMA32;
> +#else
> flags |= __GFP_DMA;
> +#endif
> break;
> }
> }
Yes I think this is the way to go, but we are trying not to add any
#ifdef CONFIG_ARM64 under arch/arm. Maybe you could introduce a static
inline function to set GFP_DMA:
static inline void xen_set_gfp_dma(gfp_t *flags)
it could be implemented under arch/arm/include/asm/xen/page.h for arm
and under arch/arm64/include/asm/xen/page.h for arm64 using __GFP_DMA
for the former and __GFP_DMA32 for the latter.
_______________________________________________
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] PCI: rockchip: Properly handle optional regulators
From: Heiko Stuebner @ 2019-08-28 18:15 UTC (permalink / raw)
To: Thierry Reding
Cc: Lorenzo Pieralisi, linux-pci, Shawn Lin, Vidya Sagar,
linux-rockchip, Bjorn Helgaas, Andrew Murray, linux-arm-kernel
In-Reply-To: <20190828150737.30285-1-thierry.reding@gmail.com>
Am Mittwoch, 28. August 2019, 17:07:37 CEST schrieb Thierry Reding:
> From: Thierry Reding <treding@nvidia.com>
>
> regulator_get_optional() can fail for a number of reasons besides probe
> deferral. It can for example return -ENOMEM if it runs out of memory as
> it tries to allocate data structures. Propagating only -EPROBE_DEFER is
> problematic because it results in these legitimately fatal errors being
> treated as "regulator not specified in DT".
>
> What we really want is to ignore the optional regulators only if they
> have not been specified in DT. regulator_get_optional() returns -ENODEV
> in this case, so that's the special case that we need to handle. So we
> propagate all errors, except -ENODEV, so that real failures will still
> cause the driver to fail probe.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
on a rk3399-gru-scarlet with no 12v regulator defined and pcie-wifi
keeping on working with this patch:
Tested-by: Heiko Stuebner <heiko@sntech.de>
Change itself also looks correct,
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Thanks for doing that cleanup
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Aaro Koskinen @ 2019-08-28 18:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz, Tony Lindgren, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <CAK8P3a1PeBMRuweAmzrTQC85CmwdZPirG3HPg9aJ99p2U7zknQ@mail.gmail.com>
Hi,
On Wed, Aug 28, 2019 at 03:02:36PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 27, 2019 at 9:05 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > On Tue, Aug 27, 2019 at 06:33:01PM +0200, Arnd Bergmann wrote:
> > > On Fri, Aug 16, 2019 at 10:34 AM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> > > > However with earlyprintk it seems to hang as soon as kernel tries to print
> > > > something. So something goes wrong with early DEBUG_LL mapping code when
> > > > CONFIG_DEBUG_UART_VIRT=0xff000000 is used?
> > >
> > > I just redid the calculation and came out with the same address, so I
> > > don't think I put the wrong one there. The address also does not
> > > conflict with the PCI mapping, and the address is the same one that
> > > is installed later, so that should also be fine.
> > >
> > > Are you sure you used the correct address in the .config file? If you
> > > ran 'make oldconfig', the virtual address would not be changed here
> > > as I just modify the default for a fresh 'make omap1_defconfig'
> > > run or similar.
> >
> > Yes... You should be able to try this out also in QEMU to see the hang:
>
> Haven't tried yet, but I took a look at the dump:
>
> > $ qemu-system-arm -M sx1 -kernel sx1-zImage -nographic
> >
> > [ Hangs silently, press Ctrl-a c to enter monitor. ]
> >
> > QEMU 4.1.0 monitor - type 'help' for more information
> > (qemu) info registers
> > R00=c0379de1 R01=0000005b R02=00000000 R03=ff000000
> > R04=00000000 R05=00000031 R06=c038f119 R07=00000000
> > R08=00000000 R09=c038f50e R10=600001d3 R11=00000001
> > R12=00000010 R13=c0379de0 R14=c000e07c R15=c000dfcc
> > PSR=000001d3 ---- A svc32
> > FPSCR: 00000000
> >
> > from System.map:
> > c000df7c T printascii
> > c000dfe0 T printch
>
> Ok, that is clearly the "busyloop" macro in
> arch/arm/include/debug/8250.S, checking if the data got sent.
>
> The 'r2' register contains zero, so UART_LSR_TEMT and
> UART_LSR_THRE are not set, but presumably the mapping
> was installed right since you did not get a page fault.
>
> I assume you checked that the uart output wasn't already broken
> by one of the earlier patches, right?
Correct, it's only with the mapping change patch it hangs.
> Also, looking at arch/arm/mach-omap1/include/mach/uncompress.h
> it seems that SX1 normally uses UART3, not UART1.
> Is that different in qemu?
In QEMU all uarts can be used, trying with UART3 as early console
hangs as well. (It prints Uncompressing... done. but I guess that's
done with the physical address.)
A.
_______________________________________________
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: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
From: Tony Lindgren @ 2019-08-28 18:30 UTC (permalink / raw)
To: Ladislav Michl
Cc: Paul Walmsley, Balaji T K, kernel-janitors, Kishore Kadiyala,
Russell King, LKML, Markus Elfring, Nikolaus Schaller, linux-omap,
linux-arm-kernel, Benoit Cousson
In-Reply-To: <20190827181457.GA16333@lenoch>
* Ladislav Michl <ladis@linux-mips.org> [190827 18:15]:
> On Mon, Aug 26, 2019 at 09:20:50AM -0700, Tony Lindgren wrote:
> > * Markus Elfring <Markus.Elfring@web.de> [190826 06:31]:
> > > From: Markus Elfring <elfring@users.sourceforge.net>
> > > Date: Mon, 26 Aug 2019 15:05:31 +0200
> > >
> > > A null pointer would be passed to a call of the function "kfree" directly
> > > after a call of the function "kzalloc" failed at one place.
> > > Remove this superfluous function call.
> > >
> > > This issue was detected by using the Coccinelle software.
> >
> > Applying into omap-for-v5.4/soc thanks.
>
> Is it really wise touching almost dead code? Last user is pandora board, so
> +Cc: Nikolaus Schaller <hns@goldelico.com>
Yeah would be good to finally get rid of that old code.
Anyways, I'll keep the $subject patch to cut down on
coccinelle produced issue.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/3] ARM: omap2plus_defconfig: Fix missing video
From: Adam Ford @ 2019-08-28 18:33 UTC (permalink / raw)
To: linux-omap
Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
linux-kernel, Rob Herring, Benoît Cousson, Adam Ford,
linux-arm-kernel
When the panel-dpi driver was removed, the simple-panels driver
was never enabled, so anyone who used the panel-dpi driver lost
video, and those who used it inconjunction with simple-panels
would have to manually enable CONFIG_DRM_PANEL_SIMPLE.
This patch makes CONFIG_DRM_PANEL_SIMPLE a module in the same
way the deprecated panel-dpi was.
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index c7bf9c493646..64eb896907bf 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -363,6 +363,7 @@ CONFIG_DRM_OMAP_PANEL_TPO_TD028TTEC1=m
CONFIG_DRM_OMAP_PANEL_TPO_TD043MTEA1=m
CONFIG_DRM_OMAP_PANEL_NEC_NL8048HL11=m
CONFIG_DRM_TILCDC=m
+CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: logicpd-torpedo-baseboard: Fix missing video
From: Adam Ford @ 2019-08-28 18:33 UTC (permalink / raw)
To: linux-omap
Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
linux-kernel, Rob Herring, Benoît Cousson, Adam Ford,
linux-arm-kernel
In-Reply-To: <20190828183351.822-1-aford173@gmail.com>
A previous commit removed the panel-dpi driver, which made the
Torpedo video stop working because it relied on the dpi driver
for setting video timings. Now that the simple-panel driver is
available in omap2plus, this patch migrates the Torpedo dev kits
to use a similar panel and remove the manual timing requirements.
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi b/arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
index 642e809e757a..449cc7616da6 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
@@ -108,7 +108,6 @@
&dss {
status = "ok";
vdds_dsi-supply = <&vpll2>;
- vdda_video-supply = <&video_reg>;
pinctrl-names = "default";
pinctrl-0 = <&dss_dpi_pins1>;
port {
@@ -124,44 +123,20 @@
display0 = &lcd0;
};
- video_reg: video_reg {
- pinctrl-names = "default";
- pinctrl-0 = <&panel_pwr_pins>;
- compatible = "regulator-fixed";
- regulator-name = "fixed-supply";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- gpio = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd INI */
- };
-
lcd0: display {
- compatible = "panel-dpi";
+ /* This isn't the exact LCD, but the timings meet spec */
+ /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
+ compatible = "newhaven,nhd-4.3-480272ef-atxl";
label = "15";
- status = "okay";
- /* default-on; */
pinctrl-names = "default";
-
+ pinctrl-0 = <&panel_pwr_pins>;
+ backlight = <&bl>;
+ enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
-
- panel-timing {
- clock-frequency = <9000000>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <3>;
- hback-porch = <2>;
- hsync-len = <42>;
- vback-porch = <3>;
- vfront-porch = <4>;
- vsync-len = <11>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
};
bl: backlight {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: am3517-evm: Fix missing video
From: Adam Ford @ 2019-08-28 18:33 UTC (permalink / raw)
To: linux-omap
Cc: Mark Rutland, devicetree, Tony Lindgren, Russell King,
linux-kernel, Rob Herring, Benoît Cousson, Adam Ford,
linux-arm-kernel
In-Reply-To: <20190828183351.822-1-aford173@gmail.com>
A previous commit removed the panel-dpi driver, which made the
video on the AM3517-evm stop working because it relied on the dpi
driver for setting video timings. Now that the simple-panel driver
is available in omap2plus, this patch migrates the am3517-evm
to use a similar panel and remove the manual timing requirements.
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/boot/dts/am3517-evm.dts b/arch/arm/boot/dts/am3517-evm.dts
index ebfe28c2f544..a1fd3e63e86e 100644
--- a/arch/arm/boot/dts/am3517-evm.dts
+++ b/arch/arm/boot/dts/am3517-evm.dts
@@ -124,10 +124,11 @@
};
lcd0: display@0 {
- compatible = "panel-dpi";
+ /* This isn't the exact LCD, but the timings meet spec */
+ /* To make it work, set CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=4 */
+ compatible = "newhaven,nhd-4.3-480272ef-atxl";
label = "15";
- status = "okay";
- pinctrl-names = "default";
+ backlight = <&bl>;
enable-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>; /* gpio176, lcd INI */
vcc-supply = <&vdd_io_reg>;
@@ -136,22 +137,6 @@
remote-endpoint = <&dpi_out>;
};
};
-
- panel-timing {
- clock-frequency = <9000000>;
- hactive = <480>;
- vactive = <272>;
- hfront-porch = <3>;
- hback-porch = <2>;
- hsync-len = <42>;
- vback-porch = <3>;
- vfront-porch = <4>;
- vsync-len = <11>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
};
bl: backlight {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [GIT PULL 1/4] soc changes for omap variants for v5.4
From: Tony Lindgren @ 2019-08-28 18:34 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/soc-signed
for you to fetch changes up to 50f57ef83d836d727902a6a7e70cca61b0d02655:
ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init() (2019-08-26 08:59:48 -0700)
----------------------------------------------------------------
SoC changes for omap variants for v5.4
The first change moves platform-specific asm-offsets.h to arch/arm/mach-omap2
to fix iessu with parallel build with CONFIG_IKHEADERS, and the second change
removes a useless kfree.
Note that the first change causes a trivial merge conflict with the iommu
changes for arch/arm/mach-omap2/Makefile.
----------------------------------------------------------------
Markus Elfring (1):
ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
Masahiro Yamada (1):
ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2
arch/arm/mach-omap2/.gitignore | 1 +
arch/arm/mach-omap2/Makefile | 5 +++--
arch/arm/mach-omap2/hsmmc.c | 4 +---
arch/arm/mach-omap2/sleep33xx.S | 2 +-
arch/arm/mach-omap2/sleep43xx.S | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/mach-omap2/.gitignore
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 2/4] more ti-sysc driver changes for v5.4
From: Tony Lindgren @ 2019-08-28 18:34 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
In-Reply-To: <pull-1567016893-318461@atomide.com>
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit c8a738f4cfaeccce40b171aca6da5fc45433ce60:
bus: ti-sysc: remove set but not used variable 'quirks' (2019-08-13 04:40:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/ti-sysc-part2-signed
for you to fetch changes up to 7edd00f71f4b91ca31dbfa08926495fe5e77aab4:
bus: ti-sysc: Detect d2d when debug is enabled (2019-08-26 08:33:25 -0700)
----------------------------------------------------------------
more ti-sysc driver changes for omap variants for v5.4
Few changes mostly to deal with sgx SoC glue quirk for omap36xx that
is needed for the related sgx SoC glue dts branch. The other changes
are to simplify sysc_check_one_child() sysc_check_children() to be void
functions, and detect d2d module when debugging is enabled.
----------------------------------------------------------------
Nishka Dasgupta (1):
bus: ti-sysc: Change return types of functions
Tony Lindgren (2):
bus: ti-sysc: Add module enable quirk for SGX on omap36xx
bus: ti-sysc: Detect d2d when debug is enabled
drivers/bus/ti-sysc.c | 45 ++++++++++++++++++++++-------------
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 30 insertions(+), 16 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 3/4] drop more legacy pdata for omaps for v5.4
From: Tony Lindgren @ 2019-08-28 18:34 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
In-Reply-To: <pull-1567016893-318461@atomide.com>
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 5b63fb90adb95a178ad403e1703f59bf1ff2c16b:
ARM: dts: Fix incomplete dts data for am3 and am4 mmc (2019-08-13 04:03:30 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/ti-sysc-drop-pdata-take2-signed
for you to fetch changes up to 1170f235834bfb858f691670b127f8673af5923b:
ARM: dts: Drop legacy custom hwmods property for dra7 gpio (2019-08-26 10:59:25 -0700)
----------------------------------------------------------------
Drop legacy platform data omap variants for v5.4
We can now drop more platform data in favor of dts data for most
devices like cpsw, gpio, i2c, mmc, uart and watchdog.
In general we can do this by dropping legacy "ti,hwmods" custom dts
property, and the platform data assuming the related dts data is correct.
This is best done as single patch as otherwise we'd have to revert two
patches in case of any unexpected issues, and we're just removing data.
Fro cpsw, before we can do this, we need to configure the cpsw mdio clocks
properly in dts though in the first patch. For omap4 i2c, we've already
dropped the platform data earlier, but have been still allocting it
dynamically based on the dts data based on the "ti,hwmods" property, but
that is no longer needed. For d2d, we are missing the dts data, so we
first add it and then drop the platform data.
For dra7, we drop platform data and "ti,hwmods" for mcasp and mcspi.
We've already dropped platform data earlier for gpio, i2c, mmc, and
uart so we just need to drop "ti,hwmods" property for those.
Note that this branch is based on earlier ti-sysc-fixes branch.
----------------------------------------------------------------
Tony Lindgren (13):
ARM: dts: Add fck for cpsw mdio for omap variants
ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4
ARM: OMAP2+: Drop legacy platform data for cpsw on dra7
ARM: dts: Drop custom hwmod property for omap4 i2c
ARM: OMAP2+: Drop legacy watchdog platform data for omap4
ARM: dts: Configure d2d dts data for omap4
ARM: OMAP2+: Drop legacy platform data for omap4 d2d
ARM: OMAP2+: Drop legacy platform data for dra7 mcspi
ARM: OMAP2+: Drop legacy platform data for dra7 mcasp
ARM: dts: Drop legacy custom hwmods property for dra7 uart
ARM: dts: Drop legacy custom hwmods property for dra7 i2c
ARM: dts: Drop legacy custom hwmods property for dra7 mmc
ARM: dts: Drop legacy custom hwmods property for dra7 gpio
arch/arm/boot/dts/am33xx-l4.dtsi | 4 +-
arch/arm/boot/dts/am437x-l4.dtsi | 6 +-
arch/arm/boot/dts/dra7-l4.dtsi | 43 +-
arch/arm/boot/dts/omap4-l4-abe.dtsi | 1 -
arch/arm/boot/dts/omap4-l4.dtsi | 39 +-
.../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 3 -
.../omap_hwmod_33xx_43xx_interconnect_data.c | 6 -
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 50 ---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 9 -
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 9 -
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 115 -----
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 475 ---------------------
12 files changed, 36 insertions(+), 724 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 4/4] sgx soc glue changes for omaps for v5.4
From: Tony Lindgren @ 2019-08-28 18:34 UTC (permalink / raw)
To: soc; +Cc: Tony Lindgren, linux-omap, arm, linux-arm-kernel
In-Reply-To: <pull-1567016893-318461@atomide.com>
From: "Tony Lindgren" <tony@atomide.com>
The following changes since commit 7edd00f71f4b91ca31dbfa08926495fe5e77aab4:
bus: ti-sysc: Detect d2d when debug is enabled (2019-08-26 08:33:25 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v5.4/ti-sysc-sgx-signed
for you to fetch changes up to 6cb0ac0fb9786d01f140dcfcd3d09ce850dd0a64:
ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx (2019-08-26 08:47:09 -0700)
----------------------------------------------------------------
SoC glue layer changes for SGX on omap variants for v5.4
For a while we've had omap4 sgx glue layer defined in dts and probed
with ti-sysc driver. This allows idling the sgx module for PM, and
removes the need for custom platform glue layer code for any further
driver changes.
We first drop the unused legacy platform data for omap4 sgx. Then for
omap5, we need add the missing clkctrl clock data so we can configure
sgx. And we configure sgx for omap34xx, omap36xx and am3517.
For am335x, we still have a dependency for rstctrl reset driver changes,
so that will be added later on.
Note that this branch is based on earlier ti-sysc branch for omap36xx
glue layer quirk handling.
----------------------------------------------------------------
Adam Ford (1):
ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx
Tony Lindgren (4):
ARM: OMAP2+: Drop legacy platform data for omap4 gpu
clk: ti: add clkctrl data omap5 sgx
ARM: dts: Configure sgx for omap5
ARM: dts: Configure interconnect target module for omap3 sgx
arch/arm/boot/dts/am3517.dtsi | 24 ++++++++++++++
arch/arm/boot/dts/omap34xx.dtsi | 26 +++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 28 ++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 1 -
arch/arm/boot/dts/omap5.dtsi | 23 +++++++++++++
arch/arm/boot/dts/omap54xx-clocks.dtsi | 14 ++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 53 ------------------------------
drivers/clk/ti/clk-54xx.c | 34 +++++++++++++++++++
include/dt-bindings/clock/omap5.h | 3 ++
9 files changed, 152 insertions(+), 54 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/5] Serial: imx: various fixes
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <20190530152950.25377-1-sorganov@gmail.com>
The original problem that caused these changes was broken bytes being
sent/received at random on RTS/CTS handshake switch (i.e., on
setting/clearing termios CRTSCTS bit).
As it went, a few other problems were found and fixed, and then the
fix for original issue has been split into multiple patches that seem
to make sense by themselves. Thus, the "serial: imx: fix data breakage
on termios change", that finally fixes the issue, depends on 2
preceding patches.
The last patch in the series, "serial: imx: use Tx ready rather than
Tx empty irq" is independent of the rest and doesn't fix any serious
issue, but it should get rid of holes in continuous output,
specifically in PIO mode.
Changes in v2:
- Removed wrong [PATCH 1/8] serial: imx: fix DTR inversion
- Rebased on top of "tty-next"
Sergey Organov (5):
serial: imx: get rid of unbounded busy-waiting loop
serial: imx: do not stop Rx/Tx on termios change
serial: imx: do not disable individual irqs during termios change
serial: imx: fix data breakage on termios change
serial: imx: use Tx ready rather than Tx empty irq
drivers/tty/serial/imx.c | 56 ++++++++++++++++++++++--------------------------
1 file changed, 26 insertions(+), 30 deletions(-)
--
2.10.0.1.g57b01a3
_______________________________________________
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/5] serial: imx: get rid of unbounded busy-waiting loop
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): remove busy-waiting "drain Tx FIFO" loop. Worse
yet, it was potentially unbounded wait due to RTS/CTS (hardware)
handshake.
Let user space ensure draining is done before termios change, if
draining is needed in the first place.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index d9a73c7..47b6156 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1644,7 +1644,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
uart_update_timeout(port, termios->c_cflag, baud);
/*
- * disable interrupts and drain transmitter
+ * disable interrupts
*/
old_ucr1 = imx_uart_readl(sport, UCR1);
imx_uart_writel(sport,
@@ -1652,9 +1652,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
UCR1);
imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
- while (!(imx_uart_readl(sport, USR2) & USR2_TXDC))
- barrier();
-
/* then, disable everything */
imx_uart_writel(sport, old_ucr2 & ~(UCR2_TXEN | UCR2_RXEN | UCR2_ATEN), UCR2);
--
2.10.0.1.g57b01a3
_______________________________________________
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 2/5] serial: imx: do not stop Rx/Tx on termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): stopping receiver and transmitter does harm when
something that doesn't touch transmission format/rate changes, such as
RTS/CTS handshake.
OTOH, it does no good on baud rate or format change, as
synchronization on upper-level protocols is still required to do it
right.
Therefore, just stop doing it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 47b6156..fa723a9a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1652,9 +1652,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
UCR1);
imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
- /* then, disable everything */
- imx_uart_writel(sport, old_ucr2 & ~(UCR2_TXEN | UCR2_RXEN | UCR2_ATEN), UCR2);
-
/* custom-baudrate handling */
div = sport->port.uartclk / (baud * 16);
if (baud == 38400 && quot != div)
--
2.10.0.1.g57b01a3
_______________________________________________
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/5] serial: imx: do not disable individual irqs during termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): disabling individual interrupt requests in UART for
duration of the routine is pointless. Get rid of it.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index fa723a9a..cc3783c 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1541,7 +1541,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
{
struct imx_port *sport = (struct imx_port *)port;
unsigned long flags;
- u32 ucr2, old_ucr1, old_ucr2, ufcr;
+ u32 ucr2, old_ucr2, ufcr;
unsigned int baud, quot;
unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
unsigned long div;
@@ -1643,15 +1643,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
*/
uart_update_timeout(port, termios->c_cflag, baud);
- /*
- * disable interrupts
- */
- old_ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport,
- old_ucr1 & ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN),
- UCR1);
- imx_uart_writel(sport, old_ucr2 & ~UCR2_ATEN, UCR2);
-
/* custom-baudrate handling */
div = sport->port.uartclk / (baud * 16);
if (baud == 38400 && quot != div)
@@ -1686,8 +1677,6 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
imx_uart_writel(sport, sport->port.uartclk / div / 1000,
IMX21_ONEMS);
- imx_uart_writel(sport, old_ucr1, UCR1);
-
imx_uart_writel(sport, ucr2, UCR2);
if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
--
2.10.0.1.g57b01a3
_______________________________________________
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/5] serial: imx: fix data breakage on termios change
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
imx_set_termios(): avoid writing baud rate divider registers when the
values to be written are the same as current. Any writing seems to
restart transmission/receiving logic in the hardware, that leads to
data breakage even when rate doesn't in fact change. E.g., user
switches RTS/CTS handshake and suddenly gets broken bytes.
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index cc3783c..e89045a 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1545,7 +1545,7 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
unsigned int baud, quot;
unsigned int old_csize = old ? old->c_cflag & CSIZE : CS8;
unsigned long div;
- unsigned long num, denom;
+ unsigned long num, denom, old_ubir, old_ubmr;
uint64_t tdiv64;
/*
@@ -1670,8 +1670,21 @@ imx_uart_set_termios(struct uart_port *port, struct ktermios *termios,
ufcr = (ufcr & (~UFCR_RFDIV)) | UFCR_RFDIV_REG(div);
imx_uart_writel(sport, ufcr, UFCR);
- imx_uart_writel(sport, num, UBIR);
- imx_uart_writel(sport, denom, UBMR);
+ /*
+ * Two registers below should always be written both and in this
+ * particular order. One consequence is that we need to check if any of
+ * them changes and then update both. We do need the check for change
+ * as even writing the same values seem to "restart"
+ * transmission/receiving logic in the hardware, that leads to data
+ * breakage even when rate doesn't in fact change. E.g., user switches
+ * RTS/CTS handshake and suddenly gets broken bytes.
+ */
+ old_ubir = imx_uart_readl(sport, UBIR);
+ old_ubmr = imx_uart_readl(sport, UBMR);
+ if (old_ubir != num || old_ubmr != denom) {
+ imx_uart_writel(sport, num, UBIR);
+ imx_uart_writel(sport, denom, UBMR);
+ }
if (!imx_uart_is_imx1(sport))
imx_uart_writel(sport, sport->port.uartclk / div / 1000,
--
2.10.0.1.g57b01a3
_______________________________________________
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 5/5] serial: imx: use Tx ready rather than Tx empty irq
From: Sergey Organov @ 2019-08-28 18:37 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Sascha Hauer, Sergey Organov, NXP Linux Team,
Pengutronix Kernel Team, Uwe Kleine-König, linux-arm-kernel
In-Reply-To: <1567017475-11919-1-git-send-email-sorganov@gmail.com>
This should help to avoid unnecessary gaps in transmission while
adding little overhead due to low default Tx threshold level (2
bytes).
Signed-off-by: Sergey Organov <sorganov@gmail.com>
---
drivers/tty/serial/imx.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e89045a..87c58f9 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -439,7 +439,7 @@ static void imx_uart_stop_tx(struct uart_port *port)
return;
ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport, ucr1 & ~UCR1_TXMPTYEN, UCR1);
+ imx_uart_writel(sport, ucr1 & ~UCR1_TRDYEN, UCR1);
/* in rs485 mode disable transmitter if shifter is empty */
if (port->rs485.flags & SER_RS485_ENABLED &&
@@ -517,7 +517,7 @@ static inline void imx_uart_transmit_buffer(struct imx_port *sport)
* and the TX IRQ is disabled.
**/
ucr1 = imx_uart_readl(sport, UCR1);
- ucr1 &= ~UCR1_TXMPTYEN;
+ ucr1 &= ~UCR1_TRDYEN;
if (sport->dma_is_txing) {
ucr1 |= UCR1_TXDMAEN;
imx_uart_writel(sport, ucr1, UCR1);
@@ -679,7 +679,7 @@ static void imx_uart_start_tx(struct uart_port *port)
if (!sport->dma_is_enabled) {
ucr1 = imx_uart_readl(sport, UCR1);
- imx_uart_writel(sport, ucr1 | UCR1_TXMPTYEN, UCR1);
+ imx_uart_writel(sport, ucr1 | UCR1_TRDYEN, UCR1);
}
if (sport->dma_is_enabled) {
@@ -688,7 +688,7 @@ static void imx_uart_start_tx(struct uart_port *port)
* disable TX DMA to let TX interrupt to send X-char */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 &= ~UCR1_TXDMAEN;
- ucr1 |= UCR1_TXMPTYEN;
+ ucr1 |= UCR1_TRDYEN;
imx_uart_writel(sport, ucr1, UCR1);
return;
}
@@ -874,7 +874,7 @@ static irqreturn_t imx_uart_int(int irq, void *dev_id)
usr1 &= ~USR1_RRDY;
if ((ucr2 & UCR2_ATEN) == 0)
usr1 &= ~USR1_AGTIM;
- if ((ucr1 & UCR1_TXMPTYEN) == 0)
+ if ((ucr1 & UCR1_TRDYEN) == 0)
usr1 &= ~USR1_TRDY;
if ((ucr4 & UCR4_TCEN) == 0)
usr2 &= ~USR2_TXDC;
@@ -1474,7 +1474,7 @@ static void imx_uart_shutdown(struct uart_port *port)
spin_lock_irqsave(&sport->port.lock, flags);
ucr1 = imx_uart_readl(sport, UCR1);
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN | UCR1_RXDMAEN | UCR1_ATDMAEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN | UCR1_RXDMAEN | UCR1_ATDMAEN);
imx_uart_writel(sport, ucr1, UCR1);
spin_unlock_irqrestore(&sport->port.lock, flags);
@@ -1778,7 +1778,7 @@ static int imx_uart_poll_init(struct uart_port *port)
ucr1 |= IMX1_UCR1_UARTCLKEN;
ucr1 |= UCR1_UARTEN;
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RTSDEN | UCR1_RRDYEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RTSDEN | UCR1_RRDYEN);
ucr2 |= UCR2_RXEN;
ucr2 &= ~UCR2_ATEN;
@@ -1938,7 +1938,7 @@ imx_uart_console_write(struct console *co, const char *s, unsigned int count)
if (imx_uart_is_imx1(sport))
ucr1 |= IMX1_UCR1_UARTCLKEN;
ucr1 |= UCR1_UARTEN;
- ucr1 &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN);
+ ucr1 &= ~(UCR1_TRDYEN | UCR1_RRDYEN | UCR1_RTSDEN);
imx_uart_writel(sport, ucr1, UCR1);
@@ -2294,7 +2294,7 @@ static int imx_uart_probe(struct platform_device *pdev)
/* Disable interrupts before requesting them */
ucr1 = imx_uart_readl(sport, UCR1);
ucr1 &= ~(UCR1_ADEN | UCR1_TRDYEN | UCR1_IDEN | UCR1_RRDYEN |
- UCR1_TXMPTYEN | UCR1_RTSDEN);
+ UCR1_TRDYEN | UCR1_RTSDEN);
imx_uart_writel(sport, ucr1, UCR1);
if (!imx_uart_is_imx1(sport) && sport->dte_mode) {
--
2.10.0.1.g57b01a3
_______________________________________________
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 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
From: Tony Lindgren @ 2019-08-28 18:45 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Arnd Bergmann, Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Linus Walleij, Linux Kernel Mailing List, Dominik Brodowski,
Tomi Valkeinen, linux-omap, Linux ARM
In-Reply-To: <20190828182318.GL30291@darkstar.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [190828 18:23]:
> On Wed, Aug 28, 2019 at 03:02:36PM +0200, Arnd Bergmann wrote:
> > I assume you checked that the uart output wasn't already broken
> > by one of the earlier patches, right?
>
> Correct, it's only with the mapping change patch it hangs.
>
> > Also, looking at arch/arm/mach-omap1/include/mach/uncompress.h
> > it seems that SX1 normally uses UART3, not UART1.
> > Is that different in qemu?
>
> In QEMU all uarts can be used, trying with UART3 as early console
> hangs as well. (It prints Uncompressing... done. but I guess that's
> done with the physical address.)
Hmm maybe we now need to get rid of the machine based
detection code for DEBUGLL like we did for mach-omap2.
Just get rid of arch_decomp_setup() in mach-omap1
uncompress.h file and make sure the assembly code
only relies on the the Kconfig options only.
That needs to be done at least for device tree based
support since we use a generic machine ID. But maybe
with multiarch support we need to rely on generic
uncompress.h and assembly.
Regards,
Tony
_______________________________________________
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-smmu: check for generic bindings first
From: Robin Murphy @ 2019-08-28 18:55 UTC (permalink / raw)
To: Stefano Stabellini, will
Cc: linux-kernel, Stefano Stabellini, michal.simek, linux-arm-kernel,
git
In-Reply-To: <20190828173837.29617-1-sstabellini@kernel.org>
On 28/08/2019 18:38, Stefano Stabellini wrote:
> From: Stefano Stabellini <stefano.stabellini@xilinx.com>
>
> Today, the arm-smmu driver checks for mmu-masters on device tree, the
> legacy property, if it is absent it assumes that we are using the new
> bindings. If it is present it assumes that we are using the legacy
> bindings. All arm-smmus need to use the same bindings: legacy or new.
>
> There are two issues with this:
>
> - we are not actually checking for the new bindings explicitly
> It would be better to have an explicit check for the new bindings rather
> than assuming we must be using the new if the old are not there.
The legacy binding is the special case, though. Isn't it perfectly
logical to check for the special case, and assume the normal case
otherwise? ;)
> - old and new bindings cannot coexist
> It would be nice to be able to provide both old and new bindings so
> that software that hasn't been updated yet is still able to get IOMMU
> information from the legacy bindings while at the same time newer
> software can get the latest information via the new bindings. (Xen has
> not been updated to use the new binding yet for instance.) The current
> code breaks under these circumstances because if the old bindings are
> present, the new are not even checked.
FWIW that was a deliberate design decision. We didn't want to see DTs
with both bindings at once - the legacy binding support remains only for
the sake of DTBs deployed in fossilised firmware that can't/won't ever
be updated. And I'm pretty sure the intervening 3 years have only
reinforced that position. Only a couple more months now until it will
have been deprecated for longer than it wasn't :)
Do note that "mmu-masters" isn't just deprecated for giggles either -
the binding made some flawed assumptions, and there are Stream ID
topologies that it cannot possibly describe, which do exist in the real
world.
> This patch changes the scheme by checking for #iommu-cells, which is
> only present with the new bindings, before checking for mmu-masters.
> The new bindings are always favored when present. All SMMUs still need
> to use the same bindings: mix-and-matching new and old bindings between
> different SMMUs is not allowed.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
> ---
>
> Let me know if you'd like me to turn the two using_*_binding variables
> into a single one.
>
> Also, please note that this is not meant as an excuse not to get Xen
> updated to use the new binding.
Fair enough, but conversely, what makes it Linux's responsibility to
handle? If Xen wants to deal with funky hybrid DTs then why shouldn't it
be Xen's job to just filter deprecated properties out of whatever it
presents to Linux?
Robin.
> drivers/iommu/arm-smmu.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 64977c131ee6..79b518ff215c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -2118,7 +2118,7 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
> {
> const struct arm_smmu_match_data *data;
> struct device *dev = &pdev->dev;
> - bool legacy_binding;
> + bool legacy_binding, generic_binding;
>
> if (of_property_read_u32(dev->of_node, "#global-interrupts",
> &smmu->num_global_irqs)) {
> @@ -2132,16 +2132,20 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev,
>
> parse_driver_options(smmu);
>
> - legacy_binding = of_find_property(dev->of_node, "mmu-masters", NULL);
> - if (legacy_binding && !using_generic_binding) {
> - if (!using_legacy_binding)
> - pr_notice("deprecated \"mmu-masters\" DT property in use; DMA API support unavailable\n");
> - using_legacy_binding = true;
> - } else if (!legacy_binding && !using_legacy_binding) {
> + generic_binding = of_find_property(dev->of_node, "#iommu-cells", NULL);
> + if (generic_binding && !using_legacy_binding) {
> using_generic_binding = true;
> } else {
> - dev_err(dev, "not probing due to mismatched DT properties\n");
> - return -ENODEV;
> + legacy_binding = of_find_property(dev->of_node, "mmu-masters",
> + NULL);
> + if (legacy_binding && !using_generic_binding) {
> + if (!using_legacy_binding)
> + pr_notice("deprecated \"mmu-masters\" DT property in use; DMA API support unavailable\n");
> + using_legacy_binding = true;
> + } else {
> + dev_err(dev, "not probing due to mismatched DT properties\n");
> + return -ENODEV;
> + }
> }
>
> if (of_dma_is_coherent(dev->of_node))
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
From: Mathieu Poirier @ 2019-08-28 19:31 UTC (permalink / raw)
To: Igor Lubashev
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
James Morris, Linux Kernel Mailing List, Arnaldo Carvalho de Melo,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <1566869956-7154-1-git-send-email-ilubashe@akamai.com>
On Mon, 26 Aug 2019 at 19:40, Igor Lubashev <ilubashe@akamai.com> wrote:
>
> This is a follow up series to the ensure perf treats perf_event_paranoid and
> kptr_restrict in a way that is similar to the kernel's. That includes use of
> capabilities instead of euid==0, when possible, as well as adjusting the logic
> and fixing bugs.
>
> Prior discussion: https://lkml.kernel.org/lkml/cover.1565188228.git.ilubashe@akamai.com
>
> === Testing notes ===
>
> I have tested on x86 with perf binary installed according to
> Documentation/admin-guide/perf-security.rst (cap_sys_admin, cap_sys_ptrace,
> cap_syslog assigned to the perf executable).
>
> I tested each permutation of:
>
> * 7 commits:
> 1. HEAD of perf/core
> 2. patch 01 on top of perf/core
> 3. patches 01-02 on top of perf/core
> 4. patches 01-03 on top of perf/core
> 5. patches 01-04 on top of perf/core
> 6. patches 01-05 on top of perf/core
> 7. HEAD of perf/cap (with known bug fixed by patch 01 of this series)
>
> * 2 build environments: with and without libcap-dev
>
> * 3 kernel.kptr_restrict values: 0, 1, 2
>
> * 4 kernel.perf_event_paranoid values: -1, 0, 1, 2
>
> * 2 users: root and non-root
>
> Total: 336 permutations
>
> Each permutation consisted of:
> perf test
> perf record -e instructions -- sleep 1
>
> All test runs were expected. Also, as expected, the following permutation (just
> that permutation) resulted in segmentation failure:
> commit: perf/cap
> build: no libcap-dev
> kernel.kptr_restrict: 0
> kernel.perf_event_paranoid: 2
> user: non-root
>
> The perf/cap commit was included in the test to ensure that we can reproduce the
> crash and hence test that the patch series fixes the crash, while retaining the
> desired behavior of perf/cap.
>
> === Series Contents ===
>
> 01: perf event: Check ref_reloc_sym before using it
> Fix the pre-existing cause of the crash above: use of ref_reloc_sym without
> a check for NULL
>
> 02: perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
> perf_event_paranoid level is verified.
> * This patch has been reviewed previously and is unchanged.
> * I kept Acks and Sign-offs.
>
> 03: perf util: kernel profiling is disallowed only when perf_event_paranoid>1
> Align perf logic regarding perf_event_paranoid to match kernel's.
> This has been reported by Arnaldo.
>
> 04: perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> Replace the use of uid and euid with a check for CAP_SYSLOG when
> kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
> Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
> * A previous version of this patch has been reviewed previously, but I
> * modified it in a non-trivial way, so I removed Acks.
>
> 05: perf: warn perf_event_paranoid restrict kernel symbols
> Warn that /proc/sys/kernel/perf_event_paranoid can also restrict kernel
> symbols.
>
> Igor Lubashev (5):
> perf event: Check ref_reloc_sym before using it
> perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
> perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> perf: warn that perf_event_paranoid can restrict kernel symbols
>
> tools/perf/arch/arm/util/cs-etm.c | 3 ++-
For the coresight part:
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
> tools/perf/arch/x86/util/intel-bts.c | 3 ++-
> tools/perf/arch/x86/util/intel-pt.c | 2 +-
> tools/perf/builtin-record.c | 2 +-
> tools/perf/builtin-top.c | 2 +-
> tools/perf/builtin-trace.c | 2 +-
> tools/perf/util/event.c | 7 ++++---
> tools/perf/util/evsel.c | 2 +-
> tools/perf/util/symbol.c | 15 ++++++++++++---
> 10 files changed, 27 insertions(+), 14 deletions(-)
For the set:
Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v4 3/3] dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the new phylink API
From: David Miller @ 2019-08-28 19:56 UTC (permalink / raw)
To: matthias.bgg
Cc: nelson.chang, frank-w, netdev, sean.wang, linux-mips, linux,
opensource, linux-mediatek, john, sr, linux-arm-kernel
In-Reply-To: <e45565b1-bb63-66af-16f6-5c7c1094dd67@gmail.com>
From: Matthias Brugger <matthias.bgg@gmail.com>
Date: Wed, 28 Aug 2019 11:29:45 +0200
> Thanks for taking this patch. For the next time, please make sure that dts[i]
> patches are independent from the binding description, as dts[i] should go
> through my tree. No problem for this round, just saying for the future.
That's not always possible nor reasonable, to be quite honest.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] perf: Treat perf_event_paranoid and kptr_restrict like the kernel does it
From: Arnaldo Carvalho de Melo @ 2019-08-28 20:22 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki Poulouse, Alexander Shishkin, Alexey Budankov,
Igor Lubashev, James Morris, Linux Kernel Mailing List,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <CANLsYkwZm9ehopjDMXNw-3JOj8MPeT_shPPJBOeLNe7BUtibmA@mail.gmail.com>
Em Wed, Aug 28, 2019 at 01:31:21PM -0600, Mathieu Poirier escreveu:
> On Mon, 26 Aug 2019 at 19:40, Igor Lubashev <ilubashe@akamai.com> wrote:
> > Igor Lubashev (5):
> > perf event: Check ref_reloc_sym before using it
> > perf tools: Use CAP_SYS_ADMIN with perf_event_paranoid checks
> > perf util: kernel profiling is disallowed only when perf_event_paranoid > 1
> > perf symbols: Use CAP_SYSLOG with kptr_restrict checks
> > perf: warn that perf_event_paranoid can restrict kernel symbols
> > tools/perf/arch/arm/util/cs-etm.c | 3 ++-
> For the coresight part:
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > tools/perf/arch/arm64/util/arm-spe.c | 3 ++-
> > tools/perf/arch/x86/util/intel-bts.c | 3 ++-
> > tools/perf/arch/x86/util/intel-pt.c | 2 +-
> > tools/perf/builtin-record.c | 2 +-
> > tools/perf/builtin-top.c | 2 +-
> > tools/perf/builtin-trace.c | 2 +-
> > tools/perf/util/event.c | 7 ++++---
> > tools/perf/util/evsel.c | 2 +-
> > tools/perf/util/symbol.c | 15 ++++++++++++---
> > 10 files changed, 27 insertions(+), 14 deletions(-)
>
> For the set:
>
> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Thanks, updated the patches with your tags,
- Arnaldo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND v11 7/8] open: openat2(2) syscall
From: Spencer Baugh @ 2019-08-28 20:17 UTC (permalink / raw)
To: Jeff Layton, linux-fsdevel
Cc: linux-arch, linux-ia64, linux-parisc, linux-sh, linux-api,
linux-kernel, linux-mips, linuxppc-dev, linux-alpha, sparclinux,
linux-arm-kernel
In-Reply-To: <4da231cd52880991d8a038adb8fbb2ef3d724db9.camel@kernel.org>
Jeff Layton <jlayton@kernel.org> writes:
> On Mon, 2019-08-26 at 19:50 +0000, sbaugh@catern.com wrote:
>> Aleksa Sarai <cyphar@cyphar.com> writes:
>> > To this end, we introduce the openat2(2) syscall. It provides all of the
>> > features of openat(2) through the @how->flags argument, but also
>> > also provides a new @how->resolve argument which exposes RESOLVE_* flags
>> > that map to our new LOOKUP_* flags. It also eliminates the long-standing
>> > ugliness of variadic-open(2) by embedding it in a struct.
>>
>> I don't like this usage of a structure in memory to pass arguments that
>> would fit in registers. This would be quite inconvenient for me as a
>> userspace developer.
>>
>> Others have brought up issues with this: the issue of seccomp, and the
>> issue of mismatch between the userspace interface and the kernel
>> interface, are the most important for me. I want to add another,
>> admittedly somewhat niche, concern.
>>
>> This interfaces requires a program to allocate memory (even on the
>> stack) just to pass arguments to the kernel which could be passed
>> without allocating that memory. That makes it more difficult and less
>> efficient to use this syscall in any case where memory is not so easily
>> allocatable: such as early program startup or assembly, where the stack
>> may be limited in size or not even available yet, or when injecting a
>> syscall while ptracing.
>>
>> A struct-passing interface was needed for clone, since we ran out of
>> registers; but we have not run out of registers yet for openat, so it
>> would be nice to avoid this if we can. We can always expand later...
>>
>
> We can't really expand later like you suggest.
>
> Suppose in a couple of years that we need to add some new argument to
> openat2 that isn't just a new flag. If all these values are passed by
> individual arguments, you can't add one later without adding yet another
> syscall.
Sure we can. This new syscall doesn't need to use all 6 available
arguments. It can enforce that the unused ones are 0. Then if we
eventually run out of flags and need to switch to pass arguments via
struct, we can just use one of the unused arguments for that purpose.
Even if we used all 6 arguments, in the worst-case scenario, the last
flag we add could change the interpretation of some other argument so it
can be used to pass a pointer to a struct.
_______________________________________________
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