[EMAIL PROTECTED] wrote:
Dirk Eibach wrote:
[EMAIL PROTECTED] wrote:
Dirk Eibach wrote:
Hello,
I have spent some time designing a RTDM I2C driver based on the linux
i2c driver. It's stripped down in some aspects but porting existing
clients and adapters should be fairly easy.
For this draft I have ported the IBM PPC4xx driver, because that is what
I have here for testing.
It's my first RTDM project, so I hope I haven't messed things up too
much.
Any comments welcome!
Great! I almost forgot this topic as it was quiet after my reply, but
now we even have code to discuss.
It took some time for me to understand the RTDM concepts and to
understand what the i2c linux driver is doing.
Before I start looking into implementation details, it would be nice if
you could sketch the basic idea of your API proposal and the typical use
cases. Code is more explicit, I know, but it's also a bit more tricky to
grab an overview from it. Do you also have some simple demo to show how
one should use your interface?
What I grabbed so far:
- for each I2C interface, a RTDM device is registered
- rti2c-api.h is ought to become the RTDM I2C device profile
- we have read/write and a bunch of IOCTLs as API
Here is a typical usecase:
int fd;
//open a instance of the RTDM device
fd = rt_dev_open( "rti2cppc4xx", 0);
I think we should define a more generic naming scheme here to make
application code easier portable. I guess there can alos be more than
one I2C controller on some system, right?
At the moment the devicename is defined by the caller of
rti2c_adapter_register().
When the device is registered a number is assigned to the adapter. Maybe
the devicename could be made up of some fixed text like "rti2c" followed
by the number that is assigned to the adapter.
// set the address of the device on the bus
rt_dev_ioctl(fd, RTI2C_SLAVE, addr);
Is the typical use case to not change the slave address that often,
rather to use separate device instances for accessing different slaves?
I'm wondering if a combined address+request command may make sense.
Maybe even a socket-based protocol device would match as well, maybe
even better... (needs more thinking, I guess)
Does Linux expose a similar API via some character devices? Keeping the
distance to Linux low might be a reason to not go the socket path.
The linux API is exactly the same. I had the same thoughts concerning
combined commands (address+request) but maybe we could offer such
commands as wrappers.
// write a value to register of the addressed device
rti2c_smbus_write_byte_data(fd, register, value);
rt_dev_close(fd);
Many common i2c usecases are packed in inline functions in rti2c-api.h
so you don't need to fiddle with IOCTLs that much.
Looks nice. A few of those inlines should become library functions,
though. But that's something to optimise later.
ACK
What I didn't grabbed:
- is transfer synchronous or asynchronous?
- can applications access an adapter concurrently?
- what are the major differences to the Linux model?
The interface is synchronous (just like its linux pendant). Applications
can access an adapter concurrently, access is serialized in
rti2-core.c/rti2c_smbus_xfer by a (per adapter) mutex.
So the typical path looks like this:
1. [depending on data size: allocate temporary buffer]
2. acquire interface mutex
3. issue request
4. pend on reply
hardware is working...
5. completion IRQ arrives and wakes up pending task
6. collect request result
7. release mutex
8. [release buffer]
A few thoughts on this:
- What are typical delays between 4. and 5.? Does it makes sense for
short requests to busy-wait (to avoid the scheduler/IRQ overhead)?
I've seen that there is some polling path included in the code, but
that would break as it calls into Linux.
Oops. I missed that schedule() call. Regarding typical delays I have to
admit that I have not measured yet, but I would estimate about 500 us
for the above usecase. What would you estimate the scheduler/IRQ overhead?
- Will a request always return? Or does it make sense to establish an
(optional) timeout mechanism here?
A timeout mechanism is already there: rti2c_ppc4xx_wait_for_tc() uses
rtdm_event_timedwait to wait for the interrupt to complete. Certainly
that is left to the implementation of the adapter.
- Buffer allocation for short requests may also happen on the stack, I
think.
That is already done. Have a look at the RTI2C_SMBUS IOCTL. Do you think
it should also be possible to do this in the read/write calls denpending
on the requested size?
- Buffer allocation for large requests may (optionally) happen
ahead-of-time via some special IOCTL. This would make a device
independent of the current system heap usage/fragmentation.
- During concurrent use, the latency of an user is defined by its
priority, of course, and the number and lengths of potentially issued
request of some lower priority user, right? Is there a way one could
intercept a pending request list? Or is this list handled in toto to
the hardware? Melts down to "how to manage the bandwidth according to
the user's priority".
Concurrent use means that single RTI2C requests are called from
different tasks. Each request is atomic (and usually quite small). So
when a low-pri thread does a lot of requests a high-pri thread can get
inbetween anytime. I think this way bandwidth is already managed properly.
The linux implementation has not only the device driver interface but
also a kernel-api. There is a i2c_driver concept, that enables you to
provide device drivers for i2c (client-)devices as kernel modules. I
left out this concept because I thought it does not fit the RTDM concept.
Actually, this fits very will in the RTDM concept in so far that RTDM
can provide exactly the same API you defined for user-space also in
kernel space. It just takes to handle the case "user_info == NULL" where
no address checks and copy_to/froms are needed. Check other RTDM drivers
on this.
Got it.
Moreover, in-kernel drivers could make use of direct invocations of
RTI2C services, check this service
http://www.xenomai.org/documentation/trunk/html/api/group__interdrv.html#g99e8509f4c8b404f0d5795b575d4c9cb
Once you locked the context, you can call into the RTDM device's
handlers directly with the demux'ing of your current file descriptor.
Are there any examples for this?
Further I left out all the sysfs stuff.
That's ok.
I'm looking forward to see some nice generic RTI2C in Xenomai soon(er or
later)!
Me too :)
My current optimistic feeling is that this could very well become stuff
for 2.4. Takes to stabilise the API (even if not all parts are
implemented then), document it like other RTDM profiles (e.g. CAN), and
iron the implementation. Sounds like a plan, doesn't it? :)
It does.
Jan
Dirk
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
