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

[Robert S. Grimes]

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.

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