Re: Preventing OMAP3 serial driver to take control of all UARTs
[sorry for being late to the party, I've been on vacation]
Mika Westerberg 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
> 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
Signed-off-by: Kevin Hilman
> ---
> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@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
On Thu, Dec 03, 2009 at 11:52:44AM -0800, Tony Lindgren wrote: > * Artem Bityutskiy [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 [091202 07:06]: > > > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren > > > > > wrote: > > > > > > * Grant Likely [091130 09:01]: > > > > > > > > > > > > > > > > > > > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
* Artem Bityutskiy [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 [091202 07:06]: > > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren > > > > wrote: > > > > > * Grant Likely [091130 09:01]: > > > > > > > > > > > > > > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
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 [091202 07:06]: > > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote: > > > > * Grant Likely [091130 09:01]: > > > > > > > > > > > > > > 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 majord...@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
On Thu, Dec 03, 2009 at 02:00:52AM +0100, ext Tony Lindgren wrote: > * Grant Likely [091202 07:06]: > > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote: > > > * Grant Likely [091130 09:01]: > > > > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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 [091202 07:06]: > On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote: > > * Grant Likely [091130 09:01]: > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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 [091202 09:24]: > On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson 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 majord...@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
On Wed, Dec 2, 2009 at 9:16 AM, Olof Johansson 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 majord...@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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
On Wed, Dec 2, 2009 at 8:53 AM, Olof Johansson 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
On Mon, Nov 30, 2009 at 12:40 PM, Tony Lindgren wrote: > * Grant Likely [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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
On Mon, Nov 30, 2009 at 10:09:58PM +0100, ext Tony Lindgren wrote:
> * Peter Barada [091130 12:30]:
> > On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> > > * Grant Likely [091130 09:01]:
> > > > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada
> > > > 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< > 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)) {
> >
Re: Preventing OMAP3 serial driver to take control of all UARTs
* Peter Barada [091130 12:30]:
> On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> > * Grant Likely [091130 09:01]:
> > > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada 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< 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 othe
Re: Preventing OMAP3 serial driver to take control of all UARTs
* Tony Lindgren [091130 11:40]: > * Grant Likely [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@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
On Mon, 2009-11-30 at 11:40 -0800, Tony Lindgren wrote:
> * Grant Likely [091130 09:01]:
> > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada 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 & (1wk_en && uart->wk_mask)) {
device_init_wakeup(dev, true);
DEV_CREATE_FILE(dev, &dev_attr_sleep_timeout);
}
}
}
}
> Regards,
>
> Tony
--
Peter Barada
Logic Product Development, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@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 [091130 09:01]: > On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada 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 majord...@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
On Mon, Nov 30, 2009 at 9:36 AM, Peter Barada 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 majord...@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
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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
