This is the mail archive of the ecos-devel@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: Serial driver for ARM s3c4510


>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    Jifl> Andrew Lunn wrote:
    >>> Additionally the AIM platform includes a 16550 UART, so this
    >>> serial interface should be implemented as /dev/ser2 also. Is
    >>> it possible and useful to make a generic s3c4510 serial
    >>> driver, use the generic 16x5x driver but make only one package
    >>> (devs/serial/arm/aim) which includes this two drivers. Or is
    >>> it better to make two packages like
    >>> devs/serial/arm/aim_s3c4510 and devs/serial/arm/aim_16x5x?
    >> 
    >> 
    >> I would go for two packages. There is no logical connection between
    >> the two, so why should they share a package? What happens if in the
    >> future you replace your 16x5x with something else etc? 
    >> 
    >> You are the second person who recently needed two different
    >> serial drivers in the same configuration. I don't really know
    >> the serial driver architecture that well, but from when i
    >> looked last the architecture is not very good at this. If you
    >> have time, it would be good it you could study the architecture
    >> and see if you can make is better for supporting multiple
    >> devices.

    Jifl> I think for that reason it may be best to include all
    Jifl> platform specific elements of a serial driver in a single
    Jifl> package. But even then, it's possible there might be
    Jifl> hiccups.

    <snip>

I have not spent much time looking at the 16x5x driver, but it seems
to me that there is an underlying structural problem which needs to be
addressed. The presence of a 16550 is a feature of the platform. A
16550 driver will need information such as base addresses and
interrupt numbers, and that information should come from the platform
HAL. The 16550 driver should just be able to #include
<cyg/hal/hal_io.h> and, directly or indirectly, get any information
that is needed. Similarly the platform HAL can instantiate the
appropriate devices, under suitable configury control and active_if
(CYGPKG_IO_SERIAL && CYGPKG_IO_SERIAL_GENERIC_16X5X).

Regarding something like CYGPRI_SER_TEST_SER_DEV, that is really a
characteristic of the testing infrastructure. Turn it into a booldata,
disabled by default. For manual testing the user should decide
explicitly which port(s) should be tested, enable the option and set
the value. For automated testing the testing infrastructure should be
smart enough to know which port(s) are actually connected to something
that can handle serial tests and manipulate the appropriate
configuration options.

The CDL restriction enforces package encapsulation. Each package can
be sure of the contents of its own <pkgconf/whatever> header, nothing
else can interfere with that contents and there are never any concerns
about the order in which things might appear in that header. I would
need a much more persuasive argument before changing this aspect of
CDL.

Bart


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