From: Joerg Roedel <[EMAIL PROTECTED]>
Date: Fri, 1 Aug 2008 09:03:28 +0200
> That may be the reason that your fix is not yet upstream.
The reason is more-so because Linus simply hasn't merged more
than a couple of patches since 2.6.27-rc1 was released.
___
On Fri, 01 Aug 2008 00:04:17 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Joerg Roedel <[EMAIL PROTECTED]>
> Date: Fri, 1 Aug 2008 09:03:28 +0200
>
> > That may be the reason that your fix is not yet upstream.
>
> The reason is more-so because Linus simply hasn't merged more
> tha
Jon Smirl wrote:
On 7/31/08, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
> As for the source clock, how about creating a new global like
> ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
> right clock value into the variable. For mpc8xxx
Trent Piepho wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
[...snip...]
I don't see why we want to go through the trouble of having uboot tell
us things about a chip that are fixed in stone. Obviously something
like the frequency of the external crystal needs to be passed up, but
why pass up stu
On Fri, Aug 01, 2008 at 08:51:23AM +0900, FUJITA Tomonori wrote:
> On Fri, 1 Aug 2008 09:43:23 +1000
> Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> > This reverts commit 29111f579f4f3f2a07385f931854ab0527ae7ea5.
> >
> > This undoes the hasty addition of a global version of iommu_num_pages()
>
On Thu, Jul 31, 2008 at 04:58:05PM -0500, Kumar Gala wrote:
> I figured out the issue. Its related to the interrupt routing being
> conveyed to the code from the device tree. We have a missing 'space'
> causing issues.
out of interest, is the M5229 attached to a single IRQ in this device
or
On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
[...]
Sorry if my mails were a bit harsh but nobody likes to be pushed around.
[ It is not like I don't want to add proper hot-plugging support or do test
on more hardware but my time schedule is already tight enough and there are
s
On Fri, 01 Aug 2008 14:25:39 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chr
On Fri, 2008-08-01 at 08:06 -0400, Josh Boyer wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > About this whole generic board mumbo-jumbo: not happening. It's a pipe
> > dream, it doesn't work, and it leads to the sort of mess we have in chrp
>
On Aug 1, 2008, at 5:43 AM, Ben Dooks wrote:
On Thu, Jul 31, 2008 at 04:58:05PM -0500, Kumar Gala wrote:
I figured out the issue. Its related to the interrupt routing being
conveyed to the code from the device tree. We have a missing 'space'
causing issues.
out of interest, is the M5229 at
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> The real problem, which kept me from making a patch to do this months ago,
> is that the source clock that the I2C freq divider applies to is different
> for just about every MPC8xxx platform. Not just a different value, b
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> I've having trouble with whether these clocks are a system resource or
> something that belongs to i2c. If they are a system resource then we
> should make nodes in the root and use a phandle in the i2c node to
> link to them.
Hi all,
I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
the latest kernel, and here they are.
There is a difference though. Dale's patches were using
kmap_atomic_pfn() to map oldmem memory, while for this patches
I took PPC64 approach to use ioremap(). This is done to be able
to
This patch removes need for each platform to specify default kexec and
crash kernel ops, thus effectively adds a working kexec support for most
boards.
Platforms that can't cope with default ops will explode in some weird
way, which means that the board's kexec support should be fixed or
blacklist
From: Dale Farnsworth <[EMAIL PROTECTED]>
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This is needed for kexec to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth <[EMAIL PROTE
Default ops are implicit now.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/celleb_setup.c |9 -
arch/powerpc/platforms/cell/setup.c|6 --
arch/powerpc/platforms/embedded6xx/c2k.c |6 --
arch/powerpc/platforms/
From: Dale Farnsworth <[EMAIL PROTECTED]>
Add the ability for a classic ppc kernel to be loaded at an address
of 32MB. This done by fixing a few places that assume we are loaded
at address 0, and by changing several uses of KERNELBASE to use
PAGE_OFFSET, instead.
Signed-off-by: Dale Farnsworth <
While for debugging it is good to catch bogus users of ioremap, but
for kdump support it is more convenient to use ioremap for
copy_oldmem_page() (exactly as we do for PPC64 currently).
The other option is to use kmap_atomic_pfn()*, but it will not work for
kernels compiled without HIGHMEM.
That
From: Dale Farnsworth <[EMAIL PROTECTED]>
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This will be needed for kdump to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth <[EMAIL
From: Dale Farnsworth <[EMAIL PROTECTED]>
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
include/asm-powerpc/kexec.h | 60 --
1 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/includ
From: Dale Farnsworth <[EMAIL PROTECTED]>
Wire up the trampoline code for ppc32 to relay exceptions from the
vectors at address 0 to vectors at address 32MB, and modify Kconfig
to enable Kdump support for all powerpcs (except BookE, for now).
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
Sig
On Aug 1, 2008, at 9:13 AM, Anton Vorontsov wrote:
Hi all,
I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
the latest kernel, and here they are.
There is a difference though. Dale's patches were using
kmap_atomic_pfn() to map oldmem memory, while for this patches
I took PPC6
On 8/1/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > I've having trouble with whether these clocks are a system resource or
> > something that belongs to i2c. If they are a system resource then we
> > should make nodes in
On 8/1/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
> > I've having trouble with whether these clocks are a system resource or
> > something that belongs to i2c. If they are a system resource then we
> > should make nodes in
On Thu, Jul 31, 2008 at 6:46 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> The i2c controller just uses some system clock that was handy. For each
> chip, the designers consult tea leaves to choose a system clock at random
> to connect to the i2c controller.
heh; I thought it was the phase of the
On Fri, Aug 1, 2008 at 1:25 AM, Wolfgang Grandegger <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>>
>> On 7/31/08, Trent Piepho <[EMAIL PROTECTED]> wrote:
>>>
>>> On Thu, 31 Jul 2008, Jon Smirl wrote:
>>> > As for the source clock, how about creating a new global like
>>> > ppc_proc_freq called
On Thu, Jul 31, 2008 at 10:25 PM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> About this whole generic board mumbo-jumbo: not happening. It's a pipe
> dream, it doesn't work, and it leads to the sort of mess we have in chrp
> where we end up having hacks to identify what exact sort of chrp
On Fri, Aug 1, 2008 at 6:06 AM, Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Aug 2008 14:25:39 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
>> About this whole generic board mumbo-jumbo: not happening. It's a pipe
>> dream, it doesn't work, and it leads to the sort of mess we h
On Fri, Aug 01, 2008 at 09:21:02AM -0500, Kumar Gala wrote:
>
> On Aug 1, 2008, at 9:13 AM, Anton Vorontsov wrote:
>
>> Hi all,
>>
>> I refreshed some Dale Farnsworth's kexec/kdump patches[1] against
>> the latest kernel, and here they are.
>>
>> There is a difference though. Dale's patches were us
On Thu, 31 Jul 2008, Trent Piepho wrote:
> The i2c controller just uses some system clock that was handy. For each
> chip, the designers consult tea leaves to choose a system clock at random
> to connect to the i2c controller.
Oh, they decided which clock to choose at design time, not at power-on
Jon Smirl wrote:
What about the Efika which is mpc5200 based and doesn't use uboot?
How does the Efika handle the dozen other properties that U-Boot normally
initializes in the device tree?
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Linu
On Fri, 1 Aug 2008 08:27:41 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> > NOT HAPPENING.
> >
> > Now, there are two approaches here that are possible:
> >
> > - Your board is really pretty much exactly the same as board XXX,
> > except maybe you have a different flash size or such, and the
arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
quite recently.
warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
MTD_NAND_NDFC depends on !PPC_MERGE.
!PPC_MERGE can never be true on PPC now that arch/ppc/ got removed.
So warp-nand.c is dead code, but that does not see
On Fri, 1 Aug 2008 18:14:01 +0300
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
> quite recently.
>
> warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
>
> MTD_NAND_NDFC depends on !PPC_MERGE.
>
> !PPC_MERGE can never be true
Josh Boyer wrote:
On Fri, 1 Aug 2008 18:14:01 +0300
Adrian Bunk <[EMAIL PROTECTED]> wrote:
arch/powerpc/platforms/44x/warp-nand.c was added this year and updated
quite recently.
warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
MTD_NAND_NDFC depends on !PPC_MERGE.
!PPC_MERGE can never be
On Fri, 1 Aug 2008 18:14:01 +0300
"Adrian Bunk" <[EMAIL PROTECTED]> wrote:
> arch/powerpc/platforms/44x/warp-nand.c was added this year and
> updated quite recently.
>
> warp-nand.c is empty unless CONFIG_MTD_NAND_NDFC=y.
>
> MTD_NAND_NDFC depends on !PPC_MERGE.
>
> !PPC_MERGE can never be true
On Fri, Aug 01, 2008 at 08:17:25AM -0500, Timur Tabi wrote:
> On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
> > Sometimes the two i2c controllers don't even
> > have the same clock.
>
> On which platform is that the case? I thought I had all 8[356]xx
> boards covered.
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
and include/asm-powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig.debug |2 +-
arch/powerpc/kernel/Makefile
On Fri, 1 Aug 2008 11:26:28 -0400
"Josh Boyer" <[EMAIL PROTECTED]> wrote:
> I don't believe it is intentional, no. Sean can you look at this and
> see what's up? I have a couple of fixes to queue up from you already
> and if you can get this one done in the next few days I'll included it
> as we
I'm trying to get the compact flash up and running on an mpc8349eITX,
and am continually running into issues where the IRQ is not processed,
and the mmio commands are not getting response. At this point, I am
starting to suspect a HW issue, but I was hoping to verify that I am
using a known good ke
I'd float a radical definition of 'compatible' here.
If the generic code can handle it with just changes to the device
tree, then it is compatible. And by generic code, I wouldn't suggest
a twisty maze of ifdefs or special case hacks. I'm talking truly
generic code that is table driven entirely
On 8/1/08, Timur Tabi <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
>
>
> > What about the Efika which is mpc5200 based and doesn't use uboot?
> >
>
> How does the Efika handle the dozen other properties that U-Boot normally
> initializes in the device tree?
Efika is like the original OpenFirmwar
Tony Breeds wrote:
> On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
>> Hi Andrew,
>>
>> make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with build
>> error
>
>
>
> Turning off GCOV "fixes" this. Not really the best solution but at
> least it narrows doen the se
On Fri, Aug 1, 2008 at 10:01 AM, M. Warner Losh <[EMAIL PROTECTED]> wrote:
> I'd float a radical definition of 'compatible' here.
>
> If the generic code can handle it with just changes to the device
> tree, then it is compatible. And by generic code, I wouldn't suggest
> a twisty maze of ifdefs o
On Fri, Aug 1, 2008 at 9:50 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
> remove the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
> and include/asm-powerpc.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
You nee
On Aug 1, 2008, at 11:30 AM, Grant Likely wrote:
On Fri, Aug 1, 2008 at 9:50 AM, Kumar Gala
<[EMAIL PROTECTED]> wrote:
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE out of arch/
powerpc
and include/asm-powerpc.
Signe
This set of patches remove Kconfig and code related to CONFIG_PPC_MERGE
and !CONFIG_PPC_MERGE. There is some discussion about that one last
use of !PPC_MERGE with respect to the 4xx MTD_NAND_NDFC driver.
Paul, is this something you'd be willing to entertain for 2.6.27?
- k
__
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
and include/asm-powerpc.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig.debug |2 +-
arch/powerpc/kernel/Makefile
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
the dead code associated with !CONFIG_PPC_MERGE.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-hcd.c |5 -
drivers/usb/host/ehci-ppc-soc.c | 201 ---
driv
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms so we don't need to depend on it.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |2 +-
drivers/net/ibm_newemac/Kconfig |2 +-
2 files changed, 2 insertions(+), 2 dele
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
the dead code associated with !CONFIG_PPC_MERGE.
With this change the pre_request_irq() and post_free_irq() calls became
nops so they have been removed.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/f
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/serial/mpc52xx_uart.c | 181 +
1 files changed, 1 insertions(+), 180 deletion
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of it use CONFIG_PPC instead.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/rtc/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/K
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/spi/mpc52xx_psc_spi.c | 55 -
1 files changed, 0 insertions(+), 55 deletions
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of CONFIG_PPC_MERGE use
CONFIG_PPC instead.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/block/floppy.c |2 +-
drivers/char/ipmi/ipmi_si_intf.c |2 +-
drive
On Fri, Aug 01, 2008 at 10:58:58AM -0500, Sparks, Sam wrote:
> I'm trying to get the compact flash up and running on an mpc8349eITX,
> and am continually running into issues where the IRQ is not processed,
> and the mmio commands are not getting response. At this point, I am
> starting to suspect a
>
> Am not terribly happy with the state of the gcov patches. They STILL
> leave thousands of dead symlinks lying around after `make mrproper' and
> generally seem to muck up the kbuild system a bit, although nothing
> that a bit of Sam love wouldn't fix.
Have not had time / energy to get aroud
>From: Anton Vorontsov
>Sent: Friday, August 01, 2008 11:51 AM
>
>Works like a charm here. I use quite outdated u-boot though. Which one
>you use? I could try it (if it is community u-boot).
I'm using the head, which I grabbed last week: U-Boot
1.3.4-rc1-00012-g1953d12
TIA for checking your itx wi
On Fri, 2008-08-01 at 11:44 -0500, Kumar Gala wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
> remove the dead code associated with !CONFIG_PPC_MERGE.
>
> The mtd maps should be using the OF based mechanism.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: J
On Fri, Aug 01, 2008 at 12:36:39PM -0500, Sparks, Sam wrote:
> >From: Anton Vorontsov
> >Sent: Friday, August 01, 2008 11:51 AM
> >
> >Works like a charm here. I use quite outdated u-boot though. Which one
> >you use? I could try it (if it is community u-boot).
>
> I'm using the head, which I grab
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all
powerpc platforms and we want to get rid of CONFIG_PPC_MERGE use
CONFIG_PPC instead.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/ata/pata_sil680.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff -
Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore
remove the dead code associated with !CONFIG_PPC_MERGE.
The mtd maps should be using the OF based mechanism.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/mtd/maps/Kconfig | 24 ---
drivers/mtd/maps/Makefile |
On Fri, Aug 01, 2008 at 06:14:20PM +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <[EMAIL PROTECTED]>
>
> Add the ability for a classic ppc kernel to be loaded at an address
> of 32MB. This done by fixing a few places that assume we are loaded
> at address 0, and by changing several uses o
On Fri, Aug 01, 2008 at 11:44:13AM -0500, Kumar Gala wrote:
> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c
> index 9a51ec8..e54d003 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -669,7 +669,6 @@ static in
On Fri, 1 Aug 2008, Timur Tabi wrote:
> On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho <[EMAIL PROTECTED]> wrote:
>
> > The real problem, which kept me from making a patch to do this months ago,
> > is that the source clock that the I2C freq divider applies to is different
> > for just about every M
Trent Piepho wrote:
> All 83xx other than 832x.
Never mind, I forgot that 83xx support for i2c1_clk was already in U-Boot:
#if defined(CONFIG_MPC834X)
i2c1_clk = tsec2_clk;
#elif defined(CONFIG_MPC8360)
i2c1_clk = csb_clk;
#elif defined(CONFIG_MPC832X)
i2c1_clk = enc_clk;
Patch 1 is version 4 of the SPU mutex lock fix.
Patch 2 is a patch to fix an issue found in OProfile while implementing
version 4 of the SPU mutex lock fix.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linux
Version 4 of the SPU mutex lock fix.
The issue is the SPU code is not holding the kernel mutex lock while
adding samples to the kernel buffer.
This patch creates per SPU buffers to hold the data. Data
is added to the buffers from in interrupt context. The data
is periodically pushed to the kern
If an error occurs on opcontrol start, the event and per cpu buffers
are released. If later opcontrol shutdown is called then the free
function will be called again to free buffers that no longer
exist. This results in a kernel oops. The following changes
prevent the call to delete buffers th
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 214388e..20180bf 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/po
On Fri, Aug 01, 2008 at 01:49:52PM -0500, Scott Wood wrote:
> On Fri, Aug 01, 2008 at 06:14:20PM +0400, Anton Vorontsov wrote:
> > From: Dale Farnsworth <[EMAIL PROTECTED]>
> >
> > Add the ability for a classic ppc kernel to be loaded at an address
> > of 32MB. This done by fixing a few places th
On Fri, 1 Aug 2008, Jon Smirl wrote:
> I don't like the third choice. Keep a simple Linux driver for i2c and
> the platform, and then move all of the messy code into uboot. BTW,
> the messy code is about 10 lines. It's going to take more than 10
> lines to hide those 10 lines.
It's not being _mov
On Fri, 2008-08-01 at 12:54 +0200, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 31 July 2008, Bartlomiej Zolnierkiewicz wrote:
>
> [...]
>
> Sorry if my mails were a bit harsh but nobody likes to be pushed around.
>
> [ It is not like I don't want to add proper hot-plugging support or do test
> This is sort of the part that sucks. Look at 44x. There are 10
> board.c files there. There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create
On Fri, 2008-08-01 at 08:27 -0600, Grant Likely wrote:
>
> I agree with most of your argument, except I really have problems with
> boards claiming compatibility with an older board. My reason is
> exactly the reason you state; One day you'll figure out that there is
> indeed a difference. The p
Kumar Gala writes:
> This set of patches remove Kconfig and code related to CONFIG_PPC_MERGE
> and !CONFIG_PPC_MERGE. There is some discussion about that one last
> use of !PPC_MERGE with respect to the 4xx MTD_NAND_NDFC driver.
>
> Paul, is this something you'd be willing to entertain for 2.6.2
On Sat, 02 Aug 2008 08:48:23 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > This is sort of the part that sucks. Look at 44x. There are 10
> > board.c files there. There really only needs to be 3 or 4 (sam440ep,
> > warp, virtex, and "generic") because the board files are identi
On Fri, 2008-08-01 at 11:44 -0500, Kumar Gala wrote:
> Now that arch/ppc is gone we don't need CONFIG_PPC_MERGE anymore remove
> the dead code associated with !CONFIG_PPC_MERGE out of arch/powerpc
> and include/asm-powerpc.
...
> diff --git a/include/asm-powerpc/irq.h b/include/asm-powerpc/irq.h
>
Andrew Morton <[EMAIL PROTECTED]> wrote on 01.08.2008 08:12:06:
> On Fri, 1 Aug 2008 15:29:36 +1000 Tony Breeds <[EMAIL PROTECTED]>
wrote:
> > On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> > > Hi Andrew,
> > >
> > > make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fai
Tony Breeds <[EMAIL PROTECTED]> wrote on 01.08.2008 07:29:36:
> On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> > Hi Andrew,
> >
> > make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with
> build error
>
>
>
> Turning off GCOV "fixes" this. Not really the best
This is a port of the ndfc driver from arch/ppc to arch/powerpc. Since
arch/ppc has been removed, references to CONFIG_PPC_MERGE where removed.
For an example of how to use the driver see
arch/powerpc/platforms/44x/warp-nand.c .
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/d
For those who are interested, I have posted a patch for the ndfc
driver. This is the driver we use un-bogusitize the warp-nand ;)
I removed the CONFIG_PPC_MERGE defines, but other than that this is the
driver we use in production.
Stefan: This has the byte order reversing that I believe you where
82 matches
Mail list logo
