Preventing OMAP3 serial driver to take control of all UARTs

Preventing OMAP3 serial driver to take control of all UARTs

[Mika Westerberg]

Hi Tony,

Current omap serial driver takes control of all 3 (4 on OMAP3640)
UARTS. However, we have such a setup where UART2 for example is used
by bluetooth driver. It uses the UART as non-standard way (there are
some Nokia extensions to H4 protocol) so we cannot use the standard
driver for driving the UART but have written special one for that
purpose.

Question is: Is there any, upstreamable, way of preventing omap serial
driver to do this? Currently this is done with custom #ifdef hackery to
mach-omap2/serial.c. Alternative solution that comes into mind is to
specify UART configuration in board files and let serial driver to use
that instead of hard-coded one. Or do you have some nice alternatives?

Thanks,
MW

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Peter Barada]

On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
> Hi Tony,
> 
> Current omap serial driver takes control of all 3 (4 on OMAP3640)
> UARTS. However, we have such a setup where UART2 for example is used
> by bluetooth driver. It uses the UART as non-standard way (there are
> some Nokia extensions to H4 protocol) so we cannot use the standard
> driver for driving the UART but have written special one for that
> purpose.
> 
> Question is: Is there any, upstreamable, way of preventing omap serial
> driver to do this? Currently this is done with custom #ifdef hackery to
> mach-omap2/serial.c. Alternative solution that comes into mind is to
> specify UART configuration in board files and let serial driver to use
> that instead of hard-coded one. Or do you have some nice alternatives?

Previously (back around 2.6.28-rc8) in the board file, the
omap_uart_config struct controlled which serial ports were enabled on
startup.  It was used in omap_serial_init, and it looks like that code
went away with the following commit:
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c

I'm kinda in the same boat as I want to use some of the unused serial
port pins for GPIO, but they are setup as serial ports....


> Thanks,
> MW
> --
> 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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Grant Likely]

On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
>> Hi Tony,
>>
>> Current omap serial driver takes control of all 3 (4 on OMAP3640)
>> UARTS. However, we have such a setup where UART2 for example is used
>> by bluetooth driver. It uses the UART as non-standard way (there are
>> some Nokia extensions to H4 protocol) so we cannot use the standard
>> driver for driving the UART but have written special one for that
>> purpose.
>>
>> Question is: Is there any, upstreamable, way of preventing omap serial
>> driver to do this? Currently this is done with custom #ifdef hackery to
>> mach-omap2/serial.c. Alternative solution that comes into mind is to
>> specify UART configuration in board files and let serial driver to use
>> that instead of hard-coded one. Or do you have some nice alternatives?
>
> Previously (back around 2.6.28-rc8) in the board file, the
> omap_uart_config struct controlled which serial ports were enabled on
> startup.  It was used in omap_serial_init, and it looks like that code
> went away with the following commit:
> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
>
> I'm kinda in the same boat as I want to use some of the unused serial
> port pins for GPIO, but they are setup as serial ports....

Not in mainlined yet, but I'm working on porting flattened device tree
support to OMAP to solve exactly this sort of problem.  Basically,
instead of hard coding or #ifdeffing things, a data blob gets handed
to the kernel at boot time telling it exactly what hardware is present
in a consistent, parsable format.  Device drivers then get probed
based on data in the device tree.  Here's some info on the approach:

http://www.elinux.org/Device_Trees

I expect to have my prototype ready for review mid-January, and most
of the common code should be either merged or queued up in linux-next
by that time.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> > On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
> >> Hi Tony,
> >>
> >> Current omap serial driver takes control of all 3 (4 on OMAP3640)
> >> UARTS. However, we have such a setup where UART2 for example is used
> >> by bluetooth driver. It uses the UART as non-standard way (there are
> >> some Nokia extensions to H4 protocol) so we cannot use the standard
> >> driver for driving the UART but have written special one for that
> >> purpose.
> >>
> >> Question is: Is there any, upstreamable, way of preventing omap serial
> >> driver to do this? Currently this is done with custom #ifdef hackery to
> >> mach-omap2/serial.c. Alternative solution that comes into mind is to
> >> specify UART configuration in board files and let serial driver to use
> >> that instead of hard-coded one. Or do you have some nice alternatives?
> >
> > Previously (back around 2.6.28-rc8) in the board file, the
> > omap_uart_config struct controlled which serial ports were enabled on
> > startup.  It was used in omap_serial_init, and it looks like that code
> > went away with the following commit:
> > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
> >
> > I'm kinda in the same boat as I want to use some of the unused serial
> > port pins for GPIO, but they are setup as serial ports....

Sounds like we need something back to specify the ports to use
from board-*.c files. Kevin, got any comments? 
 
> Not in mainlined yet, but I'm working on porting flattened device tree
> support to OMAP to solve exactly this sort of problem.  Basically,
> instead of hard coding or #ifdeffing things, a data blob gets handed
> to the kernel at boot time telling it exactly what hardware is present
> in a consistent, parsable format.  Device drivers then get probed
> based on data in the device tree.  Here's some info on the approach:
> 
> http://www.elinux.org/Device_Trees
> 
> I expect to have my prototype ready for review mid-January, and most
> of the common code should be either merged or queued up in linux-next
> by that time.

While device tree is a nice solution to some of the problems, it still
leaves all the issues we already have with buggy and and outdated
bootloaders. So we still need to properly initialize the devices in
the kernel.

Just for reference, most of the omap bootloader bugs seem to be
related to not muxing the pins right or using wrong timings for GPMC.

And then things that mostly change during the board development are
the GPIO pins, but those can be easily rewritten in the board-*.c
files based on the omap_rev.

But at least the device tree is a standard model, while the earlier
omap tag approach was non-standard.

