Am 16.04.19 um 11:28 schrieb Vijay Kumar Banerjee: > > > > On Fri, Apr 12, 2019 at 9:16 PM Christian Mauderer <l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> wrote: > > Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee: > > > > > > On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer > > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>>> wrote: > > > > 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 > > > > > 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 > > > > > > On Tue, Apr 9, 2019 at 5:28 AM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>> > > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote: > > > > > > On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote: > > > > On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> wrote: > > > > Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee: > > > > > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>>> wrote: > > > > > Am 07.04.19 um 14:35 schrieb Vijay Kumar > Banerjee: > > > > > > On Sun, Apr 7, 2019 at 5:37 PM Christian > Mauderer > > > > > <l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>> > > > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>> > > > > <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de> <mailto:l...@c-mauderer.de > <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>>>>>>> wrote: > > > > > > Am 07.04.19 um 13:08 schrieb Vijay Kumar > > Banerjee: > > > > > > > > I don't think that there are a lot of docs for how > to test. > > > Although I'm > > > > sure that there are some scripts to run a number > of libbsd > > > tests, I'm > > > > not sure where. Maybe in the RTEMS tester but I think > > that is > > > mainly for > > > > the core tests? > > > > > > The documentation for testing can be found here ... > > > > > > > https://docs.rtems.org/branches/master/user/testing/index.html > > > > > > > so far I know, RTEMS Tester is only for core tests. > > > > > > The `rtems-test` command checks the for test start and end > > banners. > > > I am not > > > sure if libbsd supports the test banners. Maybe it could > now with > > > Sebastian's > > > movement of the test support code into libtest. > > > > > > > I'll ask in the devel if there's some way to run > libbsd test > > with > > > the tester. > > > > > > There is the `rtems-run` command which has similar args to > > > `rtems-test`. It does > > > suffer from a limitation I have not fixed which is stdin > is not > > > passed through > > > to the console of the target. I also think the command has a > > timeout > > > running, > > > but I am not sure about this one. > > > > > > Chris > > > > > > > -- > > -------------------------------------------- > > embedded brains GmbH > > Herr Christian Mauderer > > Dornierstr. 4 > > D-82178 Puchheim > > Germany > > email: christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@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. > > > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
