[ECOS] cyg_flag_timed_wait()/cyg_flag_setbits() behaviour question

[ECOS] cyg_flag_timed_wait()/cyg_flag_setbits() behaviour question

[David Roethig]

We're using flags to wakeup threads. We use different bit
contained within one flag for signaling. (i.e. CAN_RX is bit 1,
SHUTDOWN is bit2, etc.)

I have some questions/comments regarding the use
of this kernel feature:

1) the flag_result returned with cyg_flag_timed_wait()
   contains all of the current bits set not the mask
   supplied with the cyg_flag_timed_wait() call.

   It seems to me that the result should only return the
   bits this call is interested in seeing. Is this
   expected behaviour?


2) the cyg_flag_setbits() routine in flags.cxx clears
   the current value of the flag upon finding the first
   thread waiting on the bit(s). It should wait until
   all tasks are woken before clearing the flag bits.
   It too suffers from the problem that the entire flag
   is cleared, not just the bit(s) desired.
   This means that multiple threads cannot use the
   same cyg_flag_t to wait for different (or common) bits.

An I misunderstanding the use of the flag feature?



Thanks,
Dave



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flag_timed_wait()/cyg_flag_setbits() behaviour question

[Andrew Lunn]

On Thu, Sep 14, 2006 at 10:50:39AM -0700, David Roethig wrote:
> 
> 
> 
> We're using flags to wakeup threads. We use different bit
> contained within one flag for signaling. (i.e. CAN_RX is bit 1,
> SHUTDOWN is bit2, etc.)
> 
> I have some questions/comments regarding the use
> of this kernel feature:
> 
> 1) the flag_result returned with cyg_flag_timed_wait()
>   contains all of the current bits set not the mask
>   supplied with the cyg_flag_timed_wait() call.
> 
>   It seems to me that the result should only return the
>   bits this call is interested in seeing. Is this
>   expected behaviour?

The documentation
http://ecos.sourceware.org/docs-latest/ref/kernel-flags.html says:

    A call to cyg_flag_wait normally blocks until the required
    condition is satisfied. It will return the value of the event flag
    at the point that the operation succeeded, which may be a superset
    of the requested events. If cyg_thread_release is used to unblock
    a thread that is currently in a wait operation, the cyg_flag_wait
    call will instead return 0.

so yes, this is expected behaviour. You know what you are interested
in, so you can do the masking yourself.

> 2) the cyg_flag_setbits() routine in flags.cxx clears
>   the current value of the flag upon finding the first
>   thread waiting on the bit(s). It should wait until
>   all tasks are woken before clearing the flag bits.
>   It too suffers from the problem that the entire flag
>   is cleared, not just the bit(s) desired.
>   This means that multiple threads cannot use the
>   same cyg_flag_t to wait for different (or common) bits.
> 
> An I misunderstanding the use of the flag feature?

The clearing depends on how the waiters are waiting, what flags they
have passed.

     cyg_flag_setbits is called by a producer thread or from inside a
     DSR when an event occurs. The specified bits are or'd into the
     current event flag value. This may cause one or more waiting
     threads to be woken up, if their conditions are now
     satisfied. How many threads are awoken depends on the use of
     CYG_FLAG_WAITMODE_CLR. The queue of threads waiting on the flag
     is walked to find threads which now have their wake condition
     fulfilled. If the awoken thread has passed CYG_FLAG_WAITMODE_CLR
     the walking of the queue is terminated, otherwise the walk
     continues. Thus if no threads have passed CYG_FLAG_WAITMORE_CLR
     all threads with fulfilled conditions will be awoken. If
     CYG_FLAG_WAITMODE_CLR is passed by threads with fulfilled
     conditions, the number of awoken threads will depend on the order
     the threads are in the queue.

Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Settign ethernet speed and duplex

[Laurie Gellatly]

Hi All,
I'm writing a new ethernet chip driver.
The chip (with built in PHY) support setting of speed (10/100) and duplex.
That's pretty easy to do in the driver but I'm lost in how it should be
connected to the application code.
I thought it might be an ioctl key but can't find anything to help me.

So, my question is, what is the 'right way' for this to be implemented and
are there examples I can follow?

Thanks again.          	...Laurie:{)


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Settign ethernet speed and duplex

