Hi Bernard,
On Mon, May 12, 2008 at 4:25 PM, Bernard Blackham
<[EMAIL PROTECTED]> wrote:
> > +/* Different peripheral ids */
> > +#define DAVINCI_TAG_UART 0x4f01
> > +#define DAVINCI_TAG_SERIAL_CONSOLE 0x4f02
> > +
> > +struct davinci_serial_console_config {
> > + u8 console_uart;
> > + u32 console_speed;
> > +};
> > +
> > +struct davinci_uart_config {
> > + /* Bit field of UARTs present; bit 0 --> UART1 */
> > + unsigned int enabled_uarts;
> > +};
>
> Hi Trilok,
>
> I've not yet done the I2C changes I said I would to support different board
> quirks on the I2C bus - each time I look at it, the OMAP way seems like
> overkill, and I started writing a simpler registration interface.
>
> But instead, does it make any sense to base it off your changes and add a
> "struct davinci_i2c_config" in a similar vein to the UARTs as you've done?
> In many cases (e.g. U-boot) the bootloader uses I2C and needs to know about
> the board's quirks too, so it makes sense to actually pass these in via the
> same tag mechanism.
>
> Do you have any thoughts on this?
Sorry for late reply. Passing through TAG can be one the option, we
need to be very cautious there, as some bootloaders can't pass
pointers, so we cant use pointers with TAGs. :).
OMAP approach might look little bit complex, because we have cpu
series from OMAP1 to OMAP3 and multiple controller instances varying
from one series to another. But I think OMAP like approach is the way
to go in future, as we never know which is the next DM6xxx processor
and what are the changes it carrying for I2C controllers.
--
---Trilok Soni
http://triloksoni.wordpress.com
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
