Hello,
On Tue, 02 Apr 2013 20:11:32 +0200
Phileas Fogg <phileas-fogg%mail.ru@localhost> wrote:
On 04/02/2013 08:59 PM, Michael wrote:
Hello,
On Tue, 02 Apr 2013 19:33:16 +0200
Phileas Fogg <phileas-fogg%mail.ru@localhost> wrote:
we need to extend/rework the OpenPIC interface because
currently the implementation assumes the little-endian
architecture which is not true on PowerMAC G5 11,2.
I'm fairly sure there are at least some ofppc boxes with the same problem.
And if we want to reuse some parts of the current OpenPIC
implementation then we need to extend it and support
the big-endian architecture too.
I thought of a global variable "openpic_be" which can be set
to 0 or 1. And "openpic_read" and "openpic_write" methods
will check it.
And then rename the 2nd parameter of "setup_openpic" to "flags"
and define 2 flags:
OPENPIC_FLAG_PASSTHROUGH and OPENPIC_FLAG_BIGENDIAN
What do you think ?
I wonder how likely it is that we'll ever need both in the same kernel
image. If that likelihood is zero then we'd be better off with a macro
and a build time option. Do you think 32bit OEA and 64bit bridge mode
will ever be supported by the same kernel?
Otherwise, I'd avoid checking flags in openpic_read() and openpic_write(),
instead make them function pointers, have variants with and
without byte order twiddling, and decide which one to use in
setup_openpic().
Yeah, you are right, checking the variable every time an IRQ is acked is
not a good idea :) But you can't know till run time if it's little
or big-endian architecture because we get this info from OFW.
Linux and FreeBSD do it at run-time on PowerMac.
I'm sure they've got their reasons ;)
What I was thinking about is this - all 32bit PowerMacs that use
OpenPICs use the little endian variant. All(?) G5 PowerMacs use the big
endian variant. Kernels that support only one of those don't need the
distinction, and introducing additional overhead, even if it's tiny, on
comparably slow hardware is something we should ( in my opinion at
least ) try to avoid.
Since the OpenPIC code is used on other architectures as well, where
the logic above doesn't necessarily apply, it's probably best to
decide at runtime and I'll add an optional fast path for 32bit Macs,
which avoids the indirection, later on.
have fun
Michael