[1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts
diff mbox

Message ID 20170520022154.6766-1-kernel.development@povil.us
State New, archived
Headers show

Commit Message

Sam Povilus May 20, 2017, 2:21 a.m. UTC
The number of xilinx ps uart should be set by a kernel parameter instead of
using a #define. This allows the user to set the number of xilinx ps uart
using only kconfig and not modifying kernel source.

The ps uart is used in Xilnx Zynq chips usually in quantities maxing at
two, but there may be other chips that use more in the future or that I
don't know about. 

Signed-off-by: Sam Povilus <kernel.development@povil.us>
---
 drivers/tty/serial/Kconfig         | 9 +++++++++
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

Comments

Alan Cox May 20, 2017, 4:20 p.m. UTC | #1
On Fri, 19 May 2017 20:21:54 -0600
Sam Povilus <kernel.development@povil.us> wrote:

> The number of xilinx ps uart should be set by a kernel parameter instead of
> using a #define. This allows the user to set the number of xilinx ps uart
> using only kconfig and not modifying kernel source.
> 
> The ps uart is used in Xilnx Zynq chips usually in quantities maxing at
> two, but there may be other chips that use more in the future or that I
> don't know about. 

If it maxes at two then just set it to two. If in in future it maxes at
lots then when it's going to happen change the code to do dynamic
allocation and test it versus actual hardware. 

Otherwise you break some of the basic ideas of having one kernel for many
systems.

Alan
Michal Simek May 22, 2017, 7:02 a.m. UTC | #2
Hi Alan,

On 20.5.2017 18:20, Alan Cox wrote:
> On Fri, 19 May 2017 20:21:54 -0600
> Sam Povilus <kernel.development@povil.us> wrote:
> 
>> The number of xilinx ps uart should be set by a kernel parameter instead of
>> using a #define. This allows the user to set the number of xilinx ps uart
>> using only kconfig and not modifying kernel source.
>>
>> The ps uart is used in Xilnx Zynq chips usually in quantities maxing at
>> two, but there may be other chips that use more in the future or that I
>> don't know about. 
> 
> If it maxes at two then just set it to two. If in in future it maxes at
> lots then when it's going to happen change the code to do dynamic
> allocation and test it versus actual hardware. 
> 
> Otherwise you break some of the basic ideas of having one kernel for many
> systems.


We have in soc vendor tree similar patch but the reason is different.

    tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option.

    This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow
    the user to provide the Max number of uart ports information.
    If multiple cards (or) PL UARTS are present, the default limit
    of 2 ports should be increased.

I haven't checked all drivers but in our case we have added this as
quick fix for scenarios where you use serial aliases where alias is
pointed to serial2 or more.
In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr
which is required to be passed.

What's the best driver to look at dynamic allocation?

Thanks,
Michal
Alan Cox May 22, 2017, 6:26 p.m. UTC | #3
> We have in soc vendor tree similar patch but the reason is different.
> 
>     tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option.
> 
>     This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow
>     the user to provide the Max number of uart ports information.
>     If multiple cards (or) PL UARTS are present, the default limit
>     of 2 ports should be increased.
> 
> I haven't checked all drivers but in our case we have added this as
> quick fix for scenarios where you use serial aliases where alias is
> pointed to serial2 or more.
> In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr
> which is required to be passed.
> 
> What's the best driver to look at dynamic allocation?

So there are quite a few that dynamically allocate the objects as they
are enumerated (eg max3100), but have a maximum set that is just pointers
(so for the max number of ports cheaper than the dynamic code)

The other question is why is it a CONFIG_ option. I'm assuming these
platforms are all ARM and in that case you could just pass the value in
the device tree, or hard code a safe maximum number of pointers to a
value which is the worst case and then install them as they are
enumerated.

There are lots of options better than breaking the "one kernel many
platforms" model.

Alan
Michal Simek May 23, 2017, 11:44 a.m. UTC | #4
On 22.5.2017 20:26, Alan Cox wrote:
>> We have in soc vendor tree similar patch but the reason is different.
>>
>>     tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option.
>>
>>     This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow
>>     the user to provide the Max number of uart ports information.
>>     If multiple cards (or) PL UARTS are present, the default limit
>>     of 2 ports should be increased.
>>
>> I haven't checked all drivers but in our case we have added this as
>> quick fix for scenarios where you use serial aliases where alias is
>> pointed to serial2 or more.
>> In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr
>> which is required to be passed.
>>
>> What's the best driver to look at dynamic allocation?
> 
> So there are quite a few that dynamically allocate the objects as they
> are enumerated (eg max3100), but have a maximum set that is just pointers
> (so for the max number of ports cheaper than the dynamic code)

yep hardcoded max 4 where in probe first free space is found and used
(range 0-3) but still max3100s statically allocated.
Shouldn't be this also dynamically allocated?


> The other question is why is it a CONFIG_ option. I'm assuming these
> platforms are all ARM and in that case you could just pass the value in
> the device tree, or hard code a safe maximum number of pointers to a
> value which is the worst case and then install them as they are
> enumerated.

I am not quite sure how exactly you want to do this via DT.

Also what do you think is a safe maximum number? This is fpga - hundreds
of pins which can do just uart.

> There are lots of options better than breaking the "one kernel many
> platforms" model.

Another options is also module parameter and dynamically allocated array
in cdns_uart_init.

Thanks,
Michal
Alan Cox May 23, 2017, 8:07 p.m. UTC | #5
> yep hardcoded max 4 where in probe first free space is found and used
> (range 0-3) but still max3100s statically allocated.
> Shouldn't be this also dynamically allocated?

The code to do the dynamic allocation would be larger than the array of
pointers for the sane worst case.

> I am not quite sure how exactly you want to do this via DT.

Count the number of DT entries for this kind of port and allocate that
many ?

> 
> Also what do you think is a safe maximum number? This is fpga - hundreds
> of pins which can do just uart.
> 
> > There are lots of options better than breaking the "one kernel many
> > platforms" model.  
> 
> Another options is also module parameter and dynamically allocated array
> in cdns_uart_init.

For a given platform the number is constant and they need to be
described, so it seems to make no sense to put it anywhere other than the
DT for that platform.

Why should users have to pass magic config options not use DT as
intended ?

Alan
Sam Povilus May 24, 2017, 3:27 a.m. UTC | #6
On Mon, May 22, 2017 at 07:26:36PM +0100, Alan Cox wrote:
> > We have in soc vendor tree similar patch but the reason is different.
> > 
> >     tty: serial: Added a CONFIG_SERIAL_XILINX_NR_UARTS option.
> > 
> >     This patch Adds CONFIG_SERIAL_XILINX_NR_UARTS option to allow
> >     the user to provide the Max number of uart ports information.
> >     If multiple cards (or) PL UARTS are present, the default limit
> >     of 2 ports should be increased.
> > 
> > I haven't checked all drivers but in our case we have added this as
> > quick fix for scenarios where you use serial aliases where alias is
> > pointed to serial2 or more.
> > In cdns_uart_init() cdns_uart_uart_driver is passed which contains .nr
> > which is required to be passed.
> > 
> > What's the best driver to look at dynamic allocation?
> 
> So there are quite a few that dynamically allocate the objects as they
> are enumerated (eg max3100), but have a maximum set that is just pointers
> (so for the max number of ports cheaper than the dynamic code)
> 
> The other question is why is it a CONFIG_ option. I'm assuming these
> platforms are all ARM and in that case you could just pass the value in
> the device tree, or hard code a safe maximum number of pointers to a
> value which is the worst case and then install them as they are
> enumerated.
> 
> There are lots of options better than breaking the "one kernel many
> platforms" model.
> 
> Alan


I guess I'm confused how this isn't a better solution than what we have
now, or how it breaks the "one kernel many platforms model".

I agree that it is not the best solution, certainly this driver should be
re-written to use the device tree and dynamic allocation, but that is
not the patch being offered at this time.

This is a very minor module buried deep in the drivers tree. I guess I
don't understand how allowing users to choose how many UARTS they might
want to implement breaks the "one kernel" model. The users of this module
and those like it do not use a pre-compiled kernel and customize their
kernels extensively.

Is there some documentation online I could read that explains this "one
kernel many platforms" model? Specifically how it pertains to FPGAs? I
am but a humble embedded developer trying to make the kernel more useful
to myself (and hopefully others), and I think I might have a limited
worldview that restricts my ability to see the full picture and I would
like to learn.
Michal Simek May 24, 2017, 1:06 p.m. UTC | #7
On 23.5.2017 22:07, Alan Cox wrote:
>> yep hardcoded max 4 where in probe first free space is found and used
>> (range 0-3) but still max3100s statically allocated.
>> Shouldn't be this also dynamically allocated?
> 
> The code to do the dynamic allocation would be larger than the array of
> pointers for the sane worst case.
> 
>> I am not quite sure how exactly you want to do this via DT.
> 
> Count the number of DT entries for this kind of port and allocate that
> many ?

:-) I think there is no doubt how to calculate that number for
static/fixed system. But where do you want to put it? And who should
read it?

