2017-03-29 18:48:18

by Olliver Schinagl

[permalink] [raw]
Subject: [PATCH] serial: tegra: Map the iir register to default defines

The tegra serial IP seems to be following the common layout and the
interrupt ID's match up nicely. Replace the magic values to match the
common serial_reg defines, with the addition of the Tegra unique End of
Data interrupt.

Signed-off-by: Olliver Schinagl <[email protected]>
---
Note I do not own any tegra hardware and just noticed it while working on my
somewhat related previous patch,
"serial: Do not treat the IIR register as a bitfield"

As such, this patch can only be applied after the aforementioned patch or the
iir variable will not have its mask applied yet.

drivers/tty/serial/serial-tegra.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/tty/serial/serial-tegra.c b/drivers/tty/serial/serial-tegra.c
index 4a084161d1d2..f765999dcbfe 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -83,6 +83,8 @@
#define TEGRA_TX_PIO 1
#define TEGRA_TX_DMA 2

+#define TEGRA_UART_IIR_EOD 0x8
+
/**
* tegra_uart_chip_data: SOC specific data.
*
@@ -707,20 +709,20 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
return IRQ_HANDLED;
}

- switch ((iir >> 1) & 0x7) {
- case 0: /* Modem signal change interrupt */
+ switch (iir) {
+ case UART_IIR_MSI: /* Modem signal change interrupt */
tegra_uart_handle_modem_signal_change(u);
break;

- case 1: /* Transmit interrupt only triggered when using PIO */
+ case UART_IIR_THRI: /* Transmit interrupt only triggered when using PIO */
tup->ier_shadow &= ~UART_IER_THRI;
tegra_uart_write(tup, tup->ier_shadow, UART_IER);
tegra_uart_handle_tx_pio(tup);
break;

- case 4: /* End of data */
- case 6: /* Rx timeout */
- case 2: /* Receive */
+ case TEGRA_UART_IIR_EOD: /* End of data */
+ case UART_IIR_RX_TIMEOUT: /* Rx timeout */
+ case UART_IIR_RDI: /* Receive */
if (!is_rx_int) {
is_rx_int = true;
/* Disable Rx interrupts */
@@ -734,13 +736,12 @@ static irqreturn_t tegra_uart_isr(int irq, void *data)
}
break;

- case 3: /* Receive error */
+ case UART_IIR_RLSI: /* Receive error */
tegra_uart_decode_rx_error(tup,
tegra_uart_read(tup, UART_LSR));
break;

- case 5: /* break nothing to handle */
- case 7: /* break nothing to handle */
+ default:
break;
}
}
--
2.11.0


2017-03-30 10:36:13

by Laxman Dewangan

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines


On Thursday 30 March 2017 12:18 AM, Olliver Schinagl wrote:
> The tegra serial IP seems to be following the common layout and the
> interrupt ID's match up nicely. Replace the magic values to match the
> common serial_reg defines, with the addition of the Tegra unique End of
> Data interrupt.
>
> Signed-off-by: Olliver Schinagl <[email protected]>
> ---

Adding Shardar for verifications.

Acked-by: Laxman Dewangan <[email protected]>

2017-03-30 13:42:37

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines


On 29/03/17 19:48, Olliver Schinagl wrote:
> The tegra serial IP seems to be following the common layout and the
> interrupt ID's match up nicely. Replace the magic values to match the
> common serial_reg defines, with the addition of the Tegra unique End of
> Data interrupt.
>
> Signed-off-by: Olliver Schinagl <[email protected]>
> ---
> Note I do not own any tegra hardware and just noticed it while working on my
> somewhat related previous patch,
> "serial: Do not treat the IIR register as a bitfield"
>
> As such, this patch can only be applied after the aforementioned patch or the
> iir variable will not have its mask applied yet.

Nit-pick. If this is the case, then this should really be part of a
patch series so it is obvious to everyone that this should only be
applied after the other patch.

Cheers
Jon

--
nvpublic

2017-03-30 15:38:01

by Olliver Schinagl

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines

Hey Jon,

On March 30, 2017 3:42:19 PM CEST, Jon Hunter <[email protected]> wrote:
>
>On 29/03/17 19:48, Olliver Schinagl wrote:
>> The tegra serial IP seems to be following the common layout and the
>> interrupt ID's match up nicely. Replace the magic values to match the
>> common serial_reg defines, with the addition of the Tegra unique End
>of
>> Data interrupt.
>>
>> Signed-off-by: Olliver Schinagl <[email protected]>
>> ---
>> Note I do not own any tegra hardware and just noticed it while
>working on my
>> somewhat related previous patch,
>> "serial: Do not treat the IIR register as a bitfield"
>>
>> As such, this patch can only be applied after the aforementioned
>patch or the
>> iir variable will not have its mask applied yet.
>
>Nit-pick. If this is the case, then this should really be part of a
>patch series so it is obvious to everyone that this should only be
>applied after the other patch.
Yes, and it was, but I did not want to have the really big list of names in this much smaller group.
>
>Cheers
>Jon

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