Peter, maybe you've already thought through all this.. But would it be
possible to do lightweight device tree that we just use to populate
the platform data?

Regards,

Tony
--
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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Peter Barada]

On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> > > On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
> > >> Hi Tony,
> > >>
> > >> Current omap serial driver takes control of all 3 (4 on OMAP3640)
> > >> UARTS. However, we have such a setup where UART2 for example is used
> > >> by bluetooth driver. It uses the UART as non-standard way (there are
> > >> some Nokia extensions to H4 protocol) so we cannot use the standard
> > >> driver for driving the UART but have written special one for that
> > >> purpose.
> > >>
> > >> Question is: Is there any, upstreamable, way of preventing omap serial
> > >> driver to do this? Currently this is done with custom #ifdef hackery to
> > >> mach-omap2/serial.c. Alternative solution that comes into mind is to
> > >> specify UART configuration in board files and let serial driver to use
> > >> that instead of hard-coded one. Or do you have some nice alternatives?
> > >
> > > Previously (back around 2.6.28-rc8) in the board file, the
> > > omap_uart_config struct controlled which serial ports were enabled on
> > > startup.  It was used in omap_serial_init, and it looks like that code
> > > went away with the following commit:
> > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
> > >
> > > I'm kinda in the same boat as I want to use some of the unused serial
> > > port pins for GPIO, but they are setup as serial ports....
> 
> Sounds like we need something back to specify the ports to use
> from board-*.c files. Kevin, got any comments? 
>  
> > Not in mainlined yet, but I'm working on porting flattened device tree
> > support to OMAP to solve exactly this sort of problem.  Basically,
> > instead of hard coding or #ifdeffing things, a data blob gets handed
> > to the kernel at boot time telling it exactly what hardware is present
> > in a consistent, parsable format.  Device drivers then get probed
> > based on data in the device tree.  Here's some info on the approach:
> > 
> > http://www.elinux.org/Device_Trees
> > 
> > I expect to have my prototype ready for review mid-January, and most
> > of the common code should be either merged or queued up in linux-next
> > by that time.
> 
> While device tree is a nice solution to some of the problems, it still
> leaves all the issues we already have with buggy and and outdated
> bootloaders. So we still need to properly initialize the devices in
> the kernel.
> 
> Just for reference, most of the omap bootloader bugs seem to be
> related to not muxing the pins right or using wrong timings for GPMC.
> 
> And then things that mostly change during the board development are
> the GPIO pins, but those can be easily rewritten in the board-*.c
> files based on the omap_rev.
> 
> But at least the device tree is a standard model, while the earlier
> omap tag approach was non-standard.
> 
> Peter, maybe you've already thought through all this.. But would it be
> possible to do lightweight device tree that we just use to populate
> the platform data?

