| Message ID | 20140717074219.GA29193@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Sebastian Andrzej Siewior <bigeasy@linutronix.de> [140717 00:44]: > * Tony Lindgren | 2014-07-17 00:09:00 [-0700]: > > >Seems to boot a bit further now with output from serial console > >initially, then I'm getting the following error again that's probably > >related to clocks not enabled when the registers are accessed: > > It is (mostly) the same thing as before. We have additionally > omap_8250_startup() in the backtrace but it is the same thing. > So you say I miss a clock? Looking through serial8250_do_startup() I see: > - pm_runtime_get_sync(port->dev); which should get the clocks up > - serial8250_clear_fifos() which does a write at address + 8. Seems to > work. > - serial_port_in(port, UART_LSR); does a read at address + 0x14, seems > to work. > - serial_port_in(port, UART_RX); does a read at address + 0. This is > probably the bad one. 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/ > Now comparing with omap-serial I noticed that I do a 32bit access > instead a 16bit. > Could you please try the following hack: No change with that :) 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
On 07/17/2014 10:12 AM, Tony Lindgren wrote: > 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? > Regards, > > Tony Sebastian -- 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
* Sebastian Andrzej Siewior <bigeasy@linutronix.de> [140717 03:09]: > On 07/17/2014 10:12 AM, Tony Lindgren wrote: > > 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 -- 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
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 2e4a93b..94af5a3 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -420,13 +420,13 @@ static void mem_serial_out(struct uart_port *p, int offset, int value) static void mem32_serial_out(struct uart_port *p, int offset, int value) { offset = offset << p->regshift; - writel(value, p->membase + offset); + writew(value, p->membase + offset); } static unsigned int mem32_serial_in(struct uart_port *p, int offset) { offset = offset << p->regshift; - return readl(p->membase + offset); + return readw(p->membase + offset); } static unsigned int io_serial_in(struct uart_port *p, int offset)