headers
Michael Ellerman | 1 Aug 2007 01:06
Picon
Gravatar

Re: [PATCH 1/3] Add a new member name to structure irq_host

On Wed, 2007-08-01 at 00:13 +0200, Segher Boessenkool wrote:
> >>> Which makes me think (again) that we should have an optional
> >>> device_node
> >>> pointer in irq_host. I know you said you wanted the irq stuff to be 
> >>> OF
> >>> agnostic, but the reality is most of the implementations do have an 
> >>> OF
> >>> node. And all of the newer irq_host implementations do, with the
> >>> exception of PS3 and celleb - which are special.
> >>
> >> How do you suggest to get a reasonable display name out of
> >> the device tree?  The recommended human-readable name for
> >> interrupt controller nodes is "interrupt-controller"...
> >> You cannot use "device_type" either, and using "compatible"
> >> requires selecting one of its string entries, and likely
> >> using a lookup table after that, too.
> >
> > In that case, I would display the node full path.
> 
> Those tend to be quite long, in the cases where there are
> multiple interrupt controllers in the system; and really
> useless otherwise.  I think the interrupt controllers should
> still just fill in the names "manually".

They tend to be long, but they're unique, which is what you want, and
they're only for debugging anyway.

> It's a good thing to have an of_node in the irq_host struct
> anyway, though :-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Segher Boessenkool | 1 Aug 2007 01:42

Re: [PATCH 1/3] Add a new member name to structure irq_host

>>> In that case, I would display the node full path.
>>
>> Those tend to be quite long, in the cases where there are
>> multiple interrupt controllers in the system; and really
>> useless otherwise.  I think the interrupt controllers should
>> still just fill in the names "manually".
>
> They tend to be long, but they're unique, which is what you want,

Yeah -- easy enough to add a sequence number to just about
anything though.

> and they're only for debugging anyway.

Oh, I thought it would be used wherever the user gets told something
about the interrupt controller -- like when the interrupt tree would
be shown in sysfs (yes that's hypothetical still ;-) )

>> It's a good thing to have an of_node in the irq_host struct
>> anyway, though :-)
>
> I posted patches for that last week.

I know, and thank you :-)

Segher
Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Aug 2007 01:56
Picon

Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface

> The hardware is called (E)IDE, the protocol is called ATA.
> Or that's what I was told -- I think there's some historic
> revisionism involved, too.

ATA is the interface and standards for the ANSI standards based disk
attachment. IDE "Integrated Drive Electronics" is a marketing name used
to cover all sorts of ST412 compatible-ish early interfaces that moved
the brains onto the disk. IDE doesn't really mean much but "brains on
disk", ATA is a real standard.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Dave Jiang | 1 Aug 2007 02:16

Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver

Arnd Bergmann wrote:
> On Wednesday 01 August 2007, Dave Jiang wrote:
>> Doh! I sent out the reworked patches right before your comments. Do you happen
>> to know where I can find an example of how to do this? In regards to making a
>> platform_device a child of the PCI host bridge that is.... Thanks!
>>
> 
> When you use an open-coded version of platform_device_register_simple(),
> you can set dev->parent before calling platform_device_add.
> 
> 	Arnd <><

Do you mean the pci_controller hose that's allocated in fsl_add_bridge? Couple
questions....
1. How do I even get access to that? (in fsl_soc.c that is)
2. pci_controller has no "struct device" member. It only has "struct device
*parent". What do I set the dev->parent of the platform device to?

--

-- 

------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
Permalink | Reply | 1 comment |
headers
David Gibson | 1 Aug 2007 03:19
Picon

Re: DTC 1.0.0 Release Coming?

On Tue, Jul 31, 2007 at 11:11:57PM +0200, Segher Boessenkool wrote:
> > Ok, figured out why.  When I push, then pop a quilt patch some of the
> > files end up with their original contents, but changed timestamps.
> > That altered stat information causes git-diff-index to give false
> > indications of changed files, so setlocalversion adds the -dirty.
> > Running git status, or gitool or various other things causes git to
> > notice that the files aren't really changed, updates the index and
> > then the version is generated correctly again.
> >
> > Not very robust though.
> 
> Well you can't blame that on DTC's build system, nor on the
> setlocalversion script, and not on Git either; it's a Quilt
> problem...

No, it's really not - touching the files on a pop is correct behaviour
for quilt (that way it will correctly trigger a rebuild on make
systems that aren't as flashy as Kbuild).

setlocalversion should be ensuring that the verison information is
based on content, not stat info, which means it needs to do a git
status or something that will remove the false positives before using
git-diff-index to determine whether the tree is clean or not.

But I still think my approach of basing the version info directly off
a hash or the source is nicer still.

--

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Ellerman | 1 Aug 2007 03:34
Picon
Gravatar

[PATCH 1/1] Fix parse_drconf_memory() for 64-bit start addresses

Some new machines use the "ibm,dynamic-reconfiguration-memory" property
to provide memory layout information, rather than via memory nodes.

There is a bug in the code to parse this property for start addresses over
4GB, we throw away the high bits and add apparently duplicate regions. This
results in a BUG() in free_bootmem_core().

Signed-off-by: Michael Ellerman <michael <at> ellerman.id.au>
---
 arch/powerpc/mm/numa.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index de45aa8..c12adc3 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
 <at>  <at>  -307,9 +307,9  <at>  <at>  static void __init parse_drconf_memory(struct device_node *memory)
 	const unsigned int *lm, *dm, *aa;
 	unsigned int ls, ld, la;
 	unsigned int n, aam, aalen;
-	unsigned long lmb_size, size;
+	unsigned long lmb_size, size, start;
 	int nid, default_nid = 0;
-	unsigned int start, ai, flags;
+	unsigned int ai, flags;

 	lm = of_get_property(memory, "ibm,lmb-size", &ls);
 	dm = of_get_property(memory, "ibm,dynamic-memory", &ld);
--

-- 
1.5.1.3.g7a33b
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Mackerras | 1 Aug 2007 03:03
Picon
Favicon

Re: ipv6 in yaboot

Doug Maxey writes:

> I just got asked about ipv6 support in yaboot and a quick investigation
> showed _no_ knowledge of the address formats in the code.
> 
> Should I be submitting an RFC for a full parser that can pick that 
> apart?  Or does has someone have code lurking in the shadows, that 
> just needed some prompting?  :)

