Serial driver for ARM s3c4510

Serial driver for ARM s3c4510

[Roland Caßebohm]

Hello,

I'm about to make a port of our new platform call ARM Industrial Module AIM 
which includes the Samsung ARM s3c4510.

For the hal I have used the SNDS hal as base. For now I have just made a copy 
of it and made the needed changes. In future I think about making variant 
based hal, because there are then at least three platforms (SNDS, E7T and 
our) which is mostly the same.

Now I want to write the serial driver for our platform for which I have the 
same problem. I want to use the e7t driver as base. So I can again just copy 
it and rename everything called e7t to aim. Another possibility would be call 
it just s3c4510 and every platform which is s3c4510 based could use the 
driver as it is. The third possibility would be to make it like the generic
16x5x driver, which includes an include file for each platform.
I'm think I would prefer doing it like the latter.

Any suggestions?

Roland
-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
http://www.visionsystems.de
___________________________________________________

Re: Serial driver for ARM s3c4510

[Roland Caßebohm]

On Dienstag, 21. Oktober 2003 10:24, Roland Caßebohm wrote:
> Hello,
>
> I'm about to make a port of our new platform call ARM Industrial Module AIM
> which includes the Samsung ARM s3c4510.
>
> For the hal I have used the SNDS hal as base. For now I have just made a
> copy of it and made the needed changes. In future I think about making
> variant based hal, because there are then at least three platforms (SNDS,
> E7T and our) which is mostly the same.
>
> Now I want to write the serial driver for our platform for which I have the
> same problem. I want to use the e7t driver as base. So I can again just
> copy it and rename everything called e7t to aim. Another possibility would
> be call it just s3c4510 and every platform which is s3c4510 based could use
> the driver as it is. The third possibility would be to make it like the
> generic 16x5x driver, which includes an include file for each platform.
> I'm think I would prefer doing it like the latter.
>
> Any suggestions?

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?

Roland
-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
http://www.visionsystems.de
___________________________________________________

Re: Serial driver for ARM s3c4510

[Andrew Lunn]

> 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.

       Andrew

Re: Serial driver for ARM s3c4510

[Jonathan Larmour]

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.

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

The most obvious issue is this in e.g. the 16x5x driver:
         puts $::cdl_system_header "#ifndef CYGDAT_IO_SERIAL_DEVICE_HEADER"
         puts $::cdl_system_header "#define CYGDAT_IO_SERIAL_DEVICE_HEADER 
<pkgconf/io_serial_generic_16x5x.h>"

However I'm not sure what info actually _must_ be made public like this, 
other than e.g.:
         cdl_option CYGPRI_SER_TEST_SER_DEV {
             display       "Serial device used for testing"
             flavor        data
             default_value { CYGDAT_IO_SERIAL_I386_PC_SERIAL0_NAME }
         }

         define_proc {
             puts $::cdl_header "#define CYGPRI_SER_TEST_CRASH_ID \"i386pc\""
             puts $::cdl_header "#define CYGPRI_SER_TEST_TTY_DEV 
\"/dev/tty0\""
         }

There would be two ways to fix this probably.... change those #defines to 
$::cdl_system_header instead, so that the generic serial layer can get 
them that way; or create a CYGPRI_SER_TEST_CRASH_ID and 
CYGPRI_SER_TEST_TTY_DEV option in the generic serial driver (or perhaps a 
subtle rename to avoid clashes with existing clashes) and use CDL requires 
statements in the child packages to set values. The latter would be 
cleaner as it doesn't involve touching system.h which could cause 
unnecessary rebuilds.

It's a shame that CDL has this restriction with the "define" CDL property: 
"The -file option can be used to specify an alternative destination. At 
the time of writing the only valid alternative definition is 
-file=system.h, which will send the output to the global configuration 
header file pkgconf/system.h." I'll create a bugzilla bug for this.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Serial driver for ARM s3c4510

[Roland Caßebohm]

