BBB Framebuffer driver : Project status
list at c-mauderer.de
Wed May 15 18:06:03 UTC 2019
On 14/05/2019 23:13, Vijay Kumar Banerjee wrote:
> Hello everyone!
> I have been active on the project and had offlist discussions about it
> with the mentors. To update the devel about the ongoing work I'm
> writing this status report and planning to write such status reports
> regularly to devel as most of the discussions are happening offlist
> with the mentors.
There should be at least all discussions with directional decisions on
the mailing list so that every one can comment and that the decision why
something has been decided that way is archived on the list.
Please add your mentors (including me) as CC when you send mails to the
list. Most people that use mailing lists have some kind of notification
if they are on CC so that they don't have to read the whole list all the
Please also note that although you have a number of dedicated mentors
everyone of the community who is interested can help too. I think there
is even some possibility to add mentors to a project after the start.
But I'm not sure of that.
If you want you can put some smaller topics (like compile problems or
similar) off list but it wouldn't be uncommon to have them in the list
too. All problems that are on the list can be later found using a search
engine and maybe help someone other with a similar problem. Everyone of
us had their learning phase. So don't be afraid of the list. There's a
saying in Germany that roughly translates as: "There are no stupid
questions. Only stupid answers."
> My forked repository for the rtems-libbsd can be found here
> All my work so far is in three branches in my forked repo.
> The am335x_lcd branch contains the commits for importing and
> porting the am335x_lcd drivers and the tda19988 branch has all
> the lcd and tda driver commits.
We already discussed that: The basic direction is fine.
> The hdmi framer communicates through the i2c bus and uses the
> iicbus driver from the freebsd source. Since RTEMS already
> supports the i2c very nicely in the target board, we have decided
> to write an adaptation layer of i2c driver that will use the RTEMS
> i2c driver throught the FreeBSD API.
I still think that's a good way that can be useful for other
applications too. But let's see whether someone has more comments
> All the imported codes along
> with the porting commit, which includes the adaptation layer,
Please split the adaption layer into an extra commit. I think that this
can be made ready quite soon and it can be commited to master totally
independent of the rest of the work.
> can be
> found in the iicbus branch in the above mentioned repository. The
> adaptation layer is currently in a basic state and it compiles without
> any warning, to make it work with the FreeBSD API. I also wrote
> a device tree overlay and applied it throught u-boot to get the device
> path with the OF_getprop* calls.
> The overlay device tree source can be found in the following gist
Again: Split the adaption layer into it's own commit. Please add some
test case that used the FreeBSD i2c API (maybe some simple i2c command
or access to some i2c EEPROM). If you are very ambitious you could try
to port the FreeBSD i2c command:
>From a quick glance it seems a quite simple command with only one c file
and without any global variables. So it shouldn't be too hard to port.
> I wanted to mention that since I came to know about all the mentors
> only after the GSoC results were declared, most of my discussions
> were offlist with Christian. From now on I will CC all the mentors
> in project-related discussions, to be able to get feedback and advice
> from all the mentors.
Again: Don't be afraid of the list. Most discussions can be public. We
could have already discussed the i2c driver on the list.
> Thank you
> -- vijay
> devel mailing list
> devel at rtems.org
More information about the devel