Hi Sekhar, > > > > > +#if defined(CONFIG_ARCH_DAVINCI_DMx) > > > > > +#define UART_PHYS DAVINCI_UART0_BASE > > > > > +#define UART_VIRT IO_ADDRESS(UART_PHYS) > > > > > +#endif > > > > > > > > These UART addressed are machine-, not arch-specific. > > > > On second thoughts, if we were to make these definitions machine > > specific, it would explode into excruciating verbosity: > > Is that the preferred approach? Would we be better off leaving > > UART selection arch-specific for now and making it machine > > specific as and when a new board deviates from the norm on that > > arch? > > How about trying to do some runtime detection of the enabled > UART by checking the enabled status in PWREMU_MGMT register of > each UART starting from UART0. You would probably also need a > fall-back option that can be chosen by boards on which this is > guaranteed not to work (they can provide the debug UART# in kernel > configuration). > > I quickly checked DM644x and OMAP-L138 documentation and both > of these have the register implemented and have the UART reset > by default. > > OMAP2/3 seems to manage this by writing a pattern to the UART SCR > registers, but unfortunately none of the DaVinci bootloaders > support this.
Ouch. PWREMU registers don't exist on TNETV107X. Second, if any of these probed UARTs happen to be in reset, poking around with their registers may be a bad idea. Since these macros are used pretty early in the boot process, I think the simpler the better. Regards Cyril. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