A lot of drivers are calling uart_register_driver in module_init.
Others are calling it in probe(pl011 for example).

In module init you probably don't have a pointer to DT to read this and
this should be in generic location not in node itself.
If all drivers should call it from probe then we should change that -
then reading property is easy and only location should be cleared.

That's why I am curious how exactly you would do it because I haven't
seen this before.

> 
>>
>> Also what do you think is a safe maximum number? This is fpga - hundreds
>> of pins which can do just uart.
>>
>>> There are lots of options better than breaking the "one kernel many
>>> platforms" model.  
>>
>> Another options is also module parameter and dynamically allocated array
>> in cdns_uart_init.
> 
> For a given platform the number is constant and they need to be
> described, so it seems to make no sense to put it anywhere other than the
> DT for that platform.

Also I don't think this is really constant in all cases. Especially in
connection to fpga where you can put others IPs to PL. You never know
what it is present in partial region and how many of these are there.
It means having truly dynamic behavior would be welcome.

Can you call uart_register_driver() from probe for every instance? It
means nr is 1 all the time.

> 
> Why should users have to pass magic config options not use DT as
> intended ?

I am not saying that config option is perfect solution. It is at least
aligned with 5 others serial drivers in the tree.

Thanks,
Michal
Alan Cox May 24, 2017, 1:31 p.m. UTC | #8
> I am not saying that config option is perfect solution. It is at least
> aligned with 5 others serial drivers in the tree.

And the fact people keep doing hacks jutifies continuing to make a mess.
Especialy as in this case it's entirely theoretical. Nobody has produced
actual hardware that hits the limit. Nobody has filed a bug, nobody is
impacted.

Creating extra CONFIG_ entries for junk like this is ridiculous, most of
the others at least have the excuse of being old code.

Generally it is better to call uart_register_driver from the probe method
because that way you don't waste time and memory registering drivers for
stuff that isn't even present however if you have no idea how many
devices there might be then you still really need to pass a suitable limit
and handle it internally dynamically allocating as needed.

If someone was hitting this in the real world and you posted a patch that
just changed the constant to 8 or 16 or whatever was needed I wouldn't
care too much, but adding CONFIG_ entries just makes stuff harder and
harder to config and more and more impossible to keep generic.

I keep hearing that the ARM folks are trying to get one unified kernel.
CONFIG_ options is not how to do that.

Alan
Michal Simek May 24, 2017, 4:09 p.m. UTC | #9
On 24.5.2017 15:31, Alan Cox wrote:
>> I am not saying that config option is perfect solution. It is at least
>> aligned with 5 others serial drivers in the tree.
> 
> And the fact people keep doing hacks jutifies continuing to make a mess.
> Especialy as in this case it's entirely theoretical. Nobody has produced
> actual hardware that hits the limit. Nobody has filed a bug, nobody is
> impacted.

This is the reason why we are talking about it how to do it right.

With this ps uart it is not that easy because this is cadence RTL which
is not in public IP database but the same think is with uartlite.
Limit there is 16. If you really want that I can create that HW design
which will require more than 16 uartlites in one design.


> Creating extra CONFIG_ entries for junk like this is ridiculous, most of
> the others at least have the excuse of being old code.

No doubt about it. I am just trying to find out what's the way you are
suggesting.


> Generally it is better to call uart_register_driver from the probe method
> because that way you don't waste time and memory registering drivers for
> stuff that isn't even present however if you have no idea how many
> devices there might be then you still really need to pass a suitable limit
> and handle it internally dynamically allocating as needed.

Ok. Is there any problem if uart_register_driver is called for every
instance separately with nr=1? This driver has major 0, minor 0. Based
on comment major 0 is for dynamic node allocation. Not sure about minor
but it is easy to figured out if this should be 0 or 1, 2, 3, etc.