[Nick Garnett]

"Laurie Gellatly" <laurie.gellatly@netic.com> writes:

> Hi All,
> I'm writing a new ethernet chip driver.
> The chip (with built in PHY) support setting of speed (10/100) and duplex.
> That's pretty easy to do in the driver but I'm lost in how it should be
> connected to the application code.
> I thought it might be an ioctl key but can't find anything to help me.
> 
> So, my question is, what is the 'right way' for this to be implemented and
> are there examples I can follow?

Generally applications don't get involved with this. The PHYs at each
end of the the wire negotiate the best speed and duplicity at
initialization and that's where it stays. Sometimes it is necessary to
prod the PHY to make it negotiate, but most just do it
automatically. Sometimes it is also necessary to query the PHY for the
settings and transfer them to the MAC. For a combined MAC+PHY I would
expect all of this to happen automatically.

I'm not sure why an application would need to change these
settings. You cannot change the duplex setting, since that depends on
the nature of the far end. If the PHYs have negotiated 10MB/s then
trying to raise it to 100MB/s will not work and I don't see any
advantage in reducing it from 100 to 10.


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Settign ethernet speed and duplex

[Laurie Gellatly]

Nick,
You've never seen auto negotiation fail then like I have.
If auto negotiation works the way its suppose to then I agree, you're better
off leaving it like that.
Reality unfortunatly does not always follow the best laid plans of mice and
men.

Regardless of what you and I might think the customer would still like to
set speed and duplex manually so....
Back to the original question, how should this be provided for?

Thanks for your comments.			...Laurie:{)


-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Nick Garnett
Sent: Friday, 15 September 2006 7:19 PM
To: laurie.gellatly@netic.com
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Settign ethernet speed and duplex


"Laurie Gellatly" <laurie.gellatly@netic.com> writes:

> Hi All,
> I'm writing a new ethernet chip driver.
> The chip (with built in PHY) support setting of speed (10/100) and duplex.
> That's pretty easy to do in the driver but I'm lost in how it should be
> connected to the application code.
> I thought it might be an ioctl key but can't find anything to help me.
>
> So, my question is, what is the 'right way' for this to be implemented and
> are there examples I can follow?

Generally applications don't get involved with this. The PHYs at each
end of the the wire negotiate the best speed and duplicity at
initialization and that's where it stays. Sometimes it is necessary to
prod the PHY to make it negotiate, but most just do it
automatically. Sometimes it is also necessary to query the PHY for the
settings and transfer them to the MAC. For a combined MAC+PHY I would
expect all of this to happen automatically.

I'm not sure why an application would need to change these
settings. You cannot change the duplex setting, since that depends on
the nature of the far end. If the PHYs have negotiated 10MB/s then
trying to raise it to 100MB/s will not work and I don't see any
advantage in reducing it from 100 to 10.


--
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Settign ethernet speed and duplex

[Gary Thomas]

Laurie Gellatly wrote:
> Nick,
> You've never seen auto negotiation fail then like I have.
> If auto negotiation works the way its suppose to then I agree, you're better
> off leaving it like that.
> Reality unfortunatly does not always follow the best laid plans of mice and
> men.
> 
> Regardless of what you and I might think the customer would still like to
> set speed and duplex manually so....
> Back to the original question, how should this be provided for?
> 
> Thanks for your comments.			...Laurie:{)

Since this needs to be done in the ethernet driver, add some options for
it in the CDL there.  If you use the PHY package as well, there are functions
you can call to manage this.  At least that's what the design was for, but
as Nick said, it's seldom [if ever] been necessary to force a PHY into a mode
that it can't auto-negotiate into.