One possibility is to pass to omap_serial_init() the omap_uart_config
struct pointer to specify which parts are enabled.  If a NULL is passed
in, then enable all the ports available.  Since omap_serial_early_init()
was already called, the muxing would have to be cleaned up, but since
the kernel should mux all the pins it uses, that shouldn't be a problem.
omap_serial_init would now look something like(warning, coding on the
fly - don't know if it will work as is):

void __init omap_serial_init(struct omap_uart_config *confptr)
{
	int i;

	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
		struct omap_uart_state *uart = &omap_uart[i];
		struct platform_device *pdev = &uart->pdev;
		struct device *dev = &pdev->dev;

		/* Only enable
		if (!confptr || confptr->port_enabled & (1<<i)) {
			omap_uart_reset(uart);
			omap_uart_idle_init(uart);

			if (WARN_ON(platform_device_register(pdev)))
				continue;
			if ((cpu_is_omap34xx() && uart->padconf) ||
			    (uart->wk_en && uart->wk_mask)) {
				device_init_wakeup(dev, true);
				DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
			}
		}
	}
}

> Regards,
> 
> Tony

-- 
Peter Barada <peterb@logicpd.com>
Logic Product Development, Inc.

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Peter Barada <peterb@logicpd.com> [091130 12:30]:
> On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> > > > On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
> > > >> Hi Tony,
> > > >>
> > > >> Current omap serial driver takes control of all 3 (4 on OMAP3640)
> > > >> UARTS. However, we have such a setup where UART2 for example is used
> > > >> by bluetooth driver. It uses the UART as non-standard way (there are
> > > >> some Nokia extensions to H4 protocol) so we cannot use the standard
> > > >> driver for driving the UART but have written special one for that
> > > >> purpose.
> > > >>
> > > >> Question is: Is there any, upstreamable, way of preventing omap serial
> > > >> driver to do this? Currently this is done with custom #ifdef hackery to
> > > >> mach-omap2/serial.c. Alternative solution that comes into mind is to
> > > >> specify UART configuration in board files and let serial driver to use
> > > >> that instead of hard-coded one. Or do you have some nice alternatives?
> > > >
> > > > Previously (back around 2.6.28-rc8) in the board file, the
> > > > omap_uart_config struct controlled which serial ports were enabled on
> > > > startup.  It was used in omap_serial_init, and it looks like that code
> > > > went away with the following commit:
> > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
> > > >
> > > > I'm kinda in the same boat as I want to use some of the unused serial
> > > > port pins for GPIO, but they are setup as serial ports....
> > 
> > Sounds like we need something back to specify the ports to use
> > from board-*.c files. Kevin, got any comments? 
> >  
> > > Not in mainlined yet, but I'm working on porting flattened device tree
> > > support to OMAP to solve exactly this sort of problem.  Basically,
> > > instead of hard coding or #ifdeffing things, a data blob gets handed
> > > to the kernel at boot time telling it exactly what hardware is present
> > > in a consistent, parsable format.  Device drivers then get probed
> > > based on data in the device tree.  Here's some info on the approach:
> > > 
> > > http://www.elinux.org/Device_Trees
> > > 
> > > I expect to have my prototype ready for review mid-January, and most
> > > of the common code should be either merged or queued up in linux-next
> > > by that time.
> > 
> > While device tree is a nice solution to some of the problems, it still
> > leaves all the issues we already have with buggy and and outdated
> > bootloaders. So we still need to properly initialize the devices in
> > the kernel.
> > 
> > Just for reference, most of the omap bootloader bugs seem to be
> > related to not muxing the pins right or using wrong timings for GPMC.
> > 
> > And then things that mostly change during the board development are
> > the GPIO pins, but those can be easily rewritten in the board-*.c
> > files based on the omap_rev.
> > 
> > But at least the device tree is a standard model, while the earlier
> > omap tag approach was non-standard.
> > 
> > Peter, maybe you've already thought through all this.. But would it be
> > possible to do lightweight device tree that we just use to populate
> > the platform data?
> 
> One possibility is to pass to omap_serial_init() the omap_uart_config
> struct pointer to specify which parts are enabled.  If a NULL is passed
> in, then enable all the ports available.  Since omap_serial_early_init()
> was already called, the muxing would have to be cleaned up, but since
> the kernel should mux all the pins it uses, that shouldn't be a problem.
> omap_serial_init would now look something like(warning, coding on the
> fly - don't know if it will work as is):
> 
> void __init omap_serial_init(struct omap_uart_config *confptr)
> {
> 	int i;
> 
> 	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
> 		struct omap_uart_state *uart = &omap_uart[i];
> 		struct platform_device *pdev = &uart->pdev;
> 		struct device *dev = &pdev->dev;
> 
> 		/* Only enable
> 		if (!confptr || confptr->port_enabled & (1<<i)) {
> 			omap_uart_reset(uart);
> 			omap_uart_idle_init(uart);
> 
> 			if (WARN_ON(platform_device_register(pdev)))
> 				continue;
> 			if ((cpu_is_omap34xx() && uart->padconf) ||
> 			    (uart->wk_en && uart->wk_mask)) {
> 				device_init_wakeup(dev, true);
> 				DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
> 			}
> 		}
> 	}
> }

Yeah, I guess something like that would be good. We may want to
specify the optional other pins there too, typically it's just
RX and TX pins.

It could also be directly struct plat_serial8250_port array we
pass? Or does that make things more complicated to use the upcoming
omap serial driver?

Regards,

Tony

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Mika Westerberg]

On Mon, Nov 30, 2009 at 10:09:58PM +0100, ext Tony Lindgren wrote:
> * Peter Barada <peterb@logicpd.com> [091130 12:30]:
> > On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > > > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada <peterb@logicpd.com> wrote:
> > > > > On Mon, 2009-11-30 at 10:46 +0200, Mika Westerberg wrote:
> > > > >> Hi Tony,
> > > > >>
> > > > >> Current omap serial driver takes control of all 3 (4 on OMAP3640)
> > > > >> UARTS. However, we have such a setup where UART2 for example is used
> > > > >> by bluetooth driver. It uses the UART as non-standard way (there are
> > > > >> some Nokia extensions to H4 protocol) so we cannot use the standard
> > > > >> driver for driving the UART but have written special one for that
> > > > >> purpose.
> > > > >>
> > > > >> Question is: Is there any, upstreamable, way of preventing omap serial
> > > > >> driver to do this? Currently this is done with custom #ifdef hackery to
> > > > >> mach-omap2/serial.c. Alternative solution that comes into mind is to
> > > > >> specify UART configuration in board files and let serial driver to use
> > > > >> that instead of hard-coded one. Or do you have some nice alternatives?
> > > > >
> > > > > Previously (back around 2.6.28-rc8) in the board file, the
> > > > > omap_uart_config struct controlled which serial ports were enabled on
> > > > > startup.  It was used in omap_serial_init, and it looks like that code
> > > > > went away with the following commit:
> > > > > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blobdiff;f=arch/arm/mach-omap2/serial.c;h=2e17b57f5b23bb6703a2d621103585af1d8d729b;hp=555e735524381cbf8ef9f20d778ad81f9438e24e;hb=4355c41a635943d30e9396b95185314343dcb551;hpb=7e9ccf7776bb68b5367eb0bb35e519df62bea35c
> > > > >
> > > > > I'm kinda in the same boat as I want to use some of the unused serial
> > > > > port pins for GPIO, but they are setup as serial ports....
> > > 
> > > Sounds like we need something back to specify the ports to use
> > > from board-*.c files. Kevin, got any comments? 
> > >  
> > > > Not in mainlined yet, but I'm working on porting flattened device tree
> > > > support to OMAP to solve exactly this sort of problem.  Basically,
> > > > instead of hard coding or #ifdeffing things, a data blob gets handed
> > > > to the kernel at boot time telling it exactly what hardware is present
> > > > in a consistent, parsable format.  Device drivers then get probed
> > > > based on data in the device tree.  Here's some info on the approach:
> > > > 
> > > > http://www.elinux.org/Device_Trees
> > > > 
> > > > I expect to have my prototype ready for review mid-January, and most
> > > > of the common code should be either merged or queued up in linux-next
> > > > by that time.
> > > 
> > > While device tree is a nice solution to some of the problems, it still
> > > leaves all the issues we already have with buggy and and outdated
> > > bootloaders. So we still need to properly initialize the devices in
> > > the kernel.
> > > 
> > > Just for reference, most of the omap bootloader bugs seem to be
> > > related to not muxing the pins right or using wrong timings for GPMC.
> > > 
> > > And then things that mostly change during the board development are
> > > the GPIO pins, but those can be easily rewritten in the board-*.c
> > > files based on the omap_rev.
> > > 
> > > But at least the device tree is a standard model, while the earlier
> > > omap tag approach was non-standard.
> > > 
> > > Peter, maybe you've already thought through all this.. But would it be
> > > possible to do lightweight device tree that we just use to populate
> > > the platform data?
> > 
> > One possibility is to pass to omap_serial_init() the omap_uart_config
> > struct pointer to specify which parts are enabled.  If a NULL is passed
> > in, then enable all the ports available.  Since omap_serial_early_init()
> > was already called, the muxing would have to be cleaned up, but since
> > the kernel should mux all the pins it uses, that shouldn't be a problem.
> > omap_serial_init would now look something like(warning, coding on the
> > fly - don't know if it will work as is):
> > 
> > void __init omap_serial_init(struct omap_uart_config *confptr)
> > {
> > 	int i;
> > 
> > 	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
> > 		struct omap_uart_state *uart = &omap_uart[i];
> > 		struct platform_device *pdev = &uart->pdev;
> > 		struct device *dev = &pdev->dev;
> > 
> > 		/* Only enable
> > 		if (!confptr || confptr->port_enabled & (1<<i)) {
> > 			omap_uart_reset(uart);
> > 			omap_uart_idle_init(uart);
> > 
> > 			if (WARN_ON(platform_device_register(pdev)))
> > 				continue;
> > 			if ((cpu_is_omap34xx() && uart->padconf) ||
> > 			    (uart->wk_en && uart->wk_mask)) {
> > 				device_init_wakeup(dev, true);
> > 				DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
> > 			}
> > 		}
> > 	}
> > }
> 
> Yeah, I guess something like that would be good. We may want to
> specify the optional other pins there too, typically it's just
> RX and TX pins.
> 
> It could also be directly struct plat_serial8250_port array we
> pass? Or does that make things more complicated to use the upcoming
> omap serial driver?

How about something like in the patch attached?

Then for example we would do in board-rx51.c:
	...
	omap_serial_init_port(2);

(we only use UART3 as serial port).

I quickly tested this with RX-51 and seems to work.

Thanks,
MW

---

From: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
Date: Tue, 1 Dec 2009 12:54:21 +0200
Subject: [PATCH] OMAP3: serial - allow platforms specify which UARTs to initialize

This patch adds new function: omap_serial_init_port(port) that can be
used to initialize only selected UARTs as serial ports. Platforms can
then in their board files call this function instead of omap_serial_init()
if they don't want to use all UARTs as serial ports.

Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
---
 arch/arm/mach-omap2/serial.c             |   59 +++++++++++++++++++++++-------
 arch/arm/plat-omap/include/plat/serial.h |    1 +
 2 files changed, 46 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..fe46560 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -631,24 +631,55 @@ void __init omap_serial_early_init(void)
 	}
 }
 
+/**
+ * omap_serial_init_port() - initialize single serial port
+ * @port: serial port number (0-3)
+ *
+ * This function initialies serial driver for given @port only.
+ * Platforms can call this function instead of omap_serial_init()
+ * if they don't plan to use all available UARTs as serial ports.
+ *
+ * Don't mix calls to omap_serial_init_port() and omap_serial_init(),
+ * use only one of the two.
+ */
+void __init omap_serial_init_port(int port)
+{
+	struct omap_uart_state *uart;
+	struct platform_device *pdev;
+	struct device *dev;
+
+	BUG_ON(port < 0);
+	BUG_ON(port >= ARRAY_SIZE(omap_uart));
+
+	uart = &omap_uart[port];
+	pdev = &uart->pdev;
+	dev = &pdev->dev;
+
+	omap_uart_reset(uart);
+	omap_uart_idle_init(uart);
+
+	if (WARN_ON(platform_device_register(pdev)))
+		return;
+
+	if ((cpu_is_omap34xx() && uart->padconf) ||
+	    (uart->wk_en && uart->wk_mask)) {
+		device_init_wakeup(dev, true);
+		DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
+	}
+}
+
+/**
+ * omap_serial_init() - intialize all supported serial ports
+ *
+ * Initializes all available UARTs as serial ports. Platforms
+ * can call this function when they want to have default behaviour
+ * for serial ports (e.g initialize them all as serial ports).
+ */
 void __init omap_serial_init(void)
 {
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
-		struct omap_uart_state *uart = &omap_uart[i];
-		struct platform_device *pdev = &uart->pdev;
-		struct device *dev = &pdev->dev;
-
-		omap_uart_reset(uart);
-		omap_uart_idle_init(uart);
-
-		if (WARN_ON(platform_device_register(pdev)))
-			continue;
-		if ((cpu_is_omap34xx() && uart->padconf) ||
-		    (uart->wk_en && uart->wk_mask)) {
-			device_init_wakeup(dev, true);
-			DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
-		}
+		omap_serial_init_port(i);
 	}
 }
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index 9951345..f5a4a92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -53,6 +53,7 @@
 #ifndef __ASSEMBLER__
 extern void __init omap_serial_early_init(void);
 extern void omap_serial_init(void);
+extern void omap_serial_init_port(int port);
 extern int omap_uart_can_sleep(void);
 extern void omap_uart_check_wakeup(void);
 extern void omap_uart_prepare_suspend(void);
-- 
1.5.6.5

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Kevin Hilman]