I would have thought that yaboot would just be passing any network
addresses in text form to some OF method, so it's up to OF to
understand ipv6 address formats.  No?

Paul.
Permalink | Reply | 4 comments |
headers
Paul Mackerras | 1 Aug 2007 04:04
Picon
Favicon

[PATCH] Use 1TB segments

This makes the kernel use 1TB segments for all kernel mappings and for
user addresses of 1TB and above, on machines which support them
(currently POWER5+ and POWER6).  We don't currently use 1TB segments
for user addresses < 1T, since that would effectively prevent 32-bit
processes from using huge pages unless we also had a way to revert to
using 256MB segments.

We detect that the machine supports 1TB segments by looking at the
ibm,processor-segment-sizes property in the device tree.

Parts of this patch were originally written by Ben Herrenschmidt.

Signed-off-by: Paul Mackerras <paulus <at> samba.org>
---
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2b66d53..4377edd 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
 <at>  <at>  -373,8 +373,16  <at>  <at>  END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 
 	ld	r8,KSP(r4)	/* new stack pointer */
 BEGIN_FTR_SECTION
+	b	2f
+END_FTR_SECTION_IFCLR(CPU_FTR_SLB)
+BEGIN_FTR_SECTION
 	clrrdi	r6,r8,28	/* get its ESID */
 	clrrdi	r9,r1,28	/* get current sp ESID */
+END_FTR_SECTION_IFCLR(CPU_FTR_1T_SEGMENT)
+BEGIN_FTR_SECTION
+	clrrdi	r6,r8,40	/* get its 1T ESID */
(Continue reading)

Permalink | Reply | 12 comments |
headers
David Gibson | 1 Aug 2007 04:08
Picon

Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS

On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> AMCC Sequoia board DTS
> 
> Signed-off-by: Valentine Barshak <vbarshak <at> ru.mvista.com>
> ---
>  arch/powerpc/boot/dts/sequoia.dts |  292 ++++++++++++++++++++++++++++++++++++++
>  1 files changed, 292 insertions(+)
> 
> diff -ruN linux.orig/arch/powerpc/boot/dts/sequoia.dts linux/arch/powerpc/boot/dts/sequoia.dts
> --- linux.orig/arch/powerpc/boot/dts/sequoia.dts	1970-01-01 03:00:00.000000000 +0300
> +++ linux/arch/powerpc/boot/dts/sequoia.dts	2007-07-27 20:44:26.000000000 +0400
>  <at>  <at>  -0,0 +1,292  <at>  <at> 
> +/*
> + * Device Tree Source for AMCC Sequoia
> + *
> + * Based on Bamboo code by Josh Boyer <jwboyer <at> linux.vnet.ibm.com>
> + * Copyright (c) 2006, 2007 IBM Corp.
> + *
> + * FIXME: Draft only!
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * To build:
> + *   dtc -I dts -O asm -o bamboo.S -b 0 sequoia.dts
> + *   dtc -I dts -O dtb -o bamboo.dtb -b 0 sequoia.dts

Needs updating to remove the bamboo references.  In fact we can
probably get rid of this "To build" comment that's been copied to just
(Continue reading)

Permalink | Reply | 47 comments |
headers
David Gibson | 1 Aug 2007 04:09
Picon

Re: [PATCH 3/6] PowerPC 440EPx: 440EPx/440EP dcr defines

On Mon, Jul 30, 2007 at 07:12:45PM +0400, Valentine Barshak wrote:
> This patch adds DCR defines needed for 440EP/440EPx clock initialization.
> These defines have been introduced in the Bamboo support by Josh Boyer
> and are needed for Sequoia as well.

These should really go in the same patch that uses them.  I dislike
this business of splitting patches up when the parts are functionally
dependent on each other.

> 
> Signed-off-by: Josh Boyer <jwboyer <at> linux.vnet.ibm.com>
> Signed-off-by: Valentine Barshak <vbarshak <at> ru.mvista.com>
> ---
>  arch/powerpc/boot/dcr.h |   11 +++++++++++
>  1 files changed, 11 insertions(+)
> 
> diff -ruN linux.orig/arch/powerpc/boot/dcr.h linux/arch/powerpc/boot/dcr.h
> --- linux.orig/arch/powerpc/boot/dcr.h	2007-07-27 20:37:10.000000000 +0400
> +++ linux/arch/powerpc/boot/dcr.h	2007-07-27 21:06:11.000000000 +0400
>  <at>  <at>  -121,4 +121,15  <at>  <at> 
>  #define DCRN_CPC0_MIRQ1					0x0ed
>  #define DCRN_CPC0_JTAGID				0x0ef
>  
> +/* 440EP/440EPx  Clock/Power-on Reset regs */
> +#define DCRN_CPR0_ADDR	0xc
> +#define DCRN_CPR0_DATA	0xd
> +#define CPR0_PLLD0	0x60
> +#define CPR0_OPBD0	0xc0
> +#define CPR0_PERD0	0xe0
> +#define CPR0_PRIMBD0	0xa0
(Continue reading)

Permalink | Reply | 1 comment |

Gmane