<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 21, 2019 at 12:08 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 18.04.19 um 21:11 schrieb Vijay Kumar Banerjee:<br>
> <br>
> <br>
> On Thu, Apr 18, 2019 at 12:39 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> First: Please note that I changed the toppic. The old one just didn't<br>
> represent the content any more.<br>
> <br>
> Am 17.04.19 um 20:40 schrieb Vijay Kumar Banerjee:<br>
> [...]<br>
> > > ><br>
> > > > Am 09.04.19 um 18:12 schrieb Vijay Kumar Banerjee:<br>
> > > > > Hi,<br>
> > > > ><br>
> > > > > I have imported and ported the the drivers in 2<br>
> > pairs(import<br>
> > > and port)<br>
> > > > > of commits <br>
> > > > > for each one. Please have a look at this branch <br>
> > > > ><br>
> > <a href="https://github.com/thelunatic/rtems-libbsd/commits/tda19988" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems-libbsd/commits/tda19988</a><br>
> > > ><br>
> > > > One detail: You have a commit named "tda19988.c:<br>
> import from<br>
> > > FreeBSD".<br>
> > > > Please remove the ".c".<br>
> > > ><br>
> > > > Noted. <br>
> > > ><br>
> > > > Maybe it would be a good idea to split of the I2C part<br>
> > and put<br>
> > > it in<br>
> > > > front of the other two parts. You can develop and<br>
> test that<br>
> > > independent<br>
> > > > with a test that just accesses some of the I2C devices<br>
> > on the<br>
> > > board via<br>
> > > > the FreeBSD API and the translation driver<br>
> discussed below.<br>
> > > ><br>
> > > > This is a good idea, I'll import iicbus separately and add<br>
> > the other <br>
> > > > two on top of it. <br>
> > > ><br>
> > > > ><br>
> > > > > I have also tried running the media01.exe and<br>
> have seen it<br>
> > > running<br>
> > > > fine<br>
> > > > > without<br>
> > > > > throwing any exceptions.<br>
> > > > ><br>
> > > > > I have used the fb.c and iicbus.c codes from the<br>
> > > freebsd source. From<br>
> > > > > what I <br>
> > > > > understand, I think the next big steps would be to<br>
> > write an<br>
> > > RTEMS <br>
> > > > > implementation layer for these portions of the code?<br>
> > And then a<br>
> > > > test in the <br>
> > > > > libbsd, like media01, to write to the /dev/fb0 <br>
> > > > ><br>
> > > > > Can you please help me chalk out a rough outline of<br>
> > the next<br>
> > > set of<br>
> > > > > actions? :)<br>
> > > ><br>
> > > > As far as I can tell, there are two possible I2C<br>
> buses here:<br>
> > > ><br>
> > > > 1. The one between the AM335x and the TDA19988.<br>
> > > ><br>
> > > > 2. The one directly on the HDMI connector (called<br>
> > HDMI_DSCL and<br>
> > > > HDMI_DSDA). I assume that's an I2C bus too.<br>
> > > ><br>
> > > > For 1. the RTEMS driver should be used. You'll<br>
> need some<br>
> > code that<br>
> > > > translates the FreeBSD API to the one used in RTEMS.<br>
> > Basically<br>
> > > that will<br>
> > > > just be a FreeBSD-I2C-driver.<br>
> > > ><br>
> > > > For 2: If that even is an independent I2C bus, you can<br>
> > use the<br>
> > > driver<br>
> > > > provided by FreeBSD. I don't think that it is<br>
> necessary to<br>
> > > translate to<br>
> > > > the RTEMS API here.<br>
> > > ><br>
> > > > I had a look at the iic and iicbus codes in freebsd<br>
> and the<br>
> > bbb-i2c.c<br>
> > > > This looks very confusing to me. Are we looking for<br>
> > something like a<br>
> > > > rtems-iicbus.c in the rtemsbsd that works like a<br>
> wrapper to the<br>
> > > bbb-i2c<br>
> > > > code, and uses the freebsd api of DEVMETHODs?<br>
> > ><br>
> > > Yes correct. Basically it would be necessary to have a I2C<br>
> > device driver<br>
> > > for FreeBSD that translates to the RTEMS API.<br>
> > ><br>
> > > ><br>
> > > > I've not been able to figure out at one look, how to<br>
> relate<br>
> > them and <br>
> > > > get a wrapper like that. Any suggestions on how to<br>
> approach<br>
> > this?<br>
> > ><br>
> > > I haven't had a look at the FreeBSD drivers yet. The first<br>
> > part that I<br>
> > > would have a look at is the description of the user facing<br>
> > FreeBSD API:<br>
> > ><br>
> > > <br>
> > <br>
> <a href="https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html" rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html</a><br>
> > ><br>
> > > Nice thing: They use a struct iic_msg that is compatible<br>
> with<br>
> > Linux's<br>
> > > struct i2c_msg (according to the man page). We are Linux<br>
> > compatible too.<br>
> > > Can be a big advantage.<br>
> > ><br>
> > > Then take a look at the simplest i2c driver that you can<br>
> find<br>
> > in FreeBSD<br>
> > > that uses the transfer API.<br>
> > > freebsd-org/sys/dev/drm2/radeon/atombios_i2c.c looks<br>
> good to me.<br>
> > > Basically you have to implement the following functions<br>
> (replace<br>
> > > radeon_atom... by a useful prefix):<br>
> > ><br>
> > > static device_method_t radeon_atom_hw_i2c_methods[] = {<br>
> > > DEVMETHOD(device_probe, <br>
> radeon_atom_hw_i2c_probe),<br>
> > > DEVMETHOD(device_attach, <br>
> > radeon_atom_hw_i2c_attach),<br>
> > > DEVMETHOD(device_detach, <br>
> > radeon_atom_hw_i2c_detach),<br>
> > > DEVMETHOD(iicbus_reset, <br>
> radeon_atom_hw_i2c_reset),<br>
> > > DEVMETHOD(iicbus_transfer, <br>
> radeon_atom_hw_i2c_xfer),<br>
> > > DEVMETHOD_END<br>
> > > };<br>
> > ><br>
> > > The iicbus_transfer function seems to get a struct<br>
> iic_msg as a<br>
> > > parameter. Now that's really lucky.<br>
> > ><br>
> > > With that you should be able to open the i2c device in RTEMS<br>
> > and just<br>
> > > pass the structure via the correct ioctl call to the<br>
> RTEMS driver.<br>
> > ><br>
> > > Basically you just have to pass the bus to use as a<br>
> parameter<br>
> > to the<br>
> > > driver. Take a look at some of the other drivers in<br>
> > nexus-devices.h that<br>
> > > have for example an address as a parameter to see how<br>
> you can<br>
> > do that.<br>
> > ><br>
> > > This gave a good idea of the objective. :)<br>
> > ><br>
> > > I had a look at the bbb-i2c.c code and how it's registering<br>
> > > and setting up the i2c_bus struct with the transfer, set and<br>
> destroy<br>
> > > fucntions. <br>
> > > I have a question from the fundamentals, the only function<br>
> > > of bbb-i2c.c<br>
> > ><br>
> <<a href="https://git.rtems.org/rtems/tree/bsps/arm/beagle/i2c/bbb-i2c.c#n414" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/beagle/i2c/bbb-i2c.c#n414</a>><br>
> > > that is 'accessible' with the header file is<br>
> am335x_i2c_bus_register<br>
> > > which basically sets the i2c_bus struct<br>
> > > and calls the i2c_bus_register function from the dev/i2c.c .<br>
> > > To use the DEVMETHOD api, we need to be able to call the <br>
> > > transfer, destroy etc. functions of the bbb-i2c.c from the<br>
> translation<br>
> > > layer in rtemsbsd. How do I #include the bbb-i2c.c in the new <br>
> > > translation driver that I'll write?<br>
> > ><br>
> > > Hope my question is stated clearly, please correct me if I'm<br>
> getting<br>
> > > some fundamentals wrong.<br>
> ><br>
> > You are not fundamentally wrong but slightly off:<br>
> ><br>
> > Regarding the question how you access transfer, destroy, ...<br>
> of the<br>
> > driver directly: Don't.<br>
> ><br>
> > You basically don't need to have a look at the bbb-i2c.c file<br>
> of RTEMS<br>
> > for that driver. Where you should have a look is the Linux I2C API<br>
> > (which has been the model for the RTEMS API).<br>
> ><br>
> > Basically your drivers transfer function will do about the<br>
> following:<br>
> ><br>
> > - Open "/dev/i2c0" (or some other path - that will be a<br>
> parameter to the<br>
> > driver and has to be stored by probe or attach in some device<br>
> > structure).<br>
> ><br>
> > - Translate the "struct iic_msg" you get as an input to a "struct<br>
> > i2c_msg". Most likely that's just a cast.<br>
> ><br>
> > - Pass that via an ioctl call to the opened bus.<br>
> ><br>
> > - Check return value and translate to the matching return of<br>
> FreeBSD.<br>
> ><br>
> > - Close "/dev/i2c0"<br>
> ><br>
> > Some of the open / close might could move to attach / detach.<br>
> But that<br>
> > would be an optimization.<br>
> ><br>
> > That driver will work on any BSP that implements the current<br>
> i2c API. So<br>
> > it's a generic translation layer.<br>
> ><br>
> > Best regards<br>
> ><br>
> > Christian<br>
> ><br>
> > Hi!<br>
> ><br>
> > I started writing the driver layer implementation in the rtemsbsd, is<br>
> > this going in the right<br>
> > direction<br>
> ><br>
> <<a href="https://gist.github.com/thelunatic/2d8a2bf2cbead5bf82abe09000afea56" rel="noreferrer" target="_blank">https://gist.github.com/thelunatic/2d8a2bf2cbead5bf82abe09000afea56</a>> ?<br>
> <br>
> Yes. That's the direction I had in mind.<br>
> <br>
> Regarding that part:<br>
> <br>
> //XXX: Open /dev/iic0<br>
> strcpy(addr, "/dev/");<br>
> strcat(addr, device_get_nameunit(dev));<br>
> <br>
> Sooner or later that should be received via a parameter. I just had a<br>
> look at nexus-devices.h: It seems that there is currently only support<br>
> for two kinds of "parameters": memory resources and interrupts.<br>
> <br>
> What would be necessary would be more of a string parameter like they<br>
> are available via the device tree interface. This kind of parameters is<br>
> normally retrieved in the driver with the OF_getprop_alloc() function.<br>
> <br>
> Problem is: The driver you currently write isn't one that is normally<br>
> put into a device tree file. So some other source for the string<br>
> parameter is necessary. I'll have to have a more detailed look at how<br>
> the parameter could get into the driver in the next few days.<br>
> <br>
> I would suggest to start with a fixed string for now. Assume that it<br>
> will somehow appear in the attach function (that would be the location<br>
> where such parameters would be parsed most of the time).<br>
> <br>
> Hi,<br>
> I have updated the gist a bit, to use a macro for the path for now, and<br>
> also added<br>
> the probe and destroy function. This looks like a better outline now, I<br>
> haven't written<br>
> the attach function, you can have a detailed look at it and suggest ways<br>
> to parse the<br>
> path in the attach.<br>
<br>
Regarding the path: Like already mentioned, I think the best solution<br>
would be to get that via the open firmware "OF_getprop*" interface.<br>
Currently the only subsystem implementing this is the FDT interface. So<br>
a way to get the information into FDT is necessary.<br>
<br>
I think the best one would be to use a FDT overlay. The function for<br>
applying a overlay isn't implemented in RTEMS yet. But luckily U-Boot<br>
can do that for us. Please have a look at<br>
<br>
<a href="https://github.com/u-boot/u-boot/blob/master/doc/README.fdt-overlays" rel="noreferrer" target="_blank">https://github.com/u-boot/u-boot/blob/master/doc/README.fdt-overlays</a><br>
<br>
That solution isn't optimal because it needs some extra U-Boot calls.<br>
But It's the best that I have found on a short notice.<br>
<br>
I could think of two alternative solutions:<br>
<br>
1. Add some possibility to RTEMS libbsd to allow giving a string<br>
parameter to a driver.<br>
<br>
2. Just instantiate one instance for each RTEMS i2c.<br>
<br>
The first one is more effort than using U-Boot.<br>
<br>
The second one could be an alternative.<br>
<br>
To get the LCD controller driver to use the i2c adaption driver, it will<br>
be necessary to modify the FDT anyway. So using an overlay to do that<br>
might is the cleanest solution.<br>
<br></blockquote><div>Hi,</div><div><br></div><div>From what I understood looking at the man pages, we want to add a property to</div><div>the FDT and from our adaptation layer, call OF_getprop to get that value (path)<br></div><div>and then use that in our program. </div><div><br></div><div>How to add this overlay to the FDT? Is there some other app using the FDT overlays</div><div>that I can use as a reference? </div><div><br></div><div>Also, we have ofw_iicbus.c in the freebsd source tree, how do we make use of that? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> > <br>
> ><br>
> > ><br>
> > > ><br>
> > > > Can we not totally use the iicbus in the freebsd source?<br>
> > ><br>
> > > We already have a I2C driver for that BSP in RTEMS. If you<br>
> > would use the<br>
> > > FreeBSD code, they would fight for the hardware. Of<br>
> course it<br>
> > would be<br>
> > > possible to replace the RTEMS driver by a FreeBSD one. But<br>
> > that would<br>
> > > potentially break some applications. Besides that I<br>
> think that<br>
> > a lot of<br>
> > > RTEMS BSPs already have an I2C driver so a generic wrapper<br>
> > could be<br>
> > > helpful for other BSPs too.<br>
> > ><br>
> > > ><br>
> > > > ><br>
> > > > > Thanks<br>
> > > > ><br>
> [...]<br>
> <br>
</blockquote></div></div>