2017-03-31 10:07:24

by Shardar Mohammed

[permalink] [raw]
Subject: RE: [PATCH] serial: tegra: Map the iir register to default defines

Verification failed on Tegra.
Fix here is, IIR should be masked with UART_IIR_MASK after reading the IIR register as on Tegra bit-6 is used for internal usage to know if FIFO mode is enabled.
while (1) {
iir = tegra_uart_read(tup, UART_IIR);
+iir &= UART_IIR_MASK;

Thanks,
Shardar

-----Original Message-----
From: Laxman Dewangan
Sent: Thursday, March 30, 2017 3:48 PM
To: Olliver Schinagl <[email protected]>; Greg Kroah-Hartman <[email protected]>; Jiri Slaby <[email protected]>; Stephen Warren <[email protected]>; Thierry Reding <[email protected]>; Alexandre Courbot <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; Shardar Mohammed <[email protected]>
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines


On Thursday 30 March 2017 12:18 AM, Olliver Schinagl wrote:
> The tegra serial IP seems to be following the common layout and the
> interrupt ID's match up nicely. Replace the magic values to match the
> common serial_reg defines, with the addition of the Tegra unique End
> of Data interrupt.
>
> Signed-off-by: Olliver Schinagl <[email protected]>
> ---

Adding Shardar for verifications.

Acked-by: Laxman Dewangan <[email protected]>

2017-03-31 10:28:38

by Jon Hunter

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines


On 31/03/17 11:07, Shardar Mohammed wrote:
> Verification failed on Tegra.
> Fix here is, IIR should be masked with UART_IIR_MASK after reading the IIR register as on Tegra bit-6 is used for internal usage to know if FIFO mode is enabled.
> while (1) {
> iir = tegra_uart_read(tup, UART_IIR);
> +iir &= UART_IIR_MASK;

Per Olliver's original email did you pick up the other patch [0] before
applying this because that does apply the mask. I mentioned to Olliver
that this should really be a series, so it is clear that this patch is
dependent upon the other.

> -----Original Message-----
> From: Laxman Dewangan
> Sent: Thursday, March 30, 2017 3:48 PM
> To: Olliver Schinagl <[email protected]>; Greg Kroah-Hartman <[email protected]>; Jiri Slaby <[email protected]>; Stephen Warren <[email protected]>; Thierry Reding <[email protected]>; Alexandre Courbot <[email protected]>
> Cc: [email protected]; [email protected]; [email protected]; Shardar Mohammed <[email protected]>
> Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines
>
>
> On Thursday 30 March 2017 12:18 AM, Olliver Schinagl wrote:
>> The tegra serial IP seems to be following the common layout and the
>> interrupt ID's match up nicely. Replace the magic values to match the
>> common serial_reg defines, with the addition of the Tegra unique End
>> of Data interrupt.
>>
>> Signed-off-by: Olliver Schinagl <[email protected]>
>> ---
>
> Adding Shardar for verifications.
>
> Acked-by: Laxman Dewangan <[email protected]>

Furthermore does this ACK imply that you have reviewed the other patch
this one is dependent upon?

Cheers
Jon

[0] http://marc.info/?l=linux-serial&m=149081309627392&w=2

--
nvpublic

2017-03-31 10:42:21

by Shardar Mohammed

[permalink] [raw]
Subject: RE: [PATCH] serial: tegra: Map the iir register to default defines

> On 31/03/17 11:07, Shardar Mohammed wrote:
> > Verification failed on Tegra.
> > Fix here is, IIR should be masked with UART_IIR_MASK after reading the IIR
> register as on Tegra bit-6 is used for internal usage to know if FIFO mode is
> enabled.
> > while (1) {
> > iir = tegra_uart_read(tup, UART_IIR);
> > +iir &= UART_IIR_MASK;
>
> Per Olliver's original email did you pick up the other patch [0] before applying
> this because that does apply the mask. I mentioned to Olliver that this should
> really be a series, so it is clear that this patch is dependent upon the other.

For UART_IIR_MASK macro, dependent patch is required if we add this required line.
But here to fix the issue with the current patch above masking step is necessary.

>
> > -----Original Message-----
> > From: Laxman Dewangan
> > Sent: Thursday, March 30, 2017 3:48 PM
> > To: Olliver Schinagl <[email protected]>; Greg Kroah-Hartman
> > <[email protected]>; Jiri Slaby <[email protected]>; Stephen
> > Warren <[email protected]>; Thierry Reding
> > <[email protected]>; Alexandre Courbot <[email protected]>
> > Cc: [email protected]; [email protected];
> > [email protected]; Shardar Mohammed
> <[email protected]>
> > Subject: Re: [PATCH] serial: tegra: Map the iir register to default
> > defines
> >
> >
> > On Thursday 30 March 2017 12:18 AM, Olliver Schinagl wrote:
> >> The tegra serial IP seems to be following the common layout and the
> >> interrupt ID's match up nicely. Replace the magic values to match the
> >> common serial_reg defines, with the addition of the Tegra unique End
> >> of Data interrupt.
> >>
> >> Signed-off-by: Olliver Schinagl <[email protected]>
> >> ---
> >
> > Adding Shardar for verifications.
> >
> > Acked-by: Laxman Dewangan <[email protected]>
>
> Furthermore does this ACK imply that you have reviewed the other patch this
> one is dependent upon?
>
Yes dependent change looks fine, but I have not tested it.

> Cheers
> Jon
>
> [0] http://marc.info/?l=linux-serial&m=149081309627392&w=2
>
> --
> nvpublic

2017-03-31 11:32:56

by Olliver Schinagl

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines

Hey Shadar,

On 31-03-17 12:42, Shardar Mohammed wrote:
>> On 31/03/17 11:07, Shardar Mohammed wrote:
>>> Verification failed on Tegra.
>>> Fix here is, IIR should be masked with UART_IIR_MASK after reading the IIR
>> register as on Tegra bit-6 is used for internal usage to know if FIFO mode is
>> enabled.
>>> while (1) {
>>> iir = tegra_uart_read(tup, UART_IIR);
>>> +iir &= UART_IIR_MASK;
>>
>> Per Olliver's original email did you pick up the other patch [0] before applying
>> this because that does apply the mask. I mentioned to Olliver that this should
>> really be a series, so it is clear that this patch is dependent upon the other.
>
> For UART_IIR_MASK macro, dependent patch is required if we add this required line.
> But here to fix the issue with the current patch above masking step is necessary.

Yeah the other big patch adds this line (and does some other fixes to
the tegra driver with regards to the UART_IIR_MASK).

I did not make it a 'set' because the other patch has a big big list of
names and touches a lot of serial devices. So both 'groups' would get a
lot of noise. I'm sorry if this caused confusion. If you guys prefer,
I'll turn it into a set.

Again, sorry for the inconvenience,

Olliver
>
>>
>>> -----Original Message-----
>>> From: Laxman Dewangan
>>> Sent: Thursday, March 30, 2017 3:48 PM
>>> To: Olliver Schinagl <[email protected]>; Greg Kroah-Hartman
>>> <[email protected]>; Jiri Slaby <[email protected]>; Stephen
>>> Warren <[email protected]>; Thierry Reding
>>> <[email protected]>; Alexandre Courbot <[email protected]>
>>> Cc: [email protected]; [email protected];
>>> [email protected]; Shardar Mohammed
>> <[email protected]>
>>> Subject: Re: [PATCH] serial: tegra: Map the iir register to default
>>> defines
>>>
>>>
>>> On Thursday 30 March 2017 12:18 AM, Olliver Schinagl wrote:
>>>> The tegra serial IP seems to be following the common layout and the
>>>> interrupt ID's match up nicely. Replace the magic values to match the
>>>> common serial_reg defines, with the addition of the Tegra unique End
>>>> of Data interrupt.
>>>>
>>>> Signed-off-by: Olliver Schinagl <[email protected]>
>>>> ---
>>>
>>> Adding Shardar for verifications.
>>>
>>> Acked-by: Laxman Dewangan <[email protected]>
>>
>> Furthermore does this ACK imply that you have reviewed the other patch this
>> one is dependent upon?
>>
> Yes dependent change looks fine, but I have not tested it.
>
>> Cheers
>> Jon
>>
>> [0] http://marc.info/?l=linux-serial&m=149081309627392&w=2
>>
>> --
>> nvpublic

2017-03-31 13:23:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines

On Thu, Mar 30, 2017 at 05:37:41PM +0200, Olliver Schinagl wrote:
> Hey Jon,
>
> On March 30, 2017 3:42:19 PM CEST, Jon Hunter <[email protected]> wrote:
> >
> >On 29/03/17 19:48, Olliver Schinagl wrote:
> >> The tegra serial IP seems to be following the common layout and the
> >> interrupt ID's match up nicely. Replace the magic values to match the
> >> common serial_reg defines, with the addition of the Tegra unique End
> >of
> >> Data interrupt.
> >>
> >> Signed-off-by: Olliver Schinagl <[email protected]>
> >> ---
> >> Note I do not own any tegra hardware and just noticed it while
> >working on my
> >> somewhat related previous patch,
> >> "serial: Do not treat the IIR register as a bitfield"
> >>
> >> As such, this patch can only be applied after the aforementioned
> >patch or the
> >> iir variable will not have its mask applied yet.
> >
> >Nit-pick. If this is the case, then this should really be part of a
> >patch series so it is obvious to everyone that this should only be
> >applied after the other patch.
> Yes, and it was, but I did not want to have the really big list of names in this much smaller group.

Ok, this is a mess, don't send me patches that need to be applied in a
specific order, yet are not obviously linked together in a single
series.

How do you expect a maintainer to handle this type of stuff? You need
to make it _OBVIOUS_ as to what I need to do here, otherwise I will get
it wrong.

I'm going to drop all of your patches from my queue and wait for a
resend with the correct order, and ones that work properly, you can do
better than this :)

thanks,

greg k-h