> If someone was hitting this in the real world and you posted a patch that
> just changed the constant to 8 or 16 or whatever was needed I wouldn't
> care too much, but adding CONFIG_ entries just makes stuff harder and
> harder to config and more and more impossible to keep generic.
> 
> I keep hearing that the ARM folks are trying to get one unified kernel.
> CONFIG_ options is not how to do that.

I have really not a problem with all of this. Just trying to understand
how to do it properly and cleanup the second driver which we use on
fpga. Last driver used by Xilinx is uart16550 where that old config
macro already exists.

Because at least now there is an issue in driver if you use serial
aliases (serial2 and up) which needs to be fixed.

Thanks,
Michal
Maarten Brock May 25, 2017, 9:27 a.m. UTC | #10
On 2017-05-24 18:09, Michal Simek wrote:
> On 24.5.2017 15:31, Alan Cox wrote:
>>> I am not saying that config option is perfect solution. It is at 
>>> least
>>> aligned with 5 others serial drivers in the tree.
>> 
>> And the fact people keep doing hacks jutifies continuing to make a 
>> mess.
>> Especialy as in this case it's entirely theoretical. Nobody has 
>> produced
>> actual hardware that hits the limit. Nobody has filed a bug, nobody is
>> impacted.
> 
> This is the reason why we are talking about it how to do it right.
> 
> With this ps uart it is not that easy because this is cadence RTL which
> is not in public IP database but the same think is with uartlite.
> Limit there is 16. If you really want that I can create that HW design
> which will require more than 16 uartlites in one design.
> 
> 
>> Creating extra CONFIG_ entries for junk like this is ridiculous, most 
>> of
>> the others at least have the excuse of being old code.
> 
> No doubt about it. I am just trying to find out what's the way you are
> suggesting.

A patch was already recently sent to this mailing list to add a CONFIG_
entry for the maximum number of uartlite devices. It is, as you say, 
quite
easy to create a device with more than 16 uartlite devices. (It is
probably harder to create one with many Cadence RTL PS uarts since that
would require a license.)

IMHO it is quite normal for anyone using the uartlite to build his/her 
own
kernel. and thus make config settings. But it is cumbersome to have to
modify the kernel sources. If the number of uartlites could be retrieved
from the device tree that would probably be even better if the price in
complexity and code size is reasonable.

Maarten
Alan Cox May 25, 2017, 1:29 p.m. UTC | #11
> Ok. Is there any problem if uart_register_driver is called for every
> instance separately with nr=1? This driver has major 0, minor 0. Based

If you are doing that level of code restructuring none that I am aware
of, and if you find one I'm happy to work on fixing it.

Alan
Michal Simek May 25, 2017, 3:33 p.m. UTC | #12
On 25.5.2017 15:29, Alan Cox wrote:
>> Ok. Is there any problem if uart_register_driver is called for every
>> instance separately with nr=1? This driver has major 0, minor 0. Based
> 
> If you are doing that level of code restructuring none that I am aware
> of, and if you find one I'm happy to work on fixing it.

ok. Let me try to play with it and see if this is working.

M

Patch
diff mbox

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 5c8850f7a2a0..fef25f17a4cc 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1461,6 +1461,15 @@  config SERIAL_XILINX_PS_UART_CONSOLE
 	help
 	  Enable a Cadence UART port to be the system console.
 
+config SERIAL_XILINX_PS_UART_NR_UARTS
+       int "Maximum number of Cadence UART ports"
+       depends on CONFIG_SERIAL_XILINX_NR_UARTS
+       range 1 64
+       default 2
+       help
+         Set this to the number of Cadence UARTS in your system, or the number
+	 you think you might implement.
+
 config SERIAL_AR933X
 	tristate "AR933X serial port support"
 	depends on HAVE_CLK && SOC_AR933X
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index c0539950f8d7..a2c51c35da65 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -36,7 +36,7 @@ 
 #define CDNS_UART_NAME		"xuartps"
 #define CDNS_UART_MAJOR		0	/* use dynamic node allocation */
 #define CDNS_UART_MINOR		0	/* works best with devtmpfs */
-#define CDNS_UART_NR_PORTS	2
+#define CDNS_UART_NR_PORTS	CONFIG_SERIAL_XILINX_NR_UARTS
 #define CDNS_UART_FIFO_SIZE	64	/* FIFO size */
 #define CDNS_UART_REGISTER_SPACE	0x1000