* Re: [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Greg Kroah-Hartman @ 2012-03-29 16:13 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Alan Cox, linux-serial, Yuriy Kozlov
In-Reply-To: <1333007727-24045-1-git-send-email-tklauser@distanz.ch>
On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> From: Yuriy Kozlov <ykozlov@ptcusa.com>
>
> Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
Is this something you have seen in the wild? Is this something to be
backported to stable kernels?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: fix RS485 half-duplex problem
From: Nicolas Ferre @ 2012-03-29 13:40 UTC (permalink / raw)
To: gregkh
Cc: Gabe.Siftar, linux-arm-kernel, linux-serial, plagnioj, linux,
claudio, br, Nicolas Ferre
In-Reply-To: <20120327202628.GB15798@kroah.com>
From: "Siftar, Gabe" <Gabe.Siftar@getingeusa.com>
On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
transmit (our transceiver will receive transmitted data).
Although the current driver attempts to disable and enable the receiver at the
appropriate points, incoming data is still loaded into the receive register
causing our code to receive the very last byte that was sent once the receiver
is enabled.
I ran this by Atmel support and they wrote: "The issue comes from the fact
that you disable the PDC/DMA Reception and not the USART Reception channel. In
your case, the[n] you will still receive data into the USART_RHR register, and
maybe you [h]ave the overrun flag set. So please disable the USART reception
channel."
The following patch should force the driver to enable/disable the receiver via
RXEN/RXDIS fields of the USART control register. It fixed the issue I was
having.
Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com>
[nicolas.ferre@atmel.com: slightly modify commit message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Greg,
Here is an updated version of the patch that you received from Gabe. I have
removed a superfluous tab in empty line, remove commit message non needed parts
and added my "Signed-off-by" line.
Feel free to queue this version for 3.4-rc.
Thanks, best regards,
Nicolas
drivers/tty/serial/atmel_serial.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 10605ec..bc3cece 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -389,6 +389,8 @@ static void atmel_start_rx(struct uart_port *port)
{
UART_PUT_CR(port, ATMEL_US_RSTSTA); /* reset status and receiver */
+ UART_PUT_CR(port, ATMEL_US_RXEN);
+
if (atmel_use_dma_rx(port)) {
/* enable PDC controller */
UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -404,6 +406,8 @@ static void atmel_start_rx(struct uart_port *port)
*/
static void atmel_stop_rx(struct uart_port *port)
{
+ UART_PUT_CR(port, ATMEL_US_RXDIS);
+
if (atmel_use_dma_rx(port)) {
/* disable PDC receive */
UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
--
1.7.9.4
^ permalink raw reply related
* [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Tobias Klauser @ 2012-03-29 7:55 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman; +Cc: linux-serial, Yuriy Kozlov
From: Yuriy Kozlov <ykozlov@ptcusa.com>
Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
Signed-off-by: Yuriy Kozlov <ykozlov@ptcusa.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/tty/serial/altera_uart.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/altera_uart.c b/drivers/tty/serial/altera_uart.c
index e790375..1f03309 100644
--- a/drivers/tty/serial/altera_uart.c
+++ b/drivers/tty/serial/altera_uart.c
@@ -556,7 +556,7 @@ static int __devinit altera_uart_probe(struct platform_device *pdev)
res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res_mem)
port->mapbase = res_mem->start;
- else if (platp->mapbase)
+ else if (platp)
port->mapbase = platp->mapbase;
else
return -EINVAL;
@@ -564,7 +564,7 @@ static int __devinit altera_uart_probe(struct platform_device *pdev)
res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res_irq)
port->irq = res_irq->start;
- else if (platp->irq)
+ else if (platp)
port->irq = platp->irq;
/* Check platform data first so we can override device node data */
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Raja, Govindraj @ 2012-03-29 7:35 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-omap, Kevin Hilman, Paul Walmsley, Felipe Balbi,
linux-serial, linux-arm-kernel
In-Reply-To: <4F733FC4.9010506@ti.com>
On Wed, Mar 28, 2012 at 10:13 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> Hi Govindraj,
>
>
> On 3/28/2012 6:09, Raja, Govindraj wrote:
>>
>> On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter<jon-hunter@ti.com> wrote:
>>>
>>> Hi Govindraj,
>>>
>>>
[...]
>>>> + u32 mvr, scheme;
>>>> + u16 revision, major, minor;
>>>> +
>>>> + mvr = serial_in(up, UART_OMAP_MVER);
>>>> +
>>>> + /* Check revision register scheme */
>>>> + scheme = mvr& (0x03<< 30);
>>>> + scheme>>= 30;
>>>
>>>
>>>
>>> Minor nit-pick, why not ...
>>>
>>> scheme = mvr>> 30;
>>>
>>
>> yes will correct it.
>
>
> Thinking some more, could be better to add some #defines for
> OMAP_MVR_VERSION_MASK/SHIFT here.
>
Yes sure.
>
>>>
>>>> + switch (scheme) {
>>>> + case 0: /* Legacy Scheme: OMAP2/3 */
>>>> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
>>>
>>>
>>>
>>> This scheme is also true from OMAP1 devices. Maybe we could include in
>>> the
>>> comment.
>>
>>
>> No omap1 from $SUBJECT also reason,
>>
>> mach-omap1/serial.c => 8250.c
>> mach-omap2/serial.c => omap-serial.c
>
>
> Got it! Thanks.
>
>>>> + major = (mvr& 0xf0)>> 4;
>>>> + minor = (mvr& 0x0f);
>>>>
>>>> + break;
>>>> + case 1:
>>>> + /* New Scheme: OMAP4+ */
>>>> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
>>>> + major = (mvr& 0x7<< 8)>> 8;
>>>
>>>
>>>
>>> Nit-pick ...
>>>
>>> major = (mvr>> 8)& 0x7;
>>
>>
>> yes fine will correct this.
>
>
> May be we should add #defines here to for OMAP_UART_MVR1_MAJ_MASK/SHIFT,
> OMAP_UART_MVR1_MIN_MASK/SHIFT, OMAP_UART_MVR2_MAJ_MASK/SHIFT and
> OMAP_UART_MVR2_MIN_MASK/SHIFT.
>
okay will add this.
--
Thanks,
Govindraj.R
--
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] staging: evict abandoned 68360serial.c driver from 3.4
From: Paul Gortmaker @ 2012-03-28 17:02 UTC (permalink / raw)
To: Greg KH; +Cc: linux-serial, Jiri Slaby, Geert Uytterhoeven, Alan Cox
In-Reply-To: <20120328150528.GD19862@kroah.com>
On 12-03-28 11:05 AM, Greg KH wrote:
> On Tue, Mar 27, 2012 at 07:07:11PM -0400, Paul Gortmaker wrote:
>> commit 3a0db7215c88077b61a673215756ec4a0dc0c7a5
>>
>> "TTY: serial, move 68360 driver to staging"
>>
>> did so because the driver had remained broken since 2008. It also
>> added this text to the TODO file:
>>
>> "If no one steps up to adopt any of these drivers, they will
>> be removed in the 3.4 release."
>>
>> A quick search on the internet doesn't reveal anyone actively
>> trying to update/fix this driver, so follow through on the above
>> and remove it from the pending 3.4 release.
>>
>> Cc: Jiri Slaby <jslaby@suse.cz>
>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
>> Cc: Alan Cox <alan@linux.intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Thanks for this, but as I missed the merge window for 3.4, I'll queue it
> up for 3.5 just to be safe.
Thanks Greg,
I only happened to stumble upon it last night or I would have
sent it earlier. No harm in it sitting there another release.
Feel free to prune the "from 3.4" off the end of the shortlog.
Paul.
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Jon Hunter @ 2012-03-28 16:43 UTC (permalink / raw)
To: Raja, Govindraj
Cc: linux-omap, Kevin Hilman, Paul Walmsley, Felipe Balbi,
linux-serial, linux-arm-kernel
In-Reply-To: <CAMrsUdKfsoks4fB4GhrRcEur8niJsaWuYGE34+j5Bk6u2XiZQQ@mail.gmail.com>
Hi Govindraj,
On 3/28/2012 6:09, Raja, Govindraj wrote:
> On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter<jon-hunter@ti.com> wrote:
>> Hi Govindraj,
>>
>>
>> On 3/21/2012 5:24, Govindraj.R wrote:
>>>
>>> From: "Govindraj.R"<govindraj.raja@ti.com>
>>>
>>> Currently the errata is populated based on cpu checks this can
>>> be removed and replaced with module version check of uart ip block.
>>> MVR reg is provided within the uart reg map use the same
>>> to populate the errata and thus now errata population and handling
>>> can be managed within the driver itself.
>>>
>>> Cc: Paul Walmsley<paul@pwsan.com>
>>> Cc: Kevin Hilman<khilman@ti.com>
>>> Signed-off-by: Felipe Balbi<balbi@ti.com>
>>> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
>>> ---
>>> arch/arm/mach-omap2/serial.c | 8 ---
>>> arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
>>> drivers/tty/serial/omap-serial.c | 62
>>> ++++++++++++++++++++++++-
>>> 3 files changed, 61 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>>> index f590afc..330ee04 100644
>>> --- a/arch/arm/mach-omap2/serial.c
>>> +++ b/arch/arm/mach-omap2/serial.c
>>> @@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct
>>> omap_board_data *bdata,
>>> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
>>> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>>>
>>> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
>>> - if (!cpu_is_omap2420()&& !cpu_is_ti816x())
>>>
>>> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
>>> -
>>> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
>>> - if (cpu_is_omap34xx() || cpu_is_omap3630())
>>> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
>>> -
>>> pdata =&omap_up;
>>> pdata_size = sizeof(struct omap_uart_port_info);
>>>
>>> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
>>> b/arch/arm/plat-omap/include/plat/omap-serial.h
>>> index 9ff4444..1a52725 100644
>>> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
>>> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
>>> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
>>> bool dma_enabled; /* To specify DMA Mode */
>>> unsigned int uartclk; /* UART clock rate */
>>> upf_t flags; /* UPF_* flags */
>>> - u32 errata;
>>> unsigned int dma_rx_buf_size;
>>> unsigned int dma_rx_timeout;
>>> unsigned int autosuspend_timeout;
>>> diff --git a/drivers/tty/serial/omap-serial.c
>>> b/drivers/tty/serial/omap-serial.c
>>> index f809041..c7666d6 100644
>>> --- a/drivers/tty/serial/omap-serial.c
>>> +++ b/drivers/tty/serial/omap-serial.c
>>> @@ -44,6 +44,13 @@
>>> #include<plat/dmtimer.h>
>>> #include<plat/omap-serial.h>
>>>
>>> +#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
>>> +
>>> +#define OMAP_UART_REV_42 0x0402
>>> +#define OMAP_UART_REV_46 0x0406
>>> +#define OMAP_UART_REV_52 0x0502
>>> +#define OMAP_UART_REV_63 0x0603
>>> +
>>> #define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
>>>
>>> /* SCR register bitmasks */
>>> @@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16
>>> ch_status, void *data)
>>> return;
>>> }
>>>
>>> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
>>> +{
>>> + u32 mvr, scheme;
>>> + u16 revision, major, minor;
>>> +
>>> + mvr = serial_in(up, UART_OMAP_MVER);
>>> +
>>> + /* Check revision register scheme */
>>> + scheme = mvr& (0x03<< 30);
>>> + scheme>>= 30;
>>
>>
>> Minor nit-pick, why not ...
>>
>> scheme = mvr>> 30;
>>
>
> yes will correct it.
Thinking some more, could be better to add some #defines for
OMAP_MVR_VERSION_MASK/SHIFT here.
>>
>>> + switch (scheme) {
>>> + case 0: /* Legacy Scheme: OMAP2/3 */
>>> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
>>
>>
>> This scheme is also true from OMAP1 devices. Maybe we could include in the
>> comment.
>
> No omap1 from $SUBJECT also reason,
>
> mach-omap1/serial.c => 8250.c
> mach-omap2/serial.c => omap-serial.c
Got it! Thanks.
>>> + major = (mvr& 0xf0)>> 4;
>>> + minor = (mvr& 0x0f);
>>>
>>> + break;
>>> + case 1:
>>> + /* New Scheme: OMAP4+ */
>>> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
>>> + major = (mvr& 0x7<< 8)>> 8;
>>
>>
>> Nit-pick ...
>>
>> major = (mvr>> 8)& 0x7;
>
> yes fine will correct this.
May be we should add #defines here to for OMAP_UART_MVR1_MAJ_MASK/SHIFT,
OMAP_UART_MVR1_MIN_MASK/SHIFT, OMAP_UART_MVR2_MAJ_MASK/SHIFT and
OMAP_UART_MVR2_MIN_MASK/SHIFT.
Jon
^ permalink raw reply
* Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Jon Hunter @ 2012-03-27 21:03 UTC (permalink / raw)
To: Govindraj.R
Cc: linux-omap, Kevin Hilman, Paul Walmsley, Felipe Balbi,
linux-serial, linux-arm-kernel
In-Reply-To: <1332325501-10467-2-git-send-email-govindraj.raja@ti.com>
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
> From: "Govindraj.R"<govindraj.raja@ti.com>
>
> Currently the errata is populated based on cpu checks this can
> be removed and replaced with module version check of uart ip block.
> MVR reg is provided within the uart reg map use the same
> to populate the errata and thus now errata population and handling
> can be managed within the driver itself.
>
> Cc: Paul Walmsley<paul@pwsan.com>
> Cc: Kevin Hilman<khilman@ti.com>
> Signed-off-by: Felipe Balbi<balbi@ti.com>
> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 8 ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
> drivers/tty/serial/omap-serial.c | 62 ++++++++++++++++++++++++-
> 3 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index f590afc..330ee04 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>
> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
> - if (!cpu_is_omap2420()&& !cpu_is_ti816x())
> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
> -
> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
> - if (cpu_is_omap34xx() || cpu_is_omap3630())
> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
> -
> pdata =&omap_up;
> pdata_size = sizeof(struct omap_uart_port_info);
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 9ff4444..1a52725 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
> bool dma_enabled; /* To specify DMA Mode */
> unsigned int uartclk; /* UART clock rate */
> upf_t flags; /* UPF_* flags */
> - u32 errata;
> unsigned int dma_rx_buf_size;
> unsigned int dma_rx_timeout;
> unsigned int autosuspend_timeout;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index f809041..c7666d6 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -44,6 +44,13 @@
> #include<plat/dmtimer.h>
> #include<plat/omap-serial.h>
>
> +#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
> +
> +#define OMAP_UART_REV_42 0x0402
> +#define OMAP_UART_REV_46 0x0406
> +#define OMAP_UART_REV_52 0x0502
> +#define OMAP_UART_REV_63 0x0603
> +
> #define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
>
> /* SCR register bitmasks */
> @@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)
> return;
> }
>
> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
> +{
> + u32 mvr, scheme;
> + u16 revision, major, minor;
> +
> + mvr = serial_in(up, UART_OMAP_MVER);
> +
> + /* Check revision register scheme */
> + scheme = mvr& (0x03<< 30);
> + scheme>>= 30;
Minor nit-pick, why not just ...
scheme = mvr >> 30;
> + switch (scheme) {
> + case 0: /* Legacy Scheme: OMAP2/3 */
> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
Same scheme applies to OMAP1 devices too. So maybe we should include in
the comment.
> + major = (mvr& 0xf0)>> 4;
> + minor = (mvr& 0x0f);
> + break;
> + case 1:
> + /* New Scheme: OMAP4+ */
> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
> + major = (mvr& 0x7<< 8)>> 8;
Nit-pick ...
major = (mvr >> 8) & 0x7;
> + minor = (mvr& 0x3f);
> + break;
> + default:
> + dev_warn(&up->pdev->dev,
> + "Unknown %s revision, defaulting to highest\n",
> + up->name);
> + /* highest possible revision */
> + major = 0xff;
> + minor = 0xff;
> + }
> +
> + /* normalize revision for the driver */
> + revision = UART_BUILD_REVISION(major, minor);
> +
> + switch (revision) {
> + case OMAP_UART_REV_46:
> + up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
> + UART_ERRATA_i291_DMA_FORCEIDLE);
> + break;
> + case OMAP_UART_REV_52:
> + up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
> + UART_ERRATA_i291_DMA_FORCEIDLE);
> + break;
> + case OMAP_UART_REV_63:
> + up->errata |= UART_ERRATA_i202_MDR1_ACCESS;
> + break;
> + default:
> + break;
> + }
Should we also warn on an unknown revision?
> +}
> +
> static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
> {
> struct omap_uart_port_info *omap_up_info;
> @@ -1443,7 +1502,6 @@ static int serial_omap_probe(struct platform_device *pdev)
> "%d\n", DEFAULT_CLK_SPEED);
> }
> up->uart_dma.uart_base = mem->start;
> - up->errata = omap_up_info->errata;
>
> if (omap_up_info->dma_enabled) {
> up->uart_dma.uart_dma_tx = dma_tx->start;
> @@ -1473,6 +1531,8 @@ static int serial_omap_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
> pm_runtime_get_sync(&pdev->dev);
>
> + omap_serial_fill_features_erratas(up);
> +
> ui[up->port.line] = up;
> serial_omap_add_console_port(up);
>
^ permalink raw reply
* Re: [PATCH] staging: evict abandoned 68360serial.c driver from 3.4
From: Greg KH @ 2012-03-28 15:05 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-serial, Jiri Slaby, Geert Uytterhoeven, Alan Cox
In-Reply-To: <1332889631-21316-1-git-send-email-paul.gortmaker@windriver.com>
On Tue, Mar 27, 2012 at 07:07:11PM -0400, Paul Gortmaker wrote:
> commit 3a0db7215c88077b61a673215756ec4a0dc0c7a5
>
> "TTY: serial, move 68360 driver to staging"
>
> did so because the driver had remained broken since 2008. It also
> added this text to the TODO file:
>
> "If no one steps up to adopt any of these drivers, they will
> be removed in the 3.4 release."
>
> A quick search on the internet doesn't reveal anyone actively
> trying to update/fix this driver, so follow through on the above
> and remove it from the pending 3.4 release.
>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Thanks for this, but as I missed the merge window for 3.4, I'll queue it
up for 3.5 just to be safe.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Raja, Govindraj @ 2012-03-28 11:09 UTC (permalink / raw)
To: Jon Hunter
Cc: linux-omap, Kevin Hilman, Paul Walmsley, Felipe Balbi,
linux-serial, linux-arm-kernel
In-Reply-To: <4F722C63.9080900@ti.com>
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter <jon-hunter@ti.com> wrote:
> Hi Govindraj,
>
>
> On 3/21/2012 5:24, Govindraj.R wrote:
>>
>> From: "Govindraj.R"<govindraj.raja@ti.com>
>>
>> Currently the errata is populated based on cpu checks this can
>> be removed and replaced with module version check of uart ip block.
>> MVR reg is provided within the uart reg map use the same
>> to populate the errata and thus now errata population and handling
>> can be managed within the driver itself.
>>
>> Cc: Paul Walmsley<paul@pwsan.com>
>> Cc: Kevin Hilman<khilman@ti.com>
>> Signed-off-by: Felipe Balbi<balbi@ti.com>
>> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
>> ---
>> arch/arm/mach-omap2/serial.c | 8 ---
>> arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
>> drivers/tty/serial/omap-serial.c | 62
>> ++++++++++++++++++++++++-
>> 3 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>> index f590afc..330ee04 100644
>> --- a/arch/arm/mach-omap2/serial.c
>> +++ b/arch/arm/mach-omap2/serial.c
>> @@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct
>> omap_board_data *bdata,
>> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
>> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>>
>> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
>> - if (!cpu_is_omap2420()&& !cpu_is_ti816x())
>>
>> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
>> -
>> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
>> - if (cpu_is_omap34xx() || cpu_is_omap3630())
>> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
>> -
>> pdata =&omap_up;
>> pdata_size = sizeof(struct omap_uart_port_info);
>>
>> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
>> b/arch/arm/plat-omap/include/plat/omap-serial.h
>> index 9ff4444..1a52725 100644
>> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
>> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
>> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
>> bool dma_enabled; /* To specify DMA Mode */
>> unsigned int uartclk; /* UART clock rate */
>> upf_t flags; /* UPF_* flags */
>> - u32 errata;
>> unsigned int dma_rx_buf_size;
>> unsigned int dma_rx_timeout;
>> unsigned int autosuspend_timeout;
>> diff --git a/drivers/tty/serial/omap-serial.c
>> b/drivers/tty/serial/omap-serial.c
>> index f809041..c7666d6 100644
>> --- a/drivers/tty/serial/omap-serial.c
>> +++ b/drivers/tty/serial/omap-serial.c
>> @@ -44,6 +44,13 @@
>> #include<plat/dmtimer.h>
>> #include<plat/omap-serial.h>
>>
>> +#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
>> +
>> +#define OMAP_UART_REV_42 0x0402
>> +#define OMAP_UART_REV_46 0x0406
>> +#define OMAP_UART_REV_52 0x0502
>> +#define OMAP_UART_REV_63 0x0603
>> +
>> #define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
>>
>> /* SCR register bitmasks */
>> @@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16
>> ch_status, void *data)
>> return;
>> }
>>
>> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
>> +{
>> + u32 mvr, scheme;
>> + u16 revision, major, minor;
>> +
>> + mvr = serial_in(up, UART_OMAP_MVER);
>> +
>> + /* Check revision register scheme */
>> + scheme = mvr& (0x03<< 30);
>> + scheme>>= 30;
>
>
> Minor nit-pick, why not ...
>
> scheme = mvr >> 30;
>
yes will correct it.
>
>> + switch (scheme) {
>> + case 0: /* Legacy Scheme: OMAP2/3 */
>> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
>
>
> This scheme is also true from OMAP1 devices. Maybe we could include in the
> comment.
No omap1 from $SUBJECT also reason,
mach-omap1/serial.c => 8250.c
mach-omap2/serial.c => omap-serial.c
>
>> + major = (mvr& 0xf0)>> 4;
>> + minor = (mvr& 0x0f);
>>
>> + break;
>> + case 1:
>> + /* New Scheme: OMAP4+ */
>> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
>> + major = (mvr& 0x7<< 8)>> 8;
>
>
> Nit-pick ...
>
> major = (mvr >> 8) & 0x7;
yes fine will correct this.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] staging: evict abandoned 68360serial.c driver from 3.4
From: Geert Uytterhoeven @ 2012-03-28 7:31 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: gregkh, linux-serial, Jiri Slaby, Alan Cox, Greg Ungerer
In-Reply-To: <1332889631-21316-1-git-send-email-paul.gortmaker@windriver.com>
CC added.
m68k and m68knommu got merged, but Greg still handles the nommu
and coldfire parts.
On Wed, Mar 28, 2012 at 01:07, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> commit 3a0db7215c88077b61a673215756ec4a0dc0c7a5
>
> "TTY: serial, move 68360 driver to staging"
>
> did so because the driver had remained broken since 2008. It also
> added this text to the TODO file:
>
> "If no one steps up to adopt any of these drivers, they will
> be removed in the 3.4 release."
>
> A quick search on the internet doesn't reveal anyone actively
> trying to update/fix this driver, so follow through on the above
> and remove it from the pending 3.4 release.
>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [ commit 3a0db72 was present in v3.2 in case people were wondering.
> Geert - I know you'd said "uClinux" wrt. 3a0db72, but I left you
> on the CC since the CONFIG_M68360 dependency comes from m68k. ]
>
> drivers/staging/Kconfig | 2 -
> drivers/staging/Makefile | 1 -
> drivers/staging/serial/68360serial.c | 2979 ----------------------------------
> drivers/staging/serial/Kconfig | 16 -
> drivers/staging/serial/Makefile | 1 -
> drivers/staging/serial/TODO | 6 -
> 6 files changed, 0 insertions(+), 3005 deletions(-)
> delete mode 100644 drivers/staging/serial/68360serial.c
> delete mode 100644 drivers/staging/serial/Kconfig
> delete mode 100644 drivers/staging/serial/Makefile
> delete mode 100644 drivers/staging/serial/TODO
>
> diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
> index 97d412d..4c99b4c 100644
> --- a/drivers/staging/Kconfig
> +++ b/drivers/staging/Kconfig
> @@ -24,8 +24,6 @@ menuconfig STAGING
>
> if STAGING
>
> -source "drivers/staging/serial/Kconfig"
> -
> source "drivers/staging/et131x/Kconfig"
>
> source "drivers/staging/slicoss/Kconfig"
> diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
> index ffe7d44..74662ce 100644
> --- a/drivers/staging/Makefile
> +++ b/drivers/staging/Makefile
> @@ -3,7 +3,6 @@
> # fix for build system bug...
> obj-$(CONFIG_STAGING) += staging.o
>
> -obj-y += serial/
> obj-y += media/
> obj-$(CONFIG_ET131X) += et131x/
> obj-$(CONFIG_SLICOSS) += slicoss/
> diff --git a/drivers/staging/serial/68360serial.c b/drivers/staging/serial/68360serial.c
> deleted file mode 100644
> index daf0b1d..0000000
> diff --git a/drivers/staging/serial/Kconfig b/drivers/staging/serial/Kconfig
> deleted file mode 100644
> index 9489688..0000000
> diff --git a/drivers/staging/serial/Makefile b/drivers/staging/serial/Makefile
> deleted file mode 100644
> index 37a6a0b..0000000
> diff --git a/drivers/staging/serial/TODO b/drivers/staging/serial/TODO
> deleted file mode 100644
> index a19cda8..0000000
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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] sh-sci: fix a race of DMA submit_tx on transfer
From: Paul Mundt @ 2012-03-28 6:11 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Takashi Yoshii, SH-Linux, linux-serial
In-Reply-To: <Pine.LNX.4.64.1203151127030.2988@axis700.grange>
On Thu, Mar 15, 2012 at 11:50:28AM +0100, Guennadi Liakhovetski wrote:
> On Thu, 15 Mar 2012, Paul Mundt wrote:
> > Looks good to me. I'll apply it unless Guennadi has any other concerns.
>
> No, I don't - my ack holds:) However, I do have some concerns regarding a
> couple of other possible issues with SCI DMA:
>
Ok, I've queued it up now (it was too late for -final, so we'll have to
rely on the stable backport later).
> 1. As I mentioned earlier, I think, sci_start_tx() should always be called
> under the port spinlock to get consistent ->cookie_tx and ->chan_tx
> values. This is the case, when called from serial core as
> ->start_tx() from most locations, but not from uart_handle_cts_change(),
> which is an exported function. It is also called internally in the SCI
> driver itself several times - with no locking. This might need fixing,
> especially in sci_tx_dma_release().
>
The bulk of the uart_handle_cts_change() callers do so with the lock
held, the only exception seems to be a few drivers that call it directly
from their interrupt handlers.
At first glance, the sci_tx/rx_dma_release() cases will probably need a
bit of reordering given that dma_release_channel() is taking a list
mutex, but I don't see too many issues otherwise. Having said that,
the whole DMA enable/disable path could probably be split up a bit with
individual toggle logic pushed down in to ->start/stop_tx as well as
->stop_rx for some finer-grained control. This would at least help make
the locking a bit more obvious.
> 2. The DMA Tx work might need to be cancelled from time to time... E.g.,
> when DMA is disabled to switch to PIO, or when shutting down the port.
>
Yes, this is something that needs to be done. I've tried to use the
driver as a module before in the past, and it does blow up rather
spectacularly in the remove case, this is hardly limited to the DMA
case though (and is also not a configuration most people are going to
ever really use, which is why we've largely ignored it thus far). The
PIO<->DMA transition on the other hand we're far more likely to hit,
especially if we end up exposing something like a userspace knob for
enabling/disabling arbitrarily for testing.
Most of the DMA cancelling looks it should be pretty easy to do via
->flush_buffer, unless I'm missing something. The amba-pl011.c driver
does just this for the dmaengine case.
^ permalink raw reply
* Hello
From: laurarey111 @ 2012-03-27 13:30 UTC (permalink / raw)
Hello xxxxx,
How are you doing over there? My name is Laura, Please let
me know if i got the right address so we can open
communication, here is my email address I am waiting for
your confirmation with care Laura...
^ permalink raw reply
* [PATCH] staging: evict abandoned 68360serial.c driver from 3.4
From: Paul Gortmaker @ 2012-03-27 23:07 UTC (permalink / raw)
To: gregkh
Cc: linux-serial, Paul Gortmaker, Jiri Slaby, Geert Uytterhoeven,
Alan Cox
commit 3a0db7215c88077b61a673215756ec4a0dc0c7a5
"TTY: serial, move 68360 driver to staging"
did so because the driver had remained broken since 2008. It also
added this text to the TODO file:
"If no one steps up to adopt any of these drivers, they will
be removed in the 3.4 release."
A quick search on the internet doesn't reveal anyone actively
trying to update/fix this driver, so follow through on the above
and remove it from the pending 3.4 release.
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[ commit 3a0db72 was present in v3.2 in case people were wondering.
Geert - I know you'd said "uClinux" wrt. 3a0db72, but I left you
on the CC since the CONFIG_M68360 dependency comes from m68k. ]
drivers/staging/Kconfig | 2 -
drivers/staging/Makefile | 1 -
drivers/staging/serial/68360serial.c | 2979 ----------------------------------
drivers/staging/serial/Kconfig | 16 -
drivers/staging/serial/Makefile | 1 -
drivers/staging/serial/TODO | 6 -
6 files changed, 0 insertions(+), 3005 deletions(-)
delete mode 100644 drivers/staging/serial/68360serial.c
delete mode 100644 drivers/staging/serial/Kconfig
delete mode 100644 drivers/staging/serial/Makefile
delete mode 100644 drivers/staging/serial/TODO
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 97d412d..4c99b4c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -24,8 +24,6 @@ menuconfig STAGING
if STAGING
-source "drivers/staging/serial/Kconfig"
-
source "drivers/staging/et131x/Kconfig"
source "drivers/staging/slicoss/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index ffe7d44..74662ce 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -3,7 +3,6 @@
# fix for build system bug...
obj-$(CONFIG_STAGING) += staging.o
-obj-y += serial/
obj-y += media/
obj-$(CONFIG_ET131X) += et131x/
obj-$(CONFIG_SLICOSS) += slicoss/
diff --git a/drivers/staging/serial/68360serial.c b/drivers/staging/serial/68360serial.c
deleted file mode 100644
index daf0b1d..0000000
diff --git a/drivers/staging/serial/Kconfig b/drivers/staging/serial/Kconfig
deleted file mode 100644
index 9489688..0000000
diff --git a/drivers/staging/serial/Makefile b/drivers/staging/serial/Makefile
deleted file mode 100644
index 37a6a0b..0000000
diff --git a/drivers/staging/serial/TODO b/drivers/staging/serial/TODO
deleted file mode 100644
index a19cda8..0000000
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Jon Hunter @ 2012-03-27 21:08 UTC (permalink / raw)
To: Govindraj.R
Cc: linux-omap, Kevin Hilman, Paul Walmsley, Felipe Balbi,
linux-serial, linux-arm-kernel
In-Reply-To: <1332325501-10467-2-git-send-email-govindraj.raja@ti.com>
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
> From: "Govindraj.R"<govindraj.raja@ti.com>
>
> Currently the errata is populated based on cpu checks this can
> be removed and replaced with module version check of uart ip block.
> MVR reg is provided within the uart reg map use the same
> to populate the errata and thus now errata population and handling
> can be managed within the driver itself.
>
> Cc: Paul Walmsley<paul@pwsan.com>
> Cc: Kevin Hilman<khilman@ti.com>
> Signed-off-by: Felipe Balbi<balbi@ti.com>
> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 8 ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
> drivers/tty/serial/omap-serial.c | 62 ++++++++++++++++++++++++-
> 3 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index f590afc..330ee04 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>
> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
> - if (!cpu_is_omap2420()&& !cpu_is_ti816x())
> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
> -
> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
> - if (cpu_is_omap34xx() || cpu_is_omap3630())
> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
> -
> pdata =&omap_up;
> pdata_size = sizeof(struct omap_uart_port_info);
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 9ff4444..1a52725 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
> bool dma_enabled; /* To specify DMA Mode */
> unsigned int uartclk; /* UART clock rate */
> upf_t flags; /* UPF_* flags */
> - u32 errata;
> unsigned int dma_rx_buf_size;
> unsigned int dma_rx_timeout;
> unsigned int autosuspend_timeout;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index f809041..c7666d6 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -44,6 +44,13 @@
> #include<plat/dmtimer.h>
> #include<plat/omap-serial.h>
>
> +#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
> +
> +#define OMAP_UART_REV_42 0x0402
> +#define OMAP_UART_REV_46 0x0406
> +#define OMAP_UART_REV_52 0x0502
> +#define OMAP_UART_REV_63 0x0603
> +
> #define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
>
> /* SCR register bitmasks */
> @@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)
> return;
> }
>
> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
> +{
> + u32 mvr, scheme;
> + u16 revision, major, minor;
> +
> + mvr = serial_in(up, UART_OMAP_MVER);
> +
> + /* Check revision register scheme */
> + scheme = mvr& (0x03<< 30);
> + scheme>>= 30;
Minor nit-pick, why not ...
scheme = mvr >> 30;
> + switch (scheme) {
> + case 0: /* Legacy Scheme: OMAP2/3 */
> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
This scheme is also true from OMAP1 devices. Maybe we could include in
the comment.
> + major = (mvr& 0xf0)>> 4;
> + minor = (mvr& 0x0f);
> + break;
> + case 1:
> + /* New Scheme: OMAP4+ */
> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
> + major = (mvr& 0x7<< 8)>> 8;
Nit-pick ...
major = (mvr >> 8) & 0x7;
Cheers
Jon
^ permalink raw reply
* Partnership
From: Ling Tia Liu @ 2012-03-27 20:24 UTC (permalink / raw)
Good Day, My name is Ling Tia Liu, I have a $17.3M business proposal from
my bank for you to handle with me. Reply for more info
^ permalink raw reply
* Re: [PATCH] atmel-serial: fix RS485 half-duplex problem
From: Greg KH @ 2012-03-27 20:26 UTC (permalink / raw)
To: Siftar, Gabe
Cc: linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, Andrew Victor, Nicolas Ferre,
Jean-Christophe PLAGNIOL-VILLARD, Claudio Scordino, Bernhard Roth
In-Reply-To: <6FF0F449D45DEE479E93D93A0C07A8BD025E9F8D47@USROCEX01>
On Tue, Mar 27, 2012 at 04:20:51PM -0400, Siftar, Gabe wrote:
> >From: Greg KH [mailto:gregkh@linuxfoundation.org]
> >Sent: Tuesday, March 27, 2012 1:55 PM
> >Care to resend this without the footer so I can accept it?
>
> Sorry. It turns out that the footer was added by our 3rd party email
> filtering service - I hope that it's no longer being included.
Looks good, thanks, I'll queue this up once 3.4-rc1 is out.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] atmel-serial: fix RS485 half-duplex problem
From: Siftar, Gabe @ 2012-03-27 20:20 UTC (permalink / raw)
To: Greg KH
Cc: linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, Andrew Victor, Nicolas Ferre,
Jean-Christophe PLAGNIOL-VILLARD, Claudio Scordino, Bernhard Roth
In-Reply-To: <20120327175433.GA6623@kroah.com>
>From: Greg KH [mailto:gregkh@linuxfoundation.org]
>Sent: Tuesday, March 27, 2012 1:55 PM
>Care to resend this without the footer so I can accept it?
Sorry. It turns out that the footer was added by our 3rd party email
filtering service - I hope that it's no longer being included.
On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
transmit (our transceiver will receive transmitted data). Although the current
driver attempts to disable and enable the receiver at the appropriate points,
incoming data is still loaded into the receive register causing our code to
receive the very last byte that was sent once the receiver is enabled.
I ran this by Atmel support and they wrote: "The issue comes from the fact
that you disable the PDC/DMA Reception and not the USART Reception channel. In
your case, the[n] you will still receive data into the USART_RHR register, and
maybe you [h]ave the overun flag set. So please disable the USART reception
channel."
The following patch should force the driver to enable/disable the receiver via
RXEN/RXDIS fields of the USART control register. It fixed the issue I was
having - perhaps others will find it useful as well.
Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com>
Index: linux-3.3/drivers/tty/serial/atmel_serial.c
===================================================================
--- linux-3.3.orig/drivers/tty/serial/atmel_serial.c
+++ linux-3.3/drivers/tty/serial/atmel_serial.c
@@ -395,6 +395,8 @@
{
UART_PUT_CR(port, ATMEL_US_RSTSTA); /* reset status and receiver */
+ UART_PUT_CR(port, ATMEL_US_RXEN);
+
if (atmel_use_dma_rx(port)) {
/* enable PDC controller */
UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -410,6 +412,8 @@
*/
static void atmel_stop_rx(struct uart_port *port)
{
+ UART_PUT_CR(port, ATMEL_US_RXDIS);
+
if (atmel_use_dma_rx(port)) {
/* disable PDC receive */
UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
^ permalink raw reply
* Re: [PATCH] atmel-serial: fix RS485 half-duplex problem
From: Greg KH @ 2012-03-27 17:54 UTC (permalink / raw)
To: Siftar, Gabe
Cc: linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org, Andrew Victor, Nicolas Ferre,
Jean-Christophe PLAGNIOL-VILLARD, Claudio Scordino, Bernhard Roth
In-Reply-To: <6FF0F449D45DEE479E93D93A0C07A8BD025E8F0631@USROCEX01>
On Tue, Mar 27, 2012 at 01:43:39PM -0400, Siftar, Gabe wrote:
> On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
> SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
> transmit (our transceiver will receive transmitted data). Although the current
> driver attempts to disable and enable the receiver at the appropriate points,
> incoming data is still loaded into the receive register causing our code to
> receive the very last byte that was sent once the receiver is enabled.
>
> I ran this by Atmel support and they wrote: "The issue comes from the fact
> that you disable the PDC/DMA Reception and not the USART Reception channel. In
> your case, the[n] you will still receive data into the USART_RHR register, and
> maybe you [h]ave the overun flag set. So please disable the USART reception
> channel."
>
> The following patch should force the driver to enable/disable the receiver via
> RXEN/RXDIS fields of the USART control register. It fixed the issue I was
> having - perhaps others will find it useful as well.
>
> Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com>
That's nice, but:
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.--
This footer just contridicted your signed-off-by:
So, what should I believe?
Hint, please remove such footers, and tell anyone who insists on them
that they directly prevent you from contributing to the kernel, as I can
not accept patches with this on it.
Care to resend this without the footer so I can accept it?
greg k-h
^ permalink raw reply
* [PATCH] atmel-serial: fix RS485 half-duplex problem
From: Siftar, Gabe @ 2012-03-27 17:43 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-serial@vger.kernel.org
Cc: Greg Kroah-Hartman, Andrew Victor, Nicolas Ferre,
Jean-Christophe PLAGNIOL-VILLARD, Claudio Scordino, Bernhard Roth
On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45.
SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we
transmit (our transceiver will receive transmitted data). Although the current
driver attempts to disable and enable the receiver at the appropriate points,
incoming data is still loaded into the receive register causing our code to
receive the very last byte that was sent once the receiver is enabled.
I ran this by Atmel support and they wrote: "The issue comes from the fact
that you disable the PDC/DMA Reception and not the USART Reception channel. In
your case, the[n] you will still receive data into the USART_RHR register, and
maybe you [h]ave the overun flag set. So please disable the USART reception
channel."
The following patch should force the driver to enable/disable the receiver via
RXEN/RXDIS fields of the USART control register. It fixed the issue I was
having - perhaps others will find it useful as well.
Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com>
Index: linux-3.3/drivers/tty/serial/atmel_serial.c
===================================================================
--- linux-3.3.orig/drivers/tty/serial/atmel_serial.c
+++ linux-3.3/drivers/tty/serial/atmel_serial.c
@@ -395,6 +395,8 @@
{
UART_PUT_CR(port, ATMEL_US_RSTSTA); /* reset status and receiver */
+ UART_PUT_CR(port, ATMEL_US_RXEN);
+
if (atmel_use_dma_rx(port)) {
/* enable PDC controller */
UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
@@ -410,6 +412,8 @@
*/
static void atmel_stop_rx(struct uart_port *port)
{
+ UART_PUT_CR(port, ATMEL_US_RXDIS);
+
if (atmel_use_dma_rx(port)) {
/* disable PDC receive */
UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
^ permalink raw reply
* Re: [PATCH] amba-pl011: fix panic introduced by "clear pending interrupts"
From: Sergei Shtylyov @ 2012-03-27 12:12 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, linux-arm-kernel, Giancarlo Asnaghi, gregkh,
linux-serial, Alan Cox
In-Reply-To: <20120326203209.GA8182@mail.gnudd.com>
Hello.
On 27-03-2012 0:32, Alessandro Rubini wrote:
> patch 9b96fba, currently in linux-next, clears interrupts using
Please also specify the summary of this commit in parens.
> uap->port.membase that has not been assigned. My x86 system,
> that uses a pci-to-amba bridge, panics with a message like:
> BUG: unable to handle kernel NULL pointer dereference at 00000038
> IP: [<c12c85ed>] pl011_probe+0x119/0x303
> Signed-off-by: Alessandro Rubini<rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi<giancarlo.asnaghi@st.com>
WBR, Sergei
^ permalink raw reply
* [PATCH] pch_uart: Fix dma channel unallocated issue
From: Tomoya MORINAGA @ 2012-03-27 9:56 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, Tomoya MORINAGA
This driver anticipates pch_uart_verify_port() is not called
during installation.
However, actually pch_uart_verify_port() is called during
installation.
As a result, memory access violation occurs like below.
0. initial value: use_dma=0
1. starup()
- dma channel is not allocated because use_dma=0
2. pch_uart_verify_port()
- Set use_dma=1
3. UART processing acts DMA mode because use_dma=1
- memory access violation occurs!
This patch fixes the issue.
Solution:
Whenever pch_uart_verify_port() is called and then
dma channel is not allocated, the channel should be allocated.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
---
drivers/tty/serial/pch_uart.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 803847b..e297b7c 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1452,8 +1452,10 @@ static int pch_uart_verify_port(struct uart_port *port,
__func__);
return -EOPNOTSUPP;
#endif
- priv->use_dma = 1;
dev_info(priv->port.dev, "PCH UART : Use DMA Mode\n");
+ if (!priv->use_dma)
+ pch_request_dma(port);
+ priv->use_dma = 1;
}
return 0;
--
1.7.7.6
^ permalink raw reply related
* [PATCH] ARM: clps711x: serial driver hungs are a result of call disable_irq within ISR
From: Alexander Shiyan @ 2012-03-27 8:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel,
Alexander Shiyan
Since 2.6.30-rc1 clps711x serial driver hungs system. This is a result
of call disable_irq from ISR. synchronize_irq waits for end of interrupt
and goes to infinite loop. This patch fix this problem.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
drivers/tty/serial/clps711x.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/clps711x.c b/drivers/tty/serial/clps711x.c
index e6c3dbd..836fe273 100644
--- a/drivers/tty/serial/clps711x.c
+++ b/drivers/tty/serial/clps711x.c
@@ -154,10 +154,9 @@ static irqreturn_t clps711xuart_int_tx(int irq, void *dev_id)
port->x_char = 0;
return IRQ_HANDLED;
}
- if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
- clps711xuart_stop_tx(port);
- return IRQ_HANDLED;
- }
+
+ if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+ goto disable_tx_irq;
count = port->fifosize >> 1;
do {
@@ -171,8 +170,11 @@ static irqreturn_t clps711xuart_int_tx(int irq, void *dev_id)
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(port);
- if (uart_circ_empty(xmit))
- clps711xuart_stop_tx(port);
+ if (uart_circ_empty(xmit)) {
+ disable_tx_irq:
+ disable_irq_nosync(TX_IRQ(port));
+ tx_enabled(port) = 0;
+ }
return IRQ_HANDLED;
}
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] amba-pl011: fix panic introduced by "clear pending interrupts"
From: Linus Walleij @ 2012-03-27 7:07 UTC (permalink / raw)
To: Alessandro Rubini
Cc: linux-kernel, Giancarlo Asnaghi, Alan Cox, gregkh, linux-serial,
linux-arm-kernel
In-Reply-To: <20120326203209.GA8182@mail.gnudd.com>
On Mon, Mar 26, 2012 at 10:32 PM, Alessandro Rubini <rubini@gnudd.com> wrote:
> patch 9b96fba, currently in linux-next, clears interrupts using
> uap->port.membase that has not been assigned. My x86 system,
> that uses a pci-to-amba bridge, panics with a message like:
>
> BUG: unable to handle kernel NULL pointer dereference at 00000038
> IP: [<c12c85ed>] pl011_probe+0x119/0x303
>
> Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
> Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
Yep I know, already sent the remedy, just waiting for Greg to pick it up:
http://marc.info/?l=linux-serial&m=133235774423240&w=2
But thanks for the quick attention :-)
Yours,
Linus Walleij
--
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
* [PATCH] amba-pl011: fix panic introduced by "clear pending interrupts"
From: Alessandro Rubini @ 2012-03-26 20:32 UTC (permalink / raw)
To: linux-kernel
Cc: Giancarlo Asnaghi, Alan Cox, gregkh, linux-serial,
linux-arm-kernel
patch 9b96fba, currently in linux-next, clears interrupts using
uap->port.membase that has not been assigned. My x86 system,
that uses a pci-to-amba bridge, panics with a message like:
BUG: unable to handle kernel NULL pointer dereference at 00000038
IP: [<c12c85ed>] pl011_probe+0x119/0x303
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
Acked-by: Giancarlo Asnaghi <giancarlo.asnaghi@st.com>
---
drivers/tty/serial/amba-pl011.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 2b4e981..38c992d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1947,8 +1947,8 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
}
/* Ensure interrupts from this UART are masked and cleared */
- writew(0, uap->port.membase + UART011_IMSC);
- writew(0xffff, uap->port.membase + UART011_ICR);
+ writew(0, base + UART011_IMSC);
+ writew(0xffff, base + UART011_ICR);
uap->vendor = vendor;
uap->lcrh_rx = vendor->lcrh_rx;
--
1.7.7.2
^ permalink raw reply related
* (From: Mrs. Mary kumba, Family Business Assistance Tel:+27-737535133 )
From: Tony Kumba @ 2012-03-26 9:45 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
Please view the attached letter
[-- Attachment #2: KUMBA`S FAMILY FROM ZIMBABWE.pdf --]
[-- Type: application/pdf, Size: 29531 bytes --]
^ 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