On 11/09/2019 10:48, Vijay Kumar Banerjee wrote: > > > > On Thu, Sep 5, 2019 at 3:08 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> wrote: > > Sorry for the late reply. This mail slipped my attention. > > On 03/09/2019 08:22, Chris Johns wrote: > > On 3/9/19 3:30 pm, Christian Mauderer wrote: > >> 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> > >>>> <mailto: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. > > > > I suggest the I2C driver init is part of the BBB BSP and not part > of every BSP. > > I do not see this as the same as the FDT code then again I have > not looked at > > the detail. > > Clearly I used the wrong terms. Sorry for the confusion. I meant that it > will link in the I2C support for every application regardless whether > I2C is used or not. Joel mentioned that he would prefer it if not all > drivers are linked in automatically during the FDT support > discussion. See: > > https://lists.rtems.org/pipermail/devel/2019-August/027265.html > > Joel wrote there: "I think this is a good idea if we can still avoid > bloating apps with all drivers." > > Like I said: I wouldn't mind a small driver like I2C but we should have > all agree to it. > > > > >> 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.) > > > > Maybe I am not understanding the issue. I thought there is I2C > code is present > > in libbsd for the BBB frame buffer so when the frame buffer is > initialised some > > I2C activity happens. If the BBB I2C is not initialised the driver > will fail or > > the display will not be initialised and this is why the example > has the code to > > initialise the bus. > > Right. > > > > > Examples should not contain BSP specific initialisations or we > have to manage > > specific builds of the examples and that is problematic. > > Fully agreed. Just not sure how that could be solved (without adding the > I2C driver). > > Hi, > > Since adding I2C in BBB initialization seems like the right solution, > should we ask > in devel and user lists in a separate thread, to know if anyone is > opposed to this change?
Hello Vijay, just send a patch. That will start the discussion if someone objects to it. > > Where should I be looking for to add i2c in BBB initialization? Please take a look at the dependencies. If there are any (like clocks or similar) you have to add it afterwards. Take a look at some other BSPs where similar hardware (like I2C, SPI, some external chips, ...) is initialized. For example the mvme3100 uses a RTEMS_SYSINIT_ITEM to pick a random sample. But I think most BSPs use a special init function similar to the one in BBB. Best regards Christian > > Regards, > Vijay > > > > > Chris > > > > Best regards > > Christian > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > <mailto: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. > -- -------------------------------------------- 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
