RE: [PATCH 1/2] ARM: add ARM_SINGLE_ARMV7 as config option
Hello Florian, On Wednesday, February 08, 2017, Florian Fainelli wrote: > On 02/08/2017 07:30 PM, Chris Brandt wrote: > > Creates a new ARM_SINGLE_ARMV7 option as an alternative > ARCH_MULTIPLATFORM. > > > > ARM_SINGLE_ARMV7 is very similar to ARCH_MULTIPLATFORM, except the > > options from ARCH_MULTI_V6_V7 were copied directly into the new > ARM_SINGLE_ARMV7. > > > > Additionally, everywhere ARCH_MULTIPLATFORM existed in build scripts, > > ARM_SINGLE_ARMV7 was added along side it in order to produce similar > > results. > > Could we try to be a little smarter than this and if ARCH_MULTIPLATFORM is > selected but only one platform beneath is we automatically select > ARM_SINGLE_ARMV7 (this may require Kconfig hackery)? Months ago I spent hours on trying to get the current kbuild system to do that and nothing I came up with would work. It's simply not designed that way. I think the closest I might have come was to purposely break the build if more then 1 was select, but that still didn't stop you from making the selection. If someone smarter than me has a way to do (not just an idea...I received lots of ideas but none of them worked), I'd be happy to hear it. > I see value in what you are doing, but I don't think pulling the platforms > out of the menu like what you do in the subsequent patch is looking nice > as an user/configurator. What I was trying to do (and what was already removed from Kconfigs) was to avoid having a duplicate set of configs for each SOC: one for single and one for multi. #I'm trying to get away from manually hacking these Kconfig files every time a new kernel is released. Chris
[PATCH 1/2] ARM: add ARM_SINGLE_ARMV7 as config option
Creates a new ARM_SINGLE_ARMV7 option as an alternative ARCH_MULTIPLATFORM.
ARM_SINGLE_ARMV7 is very similar to ARCH_MULTIPLATFORM, except the options
from ARCH_MULTI_V6_V7 were copied directly into the new ARM_SINGLE_ARMV7.
Additionally, everywhere ARCH_MULTIPLATFORM existed in build scripts,
ARM_SINGLE_ARMV7 was added along side it in order to produce similar
results.
Signed-off-by: Chris Brandt
---
arch/arm/Kconfig | 18 ++
arch/arm/Kconfig.debug| 6 --
arch/arm/Makefile | 5 +
arch/arm/kernel/devtree.c | 3 ++-
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bf8d86d..36107e7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -317,6 +317,24 @@ config ARCH_MMAP_RND_BITS_MAX
default 15 if PAGE_OFFSET=0x8000
default 16
+config ARM_SINGLE_ARMV7
+ bool "ARMv7 based single platforms"
+ depends on MMU
+ select ARM_HAS_SG_CHAIN
+ select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select CPU_V7
+ select GENERIC_CLOCKEVENTS
+ select MIGHT_HAVE_PCI
+ select MULTI_IRQ_HANDLER
+ select PCI_DOMAINS if PCI
+ select SPARSE_IRQ
+ select USE_OF
+ select HAVE_SMP
+ select MIGHT_HAVE_CACHE_L2X0
+
#
# The "ARM system type" choice list is ordered alphabetically by option
# text. Please add new entries in the option alphabetic order.
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d83f7c3..31db9e3 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1694,7 +1694,8 @@ config DEBUG_UART_8250_FLOW_CONTROL
config DEBUG_UNCOMPRESS
bool
- depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV7
default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
(!DEBUG_TEGRA_UART || !ZBOOT_ROM) && \
!DEBUG_BRCMSTB_UART
@@ -1712,7 +1713,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV7
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ab30cc6..c9809b6 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -255,12 +255,16 @@ endif
ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y)
MACHINE :=
endif
+ifeq ($(CONFIG_ARM_SINGLE_ARMV7),y)
+MACHINE :=
+endif
machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
platdirs := $(patsubst %,arch/arm/plat-%/,$(sort $(plat-y)))
ifneq ($(CONFIG_ARCH_MULTIPLATFORM),y)
ifneq ($(CONFIG_ARM_SINGLE_ARMV7M),y)
+ifneq ($(CONFIG_ARM_SINGLE_ARMV7),y)
ifeq ($(KBUILD_SRC),)
KBUILD_CPPFLAGS += $(patsubst %,-I%include,$(machdirs) $(platdirs))
else
@@ -268,6 +272,7 @@ KBUILD_CPPFLAGS += $(patsubst
%,-I$(srctree)/%include,$(machdirs) $(platdirs))
endif
endif
endif
+endif
export TEXT_OFFSET GZFLAGS MMUEXT
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f676feb..26cbc29 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -220,7 +220,8 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
{
const struct machine_desc *mdesc, *mdesc_best = NULL;
-#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M)
+#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M) ||
\
+defined(CONFIG_ARM_SINGLE_ARMV7)
DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
.l2c_aux_val = 0x0,
.l2c_aux_mask = ~0x0,
--
2.10.1
[PATCH 0/2] ARM: ARMv7 (with MMU) XIP without ARCH_MULTIPLATFORM
The basic idea of this series is to introduce a top level ARM_SINGLE_ARMV7 that can be selected instead of ARCH_MULTIPLATFORM for the purpose of being able to select XIP_KERNEL. ARM_SINGLE_ARMV7 is not selected directly, but rather by first selecting a specific SOC family (as opposed to the multiplatform option), then the SoC family will select ARM_SINGLE_ARMV7. At that point, an individual SOC device can selected which then allows them to select XIP_KERNEL if they want to. It is up to the SoC familiies to determine if XIP and/or ARM_SINGLE_ARMV7 makes sence. For this series, the Renesas SoCs allow ARM_SINGLE_ARMV7. Particulary, the Renesas RZ/A1 (ARCH_R7S72100) was tested with both XIP_KERNEL=y and XIP_KERNEL=n. System Type ---> [*] MMU-based Paged Memory Management Support -*- ARMv7 based single platforms ARM system type (Renesas ARM SoCs) [*] Renesas ARM SoCs ---> [*] RZ/A1H (R7S72100) For me, I was able to come up with a .config that would produce the same defconfig as it did before this patch series proving that ARCH_MULTIPLATFORM is just a method in grouping configs together that could normally be selected individually. I would say maybe the only other thing we could add is a XIP_CAPABLE config that is set only by each individual SoC. Then users can only select XIP_KERNEL for SoCs that actually have a chance at working. Something like: [ arch/arm/mach-shmobile/Kconfig ] config ARCH_R7S72100 bool "RZ/A1H (R7S72100)" select PM select PM_GENERIC_DOMAINS select SYS_SUPPORTS_SH_MTU2 select RENESAS_OSTM select XIP_CAPABLE [ arch/arm/Kconifg ] config XIP_KERNEL bool "Kernel Execute-In-Place from ROM" depends on !ARM_LPAE && !ARCH_MULTIPLATFORM && XIP_CAPABLE Chris Brandt (2): ARM: add ARM_SINGLE_ARMV7 as config option ARM: shmobile: add renesas soc as a top level selection arch/arm/Kconfig | 22 ++ arch/arm/Kconfig.debug | 6 -- arch/arm/Makefile | 5 + arch/arm/kernel/devtree.c | 3 ++- arch/arm/mach-shmobile/Kconfig | 2 +- 5 files changed, 34 insertions(+), 4 deletions(-) -- 2.10.1
[PATCH 2/2] ARM: shmobile: add renesas soc as a top level selection
Allows users to select "Renesas ARM SoCs" as opposed to multiplatform. ARM_SINGLE_ARMV7 is then selected to help with the behind the scenes work in the build scripts. Signed-off-by: Chris Brandt --- arch/arm/Kconfig | 4 arch/arm/mach-shmobile/Kconfig | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 36107e7..9c468dd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -359,6 +359,10 @@ config ARCH_MULTIPLATFORM select SPARSE_IRQ select USE_OF +config ARM_SOC_RENESAS_V7 + bool "Renesas ARM SoCs" + select ARM_SINGLE_ARMV7 + config ARM_SINGLE_ARMV7M bool "ARMv7-M based platforms (Cortex-M0/M3/M4)" depends on !MMU diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index ad7d604..1317aea 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -31,7 +31,7 @@ config ARCH_RMOBILE menuconfig ARCH_RENESAS bool "Renesas ARM SoCs" - depends on ARCH_MULTI_V7 && MMU + depends on (ARCH_MULTI_V7 || ARM_SOC_RENESAS_V7) && MMU select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE select ARCH_SHMOBILE select ARCH_SHMOBILE_MULTI -- 2.10.1
Re: [PATCH 1/2] ARM: add ARM_SINGLE_ARMV7 as config option
On 02/08/2017 07:30 PM, Chris Brandt wrote:
> Creates a new ARM_SINGLE_ARMV7 option as an alternative ARCH_MULTIPLATFORM.
>
> ARM_SINGLE_ARMV7 is very similar to ARCH_MULTIPLATFORM, except the options
> from ARCH_MULTI_V6_V7 were copied directly into the new ARM_SINGLE_ARMV7.
>
> Additionally, everywhere ARCH_MULTIPLATFORM existed in build scripts,
> ARM_SINGLE_ARMV7 was added along side it in order to produce similar
> results.
Could we try to be a little smarter than this and if ARCH_MULTIPLATFORM
is selected but only one platform beneath is we automatically select
ARM_SINGLE_ARMV7 (this may require Kconfig hackery)?
I see value in what you are doing, but I don't think pulling the
platforms out of the menu like what you do in the subsequent patch is
looking nice as an user/configurator.
>
> Signed-off-by: Chris Brandt
> ---
> arch/arm/Kconfig | 18 ++
> arch/arm/Kconfig.debug| 6 --
> arch/arm/Makefile | 5 +
> arch/arm/kernel/devtree.c | 3 ++-
> 4 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index bf8d86d..36107e7 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -317,6 +317,24 @@ config ARCH_MMAP_RND_BITS_MAX
> default 15 if PAGE_OFFSET=0x8000
> default 16
>
> +config ARM_SINGLE_ARMV7
> + bool "ARMv7 based single platforms"
> + depends on MMU
> + select ARM_HAS_SG_CHAIN
> + select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
> + select AUTO_ZRELADDR
> + select CLKSRC_OF
> + select COMMON_CLK
> + select CPU_V7
> + select GENERIC_CLOCKEVENTS
> + select MIGHT_HAVE_PCI
> + select MULTI_IRQ_HANDLER
> + select PCI_DOMAINS if PCI
> + select SPARSE_IRQ
> + select USE_OF
> + select HAVE_SMP
> + select MIGHT_HAVE_CACHE_L2X0
> +
> #
> # The "ARM system type" choice list is ordered alphabetically by option
> # text. Please add new entries in the option alphabetic order.
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index d83f7c3..31db9e3 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1694,7 +1694,8 @@ config DEBUG_UART_8250_FLOW_CONTROL
>
> config DEBUG_UNCOMPRESS
> bool
> - depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
> + depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
> +ARM_SINGLE_ARMV7
> default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
>(!DEBUG_TEGRA_UART || !ZBOOT_ROM) && \
>!DEBUG_BRCMSTB_UART
> @@ -1712,7 +1713,8 @@ config DEBUG_UNCOMPRESS
> config UNCOMPRESS_INCLUDE
> string
> default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
> - PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
> + PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
> + ARM_SINGLE_ARMV7
> default "mach/uncompress.h"
>
> config EARLY_PRINTK
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index ab30cc6..c9809b6 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -255,12 +255,16 @@ endif
> ifeq ($(CONFIG_ARCH_MULTIPLATFORM),y)
> MACHINE :=
> endif
> +ifeq ($(CONFIG_ARM_SINGLE_ARMV7),y)
> +MACHINE :=
> +endif
>
> machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
> platdirs := $(patsubst %,arch/arm/plat-%/,$(sort $(plat-y)))
>
> ifneq ($(CONFIG_ARCH_MULTIPLATFORM),y)
> ifneq ($(CONFIG_ARM_SINGLE_ARMV7M),y)
> +ifneq ($(CONFIG_ARM_SINGLE_ARMV7),y)
> ifeq ($(KBUILD_SRC),)
> KBUILD_CPPFLAGS += $(patsubst %,-I%include,$(machdirs) $(platdirs))
> else
> @@ -268,6 +272,7 @@ KBUILD_CPPFLAGS += $(patsubst
> %,-I$(srctree)/%include,$(machdirs) $(platdirs))
> endif
> endif
> endif
> +endif
>
> export TEXT_OFFSET GZFLAGS MMUEXT
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f676feb..26cbc29 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -220,7 +220,8 @@ const struct machine_desc * __init
> setup_machine_fdt(unsigned int dt_phys)
> {
> const struct machine_desc *mdesc, *mdesc_best = NULL;
>
> -#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M)
> +#if defined(CONFIG_ARCH_MULTIPLATFORM) || defined(CONFIG_ARM_SINGLE_ARMV7M)
> || \
> +defined(CONFIG_ARM_SINGLE_ARMV7)
> DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> .l2c_aux_val = 0x0,
> .l2c_aux_mask = ~0x0,
>
--
Florian
[PATCH 06/10] clocksource/drivers/ostm: Add renesas-ostm timer driver
From: Chris Brandt
This patch adds a OSTM driver for the Renesas architecture.
The OS Timer (OSTM) has independent channels that can be
used as a freerun or interval times.
This driver uses the first probed device as a clocksource
and then any additional devices as clock events.
Signed-off-by: Chris Brandt
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-shmobile/Kconfig | 1 +
drivers/clocksource/Kconfig| 7 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/renesas-ostm.c | 265 +
4 files changed, 274 insertions(+)
create mode 100644 drivers/clocksource/renesas-ostm.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2bb4b09..ad7d604 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
select PM
select PM_GENERIC_DOMAINS
select SYS_SUPPORTS_SH_MTU2
+ select RENESAS_OSTM
config ARCH_R8A73A4
bool "R-Mobile APE6 (R8A73A40)"
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index afef0e8..4002d6d 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -484,6 +484,13 @@ config SH_TIMER_MTU2
Timer Pulse Unit 2 (MTU2) hardware available on SoCs from Renesas.
This hardware comes with 16 bit-timer registers.
+config RENESAS_OSTM
+ bool "Renesas OSTM timer driver" if COMPILE_TEST
+ depends on GENERIC_CLOCKEVENTS
+ select CLKSRC_MMIO
+ help
+ Enables the support for the Renesas OSTM.
+
config SH_TIMER_TMU
bool "Renesas TMU timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dbbee80..d227d13 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)+= cs5535-clockevt.o
obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
+obj-$(CONFIG_RENESAS_OSTM) += renesas-ostm.o
obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
obj-$(CONFIG_EM_TIMER_STI) += em_sti.o
obj-$(CONFIG_CLKBLD_I8253) += i8253.o
diff --git a/drivers/clocksource/renesas-ostm.c
b/drivers/clocksource/renesas-ostm.c
new file mode 100644
index 000..c76f576
--- /dev/null
+++ b/drivers/clocksource/renesas-ostm.c
@@ -0,0 +1,265 @@
+/*
+ * Renesas Timer Support - OSTM
+ *
+ * Copyright (C) 2017 Renesas Electronics America, Inc.
+ * Copyright (C) 2017 Chris Brandt
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The OSTM contains independent channels.
+ * The first OSTM channel probed will be set up as a free running
+ * clocksource. Additionally we will use this clocksource for the system
+ * schedule timer sched_clock().
+ *
+ * The second (or more) channel probed will be set up as an interrupt
+ * driven clock event.
+ */
+
+struct ostm_device {
+ void __iomem *base;
+ unsigned long ticks_per_jiffy;
+ struct clock_event_device ced;
+};
+
+static void __iomem *system_clock; /* For sched_clock() */
+
+/* OSTM REGISTERS */
+#defineOSTM_CMP0x000 /* RW,32 */
+#defineOSTM_CNT0x004 /* R,32 */
+#defineOSTM_TE 0x010 /* R,8 */
+#defineOSTM_TS 0x014 /* W,8 */
+#defineOSTM_TT 0x018 /* W,8 */
+#defineOSTM_CTL0x020 /* RW,8 */
+
+#defineTE 0x01
+#defineTS 0x01
+#defineTT 0x01
+#defineCTL_PERIODIC0x00
+#defineCTL_ONESHOT 0x02
+#defineCTL_FREERUN 0x02
+
+static struct ostm_device *ced_to_ostm(struct clock_event_device *ced)
+{
+ return container_of(ced, struct ostm_device, ced);
+}
+
+static void ostm_timer_stop(struct ostm_device *ostm)
+{
+ if (readb(ostm->base + OSTM_TE) & TE) {
+ writeb(TT, ostm->base + OSTM_TT);
+
+ /*
+* Read back the register simply to confirm the write operation
+* has completed since I/O writes can sometimes get queued by
+* the bus architecture.
+*/
+ while (readb(ostm->base + OSTM_TE) & TE)
+ ;
+
Re: [PATCH] iommu/ipmmu-vmsa: Add r8a7795 DT binding
On Fri, Feb 03, 2017 at 04:10:30PM +0200, Laurent Pinchart wrote: > Hi Rob, > > On Monday 29 Feb 2016 23:33:09 Magnus Damm wrote: > > From: Magnus Damm > > > > Update the IPMMU DT binding documentation to include the r8a7795 compat > > string as well as the "renesas,ipmmu-main" property that on r8a7795 will > > be used to describe the topology and the relationship between the various > > cache IPMMU instances and the main IPMMU. > > > > Signed-off-by: Magnus Damm > > This DT binding has been merged already, but isn't used upstream (nor in the > dts nor in the drivers). We plan to start using it, and I'd like to seize > this > last opportunity to change it if needed and ask you for a review. Looks pretty standard. Rob
RE: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
Hello Russell, On Wednesday, February 08, 2017, Russell King wrote: > We have the big "ARM system type" choice, one of the options there is to > build for multi-platform. Historically, it's been to select the SoC > family - where "SoC family" means a group of SoCs that could be built > together into one image without all the fun and games of V:P patching, > auto-zreladdr, etc - _exactly_ the conditions that !MMU and XIP_KERNEL > depended upon[*]. > > To allow a SOC to be built without multiplatform, you add another option > to that choice statement (exactly as we used to have before multiplatform). > For the sake of argument, let's say we're talking about iMX ARMv7 SoCs. > So, let's call it ARM_SOC_IMX_V7. > > You add to that all the select statements that multiplatform gives you > that you need for that platform, omitting those that don't make sense > (like virt/phys patching), making it depend on XIP_KERNEL and/or !MMU. > > Then you change the mach-*/Kconfig entry like this: > > menuconfig ARCH_MXC > - bool "Freescale i.MX family" > - depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M > + bool "Freescale i.MX family" if !ARM_SOC_IMX_V7 > + depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M ||\ > + ARM_SOC_IMX_V7 > + default ARM_SOC_IMX_V7 > > and also modify the if ARCH_MULTI_V7 to also allow that section if > ARM_SOC_IMX_V7 is enabled. > > > * - that's the problem - multiplatform went head-long into the "we don't > like the existing solution, we need to move everyone away, and let's hope > no one wants XIP_KERNEL or !MMU now". So we went from a relatively good > solution that didn't support building diverse platforms together to one > that rather sucks for XIP_KERNEL and !MMU. So, a quick hack and it seems that works. I get my family of SoC that I can select XIP_KERNEL. I'll do some build experiments, and if it looks like it will work, I'll send off a patch to see how opposes it. For the most part, if everyone is off playing in the multiplatform pool, me creating a new ARM V7 single-platform pool won't affect anyone. Chris
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
On Wed, Feb 08, 2017 at 07:46:55PM +0100, Geert Uytterhoeven wrote: > Hi Russell, > > On Wed, Feb 8, 2017 at 7:39 PM, Russell King - ARM Linux > wrote: > > On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote: > >> The problem is that "multiplatform" may mean one of two things: > >> 1. Build a single kernel that can run on multiple platforms. > >> This is tricky when enabling XIP and/or NOMMU, as the physical > >> parameters > >> must be compatible with all platforms. But building a kernel with the > >> right parameters is the responsibility of the user. > >> I.e. don't shoot yourself in the foot. > >> 2. Your platform uses the arch/arm multiplatform framework. > >> > >> As everything is being migrated to 2, not allowing XIP and/or NOMMU on > >> "multiplatform" is IMHO an insane limitation. > > > > There _isn't_ a framework. What there is are a collection of Kconfig > > options that multiplatform provides you that can also be selected by > > any other configuration route. > > > > (2) really doesn't apply. > > > > The real issue is that board stuff ends up with a "depends on MULTI_xxx" > > which needs to be bypassed. That's pretty easy to do - I've done it as > > a proof of concept a few years ago when this exact same thing came up > > for !MMU, and since then I've been NAKing and refusing to apply patches > > that try to re-use multiplat for !MMU. > > So you mean this: > > --- a/arch/arm/mach-shmobile/Kconfig > +++ b/arch/arm/mach-shmobile/Kconfig > @@ -31,7 +31,7 @@ config ARCH_RMOBILE > > menuconfig ARCH_RENESAS > bool "Renesas ARM SoCs" > - depends on ARCH_MULTI_V7 && MMU > + depends on MMU > select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE > select ARCH_SHMOBILE > select ARCH_SHMOBILE_MULTI I don't see the connection, sorry. That looks totally broken to me, because you now end up being able to select it when you have (eg) something like ARCH_RPC enabled, and that's totally insane. If you think the above patch in some way represents what I was saying, that's wrong as well. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
On Wed, Feb 08, 2017 at 06:00:26PM +, Chris Brandt wrote: > On Wednesday, February 08, 2017, Russell King wrote: > > On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote: > > > Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even > > > though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', > > > ARM_PATCH_PHYS_VIRT is still forcibly selected. The result is that > > > PHYS_OFFSET depends on !ARM_PATCH_PHYS_VIRT. This means you cannot > > > enter a physical RAM address for an XIP kernel and you cannot build. > > > > > > Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT > > > and XIP_KERNEL do not go well together (read the help for > > > ARM_PATCH_PHYS_VIRT), adding this condition to ARCH_MULTIPLATFORM is > > > logical and will fix this build issue. > > > > And, ergo, multiplatform kernels and XIP_KERNEL don't go together either. > > Think about it... > > > > This is why I regard those who want multiplatform to work with options > > such as XIP_KERNEL and NOMMU to be insane. > > It's not so much that I want multiplatform and XIP together (because > absolutely they do not), it's that the SOC I care about is shoved under > the multiplatform umbrella. Right, and that's what I hear all the time, but it's not really an argument that stacks up. We have the big "ARM system type" choice, one of the options there is to build for multi-platform. Historically, it's been to select the SoC family - where "SoC family" means a group of SoCs that could be built together into one image without all the fun and games of V:P patching, auto-zreladdr, etc - _exactly_ the conditions that !MMU and XIP_KERNEL depended upon[*]. To allow a SOC to be built without multiplatform, you add another option to that choice statement (exactly as we used to have before multiplatform). For the sake of argument, let's say we're talking about iMX ARMv7 SoCs. So, let's call it ARM_SOC_IMX_V7. You add to that all the select statements that multiplatform gives you that you need for that platform, omitting those that don't make sense (like virt/phys patching), making it depend on XIP_KERNEL and/or !MMU. Then you change the mach-*/Kconfig entry like this: menuconfig ARCH_MXC - bool "Freescale i.MX family" - depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M + bool "Freescale i.MX family" if !ARM_SOC_IMX_V7 + depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M ||\ + ARM_SOC_IMX_V7 + default ARM_SOC_IMX_V7 and also modify the if ARCH_MULTI_V7 to also allow that section if ARM_SOC_IMX_V7 is enabled. * - that's the problem - multiplatform went head-long into the "we don't like the existing solution, we need to move everyone away, and let's hope no one wants XIP_KERNEL or !MMU now". So we went from a relatively good solution that didn't support building diverse platforms together to one that rather sucks for XIP_KERNEL and !MMU. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
Hi Russell,
On Wed, Feb 8, 2017 at 7:39 PM, Russell King - ARM Linux
wrote:
> On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote:
>> The problem is that "multiplatform" may mean one of two things:
>> 1. Build a single kernel that can run on multiple platforms.
>> This is tricky when enabling XIP and/or NOMMU, as the physical
>> parameters
>> must be compatible with all platforms. But building a kernel with the
>> right parameters is the responsibility of the user.
>> I.e. don't shoot yourself in the foot.
>> 2. Your platform uses the arch/arm multiplatform framework.
>>
>> As everything is being migrated to 2, not allowing XIP and/or NOMMU on
>> "multiplatform" is IMHO an insane limitation.
>
> There _isn't_ a framework. What there is are a collection of Kconfig
> options that multiplatform provides you that can also be selected by
> any other configuration route.
>
> (2) really doesn't apply.
>
> The real issue is that board stuff ends up with a "depends on MULTI_xxx"
> which needs to be bypassed. That's pretty easy to do - I've done it as
> a proof of concept a few years ago when this exact same thing came up
> for !MMU, and since then I've been NAKing and refusing to apply patches
> that try to re-use multiplat for !MMU.
So you mean this:
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -31,7 +31,7 @@ config ARCH_RMOBILE
menuconfig ARCH_RENESAS
bool "Renesas ARM SoCs"
- depends on ARCH_MULTI_V7 && MMU
+ depends on MMU
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select ARCH_SHMOBILE
select ARCH_SHMOBILE_MULTI
?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
On Wed, Feb 08, 2017 at 06:53:14PM +0100, Geert Uytterhoeven wrote: > The problem is that "multiplatform" may mean one of two things: > 1. Build a single kernel that can run on multiple platforms. > This is tricky when enabling XIP and/or NOMMU, as the physical parameters > must be compatible with all platforms. But building a kernel with the > right parameters is the responsibility of the user. > I.e. don't shoot yourself in the foot. > 2. Your platform uses the arch/arm multiplatform framework. > > As everything is being migrated to 2, not allowing XIP and/or NOMMU on > "multiplatform" is IMHO an insane limitation. There _isn't_ a framework. What there is are a collection of Kconfig options that multiplatform provides you that can also be selected by any other configuration route. (2) really doesn't apply. The real issue is that board stuff ends up with a "depends on MULTI_xxx" which needs to be bypassed. That's pretty easy to do - I've done it as a proof of concept a few years ago when this exact same thing came up for !MMU, and since then I've been NAKing and refusing to apply patches that try to re-use multiplat for !MMU. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
RE: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
On Wednesday, February 08, 2017, Russell King wrote: > On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote: > > Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even > > though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', > > ARM_PATCH_PHYS_VIRT is still forcibly selected. The result is that > > PHYS_OFFSET depends on !ARM_PATCH_PHYS_VIRT. This means you cannot > > enter a physical RAM address for an XIP kernel and you cannot build. > > > > Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT > > and XIP_KERNEL do not go well together (read the help for > > ARM_PATCH_PHYS_VIRT), adding this condition to ARCH_MULTIPLATFORM is > > logical and will fix this build issue. > > And, ergo, multiplatform kernels and XIP_KERNEL don't go together either. > Think about it... > > This is why I regard those who want multiplatform to work with options > such as XIP_KERNEL and NOMMU to be insane. It's not so much that I want multiplatform and XIP together (because absolutely they do not), it's that the SOC I care about is shoved under the multiplatform umbrella. > Please, can we stop trying to make multiplatform also cover the situations > where only a single class of platforms works (iow, the old way we used to > deal with platforms is the most sensible solution.) > > IMHO multiplatform was done right for multiplatform but at the expense of > totally breaking stuff like XIP and noMMU. We need to stop trying to bend > multiplatform to cover XIP and noMMU, but instead restore the old way of > handling this _along_ with multiplatform as an additional option. A while back there was a grandiose idea if it would be great you only selected 1 (and only 1) of the platforms in a multiplatform arch, then and only then would the XIP option become available for you. However, I tried everything I could, but the kbuild system just doesn't have a way to do such a thing. So, I'm back to shoving XIP and multiplatform together. So, any ideas on how I can take an ARCH_xxx and make it show up under both single and multiplatform?? Can I get away with making a separate ARCH_xxx_XIP that selects ARCH_xxx? Of course I just tested 4.10-rc7 for XIP+MMU and it works fine, but I have to hack the Kconfig each time. Chris
[PATCH 2/2] ARM: dts: r8a7745: Fix SCIFB0 dmas indentation
Fixes: e0d2da54c4d01ba2 ("ARM: dts: r8a7745: add [H]SCIF{|A|B} support")
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7745.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index ac62c14af764dd1a..112eabdaddb549f2 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -288,7 +288,7 @@
clocks = <&cpg CPG_MOD 206>;
clock-names = "fck";
dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
- <&dmac1 0x3d>, <&dmac1 0x3e>;
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
dma-names = "tx", "rx", "tx", "rx";
power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
status = "disabled";
--
1.9.1
[PATCH 1/2] ARM: dts: r8a7743: Fix SCIFB0 dmas indentation
Fixes: 809c013426914694 ("ARM: dts: r8a7743: add [H]SCIF{A|B} support")
Signed-off-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7743.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 5f2287ea00922ee0..bc350dcc1be67afd 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -288,7 +288,7 @@
clocks = <&cpg CPG_MOD 206>;
clock-names = "fck";
dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
- <&dmac1 0x3d>, <&dmac1 0x3e>;
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
dma-names = "tx", "rx", "tx", "rx";
power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
status = "disabled";
--
1.9.1
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
Hi Russell,
On Wed, Feb 8, 2017 at 6:44 PM, Russell King - ARM Linux
wrote:
> On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote:
>> Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even
>> though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT
>> is still forcibly selected. The result is that PHYS_OFFSET depends on
>> !ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address
>> for an XIP kernel and you cannot build.
>>
>> Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and
>> XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT),
>> adding this condition to ARCH_MULTIPLATFORM is logical and will fix this
>> build issue.
>
> And, ergo, multiplatform kernels and XIP_KERNEL don't go together either.
> Think about it...
>
> This is why I regard those who want multiplatform to work with options
> such as XIP_KERNEL and NOMMU to be insane.
>
> Please, can we stop trying to make multiplatform also cover the situations
> where only a single class of platforms works (iow, the old way we used to
> deal with platforms is the most sensible solution.)
>
> IMHO multiplatform was done right for multiplatform but at the expense of
> totally breaking stuff like XIP and noMMU. We need to stop trying to
> bend multiplatform to cover XIP and noMMU, but instead restore the old
> way of handling this _along_ with multiplatform as an additional option.
The problem is that "multiplatform" may mean one of two things:
1. Build a single kernel that can run on multiple platforms.
This is tricky when enabling XIP and/or NOMMU, as the physical parameters
must be compatible with all platforms. But building a kernel with the
right parameters is the responsibility of the user.
I.e. don't shoot yourself in the foot.
2. Your platform uses the arch/arm multiplatform framework.
As everything is being migrated to 2, not allowing XIP and/or NOMMU on
"multiplatform" is IMHO an insane limitation.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
On Wed, Feb 08, 2017 at 12:22:09PM -0500, Chris Brandt wrote: > Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even > though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT > is still forcibly selected. The result is that PHYS_OFFSET depends on > !ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address > for an XIP kernel and you cannot build. > > Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and > XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT), > adding this condition to ARCH_MULTIPLATFORM is logical and will fix this > build issue. And, ergo, multiplatform kernels and XIP_KERNEL don't go together either. Think about it... This is why I regard those who want multiplatform to work with options such as XIP_KERNEL and NOMMU to be insane. Please, can we stop trying to make multiplatform also cover the situations where only a single class of platforms works (iow, the old way we used to deal with platforms is the most sensible solution.) IMHO multiplatform was done right for multiplatform but at the expense of totally breaking stuff like XIP and noMMU. We need to stop trying to bend multiplatform to cover XIP and noMMU, but instead restore the old way of handling this _along_ with multiplatform as an additional option. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] serial: sh-sci: fix hardware RX trigger level setting
1. Do not set the RX trigger level for software timeout devices on reset;
there is no timeout by default, and data will rot.
2. Do set the RX trigger level for hardware timeout devices when set
via sysfs attribute.
Fixes SCIFA-type serial consoles.
Signed-off-by: Ulrich Hecht
Tested-by: Geert Uytterhoeven
---
drivers/tty/serial/sh-sci.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index f95a56c..9a47cc4 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1076,8 +1076,11 @@ static ssize_t rx_trigger_store(struct device *dev,
if (kstrtol(buf, 0, &r) == -EINVAL)
return -EINVAL;
+
sci->rx_trigger = scif_set_rtrg(port, r);
- scif_set_rtrg(port, 1);
+ if (port->type == PORT_SCIFA || port->type == PORT_SCIFB)
+ scif_set_rtrg(port, 1);
+
return count;
}
@@ -2179,7 +2182,11 @@ static void sci_reset(struct uart_port *port)
setup_timer(&s->rx_fifo_timer, rx_fifo_timer_fn,
(unsigned long)s);
} else {
- scif_set_rtrg(port, s->rx_trigger);
+ if (port->type == PORT_SCIFA ||
+ port->type == PORT_SCIFB)
+ scif_set_rtrg(port, 1);
+ else
+ scif_set_rtrg(port, s->rx_trigger);
}
}
}
--
2.7.4
[PATCH] ARM: xip: disable PATCH_PHYS_VIRT for ARCH_MULTIPLATFORM when XIP
Since ARCH_MULTIPLATFORM explicitly selects ARM_PATCH_PHYS_VIRT, even though ARCH_MULTIPLATFORM has 'depends on !XIP_KERNEL', ARM_PATCH_PHYS_VIRT is still forcibly selected. The result is that PHYS_OFFSET depends on !ARM_PATCH_PHYS_VIRT. This means you cannot enter a physical RAM address for an XIP kernel and you cannot build. Given that it is already clear in the Kconfig that ARM_PATCH_PHYS_VIRT and XIP_KERNEL do not go well together (read the help for ARM_PATCH_PHYS_VIRT), adding this condition to ARCH_MULTIPLATFORM is logical and will fix this build issue. Signed-off-by: Chris Brandt --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index bf8d86d..c97bd2c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -330,7 +330,7 @@ config ARCH_MULTIPLATFORM bool "Allow multiple platforms to be selected" depends on MMU select ARM_HAS_SG_CHAIN - select ARM_PATCH_PHYS_VIRT + select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL select AUTO_ZRELADDR select CLKSRC_OF select COMMON_CLK -- 2.10.1
Re: How to resolve "Waited 2000ms for CONNECT" in system resuming?
On Wed, 8 Feb 2017, Yoshihiro Shimoda wrote:
> Hi,
>
> In my environment, it causes the following message during system resume if
> debug messages are enabled:
>
> usb 2-1: Waited 2000ms for CONNECT
This message indicates that the port was connected to a device when the
system suspended, but when the system resumed the port was not
connected. (Or the device did not properly enable its terminating
resistors, or some other problem of the same general sort.)
> < My environment >
> - EHCI/OHCI controllers on R-Car H3
> (arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts)
> - Greg's usb.git / next branch (c95a9f83711bf53faeb4ed9bbb63a3f065613dfb) +
> some dts patches for R-Car H3
> - A USB 1.1 (full speed) device (A USB1.1 hub is easy to reproduce)
>
> < Details >
> - I investigated this issue and I found the issue is related the workqueue of
> drivers/usb/core/hub.c.
> If I modified the flags from WQ_FREEZABLE to "0", the issue disappeared.
>
> /*
>* The workqueue needs to be freezable to avoid interfering with
>* USB-PERSIST port handover. Otherwise it might see that a full-speed
>* device was gone before the EHCI controller had handed its port
>* over to the companion full-speed controller.
>*/
> hub_wq = alloc_workqueue("usb_hub_wq", WQ_FREEZABLE, 0);
That workqueue _must_ be freezable, as explained in the comment.
> - IIUC, an EHCI connects a full speed device first. After bus reset, an OHCI
> can connect the device.
> However, if WQ_FREEZABLE is set, the hub driver cannot issue bus reset
> while system resuming,
That's not true at all. The port _does_ get reset, by
ehci_handover_companion_ports() in drivers/usb/host/ehci-hub.c. This
code runs as part of the hub driver's resume routine, not in the hub_wq
workqueue.
> and then the issue happened.
>
> - I also found another option about "persist" feature on sysfs. If a USB1.1
> device (exclude a hub) is connected,
> we can disable the feature via sysfs and then the issue also disappeared.
>
> < Question >
> How to resolve the issue?
> - Can we modified the flags of the hub's workqueue?
Definitely not.
> - Should we disable the persist feature if we need to avoid the wait in
> system resume?
You can disable it if you want, but you probably won't like the
results. (See what happens if you suspend the system while a flash
drive is plugged into your USB-1.1 hub and is mounted.)
> - Or, other ideas?
Do some additional debugging and figure out why
ehci_handover_companion_ports() isn't working properly on your system.
Alan Stern
[PATCH 5/5] tests: Add RPF cropping test
From: Kieran Bingham
Test both the input cropping size and position
Signed-off-by: Kieran Bingham
---
tests/vsp-unit-test-0021.sh | 39 ++-
1 file changed, 39 insertions(+)
create mode 100755 tests/vsp-unit-test-0021.sh
diff --git a/tests/vsp-unit-test-0021.sh b/tests/vsp-unit-test-0021.sh
new file mode 100755
index ..d00dd0dece97
--- /dev/null
+++ b/tests/vsp-unit-test-0021.sh
@@ -0,0 +1,39 @@
+#!/bin/sh
+
+#
+# Test RPF crop in RGB and YUV mode. Use a RPF -> WPF pipeline with a fixed
ARGB32
+# format on the input and capture output frames in all RGB formats supported
+# by the WPF.
+#
+
+source vsp-lib.sh
+
+features="rpf.0 wpf.0"
+crops="(0,0)/512x384 (32,32)/512x384 (32,64)/512x384 (64,32)/512x384"
+
+
+test_rpf_cropping() {
+ test_start "RPF crop from $crop"
+
+ pipe_configure rpf-wpf 0 0
+ format_configure crop-rpf-wpf 0 0 RGB24 1024x768 ARGB32 $crop
+
+ vsp_runner rpf.0 &
+ vsp_runner wpf.0
+
+ local result=$(compare_frames crop=${crop})
+
+ test_complete $result
+}
+
+test_main() {
+ local format
+ local crop
+
+ for crop in $crops ; do
+ test_rpf_cropping $crop
+ done
+}
+
+test_init $0 "$features"
+test_run
--
git-series 0.9.1
[PATCH 0/5] vsp-tests: Implement RPF cropping tests
From: Kieran Bingham Update the gen-image utility such that it can crop the image at input, and provide tests to ensure that the output of the RPF is as we expect. The first patch in the series, reformats the output filenames such that frames, and the correct reference frame are in the correct sort order in the filesystem. This helps with comparing the output in case of errors Kieran Bingham (5): vsp-lib: sort output frames correctly vsp-lib: Filter non-filesystem regular characters gen-image: Implement option to parse an input crop vsp-lib: Support RPF frame cropping tests: Add RPF cropping test scripts/vsp-lib.sh | 44 ++- src/gen-image.c | 106 +- tests/vsp-unit-test-0021.sh | 39 ++- 3 files changed, 187 insertions(+), 2 deletions(-) create mode 100755 tests/vsp-unit-test-0021.sh base-commit: 067d210716b282f7e5ecede5a33c7f7fdabd1358 -- git-series 0.9.1
[PATCH 4/5] vsp-lib: Support RPF frame cropping
From: Kieran Bingham
Pass the optional '--crop (X,Y)/WxH' parameter through reference_frame
allowing the input to be cropped for comparison
Signed-off-by: Kieran Bingham
---
scripts/vsp-lib.sh | 37 +
1 file changed, 37 insertions(+)
diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
index 08bf8f36c582..42a4bb20d1be 100755
--- a/scripts/vsp-lib.sh
+++ b/scripts/vsp-lib.sh
@@ -162,6 +162,9 @@ reference_frame() {
vflip)
[ x$value = x1 ] && options="$options --vflip"
;;
+ crop)
+ options="$options --crop $value"
+ ;;
esac
done
@@ -717,6 +720,40 @@ format_rpf_wpf() {
__vsp_wpf_format=$5
}
+format_crop_rpf_wpf() {
+ local rpf=$1
+ local wpf=$2
+ local infmt=$(format_v4l2_to_mbus $3)
+ local size=$4
+ local outfmt=$(format_v4l2_to_mbus $5)
+ local rpfcrop=$6
+ local wpfcrop=$7
+ local rpfoutsize=
+ local outsize=
+
+ if [ x$rpfcrop != 'x' ] ; then
+ rpfcrop="crop:$rpfcrop"
+ rpfoutsize=$(echo $rpfcrop | sed 's/.*\///')
+ else
+ rpfoutsize=$size
+ fi
+
+ if [ x$wpfcrop != 'x' ] ; then
+ wpfcrop="crop:$wpfcrop"
+ outsize=$(echo $wpfcrop | sed 's/.*\///')
+ else
+ outsize=$rpfoutsize
+ fi
+
+ $mediactl -d $mdev -V "'$dev rpf.$rpf':0 [fmt:$infmt/$size $rpfcrop]"
+ $mediactl -d $mdev -V "'$dev rpf.$rpf':1 [fmt:$infmt/$rpfoutsize]"
+ $mediactl -d $mdev -V "'$dev wpf.$wpf':0 [fmt:$infmt/$rpfoutsize
$wpfcrop]"
+ $mediactl -d $mdev -V "'$dev wpf.$wpf':1 [fmt:$outfmt/$outsize]"
+
+ __vsp_rpf_format=$3
+ __vsp_wpf_format=$5
+}
+
format_wpf() {
local format=$(format_v4l2_to_mbus $1)
local size=$2
--
git-series 0.9.1
[PATCH 2/5] vsp-lib: Filter non-filesystem regular characters
From: Kieran Bingham
Parameters can contain characters not suited to use in filenames.
Add '=','(', and ')' to the filtering, and replace with '_'
Signed-off-by: Kieran Bingham
---
scripts/vsp-lib.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
index 5aff30217a27..08bf8f36c582 100755
--- a/scripts/vsp-lib.sh
+++ b/scripts/vsp-lib.sh
@@ -263,6 +263,9 @@ compare_frames() {
local params=${args// /-}
params=${params:+-$params}
params=${params//\//_}
+ params=${params/=/_}
+ params=${params/(/_}
+ params=${params/)/_}
params=$in_fmt-$out_fmt-$size$params
if [ x$__vsp_pixel_perfect != xtrue ] ; then
--
git-series 0.9.1
[PATCH 3/5] gen-image: Implement option to parse an input crop
From: Kieran Bingham
Allow the user to specify an input crop in the form (X,Y)/WxH
Signed-off-by: Kieran Bingham
---
src/gen-image.c | 106 +-
1 file changed, 106 insertions(+)
diff --git a/src/gen-image.c b/src/gen-image.c
index 9aabefa8389c..2f370e7a8ebd 100644
--- a/src/gen-image.c
+++ b/src/gen-image.c
@@ -97,6 +97,13 @@ struct format_info {
struct format_yuv_info yuv;
};
+struct image_rect {
+ int left;
+ int top;
+ unsigned int width;
+ unsigned int height;
+};
+
struct image {
const struct format_info *format;
unsigned int width;
@@ -136,6 +143,8 @@ struct options {
struct params params;
enum histogram_type histo_type;
uint8_t histo_areas[12];
+ bool crop;
+ struct image_rect inputcrop;
};
/*
-
@@ -1085,6 +1094,26 @@ static void image_flip(const struct image *input, struct
image *output,
}
/*
-
+ * Image Cropping
+ */
+
+static void image_crop(const struct image *input, const struct image *output,
+ const struct image_rect *crop)
+{
+ const uint8_t *idata = input->data;
+ uint8_t *odata = output->data;
+ unsigned int y;
+
+ for (y = 0; y < output->height; ++y) {
+ unsigned int offset = (crop->top * input->width + crop->left) *
3;
+
+ memcpy(odata + y * output->width * 3,
+ idata + y * input->width * 3 + offset,
+ output->width * 3);
+ }
+}
+
+/*
-
* Look Up Table
*/
@@ -1539,6 +1568,22 @@ static int process(const struct options *options)
input = rgb;
}
+ if (options->crop) {
+ struct image *cropped;
+
+ cropped = image_new(input->format, options->inputcrop.width,
+ options->inputcrop.height);
+
+ if (!cropped) {
+ ret = -ENOMEM;
+ goto done;
+ }
+
+ image_crop(input, cropped, &options->inputcrop);
+ image_delete(input);
+ input = cropped;
+ }
+
/* Scale */
if (options->output_width && options->output_height) {
output_width = options->output_width;
@@ -1773,6 +1818,7 @@ static void usage(const char *argv0)
printf("or percentages ([0%% - 100%%]).
Defaults to 1.0\n");
printf("-c, --compose n Compose n copies of the image
offset by (50,50) over a black background\n");
printf("-C, --no-chroma-average Disable chroma averaging for
odd pixels on output\n");
+ printf("--crop (X,Y)/WxHCrop the input image\n");
printf("-e, --encoding enc Set the YCbCr encoding method.
Valid values are\n");
printf("BT.601, REC.709, BT.2020 and
SMPTE240M\n");
printf("-f, --format format Set the output image format\n");
@@ -1813,11 +1859,13 @@ static void list_formats(void)
#define OPT_VFLIP 257
#define OPT_HISTOGRAM_TYPE 258
#define OPT_HISTOGRAM_AREAS259
+#define OPT_CROP 260
static struct option opts[] = {
{"alpha", 1, 0, 'a'},
{"clu", 1, 0, 'L'},
{"compose", 1, 0, 'c'},
+ {"crop", 1, 0, OPT_CROP},
{"encoding", 1, 0, 'e'},
{"format", 1, 0, 'f'},
{"help", 0, 0, 'h'},
@@ -1836,6 +1884,58 @@ static struct option opts[] = {
{0, 0, 0, 0}
};
+static int parse_crop(struct options *options, char *optarg)
+{
+ char * endptr;
+
+ /* (X,Y)/WxH */
+ endptr = optarg;
+ if (*endptr != '(') {
+ printf("Invalid crop argument '%s', expected '(', got '%c'\n",
optarg, *endptr);
+ return 1;
+ }
+
+ options->inputcrop.left = strtol(endptr + 1, &endptr, 10);
+ if (*endptr != ',' || endptr == optarg) {
+ printf("Invalid crop position '%s', expected ',', got '%c'\n",
optarg, *endptr);
+ return 1;
+ }
+
+ options->inputcrop.top = strtol(endptr + 1, &endptr, 10);
+ if (*endptr != ')' || endptr == optarg) {
+ printf("Invalid crop position '%s', expected ')', got '%c'\n",
optarg, *endptr);
+ return 1;
+ }
+
+ if (*endptr != ')') {
+ printf("Invalid crop argument '%s', expected x, got '%c'\n",
optarg, *endptr);
+ return 1;
+ }
+
+ endptr++;
+
+ options->inputcrop.width = strtol(endptr + 1, &endptr, 10);
+ if (*endptr != 'x' || endptr == optarg) {
+ printf("Invalid crop size '%s', expected x, got '%c'\n",
op
[PATCH 1/5] vsp-lib: sort output frames correctly
From: Kieran Bingham
In the event of failed frames, or VSP_KEEP_FRAMES being set, the output
file names do not sort such that the reference frame is next to the
failed frame.
This can make comparing reference frames and the relevant output frames
tedious and difficult.
Re-arrange the output filenames such that the sort order will match the
option parameters correctly, followed by either the reference frame
identifier, or the frame number at the end of the filename string
Signed-off-by: Kieran Bingham
---
scripts/vsp-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
index 1a356ec02374..5aff30217a27 100755
--- a/scripts/vsp-lib.sh
+++ b/scripts/vsp-lib.sh
@@ -278,12 +278,12 @@ compare_frames() {
}
if [ $match = "false" -o x$VSP_KEEP_FRAMES = x1 ] ; then
- mv $frame ${0/.sh/}-$(basename
${frame/.bin/-$params.bin})
+ mv $frame ${0/.sh/}-$params-$(basename ${frame})
fi
done
if [ x$VSP_KEEP_FRAMES = x1 -o $result = "fail" ] ; then
- mv ${frames_dir}ref-frame.bin ${0/.sh/}-ref-frame-$params.bin
+ mv ${frames_dir}ref-frame.bin ${0/.sh/}-$params-ref-frame.bin
else
rm -f ${frames_dir}ref-frame.bin
rm -f ${frames_dir}frame-*.bin
--
git-series 0.9.1
Re: [PATCH v4 4/4] arm64: dts: r8a7796: salvator-x: add SCIF1 (DEBUG1)
On Wed, Feb 8, 2017 at 11:54 AM, Simon Horman wrote: > On Fri, Feb 03, 2017 at 11:38:20AM +0100, Ulrich Hecht wrote: >> Enables the SCIF hooked up to the DEBUG1 connector. >> >> Signed-off-by: Ulrich Hecht >> Reviewed-by: Geert Uytterhoeven > > Hi Ulrich, > > could you clarify the dependency of this patch on earlier ones in the > series. Is it safe to queue this up independently of the other patches? It does not actually depend on the other patches. I think I included it here because I used that port for testing. Should be safe. CU Uli
Re: [PATCH v4 4/4] arm64: dts: r8a7796: salvator-x: add SCIF1 (DEBUG1)
On Fri, Feb 03, 2017 at 11:38:20AM +0100, Ulrich Hecht wrote: > Enables the SCIF hooked up to the DEBUG1 connector. > > Signed-off-by: Ulrich Hecht > Reviewed-by: Geert Uytterhoeven Hi Ulrich, could you clarify the dependency of this patch on earlier ones in the series. Is it safe to queue this up independently of the other patches?
Re: [PATCH v4 3/4] serial: sh-sci: make RX FIFO parameters tunable via sysfs
Hi Uli,
On Wed, Feb 8, 2017 at 11:04 AM, Ulrich Hecht
wrote:
> On Tue, Feb 7, 2017 at 3:40 PM, Geert Uytterhoeven
> wrote:
>> On Fri, Feb 3, 2017 at 11:38 AM, Ulrich Hecht
>> wrote:
>>> Allows tuning of the RX FIFO fill threshold and timeout. (The latter is
>>> only applicable to SCIFA and SCIFB).
>>>
>>> Signed-off-by: Ulrich Hecht
>>> Reviewed-by: Geert Uytterhoeven
>>> ---
>>> drivers/tty/serial/sh-sci.c | 87
>>> +
>>> 1 file changed, 87 insertions(+)
>>>
>>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>>> index 4a165ed..f95a56c 100644
>>> --- a/drivers/tty/serial/sh-sci.c
>>> +++ b/drivers/tty/serial/sh-sci.c
>>> @@ -1055,6 +1055,66 @@ static void rx_fifo_timer_fn(unsigned long arg)
>>> scif_set_rtrg(port, 1);
>>> }
>>>
>>> +static ssize_t rx_trigger_show(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + struct uart_port *port = dev_get_drvdata(dev);
>>> + struct sci_port *sci = to_sci_port(port);
>>> +
>>> + return sprintf(buf, "%d\n", sci->rx_trigger);
>>> +}
>>> +
>>> +static ssize_t rx_trigger_store(struct device *dev,
>>> + struct device_attribute *attr,
>>> + const char *buf,
>>> + size_t count)
>>> +{
>>> + struct uart_port *port = dev_get_drvdata(dev);
>>> + struct sci_port *sci = to_sci_port(port);
>>> + long r;
>>> +
>>> + if (kstrtol(buf, 0, &r) == -EINVAL)
>>> + return -EINVAL;
>>> + sci->rx_trigger = scif_set_rtrg(port, r);
>>> + scif_set_rtrg(port, 1);
>>
>> I seem to have missed the above function call during my earlier review.
>> What's the purpose of resetting the trigger immediately to 1?
>
> For the software timeout case, the timeout and the trigger levels are
> set in the interrupt handler. Setting the threshold to 1 will trigger
> that when the next byte of data comes in, and it is easier than
> duplicating the logic here.
OK.
> (There actually is a bug here, in that the threshold should only be
> reset to 1 for software timeout IPs (SCIFA and SCIFB), but that is not
> what breaks SCIFA, of course.)
I guess you'll send a patch to fix that, too?
>> I.e. "echo 1 > /sys/class/tty/ttySC0/device/rx_fifo_trigger" fixes serial
>> console input on e.g. armadillo, but echoing 32 into rx_fifo_trigger doesn't
>> break it again.
>
> This is intended to work that way. For software timeout devices (SCIFA
> and SCIFB), the trigger level is not set in hardware unless an
> rx_fifo_timeout > 0 is set as well.
>
> The bug that breaks the SCIFA console is in sci_reset(), which sets a
> hardware threshold > 1 for devices for software timeout devices even
> though the rx_fifo_timeout is 0. Something like this should fix it:
>
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2179,7 +2179,11 @@ static void sci_reset(struct uart_port *port)
> setup_timer(&s->rx_fifo_timer, rx_fifo_timer_fn,
> (unsigned long)s);
> } else {
> - scif_set_rtrg(port, s->rx_trigger);
> + if (port->type == PORT_SCIFA ||
> + port->type == PORT_SCIFB)
> + scif_set_rtrg(port, 1);
> + else
> + scif_set_rtrg(port, s->rx_trigger);
> }
> }
> }
>
> Could you try and check if that works for you?
Thanks, that unbroke serial console input on all my boards with SCIFA consoles.
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 3/4] serial: sh-sci: make RX FIFO parameters tunable via sysfs
On Tue, Feb 7, 2017 at 3:40 PM, Geert Uytterhoeven wrote:
> Hi Ulrich,
>
> On Fri, Feb 3, 2017 at 11:38 AM, Ulrich Hecht
> wrote:
>> Allows tuning of the RX FIFO fill threshold and timeout. (The latter is
>> only applicable to SCIFA and SCIFB).
>>
>> Signed-off-by: Ulrich Hecht
>> Reviewed-by: Geert Uytterhoeven
>> ---
>> drivers/tty/serial/sh-sci.c | 87
>> +
>> 1 file changed, 87 insertions(+)
>>
>> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
>> index 4a165ed..f95a56c 100644
>> --- a/drivers/tty/serial/sh-sci.c
>> +++ b/drivers/tty/serial/sh-sci.c
>> @@ -1055,6 +1055,66 @@ static void rx_fifo_timer_fn(unsigned long arg)
>> scif_set_rtrg(port, 1);
>> }
>>
>> +static ssize_t rx_trigger_show(struct device *dev,
>> + struct device_attribute *attr,
>> + char *buf)
>> +{
>> + struct uart_port *port = dev_get_drvdata(dev);
>> + struct sci_port *sci = to_sci_port(port);
>> +
>> + return sprintf(buf, "%d\n", sci->rx_trigger);
>> +}
>> +
>> +static ssize_t rx_trigger_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t count)
>> +{
>> + struct uart_port *port = dev_get_drvdata(dev);
>> + struct sci_port *sci = to_sci_port(port);
>> + long r;
>> +
>> + if (kstrtol(buf, 0, &r) == -EINVAL)
>> + return -EINVAL;
>> + sci->rx_trigger = scif_set_rtrg(port, r);
>> + scif_set_rtrg(port, 1);
>
> I seem to have missed the above function call during my earlier review.
> What's the purpose of resetting the trigger immediately to 1?
For the software timeout case, the timeout and the trigger levels are
set in the interrupt handler. Setting the threshold to 1 will trigger
that when the next byte of data comes in, and it is easier than
duplicating the logic here.
(There actually is a bug here, in that the threshold should only be
reset to 1 for software timeout IPs (SCIFA and SCIFB), but that is not
what breaks SCIFA, of course.)
> I.e. "echo 1 > /sys/class/tty/ttySC0/device/rx_fifo_trigger" fixes serial
> console input on e.g. armadillo, but echoing 32 into rx_fifo_trigger doesn't
> break it again.
This is intended to work that way. For software timeout devices (SCIFA
and SCIFB), the trigger level is not set in hardware unless an
rx_fifo_timeout > 0 is set as well.
The bug that breaks the SCIFA console is in sci_reset(), which sets a
hardware threshold > 1 for devices for software timeout devices even
though the rx_fifo_timeout is 0. Something like this should fix it:
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2179,7 +2179,11 @@ static void sci_reset(struct uart_port *port)
setup_timer(&s->rx_fifo_timer, rx_fifo_timer_fn,
(unsigned long)s);
} else {
- scif_set_rtrg(port, s->rx_trigger);
+ if (port->type == PORT_SCIFA ||
+ port->type == PORT_SCIFB)
+ scif_set_rtrg(port, 1);
+ else
+ scif_set_rtrg(port, s->rx_trigger);
}
}
}
Could you try and check if that works for you?
CU
Uli
Re: [PATCH] spi: rspi: fix the bug related to mount/remount jffs2
Hi Dong,
On Tue, Feb 7, 2017 at 11:25 AM, DongCV wrote:
>>> diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
>>> index 9daf500..2ee1301 100644
>>> --- a/drivers/spi/spi-rspi.c
>>> +++ b/drivers/spi/spi-rspi.c
>>> @@ -848,7 +848,6 @@ static int qspi_transfer_in(struct rspi_data *rspi,
>>> struct spi_transfer *xfer)
>>>ret = rspi_pio_transfer(rspi, NULL, rx, n);
>>>if (ret < 0)
>>>return ret;
>>> - *rx++ = ret;
>>
>> Storing the success code (0) in the receive buffer is indeed wrong.
>>
>> However, there are other bugs in that code:
>>
>> rspi_pio_transfer(rspi, NULL, rx, n) transfers n bytes instead of len,
>> while n is decreased by len (which is <= n).
>> Furthermore rx is not incremented.
>> Hence if len < n, n will still be non-zero, and a new iteration of the
>> loop will be started, trying to receive more data, and overwriting the
>> just filled buffer.
>>
>> The same bug is present in qspi_transfer_out().
>>
>>>}
>>>n -= len;
>>>}
>>> --
>>> 1.9.1
>>>
> (nip)
>>
>> Apart from sending patches inline, my comments from
>> https://www.spinics.net/lists/linux-spi/msg09753.html are still valid.
>
>
> Sorry I might not understand your explanation correctly. Could you please
> explain it more details?
> (Because I've tried to understand your explanation then analyzed the source
> code again as below:
> https://patchwork.kernel.org/patch/9541629/)
qspi_transfer_in() does:
while (n > 0) {
len = qspi_set_receive_trigger(rspi, n);
// len will be <= n
if (len == QSPI_BUFFER_SIZE) {
// receive blocks of len bytes
...
} else {
// receive n (not len) bytes
ret = rspi_pio_transfer(rspi, NULL, rx, n);
//
if (ret < 0)
return ret;
// bogus write (which your patch removes: OK)
*rx++ = ret;
// here we should also return (see below why)
// (in qspi_transfer_out() we should "break")
}
// Either we received a block of len bytes
// or we received n bytes, and the below is wrong if len < n!
n -= len;
// If len was < n, n will be non-zero, and we will receive more
// bytes in the next iteration
}
return 0;
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
