On Apr 17, 2005, at 08:00, James Chapman wrote:
Andy Fleming wrote:
quoted
Ok, here's the new patch with changes suggested by James Chapman:
I guess I still have questions about the way interrupts are used.
Using an interrupt to schedule a work queue which then sets a variable
that is used by a timer seems odd. Why not do all the work in the work
queue and schedule it from the interrupt handler or timer?
Ok, I've set up a new system for handling interrupts. There are now
two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT.
The first one is used to indicate that the PHY layer will poll the PHY
for state changes, and won't enable interrupts. The second indicates
that the PHY layer will neither poll, nor enable interrupts, and thus
will allow the driver to handle interrupts. The PHY layer will still
operate its state machine, though.
The driver must insure a couple things:
1) It must set phydev->state to PHY_CHANGELINK
2) It must do that in a work queue (or other non-interrupt time)
The first one tells the PHY layer that the link state changed (it has
to grab a lock to do this). The second one is required in order to
properly take the lock.
Also, did you mean to leave the #if 0 code in davicom.c?
For now. It worked around a problem some people were reporting, so I'd
like to see if they report it again now that the code's out. If so,
they have a fairly easy fix, and I can reinsert it (or at least
reevaluate it) in the future.
/james
Andy
Andy Fleming wrote:
On Apr 17, 2005, at 08:00, James Chapman wrote:
quoted
Andy Fleming wrote:
quoted
Ok, here's the new patch with changes suggested by James Chapman:
I guess I still have questions about the way interrupts are used.
Using an interrupt to schedule a work queue which then sets a variable
that is used by a timer seems odd. Why not do all the work in the work
queue and schedule it from the interrupt handler or timer?
Ok, I've set up a new system for handling interrupts. There are now two
"special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT. The
first one is used to indicate that the PHY layer will poll the PHY for
state changes, and won't enable interrupts. The second indicates that
the PHY layer will neither poll, nor enable interrupts, and thus will
allow the driver to handle interrupts. The PHY layer will still operate
its state machine, though.
The driver must insure a couple things:
1) It must set phydev->state to PHY_CHANGELINK
2) It must do that in a work queue (or other non-interrupt time)
The first one tells the PHY layer that the link state changed (it has to
grab a lock to do this). The second one is required in order to
properly take the lock.
quoted
Also, did you mean to leave the #if 0 code in davicom.c?
For now. It worked around a problem some people were reporting, so I'd
like to see if they report it again now that the code's out. If so,
they have a fairly easy fix, and I can reinsert it (or at least
reevaluate it) in the future.
quoted
/james
Andy
------------------------------------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Hi Andy.
Mind taking a look at the combined FEC/FCC driver I've posted and
comment on how hard it'll be to use your PAL? I'd be especially
interested at any API mismatches, and problems you might find.
Regards
Pantelis
Jeff,
Where do we stand on this. Are there changes you feel need to be made?=20=
Some other issue? It would like to know what we need to do to get=20
this in post 2.6.12.
thanks
- kumar
On May 10, 2005, at 12:04 PM, Fleming Andy-afleming wrote:
On Apr 17, 2005, at 08:00, James Chapman wrote:
quoted
Andy Fleming wrote:
quoted
Ok, here's the new patch with changes suggested by James Chapman:
>
> I guess I still have questions about the way interrupts are used.
>
> Using an interrupt to schedule a work queue which then sets a=20
variable
quoted
that is used by a timer seems odd. Why not do all the work in the=20
work
> queue and schedule it from the interrupt handler or timer?
Ok, I've set up a new system for handling interrupts.=A0 There are now
two "special" interrupt values, PHY_POLL, and PHY_IGNORE_INTERRUPT.=A0
The first one is used to indicate that the PHY layer will poll the =
PHY
for state changes, and won't enable interrupts.=A0 The second =
indicates
that the PHY layer will neither poll, nor enable interrupts, and thus
will allow the driver to handle interrupts.=A0 The PHY layer will =
still
operate its state machine, though.
The driver must insure a couple things:
1) It must set phydev->state to PHY_CHANGELINK
2) It must do that in a work queue (or other non-interrupt time)
The first one tells the PHY layer that the link state changed (it has
to grab a lock to do this).=A0 The second one is required in order to
properly take the lock.
quoted
> Also, did you mean to leave the #if 0 code in davicom.c?
For now.=A0 It worked around a problem some people were reporting, so =
I'd
like to see if they report it again now that the code's out.=A0 If so,
they have a fairly easy fix, and I can reinsert it (or at least
reevaluate it) in the future.
quoted
> /james
Andy
<phy_05_09_2005.patch><ATT191442.txt>=