I2C adaption layer driver for libbsd (was: Re: rtems-libbsd build error)
Christian Mauderer
list at c-mauderer.de
Wed Apr 17 19:09:48 UTC 2019
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).
>
>
> >
> > >
> > > 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
> > > >
[...]
More information about the devel
mailing list