[sorry for being late to the party, I've been on vacation]

Mika Westerberg <ext-mika.1.westerberg@nokia.com> writes:

[...]

> How about something like in the patch attached?
>
> Then for example we would do in board-rx51.c:
> 	...
> 	omap_serial_init_port(2);
>
> (we only use UART3 as serial port).
>
> I quickly tested this with RX-51 and seems to work.
>

I like this approach.

I'm against going back to the previsus platform_data extending
approach since it requires doing different stuff when using 8250 or
the upcoming omap-serial driver.

>
> ---
>
> From: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> Date: Tue, 1 Dec 2009 12:54:21 +0200
> Subject: [PATCH] OMAP3: serial - allow platforms specify which UARTs to initialize
>
> This patch adds new function: omap_serial_init_port(port) that can be
> used to initialize only selected UARTs as serial ports. Platforms can
> then in their board files call this function instead of omap_serial_init()
> if they don't want to use all UARTs as serial ports.
>
> Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>

Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>


> ---
>  arch/arm/mach-omap2/serial.c             |   59 +++++++++++++++++++++++-------
>  arch/arm/plat-omap/include/plat/serial.h |    1 +
>  2 files changed, 46 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 2e17b57..fe46560 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -631,24 +631,55 @@ void __init omap_serial_early_init(void)
>  	}
>  }
>  
> +/**
> + * omap_serial_init_port() - initialize single serial port
> + * @port: serial port number (0-3)
> + *
> + * This function initialies serial driver for given @port only.
> + * Platforms can call this function instead of omap_serial_init()
> + * if they don't plan to use all available UARTs as serial ports.
> + *
> + * Don't mix calls to omap_serial_init_port() and omap_serial_init(),
> + * use only one of the two.
> + */
> +void __init omap_serial_init_port(int port)
> +{
> +	struct omap_uart_state *uart;
> +	struct platform_device *pdev;
> +	struct device *dev;
> +
> +	BUG_ON(port < 0);
> +	BUG_ON(port >= ARRAY_SIZE(omap_uart));
> +
> +	uart = &omap_uart[port];
> +	pdev = &uart->pdev;
> +	dev = &pdev->dev;
> +
> +	omap_uart_reset(uart);
> +	omap_uart_idle_init(uart);
> +
> +	if (WARN_ON(platform_device_register(pdev)))
> +		return;
> +
> +	if ((cpu_is_omap34xx() && uart->padconf) ||
> +	    (uart->wk_en && uart->wk_mask)) {
> +		device_init_wakeup(dev, true);
> +		DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
> +	}
> +}
> +
> +/**
> + * omap_serial_init() - intialize all supported serial ports
> + *
> + * Initializes all available UARTs as serial ports. Platforms
> + * can call this function when they want to have default behaviour
> + * for serial ports (e.g initialize them all as serial ports).
> + */
>  void __init omap_serial_init(void)
>  {
>  	int i;
>  
>  	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
> -		struct omap_uart_state *uart = &omap_uart[i];
> -		struct platform_device *pdev = &uart->pdev;
> -		struct device *dev = &pdev->dev;
> -
> -		omap_uart_reset(uart);
> -		omap_uart_idle_init(uart);
> -
> -		if (WARN_ON(platform_device_register(pdev)))
> -			continue;
> -		if ((cpu_is_omap34xx() && uart->padconf) ||
> -		    (uart->wk_en && uart->wk_mask)) {
> -			device_init_wakeup(dev, true);
> -			DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
> -		}
> +		omap_serial_init_port(i);
>  	}
>  }
> diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
> index 9951345..f5a4a92 100644
> --- a/arch/arm/plat-omap/include/plat/serial.h
> +++ b/arch/arm/plat-omap/include/plat/serial.h
> @@ -53,6 +53,7 @@
>  #ifndef __ASSEMBLER__
>  extern void __init omap_serial_early_init(void);
>  extern void omap_serial_init(void);
> +extern void omap_serial_init_port(int port);
>  extern int omap_uart_can_sleep(void);
>  extern void omap_uart_check_wakeup(void);
>  extern void omap_uart_prepare_suspend(void);
> -- 
> 1.5.6.5
>
> --
> 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

