From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Cc: Josh Boyer <jdub@us.ibm.com>, Murali N Iyer <mniyer@us.ibm.com>,
linuxppc-embedded@ozlabs.org
Subject: EMAC "powerpc" port update
Date: Thu, 25 Jan 2007 18:00:02 +1100 [thread overview]
Message-ID: <1169708402.24996.82.camel@localhost.localdomain> (raw)
There's a new drop at:
http://gate.crashing.org/~benh/powerpc-emac-new-20070125.diff
No much differences from the previous one, most of my previous comments
about things to do still apply. The updates are mostly to make it work
for a customer :-)
- Fix build without debug
- Fix build when sungem or spidernet are built-in (name conflict of
exported functions in the PHY stuff)
- Fix STACR bits since it seems the HW folks had the great idea of
changing their meaning, so the PHY is now properly setup and flow
control works (yeah !)
I've decided to delay the port to the common phy layer due to the
locking issues I mentioned to after I merge it. Already too many things
going on at the same time in there :-)
I also haven't brought back the mecanism for dealing with Rx clock loss
as I need to verify wether we can do that differently using loopback, or
else, use some different way of implementing it for locking reasons
(probably pushing the clock control to the platform/cpu code and have
emac call it so the locking for access to those clock registers can be
centralized).
In fact, most of my other comments in my initial submission still
appply :-) It's however good enough to use with the Axon chip on cell
and thus could probably be merged as it co-exists fine with the old
driver in arch/ppc. Now that David Gibson is porting 4xx over to
arch/powerpc, I'll soon be able to start beating it up on 4xx too and
fix the remaining issues on these.
Murali: Note that I still don't unmap DMA pages, so it works fine as
long as the IOMMU is disabled, which should be the default on all HW we
are interested in at the moment, except some stuff you might know about
that has more than 2GB of RAM... I'll fix that in a later drop.
Ben.
reply other threads:[~2007-01-25 7:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1169708402.24996.82.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=jdub@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=mniyer@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).