* [PATCH 2/4] serial: i.MX: Make console support non optional
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-serial, Greg Kroah-Hartman, devicetree-discuss,
Nicolas Ferre, Grant Likely, kernel, Sascha Hauer, Alan Cox
In-Reply-To: <1353513428-25697-1-git-send-email-plagnioj@jcrosoft.com>
From: Sascha Hauer <s.hauer@pengutronix.de>
Traditionally console support is optional for serial drivers. This
makes it non optional for the i.MX driver since it's not worth
asking questions for a feature virtually every user of this driver
wants to have.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-serial@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: kernel@pengutronix.de
Cc: Alan Cox <alan@linux.intel.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/Kconfig | 16 +---------------
drivers/tty/serial/imx.c | 8 +-------
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b176801..10e5eec 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -541,26 +541,12 @@ config SERIAL_IMX
bool "IMX serial port support"
depends on ARCH_MXC
select SERIAL_CORE
+ select SERIAL_CORE_CONSOLE
select RATIONAL
help
If you have a machine based on a Motorola IMX CPU you
can enable its onboard serial port by enabling this option.
-config SERIAL_IMX_CONSOLE
- bool "Console on IMX serial port"
- depends on SERIAL_IMX
- select SERIAL_CORE_CONSOLE
- help
- If you have enabled the serial port on the Motorola IMX
- CPU you can make it the console by answering Y to this option.
-
- Even if you say Y here, the currently visible virtual console
- (/dev/tty0) will still be used as the system console by default, but
- you can alter that using a kernel command line option such as
- "console=ttySA0". (Try "man bootparam" or see the documentation of
- your boot loader (lilo or loadlin) about how to pass options to the
- kernel at boot time.)
-
config SERIAL_UARTLITE
tristate "Xilinx uartlite serial port support"
depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 5981912..07a8ca1 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1192,7 +1192,6 @@ static struct uart_ops imx_pops = {
static struct imx_port *imx_ports[UART_NR];
-#ifdef CONFIG_SERIAL_IMX_CONSOLE
static void imx_console_putchar(struct uart_port *port, int ch)
{
struct imx_port *sport = (struct imx_port *)port;
@@ -1348,11 +1347,6 @@ static struct console imx_console = {
.data = &imx_reg,
};
-#define IMX_CONSOLE &imx_console
-#else
-#define IMX_CONSOLE NULL
-#endif
-
static struct uart_driver imx_reg = {
.owner = THIS_MODULE,
.driver_name = DRIVER_NAME,
@@ -1360,7 +1354,7 @@ static struct uart_driver imx_reg = {
.major = SERIAL_IMX_MAJOR,
.minor = MINOR_START,
.nr = ARRAY_SIZE(imx_ports),
- .cons = IMX_CONSOLE,
+ .cons = &imx_console,
};
static int serial_imx_suspend(struct platform_device *dev, pm_message_t state)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/4] OF: Add helper for matching against linux,stdout-path
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-21 15:57 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer, Alan Cox
In-Reply-To: <20121121155312.GX4398-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
From: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
devicetrees may have a linux,stdout-path or stdout-path property
in the chosen node describing the console device. This adds a helper
function to match a device against this property and retrieve the options
so a driver can call add_preferred_console for a matching device.
Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
Cc: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
---
drivers/of/base.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 7 +++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index f2f63c8..72c49ce 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1470,3 +1470,49 @@ const char *of_prop_next_string(struct property *prop, const char *cur)
return curv;
}
EXPORT_SYMBOL_GPL(of_prop_next_string);
+
+/**
+ * of_device_is_stdout_path - check if a device node matches the
+ * linux,stdout-path property
+ * @np: Pointer to the given device_node
+ * @option: parsed option
+ *
+ * Check if this device node matches the linux,stdout-path property
+ * in the chosen node. return true if yes, false otherwise.
+ */
+int of_device_is_stdout_path(struct device_node *dn, char **option)
+{
+ const char *name;
+ struct device_node *dn_stdout;
+ bool is_stdout = 0;
+ const char *tmp;
+ const char *tmp_option;
+
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL)
+ name = of_get_property(of_chosen, "stdout-path", NULL);
+
+ if (name == NULL)
+ return 0;
+
+ tmp_option = strchr(name, ':');
+
+ tmp = kstrndup(name, strlen(name) - strlen(tmp_option), GFP_KERNEL);
+ if (!tmp)
+ return 0;
+
+ dn_stdout = of_find_node_by_path(tmp);
+
+ if (dn_stdout && dn_stdout == dn) {
+ is_stdout = 1;
+ tmp_option++;
+ *option = kstrdup(tmp_option, GFP_KERNEL);
+ }
+
+ of_node_put(dn_stdout);
+
+ kfree(tmp);
+
+ return is_stdout;
+}
+EXPORT_SYMBOL_GPL(of_device_is_stdout_path);
diff --git a/include/linux/of.h b/include/linux/of.h
index 681a6c8..6a82e3f 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -323,6 +323,8 @@ const char *of_prop_next_string(struct property *prop, const char *cur);
s; \
s = of_prop_next_string(prop, s))
+int of_device_is_stdout_path(struct device_node *dn, char **option);
+
#else /* CONFIG_OF */
static inline const char* of_node_full_name(struct device_node *np)
@@ -450,6 +452,11 @@ static inline int of_machine_is_compatible(const char *compat)
return 0;
}
+static inline int of_device_is_stdout_path(struct device_node *dn, char **option)
+{
+ return 0;
+}
+
#define of_match_ptr(_ptr) NULL
#define of_match_node(_matches, _node) NULL
#define of_property_for_each_u32(np, propname, prop, p, u) \
--
1.7.10.4
^ permalink raw reply related
* [PATCH v5] linux,stdout-path helper
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-21 15:53 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, devicetree-discuss, linux-kernel, kernel,
Sascha Hauer, linux-arm-kernel
The following adds a helper for matching the linux,stdout-path property
in the chosen node and makes use of it in the i.MX serial and Atmel serial driver.
changes since v4:
- add option support and check stdout-path too
changes since v3:
- move code from separate files to drivers/of/base.c and include/linux/of.h
changes since v2:
- move helper to OF core and make it independent of serial devices
changes since v1:
- move it out of the i.MX serial driver and make it generic for serial
devices.
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* [PATCH 2/2 Resubmit] tty/8250 Add XR17D15x devices to the exar_handle_irq override
From: Matt Schulte @ 2012-11-21 15:40 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
In-Reply-To: <CAJp1Oe5hxCSzLy3JRWJjOOiyoYjoiheTUriYaZNCmzDN-aYj=A@mail.gmail.com>
Add XR17D15x devices to the exar_handle_irq override: they have the
same extra interrupt register that could fire and never be serviced by
the standard handle_irq.
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 44be636..1cda869 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1578,7 +1578,8 @@ static int exar_handle_irq(struct uart_port *port)
ret = serial8250_handle_irq(port, iir);
- if (port->type == PORT_XR17V35X) {
+ if ((port->type == PORT_XR17V35X) ||
+ (port->type == PORT_XR17D15X)) {
int0 = serial_port_in(port, 0x80);
int1 = serial_port_in(port, 0x81);
int2 = serial_port_in(port, 0x82);
@@ -2689,7 +2690,8 @@ static void serial8250_config_port(struct
uart_port *port, int flags)
serial8250_release_std_resource(up);
/* Fixme: probably not the best place for this */
- if (port->type == PORT_XR17V35X)
+ if ((port->type == PORT_XR17V35X) ||
+ (port->type == PORT_XR17D15X))
port->handle_irq = exar_handle_irq;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/2 - Resubmit] tty/8250: Add sleep capability to XR17D15X ports
From: Matt Schulte @ 2012-11-21 15:39 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
In-Reply-To: <CAJp1Oe4UiEpt4fXMD5X=bPR8q4-y3RsLGgFa3MGxbvvDauiwbg@mail.gmail.com>
Add sleep capability to XR17D15X ports
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
[PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index df7f433..44be636 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -280,7 +280,8 @@ static const struct serial8250_config uart_config[] = {
.fifo_size = 64,
.tx_loadsz = 64,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
- .flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR,
+ .flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP,
},
[PORT_XR17V35X] = {
.name = "XR17V35X",
@@ -591,7 +592,8 @@ static void serial8250_set_sleep(struct
uart_8250_port *p, int sleep)
* offset but the UART channel may only write to the corresponding
* bit.
*/
- if (p->port.type == PORT_XR17V35X) {
+ if ((p->port.type == PORT_XR17V35X) ||
+ (p->port.type == PORT_XR17D15X)) {
serial_out(p, UART_EXAR_SLEEP, 0xff);
return;
}
@@ -1056,8 +1058,12 @@ static void autoconfig_16550a(struct uart_8250_port *up)
* Exar uarts have EFR in a weird location
*/
if (up->port.flags & UPF_EXAR_EFR) {
+ DEBUG_AUTOCONF("Exar XR17D15x ");
up->port.type = PORT_XR17D15X;
- up->capabilities |= UART_CAP_AFE | UART_CAP_EFR;
+ up->capabilities |= UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP;
+
+ return;
}
/*
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards
From: Alan Cox @ 2012-11-21 15:27 UTC (permalink / raw)
To: Matt Schulte; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CAJp1Oe7syKV54oOisSO=DX+hBaZxugSqQoHXoCPmDVWUiT1dOQ@mail.gmail.com>
> + p = pci_ioremap_bar(priv->dev, 0);
This can in theory fail so should be checked.
> +
> + port->port.flags |= UPF_EXAR_EFR;
> +
> + /*
> + * Setup Multipurpose Input/Output pins.
> + */
> + if (idx == 0) {
> + switch (priv->dev->device) {
> + case 0x04: /* PCI_DEVICE_ID_COMMTECH_4222PCI335 */
> + case 0x02: /* PCI_DEVICE_ID_COMMTECH_4224PCI335 */
> + writeb(0x78, p + 0x90); /* MPIOLVL[7:0] */
> + writeb(0x00, p + 0x92); /* MPIOINV[7:0] */
> + writeb(0x00, p + 0x93); /* MPIOSEL[7:0] */
> + break;
> + case 0x0a: /* PCI_DEVICE_ID_COMMTECH_2324PCI335 */
> + case 0x0b: /* PCI_DEVICE_ID_COMMTECH_2328PCI335 */
> + writeb(0x00, p + 0x90); /* MPIOLVL[7:0] */
> + writeb(0xc0, p + 0x92); /* MPIOINV[7:0] */
> + writeb(0xc0, p + 0x93); /* MPIOSEL[7:0] */
> + break;
> + }
> + writeb(0x00, p + 0x8f); /* MPIOINT[7:0] */
> + writeb(0x00, p + 0x91); /* MPIO3T[7:0] */
> + writeb(0x00, p + 0x94); /* MPIOOD[7:0] */
> + }
> + writeb(0x00, p + UART_EXAR_8XMODE);
> + writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
> + writeb(32, p + UART_EXAR_TXTRG);
> + writeb(32, p + UART_EXAR_RXTRG);
> + iounmap(p);
> +
> + return pci_default_setup(priv, board, port, idx);
> +}
> +
> +static int
> pci_wch_ch353_setup(struct serial_private *priv,
> const struct pciserial_board *board,
> struct uart_8250_port *port, int idx)
> @@ -1246,6 +1288,13 @@ pci_wch_ch353_setup(struct serial_private *priv,
> #define PCI_VENDOR_ID_AGESTAR 0x5372
> #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
> #define PCI_VENDOR_ID_ASIX 0x9710
> +#define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
> +#define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
> +#define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
> +#define PCI_DEVICE_ID_COMMTECH_2328PCI335 0x000b
> +#define PCI_DEVICE_ID_COMMTECH_4222PCIE 0x0019
> +#define PCI_DEVICE_ID_COMMTECH_4224PCIE 0x0020
> +#define PCI_DEVICE_ID_COMMTECH_4228PCIE 0x0021
Would be better if these defines were above where you use them commented
in the code...
Otherwise looks good.
^ permalink raw reply
* [PATCH] tty/8250 Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards
From: Matt Schulte @ 2012-11-21 15:17 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Add support for Commtech's Fastcom Async-335 and Fastcom Async-PCIe cards
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submissions:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
[PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
[PATCH 2/2] tty/8250 Add XR17D15x devices to the exar_handle_irq override
[PATCH 1/3] Add register definitions used in several Exar PCI/PCIe UARTs
drivers/tty/serial/8250/8250_pci.c | 159 ++++++++++++++++++++++++++++++++++++
include/linux/pci_ids.h | 2 +
2 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index c422871..6a7007c 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1198,6 +1198,48 @@ pci_xr17v35x_setup(struct serial_private *priv,
}
static int
+pci_fastcom335_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_8250_port *port, int idx)
+{
+ u8 __iomem *p;
+
+ p = pci_ioremap_bar(priv->dev, 0);
+
+ port->port.flags |= UPF_EXAR_EFR;
+
+ /*
+ * Setup Multipurpose Input/Output pins.
+ */
+ if (idx == 0) {
+ switch (priv->dev->device) {
+ case 0x04: /* PCI_DEVICE_ID_COMMTECH_4222PCI335 */
+ case 0x02: /* PCI_DEVICE_ID_COMMTECH_4224PCI335 */
+ writeb(0x78, p + 0x90); /* MPIOLVL[7:0] */
+ writeb(0x00, p + 0x92); /* MPIOINV[7:0] */
+ writeb(0x00, p + 0x93); /* MPIOSEL[7:0] */
+ break;
+ case 0x0a: /* PCI_DEVICE_ID_COMMTECH_2324PCI335 */
+ case 0x0b: /* PCI_DEVICE_ID_COMMTECH_2328PCI335 */
+ writeb(0x00, p + 0x90); /* MPIOLVL[7:0] */
+ writeb(0xc0, p + 0x92); /* MPIOINV[7:0] */
+ writeb(0xc0, p + 0x93); /* MPIOSEL[7:0] */
+ break;
+ }
+ writeb(0x00, p + 0x8f); /* MPIOINT[7:0] */
+ writeb(0x00, p + 0x91); /* MPIO3T[7:0] */
+ writeb(0x00, p + 0x94); /* MPIOOD[7:0] */
+ }
+ writeb(0x00, p + UART_EXAR_8XMODE);
+ writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
+ writeb(32, p + UART_EXAR_TXTRG);
+ writeb(32, p + UART_EXAR_RXTRG);
+ iounmap(p);
+
+ return pci_default_setup(priv, board, port, idx);
+}
+
+static int
pci_wch_ch353_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_8250_port *port, int idx)
@@ -1246,6 +1288,13 @@ pci_wch_ch353_setup(struct serial_private *priv,
#define PCI_VENDOR_ID_AGESTAR 0x5372
#define PCI_DEVICE_ID_AGESTAR_9375 0x6872
#define PCI_VENDOR_ID_ASIX 0x9710
+#define PCI_DEVICE_ID_COMMTECH_4222PCI335 0x0004
+#define PCI_DEVICE_ID_COMMTECH_4224PCI335 0x0002
+#define PCI_DEVICE_ID_COMMTECH_2324PCI335 0x000a
+#define PCI_DEVICE_ID_COMMTECH_2328PCI335 0x000b
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE 0x0019
+#define PCI_DEVICE_ID_COMMTECH_4224PCIE 0x0020
+#define PCI_DEVICE_ID_COMMTECH_4228PCIE 0x0021
/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
@@ -1842,6 +1891,59 @@ static struct pci_serial_quirk
pci_serial_quirks[] __refdata = {
.setup = pci_asix_setup,
},
/*
+ * Commtech, Inc. Fastcom adapters
+ *
+ */
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_4222PCI335,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_fastcom335_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_4224PCI335,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_fastcom335_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_2324PCI335,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_fastcom335_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_2328PCI335,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_fastcom335_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_4222PCIE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_4224PCIE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_COMMTECH,
+ .device = PCI_DEVICE_ID_COMMTECH_4228PCIE,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ /*
* Default "match everything" terminator entry
*/
{
@@ -1917,6 +2019,10 @@ enum pci_board_num_t {
pbn_b0_4_1152000,
+ pbn_b0_2_1152000_200,
+ pbn_b0_4_1152000_200,
+ pbn_b0_8_1152000_200,
+
pbn_b0_2_1843200,
pbn_b0_4_1843200,
@@ -2114,6 +2220,27 @@ static struct pciserial_board pci_boards[]
__devinitdata = {
.uart_offset = 8,
},
+ [pbn_b0_2_1152000_200] = {
+ .flags = FL_BASE0,
+ .num_ports = 2,
+ .base_baud = 1152000,
+ .uart_offset = 0x200,
+ },
+
+ [pbn_b0_4_1152000_200] = {
+ .flags = FL_BASE0,
+ .num_ports = 4,
+ .base_baud = 1152000,
+ .uart_offset = 0x200,
+ },
+
+ [pbn_b0_8_1152000_200] = {
+ .flags = FL_BASE0,
+ .num_ports = 2,
+ .base_baud = 1152000,
+ .uart_offset = 0x200,
+ },
+
[pbn_b0_2_1843200] = {
.flags = FL_BASE0,
.num_ports = 2,
@@ -4353,6 +4480,38 @@ static struct pci_device_id serial_pci_tbl[] = {
0, 0, pbn_b0_bt_2_115200 },
/*
+ * Commtech, Inc. Fastcom adapters
+ */
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4222PCI335,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_b0_2_1152000_200 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4224PCI335,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_b0_4_1152000_200 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_2324PCI335,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_b0_4_1152000_200 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_2328PCI335,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_b0_8_1152000_200 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4222PCIE,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V352 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4224PCIE,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V354 },
+ { PCI_VENDOR_ID_COMMTECH, PCI_DEVICE_ID_COMMTECH_4228PCIE,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V358 },
+
+ /*
* These entries match devices with class COMMUNICATION_SERIAL,
* COMMUNICATION_MODEM or COMMUNICATION_MULTISERIAL
*/
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 0199a7a..0f84473 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2326,6 +2326,8 @@
#define PCI_VENDOR_ID_TOPSPIN 0x1867
+#define PCI_VENDOR_ID_COMMTECH 0x18f7
+
#define PCI_VENDOR_ID_SILAN 0x1904
#define PCI_VENDOR_ID_RENESAS 0x1912
--
1.7.2.5
^ permalink raw reply related
* Re: [REPOST-v2] sched: Prevent wakeup to enter critical section needlessly
From: Oleg Nesterov @ 2012-11-21 13:58 UTC (permalink / raw)
To: Ivo Sieben
Cc: linux-kernel, Andi Kleen, Peter Zijlstra, Ingo Molnar,
linux-serial, Alan Cox, Greg KH
In-Reply-To: <CAMSQXEGfQE_vcvk9MvP-aJD2jeF7vU+84yx_fEn==v2Jve9w0A@mail.gmail.com>
On 11/21, Ivo Sieben wrote:
> Hi
>
> 2012/11/19 Oleg Nesterov <oleg@redhat.com>:
> >
> > Because on a second thought I suspect this change is wrong.
> >
> > Just for example, please look at kauditd_thread(). It does
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> >
> > add_wait_queue(&kauditd_wait, &wait);
> >
> > if (!CONDITION) // <-- LOAD
> > schedule();
> >
> > And the last LOAD can leak into the critical section protected by
> > wait_queue_head_t->lock, and it can be reordered with list_add()
> > inside this critical section. In this case we can race with wake_up()
> > unless it takes the same lock.
> >
> > Oleg.
> >
>
> I agree that I should solve my problem using the waitqueue_active()
> function locally. I'll abandon this patch and fix it in the
> tty_ldisc.c.
>
> But we try to understand your fault scenario: How can the LOAD leak
> into the critical section? As far as we understand the spin_unlock()
> function also contains a memory barrier
^^^^^^^^^^^^^^
Not really, in general unlock is a one-way barrier.
> to prevent such a reordering
> from happening.
Please look at the comment above prepare_to_wait(), for example. Or
look at wmb() in try_to_wake_up().
I guess this is not possible on x86, but in general
X;
LOCK();
UNLOCK();
Y;
can be reordered as
LOCK();
Y;
X;
UNLOCK();
UNLOCK + LOCK is the full memory barrier.
Oleg.
^ permalink raw reply
* Re: [REPOST-v2] sched: Prevent wakeup to enter critical section needlessly
From: Alan Cox @ 2012-11-21 13:47 UTC (permalink / raw)
To: Ivo Sieben
Cc: Oleg Nesterov, linux-kernel, Andi Kleen, Peter Zijlstra,
Ingo Molnar, linux-serial, Alan Cox, Greg KH
In-Reply-To: <CAMSQXEGfQE_vcvk9MvP-aJD2jeF7vU+84yx_fEn==v2Jve9w0A@mail.gmail.com>
> But we try to understand your fault scenario: How can the LOAD leak
> into the critical section? As far as we understand the spin_unlock()
> function also contains a memory barrier to prevent such a reordering
> from happening.
It does - it would be very interesting for someone to look at the assembly
if this is making a difference.
Alan
^ permalink raw reply
* Re: [REPOST-v2] sched: Prevent wakeup to enter critical section needlessly
From: Ivo Sieben @ 2012-11-21 13:03 UTC (permalink / raw)
To: Oleg Nesterov
Cc: linux-kernel, Andi Kleen, Peter Zijlstra, Ingo Molnar,
linux-serial, Alan Cox, Greg KH
In-Reply-To: <20121119154940.GA6354@redhat.com>
Hi
2012/11/19 Oleg Nesterov <oleg@redhat.com>:
>
> Because on a second thought I suspect this change is wrong.
>
> Just for example, please look at kauditd_thread(). It does
>
> set_current_state(TASK_INTERRUPTIBLE);
>
> add_wait_queue(&kauditd_wait, &wait);
>
> if (!CONDITION) // <-- LOAD
> schedule();
>
> And the last LOAD can leak into the critical section protected by
> wait_queue_head_t->lock, and it can be reordered with list_add()
> inside this critical section. In this case we can race with wake_up()
> unless it takes the same lock.
>
> Oleg.
>
I agree that I should solve my problem using the waitqueue_active()
function locally. I'll abandon this patch and fix it in the
tty_ldisc.c.
But we try to understand your fault scenario: How can the LOAD leak
into the critical section? As far as we understand the spin_unlock()
function also contains a memory barrier to prevent such a reordering
from happening.
Regards,
Ivo
^ permalink raw reply
* Re: [PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
From: Matt Schulte @ 2012-11-20 19:33 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CAJp1Oe4UiEpt4fXMD5X=bPR8q4-y3RsLGgFa3MGxbvvDauiwbg@mail.gmail.com>
On Tue, Nov 20, 2012 at 10:32 AM, Matt Schulte
<matts@commtech-fastcom.com> wrote:
> Add sleep capability to XR17D15X ports
>
> Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
> ---
> [PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
> Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
>
> This depends on my previous patch submission:
> [PATCH v3] Add support for new devices: Exar's XR17V35x family of
> multi-port PCIe UARTs
>
> drivers/tty/serial/8250/8250.c | 12 +++++++++---
Alan, did you get a chance to look at this one?
Thanks,
Matt Schulte
^ permalink raw reply
* Re: [PATCH 1/3] Add register definitions used in several Exar PCI/PCIe UARTs
From: Alan Cox @ 2012-11-20 17:58 UTC (permalink / raw)
To: Matt Schulte; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CAJp1Oe4aoeEQnDQWFAVaKNXVMn+294ZhNX6GfYx7F3Ym3ux6xQ@mail.gmail.com>
On Tue, 20 Nov 2012 11:21:17 -0600
Matt Schulte <matts@commtech-fastcom.com> wrote:
> Add register definitions used in several Exar PCI/PCIe UARTs
Ack to all 3 patches
^ permalink raw reply
* [PATCH 3/3] Add initialization of sampling mode and tx/rx triggers to pci_xr17v35x_setup
From: Matt Schulte @ 2012-11-20 17:25 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Add initialization of sampling mode and tx/rx triggers to pci_xr17v35x_setup
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250_pci.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index 6a7007c..3b5c426 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1192,6 +1192,10 @@ pci_xr17v35x_setup(struct serial_private *priv,
writeb(0x00, p + 0x99); /*MPIOSEL[15:8]*/
writeb(0x00, p + 0x9a); /*MPIOOD[15:8]*/
}
+ writeb(0x00, p + UART_EXAR_8XMODE);
+ writeb(UART_FCTR_EXAR_TRGD, p + UART_EXAR_FCTR);
+ writeb(128, p + UART_EXAR_TXTRG);
+ writeb(128, p + UART_EXAR_RXTRG);
iounmap(p);
return pci_default_setup(priv, board, port, idx);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/3] Optimization: check for presence of UPF_EXAR_EFR flag before serial_in
From: Matt Schulte @ 2012-11-20 17:23 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Optimization: check for presence of UPF_EXAR_EFR flag before serial_in
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 1cda869..336d17c 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -913,9 +913,9 @@ static void autoconfig_16550a(struct uart_8250_port *up)
* found at offset 0x09. Instead check the Deice ID (DVID)
* register for a 2, 4 or 8 port UART.
*/
- status1 = serial_in(up, UART_EXAR_DVID);
- if (status1 == 0x82 || status1 == 0x84 || status1 == 0x88) {
- if (up->port.flags & UPF_EXAR_EFR) {
+ if (up->port.flags & UPF_EXAR_EFR) {
+ status1 = serial_in(up, UART_EXAR_DVID);
+ if (status1 == 0x82 || status1 == 0x84 || status1 == 0x88) {
DEBUG_AUTOCONF("Exar XR17V35x ");
up->port.type = PORT_XR17V35X;
up->capabilities |= UART_CAP_AFE | UART_CAP_EFR |
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/3] Add register definitions used in several Exar PCI/PCIe UARTs
From: Matt Schulte @ 2012-11-20 17:21 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Add register definitions used in several Exar PCI/PCIe UARTs
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
include/uapi/linux/serial_reg.h | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index d0b4760..f27aa29 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -368,10 +368,22 @@
#define UART_OMAP_MDR1_DISABLE 0x07 /* Disable (default state) */
/*
- * These are definitions for the XR17V35X and XR17D15X
+ * These are definitions for the Exar XR17V35X and XR17(C|D)15X
*/
+#define UART_EXAR_8XMODE 0x88 /* 8X sampling rate select */
#define UART_EXAR_SLEEP 0x8b /* Sleep mode */
#define UART_EXAR_DVID 0x8d /* Device identification */
+#define UART_EXAR_FCTR 0x08 /* Feature Control Register */
+#define UART_FCTR_EXAR_IRDA 0x08 /* IrDa data encode select */
+#define UART_FCTR_EXAR_485 0x10 /* Auto 485 half duplex dir ctl */
+#define UART_FCTR_EXAR_TRGA 0x00 /* FIFO trigger table A */
+#define UART_FCTR_EXAR_TRGB 0x60 /* FIFO trigger table B */
+#define UART_FCTR_EXAR_TRGC 0x80 /* FIFO trigger table C */
+#define UART_FCTR_EXAR_TRGD 0xc0 /* FIFO trigger table D programmable */
+
+#define UART_EXAR_TXTRG 0x0a /* Tx FIFO trigger level write-only */
+#define UART_EXAR_RXTRG 0x0b /* Rx FIFO trigger level write-only */
+
#endif /* _LINUX_SERIAL_REG_H */
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH 429/493] tty: remove use of __devexit
From: David Brown @ 2012-11-20 17:06 UTC (permalink / raw)
To: Bill Pemberton
Cc: gregkh, Jiri Slaby, Alan Cox, Tobias Klauser, Lucas Tavares,
Daniel Walker, Bryan Huntsman, David S. Miller, Peter Korsgaard,
Tony Prisk, linuxppc-dev, linux-serial, nios2-dev,
uclinux-dist-devel, linux-arm-msm, sparclinux, linux-arm-kernel
In-Reply-To: <1353349642-3677-429-git-send-email-wfp5p@virginia.edu>
On Mon, Nov 19, 2012 at 01:26:18PM -0500, Bill Pemberton wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit is no
> longer needed.
>
> Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
> ---
> drivers/tty/serial/msm_serial.c | 2 +-
> drivers/tty/serial/msm_serial_hs.c | 2 +-
Acked-by: David Brown <davidb@codeaurora.org>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 1/3] OF: Add helper for matching against linux,stdout-path
From: Grant Likely @ 2012-11-20 16:51 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD, Sascha Hauer
Cc: linux-serial, Greg Kroah-Hartman, devicetree-discuss,
linux-kernel, kernel, linux-arm-kernel, Alan Cox
In-Reply-To: <20121119095202.GL4398@game.jcrosoft.org>
On Mon, 19 Nov 2012 10:52:02 +0100, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> wrote:
> On 10:31 Thu 15 Nov , Sascha Hauer wrote:
> > devicetrees may have a linux,stdout-path property in the chosen
> > node describing the console device. This adds a helper function
> > to match a device against this property so a driver can call
> > add_preferred_console for a matching device.
>
> I like it but I've an issue with it I cannot specify the option for
>
> as example I need to set the uart at 38400n8 or 115200n8 regarless of wath the
> booloader did
Right. stdout-path can have a set of arguments appended for things like
serial speed. ePAPR says this about stdout-path:
A string that specifies the full path to the node representing the
device to be used for boot console output. If the character ":" is
present in the value it terminates the path. The value may be an alias.
If the stdin-path property is not specified, stdout-path should be
assumed to define the input device.
So, this function needs to do three more things:
- also look for 'stdout-path' (in addition to 'linux,stdout-path')
- Parse for a ':' in the path and trim that off so it can be used for
arguments. (Bonus: return the arguments to the caller)
- make sure that it can handle the path containing an alias (I've just
not checked if the current code will handle this)
g.
^ permalink raw reply
* [PATCH 2/2] tty/8250 Add XR17D15x devices to the exar_handle_irq override
From: Matt Schulte @ 2012-11-20 16:42 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Add XR17D15x devices to the exar_handle_irq override: they have the
same extra interrupt register that could fire and never be serviced by
the standard handle_irq.
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 44be636..1cda869 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1578,7 +1578,8 @@ static int exar_handle_irq(struct uart_port *port)
ret = serial8250_handle_irq(port, iir);
- if (port->type == PORT_XR17V35X) {
+ if ((port->type == PORT_XR17V35X) ||
+ (port->type == PORT_XR17D15X)) {
int0 = serial_port_in(port, 0x80);
int1 = serial_port_in(port, 0x81);
int2 = serial_port_in(port, 0x82);
@@ -2689,7 +2690,8 @@ static void serial8250_config_port(struct
uart_port *port, int flags)
serial8250_release_std_resource(up);
/* Fixme: probably not the best place for this */
- if (port->type == PORT_XR17V35X)
+ if ((port->type == PORT_XR17V35X) ||
+ (port->type == PORT_XR17D15X))
port->handle_irq = exar_handle_irq;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
From: Matt Schulte @ 2012-11-20 16:32 UTC (permalink / raw)
To: linux-serial; +Cc: Alan Cox, Greg Kroah-Hartman
Add sleep capability to XR17D15X ports
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
[PATCH 1/2] tty/8250: Add sleep capability to XR17D15X ports
Built against tty-next commit: 1e619a1bf9ac878e6a984e4e279ccf712a65bc23
This depends on my previous patch submission:
[PATCH v3] Add support for new devices: Exar's XR17V35x family of
multi-port PCIe UARTs
drivers/tty/serial/8250/8250.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index df7f433..44be636 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -280,7 +280,8 @@ static const struct serial8250_config uart_config[] = {
.fifo_size = 64,
.tx_loadsz = 64,
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
- .flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR,
+ .flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP,
},
[PORT_XR17V35X] = {
.name = "XR17V35X",
@@ -591,7 +592,8 @@ static void serial8250_set_sleep(struct
uart_8250_port *p, int sleep)
* offset but the UART channel may only write to the corresponding
* bit.
*/
- if (p->port.type == PORT_XR17V35X) {
+ if ((p->port.type == PORT_XR17V35X) ||
+ (p->port.type == PORT_XR17D15X)) {
serial_out(p, UART_EXAR_SLEEP, 0xff);
return;
}
@@ -1056,8 +1058,12 @@ static void autoconfig_16550a(struct uart_8250_port *up)
* Exar uarts have EFR in a weird location
*/
if (up->port.flags & UPF_EXAR_EFR) {
+ DEBUG_AUTOCONF("Exar XR17D15x ");
up->port.type = PORT_XR17D15X;
- up->capabilities |= UART_CAP_AFE | UART_CAP_EFR;
+ up->capabilities |= UART_CAP_AFE | UART_CAP_EFR |
+ UART_CAP_SLEEP;
+
+ return;
}
/*
--
1.7.2.5
^ permalink raw reply related
* [PATCH] moxa: dcd handling of CLOCAL is backwards
From: Alan Cox @ 2012-11-20 16:29 UTC (permalink / raw)
To: greg, linux-serial
From: Alan Cox <alan@linux.intel.com>
We should do hangup on dcd loss if CLOCAL is false not true.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=49911
---
drivers/tty/moxa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/moxa.c b/drivers/tty/moxa.c
index 56e616b..9b57aae 100644
--- a/drivers/tty/moxa.c
+++ b/drivers/tty/moxa.c
@@ -1370,7 +1370,7 @@ static void moxa_new_dcdstate(struct moxa_port *p, u8 dcd)
p->DCDState = dcd;
spin_unlock_irqrestore(&p->port.lock, flags);
tty = tty_port_tty_get(&p->port);
- if (tty && C_CLOCAL(tty) && !dcd)
+ if (tty && !C_CLOCAL(tty) && !dcd)
tty_hangup(tty);
tty_kref_put(tty);
}
^ permalink raw reply related
* Re: [PATCH] TTY: serial 8250: Support MCR CLK_SEL bit.
From: Alan Cox @ 2012-11-20 16:23 UTC (permalink / raw)
To: mfuzzey; +Cc: Greg Kroah-Hartman, linux-serial
In-Reply-To: <50AB538F.6030904@parkeon.com>
> This chip is a DUART but the clksel bit, although present for
> both channels, (in MCR bit 7) is actually shared (as is the external
> CLKSEL pin). Hence if the kernel determines whether to enable
> /4 or /1 based on the requested baud rate for one channel it
> may break the baud rate for the other channel.
Gak.
> As a general question how should this type of dependency between
> ports due to them being part of the same chip be handled?
It sounds to me an even bigger reason for having the kernel 8250 termios
code have a ->clock_select() method but you'd need some way to find the
pair of the device. Ok thats uglier. Can you at least define the DT as
setting the *initial* divisor. That way we can later fix the kernel to be
smart about clocks without breaking any assumption about what the DT
entry means.
> So I've just refactored the existing code to share setting this bit -
> this shouldn't change the existing behaviour.
>
> Maybe I should have done this as a seperate patch to make it clearer.
Got it - and yes please make that a separate patch.
> If UART_CAP_EFR is not set but UART_CAP_SLEEP or UART_CAP_CLKSEL is
> set is assumed that it is not necessary to enable access via the EFR
> (whether
> that is a valid combination for any existing UART is another question).
Probably not.
Alan
^ permalink raw reply
* Re: [PATCH] TTY: serial 8250: Support MCR CLK_SEL bit.
From: Martin Fuzzey @ 2012-11-20 9:55 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg Kroah-Hartman, linux-serial
In-Reply-To: <20121119120043.39f59baf@pyramind.ukuu.org.uk>
Thank you for the review.
On 19/11/12 13:00, Alan Cox wrote:
>> * Allows the CLK_SEL bit to be forced to /1, /4 or left as is.
> This seems to be the wrong place to set such stuff. The kernel knows what
> speed is selected and therefore what clock would be best.
>
> Having a clocksel (and probably an of value indicating which type of
> clock sel) is a good thing, but it also ought to be set based on the
> requested baud rate, so a custom set_termios would be better.
I agree that would be nicer, however I think there is a problem,
at least in the case of the xr16c2850.
This chip is a DUART but the clksel bit, although present for
both channels, (in MCR bit 7) is actually shared (as is the external
CLKSEL pin). Hence if the kernel determines whether to enable
/4 or /1 based on the requested baud rate for one channel it
may break the baud rate for the other channel.
This problem also exists with my approach but only to the extent
that if the device tree writer tries to set one channel to /4 and the
other to /1 the result will not be as intended.
As a general question how should this type of dependency between
ports due to them being part of the same chip be handled?
> That would also handle serial console, and suspend/resume without other
> tweaks as far as I can see.
Yes, there may be problems with suspend/resume - I haven't tried yet.
> It also seems some devices use different clksel algorithms so rather than
> a CAP_CLKSEL flag we probably need to key it off the uart type.
>
True,
I've also looked at the NXP SC16C850 and SC16C852 data sheets
and they, in addition to the /4 controlled by MCR:7, also have an
additional 4 bit prescaler register.
They lack the external clksel pin however (which is the main reason
for all this - the normal 16 bit divisor is enough to allow _low_ baud rates
to be reached without enabling any other prescalers - the only case
that is really a problem is when chips that _do_ have the predivisor enabled
in hardware cause us not to be able to attain high baud rates).
I'm not sure if the clock selects are independant for the DUART case,
they appear to be but I don't have the hardware to test it.
>> static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
>> {
>> if (p->capabilities & UART_CAP_SLEEP) {
>> - if (p->capabilities & UART_CAP_EFR) {
>> - serial_out(p, UART_LCR, UART_LCR_CONF_MODE_B);
>> - serial_out(p, UART_EFR, UART_EFR_ECB);
>> - serial_out(p, UART_LCR, 0);
>> - }
>> + serial8250_enable_extended(p);
>> serial_out(p, UART_IER, sleep ? UART_IERX_SLEEP : 0);
> This seems wrong if theere is no EFR
Sorry, I don't understand here.
The same EFR bit needs to be set to enable access to both the SLEEP
and CLKSEL bits.
So I've just refactored the existing code to share setting this bit -
this shouldn't change the existing behaviour.
Maybe I should have done this as a seperate patch to make it clearer.
If UART_CAP_EFR is not set but UART_CAP_SLEEP or UART_CAP_CLKSEL is
set is assumed that it is not necessary to enable access via the EFR
(whether
that is a valid combination for any existing UART is another question).
Regards,
Martin
^ permalink raw reply
* Re: [PATCH 429/493] tty: remove use of __devexit
From: Tobias Klauser @ 2012-11-20 9:45 UTC (permalink / raw)
To: Bill Pemberton
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH, Jiri Slaby,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b, Tony Prisk,
Bryan Huntsman, Peter Korsgaard,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Lucas Tavares,
sparclinux-u79uwXL29TY76Z2rM5mHXA, Daniel Walker, David Brown,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Alan Cox
In-Reply-To: <1353349642-3677-429-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
On 2012-11-19 at 19:26:18 +0100, Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org> wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit is no
> longer needed.
>
> Signed-off-by: Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
> Cc: Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
> Cc: Lucas Tavares <lucaskt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Cc: David Brown <davidb-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Daniel Walker <dwalker-zu3NM2574RrQT0dZR+AlfA@public.gmane.org>
> Cc: Bryan Huntsman <bryanh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>
> Cc: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
> Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH@public.gmane.org
> Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org
> Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> ---
[...]
> drivers/tty/serial/altera_jtaguart.c | 2 +-
> drivers/tty/serial/altera_uart.c | 2 +-
Acked-by: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
^ permalink raw reply
* Re: [PATCH 161/493] tty: remove use of __devinit
From: Tobias Klauser @ 2012-11-20 9:44 UTC (permalink / raw)
To: Bill Pemberton
Cc: gregkh, Jiri Slaby, Alan Cox, Lucas Tavares, David S. Miller,
Peter Korsgaard, Tony Prisk, linuxppc-dev, linux-serial,
nios2-dev, linux-ia64, sparclinux, linux-arm-kernel
In-Reply-To: <1353349642-3677-161-git-send-email-wfp5p@virginia.edu>
On 2012-11-19 at 19:21:50 +0100, Bill Pemberton <wfp5p@virginia.edu> wrote:
> CONFIG_HOTPLUG is going away as an option so __devinit is no longer
> needed.
>
> Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
> Cc: Jiri Slaby <jirislaby@gmail.com>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Tobias Klauser <tklauser@distanz.ch>
> Cc: Lucas Tavares <lucaskt@linux.vnet.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Peter Korsgaard <jacmet@sunsite.dk>
> Cc: Tony Prisk <linux@prisktech.co.nz>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-serial@vger.kernel.org
> Cc: nios2-dev@sopc.et.ntust.edu.tw
> Cc: linux-ia64@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
[...]
> drivers/tty/serial/altera_jtaguart.c | 2 +-
> drivers/tty/serial/altera_uart.c | 2 +-
Acked-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* Re: [PATCH 145/493] tty: serial: remove use of __devexit_p
From: Tobias Klauser @ 2012-11-20 9:44 UTC (permalink / raw)
To: Bill Pemberton
Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b, Tony Prisk,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Lucas Tavares,
sparclinux-u79uwXL29TY76Z2rM5mHXA, Peter Korsgaard,
David S. Miller,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Alan Cox
In-Reply-To: <1353349642-3677-145-git-send-email-wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
On 2012-11-19 at 19:21:34 +0100, Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org> wrote:
> CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
> needed.
>
> Signed-off-by: Bill Pemberton <wfp5p-4Ng6DfrEGID2fBVCVOL8/A@public.gmane.org>
> Cc: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
> Cc: Lucas Tavares <lucaskt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Peter Korsgaard <jacmet-OfajU3CKLf1/SzgSGea1oA@public.gmane.org>
> Cc: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
> Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: nios2-dev-1eJk0qcHJCcaeqlQEoCUNoJY59XmG8rH@public.gmane.org
> Cc: uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org
> Cc: sparclinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> ---
[...]
> drivers/tty/serial/altera_jtaguart.c | 2 +-
> drivers/tty/serial/altera_uart.c | 2 +-
Acked-by: Tobias Klauser <tklauser-93Khv+1bN0NyDzI6CaY1VQ@public.gmane.org>
^ 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