On Dienstag, 21. October 2003 17:29, Jonathan Larmour wrote:
> 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.
>
> I think for that reason it may be best to include all platform specific
> elements of a serial driver in a single package. But even then, it's
> possible there might be hiccups.
>
> The most obvious issue is this in e.g. the 16x5x driver:
>          puts $::cdl_system_header "#ifndef CYGDAT_IO_SERIAL_DEVICE_HEADER"
>          puts $::cdl_system_header "#define CYGDAT_IO_SERIAL_DEVICE_HEADER
> <pkgconf/io_serial_generic_16x5x.h>"
>
> However I'm not sure what info actually _must_ be made public like this,
> other than e.g.:
>          cdl_option CYGPRI_SER_TEST_SER_DEV {
>              display       "Serial device used for testing"
>              flavor        data
>              default_value { CYGDAT_IO_SERIAL_I386_PC_SERIAL0_NAME }
>          }
>
>          define_proc {
>              puts $::cdl_header "#define CYGPRI_SER_TEST_CRASH_ID
> \"i386pc\"" puts $::cdl_header "#define CYGPRI_SER_TEST_TTY_DEV
> \"/dev/tty0\""
>          }
>
> There would be two ways to fix this probably.... change those #defines to
> $::cdl_system_header instead, so that the generic serial layer can get
> them that way; or create a CYGPRI_SER_TEST_CRASH_ID and
> CYGPRI_SER_TEST_TTY_DEV option in the generic serial driver (or perhaps a
> subtle rename to avoid clashes with existing clashes) and use CDL requires
> statements in the child packages to set values. The latter would be
> cleaner as it doesn't involve touching system.h which could cause
> unnecessary rebuilds.
>
> It's a shame that CDL has this restriction with the "define" CDL property:
> "The -file option can be used to specify an alternative destination. At
> the time of writing the only valid alternative definition is
> -file=system.h, which will send the output to the global configuration
> header file pkgconf/system.h." I'll create a bugzilla bug for this.
>
> Jifl

What I have done now is I have two packages (aim711_s3c4510, aim711_16x5x) 
which configures the generic serial drivers s3c4510 and 16x5x.
But additionally I have made a package which includes only one cdl file 
looking like that:

cdl_package CYGPKG_IO_SERIAL_ARM_AIM711 {
    display       "ARM Industrial Module AIM 711 serial device drivers"

    parent        CYGPKG_IO_SERIAL_DEVICES
    active_if     CYGPKG_IO_SERIAL

    include_dir   cyg/io
    include_files ; # none _exported_ whatsoever
    description   "
           This package contains serial device drivers for the
           ARM Industrial Module AIM 711."

    define_proc {
        puts $::cdl_system_header "/** serial driver proc output start **/"
        puts $::cdl_system_header "#ifndef CYGDAT_IO_SERIAL_DEVICE_HEADER"
        puts $::cdl_system_header "#define CYGDAT_IO_SERIAL_DEVICE_HEADER
                     <pkgconf/io_serial_arm_aim711.h>"
        puts $::cdl_system_header "#endif"
        puts $::cdl_system_header "/**  serial driver proc output end  **/"
        puts $::cdl_header "#include <pkgconf/system.h>";
        puts $::cdl_header "#include <pkgconf/io_serial_arm_s3c4510.h>";
        puts $::cdl_header "#include <pkgconf/io_serial_generic_16x5x.h>";
        puts $::cdl_header "#include CYGDAT_IO_SERIAL_ARM_S3C4510_CFG";
        puts $::cdl_header "#include CYGDAT_IO_SERIAL_GENERIC_16X5X_CFG";
    }
}

Now both configurations are included in CYGDAT_IO_SERIAL_DEVICE_HEADER.
The cdl_option CYGPRI_SER_TEST_SER_DEV I have only implemented in one package 
(aim711_16x5x), so there is no conflict. Maybe this could be made 
congureable.

But if I do it like that, I have three directorys for AIM in devs/serial/arm 
(aim711 aim_s3c4510 aim711_16x5x). Maybe I should make subdirectorys under 
devs/arm/aim711? Or I however make it to only one package because it is only 
one platform?

Roland

Re: Serial driver for ARM s3c4510

[Jonathan Larmour]

