Trivial bug in(?) and proposed change to libi2c.h

[Till Straumann]

Robert S. Grimes wrote:
> Thomas Doerfler wrote:
>   
>>> 2.  Near the bottom of the same file, there is the typedef for
>>> rtems_libi2c_tfr_mode_t.  I'd like to add a new field to this structure
>>> as illustrated below (the new field is spi_sel_mode):
>>>
>>>     typedef struct {
>>>       uint32_t baudrate;       /* maximum bits per second               */
>>>                                /* only valid for SPI drivers:           */
>>>       uint8_t  bits_per_char;  /* how many bits per byte/word/longword? */
>>>       boolean  lsb_first;      /* TRUE: send LSB first                  */
>>>       boolean  clock_inv;      /* TRUE: inverted clock (high active)    */
>>>       boolean  clock_phs;      /* TRUE: clock starts toggling at start
>>>     of data tfr */
>>>       boolean  spi_sel_mode;   /* SPI only - TRUE: SS set per
>>>     transaction; */
>>>                                /* FALSE: SS set per word */
>>>     } rtems_libi2c_tfr_mode_t;
>>>     
>>>       
>> Hm, in that case the transaction should also contain the currently
>> selected slave address. 
>>     
> Hmm, yeah, that seems to make sense to me; it would seem the device 
> address fits in this structure too....  It also brings up an issue I 
> have currently - I can't seem to open two SPI devices on the same SPI 
> "bus".  I haven't been able to characterize this, as one device is 
> certainly better than none, so I've shelved this issue for now.
>
> <off-topic>
> That being said, how would that fit in with device major and minor 
> numbers?  I am certainly unsure here, so let me restate my 
> configuration, which is more complex than some.  I have several, 
> separate SPI IP peripherals - this would correspond to a traditional 
> microprocessor with multiple SPI controllers.  Each SPI "bus" has 
> multiple devices attached to it.  So, I was under the impression that a 
> major device number would be assigned to each instance of the SPI 
> controller driver, and a minor number to each SPI device driver. 
>
> Is this correct?
>
> Or should the major number correspond to the SPI driver, the minor 
> number to a specific controller, and some new number (in the struct 
> under discussion) assigned for each SPI device.
>
>   
The latter. Traditionally, the major number is associated with a 
particular driver
(registered with the OS) the minor number with a device instance; 
ultimately the semantics of the
minor number are defined by the driver, the major number by the OS.

libi2c registers itself with RTEMS under one major number and it uses 
specific
semantics for the minor number. Basically, libi2c uses parts of the 
minor number
to identify a 'low-level' aka 'bus' driver and dispatches read/write 
etc. to the
'bus' driver registered with libi2c under the 'bus' number (some bits or 
the minor number).

Whatever you do, please do not break the current semantics for i2c devices
where the bus number and device-address on the bus(es) are encoded in 
the minor number.
The 'device address' on the bus which is also encoded in the minor number is
used by libi2c to address a particular device on a 'bus' during the 
addressing phase
which precedes every read/write operation.

If you have multiple identical controllers you should be able to 
register them
multiple times with libi2c under a different bus number.

Thanks
-- Till
> I don't have enough expertise in the inner workings of RTEMS' I/O system 
> to comment on the better approach.
> </off-topic>
>
>   
>> And with this functionality, the timing for the
>> negation of SS is not yet defined. Between two transactions, do you want
>> it to be negated it for 1ms, 1us, 1ns... ?
>>   
>>     
> I hadn't considered this, mainly because the Virtex hardware doesn't 
> support this directly; however, the QSPI peripheral in many (all?) 
> Coldfire and other Freescale processors, for example, do provide varying 
> degrees of support.  So clearly, we should attempt to define these 
> things as generically as possible, so I'll put on my QSPI hat on top of 
> the Virtex one...
>   
>> I know that the current implementation also has a lot of gaps, because
>> actually SPI hardware can have a fair amount of different requirements
>> concerning the timing. Maybe we should add this to the tfr_mode aswell.
>> And define the interaction between your change and the "send_addr" call
>> differently.
>>
>> The additional timing requirements IMHO would be:
>> - time (in nanoseconds?) between active edge of select signal and first
>> active clock edge
>>
>> - time (in nanoseconds?) between last active clock edge and inactive
>> edge of select signal
>>
>> - time (in nanoseconds?) between last inactive edge of select signal and
>> active edge of (possibly different) select signal
>>   
>>     
> Yes, that sounds good.  Do you want to add these, or should I and send 
> them to you for inclusion into HEAD?  I don't care either way - let me 
> know your preference.
>
> Thanks,
> -Bob
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>