This is the mail archive of the ecos-devel@sourceware.org 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: What is the reason to...


>>>>> "Gary" == Gary Thomas <gary@mlbassoc.com> writes:

    Gary> Oliver Munz @ SNR wrote:
    >> Yes, if it's the case, that the drivers only are linked in the
    >> application, if they are realy needed, then there is no reason to don't
    >> include the CYGPKG_IO_*'s and if the CYGPKG_IO_*'s do control, if the
    >> drivers are linked to the applications, then they shouldn't be marked as
    >> "hardware"...
    >> 
    >> But i don't know how it is...

    Gary> The reason things are done this way is to allow building a
    Gary> configuration with minimal drivers included. The hardware
    Gary> drivers (e.g. CYGPKG_DEVS_SPI_ARM_AT91) are designed such
    Gary> that they will be disabled unless the corresponding generic
    Gary> layer is present (CYGPKG_IO_SPI). Thus in the default
    Gary> configuration SPI will be disabled.

    Gary> Adding CYGPKG_IO_SPI enables the whole SPI framework,
    Gary> including the platform drivers.

No. What you are describing is true for some types of device, e.g.
ethernet and flash. It is not true for SPI or I2C. Those depend on
link-time elimination of unwanted functionality, as opposed to
configure-time adding of desired functionality. A key difference is
that SPI and I2C are buses that may be needed by other bits of the
port, including the platform HAL. Hence to keep things simple for
users the generic code must be included in the configuration by
default.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


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