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