[PATCH] OMAP3: serial - allow platforms specify which UARTs to initialize

[Mika Westerberg]

From: Mika Westerberg <ext-mika.1.westerberg@nokia.com>

This patch adds new function: omap_serial_init_port(port) that can be
used to initialize only selected UARTs as serial ports. Platforms can
then in their board files call this function instead of omap_serial_init()
if they don't want to use all UARTs as serial ports.

Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
I refreshed this against latest l-o master and added Kevins SoB. Tested
with RX-51.

 arch/arm/mach-omap2/serial.c             |   78 ++++++++++++++++++++---------
 arch/arm/plat-omap/include/plat/serial.h |    1 +
 2 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index e853115..eb2ba6e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -649,34 +649,64 @@ void __init omap_serial_early_init(void)
 	}
 }
 
-void __init omap_serial_init(void)
+/**
+ * omap_serial_init_port() - initialize single serial port
+ * @port: serial port number (0-3)
+ *
+ * This function initialies serial driver for given @port only.
+ * Platforms can call this function instead of omap_serial_init()
+ * if they don't plan to use all available UARTs as serial ports.
+ *
+ * Don't mix calls to omap_serial_init_port() and omap_serial_init(),
+ * use only one of the two.
+ */
+void __init omap_serial_init_port(int port)
 {
-	int i;
+	struct omap_uart_state *uart;
+	struct platform_device *pdev;
+	struct device *dev;
 
-	for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
-		struct omap_uart_state *uart = &omap_uart[i];
-		struct platform_device *pdev = &uart->pdev;
-		struct device *dev = &pdev->dev;
+	BUG_ON(port < 0);
+	BUG_ON(port >= ARRAY_SIZE(omap_uart));
 
-		omap_uart_reset(uart);
-		omap_uart_idle_init(uart);
+	uart = &omap_uart[port];
+	pdev = &uart->pdev;
+	dev = &pdev->dev;
 
-		if (WARN_ON(platform_device_register(pdev)))
-			continue;
-		if ((cpu_is_omap34xx() && uart->padconf) ||
-		    (uart->wk_en && uart->wk_mask)) {
-			device_init_wakeup(dev, true);
-			DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
-		}
+	omap_uart_reset(uart);
+	omap_uart_idle_init(uart);
 
-		/* omap44xx: Never read empty UART fifo
-		 * omap3xxx: Never read empty UART fifo on UARTs
-		 * with IP rev >=0x52
-		 */
-		if (cpu_is_omap44xx())
-			uart->p->serial_in = serial_in_override;
-		else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
-				>= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
-			uart->p->serial_in = serial_in_override;
+	if (WARN_ON(platform_device_register(pdev)))
+		return;
+
+	if ((cpu_is_omap34xx() && uart->padconf) ||
+	    (uart->wk_en && uart->wk_mask)) {
+		device_init_wakeup(dev, true);
+		DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
 	}
+
+	/* omap44xx: Never read empty UART fifo
+	 * omap3xxx: Never read empty UART fifo on UARTs
+	 * with IP rev >=0x52
+	 */
+	if (cpu_is_omap44xx())
+		uart->p->serial_in = serial_in_override;
+	else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
+			>= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
+		uart->p->serial_in = serial_in_override;
+}
+
+/**
+ * omap_serial_init() - intialize all supported serial ports
+ *
+ * Initializes all available UARTs as serial ports. Platforms
+ * can call this function when they want to have default behaviour
+ * for serial ports (e.g initialize them all as serial ports).
+ */
+void __init omap_serial_init(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(omap_uart); i++)
+		omap_serial_init_port(i);
 }
