On Tue, 4 Jan 2011 13:00:07 -0800
bruce_leon...@selinc.com wrote:
> True, but we really didn't want to recreate all the infrastructure
> that the gianfar driver has in it we wanted to just use it. Maybe
> what I should do is just take the guts of the gianfar driver and make
> a pure PCI driver ou
Happy New Year!
I didn't survive the latest round of layoffs at Pika. So in two weeks
the smaclen...@pikatech.com email will be dead. I also will no longer
have access to a Warp.
I would like to thank all the people on this list that helped me with
with the PPC. Everybody gave freely of their tim
On Thu, 21 Oct 2010 22:30:16 +0100
Michael Barry wrote:
> I am out of the office until 01/11/2010.
Woo hoo! Time to loot his office for the good stuff!
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.or
Anybody else seeing this with 2.6.36?
[ 431.260895] Unable to handle kernel paging request for data at address
0x24002082
[ 431.268407] Faulting instruction address: 0xc000f6c0
[ 431.273321] Oops: Kernel access of bad area, sig: 11 [#1]
[ 431.278670] Warp
[ 431.280494] last sysfs file:
[ 43
On Tue, 5 Oct 2010 21:55:35 -0400
Josh Boyer wrote:
> Well, Warp and Sam440EP are production boards for actual companies.
> The rest are all just eval boards. I don't know if the board
> maintainers care either way, I was just using them as examples of
> cases where someone might.
In the warp c
On Thu, 9 Sep 2010 09:49:14 -0700
Tirumala Marri wrote:
> [Marri] Great we already have it. We should remove the defconfigs
> under 44x then ?
I'd rather we didn't. I thought Linus' beef was over the churn in the
defconfigs, not the fact that they exist. The 44x defconfigs change
very rarely.
C
On Thu, 2 Sep 2010 14:12:22 -0700
"Ira W. Snyder" wrote:
> To give you three example drivers:
> 1) Data processing FPGA access driver
>
> This driver provides a simple character device to userspace which
> exposes one function: mmap. With it, you can mmap the entire data
> processing FPGA memor
On Thu, 2 Sep 2010 13:04:34 -0700
"Ira W. Snyder" wrote:
> Hello all,
>
> I've written several drivers for a custom board. The board is
> basically an mpc8349_mds board with some extra FPGAs for data
> processing.
>
> All of the drivers were written to interface with a custom system
> controlle
he generic MTMSRD macro.
Only enable ldstfp when CONFIG_PPC_FPU is set.
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 74a7f41..55f19f9 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -62,7 +62,7 @@
On Wed, 1 Sep 2010 18:02:14 +1000
Paul Mackerras wrote:
> Ah, those references would be from arch/powerpc/lib/sstep.c.
> Evidently we need #ifdef CONFIG_PPC_FPU around the emulation of the
> floating-point loads and stores.
I tried that yesterday and it didn't help, although maybe I forgot to
ma
On Wed, 1 Sep 2010 01:45:46 -0500
Kumar Gala wrote:
> For what defconfig setup do you get the errors above?
44x/ebony_defconfig
Then enable KPROBES (or XMON).
Then put an #ifdef CONFIG_PPC_FPU in ldstfp.S.
Cheers,
Sean
___
Linuxppc-dev mailing li
On Tue, 31 Aug 2010 13:46:05 -0400
Sean MacLennan wrote:
> On Tue, 31 Aug 2010 11:17:17 -0500
> Kumar Gala wrote:
>
> > Can we add proper CONFIG_PPC_FPU into this file.
>
> If nobody beats me to it I can try this evening.
I had to give up. Without the CONFIG_PPC
On Tue, 31 Aug 2010 11:17:17 -0500
Kumar Gala wrote:
> Can we add proper CONFIG_PPC_FPU into this file.
If nobody beats me to it I can try this evening.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozla
On Tue, 31 Aug 2010 04:15:20 +0200
Alexander Graf wrote:
> Commit 0016a4cf introduced a lot of mtmsrd's that were plainly
> written out. These failed to compile on my e500v2 system, so let's
> better use the macro that is around just for that purpose.
I sent in the same patch ;)
Cheers,
Sean
eric MTMSRD macro.
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
index f644863..ce818a5 100644
--- a/arch/powerpc/lib/ldstfp.S
+++ b/arch/powerpc/lib/ldstfp.S
@@ -81,7 +81,7 @@ _GLOBAL(do_lfs)
mfmsr r6
ori r7,r6,MSR_FP
best place to define it. If the
mapping of mtmsrd to mtmsr is correct, maybe it should be in asm/reg.h?
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S
index f644863..df8a03b 100644
--- a/arch/powerpc/lib/ldstfp.S
+++ b/arch/powerpc/lib/lds
The new file ldstfp.S is getting pulled in on the Warp due to
CONFIG_KPROBES, but does not compile:
AS arch/powerpc/lib/ldstfp.o
arch/powerpc/lib/ldstfp.S: Assembler messages:
arch/powerpc/lib/ldstfp.S:84: Error: Unrecognized opcode: `mtmsrd'
arch/powerpc/lib/ldstfp.S:96: Error: Unrecognize
rpc target to fail to boot.
Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().
There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.
rpc target to fail to boot.
Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().
There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.
>
> The .data..init_task output section was missing
> a load offset causing a popwerpc target to fail to boot.
>
> Sean MacLennan tracked it down to the definition of
> INIT_TASK_DATA_SECTION().
>
> There are only two users of INIT_TASK_DATA_SECTION()
> in the kern
On Tue, 13 Jul 2010 11:50:24 +0200
Sam Ravnborg wrote:
> Ben - will you take it via the popwerpc tree
> or shall I ask Michal to take it via kbuild?
Anything happening with this patch?
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.o
On Tue, 13 Jul 2010 10:54:19 +0200
Sam Ravnborg wrote:
> It looks like a missing AT() in the output section.
> The following patch should also fix it.
>
> Please test and let us know.
>
> Thanks,
> Sam
Applied the patch and it solves the problem. Thanks.
Cheers,
Sean
On Mon, 28 Jun 2010 00:59:00 -0400
Sean MacLennan wrote:
> Anybody else seeing these messages?
>
> ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> section .data..init_task lma 0xc03a2000 overlaps pr
Anybody else seeing these messages?
ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000 overlaps
previous sections
ppc_4xxFP-ld: .tmp_vmlinux2: section .data..init_task lma 0xc03a2000 overlaps
previous sections
ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000 overl
On Sat, 5 Jun 2010 19:44:37 +0200
Olaf Hering wrote:
> Maybe.
> As it stands right now, mkuboot.sh does not run without bash.
>
>
> And:
> Reality check please.
> A _development system_ without bash, installed per default on every
> sane Linux distro, does most likely not exist.
Hmmm, can't ar
On Sat, 5 Jun 2010 10:10:39 +0200
Olaf Hering wrote:
> scripts in the kernel source do not have executable permissions if
> they were created with patch(1) run mkuboot.sh with bash, its tagged
> as bash script.
Wouldn't it be better to use ${SHELL}? Not every system has bash.
Cheers,
Sean
__
m Sang
> Acked-by: Grant Likely
Acked-by: Sean MacLennan
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 18 Mar 2010 09:22:39 -0600
Grant Likely wrote:
> The following structure elements duplicate the information in
> 'struct device.of_node' and so are being eliminated. This patches
> makes all readers of the following elements use device.of_node
> instead.
Ac
On Thu, 18 Mar 2010 11:07:35 -0600
Grant Likely wrote:
> On Thu, Mar 18, 2010 at 10:59 AM, Sean MacLennan
> wrote:
> > On Thu, 18 Mar 2010 09:22:39 -0600
> > Grant Likely wrote:
> >
> >> The following structure elements duplicate the information in
> >>
On Thu, 18 Mar 2010 09:22:39 -0600
Grant Likely wrote:
> The following structure elements duplicate the information in
> 'struct device.of_node' and so are being eliminated. This patches
> makes all readers of the following elements use device.of_node
> instead.
The NDFC driver also needs a pat
On Thu, 11 Mar 2010 11:23:49 -0700
Grant Likely wrote:
> .name, .match_table and .owner are duplicated in both
> of_platform_driver and device_driver, so the of_platform_driver
> copies will be removed soon.
>
> Signed-off-by: Grant Likely
i2c-ibm_iic
Acked-by:
On Thu, 11 Mar 2010 11:22:54 -0700
Grant Likely wrote:
> .name, .match_table and .owner are duplicated in both
> of_platform_driver and device_driver, so the of_platform_driver
> copies will be removed soon.
>
> Signed-off-by: Grant Likely
NDFC
Acked-by:
The watchdog_info struct cannot be a const since we dynamically fill
in the firmware version.
Signed-off-by: Sean MacLennan
---
diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
index 435ec2a..2d22e99 100644
--- a/drivers/watchdog/pika_wdt.c
+++ b/drivers/watchdog/pika_wdt.c
On Mon, 22 Feb 2010 21:21:53 -0800
"Feng Kan" wrote:
> Hi Sean:
>
> I will withdraw this patch. I had a talk with the U-Boot guys. The
> reason for this patch was to support those guys that had their ECC
> ordering at (213) on the older version of the kernel. Upgrading to
> (123) may be problem
On Thu, 18 Feb 2010 15:11:18 -0800
Feng Kan wrote:
> This is to lock down the ordering in the correction routine against
> the calculate routine. Otherwise, incorrect define would cause ECC
> errors.
Did you actually find a 44x PPC core that is not NAND_ECC_SMS format?
Cheers,
Sean
_
Found it. We are calling sock_sendmsg, which is definitely a call that
can block! The receive side is done in a thread (which does no floating
point ;), but the send was called directly from the "evil FP thread".
It looks like under light load, you tend to get away with it, so our
trivial testing
On Fri, 11 Dec 2009 07:19:39 +1100
Benjamin Herrenschmidt wrote:
> I'm not sure that will work in all cases, you are playing a bit with
> fire :-) I suppose I could think it through after breakfast but my
> first thought is "don't do that !". Among other things you may not
> have a pt_regs to sav
One of our drivers has code that was originally running on a DSP. The
code makes heavy use of floating point. We have isolated all the
floating point to one kthread in the driver. Using enable_kernel_fp()
this has worked well.
But under a specific heavy RTP load, we started getting kernel panics.
On Wed, 9 Dec 2009 09:40:55 -0500
Josh Boyer wrote:
> How does that impact the older revisions? You're using a cuImage
> with Warp, so the device tree is bundled with that. If you boot a
> new kernel with this change to the DTS on a older board revision,
> will it do bad things?
The new SD dri
Newer revs of the FPGA have a larger SD buffer.
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index 31605ee..e576ee8 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -146,7 +146,7
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
I have not been able to reproduce the problem :( I haven't had a lot of
time to run
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
It hasn't happened that often, but I have been focusing on 2.6.31.
So far, it has a
On Thu, 3 Dec 2009 14:06:34 -0600
Jake Magee wrote:
> Have you tried the following patches? I'm not sure if they have made
> it into the newer releases.
> http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg37188.html
>
> Also for reference... http://patchwork.ozlabs.org/patch/34047/
With 2.6.32 I sometimes get lots and lots of "Bad page map" errors as
shown below. I believe these started in 2.6.32-rc8 or possibly
2.6.32-rc7. Pika just switched to 2.6.31 so I have been concentrating
on that release, and not really testing the 2.6.32 stream.
I wish I could give more info, but I
We need to align before the output section. Having the align inside
the output section causes the linker to put some filler in there,
which makes it a non-empty section, but this section isn't assigned to
a segment so you get a warning from the linker.
Signed-off-by: Sean MacLennan
---
Here is the ld -M output for the "bad" compile:
.data_nosave0xc0376790 0x870 load address 0x00376790
0xc0377000. = ALIGN (0x1000)
*fill* 0xc0376790 0x870 00
0xc0377000__nosave_begin = .
*(.data.nosave)
I looked into it some more the patch converts this section:
. = ALIGN(PAGE_SIZE);
.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
__nosave_begin = .;
*(.data.nosave)
. = ALIGN(PAGE_SIZE);
__nosave_end = .;
If I revert the commit show at the bottom of this email, the warnings
go away.
It took a while to find this, git bisect kept pointing me to a file
from arch/alpha :(
Cheers,
Sean
powerpc: Cleanup linker script using new linker script macros.
author Tim Abbott
Thu, 24 Sep 2009
Anybody else getting these? They just started popping up with the
recent changes for 2.6.32.
ppc_4xxFP-ld: .tmp_vmlinux1: warning: allocated section `.data_nosave'
not in segment KSYM.tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
ppc_4xxFP-ld: .tmp_vmlinux2: warning: all
What is the status of this bug?
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 31 Aug 2009 22:20:00 -0400
Benjamin Gamsa wrote:
> For what it's worth, the problem occurs even when ntp is not even
> started.
This is grasping, but could it have anything to do with the jiffies
wrapping near startup?
Cheers,
Sean
___
Linux
On Thu, 20 Aug 2009 17:19:17 -0700
Feng Kan wrote:
> Fix ECC Correction bug where the byte offset location were double
> fliped causing correction routine to toggle the wrong byte location
> in the ECC segment. The ndfc_calculate_ecc routine change the order
> of getting the ECC code.
It looks l
On Fri, 21 Aug 2009 10:47:09 +0530
vimal singh wrote:
> Just one question: did you enabled MTD_NAND_ECC_SMC in configs?
It is automagically selected when you select the NDFC driver.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozla
];
> - ecc_code[1] = p[1];
> + ecc_code[0] = p[1];
> + ecc_code[1] = p[2];
> ecc_code[2] = p[3];
>
> return 0;
Acked-by: Sean MacLennan
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, 20 Aug 2009 07:01:21 +0200
Stefan Roese wrote:
> On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
> > > I see other boards using SMC as well, can someone comment on the
> > > change I am proposing.
> > > Should I change the correction algorithm o
On Wed, 19 Aug 2009 16:16:54 -0700
Feng Kan wrote:
> I see other boards using SMC as well, can someone comment on the
> change I am proposing.
> Should I change the correction algorithm or the calculate function?
> If the later is preferred
> it would mean the change must be pushed in both U-Boot
On Thu, 6 Aug 2009 17:04:18 +0530
"Aggrwal Poonam-B10812" wrote:
> Can u point me to some reference of this, shud they be partit...@0,
> partit...@1, etc...
> I am not able to configure all the partitions successfully.
Not unless all your partitions are 1 byte long ;)
The number is the offset i
age of this new state.
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index 01bfb56..31605ee 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -261,10 +261,11 @@
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt wrote:
> Kumar already submitted a couple, Frans, feel free to beat me
> at converting UIC (just use kmalloc directly in there instead
> of alloc_bootmem).
I replace the bootmem_alloc with a kzalloc and the badness went away.
So it looks
On Mon, 22 Jun 2009 11:52:11 +1000
David Gibson wrote:
> On Sun, Jun 21, 2009 at 09:28:00PM -0400, Jon Smirl wrote:
> > Have git ignore generated files from dtc compile
> > Signed-off-by: Jon Smirl
>
> Acked-by: David Gibson
Ack
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt wrote:
> Right, our interrupt controllers need those fixes, they are low
> on my priority list since it's a reasonably harmless warning and I'm
> still chasing some actual breakage (though maybe not directly related
> to your patches).
>
I found the source of the badness. The backtrace is correct:
uic_init_one
___alloc_bootmem
___alloc_bootmem_nopanic
alloc_arch_preferred_bootmem
In alloc_arch_preferred_bootmem we have:
if (WARN_ON_ONCE(slab_is_available()))
return kzalloc(size, GFP_NOWAIT);
Since the sl
On Sat, 20 Jun 2009 22:56:45 +0200
Frans Pop wrote:
> The fact that your bisect ended at a merge essentially means that it
> is invalid. As a merge does not introduce any actual change (unless
> it includes changes to resolve conflicts), it normally cannot be the
> cause of a regression.
Makes s
[0.00] [ cut here ]
[0.00] Badness at c033ebc4 [verbose debug info unavailable]
[0.00] NIP: c033ebc4 LR: c033eb94 CTR:
[0.00] REGS: c037fe70 TRAP: 0700 Not tainted (2.6.30-pika)
[0.00] MSR: 00021000 CR: 22022024 XER: 000
-by: Sean MacLennan
---
diff --git a/arch/powerpc/platforms/44x/warp.c
b/arch/powerpc/platforms/44x/warp.c
index 42e09a9..0362c88 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
On Tue, 16 Jun 2009 11:24:35 -0400
Sean MacLennan wrote:
> I forgot to include the defconfig in the last set of patches. So you
> don't get to use the shiny new LEDS driver on the warp unless you turn
> it on.
>
> Enabling hotplug is also very important since we have moved t
LEDS
* Enable LED triggers
* Move to slub
* Enable hotplug
* Enable timestamps on printks
* Enable UBIFS
Signed-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/configs/44x/warp_defconfig
b/arch/powerpc/configs/44x/warp_defconfig
index 3b77f09..787635f 100644
--- a/arch/powerpc/config
On Thu, 11 Jun 2009 10:50:52 +1000
Benjamin Herrenschmidt wrote:
> n Wed, 2009-06-10 at 17:56 -0400, Sean MacLennan wrote:
> > What ever happened to this patch?
>
> Dunno... It should have been in patchwork. I remember the patch
> in fact and I intended to merge it... Can
What ever happened to this patch?
diff --git b/arch/powerpc/platforms/44x/warp.c
a/arch/powerpc/platforms/44x/warp.c index c511880..7f3c1c7 100644
--- b/arch/powerpc/platforms/44x/warp.c
+++ a/arch/powerpc/platforms/44x/warp.c
@@ -43,7 +43,13 @@ static int __init warp_probe(void)
{
unsign
On Wed, 27 May 2009 21:42:18 -0600
Grant Likely wrote:
> Make your driver use a platform device or an of_platform device. It's
> not at all hard.
Here is my first shot any other fields that I need to fill in so I
don't have any gotchas?
/* This must exist */
static void warp_device_release
On Thu, 28 May 2009 13:52:29 +1000
Benjamin Herrenschmidt wrote:
> Can't you set ISA_DMA_THRESHOLD = ~0L from your warp.c platform file ?
I actually set it in the driver proper since it is faster to test, but
it works. I am just wondering how kosher that is.
The advantage of the platform_device
On Mon, 25 May 2009 14:33:43 +1000
Benjamin Herrenschmidt wrote:
> This is going to .30 if nobody hollers. I've done some testing here
> and it seems to be fine, but more eyes at this stage are much welcome.
Sigh, I didn't get a chance to look at this until tonight. I use
__dma_alloc_coherent in
On Mon, 18 May 2009 20:58:03 -0600
Grant Likely wrote:
> Then let it lie fallow on the list and in patchwork. It is published,
> and people know that it is available (I'll certainly consider it as I
> do driver work), but there must be real (not just theoretical) in
> kernel users of the interfa
led.default_state =
> LEDS_GPIO_DEFSTATE_ON;
> + } else {
> + led.default_state =
> LEDS_GPIO_DEFSTATE_OFF;
> + }
Just a nitpick, you don't need the {} braces here. Other than that:
Acked-by:
perform this kind of operation
> properly.
>
> Signed-off-by: Timur Tabi
Nice. I could have used a routine like this in a couple of our drivers.
So, for what it is worth:
Acked-by: Sean MacLennan
Cheers,
Sean
___
Linuxppc-dev mailing list
On Sun, 3 May 2009 22:07:01 +0200
"Sam Ravnborg" wrote:
> On Sun, May 03, 2009 at 09:33:16PM +0200, Wolfgang Denk wrote:
> > Which exact commands did you use to build the kenrel, and how did
> > you set (and export?) the CROSS_COMPILE environment variable?
export CROSS_COMPILE=ppc_4xxFP-
export
On Sun, 3 May 2009 20:45:46 +1000
"Stephen Rothwell" wrote:
> What gcc, binutils versions and config are you using?
gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)
GNU assembler version 2.16.1 (powerpc-linux) using BFD version 2.16.1
And this is all running on the Warp with a 440EP.
Cheers,
Sean
__
b614a697dc17dff82f140d72d21a095f810fa7fb is first bad commit
commit b614a697dc17dff82f140d72d21a095f810fa7fb
Author: Anders Kaseorg
Date: Thu Apr 23 16:49:33 2009 -0400
kbuild, modpost: Check the section flags, to catch missing "ax"/"aw"
When you put
.section ".foo"
in an
Latest pull from Linus' git.
Cheers,
Sean
WARNING: vmlinux.o (.text): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example contains
section definitions for use in .S files.
WARNING: vmlinux.o (.head.text): unexpected non-allocatable section.
On Mon, 27 Apr 2009 14:05:44 -0500
"Timur Tabi" wrote:
> +#define spin_event_timeout(condition, timeout, delay,
> rc) \
> +{ \
> + unsigned long __loops = tb_ticks_per_usec *
> timeout;
On Fri, 17 Apr 2009 20:12:50 -0700 (PDT)
"Trent Piepho" wrote:
> On Mon, 6 Apr 2009, Sean MacLennan wrote:
> > Now that leds-gpio is a proper OF platform driver, the Warp can use
> > the leds-gpio driver rather than the old out-of-kernel driver.
> >
> > On
Any status update on this? The patch has actually been in use since
2.6.29. I wrote a stub LED driver that mimiced leds-gpio with the of
patch.
All I had to do when the leds-gpio of patch went in was drop the stub
driver.
I'd like to get this in then update the warp defconfig for 2.6.30.
Cheers,
Any update on the status of this patch? This patch was acked by Jean.
The patchwork entry is http://patchwork.ozlabs.org/patch/21576/ and the
original patch message is below.
Cheers,
Sean
On Mon, 2 Feb 2009 12:01:59 -0500
Sean MacLennan wrote:
> This is a trivial patch that does not n
On Mon, 6 Apr 2009 18:20:23 -0400
"Sean MacLennan" wrote:
> I am trying to run the /sbin/hotplug from the kernel and it doesn't
> work. Has anybody got it running?
I looked into it some more. It turns out that the env pointers are
freed before they are copied.
In kobj
I am trying to run the /sbin/hotplug from the kernel and it doesn't
work. Has anybody got it running?
I know I am being a bit vague, but I don't want to write a long email
and find out that it is a know problem ;)
Basically, I want to automount SD cards and USB keys. So if anybody
knows a better
-off-by: Sean MacLennan
---
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index 7e183ff..01bfb56 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -1,7 +1,7 @@
/*
* Device Tree Source for PIKA Warp
*
- * Copyright (c) 2008 PIKA
On Thu, 2 Apr 2009 00:39:05 -0400
"Sean MacLennan" wrote:
> Although, that *could* be unrelated bug.
It *is* an unrelated bug. dma_alloc_coherent now requires a device
where before it was optional. Carry on.
Cheers,
Sean
___
Linuxpp
On Thu, 02 Apr 2009 15:26:02 +1100
Benjamin Herrenschmidt wrote:
> The proper fix is for PAGE_KERNEL_X to have _PAGE_HWEXEC. I'll fix
> that.
That may not be enough. I made that change (adding _PAGE_HWEXEC to
PAGE_KERNEL_X) and it works for some drivers, but I am still crashing in
one driver. Al
On Thu, 02 Apr 2009 09:24:43 +1100
"Benjamin Herrenschmidt" wrote:
> I suspect I just screwed up the definition of PAGE_KERNEL_EXEC or
> something like that.
Yup, that is exactly what you did ;) You left out _PAGE_HWEXEC. The
following patch fixes the problem for me.
Cheers,
Sean
diff --git
On Wed, 1 Apr 2009 07:27:56 -0400
Josh Boyer wrote:
> I'm assuming this is the result of a git-bisect run?
Correct.
> Can I also assume you were loading the module on your Warp board?
Correct again.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linux
8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5 is first bad commit
commit 8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5
Author: Benjamin Herrenschmidt
Date: Thu Mar 19 19:34:08 2009 +
powerpc/mm: Tweak PTE bit combination definitions
This patch tweaks the way some PTE bit combinations are
With the latest from Linus' tree, I get the following oops:
Oops: Kernel access of bad area, sig: 11 [#1]
Warp
Modules linked in: simple(+)
NIP: d14b8000 LR: c0001420 CTR:
REGS: cf2a1df0 TRAP: 0400 Not tainted (2.6.29-pika)
MSR: 00029000 CR: 2422 XER:
TASK = cf896100[16
Any advantages on the PPC of using SLUB or SLOB over SLAB? I am
especially interested in memory savings.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Sat, 7 Mar 2009 08:14:41 -0700 (MST)
"Eddie Dawydiuk" wrote:
> On another note, can you tell me/point me to some documentation on
> how to get a unique machine ID for a new board?
Do you mean the model in the dts, like "amcc,yosemite"? You just pick
one.
It is just company name, board name.
On Tue, 3 Mar 2009 16:09:06 -0800
"Andrew Morton" wrote:
> afacit that interface is powerpc-only.
Yes it is. You might want a CONFIG_PPC with that.
It has been. u carry the two... longer than I want to admit
since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
platform
logs show the driver, then the devices. Currently you can get
device(s), driver, device(s).
Signed-off-by: Sean MacLennan
---
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 88f0db7..7fc0729 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c
On Mon, 02 Feb 2009 17:44:36 +0100
"Grzegorz Bernacki" wrote:
> I enabled CONFIG_EEPROM_LEGACY in my defconfig and I can see eeprom
> detected in dmesg and I can also read/write to it via file
> /sys/bus/i2c/devices/0-0050/eeprom.
Thanks for trying that! Now I need to see what I am doing diffe
On Mon, 02 Feb 2009 13:50:59 +0100
"Grzegorz Bernacki" wrote:
> I would like to have support for following devices in defconfig for
> digsy:
> - LXT PHY
> - RTC DS1337
> - EEPROM AT24
> - MTD partitioning based on OF description
I am seeing a problem where if I enable CONFIG_EEPROM_LEGACY and
C
Not sure if this is PPC specific or not. I use the following patch to
get a clean git status. Does nobody else see this file? Or am I missing
a step somewhere?
Cheers,
Sean
Ignore the vmlinux.strip file.
Signed-off-by: Sean MacLennan
diff --git a/.gitignore b/.gitignore
index 869e1a3
On Tue, 20 Jan 2009 06:29:30 -0500
"Josh Boyer" wrote:
> Since I'll be doing defconfig updates today, just tell me which
> options you need set or disabled.
Let's try this patch and see how it goes. If it doesn't apply easily, I
will just give you a list.
Note a few of the options will be disa
1 - 100 of 362 matches
Mail list logo
