* test - please ignore
From: Victor Gallardo @ 2008-07-30 22:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080729200225.57634f94@zod.rchland.ibm.com>
test - please ignore
--------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains =
information that is confidential and proprietary to Applied Micro =
Circuits Corporation or its subsidiaries. It is to be used solely for =
the purpose of furthering the parties' business relationship. All =
unauthorized review, use, disclosure or distribution is prohibited. If =
you are not the intended recipient, please contact the sender by reply =
e-mail and destroy all copies of the original message.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Kumar Gala @ 2008-07-30 22:35 UTC (permalink / raw)
To: benh; +Cc: Nick Piggin, linuxppc-dev list
In-Reply-To: <1217456772.11188.342.camel@pasglop>
On Jul 30, 2008, at 5:26 PM, Benjamin Herrenschmidt wrote:
>
>>> Index: linux-work/arch/powerpc/Kconfig
>>> ===================================================================
>>> --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30
>>> 13:17:06.000000000 +1000
>>> +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000
>>> +1000
>>> @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
>>> bool
>>> default y
>>>
>>> +config HAVE_GET_USER_PAGES_FAST
>>> + def_bool PPC64
>>> +
>>> config HAVE_SETUP_PER_CPU_AREA
>>> def_bool PPC64
>>
>> what's ppc64 specific here?
>
> Mostly _PAGE_SPECIAL (which I do plan to add to embedded which is why
> I've been trying hard to free a PTE bit :-) and the way we synchronize
> with the freeing of page tables (ppc64 uses RCU, ppc32 doesn't, we'd
> have to find something to keep fast gup in sync).
I think we have some code that uses RCU for page freeing. I'll dig it
up and posted it.
- k
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Lockless get_user_pages_fast()
From: Benjamin Herrenschmidt @ 2008-07-30 22:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Nick Piggin, linuxppc-dev list
In-Reply-To: <C8EC8414-A033-46FE-AFEC-8C2A6AB5B4F7@kernel.crashing.org>
> > Index: linux-work/arch/powerpc/Kconfig
> > ===================================================================
> > --- linux-work.orig/arch/powerpc/Kconfig 2008-07-30
> > 13:17:06.000000000 +1000
> > +++ linux-work/arch/powerpc/Kconfig 2008-07-30 13:27:40.000000000
> > +1000
> > @@ -42,6 +42,9 @@ config GENERIC_HARDIRQS
> > bool
> > default y
> >
> > +config HAVE_GET_USER_PAGES_FAST
> > + def_bool PPC64
> > +
> > config HAVE_SETUP_PER_CPU_AREA
> > def_bool PPC64
>
> what's ppc64 specific here?
Mostly _PAGE_SPECIAL (which I do plan to add to embedded which is why
I've been trying hard to free a PTE bit :-) and the way we synchronize
with the freeing of page tables (ppc64 uses RCU, ppc32 doesn't, we'd
have to find something to keep fast gup in sync).
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/ibmveth: fix multiple errors with dma_mapping_error conversion
From: Jeff Garzik @ 2008-07-30 21:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, FUJITA Tomonori, ppc-dev, Paul Mackerras, Andrew Morton
In-Reply-To: <20080728021424.40cf66bc.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> The addition of an argument to dma_mapping_error() in commit
> 8d8bb39b9eba32dd70e87fd5ad5c5dd4ba118e06 "dma-mapping: add the device
> argument to dma_mapping_error()" left a bit of fallout:
>
> drivers/net/ibmveth.c:263: error: too few arguments to function 'dma_mapping_error'
> drivers/net/ibmveth.c:264: error: expected ')' before 'goto'
> drivers/net/ibmveth.c:284: error: expected expression before '}' token
> drivers/net/ibmveth.c:297: error: too few arguments to function 'dma_mapping_error'
> drivers/net/ibmveth.c:298: error: expected ')' before 'dma_unmap_single'
> drivers/net/ibmveth.c:306: error: expected expression before '}' token
> drivers/net/ibmveth.c:491: error: too few arguments to function 'dma_mapping_error'
> drivers/net/ibmveth.c:927: error: too few arguments to function 'dma_mapping_error'
> drivers/net/ibmveth.c:927: error: expected ')' before '{' token
> drivers/net/ibmveth.c:974: error: expected expression before '}' token
> drivers/net/ibmveth.c:914: error: label 'out' used but not defined m
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/ibmveth.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> Compiler tested for ppc64_defconfig.
applied
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jon Smirl @ 2008-07-30 20:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <20080730144202.GB21958@secretlab.ca>
On 7/30/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote:
> >>> A reasonable "compatible" value would be something like
> >>> "serial-eeprom-24c32".
> >>> You can go a little bit more generic than that, if you write up in
> >>> your binding how the driver should figure out the device size and
> >>> the protocol used.
> >>
> >> Matching on "serial-eeprom-24c32" requires me to convince the at24
> >> authors to add that string as an alias binding for their driver.
> >
> > No, it requires the IIC subsystem to get fixed and not use OF
> > "compatible" values as module alias names.
>
>
> Indeed; the device tree is just a data structure with a well defined
> usage model. It is the kernel's job to adapt that data into a form that
> it can use.
Then we're going to have to work on the i2s subsystem more to get them
to allow arbitrary modalias strings like serial-eeprom-24c32.
The current i2c code has linked the use of modalias strings and the
i2c sysfs attribute 'name'. Currently those two always need to be the
same. Existing user space apps are expecting to get the linux name for
the device from the name field. That linkage needs to be broken.
Then you need entries like this:
static const struct i2c_device_id at24_ids[] = {
{ "24c01", "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
{ "24c02", "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
OF( "serial-eeprom-24c01", "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) ),
OF( "serial-eeprom-24c02", "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) ),
First column is the modalias, second is the string that is going into
the 'name' attribute. OF() causes the entries to disappear on non-OF
platforms.
We should argue for another macro that makes the non-OF strings
disappear on our platform.
I have submitted a patch like this before and Jean declared that he
doesn't recognize open firmware as a naming authority and NACK'd it.
>
>
> >> How
> >> about "serial-eeprom,24c32" or "generic,24x32"?
> >
> > Neither "serial-eeprom" nor "generic" is the name of a vendor, so
> > no. The comma has a well-defined meaning. Why would a comma be
> > easier than a dash for your device matching code, anyway?
>
>
> Just to add my voice; I 100% agree. If it is not documented, and it
> doesn't fit with established conventions, then it shouldn't be used in
> the compatible field.
>
>
> g.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Andrew Morton @ 2008-07-30 20:07 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson
In-Reply-To: <20080730193010.GB14138@csn.ul.ie>
On Wed, 30 Jul 2008 20:30:10 +0100
Mel Gorman <mel@csn.ul.ie> wrote:
> With Erics patch and libhugetlbfs, we can automatically back text/data[1],
> malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
> will also be able to override shmget() to add SHM_HUGETLB. That should cover
> a lot of the memory-intensive apps without source modification.
The weak link in all of this still might be the need to reserve
hugepages and the unreliability of dynamically allocating them.
The dynamic allocation should be better nowadays, but I've lost track
of how reliable it really is. What's our status there?
Thanks.
^ permalink raw reply
* Re: ide pmac breakage
From: Bartlomiej Zolnierkiewicz @ 2008-07-30 19:11 UTC (permalink / raw)
To: benh; +Cc: FUJITA Tomonori, linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <1217401052.11188.318.camel@pasglop>
On Wednesday 30 July 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-29 at 21:26 +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > I WON!!!
>
> Only half...
Heh, I wasn't talking about fixing the issue...
(hint: look up the author of the bad commit).
> It goes further and then blows up again. First problem is, this
> unregister interface doesn't quite convey the fact that the HW is gone
> and the IDE code seems to take it's sweet time figuring it out after
> trying some requests. Maybe something smarter can be done here ? ie,
> ide_set_interface_dead() :-)
Sure, it would be great to have controller hotplug working reliably
one day but the recent patches shouldn't really be making things worse
(quite the contrary) so I would prefer to find and learn more about
the cause of regression first.
[ However nothing prevents us from improving the hotplug support in
parallel to fixing the issue so if you have some ideas that could
be conveyed in form of patches please go ahead. ]
> mediabay0: switching to 7
> mediabay0: powering down
> media bay 0 is empty
> hdc: status error: status=0x00 { }
> ide: failed opcode was: unknown
> hdc: status error: status=0x00 { }
> ide: failed opcode was: unknown
>
> Then after this couple of failed attempts at sending commands, it
> crashes with the backtrace below. Another NULL dereference apparently,
> though the DAR value (the faulting address) has been slightly different
> between consecutive tests so it may be a use-after-free too.
Is it actually caused by additional reference counting on drive->gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?
> Note that there shouldn't be anything fundamentally different from
> ide-pmac here vs. something like pcmcia IDE cards... do you have one of
> these to test with ?
Nope and I really don't intend to have one. I count on other people
to take some care of support for host drivers that they maintain/use. ;)
Thanks,
Bart
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 4e73aee..8f253e5 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -57,23 +57,29 @@ static DEFINE_MUTEX(idecd_ref_mutex);
#define ide_cd_g(disk) \
container_of((disk)->private_data, struct cdrom_info, driver)
+static void ide_cd_release(struct kref *);
+
static struct cdrom_info *ide_cd_get(struct gendisk *disk)
{
struct cdrom_info *cd = NULL;
mutex_lock(&idecd_ref_mutex);
cd = ide_cd_g(disk);
- if (cd)
+ if (cd) {
kref_get(&cd->kref);
+ if (ide_device_get(cd->drive)) {
+ kref_put(&cd->kref, ide_cd_release);
+ cd = NULL;
+ }
+ }
mutex_unlock(&idecd_ref_mutex);
return cd;
}
-static void ide_cd_release(struct kref *);
-
static void ide_cd_put(struct cdrom_info *cd)
{
mutex_lock(&idecd_ref_mutex);
+ ide_device_put(cd->drive);
kref_put(&cd->kref, ide_cd_release);
mutex_unlock(&idecd_ref_mutex);
}
^ permalink raw reply related
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Christoph Lameter @ 2008-07-30 19:40 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev,
Andrew Hastings, Eric Munson, Andrew Morton
In-Reply-To: <20080730193010.GB14138@csn.ul.ie>
Mel Gorman wrote:
> With Erics patch and libhugetlbfs, we can automatically back text/data[1],
> malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
> will also be able to override shmget() to add SHM_HUGETLB. That should cover
> a lot of the memory-intensive apps without source modification.
So we are quite far down the road to having a VM that supports 2 page sizes 4k and 2M?
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-07-30 19:30 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev,
Andrew Hastings, Eric Munson
In-Reply-To: <20080730103407.b110afc2.akpm@linux-foundation.org>
On (30/07/08 10:34), Andrew Morton didst pronounce:
> On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman <mel@csn.ul.ie> wrote:
>
> > On (30/07/08 01:43), Andrew Morton didst pronounce:
> > > On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
> > >
> > > > Certain workloads benefit if their data or text segments are backed by
> > > > huge pages.
> > >
> > > oh. As this is a performance patch, it would be much better if its
> > > description contained some performance measurement results! Please.
> > >
> >
> > I ran these patches through STREAM (http://www.cs.virginia.edu/stream/).
> > STREAM itself was patched to allocate data from the stack instead of statically
> > for the test. They completed without any problem on x86, x86_64 and PPC64
> > and each test showed a performance gain from using hugepages. I can post
> > the raw figures but they are not currently in an eye-friendly format. Here
> > are some plots of the data though;
> >
> > x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps
> > x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps
> > ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps
> > ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps
> >
> > The test was to run STREAM with different array sizes (plotted on X-axis)
> > and measure the average throughput (y-axis). In each case, backing the stack
> > with large pages with a performance gain.
>
> So about a 10% speedup on x86 for most STREAM configurations. Handy -
> that's somewhat larger than most hugepage-conversions, iirc.
>
It is a bit. Usually, I expect around 5%.
> Do we expect that this change will be replicated in other
> memory-intensive apps? (I do).
>
I expect so. I know SpecCPU has some benchmarks that are stack-dependent and
would benefit from this patchset. I haven't experimented enough yet with other
workloads to give a decent estimate. I've added Andrew Hastings to the cc as
I believe he can make a good estimate on what sort of gains had by backing
the stack with huge pages based on experiments along those lines. Andrew?
With Erics patch and libhugetlbfs, we can automatically back text/data[1],
malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
will also be able to override shmget() to add SHM_HUGETLB. That should cover
a lot of the memory-intensive apps without source modification.
[1] It can partially remap non-hugepage-aligned segments but ideally the
application would be relinked
[2] Allocated via the morecore hook in glibc
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [patch 1/2] ppc: use the common ascii hex helpers
From: akpm @ 2008-07-30 19:29 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, harvey.harrison
From: Harvey Harrison <harvey.harrison@gmail.com>
[akpm@linux-foundation.org: exclude prom_init.c]
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/kernel/btext.c | 34 ++++++++++++++++------------------
powerpc/kernel/prom_init.c | 0
2 files changed, 16 insertions(+), 18 deletions(-)
diff -puN arch/powerpc/kernel/btext.c~ppc-use-the-common-ascii-hex-helpers arch/powerpc/kernel/btext.c
--- a/arch/powerpc/kernel/btext.c~ppc-use-the-common-ascii-hex-helpers
+++ a/arch/powerpc/kernel/btext.c
@@ -442,28 +442,26 @@ void btext_drawtext(const char *c, unsig
void btext_drawhex(unsigned long v)
{
- char *hex_table = "0123456789abcdef";
-
if (!boot_text_mapped)
return;
#ifdef CONFIG_PPC64
- btext_drawchar(hex_table[(v >> 60) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 56) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 52) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 48) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 44) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 40) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 36) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 32) & 0x0000000FUL]);
+ btext_drawchar(hex_asc_hi(v >> 56));
+ btext_drawchar(hex_asc_lo(v >> 56));
+ btext_drawchar(hex_asc_hi(v >> 48));
+ btext_drawchar(hex_asc_lo(v >> 48));
+ btext_drawchar(hex_asc_hi(v >> 40));
+ btext_drawchar(hex_asc_lo(v >> 40));
+ btext_drawchar(hex_asc_hi(v >> 32));
+ btext_drawchar(hex_asc_lo(v >> 32));
#endif
- btext_drawchar(hex_table[(v >> 28) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 24) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 20) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 16) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 12) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 8) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 4) & 0x0000000FUL]);
- btext_drawchar(hex_table[(v >> 0) & 0x0000000FUL]);
+ btext_drawchar(hex_asc_hi(v >> 24));
+ btext_drawchar(hex_asc_lo(v >> 24));
+ btext_drawchar(hex_asc_hi(v >> 16));
+ btext_drawchar(hex_asc_lo(v >> 16));
+ btext_drawchar(hex_asc_hi(v >> 8));
+ btext_drawchar(hex_asc_lo(v >> 8));
+ btext_drawchar(hex_asc_hi(v));
+ btext_drawchar(hex_asc_lo(v));
btext_drawchar(' ');
}
diff -puN arch/powerpc/kernel/prom_init.c~ppc-use-the-common-ascii-hex-helpers arch/powerpc/kernel/prom_init.c
_
^ permalink raw reply
* [patch 2/2] powerpc: replace __FUNCTION__ with __func__
From: akpm @ 2008-07-30 19:29 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, harvey.harrison
From: Harvey Harrison <harvey.harrison@gmail.com>
__FUNCTION__ is gcc-specific, use __func__
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/kernel/lparcfg.c | 8 ++++----
arch/powerpc/platforms/pseries/cmm.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff -puN arch/powerpc/kernel/lparcfg.c~powerpc-replace-__function__-with-__func__ arch/powerpc/kernel/lparcfg.c
--- a/arch/powerpc/kernel/lparcfg.c~powerpc-replace-__function__-with-__func__
+++ a/arch/powerpc/kernel/lparcfg.c
@@ -505,10 +505,10 @@ static ssize_t update_ppp(u64 *entitleme
return -EINVAL;
pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
- __FUNCTION__, ppp_data.entitlement, ppp_data.weight);
+ __func__, ppp_data.entitlement, ppp_data.weight);
pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
- __FUNCTION__, new_entitled, new_weight);
+ __func__, new_entitled, new_weight);
retval = plpar_hcall_norets(H_SET_PPP, new_entitled, new_weight);
return retval;
@@ -551,10 +551,10 @@ static ssize_t update_mpp(u64 *entitleme
return -EINVAL;
pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
- __FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+ __func__, mpp_data.entitled_mem, mpp_data.mem_weight);
pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
- __FUNCTION__, new_entitled, new_weight);
+ __func__, new_entitled, new_weight);
rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
return rc;
diff -puN arch/powerpc/platforms/pseries/cmm.c~powerpc-replace-__function__-with-__func__ arch/powerpc/platforms/pseries/cmm.c
--- a/arch/powerpc/platforms/pseries/cmm.c~powerpc-replace-__function__-with-__func__
+++ a/arch/powerpc/platforms/pseries/cmm.c
@@ -121,7 +121,7 @@ static long cmm_alloc_pages(long nr)
npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO | __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!npa) {
- pr_info("%s: Can not allocate new page list\n", __FUNCTION__);
+ pr_info("%s: Can not allocate new page list\n", __func__);
free_page(addr);
break;
}
@@ -138,7 +138,7 @@ static long cmm_alloc_pages(long nr)
}
if ((rc = plpar_page_set_loaned(__pa(addr)))) {
- pr_err("%s: Can not set page to loaned. rc=%ld\n", __FUNCTION__, rc);
+ pr_err("%s: Can not set page to loaned. rc=%ld\n", __func__, rc);
spin_unlock(&cmm_lock);
free_page(addr);
break;
_
^ permalink raw reply
* Re: Writing to CPLD mapped to EBC Port of AMCC440EP
From: Henry Bausley @ 2008-07-30 18:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080729200225.57634f94@zod.rchland.ibm.com>
Our board is based upon the Yosemite. But we have modified the CPLD and
made our own custom hardware, thats why the parameters for ioremap are
different. The system is based on the 2.6.14-rtl that has worked absolutely
perfect for a couple of years which we got from FSM Labs.
I am porting to the 2.6.24 kernel Denx with xenomai and had the problem. It
turns out the default value if the EBC0_CFG register was 0x84400000 in the
system and we needed to change it to 0xBC400000 to increase the Ready
Timeout. We were getting a machine check error.
Thank's a lot for your input!!!
----- Original Message -----
From: "Josh Boyer" <jwboyer@linux.vnet.ibm.com>
To: "Henry Bausley" <hbausley@deltatau.com>
Cc: <linuxppc-embedded@ozlabs.org>
Sent: Tuesday, July 29, 2008 5:02 PM
Subject: Re: Writing to CPLD mapped to EBC Port of AMCC440EP
> On Mon, 28 Jul 2008 16:40:35 -0700
> "Henry Bausley" <hbausley@deltatau.com> wrote:
>
>>
>> I am attempting to write to a CPLD mapped to the EBC port of a AMCC
>> 440EP. When I attempt to write using an unsigned variable
>> ie. unsigned *pbase = (unsigned char *)ioremap64(0x8F000000,0x1000000);
>> I get a kernel access of bad area, sig: 11 fault. However, if I change
>> to an unsigned char ie. unsigned char *pbase = (unsigned char
>> *)ioremap64(0x8F000000,
>> 0x1000000); The system doesn't crash. I need to write using an unsigned.
>> Does any one have any ideas what I am doing wrong?
>
> The documentation I have for the Bamboo board says the EPLD is at
> address 0x80002000 and is only 8 bytes in size. Similarly, the
> Yosemite board CPLD is at 0x80002000 and is only 16 bytes in size. Why
> you are ioremapping 16MiB at 0x8F000000 I have no idea.
>
> Also, the individual registers of the EPLD/CPLD on both boards are only
> 8 bits, so an unsigned char seems appropriate. If you have a custom
> board that does something totally different from how the eval boards
> are set up, then I'm not sure many people will be able to help you
> without documentation for that board.
>
> josh
^ permalink raw reply
* Re: [PATCH] hvc - register all available consoles (was: Re: [PATCH] powerpc/lpar - defer prefered console setup)
From: Milton Miller @ 2008-07-30 18:18 UTC (permalink / raw)
To: Bastian Blank; +Cc: ppcdev, Bastian Blank, linux-kernel, Milton Miller
In-Reply-To: <20080730100701.GA3696@wavehammer.waldi.eu.org>
Please CC me, I'm not subscribed to the list.
On Wed Jul 30 at 20:07:01 EST in 2008, Bastian Blank wrote:
> On Wed, Jul 30, 2008 at 04:13:47AM -0500, Milton Miller wrote:
>> On Wed Jul 30 at 17:34:38 EST in 2008, Bastian Blank wrote:
>>> On Wed, Jul 30, 2008 at 08:29:19AM +0200, Bastian Blank wrote:
>>>> Okay, so hvc_console is the culprit. It don't register a preferred
>>>> console if it knows it is not the first in the list.
>>>
>>> The patch registers all available hvc consoles. It adds one "struct
>>> console" for all possible hvc consoles.
>>
>> [ a 6 page patch adding forward declartions, arrays of console
>> structs, moving lots of code and creating N struct console in the
>> hvc_driver shell]
>>
>> After previously having written:
>>> On Wed, Jul 30, 2008 at 08:23:13AM +0200, Bastian Blank wrote:
>>>> On Wed, Jul 30, 2008 at 12:34:51PM +1000, Michael Ellerman wrote:
>>>>> On Mon, 2008-07-28 at 20:56 +0200, Bastian Blank wrote:
>>>>> * add_preferred_console - add a device to the list of preferred
>>>>> consoles.
>>>>> ...
>>>>> * The last preferred console added will be used for kernel
>>>>> messages
>>>>> * and stdin/out/err for init.
>>>>>
>>>>> The last console will be added by the console= parsing, and so
>>>>> that will
>>>>> be used. The console we add in the pseries setup is only used if
>>>>> nothing
>>>>> is specified on the command line.
>>>>
>>>> Okay, then there is a completely different problem. In the case of
>>>> "console=hvc0 console=hvc1" it uses the _first_ add stdin/out bla
>>>> and
>>>> ignores the second one completely.
>>>
>>> Okay, so hvc_console is the culprit. It don't register a preferred
>>> console if it knows it is not the first in the list.
>>>
>>> Bastian
>>
>>
>> [ back to the patch ]
>>> -/*
>>> - * Early console initialization. Precedes driver initialization.
>>> - *
>>> - * (1) we are first, and the user specified another driver
>>> - * -- index will remain -1
>>> - * (2) we are first and the user specified no driver
>>> - * -- index will be set to 0, then we will fail setup.
>>> - * (3) we are first and the user specified our driver
>>> - * -- index will be set to user specified driver, and we will fail
>>> - * (4) we are after driver, and this initcall will register us
>>> - * -- if the user didn't specify a driver then the console will
>>> match
>>> - *
>>> - * Note that for cases 2 and 3, we will match later when the io
>>> driver
>>> - * calls hvc_instantiate() and call register again.
>>> - */
>>> -static int __init hvc_console_init(void)
>>> -{
>>> - register_console(&hvc_con_driver);
>>> - return 0;
>>>
>>
>>
>> Please explain how the reasoning you removed breaks down.
>> What is your usage case?
>
> I have several hvc consoles on a Power hypervisor.
A pretty short description, lacking detail.
>
>> More importantly , how is this different than, say,
>> drivers/serial/8250.c,
>> which also registers just one struct console?
>> would not console=ttyS0 console=ttyS1 have the same problem?
>
> Yes, it have the same problem. Only one of the two (I think the first)
> will get enabled as console.
So lets try to fix the generic code and not one driver.
>> Please instrument the calls to register_console and
>> add_preferred_console
>> and give a detailed description of the problem you are encountering.
>
> | add_preferred_console("hvc", 4, NULL)
>
> This call was added recently by the Power LPAR code.
Not really, it was added in 2.6.16 in 2005
(463ce0e103f419f51b1769111e73fe8bb305d0ec), but we recently stopped
avoiding the call in your use case. But the same issue would exist if
the boot loader issued a console= then appended a user supplied
console=, so lets try to fix the whole problem.
> | add_preferred_console("hvc", 1, NULL)
>
> This comes from the command line ("console=hvc1").
So this meets the assertion that the latter preferred console came from
the command line, and the command line is supposed to get the last
console registered.
> | hvc_config_driver.index == -1
> | register_console(&hvc_con_driver)
> | hvc_config_driver.index == 4
So you did not indicate which call site of register_console in the hvc
driver was called.
When I broke it out the hvc_driver from its clients, there were two
call paths to register the console, as mentioned in the conmment I
quoted. Which path is the problem?
> This call is used to detect the id of the to be enabled hvc device. See
> the comment of hvc_console_init. register_console sets it to the
> _first_ id it finds, in this case 4. There is no other call to
> register_console because there is no hvc console with id 4 registered
> and hvc_instantiate checks this.
>
> The list of consoles looks like:
> - hvc, 4
> - hvc, 1
>
So you claim on the call to register_console, both
add_preferred_console calls had occurred, but the code set changed
console->index from -1 to that of the first call instead of the last
match for the driver? That sounds like the real bug.
> The boot console (udbg0) is destructed later without a real console
> remaining.
>
>> Perhaps the real fix should be scan the command line for console= at
>> console_init time? How does that compare to __setup that is called
>> now?
No, I was referring to console_init (in drivers/char/tty_io.c or so
called from init/main.c). I was thinking perhaps that the __setup
function had not been run so we saw only the setup_arch call and not
the command_line call to add_preferred_console had occurred, but that
appears not to be the case.
> This was removed because it break different things. See
> 5faae2e5d1f53df9dce482032c8486bc3a1feffc.
No that is a different check. That was a scanning for console= by the
setup_arch code. And it appears kernel/printk.c now has an explicit
exported variable for drivers to check that console= had been found on
the command line. Although it would still not trigger in this case
because we call before the command line is processed, as you noted, the
design should take the last one as Michael noted and therefore it
should work.
>>
>> NACK
>> you broke this assertion:
>>> /*
>>> * Initial console vtermnos for console API usage prior to full
>>> console
>>> * initialization. Any vty adapter outside this range will not
>>> have usable
>>> * console interfaces but can still be used as a tty device. This
>>> has to be
>>> * static because kmalloc will not work during early console init.
>>> */
>
> Well. It speaks about "range", but in fact it was exactly one.
No you are counting the wrong thing. The design is supposed to support
any single port to be the console (we have one struct console), but
only one that registers in a fixed slot (hvc_instantiate) in the range
(0, MAX_HVC_CONSOLES), can be selected for a console driver.
>> The idea is you might want serial port to 250 other partitions, but
>> only
>> need to have your choice of console be on the first 8 or so.
>
> hvc is limited to 16 devices.
You are limited to one of the first 16 devices/ports being selectable
as your console, but the number of tty devices is a totally separate
option, and is limited by the number of tty structs we allocate (which
should be dynamic) and the range of the minor that we register.
Don't confuse the current defaults (which might insanely be 8 ttys but
16 possible fixed slots to choose your console from) from the designed
flexibility.
milton
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-07-30 17:23 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Eric Munson, libhugetlbfs-devel, linux-kernel,
linux-mm
In-Reply-To: <20080730014308.2a447e71.akpm@linux-foundation.org>
On (30/07/08 01:43), Andrew Morton didst pronounce:
> On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
>
> > Certain workloads benefit if their data or text segments are backed by
> > huge pages.
>
> oh. As this is a performance patch, it would be much better if its
> description contained some performance measurement results! Please.
>
I ran these patches through STREAM (http://www.cs.virginia.edu/stream/).
STREAM itself was patched to allocate data from the stack instead of statically
for the test. They completed without any problem on x86, x86_64 and PPC64
and each test showed a performance gain from using hugepages. I can post
the raw figures but they are not currently in an eye-friendly format. Here
are some plots of the data though;
x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps
x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps
ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps
ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps
The test was to run STREAM with different array sizes (plotted on X-axis)
and measure the average throughput (y-axis). In each case, backing the stack
with large pages with a performance gain.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Andrew Morton @ 2008-07-30 17:34 UTC (permalink / raw)
To: Mel Gorman
Cc: linuxppc-dev, Eric Munson, libhugetlbfs-devel, linux-kernel,
linux-mm
In-Reply-To: <20080730172317.GA14138@csn.ul.ie>
On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman <mel@csn.ul.ie> wrote:
> On (30/07/08 01:43), Andrew Morton didst pronounce:
> > On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
> >
> > > Certain workloads benefit if their data or text segments are backed by
> > > huge pages.
> >
> > oh. As this is a performance patch, it would be much better if its
> > description contained some performance measurement results! Please.
> >
>
> I ran these patches through STREAM (http://www.cs.virginia.edu/stream/).
> STREAM itself was patched to allocate data from the stack instead of statically
> for the test. They completed without any problem on x86, x86_64 and PPC64
> and each test showed a performance gain from using hugepages. I can post
> the raw figures but they are not currently in an eye-friendly format. Here
> are some plots of the data though;
>
> x86: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86-stream-stack.ps
> x86_64: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/x86_64-stream-stack.ps
> ppc64-small: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-small-stream-stack.ps
> ppc64-large: http://www.csn.ul.ie/~mel/postings/stack-backing-20080730/ppc64-large-stream-stack.ps
>
> The test was to run STREAM with different array sizes (plotted on X-axis)
> and measure the average throughput (y-axis). In each case, backing the stack
> with large pages with a performance gain.
So about a 10% speedup on x86 for most STREAM configurations. Handy -
that's somewhat larger than most hugepage-conversions, iirc.
Do we expect that this change will be replicated in other
memory-intensive apps? (I do).
^ permalink raw reply
* Re: 4xx USB drivers
From: Josh Boyer @ 2008-07-30 16:48 UTC (permalink / raw)
To: - Reyneke; +Cc: linuxppc-embedded
In-Reply-To: <BAY101-W55F03E0DA492264568B776BE7D0@phx.gbl>
On Wed, 2008-07-30 at 13:20 +0000, - Reyneke wrote:
> Hi,
>
> Does anyone know what the state is of the ppc 44x USB host drivers in the powerpc kernel branch (v2.6.25)?
>
> The EHCI and OHCI all seem to be there and OF aware, but we can't quite get it to work.
On which 4xx board? I've used OHCI on 440EP with good success. 440EPx
has an Errata for OHCI/EHCI interactions. AMCC had a patch for arch/ppc
and I believe someone was working on porting that to arch/powerpc
(Vitaly maybe?). If you only use one driver at a time, it should work
there though.
josh
^ permalink raw reply
* [PATCH] Zero fill the return values of rtas arg buffer
From: Nathan Fontenot @ 2008-07-30 16:23 UTC (permalink / raw)
To: linuxppc-dev
The kernel copy of the rtas args struct contains the return
value(s) for the specified rtas call. These are copied back
to user space with the assumption that every value is properly
updated prior. This patch zero's out the return value fields
of the rtas args struct before processing the rtas call.
I am seeing an issue in testing partition mobility, where the
return value fields of the rtas args struct contain stale data.
This causes it to appear as thought the rtas call fails, when
it actually succeeds.
Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
---
Index: linux-2.6.git/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/rtas.c 2008-07-22 09:34:03.000000000 -0500
+++ linux-2.6.git/arch/powerpc/kernel/rtas.c 2008-07-28 11:25:18.000000000 -0500
@@ -792,6 +792,9 @@
if (args.token == RTAS_UNKNOWN_SERVICE)
return -EINVAL;
+ args.rets = &args.args[nargs];
+ memset(args.rets, 0, args.nret * sizeof(rtas_arg_t));
+
/* Need to handle ibm,suspend_me call specially */
if (args.token == ibm_suspend_me_token) {
rc = rtas_ibm_suspend_me(&args);
@@ -808,8 +811,6 @@
enter_rtas(__pa(&rtas.args));
args = rtas.args;
- args.rets = &args.args[nargs];
-
/* A -1 return code indicates that the last command couldn't
be completed due to a hardware error. */
if (args.rets[0] == -1)
^ permalink raw reply
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Scott Wood @ 2008-07-30 15:45 UTC (permalink / raw)
To: Matvejchikov Ilya; +Cc: Ben Gardiner, linuxppc-embedded
In-Reply-To: <8496f91a0807300237q302cafd3ga21ddb7bbc0bd513@mail.gmail.com>
On Wed, Jul 30, 2008 at 01:37:43PM +0400, Matvejchikov Ilya wrote:
> smc1: serial@11a80 {
> device_type = "serial";
> compatible = "fsl,cpm2-smc-uart";
> reg = <11a80 20 0 40>;
> interrupts = <4 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <7>;
> fsl,cpm-command = <1d000000>;
> };
>
> };
>
> (muram node for 2.6.25 is differs from muram node for the 2.6.26)
>
> With this device tree I have a warning message from cpm_uart driver
> tells that the dts file needs to be updated.
Right, but does the serial port work? If it works with this tree and not
with the new version, then that points to a problem in the dynamic pram
allocation. Otherwise, I'm not sure what's causing the difference
between the two versions; you may want to bisect.
-Scott
^ permalink raw reply
* RT-Preemption Kernel 2.6.25
From: Darcy Watkins @ 2008-07-30 14:59 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I noticed an RT-Preemption patch for kernel 2.6.26 (brand new) and
updates to the RT-Preemption patch for kernel 2.6.24.
Does anyone know what the state is regarding kernel 2.6.25 and whether
or not an updated RT-Preemption patch will soon be released for it?
I am using RT-Preemption with kernel 2.6.25 on a PPC405EP and experience
mysterious exceptions involving rt_spinlock_slow_lock() when my system
gets loaded to the point where the CPU becomes saturated. I want to
update and retest before diving in further.
Also, someone please point me to where email discussion, change logs,
etc are kept for RT-Preemption. I only find patches at kernel.org, not
project info. I'd like to be able to see change descriptions related to
patch updates (at least the updates related to development / maintenance
- I know some patch changes are just to keep sync with the kernel
development itself).
Thanks in advance.
--
Regards,
Darcy
--------------
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Eric B Munson @ 2008-07-30 15:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev
In-Reply-To: <20080730014139.39b3edc5.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]
/***************************************************************************
* User front end for using huge pages Copyright (C) 2008, IBM *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the Lesser GNU General Public License as *
* published by the Free Software Foundation; either version 2.1 of the *
* License, or at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU Lesser General Public License for more details. *
* *
* You should have received a copy of the Lesser GNU General Public *
* License along with this program; if not, write to the *
* Free Software Foundation, Inc., *
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
***************************************************************************/
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <string.h>
#define _GNU_SOURCE /* for getopt_long */
#include <unistd.h>
#include <getopt.h>
#include <sys/personality.h>
/* Peronsality bit for huge page backed stack */
#ifndef HUGETLB_STACK
#define HUGETLB_STACK 0x0020000
#endif
extern int errno;
extern int optind;
extern char *optarg;
void print_usage()
{
fprintf(stderr, "hugectl [options] target\n");
fprintf(stderr, "options:\n");
fprintf(stderr, " --help, -h Prints this message.\n");
fprintf(stderr,
" --stack, -s Attempts to execute target program with a hugtlb page backed stack.\n");
}
void set_huge_stack()
{
char * err;
unsigned long curr_per = personality(0xffffffff);
if (personality(curr_per | HUGETLB_STACK) == -1) {
err = strerror(errno);
fprintf(stderr,
"Error setting HUGE_STACK personality flag: '%s'\n",
err);
exit(-1);
}
}
int main(int argc, char** argv)
{
char opts [] = "+hs";
int ret = 0, index = 0;
struct option long_opts [] = {
{"help", 0, 0, 'h'},
{"stack", 0, 0, 's'},
{0, 0, 0, 0},
};
if (argc < 2) {
print_usage();
return 0;
}
while (ret != -1) {
ret = getopt_long(argc, argv, opts, long_opts, &index);
switch (ret) {
case 's':
set_huge_stack();
break;
case '?':
case 'h':
print_usage();
return 0;
case -1:
break;
default:
ret = -1;
break;
}
}
index = optind;
if (execvp(argv[index], &argv[index]) == -1) {
ret = errno;
fprintf(stderr, "Error calling execvp: '%s'\n", strerror(ret));
return ret;
}
return 0;
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Eric B Munson @ 2008-07-30 15:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev
In-Reply-To: <20080730014139.39b3edc5.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
On Wed, 30 Jul 2008, Andrew Morton wrote:
> On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson <ebmunson@us.ibm.com> wrote:
>
> > Certain workloads benefit if their data or text segments are backed by
> > huge pages. The stack is no exception to this rule but there is no
> > mechanism currently that allows the backing of a stack reliably with
> > huge pages. Doing this from userspace is excessively messy and has some
> > awkward restrictions. Particularly on POWER where 256MB of address space
> > gets wasted if the stack is setup there.
> >
> > This patch stack introduces a personality flag that indicates the kernel
> > should setup the stack as a hugetlbfs-backed region. A userspace utility
> > may set this flag then exec a process whose stack is to be backed by
> > hugetlb pages.
> >
> > Eric Munson (5):
> > Align stack boundaries based on personality
> > Add shared and reservation control to hugetlb_file_setup
> > Split boundary checking from body of do_munmap
> > Build hugetlb backed process stacks
> > [PPC] Setup stack memory segment for hugetlb pages
> >
> > arch/powerpc/mm/hugetlbpage.c | 6 +
> > arch/powerpc/mm/slice.c | 11 ++
> > fs/exec.c | 209 ++++++++++++++++++++++++++++++++++++++---
> > fs/hugetlbfs/inode.c | 52 +++++++----
> > include/asm-powerpc/hugetlb.h | 3 +
> > include/linux/hugetlb.h | 22 ++++-
> > include/linux/mm.h | 1 +
> > include/linux/personality.h | 3 +
> > ipc/shm.c | 2 +-
> > mm/mmap.c | 11 ++-
> > 10 files changed, 284 insertions(+), 36 deletions(-)
>
> That all looks surprisingly straightforward.
>
> Might there exist an x86 port which people can play with?
>
I have tested these patches on x86, x86_64, and ppc64, but not yet on ia64.
There is a user space utility that I have been using to test which would be
included in libhugetlbfs if this is merged into the kernel. I will send it
out as a reply to this thread, performance numbers are also on the way.
--
Eric B Munson
IBM Linux Technology Center
ebmunson@us.ibm.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Grant Likely @ 2008-07-30 14:42 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <043095cdcd52bb7af5cf4373b249b302@kernel.crashing.org>
On Mon, Jul 28, 2008 at 09:47:21AM +0200, Segher Boessenkool wrote:
>>> A reasonable "compatible" value would be something like
>>> "serial-eeprom-24c32".
>>> You can go a little bit more generic than that, if you write up in
>>> your binding how the driver should figure out the device size and
>>> the protocol used.
>>
>> Matching on "serial-eeprom-24c32" requires me to convince the at24
>> authors to add that string as an alias binding for their driver.
>
> No, it requires the IIC subsystem to get fixed and not use OF
> "compatible" values as module alias names.
Indeed; the device tree is just a data structure with a well defined
usage model. It is the kernel's job to adapt that data into a form that
it can use.
>> How
>> about "serial-eeprom,24c32" or "generic,24x32"?
>
> Neither "serial-eeprom" nor "generic" is the name of a vendor, so
> no. The comma has a well-defined meaning. Why would a comma be
> easier than a dash for your device matching code, anyway?
Just to add my voice; I 100% agree. If it is not documented, and it
doesn't fit with established conventions, then it shouldn't be used in
the compatible field.
g.
^ permalink raw reply
* Re: [PATCH] dtc: give advance warning that "-S" is going away.
From: Jon Loeliger @ 2008-07-30 14:03 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1217426356-1248-1-git-send-email-paul.gortmaker@windriver.com>
> The "-S" option allowed the specification of a minimum size for
> the blob, however the main reason for caring about the size is
> so there is enough padding to add a chosen node by u-boot or
> whoever. In which case, folks don't really care about the absolute
> size, but rather the size of the padding added for this -- which
> is what the "-p" option does. Having the "-S" just confuses people.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
You rock.
> + if (minsize)
> + fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be r
> emoved soon, use \"-p\" instead\n");
> +
Or use a U-boot that handles re-sizing automatically.
jdl
^ permalink raw reply
* [PATCH] dtc: give advance warning that "-S" is going away.
From: Paul Gortmaker @ 2008-07-30 13:59 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev, jdl, Paul Gortmaker
In-Reply-To: <E1KOBwm-0002vc-CT@jdl.com>
The "-S" option allowed the specification of a minimum size for
the blob, however the main reason for caring about the size is
so there is enough padding to add a chosen node by u-boot or
whoever. In which case, folks don't really care about the absolute
size, but rather the size of the padding added for this -- which
is what the "-p" option does. Having the "-S" just confuses people.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
dtc.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/dtc.c b/dtc.c
index d8fd43b..84bee2d 100644
--- a/dtc.c
+++ b/dtc.c
@@ -182,6 +182,9 @@ int main(int argc, char *argv[])
if (minsize && padsize)
die("Can't set both -p and -S\n");
+ if (minsize)
+ fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be removed soon, use \"-p\" instead\n");
+
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
inform, outform, arg);
--
1.5.6.2
^ permalink raw reply related
* RE: mpc744x, Marvell mv6446x kernel guidance please
From: Stephen Horton @ 2008-07-30 13:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20080728165108.GA22621@mag.az.mvista.com>
Hello Mark,
Thanks for your kind encouragement. I now have a mostly booting kernel.
I have just a few remaining issues to resolve; perhaps you (or others)
can give me some tips regarding these:
1. In your prpmc2800 .dts configuration, in the PCI bus configuration
section, you lay-out the IRQ mappings like this:
interrupt-map =3D <
/* IDSEL 0x0a */
5000 0 0 1 &/mv64x60/pic 50
5000 0 0 2 &/mv64x60/pic 51
I've read the Open Firmware document on Interrupt Mapping, but I still
don't really understand the first 3 columns (5000 0 0), especially where
the first column comes from. Is this just some arbitrarily selected
offset address for that device on the pci bus?
2. I've also grabbed some of the recent katana750i .dts examples that
you were working on from one of the git trees (as well as Remi Machet's
GEFanuc C2k board .dts code which is also based on your prpmc2800). Like
your katana750i example, my board also has 2 PMC sites. In your
cuboot-katana.c file, where you are setting up the PCI devices in
'katana750i_bridge_setup', I'm having trouble understanding how you
selected the bitmask values to Disable and Enable cpu->pci windows?
enables =3D in_le32((u32 *)(bridge_base +
MV64x60_CPU_BAR_ENABLE));
enables |=3D 0x0007fe00; /* Disable all cpu->pci windows */
out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE),
enables);
and here:
enables &=3D ~0x0000c000; /* Enable cpu->pci1 i/o, cpu->pci1 mem0
*/
out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE),
enables);
Can you point me in the right direction to understand this? I have
MPC7450 processor family docs for my processor as well as access to
Marvell docs.
3. My Marvell chip is a MV64462. Unlike the MV64460, it only has a
single Gig Ethernet interface, which on my board connects to an 8-port
Broadcom BCM5388 Ethernet Switch. This switch additionally has 2 Gig E
interfaces for each PMC site, 2 PICMG 2.16 connected interfaces, and 1
faceplate connected port. I am successful in getting the Marvell to
setup a Mac-to-Mac connection to the switch via its connected port, but
I'm unsure how to tell Linux about the other ports on the switch,
primarily the 2 PICMG 2.16 ports and the faceplate port. I have access
to the switch in my platform .c file, where I am configuring and
verifying that I have the mac-mac connection setup. Can you speculate
on how I can get the other interfaces to configure? Do I need to a
section in my .dts for the Broadcom switch? My .dts currently only has 1
ethernet and 1 PHY defined... Or, should I setup multiple Ethernet
sections all on the same PHY, or something like that? Or, should I just
do something in my platform file to get Linux to add the other
interfaces?
I appreciate any other addition thoughts you can give,
Regards,
Stephen
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]=20
Sent: Monday, July 28, 2008 11:51 AM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: mpc744x, Marvell mv6446x kernel guidance please
On Thu, Jul 10, 2008 at 10:46:49PM -0500, Stephen Horton wrote:
> Hello folks,
>=20
> In a current work project, I have inherited a compactPCI board that
has
> an mpc7447/7448 powerpc processor as well as a Marvell system
> controller, model mv64462 (stripped down mv64460). The board has a
> somewhat working Gentoo Linux port running on it from long ago and a
> company far far away (kernel version 2.6.9 built using arch/ppc). To
> prepare for an upcoming deployment, I would like to bring the OS
> up-to-date on this board with a newer kernel (targeting Gentoo 2008),
> but I am unsure of the approach to take. I am a software developer,
but
> normally do not work on kernel porting / board integration. I have
> researched the arch/ppc to arch/powerpc migration, but I'm a bit
> intimidated by the 'new' device tree symantics and other changes to
the
> stream. Here are some questions:
>=20
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
arch/ppc is gone now. You should spend you effort working in
arch/powerpc.
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
You can use prpmc2800 as an example.
> 3. Any advice of any kind?
Its not as bad as it looks. Just dig into it and don't give up.
Mark
^ 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