From: Vladimir Murzin <hidden> Date: 2016-02-16 10:08:52
This adds documentation of device tree bindings for the
timers found on ARM MPS2 platform.
Signed-off-by: Vladimir Murzin <redacted>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/timer/arm,mps2-timer.txt | 28 ++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
@@ -0,0 +1,28 @@+ARM MPS2 timer++The MPS2 platform has simple general-purpose 32 bits timers.++Required properties:+- compatible : Should be "arm,mps2-timer"+- reg : Address and length of the register set+- interrupts : Reference to the timer interrupt++Required clocking property, have to be one of:+- clocks : The input clock of the timer+- clock-frequency : The rate in HZ in input of the ARM MPS2 timer++Examples:++timer1: mps2-timer@40000000 {+ compatible = "arm,mps2-timer";+ reg = <0x40000000 0x1000>;+ interrupts = <8>;+ clocks = <&sysclk>;+};++timer2: mps2-timer@40001000 {+ compatible = "arm,mps2-timer";+ reg = <0x40001000 0x1000>;+ interrupts = <9>;+ clock-frequency = <25000000>;+};
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:08:55
This adds documentation of device tree bindings for the
UART found on ARM MPS2 platform
Signed-off-by: Vladimir Murzin <redacted>
Acked-by: Rob Herring <robh@kernel.org
---
.../devicetree/bindings/serial/arm,mps2-uart.txt | 22 ++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:09:06
The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7
It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/Kconfig | 8 ++++++++
arch/arm/Makefile | 1 +
arch/arm/mach-mps2/Makefile | 1 +
arch/arm/mach-mps2/Makefile.boot | 3 +++
arch/arm/mach-mps2/dtmachine.c | 21 +++++++++++++++++++++
5 files changed, 34 insertions(+)
create mode 100644 arch/arm/mach-mps2/Makefile
create mode 100644 arch/arm/mach-mps2/Makefile.boot
create mode 100644 arch/arm/mach-mps2/dtmachine.c
@@ -883,6 +883,14 @@ config ARCH_STM32helpSupportforSTMicroelectronicsSTM32processors.+configARCH_MPS2+bool"ARM MPS2 paltform"+depends onARM_SINGLE_ARMV7M+selectARM_AMBA+selectCLKSRC_MPS2+help+SupportforARMMPS2Cortex-Mplatform.+# Definitions to make life easierconfigARCH_ACORNbool
@@ -0,0 +1,112 @@+# CONFIG_USELIB is not set+CONFIG_NO_HZ_IDLE=y+CONFIG_HIGH_RES_TIMERS=y+CONFIG_LOG_BUF_SHIFT=16+CONFIG_CC_OPTIMIZE_FOR_SIZE=y+# CONFIG_UID16 is not set+# CONFIG_BASE_FULL is not set+# CONFIG_FUTEX is not set+# CONFIG_EPOLL is not set+# CONFIG_SIGNALFD is not set+# CONFIG_EVENTFD is not set+# CONFIG_AIO is not set+CONFIG_EMBEDDED=y+# CONFIG_VM_EVENT_COUNTERS is not set+# CONFIG_SLUB_DEBUG is not set+# CONFIG_BLOCK is not set+# CONFIG_MMU is not set+CONFIG_ARM_SINGLE_ARMV7M=y+CONFIG_ARCH_MPS2=y+CONFIG_SET_MEM_PARAM=y+CONFIG_DRAM_BASE=0x21000000+CONFIG_DRAM_SIZE=0x1000000+CONFIG_PREEMPT_VOLUNTARY=y+# CONFIG_ATAGS is not set+CONFIG_ZBOOT_ROM_TEXT=0x0+CONFIG_ZBOOT_ROM_BSS=0x0+CONFIG_BINFMT_FLAT=y+CONFIG_BINFMT_SHARED_FLAT=y+# CONFIG_COREDUMP is not set+# CONFIG_SUSPEND is not set+CONFIG_NET=y+CONFIG_PACKET=y+CONFIG_UNIX=y+CONFIG_INET=y+CONFIG_IP_PNP=y+CONFIG_IP_PNP_DHCP=y+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set+# CONFIG_INET_XFRM_MODE_TUNNEL is not set+# CONFIG_INET_XFRM_MODE_BEET is not set+# CONFIG_INET_LRO is not set+# CONFIG_INET_DIAG is not set+# CONFIG_IPV6 is not set+# CONFIG_WIRELESS is not set+CONFIG_DEVTMPFS=y+CONFIG_DEVTMPFS_MOUNT=y+# CONFIG_FW_LOADER is not set+CONFIG_NETDEVICES=y+# CONFIG_NET_CORE is not set+# CONFIG_NET_VENDOR_ARC is not set+# CONFIG_NET_CADENCE is not set+# CONFIG_NET_VENDOR_BROADCOM is not set+# CONFIG_NET_VENDOR_CIRRUS is not set+# CONFIG_NET_VENDOR_EZCHIP is not set+# CONFIG_NET_VENDOR_FARADAY is not set+# CONFIG_NET_VENDOR_HISILICON is not set+# CONFIG_NET_VENDOR_INTEL is not set+# CONFIG_NET_VENDOR_MARVELL is not set+# CONFIG_NET_VENDOR_MICREL is not set+# CONFIG_NET_VENDOR_NATSEMI is not set+# CONFIG_NET_VENDOR_QUALCOMM is not set+# CONFIG_NET_VENDOR_RENESAS is not set+# CONFIG_NET_VENDOR_ROCKER is not set+# CONFIG_NET_VENDOR_SAMSUNG is not set+# CONFIG_NET_VENDOR_SEEQ is not set+CONFIG_SMSC911X=y+# CONFIG_NET_VENDOR_STMICRO is not set+# CONFIG_NET_VENDOR_VIA is not set+# CONFIG_NET_VENDOR_WIZNET is not set+# CONFIG_WLAN is not set+# CONFIG_INPUT is not set+# CONFIG_SERIO is not set+# CONFIG_VT is not set+# CONFIG_LEGACY_PTYS is not set+CONFIG_SERIAL_NONSTANDARD=y+# CONFIG_DEVKMEM is not set+CONFIG_SERIAL_MPS2_UART_CONSOLE=y+CONFIG_SERIAL_MPS2_UART=y+# CONFIG_HW_RANDOM is not set+# CONFIG_HWMON is not set+CONFIG_WATCHDOG=y+CONFIG_ARM_SP805_WATCHDOG=y+CONFIG_MFD_SYSCON=y+# CONFIG_USB_SUPPORT is not set+CONFIG_NEW_LEDS=y+CONFIG_LEDS_CLASS=y+CONFIG_LEDS_SYSCON=y+CONFIG_LEDS_TRIGGERS=y+CONFIG_LEDS_TRIGGER_TIMER=y+CONFIG_LEDS_TRIGGER_ONESHOT=y+CONFIG_LEDS_TRIGGER_HEARTBEAT=y+CONFIG_LEDS_TRIGGER_BACKLIGHT=y+CONFIG_LEDS_TRIGGER_CPU=y+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y+CONFIG_ARM_TIMER_SP804=y+# CONFIG_DNOTIFY is not set+# CONFIG_INOTIFY_USER is not set+# CONFIG_MISC_FILESYSTEMS is not set+CONFIG_NFS_FS=y+CONFIG_NFS_V4=y+CONFIG_NFS_V4_1=y+CONFIG_NFS_V4_2=y+CONFIG_ROOT_NFS=y+CONFIG_NLS=y+CONFIG_PRINTK_TIME=y+CONFIG_DEBUG_INFO=y+# CONFIG_ENABLE_WARN_DEPRECATED is not set+# CONFIG_ENABLE_MUST_CHECK is not set+CONFIG_DEBUG_FS=y+CONFIG_MAGIC_SYSRQ=y+# CONFIG_SCHED_DEBUG is not set+# CONFIG_DEBUG_BUGVERBOSE is not set+CONFIG_MEMTEST=y
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:09:32
Application Notes 399 and 400 shares the same memory map and
features. Both are shipped with Cortex-M7 and have the same peripheral
as AN385/AN386, but with different location of PSRAM and Ethernet
controller.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/boot/dts/Makefile | 4 +-
arch/arm/boot/dts/mps2-an399.dts | 92 ++++++++++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mps2-an399.dts
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:11:07
Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/mps2-an385.dts | 90 +++++++++++++++
arch/arm/boot/dts/mps2.dtsi | 227 ++++++++++++++++++++++++++++++++++++++
3 files changed, 318 insertions(+)
create mode 100644 arch/arm/boot/dts/mps2-an385.dts
create mode 100644 arch/arm/boot/dts/mps2.dtsi
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:11:38
Add low-level debug support for MPS2, so that earlyprintk can be enabled
for debugging early boot issues.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/Kconfig.debug | 12 +++++++++++-
arch/arm/include/debug/mps2.S | 27 +++++++++++++++++++++++++++
2 files changed, 38 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/include/debug/mps2.S
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:12:32
This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000
Signed-off-by: Vladimir Murzin <redacted>
---
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/mps2-uart.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
From: Vladimir Murzin <hidden> Date: 2016-02-16 10:13:33
MPS2 platform has simple 32 bits general purpose countdown timers.
The driver uses the first detected timer as a clocksource and the rest
of the timers as a clockevent
Signed-off-by: Vladimir Murzin <redacted>
Acked-by: Daniel Lezcano <redacted>
---
drivers/clocksource/Kconfig | 6 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/mps2-timer.c | 275 ++++++++++++++++++++++++++++++++++++++
3 files changed, 282 insertions(+)
create mode 100644 drivers/clocksource/mps2-timer.c
@@ -0,0 +1,275 @@+/*+*Copyright(C)2015ARMLimited+*+*Author:VladimirMurzin<vladimir.murzin@arm.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2as+*publishedbytheFreeSoftwareFoundation.+*+*/++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt++#include<linux/clk.h>+#include<linux/clockchips.h>+#include<linux/clocksource.h>+#include<linux/err.h>+#include<linux/interrupt.h>+#include<linux/io.h>+#include<linux/irq.h>+#include<linux/of_address.h>+#include<linux/of.h>+#include<linux/of_irq.h>+#include<linux/sched_clock.h>+#include<linux/slab.h>++#define TIMER_CTRL 0x0+#define TIMER_CTRL_ENABLE BIT(0)+#define TIMER_CTRL_IE BIT(3)++#define TIMER_VALUE 0x4+#define TIMER_RELOAD 0x8+#define TIMER_INT 0xc++structclockevent_mps2{+void__iomem*reg;+u32clock_count_per_tick;+structclock_event_deviceclkevt;+};++staticvoid__iomem*sched_clock_base;++staticu64notracemps2_sched_read(void)+{+return~readl_relaxed(sched_clock_base+TIMER_VALUE);+}++staticinlinestructclockevent_mps2*to_mps2_clkevt(structclock_event_device*c)+{+returncontainer_of(c,structclockevent_mps2,clkevt);+}++staticvoidclockevent_mps2_writel(u32val,structclock_event_device*c,u32offset)+{+writel_relaxed(val,to_mps2_clkevt(c)->reg+offset);+}++staticintmps2_timer_shutdown(structclock_event_device*ce)+{+clockevent_mps2_writel(0,ce,TIMER_RELOAD);+clockevent_mps2_writel(0,ce,TIMER_CTRL);++return0;+}++staticintmps2_timer_set_next_event(unsignedlongnext,structclock_event_device*ce)+{+clockevent_mps2_writel(next,ce,TIMER_VALUE);+clockevent_mps2_writel(TIMER_CTRL_IE|TIMER_CTRL_ENABLE,ce,TIMER_CTRL);++return0;+}++staticintmps2_timer_set_periodic(structclock_event_device*ce)+{+u32clock_count_per_tick=to_mps2_clkevt(ce)->clock_count_per_tick;++clockevent_mps2_writel(clock_count_per_tick,ce,TIMER_RELOAD);+clockevent_mps2_writel(clock_count_per_tick,ce,TIMER_VALUE);+clockevent_mps2_writel(TIMER_CTRL_IE|TIMER_CTRL_ENABLE,ce,TIMER_CTRL);++return0;+}++staticirqreturn_tmps2_timer_interrupt(intirq,void*dev_id)+{+structclockevent_mps2*ce=dev_id;+u32status=readl_relaxed(ce->reg+TIMER_INT);++if(!status){+pr_warn("spurious interrupt\n");+returnIRQ_NONE;+}++writel_relaxed(1,ce->reg+TIMER_INT);++ce->clkevt.event_handler(&ce->clkevt);++returnIRQ_HANDLED;+}++staticint__initmps2_clockevent_init(structdevice_node*np)+{+void__iomem*base;+structclk*clk=NULL;+structclockevent_mps2*ce;+u32rate;+intirq,ret;+constchar*name="mps2-clkevt";++ret=of_property_read_u32(np,"clock-frequency",&rate);+if(ret){+clk=of_clk_get(np,0);+if(IS_ERR(clk)){+ret=PTR_ERR(clk);+pr_err("failed to get clock for clockevent: %d\n",ret);+gotoout;+}++ret=clk_prepare_enable(clk);+if(ret){+pr_err("failed to enable clock for clockevent: %d\n",ret);+gotoout_clk_put;+}++rate=clk_get_rate(clk);+}++base=of_iomap(np,0);+if(!base){+ret=-EADDRNOTAVAIL;+pr_err("failed to map register for clockevent: %d\n",ret);+gotoout_clk_disable;+}++irq=irq_of_parse_and_map(np,0);+if(!irq){+ret=-ENOENT;+pr_err("failed to get irq for clockevent: %d\n",ret);+gotoout_iounmap;+}++ce=kzalloc(sizeof(structclockevent_mps2),GFP_KERNEL);+if(!ce){+ret=-ENOMEM;+gotoout_iounmap;+}++ce->reg=base;+ce->clock_count_per_tick=DIV_ROUND_CLOSEST(rate,HZ);+ce->clkevt.irq=irq;+ce->clkevt.name=name;+ce->clkevt.rating=200;+ce->clkevt.features=CLOCK_EVT_FEAT_PERIODIC|CLOCK_EVT_FEAT_ONESHOT;+ce->clkevt.cpumask=cpu_possible_mask;+ce->clkevt.set_state_shutdown=mps2_timer_shutdown,+ce->clkevt.set_state_periodic=mps2_timer_set_periodic,+ce->clkevt.set_state_oneshot=mps2_timer_shutdown,+ce->clkevt.set_next_event=mps2_timer_set_next_event;++/* Ensure timer is disabled */+writel_relaxed(0,base+TIMER_CTRL);++ret=request_irq(irq,mps2_timer_interrupt,IRQF_TIMER,name,ce);+if(ret){+pr_err("failed to request irq for clockevent: %d\n",ret);+gotoout_kfree;+}++clockevents_config_and_register(&ce->clkevt,rate,0xf,0xffffffff);++return0;++out_kfree:+kfree(ce);+out_iounmap:+iounmap(base);+out_clk_disable:+/* clk_{disable, unprepare, put}() can handle NULL as a parameter */+clk_disable_unprepare(clk);+out_clk_put:+clk_put(clk);+out:+returnret;+}++staticint__initmps2_clocksource_init(structdevice_node*np)+{+void__iomem*base;+structclk*clk=NULL;+u32rate;+intret;+constchar*name="mps2-clksrc";++ret=of_property_read_u32(np,"clock-frequency",&rate);+if(ret){+clk=of_clk_get(np,0);+if(IS_ERR(clk)){+ret=PTR_ERR(clk);+pr_err("failed to get clock for clocksource: %d\n",ret);+gotoout;+}++ret=clk_prepare_enable(clk);+if(ret){+pr_err("failed to enable clock for clocksource: %d\n",ret);+gotoout_clk_put;+}++rate=clk_get_rate(clk);+}++base=of_iomap(np,0);+if(!base){+ret=-EADDRNOTAVAIL;+pr_err("failed to map register for clocksource: %d\n",ret);+gotoout_clk_disable;+}++/* Ensure timer is disabled */+writel_relaxed(0,base+TIMER_CTRL);++/* ... and set it up as free-running clocksource */+writel_relaxed(0xffffffff,base+TIMER_VALUE);+writel_relaxed(0xffffffff,base+TIMER_RELOAD);++writel_relaxed(TIMER_CTRL_ENABLE,base+TIMER_CTRL);++ret=clocksource_mmio_init(base+TIMER_VALUE,name,+rate,200,32,+clocksource_mmio_readl_down);+if(ret){+pr_err("failed to init clocksource: %d\n",ret);+gotoout_iounmap;+}++sched_clock_base=base;+sched_clock_register(mps2_sched_read,32,rate);++return0;++out_iounmap:+iounmap(base);+out_clk_disable:+/* clk_{disable, unprepare, put}() can handle NULL as a parameter */+clk_disable_unprepare(clk);+out_clk_put:+clk_put(clk);+out:+returnret;+}++staticvoid__initmps2_timer_init(structdevice_node*np)+{+staticinthas_clocksource,has_clockevent;+intret;++if(!has_clocksource){+ret=mps2_clocksource_init(np);+if(!ret){+has_clocksource=1;+return;+}+}++if(!has_clockevent){+ret=mps2_clockevent_init(np);+if(!ret){+has_clockevent=1;+return;+}+}+}++CLOCKSOURCE_OF_DECLARE(mps2_timer,"arm,mps2-timer",mps2_timer_init);
From: Andy Shevchenko <hidden> Date: 2016-02-16 10:48:20
On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
[off-list ref] wrote:
This driver adds support to the UART controller found on ARM MPS2
platform.
+static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
+{
+ irqreturn_t handled = IRQ_NONE;
+ struct uart_port *port = data;
+ u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+ spin_lock(&port->lock);
+
+ if (irqflag & UARTn_INT_RX_OVERRUN) {
+ struct tty_port *tport = &port->state->port;
+
+ mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
+ tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+ port->icount.overrun++;
+ handled = IRQ_HANDLED;
+ }
+
+ /*
+ * It's never been seen in practice and it never *should* happen since
+ * we check if there is enough room in TX buffer before sending data.
+ * So we keep this check in case something suspicious has happened.
+ */
+ if (irqflag & UARTn_INT_TX_OVERRUN) {
+ mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7
It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/Kconfig | 8 ++++++++
arch/arm/Makefile | 1 +
arch/arm/mach-mps2/Makefile | 1 +
arch/arm/mach-mps2/Makefile.boot | 3 +++
arch/arm/mach-mps2/dtmachine.c | 21 +++++++++++++++++++++
We are in the (slow) process of consolidating the ARM reference platforms
(versatile, integrator, realview, vexpress) into one place.
I'd suggest adding all this to the mach-vexpress directory rather than
a new directory, so we don't have another one to consolidate.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -0,0 +1,112 @@+# CONFIG_USELIB is not set+CONFIG_NO_HZ_IDLE=y+CONFIG_HIGH_RES_TIMERS=y+CONFIG_LOG_BUF_SHIFT=16+CONFIG_CC_OPTIMIZE_FOR_SIZE=y+# CONFIG_UID16 is not set+# CONFIG_BASE_FULL is not set+# CONFIG_FUTEX is not set+# CONFIG_EPOLL is not set+# CONFIG_SIGNALFD is not set+# CONFIG_EVENTFD is not set+# CONFIG_AIO is not set+CONFIG_EMBEDDED=y
Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
you need that for?
Arnd
This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.
Arnd
This should also set the baud bits back in the termios struct
accordingly.
if (tty_termios_baud_rate(new))
tty_termios_encode_baud_rate(new, baud, baud);
Not a big deal and could certainly be a follow up patch after it's merged.
Alan
On Tuesday 16 February 2016 10:08:05 Vladimir Murzin wrote:
Hi,
This patch series provide the basic support for running ucLinux on V2M-MPS2
platform.
With these patches applied ucLinux can be run on both HW and FVP models
with Cortex-M3/M4/M7 configurations.
Looks very nice overall now. I have mentioned a few details that I noticed
but no show-stoppers.
Most important question for me is how this is going to be maintained
in the long run. Can you add a patch to list the added files in
MAINTAINERS?
My preference from the arm-soc perspective would be to get pull requests for
this together with vexpress and juno through the existing maintainers
(Liviu, Sudeep, Lorenzo), and have you send your patches to them. Does
that work for you all?
Arnd
From: Andy Shevchenko <hidden> Date: 2016-02-16 13:13:55
On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
[off-list ref] wrote:
On 16/02/16 10:36, Andy Shevchenko wrote:
quoted
On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000
quoted
quoted
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+ while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+ cpu_relax();
Infinite busy loop?
In case of broken hw, yes, but I'm quite unsure how we can help to fix
it. Do you have something in mind?
Set sane amount of loops like
int count = 100;
…
while (… && --count)
Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.
You may try to recover by flushing TX queue in HW (fifo and / or Tx
shift register) if HW supports it.
--
With Best Regards,
Andy Shevchenko
From: Vladimir Murzin <hidden> Date: 2016-02-16 13:38:16
On 16/02/16 13:13, Andy Shevchenko wrote:
On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
On 16/02/16 10:36, Andy Shevchenko wrote:
quoted
On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000
quoted
quoted
quoted
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+ while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+ cpu_relax();
Infinite busy loop?
In case of broken hw, yes, but I'm quite unsure how we can help to fix
it. Do you have something in mind?
Set sane amount of loops like
int count = 100;
…
while (… && --count)
Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.
I thought about counter too, like some of drivers do, but had no idea
what to do next after counter reaches zero. In case of TX overrun we
could get it either because of broken hw or because we entered Linux
with that state already set. In both cases, it looks handy to me to
attach a debugger and see that we are spinning in this putchar loop.
If you do insist to have a counter I'll add one, but if you are not
strong about it I'd prefer to leave it as is.
You may try to recover by flushing TX queue in HW (fifo and / or Tx
shift register) if HW supports it.
From: Andy Shevchenko <hidden> Date: 2016-02-16 14:00:26
On Tue, Feb 16, 2016 at 3:38 PM, Vladimir Murzin
[off-list ref] wrote:
On 16/02/16 13:13, Andy Shevchenko wrote:
quoted
On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
On 16/02/16 10:36, Andy Shevchenko wrote:
quoted
On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
quoted
quoted
quoted
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+ while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+ cpu_relax();
Infinite busy loop?
In case of broken hw, yes, but I'm quite unsure how we can help to fix
it. Do you have something in mind?
Set sane amount of loops like
int count = 100;
…
while (… && --count)
Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.
I thought about counter too, like some of drivers do, but had no idea
what to do next after counter reaches zero. In case of TX overrun we
could get it either because of broken hw or because we entered Linux
with that state already set. In both cases, it looks handy to me to
attach a debugger and see that we are spinning in this putchar loop.
If you do insist to have a counter I'll add one, but if you are not
strong about it I'd prefer to leave it as is.
I would wait for Peter Hurley, Alan, or other experienced guys to talk.
quoted
You may try to recover by flushing TX queue in HW (fifo and / or Tx
shift register) if HW supports it.
I'm afraid this is not supported.
Maybe soft reset? Anyway, see above.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Vladimir Murzin <hidden> Date: 2016-02-16 14:25:54
On 16/02/16 10:48, Andy Shevchenko wrote:
On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
[off-list ref] wrote:
quoted
This driver adds support to the UART controller found on ARM MPS2
platform.
quoted
+static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
+{
+ irqreturn_t handled = IRQ_NONE;
+ struct uart_port *port = data;
+ u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+ spin_lock(&port->lock);
+
+ if (irqflag & UARTn_INT_RX_OVERRUN) {
+ struct tty_port *tport = &port->state->port;
+
+ mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
+ tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+ port->icount.overrun++;
+ handled = IRQ_HANDLED;
+ }
+
+ /*
+ * It's never been seen in practice and it never *should* happen since
+ * we check if there is enough room in TX buffer before sending data.
+ * So we keep this check in case something suspicious has happened.
+ */
+ if (irqflag & UARTn_INT_TX_OVERRUN) {
+ mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
From: Vladimir Murzin <hidden> Date: 2016-02-16 14:35:50
On 16/02/16 10:56, Arnd Bergmann wrote:
On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
quoted
The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7
It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/Kconfig | 8 ++++++++
arch/arm/Makefile | 1 +
arch/arm/mach-mps2/Makefile | 1 +
arch/arm/mach-mps2/Makefile.boot | 3 +++
arch/arm/mach-mps2/dtmachine.c | 21 +++++++++++++++++++++
We are in the (slow) process of consolidating the ARM reference platforms
(versatile, integrator, realview, vexpress) into one place.
Thanks for information! Sometime ago I saw on a list you had some
thoughts on consolidating M-class platforms since most of them follow
quite the same pattern (I'm looking at efm32 and stm32). So, shouldn't
this platform consider that way?
I'd suggest adding all this to the mach-vexpress directory rather than
a new directory, so we don't have another one to consolidate.
On Tuesday 16 February 2016 14:35:43 Vladimir Murzin wrote:
On 16/02/16 10:56, Arnd Bergmann wrote:
quoted
On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
quoted
The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7
It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.
Signed-off-by: Vladimir Murzin <redacted>
---
arch/arm/Kconfig | 8 ++++++++
arch/arm/Makefile | 1 +
arch/arm/mach-mps2/Makefile | 1 +
arch/arm/mach-mps2/Makefile.boot | 3 +++
arch/arm/mach-mps2/dtmachine.c | 21 +++++++++++++++++++++
We are in the (slow) process of consolidating the ARM reference platforms
(versatile, integrator, realview, vexpress) into one place.
Thanks for information! Sometime ago I saw on a list you had some
thoughts on consolidating M-class platforms since most of them follow
quite the same pattern (I'm looking at efm32 and stm32). So, shouldn't
this platform consider that way?
Right, that would be another option. vf610 is in the same category as this
one I think, it's currently in mach-imx, and we can probably leave it there.
Unless someone is going to do the patch to consolidate the cortex-m
platforms, I'd stay with mach-vexpress here, but I don't have a strong
opinion.
Arnd
@@ -0,0 +1,112 @@+# CONFIG_USELIB is not set+CONFIG_NO_HZ_IDLE=y+CONFIG_HIGH_RES_TIMERS=y+CONFIG_LOG_BUF_SHIFT=16+CONFIG_CC_OPTIMIZE_FOR_SIZE=y+# CONFIG_UID16 is not set+# CONFIG_BASE_FULL is not set+# CONFIG_FUTEX is not set+# CONFIG_EPOLL is not set+# CONFIG_SIGNALFD is not set+# CONFIG_EVENTFD is not set+# CONFIG_AIO is not set+CONFIG_EMBEDDED=y
Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
you need that for?
TBH, I have no special requirement for this option to be set and now,
looking at Kconfig entry for this option, I think that I got it here
because I stated configuration with allnoconfig.
OTOH, I don't see how harmful it can be since description says:
This option should be enabled if compiling the kernel for
an embedded system so certain expert options are available
for configuration
yes, it selects CONFIG_EXPERT and that had side effect that, for
example, CONFIG_NAMESPACE could be compiled out.
Have I missed something around it?
Thanks
Vladimir
On Tuesday 16 February 2016 14:51:59 Vladimir Murzin wrote:
quoted
Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
you need that for?
TBH, I have no special requirement for this option to be set and now,
looking at Kconfig entry for this option, I think that I got it here
because I stated configuration with allnoconfig.
OTOH, I don't see how harmful it can be since description says:
This option should be enabled if compiling the kernel for
an embedded system so certain expert options are available
for configuration
yes, it selects CONFIG_EXPERT and that had side effect that, for
example, CONFIG_NAMESPACE could be compiled out.
Have I missed something around it?
Just the history behind this symbol. We removed it a while ago in
favor if CONFIG_EXPERT, assuming that it makes it clearer that it's
not just for embedded systems, or for systems with small memory.
It's basically a zombie symbol that nobody should use directly
(independent of what the documentation says...).
Arnd
This should also set the baud bits back in the termios struct
accordingly.
if (tty_termios_baud_rate(new))
tty_termios_encode_baud_rate(new, baud, baud);
Not a big deal and could certainly be a follow up patch after it's merged.
From: Vladimir Murzin <hidden> Date: 2016-02-16 15:14:21
On 16/02/16 15:08, Arnd Bergmann wrote:
On Tuesday 16 February 2016 14:51:59 Vladimir Murzin wrote:
quoted
quoted
Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
you need that for?
TBH, I have no special requirement for this option to be set and now,
looking at Kconfig entry for this option, I think that I got it here
because I stated configuration with allnoconfig.
OTOH, I don't see how harmful it can be since description says:
This option should be enabled if compiling the kernel for
an embedded system so certain expert options are available
for configuration
yes, it selects CONFIG_EXPERT and that had side effect that, for
example, CONFIG_NAMESPACE could be compiled out.
Have I missed something around it?
Just the history behind this symbol. We removed it a while ago in
favor if CONFIG_EXPERT, assuming that it makes it clearer that it's
not just for embedded systems, or for systems with small memory.
It's basically a zombie symbol that nobody should use directly
(independent of what the documentation says...).
On Tue, Feb 16, 2016 at 11:08 AM, Vladimir Murzin
[off-list ref] wrote:
Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.
Signed-off-by: Vladimir Murzin <redacted>
Thanks for using this. I worked hard to massage this into the
core.
Reviewed-by: Linus Walleij <redacted>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Vladimir Murzin <hidden> Date: 2016-02-16 15:37:41
On 16/02/16 15:17, Linus Walleij wrote:
On Tue, Feb 16, 2016 at 11:08 AM, Vladimir Murzin
[off-list ref] wrote:
quoted
Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.
Signed-off-by: Vladimir Murzin <redacted>
This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.
I might messed it up since the MAC/PHY connects to the same 16-bit
interface as the 16MB PSRAM external memory and both connected via AHB.
Not sure how it should be expressed, so some help form DT camp would be
appreciated.
Cheers
Vladimir
From: Vladimir Murzin <hidden> Date: 2016-02-16 16:14:08
On 16/02/16 11:05, Arnd Bergmann wrote:
On Tuesday 16 February 2016 10:08:05 Vladimir Murzin wrote:
quoted
Hi,
This patch series provide the basic support for running ucLinux on V2M-MPS2
platform.
With these patches applied ucLinux can be run on both HW and FVP models
with Cortex-M3/M4/M7 configurations.
Looks very nice overall now. I have mentioned a few details that I noticed
but no show-stoppers.
Most important question for me is how this is going to be maintained
in the long run. Can you add a patch to list the added files in
MAINTAINERS?
My preference from the arm-soc perspective would be to get pull requests for
this together with vexpress and juno through the existing maintainers
(Liviu, Sudeep, Lorenzo), and have you send your patches to them. Does
that work for you all?
I'm quite happy with either way. I'm not targeting for 4.6, so we have
some time to sort it out.
Thanks
Vladimir
From: One Thousand Gnomes <hidden> Date: 2016-02-16 16:14:39
quoted
If you do insist to have a counter I'll add one, but if you are not
strong about it I'd prefer to leave it as is.
I would wait for Peter Hurley, Alan, or other experienced guys to talk.
I would leave it. Some of the drivers have defensive code of this form,
but mostly because they can be hot unplugged and we don't want to spin
into oblivion because the user ejected a serial card adapter.
Alan
This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.
I might messed it up since the MAC/PHY connects to the same 16-bit
interface as the 16MB PSRAM external memory and both connected via AHB.
Not sure how it should be expressed, so some help form DT camp would be
appreciated.
Arnd,
Does following fixup address your point on where/how ethernet node
should be placed?
This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.
I might messed it up since the MAC/PHY connects to the same 16-bit
interface as the 16MB PSRAM external memory and both connected via AHB.
Not sure how it should be expressed, so some help form DT camp would be
appreciated.
Does following fixup address your point on where/how ethernet node
should be placed?
How is the range being set here? The way I read this is:
"There is an external bus controller whose single CPU physical
address for MMIO is configurable. The chip always connects
a lan9220 device to it (as that is in the dtsi file) and
nothing else is possible, and the bootloader in this
version of the machine has configured the window to be
at address 0x40200000."
Is that what the hardware does?
I would have expected the opposite, with the external bus
interface being hardwired to one or more physical addresses
(more than one if you have multiple chip-selects), and
then allow to connect different devices, which are in the
.dts file, while the bus controller is defined in the
.dtsi file.
Arnd
This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.
I might messed it up since the MAC/PHY connects to the same 16-bit
interface as the 16MB PSRAM external memory and both connected via AHB.
Not sure how it should be expressed, so some help form DT camp would be
appreciated.
Does following fixup address your point on where/how ethernet node
should be placed?
How is the range being set here? The way I read this is:
"There is an external bus controller whose single CPU physical
address for MMIO is configurable. The chip always connects
a lan9220 device to it (as that is in the dtsi file) and
nothing else is possible, and the bootloader in this
version of the machine has configured the window to be
at address 0x40200000."
Is that what the hardware does?
I would have expected the opposite, with the external bus
interface being hardwired to one or more physical addresses
(more than one if you have multiple chip-selects), and
then allow to connect different devices, which are in the
.dts file, while the bus controller is defined in the
.dtsi file.
Right, I thought in a wrong way, in opposite it makes more sense now.
.dtsi
/* below the soc/ */
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x40200000 0x10000>,
<1 0 0xa0000000 0x10000>;
};
.dts
smb {
ethernet@0,0 {
compatible = "smsc,lan9220", "smsc,lan9115";
reg = <0 0x0 0x10000>;
interrupts = <13>;
interrupt-parent = <&nvic>;
smsc,irq-active-high;
};
and looking again at .dtsi it seems to me that fpgaio should be moved
below the soc/ under separate bus interface which would hosts audio and
spi too or I keep missing things around device-tree?
I appreciate your help on this, thanks!
Vladimir
On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
Right, I thought in a wrong way, in opposite it makes more sense now.
.dtsi
/* below the soc/ */
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x40200000 0x10000>,
<1 0 0xa0000000 0x10000>;
};
That looks good, yes.
Is 0x10000 the correct maximum addressable size of the external bus
in both cases?
Intuitively, I would guess that the 0xa0000000 range might
be much wider.
.dts
smb {
ethernet@0,0 {
compatible = "smsc,lan9220", "smsc,lan9115";
reg = <0 0x0 0x10000>;
interrupts = <13>;
interrupt-parent = <&nvic>;
smsc,irq-active-high;
};
and looking again at .dtsi it seems to me that fpgaio should be moved
below the soc/ under separate bus interface which would hosts audio and
spi too or I keep missing things around device-tree?
I don't see the audio and spi nodes, so I'm not sure where exactly
you would put them.
Ideally those things should be visible from a block diagram in the
datasheet.
Arnd
From: Vladimir Murzin <hidden> Date: 2016-02-18 11:13:14
On 18/02/16 10:45, Arnd Bergmann wrote:
On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
quoted
Right, I thought in a wrong way, in opposite it makes more sense now.
.dtsi
/* below the soc/ */
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x40200000 0x10000>,
<1 0 0xa0000000 0x10000>;
};
That looks good, yes.
Is 0x10000 the correct maximum addressable size of the external bus
in both cases?
Intuitively, I would guess that the 0xa0000000 range might
be much wider.
There is only Ethernet connected to this bus (apart from PSRAM), so it
might be wider, but there is no indication of this in documentation.
quoted
.dts
smb {
ethernet@0,0 {
compatible = "smsc,lan9220", "smsc,lan9115";
reg = <0 0x0 0x10000>;
interrupts = <13>;
interrupt-parent = <&nvic>;
smsc,irq-active-high;
};
and looking again at .dtsi it seems to me that fpgaio should be moved
below the soc/ under separate bus interface which would hosts audio and
spi too or I keep missing things around device-tree?
I don't see the audio and spi nodes, so I'm not sure where exactly
you would put them.
I just keep things simple ;)
Ideally those things should be visible from a block diagram in the
datasheet.
Indeed, block diagram indicates all them as a "FPGA APB subsystem" and
clearly draws a line indicating a bus those devices are connected to.
After your point about lan9220, it looks clearer to me to express that
subsystem outside of soc/ node indicating bus interface, so it would
match to those drawings closely.
Cheers
Vladimir
On Thursday 18 February 2016 11:13:06 Vladimir Murzin wrote:
On 18/02/16 10:45, Arnd Bergmann wrote:
quoted
On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
quoted
Right, I thought in a wrong way, in opposite it makes more sense now.
.dtsi
/* below the soc/ */
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x40200000 0x10000>,
<1 0 0xa0000000 0x10000>;
};
That looks good, yes.
Is 0x10000 the correct maximum addressable size of the external bus
in both cases?
Intuitively, I would guess that the 0xa0000000 range might
be much wider.
There is only Ethernet connected to this bus (apart from PSRAM), so it
might be wider, but there is no indication of this in documentation.
I see this called "ahb_to_extmem16" in the documentation, which indicates
that it might be use 16 bits of address space, which would match
the 64K you listed.
For SSRAM1 / SSRAM2 / SSRAM3, a 8 MB address space is mentioned
and 16 MB for external PSRAM at 0x21000000.
Arnd
From: Vladimir Murzin <hidden> Date: 2016-02-18 12:47:25
On 18/02/16 12:16, Arnd Bergmann wrote:
On Thursday 18 February 2016 11:13:06 Vladimir Murzin wrote:
quoted
On 18/02/16 10:45, Arnd Bergmann wrote:
quoted
On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
quoted
Right, I thought in a wrong way, in opposite it makes more sense now.
.dtsi
/* below the soc/ */
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x40200000 0x10000>,
<1 0 0xa0000000 0x10000>;
};
That looks good, yes.
Is 0x10000 the correct maximum addressable size of the external bus
in both cases?
Intuitively, I would guess that the 0xa0000000 range might
be much wider.
There is only Ethernet connected to this bus (apart from PSRAM), so it
might be wider, but there is no indication of this in documentation.
I see this called "ahb_to_extmem16" in the documentation, which indicates
that it might be use 16 bits of address space, which would match
the 64K you listed.
For SSRAM1 / SSRAM2 / SSRAM3, a 8 MB address space is mentioned
and 16 MB for external PSRAM at 0x21000000.
Right. I'll incorporate changes in the next version. Thanks for lessons
given and your time!
Cheers
Vladimir
IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
one is enough.
I've just tried with OF_ only and seems it works fine. Thanks for
pointing at it!
..and the reason for that was that I had stdout pointing at uart node.
Now, while testing v4 I end-up with configuration:
1) no EARLYCON_DECLARE in mps2-uart.c
2) stdout not set
3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
and I don't see bootconsole, but if I avoid 1) everything works fine.
So, I'd leave EARLYCON_DECLARE in this patch.
Cheers
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
one is enough.
I've just tried with OF_ only and seems it works fine. Thanks for
pointing at it!
..and the reason for that was that I had stdout pointing at uart node.
Now, while testing v4 I end-up with configuration:
1) no EARLYCON_DECLARE in mps2-uart.c
2) stdout not set
3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
and I don't see bootconsole, but if I avoid 1) everything works fine.
So, I'd leave EARLYCON_DECLARE in this patch.
Peter, what is your comment on this?
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
one is enough.
I've just tried with OF_ only and seems it works fine. Thanks for
pointing at it!
..and the reason for that was that I had stdout pointing at uart node.
Now, while testing v4 I end-up with configuration:
1) no EARLYCON_DECLARE in mps2-uart.c
2) stdout not set
3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
and I don't see bootconsole, but if I avoid 1) everything works fine.
So, I'd leave EARLYCON_DECLARE in this patch.
Peter, what is your comment on this?
That Vladimir is not testing with linux-next.
linux-next has common framework for both command line and OF-defined
earlycons.
Vladimir, if you pull in Greg's tty-next branch, then just
OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
should enable both command-line and OF-defined earlycons.
Regards,
Peter Hurley
IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
one is enough.
I've just tried with OF_ only and seems it works fine. Thanks for
pointing at it!
..and the reason for that was that I had stdout pointing at uart node.
Now, while testing v4 I end-up with configuration:
1) no EARLYCON_DECLARE in mps2-uart.c
2) stdout not set
3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
and I don't see bootconsole, but if I avoid 1) everything works fine.
So, I'd leave EARLYCON_DECLARE in this patch.
Peter, what is your comment on this?
That Vladimir is not testing with linux-next.
linux-next has common framework for both command line and OF-defined
earlycons.
Vladimir, if you pull in Greg's tty-next branch, then just
OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
should enable both command-line and OF-defined earlycons.
Confirmed! No doubt now EARLYCON_DECLARE can be dropped from this patch
safely.
Thanks!
Vladimir