diff --git a/arch/arm/plat-omap/include/plat/serial.h b/arch/arm/plat-omap/include/plat/serial.h
index 9951345..f5a4a92 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -53,6 +53,7 @@
 #ifndef __ASSEMBLER__
 extern void __init omap_serial_early_init(void);
 extern void omap_serial_init(void);
+extern void omap_serial_init_port(int port);
 extern int omap_uart_can_sleep(void);
 extern void omap_uart_check_wakeup(void);
 extern void omap_uart_prepare_suspend(void);
-- 
1.5.6.5

[APPLIED] [PATCH] OMAP3: serial - allow platforms specify which UARTs to

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: for-next

Initial commit ID (Likely to change): e663f3a6a9b58cff5b2f67267519ba1f75122b3b

PatchWorks
http://patchwork.kernel.org/patch/66232/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e663f3a6a9b58cff5b2f67267519ba1f75122b3b

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [091130 11:40]:
> * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
>  
> > Not in mainlined yet, but I'm working on porting flattened device tree
> > support to OMAP to solve exactly this sort of problem.  Basically,
> > instead of hard coding or #ifdeffing things, a data blob gets handed
> > to the kernel at boot time telling it exactly what hardware is present
> > in a consistent, parsable format.  Device drivers then get probed
> > based on data in the device tree.  Here's some info on the approach:
> > 
> > http://www.elinux.org/Device_Trees
> > 
> > I expect to have my prototype ready for review mid-January, and most
> > of the common code should be either merged or queued up in linux-next
> > by that time.
> 
> While device tree is a nice solution to some of the problems, it still
> leaves all the issues we already have with buggy and and outdated
> bootloaders. So we still need to properly initialize the devices in
> the kernel.
> 
> Just for reference, most of the omap bootloader bugs seem to be
> related to not muxing the pins right or using wrong timings for GPMC.
> 
> And then things that mostly change during the board development are
> the GPIO pins, but those can be easily rewritten in the board-*.c
> files based on the omap_rev.
> 
> But at least the device tree is a standard model, while the earlier
> omap tag approach was non-standard.
> 
> Peter, maybe you've already thought through all this.. But would it be
> possible to do lightweight device tree that we just use to populate
> the platform data?

Sorry, I meant to ask Grant this question as Grant (and not Peter)
is working on the device tree.

Tony

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Grant Likely]

On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
>> http://www.elinux.org/Device_Trees
>>
>> I expect to have my prototype ready for review mid-January, and most
>> of the common code should be either merged or queued up in linux-next
>> by that time.
>
> While device tree is a nice solution to some of the problems, it still
> leaves all the issues we already have with buggy and and outdated
> bootloaders. So we still need to properly initialize the devices in
> the kernel.

Yes, buggy firmware is still a problem.  However, if the required
configuration is described in the device tree data, then for some
things the driver can handle setting up the device and the amount of
board-specific code can be reduced.

> Just for reference, most of the omap bootloader bugs seem to be
> related to not muxing the pins right or using wrong timings for GPMC.
>
> And then things that mostly change during the board development are
> the GPIO pins, but those can be easily rewritten in the board-*.c
> files based on the omap_rev.
>
> But at least the device tree is a standard model, while the earlier
> omap tag approach was non-standard.
>
> Peter, maybe you've already thought through all this.. But would it be
> possible to do lightweight device tree that we just use to populate
> the platform data?

This is completely possible.  Just having the device tree available
doesn't force the kernel to use it for everything.  I've found it
useful to start small and add things as I need them.  Most important
thing to remember is to follow the documented & established device
tree conventions so that common code can understand it.

Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
connections in the device tree:
Documentation/powerpc/dts-bindings/gpio/gpio.txt

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Olof Johansson]

On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:

> Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
> connections in the device tree:
> Documentation/powerpc/dts-bindings/gpio/gpio.txt

That binding is more about documenting a bank of GPIO pins, while
chips like OMAP will need something a bit more flexible.

Given the flexibility and complexity of configuring the pins on
mobile-oriented SoCs where each function can come out a variety of
different pins, and many pins can 3 or 4 functions associated with them
(selected by software config), it will definitely bring a new level of
complexity to the device tree descriptions.

I'm definitely not saying that it is impossible, but it might take a
little work to hash out a binding that everyone will be happy with.


-Olof

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Grant Likely]

On Wed, Dec 2, 2009 at 8:53 AM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Dec 02, 2009 at 08:07:21AM -0700, Grant Likely wrote:
>
>> Oh, and speaking of GPIOs, there is a binding for describing GPIO pin
>> connections in the device tree:
>> Documentation/powerpc/dts-bindings/gpio/gpio.txt
>
> That binding is more about documenting a bank of GPIO pins, while
> chips like OMAP will need something a bit more flexible.
>
> Given the flexibility and complexity of configuring the pins on
> mobile-oriented SoCs where each function can come out a variety of
> different pins, and many pins can 3 or 4 functions associated with them
> (selected by software config), it will definitely bring a new level of
> complexity to the device tree descriptions.

Ah, you're talking about pin muxing configuration, right?  Yes, that
GPIO binding deals with controllers, not pin mux.  Pin mux is very
much an SoC specific thing that isn't mapped easily to a generic
binding.

On the 5200, I haven't attempted to describe pin-mux in the device
tree at all, and have either expected firmware to set it up correctly,
or fixed it up in the platform code.

> I'm definitely not saying that it is impossible, but it might take a
> little work to hash out a binding that everyone will be happy with.

Right.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Olof Johansson]

On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:

> Ah, you're talking about pin muxing configuration, right?  Yes, that
> GPIO binding deals with controllers, not pin mux.  Pin mux is very
> much an SoC specific thing that isn't mapped easily to a generic
> binding.

Yep.

> On the 5200, I haven't attempted to describe pin-mux in the device
> tree at all, and have either expected firmware to set it up correctly,
> or fixed it up in the platform code.

Yeah. And it's one of the things Tony commented on that firmware tends
to get wrong, seems like people aren't doing complete mux configs in
u-boot, etc.

So, if it needs to be fixed up in platform code, there will (likely) be
need for board-specific code there anyway. A bummer, since the device
tree would otherwise make it real easy to bring up new boards without
kernel code changes.


-Olof

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Grant Likely]

On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
>
>> Ah, you're talking about pin muxing configuration, right?  Yes, that
>> GPIO binding deals with controllers, not pin mux.  Pin mux is very
>> much an SoC specific thing that isn't mapped easily to a generic
>> binding.
>
> Yep.
>
>> On the 5200, I haven't attempted to describe pin-mux in the device
>> tree at all, and have either expected firmware to set it up correctly,
>> or fixed it up in the platform code.
>
> Yeah. And it's one of the things Tony commented on that firmware tends
> to get wrong, seems like people aren't doing complete mux configs in
> u-boot, etc.
>
> So, if it needs to be fixed up in platform code, there will (likely) be
> need for board-specific code there anyway. A bummer, since the device
> tree would otherwise make it real easy to bring up new boards without
> kernel code changes.

I didn't create a binding on the 5200 because I actually see very
little buggy firmware in that regard (partially because I kept telling
people to go fix their firmware).  :-)  If it ends up being the norm
that the kernel has to fix it for a given SoC, then I would create an
SoC-specific binding for pin mux configuration in the device tree so
that some degree of common code can still fix it up.

It should be feasible for board-specific code to be the exception, not the rule.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Grant Likely <grant.likely@secretlab.ca> [091202 09:24]:
> On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson <olof@lixom.net> wrote:
> > On Wed, Dec 02, 2009 at 09:04:49AM -0700, Grant Likely wrote:
> >
> >> Ah, you're talking about pin muxing configuration, right?  Yes, that
> >> GPIO binding deals with controllers, not pin mux.  Pin mux is very
> >> much an SoC specific thing that isn't mapped easily to a generic
> >> binding.
> >
> > Yep.
> >
> >> On the 5200, I haven't attempted to describe pin-mux in the device
> >> tree at all, and have either expected firmware to set it up correctly,
> >> or fixed it up in the platform code.
> >
> > Yeah. And it's one of the things Tony commented on that firmware tends
> > to get wrong, seems like people aren't doing complete mux configs in
> > u-boot, etc.
> >
> > So, if it needs to be fixed up in platform code, there will (likely) be
> > need for board-specific code there anyway. A bummer, since the device
> > tree would otherwise make it real easy to bring up new boards without
> > kernel code changes.
> 
> I didn't create a binding on the 5200 because I actually see very
> little buggy firmware in that regard (partially because I kept telling
> people to go fix their firmware).  :-)  If it ends up being the norm
> that the kernel has to fix it for a given SoC, then I would create an
> SoC-specific binding for pin mux configuration in the device tree so
> that some degree of common code can still fix it up.
> 
> It should be feasible for board-specific code to be the exception, not the rule.

The problem with pin multiplexing is that development boards such as
Beagle don't know the desired configuration in the bootloader.
There are pins available for connecting external hardware, such as
I2C, SPI, or whatever to the 16-bit GPMC bus. Also, the bootloaders
tend not to care about pin multiplexing for power management.

We now have kernel cmdline override for pin multiplexing, but
that does not help with adding platform_data for custom I2C or
SPI devices.

Just something to keep in mind, I still think we can benefit
from the open firmware support in various ways :)

Regards,

Tony
--
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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:

<snip>

