Mohan Kumar M writes:
> One of the relocatable kernel support patches assumes that the target
> address will be 0. But for kdump kernels (without relocation support) it
> will be 32MB. The following patch fixes this issue.
>
> Fix kdump kernel issue
>
> Kdump kernel without relocation support ne
Mohan Kumar M writes:
> Support for relocatable kdump kernel
[snip]
> @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start)
> /* process relocations for the final address of the kernel */
> lis r25,[EMAIL PROTECTED] /* compute virtual base of kernel */
> sldir25,r25,32
>
Josh Boyer writes:
> From: Josh Poimboeuf <[EMAIL PROTECTED]>
>
> The powerpc 32-bit and 64-bit kernel_thread functions don't properly
> propagate errors being returned by the clone syscall. (In the case of
> error, the syscall exit code returns a positive errno in r3 and sets
> the CR0[SO] bit.
Grant Likely writes:
> On Wed, Oct 08, 2008 at 04:39:13PM +0200, Dominik Bozek wrote:
> > Hi all,
> >
> > I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313.
> > And the major conclusion is that __copy_tofrom_user is more efficient
> > than memcpy. Sometimes about 40%.
> >
>
Scott Wood writes:
> I'm not sure why we don't use dcbt in memcpy(), as it's just ignored if
> the memory is cache-inhibited.
Both dcbt and dcbz tend to slow things down if the relevant block is
already in the cache. Since the kernel memcpy is mostly used for
copies that are only 1 or a small n
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-08 at 12:51 -0700, Kevin Diggs wrote:
Hi,
I thought I might take a whack at fixing the 2.6 serial driver
for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA.
A quick glance at macserial.c (2.4.31) suggests it has dbdma
The fsl_upm nand driver fails to build because fsl_lbc_lock isn't
exported, the lock is needed by the inlined fsl_upm_run_pattern()
function:
ERROR: "fsl_lbc_lock" [drivers/mtd/nand/fsl_upm.ko] undefined!
Dave Jones purposed to export the lock, but it is better to just uninline
the fsl_upm_run_pa
On Thu, Oct 09, 2008 at 07:45:11AM +1100, Benjamin Herrenschmidt wrote:
> Yes, it's not totally trivial and I wouldn't recommend using the weirdo
> code in macserial (it does things that I don't understand how they work
> with the dbdma engine).
>
> The best way I see is to start from scratch with
Commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614 ("powerpc: Change the
default link address for pSeries zImage kernels") changed the
real-base value in the CHRP note added by the addnote program from
12MB to 32MB to give more space for Open Firmware to load the zImage.
(The real-base value says wher
On Thu, Oct 09, 2008 at 03:02:19AM +0400, Anton Vorontsov wrote:
> Hi,
>
> On Wed, Oct 08, 2008 at 06:28:15PM -0400, Dave Jones wrote:
> > Hi Anton,
> > I tried reenabling CONFIG_MTD_NAND_FSL_UPM in the Fedora kernel
> > today (currently on 2.6.27-rc9-git1), and got the error below.
> >
On Thu, Oct 09, 2008 at 03:02:19AM +0400, Anton Vorontsov wrote:
> Though better option would be to uninline the fsl_upm_run_pattern()..
> it is quite big anyway... Something like this:
Even better. We don't need exported fsl_lbc_regs too. And also we can
mark the lock and regs as static. Yeah, w/
Hi,
On Wed, Oct 08, 2008 at 06:28:15PM -0400, Dave Jones wrote:
> Hi Anton,
> I tried reenabling CONFIG_MTD_NAND_FSL_UPM in the Fedora kernel
> today (currently on 2.6.27-rc9-git1), and got the error below.
>
> ERROR: "fsl_lbc_lock" [drivers/mtd/nand/fsl_upm.ko] undefined!
Weird. It works for
Here is the remainder of the driver - just the structure of the
registers for the 440EPx. I put the struct in this file because that
is similar to what was done for the mpc52xx, but the struct could go
elsewhere if more appropriate.
Anyway, I'd like some feedback on this driver, because I imagine
On Thu, Oct 09, 2008 at 07:03:06AM +1100, Benjamin Herrenschmidt wrote:
> No. Instead, send a patch that fixes the defconfig's to explicitely set
> those to "n".
What's the difference, other than wasting some bytes in the Kconfig file?
> As to whether those should be defaults or not, this is a d
On Oct 8, 2008, at 2:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-08 at 07:10 -0500, Kumar Gala wrote:
On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote:
Its useful to not rebase a branch you expect people to send you
patches against and sub-maintainers are using to build tr
I have begun writing a driver for the GPIOs of the PPC440EPx. I just
noticed that the PIKA Warp .dts references a device "ibm,gpio-440ep",
but so far I have not been able to find a driver for that device.
So, here is what I have so far (patch is off 2.6.27-rc9). It is not
sufficiently general to
On Wed, 2008-10-08 at 12:51 -0700, Kevin Diggs wrote:
> Hi,
>
> I thought I might take a whack at fixing the 2.6 serial driver
> for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA.
> A quick glance at macserial.c (2.4.31) suggests it has dbdma support for
> receive. Any
On Wed, 2008-10-08 at 15:14 -0500, Timur Tabi wrote:
>
> But this is the reason I sent you the patch in the first place. I
> think "default y" is wrong and doesn't make any sense, so I'm asking
> you for a technical reason why PMAC and CHRP should default to yes.
> That is the focus of my patch.
On Wed, Oct 8, 2008 at 3:03 PM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> No. Instead, send a patch that fixes the defconfig's to explicitely set
> those to "n". As to whether those should be defaults or not, this is a
> different discussion (I'm almost tempted to have everything default
On Wed, 2008-10-08 at 14:57 -0500, Timur Tabi wrote:
> Remove the "default y" from the Kconfig options for CHRP, PMAC, and PMAC64
> platforms. This patch is a follow-up to "remove CHRP and PMAC support from
> defconfigs, fix Kconfigs", which was applied incompletely.
No. Instead, send a patch tha
Hi,
I thought I might take a whack at fixing the 2.6 serial driver
for my 8600. At the top of pmac_zilog.c (2.6.26) there is a todo for DMA.
A quick glance at macserial.c (2.4.31) suggests it has dbdma support for
receive. Anyone know of any pitfalls for adding dbdma support for
pmac_zilo
Remove the "default y" from the Kconfig options for CHRP, PMAC, and PMAC64
platforms. This patch is a follow-up to "remove CHRP and PMAC support from
defconfigs, fix Kconfigs", which was applied incompletely.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Ben, in the future, please apply eith
Benjamin Herrenschmidt wrote:
> yeah well, there's a consistency problem. If we remove default for these
> we should remove default for all.
I only removed the default from the ones I knew were wrong.
> The bug I think is in your original patch in fact to just remove those
> from .config rather
On Wed, 2008-10-08 at 10:28 -0500, Timur Tabi wrote:
> On Fri, Sep 26, 2008 at 12:19 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> > The Kconfig files for PowerPC CHRP and PMAC support had "default=y" for some
> > Kconfig options, and this caused support for CHRP and PMAC platforms to be
> > enabled
On Wed, 2008-10-08 at 07:10 -0500, Kumar Gala wrote:
> On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote:
>
> >
> >> Its useful to not rebase a branch you expect people to send you
> >> patches against and sub-maintainers are using to build tree's
> >> against. It sounds like 'next' is tha
On Oct 8, 2008, at 1:51 PM, Matt Sealey wrote:
Grant Likely wrote:
On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey <[EMAIL PROTECTED]>
wrote:
If this patchset is okay with everyone, is it possible that it could
be rushed into 2.6.27 before it hits rc10 or release? :/
no
Shucks :(
At least i
Grant Likely wrote:
On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
If this patchset is okay with everyone, is it possible that it could
be rushed into 2.6.27 before it hits rc10 or release? :/
no
Shucks :(
At least it'll patch cleanly against 2.6.27 though right? It
The RTC is sitting on the I2C1 bus at address 0x68. RTC interrupt signal
is connected to the IPIC's EXT3 interrupt line.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8377_mds.dts |7 +++
arch/powerpc/boot/dts/mpc8378_mds.dts |7 +++
arch/powerpc/
On Oct 8, 2008, at 11:14 AM, Grant Likely wrote:
On Wed, Oct 8, 2008 at 12:20 AM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
On Oct 7, 2008, at 2:00 PM, John Rigby wrote:
The following three patches add pci support for MPC5121
These got no NACKs back in August but they were not picked up
by any
Dominik Bozek wrote:
I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313.
And the major conclusion is that __copy_tofrom_user is more efficient
than memcpy. Sometimes about 40%.
If I good understand, the memcpy() just copy the data, while
__copy_tofrom_user() take care if the
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
drivers/pwm/atmel-pwm.c | 631 +++
1 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/atmel-pwm.c
diff --git a/drivers/pwm/atmel-pwm.c b/drivers/pwm/atmel-pwm.c
new fi
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
drivers/pwm/pwm.c | 667 +
1 files changed, 667 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/pwm.c
diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
new file mode 100644
ind
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
arch/arm/Kconfig |2 +
drivers/Makefile |2 +
drivers/misc/Kconfig |9 -
drivers/misc/Makefile|1 -
drivers/misc/atmel_pwm.c | 409 --
drivers/pwm/Kconfig
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
include/linux/pwm.h | 168 --
1 files changed, 147 insertions(+), 21 deletions(-)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 3945f80..d3d18f7 100644
--- a/include/linux/pwm.h
++
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
Documentation/pwm.txt | 258 +
1 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 Documentation/pwm.txt
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
new file mod
Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]>
---
drivers/leds/Kconfig | 21 --
drivers/leds/Makefile |2 +
drivers/leds/leds-pwm.c| 141
drivers/leds/ledtrig-dim.c | 95 +
include/linux/pwm-led
This series proposes a "generic PWM" driver API.
This proposed API is motivated by the author's need to support
pluggable devices; a secondary objective is to consolidate the
existing PWM implementations behind an agreeable, consistent,
redundancy-reducing interface.
The code included in this pat
Acked-by: Dave Jiang <[EMAIL PROTECTED]>
Kumar Gala wrote:
All other compatibles that are uniquely identifying the processor use
a prefix of the form fsl,mpc85...'. We add support for it so we
can deprecate the older 'fsl,85...' that was inproperly used here.
Additionally added mpc8536 & mpc85
On Wed, Oct 8, 2008 at 6:38 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Oct 7, 2008, at 4:13 PM, John Rigby wrote:
>
>> Uses mpc83xx_add_bridge in fsl_pci.c
>>
>> Adds second register tuple to pci node register property
>> as done for 83xx device trees in a previous patch.
>>
>> Signed-off-by:
On Wed, Oct 8, 2008 at 12:20 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Oct 7, 2008, at 2:00 PM, John Rigby wrote:
>
>> The following three patches add pci support for MPC5121
>> These got no NACKs back in August but they were not picked up
>> by anyone either.
>
> I'll look at picking up pat
Forwarding message to [EMAIL PROTECTED] This is an interesting
question for the wider powerpc community, but not many people read
linuxppc-embedded.
On Wed, Oct 08, 2008 at 04:39:13PM +0200, Dominik Bozek wrote:
> Hi all,
>
> I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313
On Wed, Oct 8, 2008 at 9:29 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> If this patchset is okay with everyone, is it possible that it could
> be rushed into 2.6.27 before it hits rc10 or release? :/
no
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
If this patchset is okay with everyone, is it possible that it could
be rushed into 2.6.27 before it hits rc10 or release? :/
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
John Rigby wrote:
The following three patches add pci support for MPC5121
These got no NACKs back
On Fri, Sep 26, 2008 at 12:19 PM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> The Kconfig files for PowerPC CHRP and PMAC support had "default=y" for some
> Kconfig options, and this caused support for CHRP and PMAC platforms to be
> enabled incorrectly for several platforms. Fix the Kconfigs and the
From: Grant Likely <[EMAIL PROTECTED]>
Compatible property values in the form linux, is not documented
anywhere and using it leaks Linux implementation details into the device
tree data (which is bad). Remove support for compatible values of this
form.
If any platforms exist which depended on th
No, the PowerPC 405s can’t be used as a SMP platform. The 405 caches are not
designed with cache coherency for SMP.
Thanks,
John
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ??
Sent: Wednesday, October 08, 2008 12:49 AM
To: linuxppc-
On Oct 8, 2008, at 8:53 AM, Leon Woestenberg wrote:
I would like these patches to be ported forward to mainline, and I can
put some time in this, but I'ld rather first know what the Freescale
status on the patches is?
John, Stuart, could you please check if there is ongoing work in
Freescale?
Kumar, John,
On Mon, Oct 6, 2008 at 5:09 PM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> On Oct 6, 2008, at 8:42 AM, Leon Woestenberg wrote:
>> can Freescale or any of the powerpc maintainers indicate to what
>> extend PCI Express support for the MPC8315E processor has been merged
>> to Linux mainline
On Oct 7, 2008, at 4:13 PM, John Rigby wrote:
Uses mpc83xx_add_bridge in fsl_pci.c
Adds second register tuple to pci node register property
as done for 83xx device trees in a previous patch.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc5121ads.dts |3 ++-
On Oct 7, 2008, at 2:00 PM, John Rigby wrote:
Modify mpc83xx_add_bridge to get config space register base address
from the device
tree instead of immr + hardcoded offset.
83xx pci nodes have this change:
register properties now contain two address length tuples:
First is the pci b
On Oct 7, 2008, at 2:00 PM, John Rigby wrote:
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS
All other compatibles that are uniquely identifying the processor use
a prefix of the form fsl,mpc85...'. We add support for it so we
can deprecate the older 'fsl,85...' that was inproperly used here.
Additionally added mpc8536 & mpc8560 to the compatible lists.
Signed-off-by: Kumar Gala <[EMAIL
On Oct 8, 2008, at 4:29 AM, Benjamin Herrenschmidt wrote:
Its useful to not rebase a branch you expect people to send you
patches against and sub-maintainers are using to build tree's
against. It sounds like 'next' is that branch.
Indeed. Though so far I've managed to avoid rebasing anythi
On Wed, Oct 08, 2008 at 02:49:14PM +0800,
=?GB2312?B?ItXF6fMiIDx6aGFuZ3lpaGVyZUBnbWFpbC5jb20+?= wrote:
>Hi all,
>
>I am working with a Xilinx Virtex II Pro evaluation board, which has two
>PowerPC 405 and I have ported linux 2.6.24 onto that board when there is one
>PPC405 configured.
>
>I'd like
> > I'll leave you to argue with Linus about that, but since that was the
> > decision back in 2005 (for good C reasons) we can safely rely on it.
>
> `git grep NO_IRQ include arch/*/include' is still quite enlightening...
Good guide to platform code we should delete really
__
On Wed, 8 Oct 2008, Alan Cox wrote:
> On Wed, 08 Oct 2008 09:40:54 +0100
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote:
> > > Zero means no IRQ. Any platform with bits of code left over exposing IRQ
> > > 0 is already not supported by lots of
> Its useful to not rebase a branch you expect people to send you
> patches against and sub-maintainers are using to build tree's
> against. It sounds like 'next' is that branch.
Indeed. Though so far I've managed to avoid rebasing anything :-)
Cheers,
Ben.
___
On Wed, 08 Oct 2008 09:40:54 +0100
David Woodhouse <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote:
> > Zero means no IRQ. Any platform with bits of code left over exposing IRQ
> > 0 is already not supported by lots of driver code including libata.
>
> ...and must i
On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote:
> Zero means no IRQ. Any platform with bits of code left over exposing IRQ
> 0 is already not supported by lots of driver code including libata.
...and must implement some kind of interrupt remapping crap just to work
around this bogus design deci
Michael Neuling <[EMAIL PROTECTED]> wrote on 08.10.2008 08:24:13:
> Elbert,
>
> Just CCing in the ehea maintainers...
>
> Jan-Bernd, Thomas, Christoph: can you help with this query?
>
> Mikey
>
> System log shows a lot of "ehea: Error", see below, during system start
up.
> Not sure what i
Ben, Paul
Please merge or comment on the following patches for 2.6.28. They were
originally posted for 2.6.27 as the merge window was opening and got
lost in the shuffles. I verified they still applied to Ben's next tree
on 10/5, with minor offsets.
powerpc: numa.c: always trim to lmb_end
61 matches
Mail list logo
