* Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
From: Anton Vorontsov @ 2008-03-26 23:07 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <47EABA4B.1000105@genesi-usa.com>
On Wed, Mar 26, 2008 at 09:04:11PM +0000, Matt Sealey wrote:
> Can someone throw me a link to the GPIO spec being implemented here (yes,
> I would like docs too!) or a pointer to the relevant DTS which implements
> it?
>
> Supporting GPIO in the device tree is something that has been undefined
> for ages, and I seem to not be able to find the supporting DTS patches for
> this implementation in patchwork..??
Here the last respin starts:
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/052881.html
> Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>>> Despite leds-gpio and leds-of-gpio similar names and purposes, there
>>> is actually very few code can be shared between the two (both drivers
>>> are mostly the driver bindings anyway).
>>>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>
>> Other than the fact that it needs some documentation of the binding in
>> booting-without-of.txt, it looks pretty good to me.
Thanks, will document it.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Matt Sealey @ 2008-03-26 22:57 UTC (permalink / raw)
To: Grant Likely, Matt Sealey, linuxppc-dev, Paul Mackerras,
Anatolij Gustschin
In-Reply-To: <20080326225128.GB5777@localhost.localdomain>
David Gibson wrote:
> On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
>>> Bartlomiej Sieka wrote:
>>> > +
>>> > + phy0:ethernet-phy@0 {
>>> > + device_type = "ethernet-phy";@0"
>>> > + reg = <0>;
>>> > + };
>>>
>>> What's the parsing of this pan out to? What does it mean?
>>>
>>> Having colons in device names is totally contrary to OF device naming
>>> spec. Does the part after the colon have a special meaning to the DTC?
>> "phy0:" is a label used by dtc.
>> "ethernet-phy@0" is the node name.
>
> I would suggest a space after the colon though, to make this clearer.
> That's the style I've been using in all my dts files.
I would suggest taking a hint from C structures...
ethernet-phy@0 {
name = "ethernet-phy";
reg = <0>;
foo = bar;
} phy0;
I mean, this is really intuitive, we all do this every day...
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
From: Anton Vorontsov @ 2008-03-26 22:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, i2c
In-Reply-To: <47EAB885.7000006@freescale.com>
On Wed, Mar 26, 2008 at 03:56:37PM -0500, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> > +config MCU_MPC837XRDB
> > + tristate "MPC837XRDB MCU driver"
> > + depends on I2C && MPC837x_RDB && OF_GPIO
>
> The MPC8349E-mITX also has this chip. Can you include support for that board as
> well?
Well, only if it has the same (or compatible) firmware.. then yes.
Thanks for the info, I'll look into this.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr
From: Kumar Gala @ 2008-03-26 22:47 UTC (permalink / raw)
To: linuxppc-dev
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/init_32.c | 10 +++++-----
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 59f6649..ada249b 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -227,5 +227,5 @@ adjust_total_lowmem(void)
__cam0 >> 20, __cam1 >> 20, __cam2 >> 20,
(total_lowmem - __cam0 - __cam1 - __cam2) >> 20);
__max_low_memory = __cam0 + __cam1 + __cam2;
- __initial_memory_limit = memstart_addr + __max_low_memory;
+ __initial_memory_limit_addr = memstart_addr + __max_low_memory;
}
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 345a275..555bb7e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -96,10 +96,10 @@ int __map_without_ltlbs;
unsigned long __max_low_memory = MAX_LOW_MEM;
/*
- * limit of what is accessible with initial MMU setup -
+ * address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit = 0x10000000;
+unsigned long __initial_memory_limit_addr = 0x10000000;
/*
* Check for command-line options that affect what MMU_init will do.
@@ -132,10 +132,10 @@ void __init MMU_init(void)
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
- __initial_memory_limit = 0x01000000;
+ __initial_memory_limit_addr = 0x01000000;
/* 8xx can only access 8MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 0x50)
- __initial_memory_limit = 0x00800000;
+ __initial_memory_limit_addr = 0x00800000;
/* parse args from command line */
MMU_setup();
@@ -210,7 +210,7 @@ void __init *early_get_page(void)
p = alloc_bootmem_pages(PAGE_SIZE);
} else {
p = __va(lmb_alloc_base(PAGE_SIZE, PAGE_SIZE,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
}
return p;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 67477e7..0480225 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -48,7 +48,7 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
-extern unsigned long __initial_memory_limit;
+extern phys_addr_t __initial_memory_limit_addr;
extern unsigned long total_memory;
extern unsigned long total_lowmem;
extern phys_addr_t memstart_addr;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 7dea68b..12b6a46 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -234,7 +234,7 @@ void __init MMU_init_hw(void)
*/
if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
Hash = __va(lmb_alloc_base(Hash_size, Hash_size,
- __initial_memory_limit));
+ __initial_memory_limit_addr));
cacheable_memzero(Hash, Hash_size);
_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
--
1.5.4.1
^ permalink raw reply related
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: David Gibson @ 2008-03-26 22:51 UTC (permalink / raw)
To: Grant Likely; +Cc: Anatolij Gustschin, Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40803261416s38164c98ua774731eadc1f85f@mail.gmail.com>
On Wed, Mar 26, 2008 at 03:16:47PM -0600, Grant Likely wrote:
> On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
> > Bartlomiej Sieka wrote:
> > > +
> > > + phy0:ethernet-phy@0 {
> > > + device_type = "ethernet-phy";@0"
> > > + reg = <0>;
> > > + };
> >
> > What's the parsing of this pan out to? What does it mean?
> >
> > Having colons in device names is totally contrary to OF device naming
> > spec. Does the part after the colon have a special meaning to the DTC?
>
> "phy0:" is a label used by dtc.
> "ethernet-phy@0" is the node name.
I would suggest a space after the colon though, to make this clearer.
That's the style I've been using in all my dts files.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32
From: Kumar Gala @ 2008-03-26 22:44 UTC (permalink / raw)
To: linuxppc-dev
Now that we have a proper variable that is the address of the top
of low memory we can use it to limit the lmb allocations.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
include/asm-powerpc/lmb.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index 028184b..6f5fdf0 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -6,8 +6,8 @@
#define LMB_DBG(fmt...) udbg_printf(fmt)
#ifdef CONFIG_PPC32
-extern unsigned long __max_low_memory;
-#define LMB_REAL_LIMIT __max_low_memory
+extern phys_addr_t lowmem_end_addr;
+#define LMB_REAL_LIMIT lowmem_end_addr
#else
#define LMB_REAL_LIMIT 0
#endif
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] scanlog_init cleanup, minor fixes
From: Michael Ellerman @ 2008-03-26 22:40 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080323225144.GA7137@localdomain>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Sun, 2008-03-23 at 17:51 -0500, Nathan Lynch wrote:
> scanlog_init() could use some love.
> diff --git a/arch/powerpc/platforms/pseries/scanlog.c b/arch/powerpc/platforms/pseries/scanlog.c
> index 8e1ef16..e5b0ea8 100644
> --- a/arch/powerpc/platforms/pseries/scanlog.c
> +++ b/arch/powerpc/platforms/pseries/scanlog.c
> @@ -195,31 +195,30 @@ const struct file_operations scanlog_fops = {
> static int __init scanlog_init(void)
> {
> struct proc_dir_entry *ent;
> + void *data;
> + int err = -ENOMEM;
>
> ibm_scan_log_dump = rtas_token("ibm,scan-log-dump");
> - if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE) {
> - printk(KERN_ERR "scan-log-dump not implemented on this system\n");
> - return -EIO;
> - }
> + if (ibm_scan_log_dump == RTAS_UNKNOWN_SERVICE)
> + return -ENODEV;
>
> - ent = create_proc_entry("ppc64/rtas/scan-log-dump", S_IRUSR, NULL);
> - if (ent) {
> - ent->proc_fops = &scanlog_fops;
> - /* Ideally we could allocate a buffer < 4G */
> - ent->data = kmalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> - if (!ent->data) {
> - printk(KERN_ERR "Failed to allocate a buffer\n");
> - remove_proc_entry("scan-log-dump", ent->parent);
> - return -ENOMEM;
> - }
> - ((unsigned int *)ent->data)[0] = 0;
> - } else {
> - printk(KERN_ERR "Failed to create ppc64/scan-log-dump proc entry\n");
> - return -EIO;
> - }
> + /* Ideally we could allocate a buffer < 4G */
> + data = kzalloc(RTAS_DATA_BUF_SIZE, GFP_KERNEL);
> + if (!data)
> + goto err;
Not your bug, but what happens if data is > 4G? Kaboom?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] allow arch specific function for allocating gigantic pages
From: Andi Kleen @ 2008-03-26 21:49 UTC (permalink / raw)
To: Jon Tollefson
Cc: npiggin, Adam Litke, linuxppc-dev, linux-kernel,
Linux Memory Management List, Andi Kleen, Paul Mackerras
In-Reply-To: <47EABF09.6090302@linux.vnet.ibm.com>
Haven't reviewed it in detail, just noticed something.
> @@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
> {
> if (HPAGE_SHIFT == 0)
> return 0;
> + INIT_LIST_HEAD(&huge_boot_pages);
> return hugetlb_init_hstate(&global_hstate);
I don't think adding the INIT_LIST_HEAD here is correct. There can
be huge pages added by the __setup handlers before hugetlb_init
-Andi
^ permalink raw reply
* Re: dtc: Trivial formatting fixes
From: David Gibson @ 2008-03-26 22:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JeVTb-0005tQ-Ae@jdl.com>
On Wed, Mar 26, 2008 at 08:15:35AM -0500, Jon Loeliger wrote:
> > This patch fixes some trivial indentation and brace/bracket style
> > problems.
>
>
> > @@ -179,9 +179,8 @@
> > arg = argv[optind];
> >
> > /* minsize and padsize are mutually exclusive */
> > - if ((minsize) && (padsize)) {
> > + if (minsize && padsize)
> > die("Can't set both -p and -S\n");
> > - }
>
>
> I do not consider extra braces a "problem", and will
> not be applying those changes. The other indentation
> fixes will be applied, of course.
Meh, whatever. Usual kernel style - which is what I originally
adopted for dtc - says no braces for one line blocks.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: ppc platform for AMCC-440EPx - ELDK to the rescue
From: Wolfgang Denk @ 2008-03-26 22:22 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080326130837.762DBDE2FB@ozlabs.org>
In message <20080326130837.762DBDE2FB@ozlabs.org> you wrote:
> I finally resolved my nightmare of getting linux-2.6.24/5... to work
> on my AMCC-440Epx - Sequoia spinoff board. Following a clue I derived
> from a reply from Wolfgang Denx, I went to the DENX Engineering site
> where I discoved and downloaded the ELDK for the ppc_4xxFP. the ELDK
> uses the ppc platform instead of the powerpc platform. FINALLY the
This is not exactly correct. Actually it supports both.
> Also, I fail to see what the DTS virtualization layer of the hardware
> buys us. When debugging, it's so much harder to use than the ppc
> platform's straight forward and standard methodologies. I can't
> understand to goal to eliminate the ppc platform, especially given
> the fact that DENX's ELDK is still using it with Linux 2.6.24.2 !!
You miss the fact that the ELDK has full support for arch/powerpc,
and that some board configurations in our kernel (for example, all
MPC5200 based ones) are available in arch/powerpc configurations
only.
But then - what's the difference? All it takes is a redefinition of
the ARCH envrionment variable in your shell...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I've got a bad feeling about this.
^ permalink raw reply
* Re: [PATCH 0/4] 16G huge page support for powerpc
From: Andi Kleen @ 2008-03-26 21:47 UTC (permalink / raw)
To: Jon Tollefson
Cc: npiggin, Adam Litke, linuxppc-dev, linux-kernel,
Linux Memory Management List, Andi Kleen, Paul Mackerras
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
FWIW i turned over the hugepages patchkit to Nick Piggin. So send
all future patches to him please.
-Andi
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Bartlomiej Sieka @ 2008-03-26 21:32 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <47EAB687.5040702@grandegger.com>
Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On Wed, Mar 26, 2008 at 1:45 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>>> The bulk of this patch is taken from
>>> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
>>> other updates.
>>>
>>> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
>>> ---
>>> Addressed comments from the list; would appreciate picking up as the patch
>>> fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous,
>>> but not tested due to hardware unavailability).
>> I see one obvious error; but other than that it looks good. Once that
>> is fixed I can recommend for Paul to pick it up for .25. It's just
>> dts changes, so I don't expect it to be a problem.
>>
>> Cheers,
[...]
> And whats about the two CAN nodes for tqm5200.dts? Do we have them already?
Hello Wolfgang,
patchwork shows your updates as "Awaiting Upstream"
(http://patchwork.ozlabs.org/linuxppc/patch?q=Grandegger&id=17444), so I
haven't included them in my patch. I suppose you should follow-up with
Grant/Paulus on the status?
Regards,
Bartlomiej
^ permalink raw reply
* [PATCH 4/4] powerpc: define page support for 16G pages
From: Jon Tollefson @ 2008-03-26 21:29 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The huge page size is setup for 16G pages if that size is specified at boot-time. The support for
multiple huge page sizes is not being utilized yet. That will be in a future patch.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 44d3d55..b6a02b7 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -26,6 +26,7 @@
#define HPAGE_SHIFT_64K 16
#define HPAGE_SHIFT_16M 24
+#define HPAGE_SHIFT_16G 34
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
@@ -589,9 +590,11 @@ void set_huge_psize(int psize)
{
/* Check that it is a page size supported by the hardware and
* that it fits within pagetable limits. */
- if (mmu_psize_defs[psize].shift && mmu_psize_defs[psize].shift < SID_SHIFT &&
+ if (mmu_psize_defs[psize].shift &&
+ mmu_psize_defs[psize].shift < SID_SHIFT_1T &&
(mmu_psize_defs[psize].shift > MIN_HUGEPTE_SHIFT ||
- mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K)) {
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_64K ||
+ mmu_psize_defs[psize].shift == HPAGE_SHIFT_16G)) {
HPAGE_SHIFT = mmu_psize_defs[psize].shift;
mmu_huge_psize = psize;
#ifdef CONFIG_PPC_64K_PAGES
@@ -599,6 +602,8 @@ void set_huge_psize(int psize)
#else
if (HPAGE_SHIFT == HPAGE_SHIFT_64K)
hugepte_shift = (PMD_SHIFT-HPAGE_SHIFT);
+ else if (HPAGE_SHIFT == HPAGE_SHIFT_16G)
+ hugepte_shift = (PGDIR_SHIFT-HPAGE_SHIFT);
else
hugepte_shift = (PUD_SHIFT-HPAGE_SHIFT);
#endif
@@ -625,6 +630,9 @@ static int __init hugepage_setup_sz(char *str)
case HPAGE_SHIFT_16M:
mmu_psize = MMU_PAGE_16M;
break;
+ case HPAGE_SHIFT_16G:
+ mmu_psize = MMU_PAGE_16G;
+ break;
}
if (mmu_psize >=0 && mmu_psize_defs[mmu_psize].shift)
^ permalink raw reply related
* [PATCH 3/4] powerpc: scan device tree and save gigantic page locations
From: Jon Tollefson @ 2008-03-26 21:27 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The 16G huge pages have to be reserved in the HMC prior to boot. The location of
the pages are placed in the device tree. During very early boot these locations are
saved for use by hugetlbfs.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 41 ++++++++++++++++++++++++++++++++++++++-
arch/powerpc/mm/hugetlbpage.c | 17 ++++++++++++++++
include/asm-powerpc/mmu-hash64.h | 2 +
3 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index a83dfa3..d3f7d92 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -67,6 +67,7 @@
#define KB (1024)
#define MB (1024*KB)
+#define GB (1024L*MB)
/*
* Note: pte --> Linux PTE
@@ -302,6 +303,41 @@ static int __init htab_dt_scan_page_sizes(unsigned long node,
return 0;
}
+/* Scan for 16G memory blocks that have been set aside for huge pages
+ * and reserve those blocks for 16G huge pages.
+ */
+static int __init htab_dt_scan_hugepage_blocks(unsigned long node,
+ const char *uname, int depth,
+ void *data) {
+ char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ unsigned long *lprop;
+ u32 *prop;
+
+ /* We are scanning "memory" nodes only */
+ if (type == NULL || strcmp(type, "memory") != 0)
+ return 0;
+
+ /* This property is the log base 2 of the number of virtual pages that
+ * will represent this memory block. */
+ prop = of_get_flat_dt_prop(node, "ibm,expected#pages", NULL);
+ if (prop == NULL)
+ return 0;
+ unsigned int expected_pages = (1 << prop[0]);
+ lprop = of_get_flat_dt_prop(node, "reg", NULL);
+ if (lprop == NULL)
+ return 0;
+ long unsigned int phys_addr = lprop[0];
+ long unsigned int block_size = lprop[1];
+ if (block_size != (16 * GB))
+ return 0;
+ printk(KERN_INFO "Reserving huge page memory "
+ "addr = 0x%lX size = 0x%lX pages = %d\n",
+ phys_addr, block_size, expected_pages);
+ lmb_reserve(phys_addr, block_size * expected_pages);
+ add_gpage(phys_addr, block_size, expected_pages);
+ return 0;
+}
+
static void __init htab_init_page_sizes(void)
{
int rc;
@@ -370,7 +406,10 @@ static void __init htab_init_page_sizes(void)
mmu_psize_defs[mmu_io_psize].shift);
#ifdef CONFIG_HUGETLB_PAGE
- /* Init large page size. Currently, we pick 16M or 1M depending
+ /* Reserve 16G huge page memory sections for huge pages */
+ of_scan_flat_dt(htab_dt_scan_hugepage_blocks, NULL);
+
+/* Init large page size. Currently, we pick 16M or 1M depending
* on what is available
*/
if (mmu_psize_defs[MMU_PAGE_16M].shift)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 31d977b..44d3d55 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -108,6 +108,23 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
}
#endif
+/* Build list of addresses of gigantic pages. This function is used in early
+ * boot before the buddy allocator is setup.
+ */
+void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages)
+{
+ if (addr) {
+ while (number_of_pages > 0) {
+ gpage_freearray[nr_gpages] = __va(addr);
+ nr_gpages++;
+ number_of_pages--;
+ addr += page_size;
+ }
+ }
+}
+
+
/* Put 16G page address into temporary huge page list because the mem_map
* is not up yet.
*/
diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
index 2864fa3..db1276a 100644
--- a/include/asm-powerpc/mmu-hash64.h
+++ b/include/asm-powerpc/mmu-hash64.h
@@ -279,6 +279,8 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
unsigned long pstart, unsigned long mode,
int psize, int ssize);
extern void set_huge_psize(int psize);
+extern void add_gpage(unsigned long addr, unsigned long page_size,
+ unsigned long number_of_pages);
extern void demote_segment_4k(struct mm_struct *mm, unsigned long addr);
extern void htab_initialize(void);
^ permalink raw reply related
* [PATCH 2/4] powerpc: function for allocating gigantic pages
From: Jon Tollefson @ 2008-03-26 21:26 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
The 16G page locations have been saved during early boot in an array. The
alloc_bm_huge_page() function adds a page from here to the huge_boot_pages list.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
hugetlbpage.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 94625db..31d977b 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -29,6 +29,10 @@
#define NUM_LOW_AREAS (0x100000000UL >> SID_SHIFT)
#define NUM_HIGH_AREAS (PGTABLE_RANGE >> HTLB_AREA_SHIFT)
+#define MAX_NUMBER_GPAGES 1024
+
+static void *gpage_freearray[MAX_NUMBER_GPAGES];
+static unsigned nr_gpages;
unsigned int hugepte_shift;
#define PTRS_PER_HUGEPTE (1 << hugepte_shift)
@@ -104,6 +108,21 @@ pmd_t *hpmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr)
}
#endif
+/* Put 16G page address into temporary huge page list because the mem_map
+ * is not up yet.
+ */
+int alloc_bm_huge_page(struct hstate *h)
+{
+ struct huge_bm_page *m;
+ if (nr_gpages == 0)
+ return 0;
+ m = gpage_freearray[--nr_gpages];
+ list_add(&m->list, &huge_boot_pages);
+ m->hstate = h;
+ return 1;
+}
+
+
/* Modelled after find_linux_pte() */
pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
{
^ permalink raw reply related
* [PATCH 1/4] allow arch specific function for allocating gigantic pages
From: Jon Tollefson @ 2008-03-26 21:24 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Paul Mackerras, Andi Kleen, Adam Litke
In-Reply-To: <47EABE2D.7080400@linux.vnet.ibm.com>
Allow alloc_bm_huge_page() to be overridden by architectures that can't always use bootmem.
This requires huge_boot_pages to be available for use by this function. Also huge_page_size()
and other functions need to use a long so that they can handle the 16G page size.
Signed-off-by: Jon Tollefson <kniht@linux.vnet.ibm.com>
---
include/linux/hugetlb.h | 10 +++++++++-
mm/hugetlb.c | 21 +++++++++------------
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index a8de3c1..35a41be 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -35,6 +35,7 @@ void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed);
extern unsigned long hugepages_treat_as_movable;
extern const unsigned long hugetlb_zero, hugetlb_infinity;
extern int sysctl_hugetlb_shm_group;
+extern struct list_head huge_boot_pages;
/* arch callbacks */
@@ -219,9 +220,15 @@ struct hstate {
unsigned int surplus_huge_pages_node[MAX_NUMNODES];
unsigned long parsed_hugepages;
};
+struct huge_bm_page {
+ struct list_head list;
+ struct hstate *hstate;
+};
void __init huge_add_hstate(unsigned order);
struct hstate *huge_lookup_hstate(unsigned long pagesize);
+/* arch callback */
+int alloc_bm_huge_page(struct hstate *h);
#ifndef HUGE_MAX_HSTATE
#define HUGE_MAX_HSTATE 1
@@ -248,7 +255,7 @@ static inline struct hstate *hstate_inode(struct inode *i)
return HUGETLBFS_I(i)->hstate;
}
-static inline unsigned huge_page_size(struct hstate *h)
+static inline unsigned long huge_page_size(struct hstate *h)
{
return PAGE_SIZE << h->order;
}
@@ -273,6 +280,7 @@ extern unsigned long sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
#else
struct hstate {};
+#define alloc_bm_huge_page(h) NULL
#define hstate_file(f) NULL
#define hstate_vma(v) NULL
#define hstate_inode(i) NULL
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c28b8b6..a0017b0 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -27,6 +27,7 @@ unsigned long max_huge_pages[HUGE_MAX_HSTATE];
unsigned long sysctl_overcommit_huge_pages[HUGE_MAX_HSTATE];
static gfp_t htlb_alloc_mask = GFP_HIGHUSER;
unsigned long hugepages_treat_as_movable;
+struct list_head huge_boot_pages;
static int max_hstate = 1;
@@ -43,7 +44,8 @@ struct hstate *parsed_hstate __initdata = &global_hstate;
*/
static DEFINE_SPINLOCK(hugetlb_lock);
-static void clear_huge_page(struct page *page, unsigned long addr, unsigned sz)
+static void clear_huge_page(struct page *page, unsigned long addr,
+ unsigned long sz)
{
int i;
@@ -521,14 +523,8 @@ static __init char *memfmt(char *buf, unsigned long n)
return buf;
}
-static __initdata LIST_HEAD(huge_boot_pages);
-
-struct huge_bm_page {
- struct list_head list;
- struct hstate *hstate;
-};
-
-static int __init alloc_bm_huge_page(struct hstate *h)
+/* Can be overriden by architectures */
+__attribute__((weak)) int alloc_bm_huge_page(struct hstate *h)
{
struct huge_bm_page *m;
m = __alloc_bootmem_node_nopanic(NODE_DATA(h->hugetlb_next_nid),
@@ -614,6 +610,7 @@ static int __init hugetlb_init(void)
{
if (HPAGE_SHIFT == 0)
return 0;
+ INIT_LIST_HEAD(&huge_boot_pages);
return hugetlb_init_hstate(&global_hstate);
}
module_init(hugetlb_init);
@@ -866,7 +863,7 @@ int hugetlb_report_meminfo(char *buf)
n += dump_field(buf + n, offsetof(struct hstate, surplus_huge_pages));
n += sprintf(buf + n, "Hugepagesize: ");
for_each_hstate (h)
- n += sprintf(buf + n, " %5u", huge_page_size(h) / 1024);
+ n += sprintf(buf + n, " %5lu", huge_page_size(h) / 1024);
n += sprintf(buf + n, " kB\n");
return n;
}
@@ -947,7 +944,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
unsigned long addr;
int cow;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
cow = (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
@@ -992,7 +989,7 @@ void __unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start,
struct page *page;
struct page *tmp;
struct hstate *h = hstate_vma(vma);
- unsigned sz = huge_page_size(h);
+ unsigned long sz = huge_page_size(h);
/*
* A page gathering list, protected by per file i_mmap_lock. The
^ permalink raw reply related
* [PATCH 0/4] 16G huge page support for powerpc
From: Jon Tollefson @ 2008-03-26 21:20 UTC (permalink / raw)
To: linux-kernel, Linux Memory Management List, linuxppc-dev
Cc: Adam Litke, Andi Kleen, Paul Mackerras
This patch set builds on Andi Kleen's patches for GB pages for hugetlb
posted on March 16th. This set adds support for 16G huge pages on
ppc64. Supporting multiple huge page sizes on ppc64 as defined in
Andi's patches is not a part of this set; that will be included in a
future patch.
The first patch here adds an arch callback since the 16G pages are not
allocated from bootmem. The 16G pages have to be reserved prior to
boot-time. The location of these pages are indicated in the device tree.
Support for 16G pages requires a POWER5+ or later machine and a little
bit of memory.
Jon
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Grant Likely @ 2008-03-26 21:16 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Paul Mackerras, Anatolij Gustschin
In-Reply-To: <47EAB9CC.7060002@genesi-usa.com>
On Wed, Mar 26, 2008 at 3:02 PM, Matt Sealey <matt@genesi-usa.com> wrote:
> Bartlomiej Sieka wrote:
> > +
> > + phy0:ethernet-phy@0 {
> > + device_type = "ethernet-phy";@0"
> > + reg = <0>;
> > + };
>
> What's the parsing of this pan out to? What does it mean?
>
> Having colons in device names is totally contrary to OF device naming
> spec. Does the part after the colon have a special meaning to the DTC?
"phy0:" is a label used by dtc.
"ethernet-phy@0" is the node name.
>
> I also was under the impression that device_type was invalid in a DTS
> file, have we changed our minds again?
No, we haven't. It kind of sneaked back in for ethernet phys. I
don't know why.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [RESEND2][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Bartlomiej Sieka @ 2008-03-26 21:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <fa686aa40803261335q2b8af09cw6f05dc0cf905d0b5@mail.gmail.com>
The bulk of this patch is taken from
http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
other updates.
Signed-off-by: Marian Balakowicz <m8@semihalf.com>
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..2d25ca8 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -231,4 +248,22 @@
reg = <8000 4000>;
};
};
+
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 2000000>;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..d86eba0 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = <&mpc5200_pic>;
};
-
spi@f00 {
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <f00 20>;
@@ -209,10 +208,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@2 {
+ device_type = "ethernet-phy";
+ reg = <2>;
+ };
};
ata@3a00 {
@@ -223,11 +237,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -240,7 +262,8 @@
compatible = "fsl,lpb";
#address-cells = <2>;
#size-cells = <1>;
- ranges = <1 0 50000000 00010000
+ ranges = <0 0 ff000000 01000000
+ 1 0 50000000 00010000
2 0 50010000 00010000
3 0 50020000 00010000>;
@@ -271,31 +294,15 @@
compatible = "promess,pro_module_dio";
reg = <3 800 2>;
};
- };
- pci@f0000d00 {
- #interrupt-cells = <1>;
- #size-cells = <2>;
- #address-cells = <3>;
- device_type = "pci";
- compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
- reg = <f0000d00 100>;
- interrupt-map-mask = <f800 0 0 7>;
- interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
- c000 0 0 2 &mpc5200_pic 1 1 3
- c000 0 0 3 &mpc5200_pic 1 2 3
- c000 0 0 4 &mpc5200_pic 1 3 3
-
- c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
- c800 0 0 2 &mpc5200_pic 1 2 3
- c800 0 0 3 &mpc5200_pic 1 3 3
- c800 0 0 4 &mpc5200_pic 0 0 3>;
- clock-frequency = <0>; // From boot loader
- interrupts = <2 8 0 2 9 0 2 a 0>;
- interrupt-parent = <&mpc5200_pic>;
- bus-range = <0 0>;
- ranges = <42000000 0 80000000 80000000 0 20000000
- 02000000 0 a0000000 a0000000 0 10000000
- 01000000 0 00000000 b0000000 0 01000000>;
+ // 16-bit flash device at LocalPlus Bus CS0
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 01000000>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
index c86464f..d2dc278 100644
--- a/arch/powerpc/boot/dts/tqm5200.dts
+++ b/arch/powerpc/boot/dts/tqm5200.dts
@@ -127,10 +127,25 @@
ethernet@3000 {
device_type = "network";
compatible = "fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0:ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
ata@3a00 {
@@ -141,11 +156,19 @@
};
i2c@3d40 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
+
+ rtc@68 {
+ device_type = "rtc";
+ compatible = "dallas,ds1307";
+ reg = <68>;
+ };
};
sram@8000 {
@@ -154,6 +177,23 @@
};
};
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc000000 02000000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 02000000>;
+ bank-width = <4>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
+
pci@f0000d00 {
#interrupt-cells = <1>;
#size-cells = <2>;
^ permalink raw reply related
* Re: [PATCH 4/5] i2c: MPC837xRDB Power Management and GPIO expander driver
From: Timur Tabi @ 2008-03-26 20:56 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080326202511.GD1772@localhost.localdomain>
Anton Vorontsov wrote:
> +config MCU_MPC837XRDB
> + tristate "MPC837XRDB MCU driver"
> + depends on I2C && MPC837x_RDB && OF_GPIO
The MPC8349E-mITX also has this chip. Can you include support for that board as
well?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
From: Matt Sealey @ 2008-03-26 21:04 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <fa686aa40803261357m4a8e8703u7f3b8e39199e1de7@mail.gmail.com>
Can someone throw me a link to the GPIO spec being implemented here (yes,
I would like docs too!) or a pointer to the relevant DTS which implements
it?
Supporting GPIO in the device tree is something that has been undefined
for ages, and I seem to not be able to find the supporting DTS patches for
this implementation in patchwork..??
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov
> <avorontsov@ru.mvista.com> wrote:
>> Despite leds-gpio and leds-of-gpio similar names and purposes, there
>> is actually very few code can be shared between the two (both drivers
>> are mostly the driver bindings anyway).
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>
> Other than the fact that it needs some documentation of the binding in
> booting-without-of.txt, it looks pretty good to me.
>
> g.
>
>
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Matt Sealey @ 2008-03-26 21:02 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <20080326194526.GA17424@frozen.semihalf.com>
Bartlomiej Sieka wrote:
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
What's the parsing of this pan out to? What does it mean?
Having colons in device names is totally contrary to OF device naming
spec. Does the part after the colon have a special meaning to the DTC?
I also was under the impression that device_type was invalid in a DTS
file, have we changed our minds again?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Josh Boyer @ 2008-03-26 20:57 UTC (permalink / raw)
To: Roland McGrath
Cc: Arnd Bergmann, Jan, linuxppc-dev, Paul Mackerras, Kratochvil
In-Reply-To: <20080313014745.DE97826F992@magilla.localdomain>
On Wed, 12 Mar 2008 18:47:45 -0700 (PDT)
Roland McGrath <roland@redhat.com> wrote:
> The only machine I have at home for testing powerpc is an Apple G5,
> supplied to me by IBM. It says:
> cpu : PPC970FX, altivec supported
> revision : 3.0 (pvr 003c 0300)
> so I am guessing this document applies to the chips I have. Since I can't
> test on other chips myself, it is plausible from what I've seen that there
> is no mysterious kernel problem and only this hardware problem. The
> description of the hardware problem would not make me think that it would
> behave this way, but it is not very detailed or precise, or at least does
> not seem so to a reader not expert on powerpc.
I ran the testcase on my older G5 today with:
cpu : PPC970, altivec supported
revision : 2.2 (pvr 0039 0202)
and it also failed after a few iterations. This was with
2.6.25-0.121.rc5.git4.fc9 as the kernel, which is fairly close to mainline. At the least, this doesn't seem to be 970FX related. I'll try building a vanilla 2.6.25-rc7 later this evening to see if that makes a difference.
josh
^ permalink raw reply
* Re: [PATCH 3/5] leds: implement OpenFirmare GPIO LEDs driver
From: Grant Likely @ 2008-03-26 20:57 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Richard Purdie
In-Reply-To: <20080326202453.GC1772@localhost.localdomain>
On Wed, Mar 26, 2008 at 2:24 PM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> Despite leds-gpio and leds-of-gpio similar names and purposes, there
> is actually very few code can be shared between the two (both drivers
> are mostly the driver bindings anyway).
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Other than the fact that it needs some documentation of the binding in
booting-without-of.txt, it looks pretty good to me.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RESEND][POWERPC] mpc5200: Amalgamated dts fixes and updates
From: Wolfgang Grandegger @ 2008-03-26 20:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras, Anatolij Gustschin
In-Reply-To: <fa686aa40803261335q2b8af09cw6f05dc0cf905d0b5@mail.gmail.com>
Grant Likely wrote:
> On Wed, Mar 26, 2008 at 1:45 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>> The bulk of this patch is taken from
>> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
>> other updates.
>>
>> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
>> ---
>> Addressed comments from the list; would appreciate picking up as the patch
>> fixes booting issue on TQM5200 and Motion-PRO (cm5200 changes are analogous,
>> but not tested due to hardware unavailability).
>
> I see one obvious error; but other than that it looks good. Once that
> is fixed I can recommend for Paul to pick it up for .25. It's just
> dts changes, so I don't expect it to be a problem.
>
> Cheers,
> g.
>
>> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
>> index 76951ab..f27256b 100644
>> --- a/arch/powerpc/boot/dts/motionpro.dts
>> +++ b/arch/powerpc/boot/dts/motionpro.dts
>> @@ -209,10 +208,25 @@
>> + mdio@3000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
>> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
>> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
>> + interrupt-parent = <&mpc5200_pic>;
>> +
>> + phy0:ethernet-phy@0 {
>> + device_type = "ethernet-phy";
>> + reg = <2>;
>
> This doesn't look right. Reg should match the value in "ethernet-phy@0"
And whats about the two CAN nodes for tqm5200.dts? Do we have them already?
Thanks,
Wolfgang.
^ 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