> 
> 
> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org
> [mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Nick Garnett
> Sent: Friday, 15 September 2006 7:19 PM
> To: laurie.gellatly@netic.com
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Settign ethernet speed and duplex
> 
> 
> "Laurie Gellatly" <laurie.gellatly@netic.com> writes:
> 
>> Hi All,
>> I'm writing a new ethernet chip driver.
>> The chip (with built in PHY) support setting of speed (10/100) and duplex.
>> That's pretty easy to do in the driver but I'm lost in how it should be
>> connected to the application code.
>> I thought it might be an ioctl key but can't find anything to help me.
>>
>> So, my question is, what is the 'right way' for this to be implemented and
>> are there examples I can follow?
> 
> Generally applications don't get involved with this. The PHYs at each
> end of the the wire negotiate the best speed and duplicity at
> initialization and that's where it stays. Sometimes it is necessary to
> prod the PHY to make it negotiate, but most just do it
> automatically. Sometimes it is also necessary to query the PHY for the
> settings and transfer them to the MAC. For a combined MAC+PHY I would
> expect all of this to happen automatically.
> 
> I'm not sure why an application would need to change these
> settings. You cannot change the duplex setting, since that depends on
> the nature of the far end. If the PHYs have negotiated 10MB/s then
> trying to raise it to 100MB/s will not work and I don't see any
> advantage in reducing it from 100 to 10.
> 
> 
> --
> Nick Garnett                                 eCos Kernel Architect
> http://www.ecoscentric.com            The eCos and RedBoot experts
> 
> 
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> 
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Settign ethernet speed and duplex

[Nick Garnett]

"Laurie Gellatly" <laurie.gellatly@netic.com> writes:

> Nick,
> You've never seen auto negotiation fail then like I have.
> If auto negotiation works the way its suppose to then I agree, you're better
> off leaving it like that.
> Reality unfortunatly does not always follow the best laid plans of mice and
> men.

Indeed. But we sort it out in the ethernet driver, no need for the
application to be bothered.

> 
> Regardless of what you and I might think the customer would still like to
> set speed and duplex manually so....
> Back to the original question, how should this be provided for?
>

You might be able to get an ioctl() to work. However there is no
existing BSD IOCTL to do this. So you would have to invent a new one,
work out how to encode it and work out how it gets passed through the
stack to the driver.

Note that the fact that there is not an existing IOCTL for this
suggests that it is not something that applications should normally
get involved in.

Alternatively, define some config options, or some global variables
that the application can set before bringing the ethernet up. Changing
these settings after the driver is already running is a very bad idea.


-- 
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Settign ethernet speed and duplex

[Laurie Gellatly]

Nick,
OK, you've given me something to think a bit more on. Appreciate your
experience in this area. As it turns out there is already the facility
to set the value on startup. This might be the best path for me rather
than trying to create a dynamic setting.
Then the next time the system boots, the new values will be adopted.

Thanks again.			...Laurie:{)

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Nick Garnett
Sent: Friday, 15 September 2006 9:07 PM
To: laurie.gellatly@netic.com
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Settign ethernet speed and duplex


"Laurie Gellatly" <laurie.gellatly@netic.com> writes:

> Nick,
> You've never seen auto negotiation fail then like I have.
> If auto negotiation works the way its suppose to then I agree, you're
better
> off leaving it like that.
> Reality unfortunatly does not always follow the best laid plans of mice
and
> men.

Indeed. But we sort it out in the ethernet driver, no need for the
application to be bothered.

>
> Regardless of what you and I might think the customer would still like to
> set speed and duplex manually so....
> Back to the original question, how should this be provided for?
>

You might be able to get an ioctl() to work. However there is no
existing BSD IOCTL to do this. So you would have to invent a new one,
work out how to encode it and work out how it gets passed through the
stack to the driver.

Note that the fact that there is not an existing IOCTL for this
suggests that it is not something that applications should normally
get involved in.

Alternatively, define some config options, or some global variables
that the application can set before bringing the ethernet up. Changing
these settings after the driver is already running is a very bad idea.


--
Nick Garnett                                 eCos Kernel Architect
http://www.ecoscentric.com            The eCos and RedBoot experts


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Settign ethernet speed and duplex

[Daniel Néri]

Nick Garnett <nickg@ecoscentric.com> writes:

> You might be able to get an ioctl() to work. However there is no
> existing BSD IOCTL to do this.

That's not really true; on BSD you would use the "ifmedia" interface
and SIOCGIFMEDIA/SIOCSIFMEDIA ioctls to do this (used by ifconfig(8)
with the "media" and "mediaopt" parameters).

But it appears that those parts of the FreeBSD stack were never ported
to eCos.


Regards,
-- 
Daniel Néri <daniel.neri@sigicom.se>
Sigicom AB, Stockholm, Sweden


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss