[PATCH] Add lvgl_hello: Sample Hello world app using littleVGL and libbsd

[Vijay Kumar Banerjee]

On Thu, Sep 5, 2019 at 3:08 PM Christian Mauderer <
christian.mauderer at 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 <chrisj at rtems.org
> >>>> <mailto:chrisj at 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?

Where should I be looking for to add i2c in BBB initialization?

Regards,
Vijay

> >
> > Chris
> >
>
> Best regards
>
> Christian
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190911/ba35a20d/attachment-0002.html>