On 03/09/2019 01:46, Chris Johns wrote: > On 2/9/19 5:42 pm, Vijay Kumar Banerjee wrote: >> On Mon, Sep 2, 2019 at 4:34 AM Chris Johns <chr...@rtems.org >> <mailto:chr...@rtems.org>> wrote: >> > + puts("\nRTEMS I2C TEST\n"); >> > + exit_code = bbb_register_i2c_0(); >> > + assert(exit_code == 0); >> >> Is this needed for the display to work? >> >> Yes. We need to register the rtems i2c device in order to work with the TDA >> driver >> as libbsd uses rtems i2c driver. The bbb_register_* is making it bbb >> specific, what >> do you suggest to make it more generic? > > Should the I2C be registered during the BSP initalisation? This would remove > the > need for this type of call being spread across all applications on the BBB. > The > BBB has a lot of resources and the I2C is part of the SoC and so always > present. > > I cannot think of a way to have a sysinit entry that installs the driver when > the I2C bus used. > > Chris
Hello Chris, I would also prefer that the I2C is initialized during BSP init. But note that this opens the same discussion we had with Joel when I suggested the FDT support as a project: It links in the Support for every BSP. I don't really think it hurts for a small driver like I2C on a big target like BBB but we should make sure that everyone is OK with that. What might could be a problem: Is there something in the initialization that might is application specific? The still bad solution for pin config for example? (@Vijay: Bad because it's hard coded in I2C driver and not due to the double init.) Best regards Christian -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
