This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SPI infrastructure


>>>>> "Savin" == Savin Zlobec <savin@elatec.si> writes:

    Savin> Writting an SPI bus driver a few questions came to my mind:

    Savin> - there are bus device table defines in spi.h, but I
    Savin> couldn't find any method to do an lookup, it would be nice
    Savin> to have something like cyg_spi_device
    Savin> *cyg_spi_lookup(cyg_spi_bus *bus, int device_num) or even
    Savin> better cyg_spi_device *cyg_spi_lookup(int bus_num, int
    Savin> device_num).

    Savin> - without lookup methods (it seems) the only way to assign
    Savin> an SPI device to odher device drivers (like DataFlash
    Savin> driver) is to pass the pointer to it (I guess the
    Savin> HAL_SPI_EXPORTED_DEVICES does this).

Correct. I did not see any point in being able to look up attached
devices or anything like that. Unlike say PCI there is no standard SPI
protocol for interrogating SPI devices and finding out about their
capabilities. Instead you have to know exactly what kind of device you
are talking to and try to communicate with it.

Hence the model I adopted is that the platform HAL (usually) exports
data structures corresponding to the various attached devices. For
example <cyg/hal/plf_io.h> can contain something like:

#ifndef __IN_PLATFORM_SPI_C
# define HAL_SPI_EXPORTED_DEVICES				\
    extern cyg_spi_device               cyg_spi_mmc_dev0;	\
    extern cyg_spi_device		cyg_spi_adc;		\
    extern cyg_spi_device		cyg_spi_temp_sensor;
#endif

Application code can then use these structures directly. Or other eCos
packages such as an MMC driver can use these structures, as long as
such packages define a naming convention that should be observed by
the platform HAL. For example an MMC driver could require that the
various card slots are accessible as cyg_spi_mmc_dev0,
cyg_spi_mmc_dev1, ..., without really introducing any complexity into
the system.

Note that I don't expect to see that many packages for specific SPI
devices. There are far too many such devices, and hence the
probability of two different boards with eCos ports using the exact
same device are small. There may be company product lines based around
similar hardware where reuse is possible, but that can be handled at
the application level. Without reusability there is little point in
creating lots of eCos packages for the various SPI devices.

In theory you could introduce complications like being able to look up
an spi_device by a string name, but I don't see the point. Compared
with accessing the device structures directly, look ups are just overhead
and I don't think they offer any maintainability or other gains. With
my approach there is also much less risk of accidentally sending ADC
requests to an MMC card, or anything similar.

    Savin> - the transfer and tick methods require the polled flag.
    Savin> The polled mode would be used in configurations like
    Savin> RedBoot or at init times and non polled mode when kernel is
    Savin> running - so since all of the communication is done either
    Savin> in one or anodher mode the polled mode could be set with
    Savin> set_config making the tick and transfer methods lighter and
    Savin> clearer.

Not necessarily true. With some hardware you may want to use interrupt
driven I/O for large transfers, e.g. a disk block, but then switch to
polled mode to check for completion. The extra costs of setting up
interrupt-driven I/O may be fine for large transfers but not
acceptable for small ones. Unfortunately this is somewhat
hardware- and application-specific.

I did think about making polled vs. interrupt-driven part of the
device state rather than passing it as argument, but I am not
convinced there are any real gains. You would save an argument to the
transfer and tick functions, but those would now have to check a
global setting instead. In cpu cycle and code size terms those would
pretty much cancel out. Add in the extra overheads of a more
complicated set_config routine plus application calls to set_config,
and I think you are better off with the extra argument. I do agree
that it makes the tick and transfer methods slightly harder to use,
which is unfortunate.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]