* [PATCH V2 4/6] serial: use the new linux/sizes.h
From: Alessandro Rubini @ 2012-05-28 16:37 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <cover.1338222460.git.rubini@gnudd.com>
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Russell King <linux@arm.linux.org.uk>
---
drivers/tty/serial/amba-pl011.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 4ad721f..d394b93 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -53,9 +53,9 @@
#include <linux/delay.h>
#include <linux/types.h>
#include <linux/pinctrl/consumer.h>
+#include <linux/sizes.h>
#include <asm/io.h>
-#include <asm/sizes.h>
#define UART_NR 14
--
1.7.7.2
^ permalink raw reply related
* [PATCH V2 1/6] sizes.h: move from asm-generic to <linux/sizes.h>
From: Alessandro Rubini @ 2012-05-28 16:37 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <cover.1338222460.git.rubini@gnudd.com>
sizes.h is used throughout the AMBA code and drivers, so the header
should be available to everyone in order to driver AMBA/PrimeCell
peripherals behind a PCI bridge where the host can be any platform
(I'm doing it under x86).
At this step <asm-generic/sizes.h> includes <linux/sizes.h>,
to allow a grace period for both in-tree and out-of-tree drivers.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Alan Cox <alan@linux.intel.com>
---
include/asm-generic/sizes.h | 49 +-----------------------------------------
include/linux/sizes.h | 47 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 47 deletions(-)
create mode 100644 include/linux/sizes.h
diff --git a/include/asm-generic/sizes.h b/include/asm-generic/sizes.h
index ea5d4ef..1dcfad9 100644
--- a/include/asm-generic/sizes.h
+++ b/include/asm-generic/sizes.h
@@ -1,47 +1,2 @@
-/*
- * linux/include/asm-generic/sizes.h
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#ifndef __ASM_GENERIC_SIZES_H__
-#define __ASM_GENERIC_SIZES_H__
-
-#define SZ_1 0x00000001
-#define SZ_2 0x00000002
-#define SZ_4 0x00000004
-#define SZ_8 0x00000008
-#define SZ_16 0x00000010
-#define SZ_32 0x00000020
-#define SZ_64 0x00000040
-#define SZ_128 0x00000080
-#define SZ_256 0x00000100
-#define SZ_512 0x00000200
-
-#define SZ_1K 0x00000400
-#define SZ_2K 0x00000800
-#define SZ_4K 0x00001000
-#define SZ_8K 0x00002000
-#define SZ_16K 0x00004000
-#define SZ_32K 0x00008000
-#define SZ_64K 0x00010000
-#define SZ_128K 0x00020000
-#define SZ_256K 0x00040000
-#define SZ_512K 0x00080000
-
-#define SZ_1M 0x00100000
-#define SZ_2M 0x00200000
-#define SZ_4M 0x00400000
-#define SZ_8M 0x00800000
-#define SZ_16M 0x01000000
-#define SZ_32M 0x02000000
-#define SZ_64M 0x04000000
-#define SZ_128M 0x08000000
-#define SZ_256M 0x10000000
-#define SZ_512M 0x20000000
-
-#define SZ_1G 0x40000000
-#define SZ_2G 0x80000000
-
-#endif /* __ASM_GENERIC_SIZES_H__ */
+/* This is a placeholder, to be removed over time */
+#include <linux/sizes.h>
diff --git a/include/linux/sizes.h b/include/linux/sizes.h
new file mode 100644
index 0000000..ce3e815
--- /dev/null
+++ b/include/linux/sizes.h
@@ -0,0 +1,47 @@
+/*
+ * include/linux/sizes.h
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_SIZES_H__
+#define __LINUX_SIZES_H__
+
+#define SZ_1 0x00000001
+#define SZ_2 0x00000002
+#define SZ_4 0x00000004
+#define SZ_8 0x00000008
+#define SZ_16 0x00000010
+#define SZ_32 0x00000020
+#define SZ_64 0x00000040
+#define SZ_128 0x00000080
+#define SZ_256 0x00000100
+#define SZ_512 0x00000200
+
+#define SZ_1K 0x00000400
+#define SZ_2K 0x00000800
+#define SZ_4K 0x00001000
+#define SZ_8K 0x00002000
+#define SZ_16K 0x00004000
+#define SZ_32K 0x00008000
+#define SZ_64K 0x00010000
+#define SZ_128K 0x00020000
+#define SZ_256K 0x00040000
+#define SZ_512K 0x00080000
+
+#define SZ_1M 0x00100000
+#define SZ_2M 0x00200000
+#define SZ_4M 0x00400000
+#define SZ_8M 0x00800000
+#define SZ_16M 0x01000000
+#define SZ_32M 0x02000000
+#define SZ_64M 0x04000000
+#define SZ_128M 0x08000000
+#define SZ_256M 0x10000000
+#define SZ_512M 0x20000000
+
+#define SZ_1G 0x40000000
+#define SZ_2G 0x80000000
+
+#endif /* __LINUX_SIZES_H__ */
--
1.7.7.2
^ permalink raw reply related
* [PATCH V2 3/6] ARM: use the new linux/sizes.h
From: Alessandro Rubini @ 2012-05-28 16:37 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <cover.1338222460.git.rubini@gnudd.com>
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Alan Cox <alan@linux.intel.com>
---
arch/arm/include/asm/memory.h | 2 +-
arch/arm/mm/dma-mapping.c | 2 +-
arch/arm/mm/init.c | 2 +-
arch/arm/mm/ioremap.c | 2 +-
arch/arm/mm/mmu.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index fcb5757..e965f1b 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -16,7 +16,7 @@
#include <linux/compiler.h>
#include <linux/const.h>
#include <linux/types.h>
-#include <asm/sizes.h>
+#include <linux/sizes.h>
#ifdef CONFIG_NEED_MACH_MEMORY_H
#include <mach/memory.h>
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ea6b431..30a031c 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -23,12 +23,12 @@
#include <linux/slab.h>
#include <linux/iommu.h>
#include <linux/vmalloc.h>
+#include <linux/sizes.h>
#include <asm/memory.h>
#include <asm/highmem.h>
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
-#include <asm/sizes.h>
#include <asm/mach/arch.h>
#include <asm/dma-iommu.h>
#include <asm/mach/map.h>
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index c21d06c..ad7fd8a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -21,13 +21,13 @@
#include <linux/gfp.h>
#include <linux/memblock.h>
#include <linux/dma-contiguous.h>
+#include <linux/sizes.h>
#include <asm/mach-types.h>
#include <asm/memblock.h>
#include <asm/prom.h>
#include <asm/sections.h>
#include <asm/setup.h>
-#include <asm/sizes.h>
#include <asm/tlb.h>
#include <asm/fixmap.h>
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 4f55f50..566750f 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -25,6 +25,7 @@
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/io.h>
+#include <linux/sizes.h>
#include <asm/cp15.h>
#include <asm/cputype.h>
@@ -32,7 +33,6 @@
#include <asm/mmu_context.h>
#include <asm/pgalloc.h>
#include <asm/tlbflush.h>
-#include <asm/sizes.h>
#include <asm/system_info.h>
#include <asm/mach/map.h>
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e5dad60..2196116 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -16,13 +16,13 @@
#include <linux/memblock.h>
#include <linux/fs.h>
#include <linux/vmalloc.h>
+#include <linux/sizes.h>
#include <asm/cp15.h>
#include <asm/cputype.h>
#include <asm/sections.h>
#include <asm/cachetype.h>
#include <asm/setup.h>
-#include <asm/sizes.h>
#include <asm/smp_plat.h>
#include <asm/tlb.h>
#include <asm/highmem.h>
--
1.7.7.2
^ permalink raw reply related
* [PATCH V2 0/6] Bridging PCI to amba
From: Alessandro Rubini @ 2012-05-28 16:36 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
V2: accepted comments I got on V1; rewritten the driver to be generic;
made it tristate instead of boolean. Rebased on new next.
This patch set introduces use of AMBA devices under a PCI bridge.
The device table in the driver include all the devices that we'll be
able to run using AMBA drivers.
To compile AMBA under x86, though I need <asm/sizes.h>,
which is moved to <linux/sizes.h> as suggested earlier.
I'm hereby volunteering to handle the moving of the various users
of <asm/sizes.h> to <linux/sizes.h>; this set only moves the ARM core
files and the ones that I need under x86.
The whole patch set is sent to the same set of recipients:
all relevant lists, Russell King (for arm), Greg-KH (for uart) and
Arnd Bergmann (for generic include).
With this set in place (plus a clok API not included here) I have
4 serial ports working.
Success strings:
spusa.root# uname -r
3.4.0-next-20120528-00016-g1e5853d
spusa.root# dmesg | grep ttyA
amba-0000:03:00.5: ttyAMA0 at MMIO 0xcf400000 (irq = 64) is a PL011 rev3
amba-0000:03:00.6: ttyAMA1 at MMIO 0xcec00000 (irq = 65) is a PL011 rev3
amba-0000:03:00.7: ttyAMA2 at MMIO 0xce400000 (irq = 66) is a PL011 rev3
amba-0000:04:00.5: ttyAMA3 at MMIO 0xd3400000 (irq = 71) is a PL011 rev3
spusa.root# grep -B2 pl011 /proc/iomem
ce400000-ce7fffff : 0000:03:00.7
ce400000-ce400fff : amba-0000:03:00.7
ce400000-ce400fff : uart-pl011
--
cec00000-ceffffff : 0000:03:00.6
cec00000-cec00fff : amba-0000:03:00.6
cec00000-cec00fff : uart-pl011
--
cf400000-cf7fffff : 0000:03:00.5
cf400000-cf400fff : amba-0000:03:00.5
cf400000-cf400fff : uart-pl011
--
d3400000-d37fffff : 0000:04:00.5
d3400000-d3400fff : amba-0000:04:00.5
d3400000-d3400fff : uart-pl011
Alessandro Rubini (6):
sizes.h: move from asm-generic to <linux/sizes.h>
amba: use the new linux/sizes.h
ARM: use the new linux/sizes.h
serial: use the new linux/sizes.h
x86: add CONFIG_ARM_AMBA, selected by STA2X11
drivers/amba: add support for a PCI bridge
arch/arm/include/asm/memory.h | 2 +-
arch/arm/mm/dma-mapping.c | 2 +-
arch/arm/mm/init.c | 2 +-
arch/arm/mm/ioremap.c | 2 +-
arch/arm/mm/mmu.c | 2 +-
arch/x86/Kconfig | 4 ++
drivers/Kconfig | 2 +
drivers/amba/Kconfig | 10 ++++
drivers/amba/Makefile | 1 +
drivers/amba/bus.c | 2 +-
drivers/amba/pci-amba.c | 95 +++++++++++++++++++++++++++++++++++++++
drivers/tty/serial/amba-pl011.c | 2 +-
include/asm-generic/sizes.h | 49 +-------------------
include/linux/sizes.h | 47 +++++++++++++++++++
14 files changed, 168 insertions(+), 54 deletions(-)
create mode 100644 drivers/amba/Kconfig
create mode 100644 drivers/amba/pci-amba.c
create mode 100644 include/linux/sizes.h
--
1.7.7.2
^ permalink raw reply
* [PATCH V2 2/6] amba: use the new linux/sizes.h
From: Alessandro Rubini @ 2012-05-28 16:37 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <cover.1338222460.git.rubini@gnudd.com>
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Alan Cox <alan@linux.intel.com>
---
drivers/amba/bus.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index b7e7285..e8eb91b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -16,9 +16,9 @@
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/amba/bus.h>
+#include <linux/sizes.h>
#include <asm/irq.h>
-#include <asm/sizes.h>
#define to_amba_driver(d) container_of(d, struct amba_driver, drv)
--
1.7.7.2
^ permalink raw reply related
* Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Russell King - ARM Linux @ 2012-05-28 16:31 UTC (permalink / raw)
To: Roland Stigge
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
In-Reply-To: <4FC3A768.3060208@antcom.de>
On Mon, May 28, 2012 at 06:27:20PM +0200, Roland Stigge wrote:
> On 28/05/12 17:03, Russell King - ARM Linux wrote:
> >> Initially, with my RFC patch, there was an #ifdef for bigger FIFO in
> >> case of LPC32xx where we have a 16550A variant with 64 byte fifos.
> >
> > What are all the differences? Is it just a larger FIFO?
>
> Yes, this is how it's summarized in the manual (LPC32xx SoC).
>
> >> So maybe 16750 is the better choice for me, anyway. Already supported in
> >> of-serial. Works for now, but need more testing. Another hint is that
> >> 16750 is advertised as "IP core for Soc" which matches the case of LPC32xx.
> >
> > 16750 also has automatic hardware flow control support, selectable through
> > bit 5 in the MCR register. If your UART has that, then it's probably a
> > 16750 derivative rather than a 16550 or 16650 derivative.
> >
> > 16650s have an EFR register at offset 2, selectable by writing 0xBF into
> > the LCR register, which the 16750 doesn't have. 16650 also has automatic
> > hardware flow control, bit this is selected through a couple of bits in
> > the EFR.
>
> The 4 LPC32xx's "Standard" UARTs have neither of those.
>
> Is it ok to use "ns16650", i.e. PORT_16650, or do I need to introduce a
> FIFO depth configuration?
I think you need a new type, because as I said above, 16650s have that
additional EFR, and we will attempt to access that register which
isn't present in yours.
It's not solely about fifo depth.
^ permalink raw reply
* Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Roland Stigge @ 2012-05-28 16:27 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
In-Reply-To: <20120528150311.GA28290@n2100.arm.linux.org.uk>
On 28/05/12 17:03, Russell King - ARM Linux wrote:
>> Initially, with my RFC patch, there was an #ifdef for bigger FIFO in
>> case of LPC32xx where we have a 16550A variant with 64 byte fifos.
>
> What are all the differences? Is it just a larger FIFO?
Yes, this is how it's summarized in the manual (LPC32xx SoC).
>> So maybe 16750 is the better choice for me, anyway. Already supported in
>> of-serial. Works for now, but need more testing. Another hint is that
>> 16750 is advertised as "IP core for Soc" which matches the case of LPC32xx.
>
> 16750 also has automatic hardware flow control support, selectable through
> bit 5 in the MCR register. If your UART has that, then it's probably a
> 16750 derivative rather than a 16550 or 16650 derivative.
>
> 16650s have an EFR register at offset 2, selectable by writing 0xBF into
> the LCR register, which the 16750 doesn't have. 16650 also has automatic
> hardware flow control, bit this is selected through a couple of bits in
> the EFR.
The 4 LPC32xx's "Standard" UARTs have neither of those.
Is it ok to use "ns16650", i.e. PORT_16650, or do I need to introduce a
FIFO depth configuration?
Thanks in advance,
Roland
^ permalink raw reply
* Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Russell King - ARM Linux @ 2012-05-28 15:03 UTC (permalink / raw)
To: Roland Stigge
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
In-Reply-To: <4FC35F97.2030400@antcom.de>
On Mon, May 28, 2012 at 01:20:55PM +0200, Roland Stigge wrote:
> On 28/05/12 12:03, Russell King - ARM Linux wrote:
> > Something which occurs to me. Normally, the digit at the end indicates
> > how many ports are integrated into the device (0=1port, 2=2port, 4=4port.)
> > Are you sure there isn't a ST16650 which has the same characteristics?
> >
> > We really should stick with naming these using the single port versions if
> > at all possible.
>
> Right.
>
> This indicates to me that maybe this is not the right solution for my
> original problem, anyway. :-)
>
> Initially, with my RFC patch, there was an #ifdef for bigger FIFO in
> case of LPC32xx where we have a 16550A variant with 64 byte fifos.
What are all the differences? Is it just a larger FIFO?
> Looking at the 16x50 line:
>
> 16550A 16 bytes FIFOs
> 16650V2 32 bytes FIFOs
> 16750 64 bytes FIFOs
>
> (?)
>
> So maybe 16750 is the better choice for me, anyway. Already supported in
> of-serial. Works for now, but need more testing. Another hint is that
> 16750 is advertised as "IP core for Soc" which matches the case of LPC32xx.
16750 also has automatic hardware flow control support, selectable through
bit 5 in the MCR register. If your UART has that, then it's probably a
16750 derivative rather than a 16550 or 16650 derivative.
16650s have an EFR register at offset 2, selectable by writing 0xBF into
the LCR register, which the 16750 doesn't have. 16650 also has automatic
hardware flow control, bit this is selected through a couple of bits in
the EFR.
With that information, you should be able to track down which of these
your UART is derived from.
^ permalink raw reply
* Fw: struct tty_flip_buffer replacement in newer kernels
From: Dmitriy Alekseev @ 2012-05-28 12:52 UTC (permalink / raw)
To: linux-serial@vger.kernel.org
Cc: Юрий Зверев
In-Reply-To: <1338208815.57140.YahooMailNeo@web44914.mail.sp1.yahoo.com>
Hi,
My st16c554 chip is connected with cpu (at91rm9200) in 68 (Motorola) mode, and formally works as 68c554.
Is 8250 driver supports the 68 mode?
I thought the driver maintains whole 16c554 IC, or it means only mode 16 is supported?
Thanks.
Best regards,
Dmitriy Alekseev
________________________________
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dmitriy Alekseev <alexeev6@yahoo.com>
Cc: "linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Sent: Thursday, May 24, 2012 8:00 PM
Subject: Re: struct tty_flip_buffer replacement in newer kernels
On Thu, 24 May 2012 08:05:12 -0700 (PDT)
Dmitriy Alekseev <alexeev6@yahoo.com> wrote:
> The link I gave is original source, which I afterwards changed according to my parameters - clock and processor memory map.
>
> You right about offset 0x8, this is offset between ports in my 68 mode, I corrected, but it doesn't give any result.
You may have to stick some traces into drivers/tty/8250.c at this point
and see what is going on. It's clearly trying to do the set up right, and
created the ports but didn't believe the hardware. That usually implies
that a parameter is wrong somewhere.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo
info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Roland Stigge @ 2012-05-28 11:20 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
In-Reply-To: <20120528100338.GI24149@n2100.arm.linux.org.uk>
On 28/05/12 12:03, Russell King - ARM Linux wrote:
> Something which occurs to me. Normally, the digit at the end indicates
> how many ports are integrated into the device (0=1port, 2=2port, 4=4port.)
> Are you sure there isn't a ST16650 which has the same characteristics?
>
> We really should stick with naming these using the single port versions if
> at all possible.
Right.
This indicates to me that maybe this is not the right solution for my
original problem, anyway. :-)
Initially, with my RFC patch, there was an #ifdef for bigger FIFO in
case of LPC32xx where we have a 16550A variant with 64 byte fifos.
Looking at the 16x50 line:
16550A 16 bytes FIFOs
16650V2 32 bytes FIFOs
16750 64 bytes FIFOs
(?)
So maybe 16750 is the better choice for me, anyway. Already supported in
of-serial. Works for now, but need more testing. Another hint is that
16750 is advertised as "IP core for Soc" which matches the case of LPC32xx.
Maybe NXP can comment on this?
Thanks in advance,
Roland
^ permalink raw reply
* Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Russell King - ARM Linux @ 2012-05-28 10:03 UTC (permalink / raw)
To: Roland Stigge
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
In-Reply-To: <1338199134-23885-1-git-send-email-stigge@antcom.de>
On Mon, May 28, 2012 at 11:58:54AM +0200, Roland Stigge wrote:
> The (ST)16654 chip was missing in the list of supported chips in of-serial.
> This patch adds the string "st16654" to it, and to the documentation.
Something which occurs to me. Normally, the digit at the end indicates
how many ports are integrated into the device (0=1port, 2=2port, 4=4port.)
Are you sure there isn't a ST16650 which has the same characteristics?
We really should stick with naming these using the single port versions if
at all possible.
^ permalink raw reply
* [PATCH] serial/of-serial: Add 16654 chip to compatible string list
From: Roland Stigge @ 2012-05-28 9:58 UTC (permalink / raw)
To: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel, arnd
Cc: Roland Stigge
The (ST)16654 chip was missing in the list of supported chips in of-serial.
This patch adds the string "st16654" to it, and to the documentation.
Signed-off-by: Roland Stigge <stigge@antcom.de>
---
Applies to v3.4
Documentation/devicetree/bindings/tty/serial/of-serial.txt | 1 +
drivers/tty/serial/of_serial.c | 1 +
2 files changed, 2 insertions(+)
--- linux-2.6.orig/Documentation/devicetree/bindings/tty/serial/of-serial.txt
+++ linux-2.6/Documentation/devicetree/bindings/tty/serial/of-serial.txt
@@ -6,6 +6,7 @@ Required properties:
- "ns16450"
- "ns16550a"
- "ns16550"
+ - "st16654"
- "ns16750"
- "ns16850"
- "nvidia,tegra20-uart"
--- linux-2.6.orig/drivers/tty/serial/of_serial.c
+++ linux-2.6/drivers/tty/serial/of_serial.c
@@ -179,6 +179,7 @@ static struct of_device_id __devinitdata
{ .compatible = "ns16450", .data = (void *)PORT_16450, },
{ .compatible = "ns16550a", .data = (void *)PORT_16550A, },
{ .compatible = "ns16550", .data = (void *)PORT_16550, },
+ { .compatible = "st16654", .data = (void *)PORT_16654, },
{ .compatible = "ns16750", .data = (void *)PORT_16750, },
{ .compatible = "ns16850", .data = (void *)PORT_16850, },
{ .compatible = "nvidia,tegra20-uart", .data = (void *)PORT_TEGRA, },
^ permalink raw reply
* Re: [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Arnd Bergmann @ 2012-05-27 12:07 UTC (permalink / raw)
To: Roland Stigge
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel
In-Reply-To: <4FC21214.7060804@antcom.de>
On Sunday 27 May 2012, Roland Stigge wrote:
> > Actually some of the other entries are wrong, too. The ns8250 entry should
> > be i8250, and I guess the 16750 and 16850 were also not made by national.
>
> But maybe we should keep the existing compatible strings because
> existing boards/bootloaders are providing them already?
Right, we should only add to the list. Any entry that's already used potentially
needs to stay in there as you say.
Arnd
^ permalink raw reply
* Re: [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Roland Stigge @ 2012-05-27 11:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel
In-Reply-To: <201205271023.16742.arnd@arndb.de>
Hi,
On 27/05/12 12:23, Arnd Bergmann wrote:
>> --- a/drivers/tty/serial/of_serial.c
>> +++ b/drivers/tty/serial/of_serial.c
>> @@ -179,6 +179,7 @@ static struct of_device_id __devinitdata of_platform_serial_table[] = {
>> { .compatible = "ns16450", .data = (void *)PORT_16450, },
>> { .compatible = "ns16550a", .data = (void *)PORT_16550A, },
>> { .compatible = "ns16550", .data = (void *)PORT_16550, },
>> + { .compatible = "ns16654", .data = (void *)PORT_16654, },
>> { .compatible = "ns16750", .data = (void *)PORT_16750, },
>> { .compatible = "ns16850", .data = (void *)PORT_16850, },
>> { .compatible = "nvidia,tegra20-uart", .data = (void *)PORT_TEGRA, },
>>
>> Wondering if it should rather be .compatible = "st16654"?
>> Will prepare a patch with adjustment of Documentation/.../of-serial.txt when
>> we agree on sth.
>
> I think st16654 would be better than ns16654 here, yes.
OK, will provide a patch accordingly.
> Actually some of the other entries are wrong, too. The ns8250 entry should
> be i8250, and I guess the 16750 and 16850 were also not made by national.
But maybe we should keep the existing compatible strings because
existing boards/bootloaders are providing them already?
Roland
^ permalink raw reply
* Re: [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Arnd Bergmann @ 2012-05-27 10:23 UTC (permalink / raw)
To: Roland Stigge
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel
In-Reply-To: <4FC1EEA7.2060109@antcom.de>
On Sunday 27 May 2012, Roland Stigge wrote:
> I did it via the following modification in of_serial.c:
>
> --- a/drivers/tty/serial/of_serial.c
> +++ b/drivers/tty/serial/of_serial.c
> @@ -179,6 +179,7 @@ static struct of_device_id __devinitdata of_platform_serial_table[] = {
> { .compatible = "ns16450", .data = (void *)PORT_16450, },
> { .compatible = "ns16550a", .data = (void *)PORT_16550A, },
> { .compatible = "ns16550", .data = (void *)PORT_16550, },
> + { .compatible = "ns16654", .data = (void *)PORT_16654, },
> { .compatible = "ns16750", .data = (void *)PORT_16750, },
> { .compatible = "ns16850", .data = (void *)PORT_16850, },
> { .compatible = "nvidia,tegra20-uart", .data = (void *)PORT_TEGRA, },
>
> Works for now, will need to test more thoroughly with LPC32xx (note that
> the manual explicitly mentions "downwards compatible with the INS16Cx50"
> and "Register locations conform to ‘550 industry standard" but nothing
> about an EFR register which 16654 is configured for in 8250.c).
>
> The patch should be useful in of_serial anyway (even without the LPC32xx
> case).
>
> Wondering if it should rather be .compatible = "st16654"?
> Will prepare a patch with adjustment of Documentation/.../of-serial.txt when
> we agree on sth.
I think st16654 would be better than ns16654 here, yes.
Actually some of the other entries are wrong, too. The ns8250 entry should
be i8250, and I guess the 16750 and 16850 were also not made by national.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Roland Stigge @ 2012-05-27 9:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alan, gregkh, linux-serial, linux-kernel, kevin.wells,
srinivas.bakki, linux-arm-kernel
In-Reply-To: <201205270232.58253.arnd@arndb.de>
Hi,
On 27/05/12 04:32, Arnd Bergmann wrote:
>> this is how the modified FIFO is handled in the repositories at
>> git.lpclinux.com. Is there a better way for doing this (without ifdef)? Looks
>> like registering additional types (like PORT_16550A) isn't encouraged. Maybe
>> extending of_serial.c? The latter currently doesn't handle .fifosize and
>> .tx_loadsz, though.
>>
>> Any suggestions appreciated.
>
> We occasionally add new types, and I think that would be ok here too, if it's
> actually a new type. It definitely doesn't look like a 16550.
>
> I wonder if it's in fact a PORT_16654, or if we can at least pretend it's one.
Thanks for the hint!
I did it via the following modification in of_serial.c:
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -179,6 +179,7 @@ static struct of_device_id __devinitdata of_platform_serial_table[] = {
{ .compatible = "ns16450", .data = (void *)PORT_16450, },
{ .compatible = "ns16550a", .data = (void *)PORT_16550A, },
{ .compatible = "ns16550", .data = (void *)PORT_16550, },
+ { .compatible = "ns16654", .data = (void *)PORT_16654, },
{ .compatible = "ns16750", .data = (void *)PORT_16750, },
{ .compatible = "ns16850", .data = (void *)PORT_16850, },
{ .compatible = "nvidia,tegra20-uart", .data = (void *)PORT_TEGRA, },
Works for now, will need to test more thoroughly with LPC32xx (note that
the manual explicitly mentions "downwards compatible with the INS16Cx50"
and "Register locations conform to ‘550 industry standard" but nothing
about an EFR register which 16654 is configured for in 8250.c).
The patch should be useful in of_serial anyway (even without the LPC32xx
case).
Wondering if it should rather be .compatible = "st16654"?
Will prepare a patch with adjustment of Documentation/.../of-serial.txt when
we agree on sth.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Arnd Bergmann @ 2012-05-27 2:32 UTC (permalink / raw)
To: Roland Stigge
Cc: srinivas.bakki, gregkh, linux-kernel, kevin.wells, linux-serial,
linux-arm-kernel, alan
In-Reply-To: <1338048678-23991-1-git-send-email-stigge@antcom.de>
On Saturday 26 May 2012, Roland Stigge wrote:
> Hi,
>
> this is how the modified FIFO is handled in the repositories at
> git.lpclinux.com. Is there a better way for doing this (without ifdef)? Looks
> like registering additional types (like PORT_16550A) isn't encouraged. Maybe
> extending of_serial.c? The latter currently doesn't handle .fifosize and
> .tx_loadsz, though.
>
> Any suggestions appreciated.
We occasionally add new types, and I think that would be ok here too, if it's
actually a new type. It definitely doesn't look like a 16550.
I wonder if it's in fact a PORT_16654, or if we can at least pretend it's one.
Arnd
^ permalink raw reply
* [PATCH RFC] serial/8250: Adjusting FIFO parameters for LPC32xx
From: Roland Stigge @ 2012-05-26 16:11 UTC (permalink / raw)
To: alan, gregkh, linux-serial, linux-kernel, arnd, kevin.wells,
srinivas.bakki, linux-arm-kernel
Cc: Roland Stigge
Hi,
this is how the modified FIFO is handled in the repositories at
git.lpclinux.com. Is there a better way for doing this (without ifdef)? Looks
like registering additional types (like PORT_16550A) isn't encouraged. Maybe
extending of_serial.c? The latter currently doesn't handle .fifosize and
.tx_loadsz, though.
Any suggestions appreciated.
Thanks in advance,
Roland
---
drivers/tty/serial/8250/8250.c | 7 +++++++
1 file changed, 7 insertions(+)
--- linux-2.6.orig/drivers/tty/serial/8250/8250.c
+++ linux-2.6/drivers/tty/serial/8250/8250.c
@@ -158,9 +158,16 @@ static const struct serial8250_config ua
},
[PORT_16550A] = {
.name = "16550A",
+#ifdef CONFIG_ARCH_LPC32XX
+ .fifo_size = 64,
+ .tx_loadsz = 32,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_00 | UART_FCR_T_TRIG_00,
+#else
.fifo_size = 16,
.tx_loadsz = 16,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+#endif
.flags = UART_CAP_FIFO,
},
[PORT_CIRRUS] = {
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Alessandro Rubini @ 2012-05-26 9:27 UTC (permalink / raw)
To: linux
Cc: linux-kernel, giancarlo.asnaghi, alan, x86, gregkh, arnd,
linux-arm-kernel, linux-serial, linux-arch
In-Reply-To: <20120526084328.GE24149@n2100.arm.linux.org.uk>
>> + default y if STA2X11
>
> I don't think we want to encourage an ever growing list of platforms
> here. If we did this on ARM, this would be hellishly long.
Ok.
> NAK. We have interfaces in the AMBA code for dynamically allocating
> AMBA devices now - please use them instead of coding your own. They
> avoid bugs.
Sure. Thanks for noting. Maybe it wasn't there when I coded this
initially. Will do.
>> + printk(KERN_INFO "%s %i\n", __func__, __LINE__);
>
> This looks like debugging.
Yes. After sending I noted this and another point. I apologize.
Version 2 will be fixed in all respects.
> This comes nowhere close to being sane with the driver model. [...]
> In other words, save off the platform data pointer, unregister the struct
> device, and then free the platform data (it will not be used at that point.)
Thanks a lot for this and also the comments on APB/AHB in the other message.
/alessandro
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Russell King - ARM Linux @ 2012-05-26 8:48 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, Giancarlo Asnaghi, Alan Cox, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <b166cb0fce2a67b24da5808604553b4196258f45.1337959750.git.rubini@gnudd.com>
One other point.
On Fri, May 25, 2012 at 05:48:57PM +0200, Alessandro Rubini wrote:
> +/* This is a template, copied every time a new pci device appears */
> +static AMBA_APB_DEVICE(pl011_pci_template, "pl011-pci", 0,
> + 0 /* base */, {0} /* irqs */, NULL /* data */);
APB device. It's a _peripheral_, it only has a _slave_ port which can't
initiate DMA, so:
> + if (pdev->vendor == PCI_VENDOR_ID_STMICRO) {
> + /* Under sta2x11, DMA is there but limited to 512M */
> + adev->dma_mask = SZ_512M - 1;
> + adev->dev.coherent_dma_mask = SZ_512M - 1;
> + }
This is pointless and unnecessary. The PL011 driver itself doesn't use
_this_ struct device for anything to do with DMA at all. That's all
handled by the DMA engine's struct device.
That's true of all APB devices. Only AHB devices with a master port can
initiate bus transactions, and hence cause accesses to other parts of the
system.
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Russell King - ARM Linux @ 2012-05-26 8:43 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, Giancarlo Asnaghi, Alan Cox, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <b166cb0fce2a67b24da5808604553b4196258f45.1337959750.git.rubini@gnudd.com>
On Fri, May 25, 2012 at 05:48:57PM +0200, Alessandro Rubini wrote:
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 070b442..e5e5ef6 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -39,14 +39,22 @@ config SERIAL_AMBA_PL010_CONSOLE
> config SERIAL_AMBA_PL011
> tristate "ARM AMBA PL011 serial port support"
> depends on ARM_AMBA
> + default y if STA2X11
I don't think we want to encourage an ever growing list of platforms
here. If we did this on ARM, this would be hellishly long.
> +/* This is a template, copied every time a new pci device appears */
> +static AMBA_APB_DEVICE(pl011_pci_template, "pl011-pci", 0,
> + 0 /* base */, {0} /* irqs */, NULL /* data */);
> +
> +static int __devinit pl011_pci_probe(struct pci_dev *pdev,
> + const struct pci_device_id *id)
> +{
> + struct amba_device *adev;
> + struct amba_pl011_data *data;
> + int ret;
> +
> + /* Simply build an amba device and register it */
> + adev = kmemdup(&pl011_pci_template_device,
> + sizeof(pl011_pci_template_device), GFP_KERNEL);
NAK. We have interfaces in the AMBA code for dynamically allocating
AMBA devices now - please use them instead of coding your own. They
avoid bugs.
> + /* change name */
> + adev->dev.init_name = kasprintf(GFP_ATOMIC, "pl011-pci-%02x:%04x",
> + pdev->bus->number, pdev->devfn);
> +
> + printk(KERN_INFO "%s %i\n", __func__, __LINE__);
This looks like debugging.
> + if ((ret = amba_device_register(adev, &pdev->resource[0])) < 0) {
> + kfree(adev);
> + return ret;
> + }
> + return 0;
> +};
> +
> +static void __devexit pl011_pci_remove(struct pci_dev *pdev)
> +{
> + struct amba_device *adev = pci_get_drvdata(pdev);
> + amba_device_unregister(adev);
> + kfree(adev->dev.platform_data);
> + kfree(adev);
This comes nowhere close to being sane with the driver model. This is
an oops waiting to happen. You can't guarantee that 'adev' will be
unused by the time amba_device_unregister() (or in fact any such call
into the driver model) returns.
This is because these suckers (and all devices) are refcounted. If you
use the correct interfaces, the devices will be freed for you automatically
at the correct time.
The only thing that won't be is adev->dev.platform_data - the correct way
to do this is the following along with the correct allocation interfaces:
struct amba_device *adev = pci_get_drvdata(pdev);
void *priv = adev->dev.platform_data;
amba_device_unregister(adev);
kfree(priv);
In other words, save off the platform data pointer, unregister the struct
device, and then free the platform data (it will not be used at that point.)
^ permalink raw reply
* Re: [PATCH 2/6] amba: use the new linux/sizes.h
From: Russell King - ARM Linux @ 2012-05-26 8:33 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, Giancarlo Asnaghi, Alan Cox, x86,
Greg Kroah-Hartman, Arnd Bergmann, linux-arm-kernel, linux-serial,
linux-arch
In-Reply-To: <0e1b40d651ffbc654616173f2c3bf89888db21a5.1337959750.git.rubini@gnudd.com>
On Fri, May 25, 2012 at 05:48:12PM +0200, Alessandro Rubini wrote:
> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
> drivers/amba/bus.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index b7e7285..e29bfa7 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -18,7 +18,7 @@
> #include <linux/amba/bus.h>
>
> #include <asm/irq.h>
> -#include <asm/sizes.h>
> +#include <linux/sizes.h>
Please move this up alongside the other linux/ includes.
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Arnd Bergmann @ 2012-05-26 8:29 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, giancarlo.asnaghi, alan, linux, x86, gregkh,
linux-arm-kernel, linux-serial, linux-arch
In-Reply-To: <20120526075855.GA1702@mail.gnudd.com>
On Saturday 26 May 2012, Alessandro Rubini wrote:
> > Aside from the dma mask, this looks almost entirely generic. Would it
> > be possible to make this a generic pci-amba driver that lives under
> > drivers/amba/ and does not care about the type of device behind it?
>
> Yes, it's possible. Actually, this was my longer-time plan: propose a
> factorization when more of those were ready. So I'll remove the
> special name in the device and offer an implementation as generic
> as possible.
>
> BTW, are the prerequisite patches of with you?
>
Yes, they all look good to me, although patch 5 would have to change
if you do patch 6 the way we discussed here.
Arnd
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Alessandro Rubini @ 2012-05-26 7:58 UTC (permalink / raw)
To: arnd
Cc: linux-kernel, giancarlo.asnaghi, alan, linux, x86, gregkh,
linux-arm-kernel, linux-serial, linux-arch
In-Reply-To: <201205260739.31653.arnd@arndb.de>
> Aside from the dma mask, this looks almost entirely generic. Would it
> be possible to make this a generic pci-amba driver that lives under
> drivers/amba/ and does not care about the type of device behind it?
Yes, it's possible. Actually, this was my longer-time plan: propose a
factorization when more of those were ready. So I'll remove the
special name in the device and offer an implementation as generic
as possible.
BTW, are the prerequisite patches of with you?
thanks
/alessandro
^ permalink raw reply
* Re: [PATCH 6/6] serial: add amba-pl011-pci
From: Arnd Bergmann @ 2012-05-26 7:39 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, Giancarlo Asnaghi, Alan Cox, Russell King, x86,
Greg Kroah-Hartman, linux-arm-kernel, linux-serial, linux-arch
In-Reply-To: <b166cb0fce2a67b24da5808604553b4196258f45.1337959750.git.rubini@gnudd.com>
On Friday 25 May 2012, Alessandro Rubini wrote:
>
> This is a simple PCI driver that registers an amba device
> in its probe function. It successfully drives the 4 serial
> ports of the sta2x11 I/O Hub.
>
> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Aside from the dma mask, this looks almost entirely generic. Would it
be possible to make this a generic pci-amba driver that lives under
drivers/amba/ and does not care about the type of device behind it?
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox