<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 12:39 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">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: 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 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 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 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 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 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 necessary to<br>> > translate to<br>> > > the RTEMS API here.<br>> > ><br>> > > I had a look at the iic and iicbus codes in freebsd 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 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 relate<br>> them and <br>> > > get a wrapper like that. Any suggestions on how to 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>> <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 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 find<br>> in FreeBSD<br>> > that uses the transfer API.<br>> > freebsd-org/sys/dev/drm2/radeon/atombios_i2c.c looks good to me.<br>> > Basically you have to implement the following functions (replace<br>> > radeon_atom... by a useful prefix):<br>> ><br>> > static device_method_t radeon_atom_hw_i2c_methods[] = {<br>> > DEVMETHOD(device_probe, 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, radeon_atom_hw_i2c_reset),<br>> > DEVMETHOD(iicbus_transfer, radeon_atom_hw_i2c_xfer),<br>> > DEVMETHOD_END<br>> > };<br>> ><br>> > The iicbus_transfer function seems to get a struct 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 RTEMS driver.<br>> ><br>> > Basically you just have to pass the bus to use as a 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 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 destroy<br>> > fucntions. <br>> > I have a question from the fundamentals, the only function<br>> > of bbb-i2c.c<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 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 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 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, ... of the<br>> driver directly: Don't.<br>> <br>> You basically don't need to have a look at the bbb-i2c.c file 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 following:<br>> <br>> - Open "/dev/i2c0" (or some other path - that will be a 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 FreeBSD.<br>> <br>> - Close "/dev/i2c0"<br>> <br>> Some of the open / close might could move to attach / detach. But that<br>> would be an optimization.<br>> <br>> That driver will work on any BSP that implements the current 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>> <<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></blockquote><div>Hi,</div><div>I have updated the gist a bit, to use a macro for the path for now, and also added</div><div>the probe and destroy function. This looks like a better outline now, I haven't written</div><div>the attach function, you can have a detailed look at it and suggest ways to parse the</div><div>path in the attach.</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>> > > 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 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 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>
</blockquote></div></div>