[PATCH linux dev-4.13] serial: 8250: Add Nuvoton NPCM UART

[Tomer Maimon]

On 7 February 2018 at 03:50, Joel Stanley <joel at jms.id.au> wrote:
> On Tue, Feb 6, 2018 at 10:54 PM, Tomer Maimon <tmaimon77 at gmail.com> wrote:
>> On 6 February 2018 at 12:37, Avi Fishman <avifishman70 at gmail.com> wrote:
>>> On Tue, Feb 6, 2018 at 7:50 AM, Joel Stanley <joel at jms.id.au> wrote:
>>>> On Mon, Feb 5, 2018 at 7:39 PM, Tomer Maimon <tmaimon77 at gmail.com> wrote:
>>>>> On 2 February 2018 at 06:27, Joel Stanley <joel at jms.id.au> wrote:
>>>>
>>>>>>  /* Uart divisor latch read */
>>>>>> @@ -2143,6 +2153,15 @@ int serial8250_do_startup(struct uart_port *port)
>>>>>>                                 UART_DA830_PWREMU_MGMT_FREE);
>>>>>>         }
>>>>>>
>>>>>> +       if (port->type == PORT_NPCM) {
>>>>>> +               /*
>>>>>> +                * Nuvoton calls the scratch register 'UART_TOR' (timeout
>>>>>> +                * register). Enable it, and set TIOC (timeout interrupt
>>>>>> +                * comparator) to be 0x20 for correct operation.
>>>>>> +                */
>>>>>> +               serial_port_out(port, UART_NPCM_TOR, UART_NPCM_TOIE | 0x20);
>>>>>> +       }
>>>>>
>>>>> Can we set the TOR register dynamically (adding special IOCTL)?
>>>>
>>>> We would have to have a good reason to do so.
>>>>
>>>> Under what circumstances would a user need to change this dynamically?
>>>
>>> Tomer, I agree it is not important to change at run time.
>> I agree Avi,
>> but the only problem I see with it that if we will need in the future
>> to TOR register dynamically (new SOC, client demand, etc.)
>> Could it be done in the 8250 files?
>
> If we have a requirement in the future I suggest we decide how to
> solve that problem then. Cross that bridge when we come to it.
Sounds good
>
>
>>>
>>>>
>>>>>
>>>>>> +
>>>>>>  #ifdef CONFIG_SERIAL_8250_RSA
>>>>>>         /*
>>>>>>          * If this is an RSA port, see if we can kick it up to the
>>>>>> @@ -2465,6 +2484,15 @@ static unsigned int xr17v35x_get_divisor(struct uart_8250_port *up,
>>>>>>         return quot_16 >> 4;
>>>>>>  }
>>>>>>
>>>>>> +/* Nuvoton NPCM UARTs have a custom divisor calculation */
>>>>>> +static unsigned int npcm_get_divisor(struct uart_8250_port *up,
>>>>>> +               unsigned int baud)
>>>>>> +{
>>>>>> +       struct uart_port *port = &up->port;
>>>>>> +
>>>>>> +       return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
>>>>>> +}
>>>>
>>>> Did you test this version of the driver on your hardware?
>> Yes Thanks!!! it working fine.
>
> Great!
>
>>>>
>>>> I think I understand why you had the extra code, but does it affect
>>>> operation in any of your tests?
>>>>
>>>> From what I understand the baud rates are often calculated to be "near enough".
>>>
>>> Joel, I made the original calculation but I agree that this one is
>>> good enough (I confused Tomer to think that your calculation will not
>>> fit :)
>>>
>> I see you add the TOR to include/uapi/linux/serial_reg.h will the
>> maintainer accept it?
>
> It's in a private include, include/uapi/linux/serial_reg.h.
>
> Initially I didn't do this, but if you examine the end of that file
> there are a number of other 8250 ports that do this.
>
> If you would like, I will send this patch upstream now.
Yes great please do,

Thanks a lot
>
> Cheers,
>
> Joel

Cheers,

Tomer