* Rick Bronson <rick@xxxxxxx> [081102 10:07]: > > > Leaving only one map_desc[] entry left using MT_DEVICE not MT_MEMORY_SO... > > I didn't try this, since I'm currently not hooking up that serial port, > > but dmesg does show(*): > > > > Serial: 8250/16550 driver3 ports, IRQ sharing disabled > > serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 > > serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 > > serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16650V2 > > console [ttyS2] enabled > > > > Is that what you saw too? > > Yep, that's what I saw, but only if I had DEBUG_LL=y. Without that > I had nothing except "Uncompressing Linux........". ST16650V2 is a > clue that something went awry in auto-detection of the type of 8250 > serial port. With the MT_MEMORY_SO change, I get: > > Serial: 8250/16550 driver4 ports, IRQ sharing enabled > serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 > serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654 > serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654 > console [ttyS2] enabled > > I guess we don't see this problem on the other 2 ports since they > are mapped MT_MEMORY_SO and not MT_DEVICE (L4_34XX_PHYS). Rick, can you please reply with your Signed-off-by for your patch? Let's push that one, then continue thinking about the so/device issues. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
