* Please pull from 'merge' branch for 2.6.30 (updated)
From: Kumar Gala @ 2009-04-27 20:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
Can we possibly get this and the other pull requests dealt with and sent
to Linus so we might get such fixes in before he tags a -rc4.
thanks
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/boot/dts/gef_ppc9a.dts | 1 +
arch/powerpc/include/asm/mmu.h | 6 ------
arch/powerpc/include/asm/ppc-opcode.h | 11 +----------
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/mm/tlb_nohash_low.S | 16 ++--------------
5 files changed, 5 insertions(+), 31 deletions(-)
Kumar Gala (1):
Revert "powerpc: Add support for early tlbilx opcode"
Martyn Welch (1):
powerpc/86xx: Add device_type entry to soc for ppc9a
Stephen Rothwell (1):
powerpc: fix for long standing bug noticed by gcc 4.4.0
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:12 UTC (permalink / raw)
To: Kumar Gala
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <9B86B565-1A28-46CD-8C30-DECB3EBF0763@kernel.crashing.org>
>>>> Can you give me an example of non-PCI memory that would be
>>>> non-prefetchable that you'd like us to try? We can see if our
>>>> host CPUs have an area like that ... we just need to know
>>>> what device to look for first :)
>>> You can mark the pci inbound window on the 83xx as non-prefetchable
>>> (assuming 83xx is host). On a x86 host I doubt there is any easy way
>>> to get non-prefetchable memory.
>>
>> Yep, we were going to do that, but chose to use the
>> 1MB region already setup for the IMMRs since its already
>> marked as non-prefetchable. We were only doing reads, so
>> it wasn't going to hurt anything.
>>
>> I doubt that marking one of the other BAR regions
>> as non-prefetchable will give a different result.
>> However, we're more than happy to double-check if
>> you'd like.
>
> Its possible you'll get a different result since IMMR is a register
> space internal and thats normally a completely different bus than memory
> would be (internal to the 83xx). I'd suggest double-checking w/a BAR
> marked non-prefetch pointing to real memory.
We had a 4k BAR1 setup to point to DDR memory.
With prefetchable set, a 36-byte transfer generated a
burst-of-8 32-bit words followed by a single transaction.
With non-prefetchable set, the transfers were all single.
So it works like we'd expect.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 20:04 UTC (permalink / raw)
To: David Hawkins
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F60BF8.8040404@ovro.caltech.edu>
David Hawkins wrote:
> Can you give me an example of non-PCI memory that would be
> non-prefetchable that you'd like us to try? We can see if our
> host CPUs have an area like that ... we just need to know
> what device to look for first :)
Hmmmm.... I was going to say any SOC device in the IMMR, but I don't see
anything there that would constitute a memory buffer.
I test this change on an 8610 and DMA to a register I/O, where this bit
isn't even defined, and it made no difference. So I guess this change
is okay.
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-04-27 20:02 UTC (permalink / raw)
To: David Hawkins
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <49F60EC9.2050501@ovro.caltech.edu>
On Apr 27, 2009, at 3:00 PM, David Hawkins wrote:
>
>>> Can you give me an example of non-PCI memory that would be
>>> non-prefetchable that you'd like us to try? We can see if our
>>> host CPUs have an area like that ... we just need to know
>>> what device to look for first :)
>> You can mark the pci inbound window on the 83xx as non-prefetchable
>> (assuming 83xx is host). On a x86 host I doubt there is any easy
>> way to get non-prefetchable memory.
>
> Yep, we were going to do that, but chose to use the
> 1MB region already setup for the IMMRs since its already
> marked as non-prefetchable. We were only doing reads, so
> it wasn't going to hurt anything.
>
> I doubt that marking one of the other BAR regions
> as non-prefetchable will give a different result.
> However, we're more than happy to double-check if
> you'd like.
Its possible you'll get a different result since IMMR is a register
space internal and thats normally a completely different bus than
memory would be (internal to the 83xx). I'd suggest double-checking w/
a BAR marked non-prefetch pointing to real memory.
- k
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:01 UTC (permalink / raw)
To: Kumar Gala
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <49F60EC9.2050501@ovro.caltech.edu>
>> You can mark the pci inbound window on the 83xx as non-prefetchable
>> (assuming 83xx is host). On a x86 host I doubt there is any easy way
>> to get non-prefetchable memory.
One more note; we don't have access to a host-mode MPC8349EA,
our boards are all targets.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:00 UTC (permalink / raw)
To: Kumar Gala
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <46B638E2-885C-4281-81EA-CB685264E143@kernel.crashing.org>
>> Can you give me an example of non-PCI memory that would be
>> non-prefetchable that you'd like us to try? We can see if our
>> host CPUs have an area like that ... we just need to know
>> what device to look for first :)
>
> You can mark the pci inbound window on the 83xx as non-prefetchable
> (assuming 83xx is host). On a x86 host I doubt there is any easy way to
> get non-prefetchable memory.
Yep, we were going to do that, but chose to use the
1MB region already setup for the IMMRs since its already
marked as non-prefetchable. We were only doing reads, so
it wasn't going to hurt anything.
I doubt that marking one of the other BAR regions
as non-prefetchable will give a different result.
However, we're more than happy to double-check if
you'd like.
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-04-27 19:54 UTC (permalink / raw)
To: David Hawkins
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Timur Tabi
In-Reply-To: <49F60BF8.8040404@ovro.caltech.edu>
On Apr 27, 2009, at 2:48 PM, David Hawkins wrote:
> Can you give me an example of non-PCI memory that would be
> non-prefetchable that you'd like us to try? We can see if our
> host CPUs have an area like that ... we just need to know
> what device to look for first :)
You can mark the pci inbound window on the 83xx as non-prefetchable
(assuming 83xx is host). On a x86 host I doubt there is any easy way
to get non-prefetchable memory.
- k
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 19:48 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F60A3A.4060402@freescale.com>
>> Would you like some sort of summary of this info for a commit
>> message?
>
> That's probably overkill. I just want a sentence or two that tells
> someone looking at the code casually that the behavior of reading PCI
> memory might be different than what they expect.
Ok, will-do.
>> Would you like us to check any other transaction/register combos?
>
> Yes, could you try this on non-PCI memory?
We've been using it to DMA between the x86 host main memory and
the MPC8349EA boards (PCI targets). The reason we changed to
Read Multiple was that it had a dramatic improvement in
efficiency through bridges. However, the x86 host memory
is prefetchable, so is consistent with the use of Read Multiple.
Can you give me an example of non-PCI memory that would be
non-prefetchable that you'd like us to try? We can see if our
host CPUs have an area like that ... we just need to know
what device to look for first :)
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Kumar Gala @ 2009-04-27 19:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Michael Neuling, Paul Mackerras, Milton Miller
In-Reply-To: <439723CB-6615-428B-9A7F-C6CBA5EB7CBE@kernel.crashing.org>
On Apr 27, 2009, at 2:31 PM, Kumar Gala wrote:
>
> On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
>
>> Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
>> ===================================================================
>> --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
>> +++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
>> @@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
>> #define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
>> #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
>> #define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
>> +#define CPU_FTR_TLBIE_206 LONG_ASM_CONST(0x0100000000000000)
>>
>> #ifndef __ASSEMBLY__
>>
>> @@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
>> CPU_FTR_MMCRA | CPU_FTR_SMT | \
>> CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
>> CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
>> - CPU_FTR_DSCR | CPU_FTR_SAO)
>> + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_TLBIE_206)
>> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
>> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
>> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
>
> I think our preference is to use MMU features for such things now
> instead of burning a cpu feature for it.
I see Ben has already made this comment.. so I just second his notion.
- k
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 19:40 UTC (permalink / raw)
To: David Hawkins
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F608B7.9080409@ovro.caltech.edu>
David Hawkins wrote:
> Would you like some sort of summary of this info for a commit
> message?
That's probably overkill. I just want a sentence or two that tells
someone looking at the code casually that the behavior of reading PCI
memory might be different than what they expect.
> Would you like us to check any other transaction/register combos?
Yes, could you try this on non-PCI memory?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
From: Kumar Gala @ 2009-04-27 19:29 UTC (permalink / raw)
To: Rogério Brito
Cc: linuxppc-dev, linux-mtd, Guennadi Liakhovetski, linux-kernel
In-Reply-To: <20090424223355.GB7858@ime.usp.br>
On Apr 24, 2009, at 5:33 PM, Rog=E9rio Brito wrote:
> This patch addresses the following issues:
>
>
> 01. makes CFQ the default scheduler, to be in line with the rest of =20=
> the kernel.
>
> 02. since linkstations are meant to store files, enable large blk =20
> devices.
>
> 03. disable CONFIG_MIGRATION in in such low memory devices.
>
> 04. disable CONFIG_BLK_DEV_RAM.
do we not allow booting a ramdisk?
> 05. disable CONFIG_SCSI_LOWLEVEL, as no device under that tree is =20
> used.
>
> 06. idem for CONFIG_NETDEV_10000.
>
> 07. idem for CONFIG_WIRELESS.
>
> 08. idem for CONFIG_HWMON.
>
> 09. idem for CONFIG_CRYPTO_HW.
>
> 10. disable CONFIG_VIDEO_OUTPUT_CONTROL.
>
> 11. keep consistency and disable extended attributes in CIFS, ext3, =20=
> and NFS.
>
> 12. enable CONFIG_PRINTK_TIME.
>
> Signed-off-by: Rog=E9rio Brito <rbrito@ime.usp.br>
>
> ---
>
> Dear Kumar, please, apply this one.
>
> I have another patch regarding one regression regarding MTD &
> PHYSMAP_COMPAT that I plan to send on top of this one.
>
> Thanks.
Ok, can we look at just specifying such info in the linkstation device =20=
tree.
Also, can you break this defconfig update into two patches. 1. that =20
just updates to 2.6.30-rc3 (or latest) and 2. that makes the various =20
changes you've listed above.
- k=
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 19:34 UTC (permalink / raw)
To: Timur Tabi
Cc: Ira Snyder, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Zhang Wei
In-Reply-To: <ed82fe3e0904270731g2d2519a7mc12e4152c716c0a9@mail.gmail.com>
Hi all,
>> You are assuming the PCI memory space is prefetchable( no side effect)
>> for DMA. Is it possible that DMA is from non-prefetchable memory space?
>
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
> PCI memory that you are reading from should be just a buffer of data,
> and there should be side-effect of reading it.
>
> However, I would like to see a comment at the top of the file warning
> people that copying from PCI memory will result in prefetched reads.
>
Here's a few results from DMA tests between two
MPC8349EA boards housed in a CPCI chassis.
1. DMA mode register (DMAMRn)
PCI read command (PRC, bits 11:10)
a) DMAMRn[PRC] = 00 = PCI Read
The PCI read command is 6h on the PCI bus.
For DMA lengths of less than 1 cache line (32-bytes)
the DMA controller will generate a PCI 6h command.
However, for lengths of 32-bytes and higher, the
DMA controller actually generates a PCI Read Line (Eh)
command.
Freescale indicated that this 'change of PCI command code'
functionality is an undocumented 'feature', there to
improve performance for longer read lengths.
b) DMAMRn[PRC] = 01 = PCI Read Line
Generated the PCI command code for PCI read line (Eh),
regardless of DMA length.
c) DMAMRn[PRC] = 10 = PCI Read Multiple
Generated the PCI command code for PCI Read Multiple (Ch),
regardless of DMA length.
2. DMA from areas marked as non-prefetchable.
We setup two test cases:
a) Two boards in the same PCI segment with no intervening
bridges.
b) Two boards in separate PCI segments with intervening
bridges (in this case, there was two bridges on SBS
CPCI-to-CPI backplane bridging cards).
The PCI window to the IMMR registers on the boards is marked
as non-prefetchable. DMA from that area (reads) appeared on the
PCI bus as single 32-bit read transactions, i.e., the target
device effectively ignores the PCI read command, and the target
returns read data as single reads, i.e., the target acts as
as non-prefetchable memory.
We tested with the PCI Read Multiple command, and no data
was ever prefetched from the target. The bridges did not
prefetch and discard data, eg. we tried 36-bytes, and there
were 9 separate 4-byte transactions (we were using a 32-bit
PCI host for this test). Hence, at least for this example
target device, there are no side effects to using PCI
read multiple on the bus master, to a target PCI memory
region marked as non-prefetchable.
So even though the bridges were seeing transactions that
indicated read multiple, only single read cycles were
seen to be used.
Would you like some sort of summary of this info for a commit
message?
Would you like us to check any other transaction/register combos?
Cheers,
Dave
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Kumar Gala @ 2009-04-27 19:31 UTC (permalink / raw)
To: Michael Neuling; +Cc: Paul Mackerras, Milton Miller, linuxppc-dev
In-Reply-To: <20090424062431.D3803120E7@localhost.localdomain>
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
> Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
> +++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
> @@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
> #define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
> #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
> #define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
> +#define CPU_FTR_TLBIE_206 LONG_ASM_CONST(0x0100000000000000)
>
> #ifndef __ASSEMBLY__
>
> @@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
> CPU_FTR_MMCRA | CPU_FTR_SMT | \
> CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
> CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
> - CPU_FTR_DSCR | CPU_FTR_SAO)
> + CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_TLBIE_206)
> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
I think our preference is to use MMU features for such things now
instead of burning a cpu feature for it.
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Add 2.06 tlbie mnemonics
From: Kumar Gala @ 2009-04-27 19:30 UTC (permalink / raw)
To: Michael Neuling; +Cc: Paul Mackerras, Milton Miller, linuxppc-dev
In-Reply-To: <20090424062431.D3803120E7@localhost.localdomain>
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
> Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c
> +++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
> @@ -38,6 +38,9 @@
>
> static DEFINE_SPINLOCK(native_tlbie_lock);
>
> +#define TLBIE(lp,a) \
> + stringify_in_c(.long 0x7c000264 | ((a) << 11) | ((lp) << 21))
> +
Put this ppc-opcode.h now that we have it.
- k
^ permalink raw reply
* [PATCH v6] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-04-27 19:05 UTC (permalink / raw)
To: linuxppc-dev, galak, benh, jwboyer, scottwood
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
I'm making this a PowerPC-specific patch because I want to use
tb_ticks_per_usec, which does not exist on all other platforms. I don't want
to use jiffies because jiffies works only when interrupts are enabled, and
the resolution may not be fine enough.
arch/powerpc/include/asm/delay.h | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..1939e0f 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,6 +2,8 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include <asm/time.h>
+
/*
* Copyright 1996, Paul Mackerras.
*
@@ -30,5 +32,30 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates if the bit never changes. The delay is for devices that need a
+ * delay in between successive reads.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ udelay(delay); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
^ permalink raw reply related
* [PATCH] alim15x3: Remove historical hacks, re-enable init_hwif for PowerPC
From: Anton Vorontsov @ 2009-04-27 18:47 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linuxppc-dev, Roderick Colenbrander, linux-ide
In-Reply-To: <c8485d470904270146g7b7204eckc58cd57449a41f45@mail.gmail.com>
Some time ago we had to disable init_hwif callback for PowerPC builds.
That was because of a historical IRQ overwrite in the driver, which
was causing IDE malfunction on the MPC8610HPCD PowerPC boards.
It's unclear whether this overwrite is still useful, but it is proven
to cause a bit of harm, and today some PowerPC targets (Xilinx ML510,
as reported by Roderick Colenbrander) need the init_hwif, so we have
to re-enable it and remove the overwrite.
Reported-by: Roderick Colenbrander <thunderbird2k@gmail.com>
Suggested-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
On Mon, Apr 27, 2009 at 10:46:25AM +0200, Roderick Colenbrander wrote:
> >> Seems like this should allow MPC8610HPCD to work with Roderick's patch
> >> if the IDE controller is set to native mode and ALI south-bridge SIRQ
> >> tables are correctly set (or if this is not ALI's south-bridge). Anton?
> >
> > OK, I'll test this approach.
> >
>
> Did this approach work for you?
I'm sorry for the delay. Yes, it seem to work.
drivers/ide/alim15x3.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/ide/alim15x3.c b/drivers/ide/alim15x3.c
index 537da1c..e59b6de 100644
--- a/drivers/ide/alim15x3.c
+++ b/drivers/ide/alim15x3.c
@@ -402,27 +402,23 @@ static u8 ali_cable_detect(ide_hwif_t *hwif)
return cbl;
}
-#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
+#ifndef CONFIG_SPARC64
/**
* init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
* @hwif: interface to configure
*
* Obtain the IRQ tables for an ALi based IDE solution on the PC
* class platforms. This part of the code isn't applicable to the
- * Sparc and PowerPC systems.
+ * Sparc systems.
*/
static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
{
- struct pci_dev *dev = to_pci_dev(hwif->dev);
u8 ideic, inmir;
s8 irq_routing_table[] = { -1, 9, 3, 10, 4, 5, 7, 6,
1, 11, 0, 12, 0, 14, 0, 15 };
int irq = -1;
- if (dev->device == PCI_DEVICE_ID_AL_M5229)
- hwif->irq = hwif->channel ? 15 : 14;
-
if (isa_dev) {
/*
* read IDE interface control
@@ -455,7 +451,7 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
}
#else
#define init_hwif_ali15x3 NULL
-#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
+#endif /* CONFIG_SPARC64 */
/**
* init_dma_ali15x3 - set up DMA on ALi15x3
--
1.6.2.2
^ permalink raw reply related
* Re: [PATCH] powerpc/86xx: Add device_type entry to soc for ppc9a
From: Kumar Gala @ 2009-04-27 18:02 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20090427162428.8133.23523.stgit@ubuntu8041.localdomain>
On Apr 27, 2009, at 11:24 AM, Martyn Welch wrote:
> The 'device_type = "soc";' line *is* needed in the DTS for
> get_immrbase()
> to return the correct address.
>
> Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
> ---
>
> arch/powerpc/boot/dts/gef_ppc9a.dts | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
applied to merge
- k
^ permalink raw reply
* Re: [PATCH] 83xx: add support for the kmeter1 board.
From: Scott Wood @ 2009-04-27 18:05 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev
In-Reply-To: <49F544DE.1010307@denx.de>
On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
> 1) add in the soc node an "errata" node and in this "errata" node
> we can add all CPU specific errata as an example the qe_enet10
> errata, which above code covers:
What about errata discovered after the device tree is deployed?
> soc8360@e0000000 {
> [...]
> errata {
> device_type = "errata";
device_type is deprecated except for a couple of legacy uses. Please do
not add new ones.
> compatible = "fsl,mpc83xx_errata";
To be bound to by an "errata driver"? :-P
> #address-cells = <1>;
> #size-cells = <1>;
>
> qe_enet10@14a8 {
> device_type = "errata";
> compatible = "fsl,mpc83xx_errata_qe_enet10";
> reg = <0x14a8 0x08>;
But that register is part of the "QE parallel I/O port" block (even if it
happens to be undocumented within that block), not part of the "QE ENET10
erratum" block. The device tree describes the hardware, not what you
want to do with it.
The presence of the erratum itself is indicated by the presence of the
buggy device, possibly in conjunction with SVR if the device tree is not
specific enough.
-Scott
^ permalink raw reply
* [PATCH 2/2] powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
From: Kumar Gala @ 2009-04-27 17:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
In-Reply-To: <1240855188-24879-1-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/gef_ppc9a.dts | 13 +++++++++++++
arch/powerpc/boot/dts/gef_sbc310.dts | 13 +++++++++++++
arch/powerpc/boot/dts/gef_sbc610.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 13 +++++++++++++
arch/powerpc/boot/dts/sbc8641d.dts | 13 +++++++++++++
7 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts b/arch/powerpc/boot/dts/gef_ppc9a.dts
index d47ad07..cbf135c 100644
--- a/arch/powerpc/boot/dts/gef_ppc9a.dts
+++ b/arch/powerpc/boot/dts/gef_ppc9a.dts
@@ -166,6 +166,19 @@
reg = <0xfef00000 0x100000>; // CCSRBAR 1M
bus-frequency = <33333333>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c1: i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index 1569117..155776c 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -166,6 +166,19 @@
reg = <0xfef00000 0x100000>; // CCSRBAR 1M
bus-frequency = <33333333>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c1: i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 6582dbd..6898d7e 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -131,6 +131,19 @@
reg = <0xfef00000 0x100000>; // CCSRBAR 1M
bus-frequency = <33333333>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c1: i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 4f081bb..252db6e 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -115,6 +115,19 @@
reg = <0xe0000000 0x1000>;
bus-frequency = <0>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8610-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 51852e6..8bcccd7 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -117,6 +117,19 @@
reg = <0xffe00000 0x00001000>; // CCSRBAR
bus-frequency = <0>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
index b5dc942..d4c909d 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
@@ -110,6 +110,19 @@
reg = <0x0f 0xffe00000 0x0 0x00001000>; // CCSRBAR
bus-frequency = <0>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/powerpc/boot/dts/sbc8641d.dts b/arch/powerpc/boot/dts/sbc8641d.dts
index cfd5782..aa8f931 100644
--- a/arch/powerpc/boot/dts/sbc8641d.dts
+++ b/arch/powerpc/boot/dts/sbc8641d.dts
@@ -129,6 +129,19 @@
reg = <0xf8000000 0x00001000>; // CCSRBAR
bus-frequency = <0>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/2] powerpc/86xx: Add binding for LAWs and MCM
From: Kumar Gala @ 2009-04-27 17:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the MPX coherency
module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 ++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mcm.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcm.txt b/Documentation/powerpc/dts-bindings/fsl/mcm.txt
new file mode 100644
index 0000000..4ceda9b
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mcm.txt
@@ -0,0 +1,64 @@
+=====================================================================
+MPX LAW & Coherency Module Device Tree Binding
+Copyright (C) 2009 Freescale Semiconductor Inc.
+=====================================================================
+
+Local Access Window (LAW) Node
+
+The LAW node represents the region of CCSR space where local access
+windows are configured. For MCM based devices this is the first 4k
+of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
+number of local access windows as specified by fsl,num-laws.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,mcm-law"
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - fsl,num-laws
+ Usage: required
+ Value type: <u32>
+ Definition: The value specifies the number of local access
+ windows for this device.
+
+=====================================================================
+
+MPX Coherency Module Node
+
+The MPX LAW node represents the region of CCSR space where MCM config
+and error reporting registers exist, this is the second 4k (0x1000)
+of CCSR space.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,CHIP-mcm", "fsl,mcm" where
+ CHIP is the processor (mpc8641, mpc8610, etc.)
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - interrupts
+ Usage: required
+ Value type: <prop-encoded-array>
+
+ - interrupt-parent
+ Usage: required
+ Value type: <phandle>
+
+=====================================================================
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
From: Grant Likely @ 2009-04-27 17:50 UTC (permalink / raw)
To: Scott Wood
Cc: Joakim Tjernlund, linuxppc-dev, Andy Fleming, netdev,
David Miller
In-Reply-To: <20090427173606.GA10292@ld0162-tx32.am.freescale.net>
On Mon, Apr 27, 2009 at 11:36 AM, Scott Wood <scottwood@freescale.com> wrot=
e:
> On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> Previous rework to ucc_geth.c to add of_mdio support (net: Rework
>> ucc_geth driver to use of_mdio infrastructure) added a block of
>> code which broke older openfirmware device trees which use an
>> 'interface' property in the phy node to describe the connection
>> between the MAC and the PHY. =A0This patch removes the offending blurb.
> [snip]
>> =A0 =A0 =A0 prop =3D of_get_property(np, "phy-connection-type", NULL);
>> =A0 =A0 =A0 if (!prop) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* handle interface property present in old =
trees */
>> - =A0 =A0 =A0 =A0 =A0 =A0 if (!phy)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENODEV;
>> -
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 prop =3D of_get_property(phy, "interface", N=
ULL);
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (prop !=3D NULL) {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 phy_interface =3D enet_to_ph=
y_interface[*prop];
>
> The above test only makes a difference when there is no phy node -- so I
> don't see how it was breaking device trees that had a phy node (with or
> without an "interface" property). =A0I can see it breaking fixed link
> device trees, though.
Sorry, you're right. I got myself confused when I was writing the
description. This patch fixes breakage when using a fixed-link and
there is no phy-connection-type property.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: How to use Localbus on 5200B w/ 2.6.29.1
From: Grant Likely @ 2009-04-27 17:36 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1240852719.3495.0@antares>
On Mon, Apr 27, 2009 at 11:18 AM, Albrecht Dre=DF <albrecht.dress@arcor.de>=
wrote:
> Hi all,
>
> I have a question about the definition of the localbus on the Freescale
> 5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which I
> could not figure out with the docs and the list archives...
>
> When I use 'compatible =3D "fsl,mpc5200b-lpb";' in the dts file, the loca=
lbus
> and any nodes below it don't show up in /sys/devices.
For completeness use: compatible =3D
"fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple-bus"; Then it will work.
The kernel doesn't currently bind on the 'b' string, but we put it in
the list anyway to completely describe the hardware, just in case it
ever becomes important in the future.
[...]
> =A0 =A0 =A0 =A0mydev@3,0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "mydev";
"mydev" should be in the form: "<vendor>,<device>".
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0 0x0 0x100>; =A0 =A0 =A0 =A0 =A0=
=A0// 256 Bytes, 32 used
If this is on CS3, then reg should be:
reg =3D <3 0x0 0x100>; // 256 Bytes, 32 used
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <1 3 2>; =A0 =A0 =A0 =A0 =
=A0 // todo - level?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&mpc5200_pic>;
> =A0 =A0 =A0 =A0};
> };
> # ls -al /sys/devices/f0000300.localbus/
> drwxr-xr-x =A0 =A04 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 .
> drwxr-xr-x =A0 =A07 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 ..
> -r--r--r-- =A0 =A01 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A04096 Jan =
=A01 00:00 devspec
> drwxr-xr-x =A0 =A02 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 fc000000.flash
> drwxr-xr-x =A0 =A02 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 fc000000.mydev
> -r--r--r-- =A0 =A01 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A04096 Jan =
=A01 00:00 modalias
> -r--r--r-- =A0 =A01 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A04096 Jan =
=A01 00:00 name
> lrwxrwxrwx =A0 =A01 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 Jan =
=A01 00:00 subsystem ->
> ../../bus/of_platform
> -rw-r--r-- =A0 =A01 0 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A04096 Jan =
=A01 00:00 uevent
> </snip>
>
> which is also confusing, as both devices appear to have the same address?
> =A0Any idea what goes wrong here?
Because the reg property for mydev is wrong (see above).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] net: Fix ucc_geth.c handling of phy 'interface' property.
From: Scott Wood @ 2009-04-27 17:36 UTC (permalink / raw)
To: Grant Likely
Cc: Joakim Tjernlund, linuxppc-dev, Andy Fleming, netdev,
David Miller
In-Reply-To: <20090427153612.5108.10877.stgit@localhost.localdomain>
On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Previous rework to ucc_geth.c to add of_mdio support (net: Rework
> ucc_geth driver to use of_mdio infrastructure) added a block of
> code which broke older openfirmware device trees which use an
> 'interface' property in the phy node to describe the connection
> between the MAC and the PHY. This patch removes the offending blurb.
[snip]
> prop = of_get_property(np, "phy-connection-type", NULL);
> if (!prop) {
> /* handle interface property present in old trees */
> - if (!phy)
> - return -ENODEV;
> -
> prop = of_get_property(phy, "interface", NULL);
> if (prop != NULL) {
> phy_interface = enet_to_phy_interface[*prop];
The above test only makes a difference when there is no phy node -- so I
don't see how it was breaking device trees that had a phy node (with or
without an "interface" property). I can see it breaking fixed link
device trees, though.
-Scott
^ permalink raw reply
* How to use Localbus on 5200B w/ 2.6.29.1
From: Albrecht Dreß @ 2009-04-27 17:18 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
Hi all,
I have a question about the definition of the localbus on the Freescale
5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which
I could not figure out with the docs and the list archives...
When I use 'compatible = "fsl,mpc5200b-lpb";' in the dts file, the
localbus and any nodes below it don't show up in /sys/devices.
When I use the following (top-level, not under the soc node) in the dts
file
<snip>
localbus {
compatible = "fsl,lpb";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0000300 0x32>;
ranges = < 0 0 0xfc000000 0x02000000
3 0 0xf0020000 0x00010000 >;
flash@0,0 {
compatible = "cfi-flash";
reg = <0 0x0 0x2000000>; // 32 MB
bank-width = <1>; // width in bytes of
the flash bank
device-width = <1>; // one devices on each
bank
#size-cells = <1>;
#address-cells = <1>;
};
mydev@3,0 {
compatible = "mydev";
reg = <0 0x0 0x100>; // 256 Bytes, 32 used
interrupts = <1 3 2>; // todo - level?
interrupt-parent = <&mpc5200_pic>;
};
};
</snip>
I see in /sys/devices
<snip>
# ls -al /sys/devices/
drwxr-xr-x 7 0 0 0 Jan 1 00:00 .
drwxr-xr-x 11 0 0 0 Jan 1 00:00 ..
drwxr-xr-x 31 0 0 0 Jan 1 00:00 f0000000.soc5200
drwxr-xr-x 4 0 0 0 Jan 1 00:00
f0000300.localbus
drwxr-xr-x 2 0 0 0 Jan 1 00:00 platform
drwxr-xr-x 5 0 0 0 Jan 1 00:00 system
drwxr-xr-x 8 0 0 0 Jan 1 00:00 virtual
</snip>
Does this mean that the documentation (and some existing dts files) are
inaccurate? What is the proper way to specify the localbus (or, in
particular, it's child nodes) on the 5200B?
In /sys/devices/f0000300.localbus, I see
<snip>
# ls -al /sys/devices/f0000300.localbus/
drwxr-xr-x 4 0 0 0 Jan 1 00:00 .
drwxr-xr-x 7 0 0 0 Jan 1 00:00 ..
-r--r--r-- 1 0 0 4096 Jan 1 00:00 devspec
drwxr-xr-x 2 0 0 0 Jan 1 00:00 fc000000.flash
drwxr-xr-x 2 0 0 0 Jan 1 00:00 fc000000.mydev
-r--r--r-- 1 0 0 4096 Jan 1 00:00 modalias
-r--r--r-- 1 0 0 4096 Jan 1 00:00 name
lrwxrwxrwx 1 0 0 0 Jan 1 00:00 subsystem ->
../../bus/of_platform
-rw-r--r-- 1 0 0 4096 Jan 1 00:00 uevent
</snip>
which is also confusing, as both devices appear to have the same
address? Any idea what goes wrong here?
The flash device itself (mydev isn't present yet...) also doesn't work
although mtd is enabled, but that's probably a different problem.
Any help would be really welcome!
Thanks in advance,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 00/13] OF device tree handling of PHY drivers
From: Grant Likely @ 2009-04-27 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, afleming, David Miller, netdev
In-Reply-To: <20090427.025436.68188155.davem@davemloft.net>
Kumar,
David has pulled my phylib changes into his -next tree. However, some
of the driver changes have been compile tested only due to lack of
hardware. Who can I ask to test the changes to the following files?
arch/powerpc/platforms/82xx/ep8248e.c | 9 +-
drivers/net/fs_enet/fs_enet-main.c | 69 +--
drivers/net/fs_enet/mii-bitbang.c | 29 +-
drivers/net/fs_enet/mii-fec.c | 26 +-
drivers/net/ucc_geth.c | 47 +-
drivers/net/ucc_geth.h | 2 +-
Thanks,
g.
On Mon, Apr 27, 2009 at 3:54 AM, David Miller <davem@davemloft.net> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
> Date: Sat, 25 Apr 2009 16:52:34 -0600
>
>> This series adds common code for reading PHY connection data out of
>> the OpenFirmware device tree. =A0This simplifies the network drivers
>> which use the device tree and which currently implement their own
>> solutions for reading the PHY data out of the device tree directly.
>>
>> I would like to see this series, or at least the core changes (1-4)
>> plus the tested drivers (5-8 & 12, but #12 is a new driver and it
>> may need more review), go into -next for 2.6.31.
>>
>> Due to dependencies, I think it is easiest if all of them go in via the
>> same tree. =A0David, are you willing to merge them via yours? =A0Four of=
the
>> patches are outside of drivers/net (patches 1 and 4 touch drivers/of/,
>> and patches 9 & 10 touch arch/powerpc), but I personally have no issues
>> if those changes go through you. =A0I just need to double check with Ben=
H.
>
> I've applied all of these patches to net-next-2.6, thanks.
>
>> =A0 git://git.secretlab.ca/git/linux-2.6 next-net
>
> You know, if you had actually based this tree on net-next-2.6
> I could have pulled from it. =A0I actually tried, and I got a
> lot of upstream stuff I wasn't ready to get in that tree just
> yet :-/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox