On Wed, 2006-10-18 at 07:52 -0600, Grant Likely wrote:
On 10/18/06, Sascha Hauer [EMAIL PROTECTED] wrote:
Is someone working on this already?
There are some Kconfig entries, but there seems to be no code, at least
not in vanilla.
I'm slowly working on it. I've got a .dts written and
On Wed, 2006-10-25 at 21:05 +0200, Nicolas DET wrote:
In addition to various whitespace damage in the patch...
+ if (_chrp_type == _CHRP_E5K2) {
+ ppc_md.get_irq = mpc52xx_get_irq;
+ mpc52xx_init_irq();
+ return;
+ }
As I wrote, the above should
On Wed, 2006-10-25 at 17:01 -0600, Grant Likely wrote:
Thanks Nicolas, I'll dig through the PIC code tonight. I'm really not
sure about the implications of this being a CHRP board vs. the
Lite5200 using u-boot. ie. Should the Lite5200 also be a CHRP
platform? Does u-boot provide enough
Any reason why this is not static nor __init ? :
+struct device_node *find_mpc52xx_pic(void)
+{
+ struct device_node *dev;
+ const char *piccompatible_list[] =
+ {
+ mpc5200-interrupt-controller,
+ mpc52xx-interrupt-controller,
+
Since the bestcomm init is in a module, a different module could be
implemented,
(like bestcomm-chrp5k2.ko) that instead of clearing SRAM and doing
everything
from scrtch, would rely on the bootloader more. This would allow
custom tasks
to be marked as don't touch. So if the bootloader want
On Thu, 2006-10-26 at 19:54 +0200, Sylvain Munaut wrote:
Hi Nicolas,
I don't have much to add to what's already been posted, so here's a
couple of details,
mainly compatibility concerns with the legacy arch/ppc tree.
I'd rather not clobber the code to be compatible with arch/ppc... once
On Fri, 2006-10-27 at 13:56 +0400, Andrey Volkov wrote:
Grant Likely wrote:
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index
On Mon, 2006-10-30 at 00:10 +0100, Nicolas DET wrote:
+/*
+ * void call to be used for .ack in the irq_chip_ops
+ * indeed, some of our irq does noy need ack
+ * but the kernel call .ack if it's valid or not
+*/
+
+static void mpc52xx_voidfunc(unsigned int virq)
+{
+#ifdef DEBUG
+
set_irq_type() does nothing if you haven't hooked a set_type callback to
your irq_chip and none of yours does so just drop it for now and look at
how this is done in mpic or ipic. If you actually want to implement
proper set_type (which you might need to do if you want that code to
work
On Tue, 2006-10-31 at 08:49 +0100, Nicolas DET wrote:
In this case: shouldn't the platform init correctly setup the hw instead
of the Firmware?
No. The device-tree contains the polarity information, it gets passed to
the PIC driver via set_irq_type() anyway so there is no need in theory
to
In my point of view, the Firmware main task is to init the HW. I do not
think it's a good idea to overwrite firmware hw settings in the common
code. In my mind, this should be done in platform specific area.
The setting of interrupt polarity is a matter that is at the edge
between firmware
On Tue, 2006-10-31 at 10:04 +0100, Nicolas DET wrote:
Benjamin Herrenschmidt wrote:
In my point of view, the Firmware main task is to init the HW. I do not
think it's a good idea to overwrite firmware hw settings in the common
code. In my mind, this should be done in platform specific
This definitely needs to be removed. It's used to figure out which
driver should drive a PSC (based on function). We've got a device
tree to provide this information now.
Which means we should define how that is presented in the devie-tree and
Nicolas should then update his tree
On Tue, 2006-10-31 at 16:08 -0700, Grant Likely wrote:
On 10/31/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
This definitely needs to be removed. It's used to figure out which
driver should drive a PSC (based on function). We've got a device
tree to provide this information
My only remaining comment is what I said earlier about the way you
divided the interrupt in levels.
In fact, I've finally dug into the doc and found out that the situation
is even less clear :)
The whole point of this division is to avoid special cases and properly
deal with the separation in
On Thu, 2006-11-02 at 09:19 +1100, Benjamin Herrenschmidt wrote:
On Wed, 2006-11-01 at 21:29 +0100, Nicolas DET wrote:
Ooops ... here's the english version :)
+
+static void __init efika_init_IRQ(void)
+{
+ mpc52xx_init_irq();
+}
Ya pas moyen que mpc52xx_init_irq() ait le bon
On Thu, 2006-11-02 at 09:23 +1100, Benjamin Herrenschmidt wrote:
And in english here too
On Wed, 2006-11-01 at 21:31 +0100, Nicolas DET wrote:
+/**+ ohci = hcd_to_ohci(hcd);
+ ohci-flags |= OHCI_BIG_ENDIAN;
+ ohci_hcd_init(ohci);
Bon, c'est pas mal. Le seul truc ici
On Sun, 2006-11-05 at 01:27 +0100, Sylvain Munaut wrote:
+ picnode = find_mpc52xx_picnode();
+ sdmanode = find_mpc52xx_sdmanode();
Any reason why you have those inline 1-line functions and just not put
the actual of_find_* call in here ?
I think it might be worth creating
On Mon, 2006-11-06 at 14:46 -0800, Andrew Morton wrote:
On Sun, 5 Nov 2006 12:57:16 +0100 (MET)
Nicolas DET [EMAIL PROTECTED] wrote:
Add Efika (http://www.bplan-gmbh.de/efika_spec_en.html) platform support
for arch/powerpc
Who (if anyone) is the maintainer for this sort of thing?
It's
On Mon, 2006-11-06 at 20:00 -0600, Josh Boyer wrote:
Hi Edi,
On Mon, 2006-11-06 at 18:21 -0500, Edi Shmueli wrote:
From: Edi Shmueli [EMAIL PROTECTED]
This patch enables applications to exploit the PPC440 TLB support for
huge-page mapping, to minimize TLB thrashing.
Applications
On Mon, 2006-11-06 at 19:26 -0800, Roland Dreier wrote:
Also, while it's great to have somebody do this work, I doubt there is
much interest in merging it for arch/ppc...
On that subject, what's the latest on moving ppc4xx to arch/powerpc?
At the kernel summit you told me to chill out
Hi !
On my work in porting emac over to arch/powerpc (and make it work on SMP
platforms since there's at least one coming, possibly too), I ended up
with a problem with things like the workarounds for the EMAC loss of RX
clock (CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) that I think uncovers a more
generic
On my work in porting emac over to arch/powerpc (and make it work on SMP
platforms since there's at least one coming, possibly too), I ended up
with a problem with things like the workarounds for the EMAC loss of RX
clock (CONFIG_IBM_EMAC_PHY_RX_CLK_FIX) that I think uncovers a more
generic
No, it's not simpler. This just does not handle the problem this
workaround was implemented for.
Quite possibly I didn't fully understand it as there is little
explanation in the code about what is going on except that the RX clock
from the PHY is dropping and that is causing TX timeouts...
On Wed, 2006-12-06 at 22:57 +0100, Roger Larsson wrote:
On Wednesday 06 December 2006 06:10, Benjamin Herrenschmidt wrote:
On UP configuration, there is no real problem: local_irq_disable/enable
around the code tweaking those bits (read/modify/write) is enough and
everybody is happy
GACK! Many better engineers than any of us have spent countless hours
breaking down locks. A lock takes nearly no space at all, you're not
proposing to lock any less often, so multiple locks take no less time,
the only thing you stand to gain by protecting multiple data structures
with one
The specific example that made me think about it was some clock control
registers on 4xx that the EMAC driver is whacking every now and then (on
link state change, no lock contention to be worried about here), though
they could be used by other drivers too (or platform code). Since those
On Fri, 2006-12-08 at 21:15 +0100, Arnd Bergmann wrote:
On Friday 08 December 2006 21:05, Wolfgang Grandegger wrote:
Can anybody tell me why the spin_* protection is needed? I thought that
32-bit read and write operations are atomic.
The spinlocks are needed to guarantee ordering between
Then the spinlock makes sense avoiding the interruption of the
subsequent read write accesses.
Sorry for the noise.
Ok, yes, it does make sense in that context then.
Ben.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
'/cpus/PowerPC,[EMAIL PROTECTED]/timebase-frequency' as what it's searching
for, but
what ft_get_prop() finds is
'///cpus//cpus/PowerPC,[EMAIL PROTECTED]/timebase-frequency', which of
course doesn't
match, so it returns NULL to ft_setup() and the 'timebase-frequency' never
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
On Fri, 2007-02-02 at 05:36 -0800, Russell McGuire wrote:
Well I am getting smarter on this:
I have read through the PCI Bridge Specs and found another issue that might
have been causing a problem with the IDSEL lines. Unless you are interested
I'll forgo that explanation and just go with
On Mon, 2007-02-12 at 10:30 -0800, Roland Dreier wrote:
Benjamin David Gibson is making some good progress with the
Benjamin powerpc port, we have ebony booting and emac's up,
Benjamin though he's still ironing out some issues and PCI is
Benjamin still to go. Hopefully, we'll
On Mon, 2007-02-12 at 14:16 -0600, Jon Loeliger wrote:
So, like, the other day Benjamin Herrenschmidt mumbled:
Note that there are still things that we might want to change. For
example, I think we really should look into adding a macro mecanism
and/or an include mecanism to dtc so
On Tue, 2007-04-24 at 20:34 -0700, Siva Prasad wrote:
Thanks Ben.
I managed to fix this. I am working on how best we can rewrite the self
modifying code we have for create_hpte routine. I would prefer to read
from SDR1, than to hardcode (or self modify the code) the way it is done
now.
On Wed, 2007-05-02 at 12:58 -0700, Siva Prasad wrote:
Hi Ben,
First,
Are there any other places where we have self modifying code in Linux
kernel, other than in arch/powerpc/mm/ppc_mmu_32.c:MMU_init_hw()
(basically modified create_hpte and flush_hash_page)
There is the cpu feature fixup
apparently after more investigations - it looks like there is something in
the ext2 driver code
that is mal-adjustedI haven't talked to the guy today who was looking at
that - but the ext2
driver code that was openning a 'virtual file' / console - had some problems
mapping that
to pci_iomap on ppc64.
Signed-off-by: Benjamin Herrenschmidt benh at kernel.crashing.org
Index: linux-work/arch/ppc64/kernel/iomap.c
===
--- linux-work.orig/arch/ppc64/kernel/iomap.c 2005-01-24 11:42:36.0
+1100
+++ linux-work
On Wed, 2006-08-30 at 01:33 -0500, Olof Johansson wrote:
On Wed, Aug 30, 2006 at 10:55:39AM +0800, Liu Dave-r63238 wrote:
Can we do atomic operation in user space as kernel space?
Ok, let's hope that clarifies it for everybody.
Atomic operations in user space are possible using reservations
On Wed, 2005-04-06 at 01:51 -0500, Kumar Gala wrote:
Paul,
I've tracked down a bug I've been having to the fact that pte_update
assumes a pte is a unsigned long. I need to look into what the exact
implications this has. I was wondering what the thoughts were with
respect to how this is
version of pte_update.
- kumar
--
Benjamin Herrenschmidt benh at kernel.crashing.org
On Wed, 2005-04-06 at 19:33 -0400, Dan Malek wrote:
On Apr 6, 2005, at 6:37 PM, Wolfgang Denk wrote:
are there any plans yet how to continue PPC kernel development now
that Linus (and probably others, too) stopped using BitKeeper?
For all practical purposes, we have stopped using it
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Benjamin Herrenschmidt benh at kernel.crashing.org
On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote:
Andrew,
Moved common FPU exception handling code out of head.S so it can be used
by several of the sub-architectures that might of a full PowerPC FPU.
Also, uses new CONFIG_PPC_FPU define to fix alignment exception
handling for
On Sun, 2005-10-30 at 23:03 +0300, Pantelis Antoniou wrote:
Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
address fixes the problem.
Ugh ?
What is the problem precisely ? This is just a dodgy workaround for an
unexplained problem. Normally, the kenrel _WILL_ cause
On Mon, 2005-11-07 at 06:44 -0200, Marcelo Tosatti wrote:
The bug is that the zeroed TLB is not invalidated (the same reason
for the dcbst misbehaviour), resulting in infinite TLBError faults.
I see, so you are in the same situation as ia64 which has valid but
unmapped TLBs ?
Dan, I wonder
On Sat, 2004-04-24 at 06:53, Randy Vinson wrote:
In updating some of the boards for 2.6, I've encountered one
without an 8259. I can either stub-out the call to i8359_irq() in
my board-specific code or pull the openpic_hookup_cascade() support
forward from 2.4. I've been told that the
On Sun, 2003-12-14 at 20:24, DaveyWu wrote:
Stefan,
Thanks for your reply. My bootloader is OpenBios. I think the problem is not
caused by the wrong MAC addresses, because when I boot the 2.4.18 kernel the
MAC address of eth1 is same 00:00:00:00:00:00 but both EMACs work well.
Our engin
On Thu, 2005-06-30 at 14:05 -0400, Dan Malek wrote:
On Jun 29, 2005, at 7:31 PM, Benjamin Herrenschmidt wrote:
- The debate between Dan and me here is about the semantics of
io_block_mapping().
My point of discussion is this function needs to be much smarter than
simply allocating
.
The solution to this problem is to disable kernel preemption while
destroying a MMU context.
Signed-off-by: Guillaume Autran gautran at mrv.com
Acked-by: Benjamin Herrenschmidt benh at kernel.crashing.org
---
diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
--- a/include
On Mon, 2005-07-25 at 08:16 -0500, Bogdan Antonovici wrote:
Yes, it was. After some research on the previous message i realized
that it run out of memory so i did mem=8M and it hasn't been crashed
since then.
I still would like to understand why that swap code was run when the
swapping wasn't
Hi Paul Gabriel !
We indeed have some weird stuff mixing signed unsigned in the
arch/ppc/kernel/time.c code. The patch enclosed, from Jean-Denis
Boyer, seems the right fix, except for one thing: I'd rather
change the test from = to (which in the old could would mean
changing the while (... 0
I don't have the time to study whether the patches proposed would work
well in all these weird cases.
BTW, how do you initially set the system time in your RTC less machines ?
I spent some time studying the latest of the patches and it seems ok.
Ben.
** Sent via the linuxppc-embedded mail
On Wed, 2005-09-07 at 20:03 -0300, Marcelo Tosatti wrote:
Hi,
The following patch adds big endian version of ld_/st_ macros
and converts core 8xx code to use them.
Other than making IO accesses explicit (which is a plus for
readability), a common set of macros provides a unified place
On Wed, 2005-09-07 at 20:42 -0400, Dan Malek wrote:
On Sep 7, 2005, at 8:28 PM, Benjamin Herrenschmidt wrote:
I'm not fan of the approach. You should use in_/out_ macros for IOs. If
you don't need eieio on 8xx , then just #ifdef it out of the
implementation of these.
Yeah, #ifdef
e is shared by all architectures. Doing something like
/*
* 8, 16 and 32 bit, big and little endian I/O operations, with barrier.
*/
extern inline int in_8(volatile unsigned char __iomem *addr)
{
int ret;
__asm__ __volatile__(
lbz%U1%X1 %0,%1;\n
I think she lost the I in ICACHE... its a power5 only feature at this
point.
And good old 601 too :) It has a unified cache. We could make a common
feature bit for these.
Ben.
On Tue, 2005-09-13 at 14:05 -0500, Kumar Gala wrote:
This probably has to due with what happens on a G4 system with a
kernel not build with Altivec.. However, I dont remember exactly what
behavior is desired.
No, we should never set MSR_VEC on a kernel not built with
CONFIG_ALTIVEC.
Ben.
On Tue, 2005-09-13 at 16:43 -0500, Kumar Gala wrote:
On Sep 13, 2005, at 3:35 PM, Marcelo Tosatti wrote:
On Tue, Sep 13, 2005 at 02:05:57PM -0500, Kumar Gala wrote:
This probably has to due with what happens on a G4 system with a
kernel not build with Altivec.. However, I dont remember
On Wed, 2005-08-17 at 01:30 -0500, Kumar Gala wrote:
On Aug 16, 2005, at 11:21 AM, David Woodhouse wrote:
My dual G4 PowerMac crashes sometimes when it probes for the (absent)
serial ports. Theoretically it's supposed to take a machine check and
recover -- but it doesn't always work like
, can be downloaded, the URL is in the
document.
---
Booting the Linux/ppc64 kernel without Open Firmware
(c) 2005 Benjamin Herrenschmidt benh at kernel.crashing.org, IBM Corp.
May 18, 2005: Rev 0.1 - Initial draft
Here is the kernel patch. It applies on top of the various prom_init.c
bug fixes that I already posted today on the linuxppc-dev
linuxppc64-dev lists (those will be in the next -mm and maybe in
2.6.12).
This patch is intended to hit upstream by 2.6.13
Index:
On Wed, 2005-06-01 at 11:58 -0500, Jon Loeliger wrote:
On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
Here's the fourth version of my document along with new kernel patches
for the new improved flattened format, and the first release of the
device-tree compiler tool. The patches
On Wed, 2005-06-01 at 14:54 -0500, Jon Loeliger wrote:
On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).
Here's the fourth version of my document along with new kernel patches
for the new improved flattened format
On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote:
Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
proper PCMCIA controllers, those are swallowed properly when the card
is removed. The eating of the machine check is a bit too hackish to my
taste... Better is to not do
On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote:
Hi Ben,
On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote:
Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
proper PCMCIA
On Thu, 2005-06-02 at 17:00 -0700, Mark A. Greer wrote:
Two things:
1) What is common in your list?
2) On a slightly different note...if no one volunteers to look after the
following ones, I vote to remove them:
k2
lopec
mcpn765
menf1Dead (Matt Porter)
pmac :)
On Thu, 2005-06-02 at 19:09 -0500, Kumar Gala wrote:
On Jun 2, 2005, at 7:00 PM, Mark A. Greer wrote:
Two things:
1) What is common in your list?
Good question, hopefully Paul knows. I just did an ls in
arch/ppc/configs/ to create the list.
it's pmac+chrp+prep in a single image
On Wed, 2005-06-01 at 18:28 +1000, Benjamin Herrenschmidt wrote:
Here is the kernel patch. It applies on top of the various prom_init.c
bug fixes that I already posted today on the linuxppc-dev
linuxppc64-dev lists (those will be in the next -mm and maybe in
2.6.12).
This patch is intended
On Fri, 2005-06-03 at 16:22 -0700, Geoff Levand wrote:
I rebased this to apply to Benjamin's ppc32-rework-pm.diff, but
didn't recode it to take advantage of the extra hooks. More work
is certainly needed for wake-on-lan. Any comments on improvement
would be most welcome.
I could also
On Fri, 2005-06-03 at 12:19 -0500, Jon Loeliger wrote:
Ben and Folks,
Hi Jon !
I've read through ppc64/kernel/prom.c and done some minor
call-chain analysis rooted at the two functions:
early_init_devtree()
unflatten_device_tree()
as they are apparently the only two referenced in
On Wed, 2005-06-15 at 14:00 -0500, Jon Loeliger wrote:
On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:
It's basically used to extract some infos directly from the flattened
tree in order to construct the LMB list (list of memory blocks,
equivalent of ppc32's mem_pieces
On Mon, 2005-06-27 at 11:28 -0500, Jon Loeliger wrote:
Guys,
As an initial step towards getting the OF Flat Dev tree
handled in the PPC32 tree, this patch cleans up some of
the interface parts of the very early mem_pieces manager
and adds some PPC64-LMB-like routines as well.
It has been
On Tue, 2005-06-28 at 09:53 -0400, Dan Malek wrote:
On Jun 28, 2005, at 2:30 AM, Benjamin Herrenschmidt wrote:
You should consider 8Mb pages the way we do BATs yes,
It's always been considered, just never fully implemented :-)
Note that I'll soon send the patch I told you about
On Tue, 2005-06-28 at 09:42 -0400, Guillaume Autran wrote:
Hi,
I happen to notice a race condition in the mmu_context code for the 8xx
with very few context (16 MMU contexts) and kernel preemption enable. It
is hard to reproduce has it shows only when many processes are
created/destroy
I'm still a bit confused with kernel preemption. One thing for sure
is that disabling kernel preemption does indeed fix my problem.
So, my question is, what if a task in the middle of being schedule
gets preempted by an IRQ handler, where will this task restart
execution ? Back at the
Execution is resumed exactly where it has been interrupted.
The idea behind my patch was to get rid of that nr_free_contexts counter
that is (I thing) redundant with the context_map.
Apparently its there to avoid the spinlock exactly on !FEW_CONTEXTS machines.
I suppose that what
On Wed, 2005-06-29 at 14:19 -0300, Marcelo Tosatti wrote:
Once the physical-virtual mapping for device IO space are set
with io_block_mapping() (or with ioremap() for dynamic virtual
addresses), why would you want to ioremap() the physical address
again???
PS: I've had a quick try at
update_mmu_cache(vma, addr, pte) do { } while(0) */
+extern void update_mmu_cache(struct vm_area_struct *, unsigned long, pte_t);
#else/* 6xx, 7xx, 7xxx cpus */
struct mm_struct;
--
Benjamin Herrenschmidt benh at kernel.crashing.org
** Sent via the linuxppc-embedded mail list. See http
{ } while(0) */
+extern void update_mmu_cache(struct vm_area_struct *, unsigned long,
pte_t);
#else /* 6xx, 7xx, 7xxx cpus */
struct mm_struct;
--
Benjamin Herrenschmidt benh at kernel.crashing.org
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
To add to these comments, I can reproduce the problem as well on a
unix socket shared either between two processes, or read written
by a single process.
After doing various tests, the problem appears rarely and randomly
with half the RAM mapped with fixed TLBs, and very reproduceably
with all
Looks like Ben and I have found the problem;
Cool. I know this works OK on 8xx, I just haven't finished a working
tlb miss handler that will work regardless of the page size.
From my understanding, it seems the problem on 4xx is that the
shadow TLBs aren't keeping the PID. Thus the following
flush_instruction_cache() is already an iccci on 4xx (iccci flushes
the entire ICU). flush_dcache_icache() should be fixed though. We
could either replace the entire icache flushing loop with a single
iccci, or we could replace each icbi with two icbis, on the address
and the address XORed with
The other problem is the namespace of request_irq() usually assumes
numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
use these numbers.
Not that much actually. Look at pmac, I have nothing even close to
the 0..15 ISA namespace. Of course, a few crappy legacy ISA drivers
are
As far as I can tell there's no problem with get_free_pages() (or
rather, alloc_pages()), except that we need to add GFP_ATOMIC to the
flags if we're in interrupt context.
The problems are in get_vm_area() which does a kmalloc() without
GFP_ATOMIC and in map_page() which can sleep.
(Note do
On Tue, 2005-03-08 at 19:47 -0600, Andy Fleming wrote:
I've finally gotten all of ebs's suggestions into the PHY code. Here
is the new version. It has the following improvements:
* All PHYs now determine speed,duplex, etc using the same generic code,
rather than PHY-specific registers.
On Tue, 2005-03-08 at 19:42 -0800, David S. Miller wrote:
On Wed, 09 Mar 2005 13:14:16 +1100
Benjamin Herrenschmidt benh at kernel.crashing.org wrote:
I'll have a closer look when I find some time, see if it makes sense to
adapt sungem or not.
Especially because of the Broadcom PHYs I
On Thu, 2005-03-10 at 23:01 +, James Chapman wrote:
Hi Andy,
Can you elaborate on why this phy abstraction is needed?
In your original post, you mentioned that you were going to post a
patch to show how your code would be hooked up in an existing net
driver. Did I miss it? It would
On Thu, 2005-03-10 at 18:27 -0500, Jeff Garzik wrote:
I haven't had time to review the phy abstraction layer, but my gut
feeling is that there are several common code patterns which could be
abstracted out, to save code.
Typically there will be one or more phy-specific functions in each
On Mon, 2005-03-28 at 10:44 -0600, Kumar Gala wrote:
Guys,
While this is not overly important to me, I was wondering if we had any
rules related to formatting of assembly files. We seem to have code
formatted with and without spaces in the args.
I'm assuming something like this (w/o
On Fri, 2005-12-02 at 01:07 -0700, Jason Gunthorpe wrote:
I have a custom embedded system with a 440GP derived CPU that places the
memory starting at 0xc000 which requires a non-zero PPC_MEMSTART. There
are a couple of places that assume PPC_MEMSTART is 0. This results in
various tricky
On Thu, 2006-06-15 at 14:14 -0700, Shawn Jin wrote:
Hi,
I'm looking at the linux PCI implementation, especially MSI support
for Ocotea. And I have some observations and questions about it. Maybe
somebody here can shed some light on them. Thanks.
Hi ! What is Ocotea ! :)
1. Obviously MSI
But anyway, it's mainly internal cleanup and adapting drivers
from the public version on my git tree to this newest/cleaner
version is a 15 min work ;)
Any reason why you aren't regulary submitting those patches for upstream
inclusion ?
Ben.
On Sat, 2006-07-01 at 11:15 +0200, Wolfgang Denk wrote:
In message 1151709367.27137.4.camel at localhost.localdomain you wrote:
I don;t know - the patches were submitted to this list a long time
ago; we added them to our repository without any additional problems;
see
On Fri, 2006-07-07 at 18:15 -0400, gturnock at ivhs.com wrote:
Hi All,
I am currently attempting to get the 2.6 Linux Kernel
( Sylvain's Kernel from
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git) booting over
NFS on a Freescale LITE5200 board. At present, I have been able to
All PCI VGA cards for use on x86 PCs have a ROMscan
BIOS
extension on them. This initializes the card after POST -
basically,
the motherboard BIOS transfers control to the BIOS on the
PCI VGA card, which then initializes itself. If
Only memory mapped into userland contexts can be paged out in the first
place.
Ben.
Our system crashes in the function ppc4xx_gdb_init() in file
ppc4xx_setup.c. Without this call bootup look much better ;-). Any
comments on this?
The function dereferences the regs of the init.task which no longer
exist. (And was previously not properly initialized anyway).
I noticed that the
Will you please check that in? I pused the files but couldn't
decide which method of initialization was current :-).
I'm still sorting out the bootloader stuff.
I'll do tomorrow when I'm at work.
Note that I still didn't manage to get userland to work on
my 405GP. I'm suspecting an issue
I'm working on this at the moment too. The first problem I found was
that the ELF loader would refuse to exec() init, which turned out to
be because bytes 16-32 (and possibly later ones too, I forget) of
binprm-buf were junk. The data was correct in the page cache. I
found this was fixed by
1 - 100 of 157 matches
Mail list logo
