CPM commands are executed from different drivers, e.g. fcc_enet.c and
in different execution contexts.
Isn't there a need for a central place to handle CPM commands?
For example:
m8260_cpm_cmd(...)
disable ints
bounded wait until FLG is clear
if not clear => ???
write to CPCR
enable ints
I have problems when testing the ATM driver and at the same time having
limited Ethernet traffic (debug printouts). I get a "transmit timed
out" and descriptor ring dump from the eth driver. Disabling irqs in the
atm driver around CPCR handling seems to fix that problem.
Comments?
Thanks,
Hans
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hans Feldt wrote:
Isn't there a need for a central place to handle CPM commands?
You could make it an inline function or macro, but I'm not sure
it's worth it. All CPM drivers must have knowledge of how they
may affect others and take care to ensure incorrect operation
doesn't occur. In this case, there isn't a consistent use of
sending CPM commands, as you mentioned in your message. There are
different contexts in which drivers send these commands. It
doesn't make sense for a driver to continue without waiting for
the command to complete, so there isn't any need to wait for this
prior to sending a command.
m8260_cpm_cmd(...)
disable ints
bounded wait until FLG is clear
if not clear => ???
write to CPCR
enable ints
A more proper order of operation would be:
disable ints
write CPCR
bounded wait until FLG is clear
enable ints
return status
In some cases, it could be argued for a performance benefit to actually
perform other operations while waiting for the CPM command to finish.
....Disabling irqs in the
atm driver around CPCR handling seems to fix that problem.
Then....that's what you should do. It isn't always appropriate to
generally disable/enable interrupts in a common function because of
the driver context when the CPCR is accessed. We also have to be
careful about making a generic and abstract CPM interface, since the
overhead of such functions would have a negative affect in an area
where we are sensitive to performance.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan,
different contexts in which drivers send these commands. It
doesn't make sense for a driver to continue without waiting for
the command to complete, so there isn't any need to wait for this
prior to sending a command.
I think that a driver should not wait forever for a CPM command to complete, as
this could possibly halt the entire kernel. Granted, if this happens then the
state of the system is flaky at best, but it might still be possible to
function, maybe even enough to debug the real problem.
Since the CPM is a shared resource between different drivers, I don't think it
is such a bad idea to have some software help in sharing it, as opposed to just
hoping everyone behaves properly.
Actually, on a complicated CPU such as the 8260, there are many common
resources that are shared that might be better protected in software, e.g. io
port pins, internal dpram, baud rate generators, timers, mutually exclusive
features, etc.
Along the same lines, what is the current vision of future linux support for
the 8260?
Pete
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/