* Sebastian Andrzej Siewior [off-list ref] [140717 03:09]:

On 07/17/2014 10:12 AM, Tony Lindgren wrote:

quoted

Hmm it could be that it works for a while because the clocks are on
from the bootloader and pm_runtime calls won't do anything. This
could happen if the interconnect data based on the ti,hwmods entry
is not getting matched to the new driver. This gets initialized when
the device entry gets created in omap_device_build_from_dt().

Or maybe something now affects the clock aliases? It seems that we
are still missing the clocks entries in the .dtsi files, see the
mappings with $ git grep uart drivers/clk/ti/

I've been looking for something completely different while I noticed
this:

in drivers/tty/serial/omap-serial.c
| static struct platform_driver serial_omap_driver = {
|         .driver         = {
|                 .name   = DRIVER_NAME,
|         },
| };
|

and DRIVER_NAME should come from include/linux/platform_data/serial-omap.h
Looking further, I've found arch/arm/mach-omap2/serial.c:
| void __init omap_serial_init_port(struct omap_board_data *bdata,
|                         struct omap_uart_port_info *info)
| {
|         char *name
?
|	name = DRIVER_NAME;
?
|	pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size);
?
|

Would this explain it?

That would explain it for legacy booting, but not for device tree
based booting. I can try to debug it further on Monday.

Regards,

Tony