Roland Caßebohm wrote:
> 
>     define_proc {
>         puts $::cdl_system_header "/** serial driver proc output start **/"
>         puts $::cdl_system_header "#ifndef CYGDAT_IO_SERIAL_DEVICE_HEADER"
>         puts $::cdl_system_header "#define CYGDAT_IO_SERIAL_DEVICE_HEADER
>                      <pkgconf/io_serial_arm_aim711.h>"
>         puts $::cdl_system_header "#endif"
>         puts $::cdl_system_header "/**  serial driver proc output end  **/"
>         puts $::cdl_header "#include <pkgconf/system.h>";
>         puts $::cdl_header "#include <pkgconf/io_serial_arm_s3c4510.h>";
>         puts $::cdl_header "#include <pkgconf/io_serial_generic_16x5x.h>";
>         puts $::cdl_header "#include CYGDAT_IO_SERIAL_ARM_S3C4510_CFG";
>         puts $::cdl_header "#include CYGDAT_IO_SERIAL_GENERIC_16X5X_CFG";
>     }
> }
> 
> Now both configurations are included in CYGDAT_IO_SERIAL_DEVICE_HEADER.
> The cdl_option CYGPRI_SER_TEST_SER_DEV I have only implemented in one package 
> (aim711_16x5x), so there is no conflict. Maybe this could be made 
> congureable.

Hmm. It's very unlikely that a user would notice that only one serial 
device was being tested, and being founded on completely different 
drivers, that's quite unfortunate. Similarly automated testing 
infrastructure wouldn't be able to manage either.

> But if I do it like that, I have three directorys for AIM in devs/serial/arm 
> (aim711 aim_s3c4510 aim711_16x5x). Maybe I should make subdirectorys under 
> devs/arm/aim711? Or I however make it to only one package because it is only 
> one platform?

If there are to be three directories, then yes, make subdirectories under 
an aim711 directory (although consider whether anything here might be 
applicable to other AIM models, although probably not).

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Serial driver for ARM s3c4510

[Bart Veer]

>>>>> "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

Re: Serial driver for ARM s3c4510

[Roland Caßebohm]

On Mittwoch, 22. Oktober 2003 16:40, Bart Veer wrote:
> 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.

So I can do it like that:

cdl_component CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_TESTING {
    display    "Testing parameters"
    flavor     bool
    calculated 1
    active_if  CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0

    i {
        display       "Serial device used for testing"
        flavor        booldata
        default_value 0
        legal_values  { 0 CYGDAT_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0_NAME }
    }

    define_proc {
        puts $::cdl_header "#define CYGPRI_SER_TEST_CRASH_ID \"arm16x5x\""
        puts $::cdl_header "#define CYGPRI_SER_TEST_TTY_DEV  \"/dev/tty2\""
    }
}

But what should I do with CYGPRI_SER_TEST_TTY_DEV? Although I think this is a 
general problem, because it wouldn't make sense to make  
CYGPRI_SER_TEST_SER_DEV configureable but not CYGPRI_SER_TEST_TTY_DEV.

Maybe it is also possible to have this in the serial io package

cdl_interface CYGINT_IO_SERIAL_TEST_DEV {
    display     "Serial testing device"
}

and cdl_option CYGPRI_SER_TEST_SER_DEV implements it if enabled?

Roland

Re: Serial driver for ARM s3c4510

[Jonathan Larmour]

Roland Caßebohm wrote:
> On Mittwoch, 22. Oktober 2003 16:40, Bart Veer wrote:
> 
>>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.

However this would be a regressive step in that current testing 
assumptions would stop working. Granted with the automated testing things 
can be munged, but right now one of the good things about eCos testing is 
that for manual testing users can run through the tests and check for 
failures. Right now, at least they'll get a test failure if a serial 
device is not configured correctly with ser_filter magic on the other end.