> >
> > maybe you've already thought through all this.. But would it be
> > possible to do lightweight device tree that we just use to populate
> > the platform data?
> 
> This is completely possible.  Just having the device tree available
> doesn't force the kernel to use it for everything.  I've found it
> useful to start small and add things as I need them.  Most important
> thing to remember is to follow the documented & established device
> tree conventions so that common code can understand it.

OK, sounds good to me.

Tony

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Mika Westerberg]

On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> * Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> 
> <snip>
> 
> > >
> > > maybe you've already thought through all this.. But would it be
> > > possible to do lightweight device tree that we just use to populate
> > > the platform data?
> > 
> > This is completely possible.  Just having the device tree available
> > doesn't force the kernel to use it for everything.  I've found it
> > useful to start small and add things as I need them.  Most important
> > thing to remember is to follow the documented & established device
> > tree conventions so that common code can understand it.
> 
> OK, sounds good to me.

Hi,

This device tree stuff sounds like very cool way of doing things. Hope
it is ready soon :)

Meanwhile, would it be OK to implement something to get the serial driver
taking control of the all the UARTs? Any comments on adding new function
to mach-omap2/serial.c: omap_serial_init_port(int port) that could be
used from board files instead of omap_serial_init()?

Thanks,
MW

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Artem Bityutskiy]

On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > * Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > 
> > <snip>
> > 
> > > >
> > > > maybe you've already thought through all this.. But would it be
> > > > possible to do lightweight device tree that we just use to populate
> > > > the platform data?
> > > 
> > > This is completely possible.  Just having the device tree available
> > > doesn't force the kernel to use it for everything.  I've found it
> > > useful to start small and add things as I need them.  Most important
> > > thing to remember is to follow the documented & established device
> > > tree conventions so that common code can understand it.
> > 
> > OK, sounds good to me.
> 
> Hi,
> 
> This device tree stuff sounds like very cool way of doing things. Hope
> it is ready soon :)
> 
> Meanwhile, would it be OK to implement something to get the serial driver
> taking control of the all the UARTs? Any comments on adding new function
> to mach-omap2/serial.c: omap_serial_init_port(int port) that could be
> used from board files instead of omap_serial_init()?

Device tree is really promising, but we do need an alternative method
anyway, because not everyone will use the device tree. IOW, device tree
does not exist yet, and will not be mandatory, so an alternative is
required.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
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

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Tony Lindgren]

* Artem Bityutskiy <dedekind1@gmail.com> [091203 00:46]:
> On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> > On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > > * Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > > 
> > > <snip>
> > > 
> > > > >
> > > > > maybe you've already thought through all this.. But would it be
> > > > > possible to do lightweight device tree that we just use to populate
> > > > > the platform data?
> > > > 
> > > > This is completely possible.  Just having the device tree available
> > > > doesn't force the kernel to use it for everything.  I've found it
> > > > useful to start small and add things as I need them.  Most important
> > > > thing to remember is to follow the documented & established device
> > > > tree conventions so that common code can understand it.
> > > 
> > > OK, sounds good to me.
> > 
> > Hi,
> > 
> > This device tree stuff sounds like very cool way of doing things. Hope
> > it is ready soon :)
> > 
> > Meanwhile, would it be OK to implement something to get the serial driver
> > taking control of the all the UARTs? Any comments on adding new function
> > to mach-omap2/serial.c: omap_serial_init_port(int port) that could be
> > used from board files instead of omap_serial_init()?
> 
> Device tree is really promising, but we do need an alternative method
> anyway, because not everyone will use the device tree. IOW, device tree
> does not exist yet, and will not be mandatory, so an alternative is
> required.

Right, it sounds like the device tree won't solve all the issues.

But before we change anything with the mach-omap2/serial.c, let's wait
until we hear comments from Kevin.

Regards,

Tony

Re: Preventing OMAP3 serial driver to take control of all UARTs

[Mika Westerberg]

On Thu, Dec 03, 2009 at 11:52:44AM -0800, Tony Lindgren wrote:
> * Artem Bityutskiy <dedekind1@gmail.com> [091203 00:46]:
> > On Thu, 2009-12-03 at 08:56 +0200, Mika Westerberg wrote:
> > > On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote:
> > > > * Grant Likely <grant.likely@secretlab.ca> [091202 07:06]:
> > > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > > > > * Grant Likely <grant.likely@secretlab.ca> [091130 09:01]:
> > > > 
> > > > <snip>
> > > > 
> > > > > >
> > > > > > maybe you've already thought through all this.. But would it be
> > > > > > possible to do lightweight device tree that we just use to populate
> > > > > > the platform data?
> > > > > 
> > > > > This is completely possible.  Just having the device tree available
> > > > > doesn't force the kernel to use it for everything.  I've found it
> > > > > useful to start small and add things as I need them.  Most important
> > > > > thing to remember is to follow the documented & established device
> > > > > tree conventions so that common code can understand it.
> > > > 
> > > > OK, sounds good to me.
> > > 
> > > Hi,
> > > 
> > > This device tree stuff sounds like very cool way of doing things. Hope
> > > it is ready soon :)
> > > 
> > > Meanwhile, would it be OK to implement something to get the serial driver
> > > taking control of the all the UARTs? Any comments on adding new function
> > > to mach-omap2/serial.c: omap_serial_init_port(int port) that could be
> > > used from board files instead of omap_serial_init()?
> > 
> > Device tree is really promising, but we do need an alternative method
> > anyway, because not everyone will use the device tree. IOW, device tree
> > does not exist yet, and will not be mandatory, so an alternative is
> > required.
> 
> Right, it sounds like the device tree won't solve all the issues.
> 
> But before we change anything with the mach-omap2/serial.c, let's wait
> until we hear comments from Kevin.

Tony, Kevin,

Any comments on this?

Thanks,
MW