Perhaps we need a something that has "requires { CYGPRI_SER_TEST_SER_DEV 
!= 0 }", but that would mean having new clean configurations that don't 
work by default (or if an #ifndef in the test file itself, that doesn't 
compile by default). That's something we didn't want to do as a policy 
decision. The alternative would be the user not knowing that serial is not 
being testing, unless they look in the serial driver configuration each 
time they create a new configuration. If this principle was applied to all 
devices (not that they're tested much at present :-|), that would be a lot 
for a user to configure before they could even manage to do a proper test run.

> So I can do it like that:
> 
> cdl_component CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_TESTING {
>     display    "Testing parameters"
>     flavor     bool
>     calculated 1
>     active_if  CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0
> 
>     i {
>         display       "Serial device used for testing"
>         flavor        booldata
>         default_value 0
>         legal_values  { 0 CYGDAT_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0_NAME }
>     }
> 
>     define_proc {
>         puts $::cdl_header "#define CYGPRI_SER_TEST_CRASH_ID \"arm16x5x\""
>         puts $::cdl_header "#define CYGPRI_SER_TEST_TTY_DEV  \"/dev/tty2\""
>     }
> }
> 
> But what should I do with CYGPRI_SER_TEST_TTY_DEV? Although I think this is a 
> general problem, because it wouldn't make sense to make  
> CYGPRI_SER_TEST_SER_DEV configureable but not CYGPRI_SER_TEST_TTY_DEV.
> 
> Maybe it is also possible to have this in the serial io package
> 
> cdl_interface CYGINT_IO_SERIAL_TEST_DEV {
>     display     "Serial testing device"
> }
> 
> and cdl_option CYGPRI_SER_TEST_SER_DEV implements it if enabled?

I don't see an interface helps any. I imagine whatever solution is used 
for CYGPRI_SER_TEST_SER_DEV should also be used for CYGPRI_SER_TEST_TTY_DEV.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Serial driver for ARM s3c4510

[Jonathan Larmour]

Bart Veer wrote:
> 
> 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.

By that token, having packages dump stuff in <pkgconf/system.h> breaks 
that encapsulation just as much, if not more because of the widespread 
nature. Anything can interfere with that (and define or undefine any 
options), and the order could clearly be important. And as I said, doing 
so causes effectively a whole system rebuild unnecessarily.

Perhaps the use of "puts $::cdl_system_header" should be deprecated. Being 
able to define something in a parent package's header is at best no worse 
than that functionality, and more likely less bad.

The alternative is to make new booldata CDL options, which requires wider 
changes, and no-one is likely to change current practice if 
$::cdl_system_header is available and not deprecated.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Serial driver for ARM s3c4510

[Roland Caßebohm]

On Donnerstag, 23. Oktober 2003 13:17, Roland Caßebohm wrote:
> On Mittwoch, 22. Oktober 2003 16:40, Bart Veer wrote:
> > 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.
>
> So I can do it like that:
>
> cdl_component CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_TESTING {
>     display    "Testing parameters"
>     flavor     bool
>     calculated 1
>     active_if  CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0
>
>     cdl_option CYGPRI_SER_TEST_SER_DEV {
>         display       "Serial device used for testing"
>         flavor        booldata
>         default_value 0
>         legal_values  { 0 CYGDAT_IO_SERIAL_ARM_AIM711_16X5X_SERIAL0_NAME }
>     }
>
>     define_proc {
>         puts $::cdl_header "#define CYGPRI_SER_TEST_CRASH_ID \"arm16x5x\""
>         puts $::cdl_header "#define CYGPRI_SER_TEST_TTY_DEV  \"/dev/tty2\""
>     }
> }
>

I've tested this now but it doesn't work. The aim711_s3s4510 file I have 
changed similar.
But the configtool says:

Option `CYGPRI_SER_TEST_SER_DEV' cannot be loaded.
    The name is already in use

even though if CYGPRI_SER_TEST_SER_DEV is disabled. I have made another test 
in which I have made CYGPKG_IO_SERIAL_ARM_AIM711_16X5X_TESTING and 
CYGPKG_IO_SERIAL_ARM_AIM711_S3C4510_TESTING configurable, but with the same 
result, even though if these options are disabled the conflict is there.

Re: Serial driver for ARM s3c4510

[Roland Caßebohm]

On Freitag, 24. Oktober 2003 06:25, Jonathan Larmour wrote:
> Roland Caßebohm wrote:
> > On Mittwoch, 22. Oktober 2003 16:40, Bart Veer wrote:
> >>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.
>
> However this would be a regressive step in that current testing
> assumptions would stop working. Granted with the automated testing things
> can be munged, but right now one of the good things about eCos testing is
> that for manual testing users can run through the tests and check for
> failures. Right now, at least they'll get a test failure if a serial
> device is not configured correctly with ser_filter magic on the other end.
>
> Perhaps we need a something that has "requires { CYGPRI_SER_TEST_SER_DEV
> != 0 }", but that would mean having new clean configurations that don't
> work by default (or if an #ifndef in the test file itself, that doesn't
> compile by default). That's something we didn't want to do as a policy
> decision. The alternative would be the user not knowing that serial is not
> being testing, unless they look in the serial driver configuration each
> time they create a new configuration. If this principle was applied to all
> devices (not that they're tested much at present :-|), that would be a lot
> for a user to configure before they could even manage to do a proper test
> run.
>
> > ...
> > 
> > Maybe it is also possible to have this in the serial io package
> >
> > cdl_interface CYGINT_IO_SERIAL_TEST_DEV {
> >     display     "Serial testing device"
> > }
> >
> > and cdl_option CYGPRI_SER_TEST_SER_DEV implements it if enabled?
>
> I don't see an interface helps any. 

Sorry, I have a little bit switched the topic, I thought if the are two 
packages which could define the option CYGPRI_SER_TEST_SER_DEV the interface 
would help avoid conflicts, because both could be enabled.

> I imagine whatever solution is used
> for CYGPRI_SER_TEST_SER_DEV should also be used for
> CYGPRI_SER_TEST_TTY_DEV.

I agree.

But for now, to have a solution for me, I will make one platform specific 
serial driver package which will include the two drivers generic 16x5x and 
arm s3c4510. This package will only one time implement 
CYGINT_IO_SERIAL_TEST_DEV and related things. Doing like this the package 
behaves like all the other platforms. But I will left it as three cdl files 
to be more clear.

My directory structure will look like this:

aim711
aim711/current
aim711/current/cdl
aim711/current/cdl/ser_arm_aim711.cdl
aim711/current/cdl/ser_arm_aim711_16x5x.cdl
aim711/current/cdl/ser_arm_aim711_s3c4510.cdl
aim711/current/include/ser_arm_aim711_16x5x.inl
aim711/current/include/ser_arm_aim711_s3c4510.inl
aim711/current/ChangeLog

If there would be a semilar platform but with only one serial interface it 
must have its own platform specific serial driver package.

Do you think this would be good at the moment?

Roland
-- 

___________________________________________________

VS Vision Systems GmbH, Industrial Image Processing
Dipl.-Ing. Roland Caßebohm
Aspelohe 27A, D-22848 Norderstedt, Germany
Mail: roland.cassebohm@visionsystems.de
http://www.visionsystems.de
___________________________________________________

Re: Serial driver for ARM s3c4510

[Jonathan Larmour]

Roland Caßebohm wrote:
> On Freitag, 24. Oktober 2003 06:25, Jonathan Larmour wrote:
> 
>>Roland Caßebohm wrote:
>>
>>>Maybe it is also possible to have this in the serial io package
>>>
>>>cdl_interface CYGINT_IO_SERIAL_TEST_DEV {
>>>    display     "Serial testing device"
>>>}
>>>
>>>and cdl_option CYGPRI_SER_TEST_SER_DEV implements it if enabled?
>>
>>I don't see an interface helps any. 
> 
> 
> Sorry, I have a little bit switched the topic, I thought if the are two 
> packages which could define the option CYGPRI_SER_TEST_SER_DEV the interface 
> would help avoid conflicts, because both could be enabled.

However since the value of the option is the most important property, I'm 
afraid that probably won't help.

>>I imagine whatever solution is used
>>for CYGPRI_SER_TEST_SER_DEV should also be used for
>>CYGPRI_SER_TEST_TTY_DEV.
> 
> I agree.
> 
> But for now, to have a solution for me, I will make one platform specific 
> serial driver package which will include the two drivers generic 16x5x and 
> arm s3c4510. This package will only one time implement 
> CYGINT_IO_SERIAL_TEST_DEV and related things. Doing like this the package 
> behaves like all the other platforms. But I will left it as three cdl files 
> to be more clear.

Given the current structure, that's probably a fair compromise, but more 
sweeping work will be needed sometime in the future as Bart correctly 
points out, and more care is needed there to ensure we don't regress on 
what gets tested.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine