Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
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 fails with build error snip Turning off GCOV fixes this. Not really the best solution but at least it narrows doen the search effort. Thanks. Peter, Can you have a look at how this can be fixed, if at all? 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. Plus it breaks the build on a few architectures (branch out of range, mainly), but that's a fairly minor thing which could even be worked around in Kconfig (disable the offending code if gcov is enabled) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
On Fri, Aug 01, 2008 at 12:37:25AM -0400, Jon Smirl wrote: On 8/1/08, David Gibson [EMAIL PROTECTED] wrote: On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote: On 7/31/08, David Gibson [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote: On 7/31/08, David Gibson [EMAIL PROTECTED] wrote: [snip] Why does the fake fabric device need to be in the device tree? Can't we just dynamically create it as part of the boot process? Um.. yes.. that would be exactly what instantiating it from the platform code does. Platform devices are missing the compatible chain process. If we do this with platform drivers the boot code creates a 'fabric' device then I'll have to ensure that my board-fabric driver gets probed before default-fabric because they both want to bind to the fabric device. If you need a board-specific fabric driver, the board platform code shouldn't be instantiating the generic fabric driver. Given the board specific driver a different name... -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Revert Merge branch 'x86/iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip into for-linus
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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Revert Merge branch 'x86/iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip into for-linus
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 than a couple of patches since 2.6.27-rc1 was released. Yeah, I think so. I'll send the patch to Linus if necessary. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 mpc8 get it from uboot.
mpc5200 can easily compute it from ppc_proc_freq and checking how the
ipb divider is set. That will move the clock problem out of the i2c
driver.
There is a huge variation in where the I2C source clock comes from.
Sometimes it's the system bus, sometimes ethernet, sometimes SEC, etc. If
I look at u-boot (which might not be entirely correct or complete), I see:
83xx: 5 different clock sources
85xx: 3 different clock sources
86xx: 2 different clock sources
But there's more. Sometimes the two I2C controllers don't use the same
clock! So even if you add 10 globals with different clocks, and then add
code to the mpc i2c driver so if can figure out which one to use given the
platform, it's still not enough because you need to know which controller
the device node is for.
IMHO, what Timur suggested of having u-boot put the source clock into the
i2c node makes the most sense. U-boot has to figure this out, so why
duplicate the work?
Here's my idea:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
bus-frequency = 10;
/* Either */
source-clock-frequency = 0;
/* OR */
source-clock = ccb;
};
Can't we hide a lot of this on platforms where the source clock is not
messed up? For example the mpc5200 doesn't need any of this, the
needed frequency is already available in mpc52xx_find_ipb_freq().
mpc5200 doesn't need any uboot change.
Next would be normal mpc8xxx platforms where i2c is driven by a single
clock, add a uboot filled in parameter in the root node (or I think it
can be computed off of the ones uboot is already filling in). make a
mpc8xxx_find_i2c_freq() function. May not need to change device tree
and uboot.
Finally use this for those days when the tea leaves were especially
bad. Both a device tree and uboot change.
Except the i2c clock isn't always a based on an integer divider of the CCB
frequency. What's more, it's not always the same for both i2c controllers.
Suppose i2c #1 uses CCB times 2/3 and i2c #2 uses CCB/2, how would
fsl_get_i2c_freq() figure that out from bus-frequency and
i2c-clock-divider?
If you get the CCB frequency from uboot and know the chip model, can't
you compute these in the platform code? Then make a
mpc8xxx_find_i2c_freq(cell_index).
We can, of course, but do we want to? #ifdef's are not acceptable for
Linux which means scanning the model property to get the divider from
some table. And when a new MPC model shows up, we need to update the
table. This can all be saved and avoided by adding a I2C clock source
divider or frequency property to the FDT. The FDT is to describe the
hardware and the fixed divider value is a property of it.
I'm in favor of a I2C node specific divider property because it does
not rely on a boot-loader filling in the real value. It's fixed for a
certain MPC model. And the I2C source clock frequency is then just:
fsl_get_sys_freq() / divider.
I'm quite sure that work for all MPCs, but at least for the one covered
by the i2c-mpc driver.
Furthermore, mpc52xx_find_ipb_freq() does the same as
fsl_get_sys_freq(). It looks up the value for the property
bus-frequency of the soc. We don't need a mpc8xxx_find_i2c_freq() but
a common fsl_get_i2c_freq() for all MPCs.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 stuff that can be computed (or recovered by reading a register)? One could also say that if U-boot has to have the code and already calculated the value, why duplicate the code and the calculation in Linux? Right, if the bus-frequency property for the I2C device is not defined, the Linux I2C bus driver should just overtake the pre-defined values. That's what I (we?) wanted to implement anyhow. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Revert Merge branch 'x86/iommu' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip into for-linus
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() that broke both the powerpc and sparc builds. This function can be revisited later. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/x86/kernel/amd_iommu.c | 13 - arch/x86/kernel/pci-gart_64.c | 11 +++ include/linux/iommu-helper.h |1 - lib/iommu-helper.c|8 4 files changed, 15 insertions(+), 18 deletions(-) This patch comes from git revert -m 1 29111f579f4f3f2a07385f931854ab0527ae7ea5 I have test built powerpc ppc64_defconfig and sparc64 defconfig. The only references to iommu_num_pages() after this is applied are in the powerpc and sparc code. Linus, please apply. This is impacting on both powerpc and sparc development and even the author of the patches said that those patches were not urgent. Ingo has a patch to fix this problem in the x86 tree: http://marc.info/?l=linux-kernelm=121754062325903w=2 FUJITA, can you send your fix directly to Linus again please? Andrew mentioned that the x86 maintainers are on vacation. That may be the reason that your fix is not yet upstream. Joerg -- | AMD Saxony Limited Liability Company Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System| Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center| AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libata badness
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 has the bridge been configured to route the IRQs from the IDE to the same pin on the PIC? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ide pmac breakage
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
still more fundamental things to address (which take priority). ]
-host-dev[0] = hws[0]-dev;
+host-dev[0] = hws[0]-parent ? hws[0]-parent : hws[0]-dev;
Could you please try it together with my previous patch for
ide_device_{get,put}()?
Please test it when you have some time.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 chrp we have and do things differently etc... 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 support for board XXX can cope perfectly with it simply due to the device-tree the right information. If that happens to be the case, make your board compatible with board XXX. Make that entry -second- in your compatible list, because one day you'll figure out that there -is- indeed a difference and I don't want to see board XXX code start to grow code to recognise your other board and work around the difference. So at that stage, copy board XXX.c file and start over with your own board support that matches on your first compatible propery entry. 44x does this today for a small number of boards. The issue, if there really is one, is that there's no clear definition on what is acceptable to be called compatible. If _Linux_ platform support for board FOO - Once you figure out that really, those 5 boards here -do- share 99% of the code... it's just that one need a workaround at the IRQ fixup level, maybe one needs a tweak on a GPIO at boot and one has an issue on reboot that needs to be whacked a bit differently ... well, make -library- code. I have no objection of having something like for each ppc_md field called X, having a utility file providing an mpc52xx_generic_X function. Such a board could then basically have a small .c file whose ppc_md just use the generic functions for all except the ones that need to be hooked/wrapped/replaced/whatever. 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 a board.c file for a new board and plug in the library functions to ppc_md. Alternatively, you could do the: compatible = specific-board, similar-board approach that has been done for e.g. Bamboo and Yosemite. Again, the issue is that is that OK? Is it OK for a board to claim compatibility with another board when it might not have all the devices of that board, or might have additional devices, etc. I was of the opinion it is, and the device tree handles this just fine, as does the platform code. But it can be confusing, hence the discussion here. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 where we end up having hacks to identify what exact sort of chrp we have and do things differently etc... 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 support for board XXX can cope perfectly with it simply due to the device-tree the right information. If that happens to be the case, make your board compatible with board XXX. Make that entry -second- in your compatible list, because one day you'll figure out that there -is- indeed a difference and I don't want to see board XXX code start to grow code to recognise your other board and work around the difference. So at that stage, copy board XXX.c file and start over with your own board support that matches on your first compatible propery entry. 44x does this today for a small number of boards. The issue, if there really is one, is that there's no clear definition on what is acceptable to be called compatible. If _Linux_ platform support for board FOO Ignore that last line. Emailing before coffee is considered dangerous. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libata badness
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 attached to a single IRQ in this device or has the bridge been configured to route the IRQs from the IDE to the same pin on the PIC? The bridge is routing interrupts via an i8259 to a single interrupt on the OpenPIC (primary pic). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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, but a totally different internal clock. Sometimes is CCB, sometimes CCB/2, sometimes tsec2's clock, etc. On which SOC is it the tesc2 clock? 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. Did I miss some? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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. I can't speak for 52xx, but for 8[356]xx, I would say the clocks belong to the I2C devices. The screwball determination of whether to divide by 1, 2, or 3 only applies to the I2C device only. The divider itself is not used to drive a clock for any other device. If you disable I2C support, then you don't need to care about the divider (or its output clock) at all. That's why I think have the I2C clock in the parent node is wrong, because it would only be used if you had I2C child nodes. If you didn't have any I2C nodes, then you would need to delete the property from the parent node as well. The phandle in the mpc5200 case could be implicit since it is fixed in silicon. If we want to use the same I2C driver for 52xx and 83xx, it shouldn't be implicit. Otherwise, the driver will have to check the platform to determine where to look. Is this register in a system register bank or an i2c one? gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG That should be guts- I think. The global utilities is a block of miscellaneous registers, one per SOC. It's not part of the I2C block. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH 0/8] kexec/kdump support for ppc32
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 support kdump on !HIGHMEM kernels. Also, please take a special look into 8/8 patch, there is a hunk marked with XXX:, which I don't quite understand for PPC64 case (this hunk also persist in the original Dale's patch, and w/o it the capturing kernel doesn't boot on ppc32). I'll try to refresh BookE support as soon as I'll find some BookE board. The patchset includes: - Kexec support [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments 2/8 and 3/8 patches are used to avoid adding lots of default ops to the board files. - Kdump support [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32 [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32 [PATCH 8/8] powerpc: last bits to support kdump on ppc32 [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit
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
blacklisted via dummy _prepare callback returning -ENOSYS.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/kernel/machine_kexec.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index a625673..ac42cfb 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -22,6 +22,8 @@ void machine_crash_shutdown(struct pt_regs *regs)
{
if (ppc_md.machine_crash_shutdown)
ppc_md.machine_crash_shutdown(regs);
+ else
+ return default_machine_crash_shutdown(regs);
}
/*
@@ -33,11 +35,8 @@ int machine_kexec_prepare(struct kimage *image)
{
if (ppc_md.machine_kexec_prepare)
return ppc_md.machine_kexec_prepare(image);
- /*
-* Fail if platform doesn't provide its own machine_kexec_prepare
-* implementation.
-*/
- return -ENOSYS;
+ else
+ return default_machine_kexec_prepare(image);
}
void machine_kexec_cleanup(struct kimage *image)
@@ -54,13 +53,10 @@ void machine_kexec(struct kimage *image)
{
if (ppc_md.machine_kexec)
ppc_md.machine_kexec(image);
- else {
- /*
-* Fall back to normal restart if platform doesn't provide
-* its own kexec function, and user insist to kexec...
-*/
- machine_restart(NULL);
- }
+ else
+ default_machine_kexec(image);
+ /* Fall back to normal restart if we're still alive. */
+ machine_restart(NULL);
for(;;);
}
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
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 PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/kernel/machine_kexec.c| 27 +++
arch/powerpc/kernel/machine_kexec_64.c | 20 +---
2 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index aab7688..a625673 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -13,8 +13,10 @@
#include linux/reboot.h
#include linux/threads.h
#include linux/lmb.h
+#include linux/of.h
#include asm/machdep.h
#include asm/prom.h
+#include asm/sections.h
void machine_crash_shutdown(struct pt_regs *regs)
{
@@ -116,3 +118,28 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
{
return (start + size) crashk_res.start start = crashk_res.end;
}
+
+/* Values we need to export to the second kernel via the device tree. */
+static unsigned long kernel_end;
+
+static struct property kernel_end_prop = {
+ .name = linux,kernel-end,
+ .length = sizeof(unsigned long),
+ .value = kernel_end,
+};
+
+static int __init kexec_setup(void)
+{
+ struct device_node *node;
+
+ node = of_find_node_by_path(/chosen);
+ if (!node)
+ return -ENOENT;
+
+ kernel_end = __pa(_end);
+ prom_add_property(node, kernel_end_prop);
+
+ of_node_put(node);
+ return 0;
+}
+__initcall(kexec_setup);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index a168514..c30678d 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -289,7 +289,7 @@ void default_machine_kexec(struct kimage *image)
}
/* Values we need to export to the second kernel via the device tree. */
-static unsigned long htab_base, kernel_end;
+static unsigned long htab_base;
static struct property htab_base_prop = {
.name = linux,htab-base,
@@ -303,32 +303,22 @@ static struct property htab_size_prop = {
.value = htab_size_bytes,
};
-static struct property kernel_end_prop = {
- .name = linux,kernel-end,
- .length = sizeof(unsigned long),
- .value = kernel_end,
-};
-
static void __init export_htab_values(void)
{
struct device_node *node;
+ /* On machines with no htab htab_address is NULL */
+ if (NULL == htab_address)
+ return;
+
node = of_find_node_by_path(/chosen);
if (!node)
return;
- kernel_end = __pa(_end);
- prom_add_property(node, kernel_end_prop);
-
- /* On machines with no htab htab_address is NULL */
- if (NULL == htab_address)
- goto out;
-
htab_base = __pa(htab_address);
prom_add_property(node, htab_base_prop);
prom_add_property(node, htab_size_prop);
- out:
of_node_put(node);
}
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments
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/embedded6xx/prpmc2800.c |6 --
arch/powerpc/platforms/maple/setup.c |6 --
arch/powerpc/platforms/powermac/setup.c|6 --
arch/powerpc/platforms/ps3/setup.c |4
7 files changed, 0 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c
b/arch/powerpc/platforms/cell/celleb_setup.c
index b11cb30..07c234f 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -45,7 +45,6 @@
#include asm/mmu.h
#include asm/processor.h
#include asm/io.h
-#include asm/kexec.h
#include asm/prom.h
#include asm/machdep.h
#include asm/cputable.h
@@ -226,9 +225,6 @@ define_machine(celleb_beat) {
.pci_setup_phb = celleb_setup_phb,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = beat_kexec_cpu_down,
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
@@ -248,9 +244,4 @@ define_machine(celleb_native) {
.pci_probe_mode = celleb_pci_probe_mode,
.pci_setup_phb = celleb_setup_phb,
.init_IRQ = celleb_init_IRQ_native,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index ab721b5..5930536 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -35,7 +35,6 @@
#include asm/mmu.h
#include asm/processor.h
#include asm/io.h
-#include asm/kexec.h
#include asm/pgtable.h
#include asm/prom.h
#include asm/rtas.h
@@ -289,9 +288,4 @@ define_machine(cell) {
.progress = cell_progress,
.init_IRQ = cell_init_irq,
.pci_setup_phb = cell_setup_phb,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/c2k.c
b/arch/powerpc/platforms/embedded6xx/c2k.c
index d0b25b8..19d3bc4 100644
--- a/arch/powerpc/platforms/embedded6xx/c2k.c
+++ b/arch/powerpc/platforms/embedded6xx/c2k.c
@@ -20,7 +20,6 @@
#include linux/seq_file.h
#include linux/time.h
#include linux/of.h
-#include linux/kexec.h
#include asm/machdep.h
#include asm/prom.h
@@ -150,9 +149,4 @@ define_machine(c2k) {
.get_irq= mv64x60_get_irq,
.restart= c2k_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 5a19b9a..e40b5a8 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -19,7 +19,6 @@
#include asm/prom.h
#include asm/system.h
#include asm/time.h
-#include asm/kexec.h
#include mm/mmu_decl.h
@@ -158,9 +157,4 @@ define_machine(prpmc2800){
.get_irq= mv64x60_get_irq,
.restart= prpmc2800_restart,
.calibrate_decr = generic_calibrate_decr,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index 3647147..1be9b7c 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -51,7 +51,6 @@
#include asm/system.h
#include asm/pgtable.h
#include asm/io.h
-#include asm/kexec.h
#include asm/pci-bridge.h
#include asm/iommu.h
#include asm/machdep.h
@@ -336,9 +335,4 @@ define_machine(maple) {
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
.power_save = power4_idle,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
-#endif
};
[PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
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 [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/kernel/head_32.S | 11 ++-
arch/powerpc/mm/init_32.c |2 +-
arch/powerpc/mm/pgtable_32.c |4 ++--
arch/powerpc/mm/ppc_mmu_32.c |8
include/asm-powerpc/ppc_asm.h |4 ++--
5 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 99ee2f0..45e612b 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -176,7 +176,8 @@ __after_mmu_off:
bl reloc_offset
mr r26,r3
addis r4,r3,[EMAIL PROTECTED] /* current address of _start */
- cmpwi 0,r4,0 /* are we already running at 0? */
+ lis r5,[EMAIL PROTECTED]
+ cmplw 0,r4,r5 /* already running at PHYSICAL_START? */
bne relocate_kernel
/*
* we now have the 1st 16M of ram mapped with the bats.
@@ -804,13 +805,13 @@ giveup_altivec:
/*
* This code is jumped to from the startup code to copy
- * the kernel image to physical address 0.
+ * the kernel image to physical address PHYSICAL_START.
*/
relocate_kernel:
addis r9,r26,[EMAIL PROTECTED]/* fetch klimit */
lwz r25,[EMAIL PROTECTED](r9)
addis r25,r25,[EMAIL PROTECTED]
- li r3,0/* Destination base address */
+ lis r3,[EMAIL PROTECTED]/* Destination base address */
li r6,0/* Destination offset */
li r5,0x4000 /* # bytes of memory to copy */
bl copy_and_flush /* copy the first 0x4000 bytes */
@@ -1172,11 +1173,11 @@ mmu_off:
/*
* Use the first pair of BAT registers to map the 1st 16MB
- * of RAM to KERNELBASE. From this point on we can't safely
+ * of RAM to PAGE_OFFSET. From this point on we can't safely
* call OF any more.
*/
initial_bats:
- lis r11,[EMAIL PROTECTED]
+ lis r11,[EMAIL PROTECTED]
mfspr r9,SPRN_PVR
rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */
cmpwi 0,r9,1
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 388ceda..4ac0e4e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -49,7 +49,7 @@
#if defined(CONFIG_KERNEL_START_BOOL) || defined(CONFIG_LOWMEM_SIZE_BOOL)
/* The ammount of lowmem must be within 0xF000 - KERNELBASE. */
-#if (CONFIG_LOWMEM_SIZE (0xF000 - KERNELBASE))
+#if (CONFIG_LOWMEM_SIZE (0xF000 - PAGE_OFFSET))
#error You must adjust CONFIG_LOWMEM_SIZE or CONFIG_START_KERNEL
#endif
#endif
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 2001abd..ea50968 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -288,7 +288,7 @@ int map_page(unsigned long va, phys_addr_t pa, int flags)
}
/*
- * Map in all of physical memory starting at KERNELBASE.
+ * Map in all of physical memory starting at PAGE_OFFSET.
*/
void __init mapin_ram(void)
{
@@ -297,7 +297,7 @@ void __init mapin_ram(void)
int ktext;
s = mmu_mapin_ram();
- v = KERNELBASE + s;
+ v = PAGE_OFFSET + s;
p = memstart_addr + s;
for (; s total_lowmem; s += PAGE_SIZE) {
ktext = ((char *) v = _stext (char *) v etext);
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..7c86103 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -95,16 +95,16 @@ unsigned long __init mmu_mapin_ram(void)
break;
}
- setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[2].limit - KERNELBASE + 1;
+ setbat(2, PAGE_OFFSET, 0, bl, _PAGE_RAM);
+ done = (unsigned long)bat_addrs[2].limit - PAGE_OFFSET + 1;
if ((done tot) !bat_addrs[3].limit) {
/* use BAT3 to cover a bit more */
tot -= done;
for (bl = 12810; bl max_size; bl = 1)
if (bl * 2 tot)
break;
- setbat(3, KERNELBASE+done, done, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[3].limit - KERNELBASE + 1;
+ setbat(3, PAGE_OFFSET+done, done, bl, _PAGE_RAM);
+ done = (unsigned long)bat_addrs[3].limit - PAGE_OFFSET + 1;
}
return done;
diff --git a/include/asm-powerpc/ppc_asm.h b/include/asm-powerpc/ppc_asm.h
index 0966899..d0c7f33 100644
--- a/include/asm-powerpc/ppc_asm.h
+++ b/include/asm-powerpc/ppc_asm.h
@@ -425,14 +425,14 @@
[PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32
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 is, on a board with 256MB RAM and [EMAIL PROTECTED] case, the !HIGHMEM capturing kernel maps 0-96M range, which does not include all the memory needed to capture the dump. And obviously accessing anything upper than 96M will cause faults. * http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046747.html Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- arch/powerpc/mm/pgtable_32.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index ea50968..3e69b0d 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -194,6 +194,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags) if (p 16*1024*1024) p += _ISA_MEM_BASE; +#ifndef CONFIG_CRASH_DUMP /* * Don't allow anybody to remap normal RAM that we're using. * mem_init() sets high_memory so only do the check after that. @@ -203,6 +204,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags) (unsigned long long)p, __builtin_return_address(0)); return NULL; } +#endif if (size == 0) return NULL; -- 1.5.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
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 PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/kernel/machine_kexec.c| 38
arch/powerpc/kernel/machine_kexec_64.c | 43
2 files changed, 38 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index ac42cfb..bfef717 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long
size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_size;
static struct property kernel_end_prop = {
.name = linux,kernel-end,
@@ -124,6 +125,41 @@ static struct property kernel_end_prop = {
.value = kernel_end,
};
+static struct property crashk_base_prop = {
+ .name = linux,crashkernel-base,
+ .length = sizeof(unsigned long),
+ .value = crashk_res.start,
+};
+
+static struct property crashk_size_prop = {
+ .name = linux,crashkernel-size,
+ .length = sizeof(unsigned long),
+ .value = crashk_size,
+};
+
+static void __init export_crashk_values(struct device_node *node)
+{
+ struct property *prop;
+
+ /* There might be existing crash kernel properties, but we can't
+* be sure what's in them, so remove them. */
+ prop = of_find_property(node, linux,crashkernel-base, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, linux,crashkernel-size, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ if (crashk_res.start != 0) {
+ prom_add_property(node, crashk_base_prop);
+ crashk_size = crashk_res.end - crashk_res.start + 1;
+ prom_add_property(node, crashk_size_prop);
+ }
+
+ of_node_put(node);
+}
+
static int __init kexec_setup(void)
{
struct device_node *node;
@@ -135,6 +171,8 @@ static int __init kexec_setup(void)
kernel_end = __pa(_end);
prom_add_property(node, kernel_end_prop);
+ export_crashk_values(node);
+
of_node_put(node);
return 0;
}
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index c30678d..2aab296 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -322,52 +322,9 @@ static void __init export_htab_values(void)
of_node_put(node);
}
-static struct property crashk_base_prop = {
- .name = linux,crashkernel-base,
- .length = sizeof(unsigned long),
- .value = crashk_res.start,
-};
-
-static unsigned long crashk_size;
-
-static struct property crashk_size_prop = {
- .name = linux,crashkernel-size,
- .length = sizeof(unsigned long),
- .value = crashk_size,
-};
-
-static void __init export_crashk_values(void)
-{
- struct device_node *node;
- struct property *prop;
-
- node = of_find_node_by_path(/chosen);
- if (!node)
- return;
-
- /* There might be existing crash kernel properties, but we can't
-* be sure what's in them, so remove them. */
- prop = of_find_property(node, linux,crashkernel-base, NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- prop = of_find_property(node, linux,crashkernel-size, NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- if (crashk_res.start != 0) {
- prom_add_property(node, crashk_base_prop);
- crashk_size = crashk_res.end - crashk_res.start + 1;
- prom_add_property(node, crashk_size_prop);
- }
-
- of_node_put(node);
-}
-
static int __init kexec_setup(void)
{
export_htab_values();
- export_crashk_values();
return 0;
}
__initcall(kexec_setup);
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
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/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index acdcdc6..9ecc307 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -38,7 +38,6 @@ typedef void (*crash_shutdown_t)(void);
#ifdef CONFIG_KEXEC
-#ifdef __powerpc64__
/*
* This function is responsible for capturing register states if coming
* via panic or invoking dump using sysrq-trigger.
@@ -51,6 +50,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
else {
/* FIXME Merge this with xmon_save_regs ?? */
unsigned long tmp1, tmp2;
+#ifdef __powerpc64__
__asm__ __volatile__ (
std0,0(%2)\n
std1,8(%2)\n
@@ -99,16 +99,58 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
: =r (tmp1), =r (tmp2)
: b (newregs)
: memory);
+#else /* __powerpc64__ */
+ __asm__ __volatile__ (
+ stw0,0(%2)\n
+ stw1,4(%2)\n
+ stw2,8(%2)\n
+ stw3,12(%2)\n
+ stw4,16(%2)\n
+ stw5,20(%2)\n
+ stw6,24(%2)\n
+ stw7,28(%2)\n
+ stw8,32(%2)\n
+ stw9,36(%2)\n
+ stw10,40(%2)\n
+ stw11,44(%2)\n
+ stw12,48(%2)\n
+ stw13,52(%2)\n
+ stw14,56(%2)\n
+ stw15,60(%2)\n
+ stw16,64(%2)\n
+ stw17,68(%2)\n
+ stw18,72(%2)\n
+ stw19,76(%2)\n
+ stw20,80(%2)\n
+ stw21,84(%2)\n
+ stw22,88(%2)\n
+ stw23,92(%2)\n
+ stw24,96(%2)\n
+ stw25,100(%2)\n
+ stw26,104(%2)\n
+ stw27,108(%2)\n
+ stw28,112(%2)\n
+ stw29,116(%2)\n
+ stw30,120(%2)\n
+ stw31,124(%2)\n
+ mfmsr %0\n
+ stw%0,132(%2)\n
+ mfctr %0\n
+ stw%0,140(%2)\n
+ mflr %0\n
+ stw%0,144(%2)\n
+ bl 1f\n
+ 1: mflr %1\n
+ stw%1,128(%2)\n
+ mtlr %0\n
+ mfxer %0\n
+ stw%0,148(%2)\n
+ : =r (tmp1), =r (tmp2)
+ : b (newregs)
+ : memory);
+#endif /* __powerpc64 __ */
}
}
-#else
-/*
- * Provide a dummy definition to avoid build failures. Will remain
- * empty till crash dump support is enabled.
- */
-static inline void crash_setup_regs(struct pt_regs *newregs,
- struct pt_regs *oldregs) { }
-#endif /* !__powerpc64 __ */
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] powerpc: last bits to support kdump on ppc32
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]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/kernel/crash_dump.c |6 +-
arch/powerpc/kernel/setup_32.c |2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..006a475 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -321,7 +321,7 @@ config KEXEC
config CRASH_DUMP
bool Build a kdump crash kernel
- depends on PPC_MULTIPLATFORM PPC64
+ depends on PPC_MULTIPLATFORM !BOOKE
help
Build a kernel suitable for use as a kdump capture kernel.
The kernel will be linked at a different address than normal, and
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index e0debcc..96cd521 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -34,7 +34,11 @@ void __init reserve_kdump_trampoline(void)
static void __init create_trampoline(unsigned long addr)
{
- unsigned int *p = (unsigned int *)addr;
+ unsigned int *p;
+
+ /* XXX: why this code is working without += PAGE_OFFSET on PPC64? */
+ addr += PAGE_OFFSET;
+ p = (unsigned int *)addr;
/* The maximum range of a single instruction branch, is the current
* instruction's address + (32 MB - 4) bytes. For the trampoline we
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..1d76afc 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -121,6 +121,8 @@ notrace void __init machine_init(unsigned long dt_ptr,
unsigned long phys)
probe_machine();
+ setup_kdump_trampoline();
+
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
--
1.5.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/8] kexec/kdump support for ppc32
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 PPC64 approach to use ioremap(). This is done to be able to support kdump on !HIGHMEM kernels. Also, please take a special look into 8/8 patch, there is a hunk marked with XXX:, which I don't quite understand for PPC64 case (this hunk also persist in the original Dale's patch, and w/o it the capturing kernel doesn't boot on ppc32). I'll try to refresh BookE support as soon as I'll find some BookE board. The patchset includes: - Kexec support [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments 2/8 and 3/8 patches are used to avoid adding lots of default ops to the board files. - Kdump support [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32 [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32 [PATCH 8/8] powerpc: last bits to support kdump on ppc32 [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html What's the state of the kexec tools for ppc32? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 the root and use a phandle in the i2c node to link to them. I can't speak for 52xx, but for 8[356]xx, I would say the clocks belong to the I2C devices. The screwball determination of whether to divide by 1, 2, or 3 only applies to the I2C device only. The divider itself is not used to drive a clock for any other device. If you disable I2C support, then you don't need to care about the divider (or its output clock) at all. That's why I think have the I2C clock in the parent node is wrong, because it would only be used if you had I2C child nodes. If you didn't have any I2C nodes, then you would need to delete the property from the parent node as well. I see this as being one of three ways... The source clocks belong to the platform and the clock messiness belongs in the platform code. The source clocks belong to i2c. The i2c driver needs to use platform specific bindings like Grant proposed. 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. I'm also of the view that all clocks are system resources. Linux is designed to have clock domains, we just aren't using them on PowerPC. Check out arch/powerpc/kernel/clock.c. They are mostly used on ARM. Could we define domains I2C1, I2C2,.. and then implement them? That implies using the root node to communicate the clock speeds to Linux. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 the root and use a phandle in the i2c node to link to them. I can't speak for 52xx, but for 8[356]xx, I would say the clocks belong to the I2C devices. The screwball determination of whether to divide by 1, 2, or 3 only applies to the I2C device only. The divider itself is not used to drive a clock for any other device. If you disable I2C support, then you don't need to care about the divider (or its output clock) at all. That's why I think have the I2C clock in the parent node is wrong, because it would only be used if you had I2C child nodes. If you didn't have any I2C nodes, then you would need to delete the property from the parent node as well. I see this as being one of three ways... The source clocks belong to the platform and the clock messiness belongs in the platform code. The source clocks belong to i2c. The i2c driver needs to use platform specific bindings like Grant proposed. 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. I'm also of the view that all clocks are system resources. Linux is designed to have clock domains, we just aren't using them on PowerPC. Check out arch/powerpc/kernel/clock.c. They are mostly used on ARM. Could we define domains I2C1, I2C2,.. and then implement them? That implies using the root node to communicate the clock speeds to Linux. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 moon. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 ppc_ipb_freq. The platform code can then set the
right clock value into the variable. For mpc8 get it from uboot.
mpc5200 can easily compute it from ppc_proc_freq and checking how the
ipb divider is set. That will move the clock problem out of the i2c
driver.
There is a huge variation in where the I2C source clock comes from.
Sometimes it's the system bus, sometimes ethernet, sometimes SEC, etc.
If
I look at u-boot (which might not be entirely correct or complete), I
see:
83xx: 5 different clock sources
85xx: 3 different clock sources
86xx: 2 different clock sources
But there's more. Sometimes the two I2C controllers don't use the same
clock! So even if you add 10 globals with different clocks, and then
add
code to the mpc i2c driver so if can figure out which one to use given
the
platform, it's still not enough because you need to know which
controller
the device node is for.
IMHO, what Timur suggested of having u-boot put the source clock into
the
i2c node makes the most sense. U-boot has to figure this out, so why
duplicate the work?
Here's my idea:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
bus-frequency = 10;
/* Either */
source-clock-frequency = 0;
/* OR */
source-clock = ccb;
};
Can't we hide a lot of this on platforms where the source clock is not
messed up? For example the mpc5200 doesn't need any of this, the
needed frequency is already available in mpc52xx_find_ipb_freq().
mpc5200 doesn't need any uboot change.
Next would be normal mpc8xxx platforms where i2c is driven by a single
clock, add a uboot filled in parameter in the root node (or I think it
can be computed off of the ones uboot is already filling in). make a
mpc8xxx_find_i2c_freq() function. May not need to change device tree
and uboot.
Finally use this for those days when the tea leaves were especially
bad. Both a device tree and uboot change.
Except the i2c clock isn't always a based on an integer divider of the
CCB
frequency. What's more, it's not always the same for both i2c
controllers.
Suppose i2c #1 uses CCB times 2/3 and i2c #2 uses CCB/2, how would
fsl_get_i2c_freq() figure that out from bus-frequency and
i2c-clock-divider?
If you get the CCB frequency from uboot and know the chip model, can't
you compute these in the platform code? Then make a
mpc8xxx_find_i2c_freq(cell_index).
We can, of course, but do we want to? #ifdef's are not acceptable for Linux
which means scanning the model property to get the divider from some table.
And when a new MPC model shows up, we need to update the table. This can all
be saved and avoided by adding a I2C clock source divider or frequency
property to the FDT. The FDT is to describe the hardware and the fixed
divider value is a property of it.
I'm in favor of a I2C node specific divider property because it does not
rely on a boot-loader filling in the real value. It's fixed for a certain
MPC model. And the I2C source clock frequency is then just:
That is true; and if pin-strapping/dip-switch settings are changed,
then that too should be described in the device tree. However, as
Trent stated, that still leaves the question of *which* clock is the
divider applied against. If it isn't the bus-frequency, then there
needs to be a way to override it (an optional property would be usable
here).
Furthermore, mpc52xx_find_ipb_freq() does the same as fsl_get_sys_freq(). It
looks up the value for the property bus-frequency of the soc. We don't
need a mpc8xxx_find_i2c_freq() but a common fsl_get_i2c_freq() for all MPCs.
implementation detail. Get the device tree binding correct first.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 we have and do things differently etc... I am fully aware of the hell and hacks that went along with chrp. I am *not* suggesting a do everything platform that must figure out all the quirks of a board in a single machine definition. I know too well that is the way of pain. 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 support for board XXX can cope perfectly with it simply due to the device-tree the right information. If that happens to be the case, make your board compatible with board XXX. Make that entry -second- in your compatible list, because one day you'll figure out that there -is- indeed a difference and I don't want to see board XXX code start to grow code to recognise your other board and work around the difference. So at that stage, copy board XXX.c file and start over with your own board support that matches on your first compatible propery entry. 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 problem is; when the original board (the one others are claiming compatibility with) gains additional code to fixup quirks or something, then that code will get changed with no visibility that it is borking up other boards that are currently depending on it. I far prefer the solution I'm currently using in 5200-land where there is a simple (boring?) board port which *explicitly* states which boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c). When someone goes to modify that file, it is explicit that it currently supports multiple boards. If a board becomes 'non-boring', then it is removed from the simple platform; the simple platform is *not* extended to accommodate it. I *fully* agree that it is insane for the code to grow detection logic and I've been explicit about not doing anything of the sort in 5200 land. What I am suggesting is that if nothing else claims the board, then allow the simple platform to bind against it based on the fact that it uses the same SoC. However, if I can't get concensus on this approach, then I do /not/ want to go to a boards compatible with other boards scheme. It will cause breakage and pain that is non-obvious to debug for many users. BTW, I am also not suggesting that the .dts files themselves try to claim some kind of 'generic' compatibility. I'm proposing handling any catch-all cases in the Linux code itself, where it is easy to change because it is just an implementation detail. Trying to make the dt 'generic' doesn't make any sense because doing so is almost always wrong (or will become wrong in the future). - Once you figure out that really, those 5 boards here -do- share 99% of the code... it's just that one need a workaround at the IRQ fixup level, maybe one needs a tweak on a GPIO at boot and one has an issue on reboot that needs to be whacked a bit differently ... well, make -library- code. I have no objection of having something like for each ppc_md field called X, having a utility file providing an mpc52xx_generic_X function. Such a board could then basically have a small .c file whose ppc_md just use the generic functions for all except the ones that need to be hooked/wrapped/replaced/whatever. I agree. 5200 code already does this. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 have in chrp where we end up having hacks to identify what exact sort of chrp we have and do things differently etc... 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 support for board XXX can cope perfectly with it simply due to the device-tree the right information. If that happens to be the case, make your board compatible with board XXX. Make that entry -second- in your compatible list, because one day you'll figure out that there -is- indeed a difference and I don't want to see board XXX code start to grow code to recognise your other board and work around the difference. So at that stage, copy board XXX.c file and start over with your own board support that matches on your first compatible propery entry. 44x does this today for a small number of boards. The issue, if there really is one, is that there's no clear definition on what is acceptable to be called compatible. If _Linux_ platform support for board FOO As stated in my previous email; I dislike this approach. I far prefer making the board support code provide an explicit list rather than trying to define what it means for one board to be compatible with another. I have no objection of having something like for each ppc_md field called X, having a utility file providing an mpc52xx_generic_X function. Such a board could then basically have a small .c file whose ppc_md just use the generic functions for all except the ones that need to be hooked/wrapped/replaced/whatever. 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 a board.c file for a new board and plug in the library functions to ppc_md. Alternatively, you could do the: compatible = specific-board, similar-board approach that has been done for e.g. Bamboo and Yosemite. Again, the issue is that is that OK? Is it OK for a board to claim compatibility with another board when it might not have all the devices of that board, or might have additional devices, etc. I was of the opinion it is, and the device tree handles this just fine, as does the platform code. But it can be confusing, hence the discussion here. I say no [but you already know that. :-) ] -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/8] kexec/kdump support for ppc32
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 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 support kdump on !HIGHMEM kernels. Also, please take a special look into 8/8 patch, there is a hunk marked with XXX:, which I don't quite understand for PPC64 case (this hunk also persist in the original Dale's patch, and w/o it the capturing kernel doesn't boot on ppc32). I'll try to refresh BookE support as soon as I'll find some BookE board. The patchset includes: - Kexec support [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec [PATCH 2/8] powerpc: make default kexec/crash_kernel ops implicit [PATCH 3/8] powerpc: remove default kexec/crash_kernel ops assignments 2/8 and 3/8 patches are used to avoid adding lots of default ops to the board files. - Kdump support [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M [PATCH 5/8] powerpc: allow to ioremap RAM addresses for kdump kernel on ppc32 [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32 [PATCH 8/8] powerpc: last bits to support kdump on ppc32 [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046739.html What's the state of the kexec tools for ppc32? Current kexec-tools has split arch support, and ppc32 is officially broken. I use some old (20070330), patched kexec-tools with ppc32/ and ppc64/ merged into powerpc (alike to Linux). I hope one day I (or somebody else) will find time to cleanup or re-do the patches for the recent kexec-tools, and merge them after all. Though, I didn't look into the patches themselves yet, so I can't tell how much work is pending. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 time? With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis 293-0376800-10 GEBA-BE-BB___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 support for board XXX can cope perfectly with it simply due to the device-tree the right information. If that happens to be the case, make your board compatible with board XXX. Make that entry -second- in your compatible list, because one day you'll figure out that there -is- indeed a difference and I don't want to see board XXX code start to grow code to recognise your other board and work around the difference. So at that stage, copy board XXX.c file and start over with your own board support that matches on your first compatible propery entry. 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 problem is; when the original board (the one others are claiming compatibility with) gains additional code to fixup quirks or something, then that code will get changed with no visibility that it is borking up other boards that are currently depending on it. There is that possibility yes. And it is even non-theoretical to a degree, as the situation may occur with the existing Bamboo/Yosemite scenario when we get around to fixing up the horror that is the EBC on Bamboo. Admittedly, a single person did both those ports so the inherent knowledge is already there, but that won't always be the case. I far prefer the solution I'm currently using in 5200-land where there is a simple (boring?) board port which *explicitly* states which boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c). When someone goes to modify that file, it is explicit that it currently supports multiple boards. If a board becomes 'non-boring', then it is removed from the simple platform; the simple platform is *not* extended to accommodate it. To me, the solution you are using there seems like the best compromise between the various options. It allows a common board.c (or platform) file in the kernel, while still adhering to a form of purity in the device tree itself. The only slightly annoying issue is the need to change the explicit list, but I don't consider that a burden really. If you haven't noticed, my primary reason for wanting to do _something_ is to prevent the proliferation of code duplication that we've seen. Cleanup time is in order, and this is the most expedient and seemingly correct way of doing things. I *fully* agree that it is insane for the code to grow detection logic and I've been explicit about not doing anything of the sort in 5200 land. What I am suggesting is that if nothing else claims the board, then allow the simple platform to bind against it based on the fact that it uses the same SoC. However, if I can't get concensus on this approach, then I do /not/ want to go to a boards compatible with other boards scheme. It will cause breakage and pain that is non-obvious to debug for many users. I think there is too much momentum behind the old method, and not a clear enough definition on how one would bind to a generic SoC without dealing with things like link order, etc. Also, not every platform has SoC nodes (as you already pointed out), and adding them to the DTS files (or adding a new property or binding to the CPU node, etc) for this purpose seems to be both overkill and contrary to not wanting to break existing products out there that use the old DTS files and method. They should be few in number, but they do exist (see PIKA Warp). I'm growing very much of the opinion that the way you are _currently_ handling 52xx is more or less the way we should go. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
platforms/44x/warp-nand.c bogosity
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 seem to be intentionally? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: platforms/44x/warp-nand.c bogosity
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 PPC now that arch/ppc/ got removed. So warp-nand.c is dead code, but that does not seem to be intentionally? 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 well. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: platforms/44x/warp-nand.c bogosity
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 true on PPC now that arch/ppc/ got removed. So warp-nand.c is dead code, but that does not seem to be intentionally? 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 well. josh The current community ndfc driver won't build for arch/powerpc. It still uses ioremap64 and includes asm/ibm4xx.h stuff. Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: platforms/44x/warp-nand.c bogosity
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 PPC now that arch/ppc/ got removed. So warp-nand.c is dead code, but that does not seem to be intentionally? I use a local copy of ndfc.c that was modified to work with arch/powerpc. I submitted the patch, but it was never accepted into the kernel, and to be honest I don't remember why. I will look into this. So the code is definitely not dead. You can't realistically run a warp without the NAND. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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. Did I miss some? On 8313, i2c1 is driven by the encryption clock (whose divider from the CSB clock is programmable as 1, 2, or 3), but i2c2 is driven directly by the CSB clock. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
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 | 14 --
arch/powerpc/kernel/cpu_setup_44x.S |6 -
arch/powerpc/kernel/irq.c| 25 +---
arch/powerpc/kernel/process.c|2 -
arch/powerpc/kernel/vdso.c |2 -
arch/powerpc/lib/Makefile|2 -
arch/powerpc/platforms/52xx/Makefile |4 +-
arch/powerpc/platforms/Makefile |6 -
arch/powerpc/platforms/powermac/Makefile |3 +-
arch/powerpc/sysdev/Makefile |2 -
include/asm-powerpc/dcr.h|6 +-
include/asm-powerpc/i8259.h |5 -
include/asm-powerpc/ipic.h |7 -
include/asm-powerpc/irq.h| 288 --
15 files changed, 6 insertions(+), 368 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 8c8aadb..4ebc52a 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -97,7 +97,7 @@ config IRQSTACKS
config VIRQ_DEBUG
bool Expose hardware/virtual IRQ mapping via debugfs
- depends on DEBUG_FS PPC_MERGE
+ depends on DEBUG_FS
help
This option will show the mapping relationship between hardware irq
numbers and virtual irq numbers. The mapping is exposed via debugfs
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 1a40947..64f5948 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -59,8 +59,6 @@ obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
-ifeq ($(CONFIG_PPC_MERGE),y)
-
extra-$(CONFIG_PPC_STD_MMU):= head_32.o
extra-$(CONFIG_PPC64) := head_64.o
extra-$(CONFIG_40x):= head_40x.o
@@ -100,12 +98,6 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
-else
-# stuff used from here for ARCH=ppc
-smpobj-$(CONFIG_SMP) += smp.o
-
-endif
-
obj-$(CONFIG_PPC64)+= $(obj64-y)
extra-$(CONFIG_PPC_FPU)+= fpu.o
@@ -121,9 +113,6 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
-
-ifeq ($(CONFIG_PPC_MERGE),y)
-
$(obj)/built-in.o: prom_init_check
quiet_cmd_prom_init_check = CALL$
@@ -133,7 +122,4 @@ PHONY += prom_init_check
prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
$(call cmd,prom_init_check)
-endif
-
-
clean-files := vmlinux.lds
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S
b/arch/powerpc/kernel/cpu_setup_44x.S
index 5465e8d..80cac98 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -39,12 +39,6 @@ _GLOBAL(__setup_cpu_440gx)
_GLOBAL(__setup_cpu_440spe)
b __fixup_440A_mcheck
- /* Temporary fixup for arch/ppc until we kill the whole thing */
-#ifndef CONFIG_PPC_MERGE
-_GLOBAL(__fixup_440A_mcheck)
- blr
-#endif
-
/* enable APU between CPU and FPU */
_GLOBAL(__init_fpu_44x)
mfspr r3,SPRN_CCR0
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6ac8612..d972dec 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -77,22 +77,12 @@ static int ppc_spurious_interrupts;
EXPORT_SYMBOL(__irq_offset_value);
atomic_t ppc_n_lost_interrupts;
-#ifndef CONFIG_PPC_MERGE
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
-#endif
-
#ifdef CONFIG_TAU_INT
extern int tau_initialized;
extern int tau_interrupts(int);
#endif
#endif /* CONFIG_PPC32 */
-#if defined(CONFIG_SMP) !defined(CONFIG_PPC_MERGE)
-extern atomic_t ipi_recv;
-extern atomic_t ipi_sent;
-#endif
-
#ifdef CONFIG_PPC64
EXPORT_SYMBOL(irq_desc);
@@ -216,21 +206,14 @@ int show_interrupts(struct seq_file *p, void *v)
skip:
spin_unlock_irqrestore(desc-lock, flags);
} else if (i == NR_IRQS) {
-#ifdef CONFIG_PPC32
-#ifdef CONFIG_TAU_INT
+#if defined(CONFIG_PPC32) defined(CONFIG_TAU_INT)
if (tau_initialized){
seq_puts(p, TAU: );
for_each_online_cpu(j)
seq_printf(p, %10u , tau_interrupts(j));
seq_puts(p, PowerPC Thermal Assist (cpu
temp)\n);
}
-#endif
-#if defined(CONFIG_SMP) !defined(CONFIG_PPC_MERGE)
- /* should this be per processor send/receive? */
- seq_printf(p, IPI (recv/sent): %10u/%u\n,
- atomic_read(ipi_recv), atomic_read(ipi_sent));
-#endif
-#endif /* CONFIG_PPC32 */
+#endif /*
Re: platforms/44x/warp-nand.c bogosity
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 well. So I went back in the archives. Somebody else, Thomas Gleixner I believe, was already working on the ndfc port. So, since I *had* to have a working ndfc, I put a local copy in my kernel and forgot about it. It looks like Thomas has dropped the port. I should probably resubmit the patch with the arch/ppc code removed. However, I don't think this would be for 2.6.27 timeframe since there will probably be discussion. For one, my patch just gets it working... the warp-nand.c file shows that it is not a complete solution ;) Second, there are some byte order issues. So could we just leave warp-nand.c there but disabled for now? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Compact flash on mpc8349eITX
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 kernel configuration. Has anyone successfully communicated with a compact flash device in true IDE mode on the MPC8349eITX? If so, do you happen to know the kernel configuration and/or revision? I appreciate any help, as I am really getting stuck here. Regards, Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 from the dtc. If you need special C code to initialize the board, then it isn't compatible. This is exactly analogous to the pc-net driver supporting dozens of different cards that differ only in their ID. Are all these cards 100% the same: no. There's plenty of differences between them. However, the pc-net driver copes with the small differences so that one driver can handle most of the ne2000 class of network cards. Are there special drivers for ne2000-like cards that aren't quite compatible enough or have extra features, sure. That doesn't totally invalidate the utility. There are always engineering trade offs to be made. Warner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 OpenFirmware. It has a Forth interpreter and builds the device tree itself. It doesn't use flat device trees that get filled in by the boot firmware. -- Timur Tabi Linux Kernel Developer @ Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
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 snip Turning off GCOV fixes this. Not really the best solution but at least it narrows doen the search effort. Thanks, kernel compiles after turning off the GCOV profiling options. Peter, Can you have a look at how this can be fixed, if at all? Peter, kindly let me know if you want me to test any test patches/fixes. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 or special case hacks. I'm talking truly generic code that is table driven entirely from the dtc. If you need special C code to initialize the board, then it isn't compatible. When doing the initial board port, you don't *know* if you're going to need special cases. Or, you don't know if the special case code belongs in the platform code, or belongs somewhere else (implementation detail). Or, the special code could get refactored in the future and be moved into or out of the platform code. Claiming one board is compatible with another tends to just encode a Linux implementation detail into the device tree. This is exactly analogous to the pc-net driver supporting dozens of different cards that differ only in their ID. Are all these cards 100% the same: no. There's plenty of differences between them. However, the pc-net driver copes with the small differences so that one driver can handle most of the ne2000 class of network cards. Yes, and we use lists of compatible values for devices. However, the board level has much higher complexity. The likelyhood of getting it wrong is much greater. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
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 need to remove references to it from drivers also drivers/ata/pata_sil680.c 233:#ifdef CONFIG_PPC_MERGE drivers/block/floppy.c 4168:#if defined(CONFIG_PPC_MERGE) drivers/char/ipmi/ipmi_si_intf.c 2703:#ifdef CONFIG_PPC_MERGE drivers/i2c/busses/i2c-pca-isa.c 116:#ifdef CONFIG_PPC_MERGE drivers/input/serio/i8042-io.h 70:#if defined(CONFIG_PPC_MERGE) drivers/usb/host/ehci-hcd.c 1017:#if defined(CONFIG_440EPX) !defined(CONFIG_PPC_MERGE) drivers/usb/host/ehci.h 748:#if defined(CONFIG_PPC) !defined(CONFIG_PPC_MERGE) drivers/usb/host/ohci.h 536:#if defined(CONFIG_PPC) !defined(CONFIG_PPC_MERGE) drivers/net/fs_enet/mac-fec.c 316:#ifndef CONFIG_PPC_MERGE 418:#ifndef CONFIG_PPC_MERGE drivers/net/fs_enet/mac-scc.c 376:#ifndef CONFIG_PPC_MERGE drivers/pnp/isapnp/core.c 1015:#ifdef CONFIG_PPC_MERGE drivers/pnp/pnpbios/core.c 522:#if defined(CONFIG_PPC_MERGE) 580:#if defined(CONFIG_PPC_MERGE) drivers/serial/mpc52xx_uart.c 76:#if defined(CONFIG_PPC_MERGE) 110:#if defined(CONFIG_PPC_MERGE) 258:#if defined(CONFIG_PPC_MERGE) 889:#if !defined(CONFIG_PPC_MERGE) 949:#if !defined(CONFIG_PPC_MERGE) 1056:#endif /* defined(CONFIG_PPC_MERGE) */ 1075:#if defined(CONFIG_PPC_MERGE) 1104:#if !defined(CONFIG_PPC_MERGE) 1208:#endif /* !defined(CONFIG_PPC_MERGE) */ 1211:#if defined(CONFIG_PPC_MERGE) 1405:#endif /* defined(CONFIG_PPC_MERGE) */ 1426:#if defined(CONFIG_PPC_MERGE) 1453:#if defined(CONFIG_PPC_MERGE) drivers/spi/mpc52xx_psc_spi.c 19:#if defined(CONFIG_PPC_MERGE) 474:#if !defined(CONFIG_PPC_MERGE) 519:#else /* defined(CONFIG_PPC_MERGE) */ 589:#endif /* defined(CONFIG_PPC_MERGE) */ -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove use of CONFIG_PPC_MERGE
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. Signed-off-by: Kumar Gala [EMAIL PROTECTED] You need to remove references to it from drivers also Old your horses (or should I say kilt).. patches are coming :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 00/10] powerpc: Remove use of CONFIG_PPC_MERGE
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 01/10] powerpc: Remove use of CONFIG_PPC_MERGE
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 | 14 --
arch/powerpc/kernel/cpu_setup_44x.S |6 -
arch/powerpc/kernel/irq.c| 25 +---
arch/powerpc/kernel/process.c|2 -
arch/powerpc/kernel/vdso.c |2 -
arch/powerpc/lib/Makefile|2 -
arch/powerpc/platforms/52xx/Makefile |4 +-
arch/powerpc/platforms/Makefile |6 -
arch/powerpc/platforms/powermac/Makefile |3 +-
arch/powerpc/sysdev/Makefile |2 -
include/asm-powerpc/dcr.h|6 +-
include/asm-powerpc/i8259.h |5 -
include/asm-powerpc/ipic.h |7 -
include/asm-powerpc/irq.h| 288 --
15 files changed, 6 insertions(+), 368 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 8c8aadb..4ebc52a 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -97,7 +97,7 @@ config IRQSTACKS
config VIRQ_DEBUG
bool Expose hardware/virtual IRQ mapping via debugfs
- depends on DEBUG_FS PPC_MERGE
+ depends on DEBUG_FS
help
This option will show the mapping relationship between hardware irq
numbers and virtual irq numbers. The mapping is exposed via debugfs
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 1a40947..64f5948 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -59,8 +59,6 @@ obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
obj-$(CONFIG_MODULES) += module.o module_$(CONFIG_WORD_SIZE).o
obj-$(CONFIG_44x) += cpu_setup_44x.o
-ifeq ($(CONFIG_PPC_MERGE),y)
-
extra-$(CONFIG_PPC_STD_MMU):= head_32.o
extra-$(CONFIG_PPC64) := head_64.o
extra-$(CONFIG_40x):= head_40x.o
@@ -100,12 +98,6 @@ ifneq ($(CONFIG_PPC_INDIRECT_IO),y)
obj-y += iomap.o
endif
-else
-# stuff used from here for ARCH=ppc
-smpobj-$(CONFIG_SMP) += smp.o
-
-endif
-
obj-$(CONFIG_PPC64)+= $(obj64-y)
extra-$(CONFIG_PPC_FPU)+= fpu.o
@@ -121,9 +113,6 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
-
-ifeq ($(CONFIG_PPC_MERGE),y)
-
$(obj)/built-in.o: prom_init_check
quiet_cmd_prom_init_check = CALL$
@@ -133,7 +122,4 @@ PHONY += prom_init_check
prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
$(call cmd,prom_init_check)
-endif
-
-
clean-files := vmlinux.lds
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S
b/arch/powerpc/kernel/cpu_setup_44x.S
index 5465e8d..80cac98 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -39,12 +39,6 @@ _GLOBAL(__setup_cpu_440gx)
_GLOBAL(__setup_cpu_440spe)
b __fixup_440A_mcheck
- /* Temporary fixup for arch/ppc until we kill the whole thing */
-#ifndef CONFIG_PPC_MERGE
-_GLOBAL(__fixup_440A_mcheck)
- blr
-#endif
-
/* enable APU between CPU and FPU */
_GLOBAL(__init_fpu_44x)
mfspr r3,SPRN_CCR0
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 6ac8612..d972dec 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -77,22 +77,12 @@ static int ppc_spurious_interrupts;
EXPORT_SYMBOL(__irq_offset_value);
atomic_t ppc_n_lost_interrupts;
-#ifndef CONFIG_PPC_MERGE
-#define NR_MASK_WORDS ((NR_IRQS + 31) / 32)
-unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
-#endif
-
#ifdef CONFIG_TAU_INT
extern int tau_initialized;
extern int tau_interrupts(int);
#endif
#endif /* CONFIG_PPC32 */
-#if defined(CONFIG_SMP) !defined(CONFIG_PPC_MERGE)
-extern atomic_t ipi_recv;
-extern atomic_t ipi_sent;
-#endif
-
#ifdef CONFIG_PPC64
EXPORT_SYMBOL(irq_desc);
@@ -216,21 +206,14 @@ int show_interrupts(struct seq_file *p, void *v)
skip:
spin_unlock_irqrestore(desc-lock, flags);
} else if (i == NR_IRQS) {
-#ifdef CONFIG_PPC32
-#ifdef CONFIG_TAU_INT
+#if defined(CONFIG_PPC32) defined(CONFIG_TAU_INT)
if (tau_initialized){
seq_puts(p, TAU: );
for_each_online_cpu(j)
seq_printf(p, %10u , tau_interrupts(j));
seq_puts(p, PowerPC Thermal Assist (cpu
temp)\n);
}
-#endif
-#if defined(CONFIG_SMP) !defined(CONFIG_PPC_MERGE)
- /* should this be per processor send/receive? */
- seq_printf(p, IPI (recv/sent): %10u/%u\n,
- atomic_read(ipi_recv), atomic_read(ipi_sent));
-#endif
-#endif /* CONFIG_PPC32 */
+#endif
[PATCH 02/10] usb: remove code associated with !CONFIG_PPC_MERGE
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 ---
drivers/usb/host/ehci.h |9 --
drivers/usb/host/ohci.h |8 --
4 files changed, 0 insertions(+), 223 deletions(-)
delete mode 100644 drivers/usb/host/ehci-ppc-soc.c
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index d9d53f2..84ed135 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1014,11 +1014,6 @@ MODULE_LICENSE (GPL);
#definePS3_SYSTEM_BUS_DRIVER ps3_ehci_driver
#endif
-#if defined(CONFIG_440EPX) !defined(CONFIG_PPC_MERGE)
-#include ehci-ppc-soc.c
-#definePLATFORM_DRIVER ehci_ppc_soc_driver
-#endif
-
#ifdef CONFIG_USB_EHCI_HCD_PPC_OF
#include ehci-ppc-of.c
#define OF_PLATFORM_DRIVER ehci_hcd_ppc_of_driver
diff --git a/drivers/usb/host/ehci-ppc-soc.c b/drivers/usb/host/ehci-ppc-soc.c
deleted file mode 100644
index 529590e..000
--- a/drivers/usb/host/ehci-ppc-soc.c
+++ /dev/null
@@ -1,201 +0,0 @@
-/*
- * EHCI HCD (Host Controller Driver) for USB.
- *
- * (C) Copyright 2006-2007 Stefan Roese [EMAIL PROTECTED], DENX Software
Engineering
- *
- * Bus Glue for PPC On-Chip EHCI driver
- * Tested on AMCC 440EPx
- *
- * Based on ehci-au1xxx.c by K.Boge [EMAIL PROTECTED]
- *
- * This file is licenced under the GPL.
- */
-
-#include linux/platform_device.h
-
-extern int usb_disabled(void);
-
-/* called during probe() after chip reset completes */
-static int ehci_ppc_soc_setup(struct usb_hcd *hcd)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- int retval;
-
- retval = ehci_halt(ehci);
- if (retval)
- return retval;
-
- retval = ehci_init(hcd);
- if (retval)
- return retval;
-
- ehci-sbrn = 0x20;
- return ehci_reset(ehci);
-}
-
-/**
- * usb_ehci_ppc_soc_probe - initialize PPC-SoC-based HCDs
- * Context: !in_interrupt()
- *
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
- *
- */
-int usb_ehci_ppc_soc_probe(const struct hc_driver *driver,
- struct usb_hcd **hcd_out,
- struct platform_device *dev)
-{
- int retval;
- struct usb_hcd *hcd;
- struct ehci_hcd *ehci;
-
- if (dev-resource[1].flags != IORESOURCE_IRQ) {
- pr_debug(resource[1] is not IORESOURCE_IRQ);
- retval = -ENOMEM;
- }
- hcd = usb_create_hcd(driver, dev-dev, PPC-SOC EHCI);
- if (!hcd)
- return -ENOMEM;
- hcd-rsrc_start = dev-resource[0].start;
- hcd-rsrc_len = dev-resource[0].end - dev-resource[0].start + 1;
-
- if (!request_mem_region(hcd-rsrc_start, hcd-rsrc_len, hcd_name)) {
- pr_debug(request_mem_region failed);
- retval = -EBUSY;
- goto err1;
- }
-
- hcd-regs = ioremap(hcd-rsrc_start, hcd-rsrc_len);
- if (!hcd-regs) {
- pr_debug(ioremap failed);
- retval = -ENOMEM;
- goto err2;
- }
-
- ehci = hcd_to_ehci(hcd);
- ehci-big_endian_mmio = 1;
- ehci-big_endian_desc = 1;
- ehci-caps = hcd-regs;
- ehci-regs = hcd-regs + HC_LENGTH(ehci_readl(ehci,
ehci-caps-hc_capbase));
-
- /* cache this readonly data; minimize chip reads */
- ehci-hcs_params = ehci_readl(ehci, ehci-caps-hcs_params);
-
-#if defined(CONFIG_440EPX)
- /*
-* 440EPx Errata USBH_3
-* Fix: Enable Break Memory Transfer (BMT) in INSNREG3
-*/
- out_be32((void *)((ulong)(ehci-regs-command) + 0x8c), (1 0));
- ehci_dbg(ehci, Break Memory Transfer (BMT) has beed enabled!\n);
-#endif
-
- retval = usb_add_hcd(hcd, dev-resource[1].start, IRQF_DISABLED);
- if (retval == 0)
- return retval;
-
- iounmap(hcd-regs);
-err2:
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-err1:
- usb_put_hcd(hcd);
- return retval;
-}
-
-/* may be called without controller electrically present */
-/* may be called with controller, bus, and devices active */
-
-/**
- * usb_ehci_hcd_ppc_soc_remove - shutdown processing for PPC-SoC-based HCDs
- * @dev: USB Host Controller being removed
- * Context: !in_interrupt()
- *
- * Reverses the effect of usb_ehci_hcd_ppc_soc_probe(), first invoking
- * the HCD's stop() method. It is always called from a thread
- * context, normally rmmod, apmd, or something similar.
- *
- */
-void usb_ehci_ppc_soc_remove(struct usb_hcd *hcd, struct platform_device *dev)
-{
- usb_remove_hcd(hcd);
- iounmap(hcd-regs);
- release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
-
[PATCH 04/10] netdev: drop CONFIG_PPC_MERGE from Kconfig
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 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index fa533c2..4e89c81 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1812,7 +1812,7 @@ config FEC2 config FEC_MPC52xx tristate MPC52xx FEC driver - depends on PPC_MERGE PPC_MPC52xx PPC_BESTCOMM_FEC + depends on PPC_MPC52xx PPC_BESTCOMM_FEC select CRC32 select PHYLIB ---help--- diff --git a/drivers/net/ibm_newemac/Kconfig b/drivers/net/ibm_newemac/Kconfig index 70a3272..bcec732 100644 --- a/drivers/net/ibm_newemac/Kconfig +++ b/drivers/net/ibm_newemac/Kconfig @@ -1,6 +1,6 @@ config IBM_NEW_EMAC tristate IBM EMAC Ethernet support - depends on PPC_DCR PPC_MERGE + depends on PPC_DCR select CRC32 help This driver supports the IBM EMAC family of Ethernet controllers -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 03/10] fs-enet: remove code associated with !CONFIG_PPC_MERGE
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/fs_enet-main.c |2 --
drivers/net/fs_enet/fs_enet.h |2 --
drivers/net/fs_enet/mac-fcc.c | 12
drivers/net/fs_enet/mac-fec.c | 30 --
drivers/net/fs_enet/mac-scc.c | 26 --
5 files changed, 0 insertions(+), 72 deletions(-)
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 int fs_request_irq(struct net_device *dev, int irq,
const char *name,
{
struct fs_enet_private *fep = netdev_priv(dev);
- (*fep-ops-pre_request_irq)(dev, irq);
return request_irq(irq, irqf, IRQF_SHARED, name, dev);
}
@@ -678,7 +677,6 @@ static void fs_free_irq(struct net_device *dev, int irq)
struct fs_enet_private *fep = netdev_priv(dev);
free_irq(irq, dev);
- (*fep-ops-post_free_irq)(dev, irq);
}
static void fs_timeout(struct net_device *dev)
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index db46d2e..85a4bab 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -34,8 +34,6 @@ struct fs_ops {
void (*adjust_link)(struct net_device *dev);
void (*restart)(struct net_device *dev);
void (*stop)(struct net_device *dev);
- void (*pre_request_irq)(struct net_device *dev, int irq);
- void (*post_free_irq)(struct net_device *dev, int irq);
void (*napi_clear_rx_event)(struct net_device *dev);
void (*napi_enable_rx)(struct net_device *dev);
void (*napi_disable_rx)(struct net_device *dev);
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 0a97fc2..b8c40d0 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -421,16 +421,6 @@ static void stop(struct net_device *dev)
fs_cleanup_bds(dev);
}
-static void pre_request_irq(struct net_device *dev, int irq)
-{
- /* nothing */
-}
-
-static void post_free_irq(struct net_device *dev, int irq)
-{
- /* nothing */
-}
-
static void napi_clear_rx_event(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
@@ -540,8 +530,6 @@ const struct fs_ops fs_fcc_ops = {
.set_multicast_list = set_multicast_list,
.restart= restart,
.stop = stop,
- .pre_request_irq= pre_request_irq,
- .post_free_irq = post_free_irq,
.napi_clear_rx_event= napi_clear_rx_event,
.napi_enable_rx = napi_enable_rx,
.napi_disable_rx= napi_disable_rx,
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 0a7d1c5..14e5753 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -313,11 +313,7 @@ static void restart(struct net_device *dev)
* Clear any outstanding interrupt.
*/
FW(fecp, ievent, 0xffc0);
-#ifndef CONFIG_PPC_MERGE
- FW(fecp, ivec, (fep-interrupt / 2) 29);
-#else
FW(fecp, ivec, (virq_to_hw(fep-interrupt) / 2) 29);
-#endif
/*
* adjust to speed (only for DUET RMII)
@@ -413,30 +409,6 @@ static void stop(struct net_device *dev)
}
}
-static void pre_request_irq(struct net_device *dev, int irq)
-{
-#ifndef CONFIG_PPC_MERGE
- immap_t *immap = fs_enet_immap;
- u32 siel;
-
- /* SIU interrupt */
- if (irq = SIU_IRQ0 irq SIU_LEVEL7) {
-
- siel = in_be32(immap-im_siu_conf.sc_siel);
- if ((irq 1) == 0)
- siel |= (0x8000 irq);
- else
- siel = ~(0x8000 (irq ~1));
- out_be32(immap-im_siu_conf.sc_siel, siel);
- }
-#endif
-}
-
-static void post_free_irq(struct net_device *dev, int irq)
-{
- /* nothing */
-}
-
static void napi_clear_rx_event(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
@@ -529,8 +501,6 @@ const struct fs_ops fs_fec_ops = {
.set_multicast_list = set_multicast_list,
.restart= restart,
.stop = stop,
- .pre_request_irq= pre_request_irq,
- .post_free_irq = post_free_irq,
.napi_clear_rx_event= napi_clear_rx_event,
.napi_enable_rx = napi_enable_rx,
.napi_disable_rx= napi_disable_rx,
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 029b3c7..397608a 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++
[PATCH 06/10] serial/mpc52xx_uart: remove code associated with !CONFIG_PPC_MERGE
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 deletions(-)
diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 3612607..6117d3d 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -72,13 +72,8 @@
#include linux/console.h
#include linux/delay.h
#include linux/io.h
-
-#if defined(CONFIG_PPC_MERGE)
#include linux/of.h
#include linux/of_platform.h
-#else
-#include linux/platform_device.h
-#endif
#include asm/mpc52xx.h
#include asm/mpc512x.h
@@ -107,12 +102,11 @@ static struct uart_port
mpc52xx_uart_ports[MPC52xx_PSC_MAXNUM];
*it's cleared, then a memset(...,0,...) should be added to
*the console_init
*/
-#if defined(CONFIG_PPC_MERGE)
+
/* lookup table for matching device nodes to index numbers */
static struct device_node *mpc52xx_uart_nodes[MPC52xx_PSC_MAXNUM];
static void mpc52xx_uart_of_enumerate(void);
-#endif
#define PSC(port) ((struct mpc52xx_psc __iomem *)((port)-membase))
@@ -255,17 +249,12 @@ static void mpc52xx_psc_cw_restore_ints(struct uart_port
*port)
/* Search for bus-frequency property in this node or a parent */
static unsigned long mpc52xx_getuartclk(void *p)
{
-#if defined(CONFIG_PPC_MERGE)
/*
* 5200 UARTs have a / 32 prescaler
* but the generic serial code assumes 16
* so return ipb freq / 2
*/
return mpc52xx_find_ipb_freq(p) / 2;
-#else
- pr_debug(unexpected call to mpc52xx_getuartclk with arch/ppc\n);
- return NULL;
-#endif
}
static struct psc_ops mpc52xx_psc_ops = {
@@ -886,10 +875,6 @@ mpc52xx_console_get_options(struct uart_port *port,
/* CT{U,L}R are write-only ! */
*baud = CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD;
-#if !defined(CONFIG_PPC_MERGE)
- if (__res.bi_baudrate)
- *baud = __res.bi_baudrate;
-#endif
/* Parse them */
switch (mr1 MPC52xx_PSC_MODE_BITS_MASK) {
@@ -946,42 +931,6 @@ mpc52xx_console_write(struct console *co, const char *s,
unsigned int count)
psc_ops-cw_restore_ints(port);
}
-#if !defined(CONFIG_PPC_MERGE)
-static int __init
-mpc52xx_console_setup(struct console *co, char *options)
-{
- struct uart_port *port = mpc52xx_uart_ports[co-index];
-
- int baud = CONFIG_SERIAL_MPC52xx_CONSOLE_BAUD;
- int bits = 8;
- int parity = 'n';
- int flow = 'n';
-
- if (co-index 0 || co-index = MPC52xx_PSC_MAXNUM)
- return -EINVAL;
-
- /* Basic port init. Needed since we use some uart_??? func before
-* real init for early access */
- spin_lock_init(port-lock);
- port-uartclk = __res.bi_ipbfreq / 2; /* Look at CTLR doc */
- port-ops = mpc52xx_uart_ops;
- port-mapbase = MPC52xx_PA(MPC52xx_PSCx_OFFSET(co-index+1));
-
- /* We ioremap ourself */
- port-membase = ioremap(port-mapbase, MPC52xx_PSC_SIZE);
- if (port-membase == NULL)
- return -EINVAL;
-
- /* Setup the port parameters accoding to options */
- if (options)
- uart_parse_options(options, baud, parity, bits, flow);
- else
- mpc52xx_console_get_options(port, baud, parity, bits, flow);
-
- return uart_set_options(port, co, baud, parity, bits, flow);
-}
-
-#else
static int __init
mpc52xx_console_setup(struct console *co, char *options)
@@ -1053,7 +1002,6 @@ mpc52xx_console_setup(struct console *co, char *options)
return uart_set_options(port, co, baud, parity, bits, flow);
}
-#endif /* defined(CONFIG_PPC_MERGE) */
static struct uart_driver mpc52xx_uart_driver;
@@ -1072,9 +1020,7 @@ static struct console mpc52xx_console = {
static int __init
mpc52xx_console_init(void)
{
-#if defined(CONFIG_PPC_MERGE)
mpc52xx_uart_of_enumerate();
-#endif
register_console(mpc52xx_console);
return 0;
}
@@ -1100,115 +1046,6 @@ static struct uart_driver mpc52xx_uart_driver = {
.cons = MPC52xx_PSC_CONSOLE,
};
-
-#if !defined(CONFIG_PPC_MERGE)
-/* */
-/* Platform Driver */
-/* */
-
-static int __devinit
-mpc52xx_uart_probe(struct platform_device *dev)
-{
- struct resource *res = dev-resource;
-
- struct uart_port *port = NULL;
- int i, idx, ret;
-
- /* Check validity presence */
- idx = dev-id;
- if (idx 0 || idx = MPC52xx_PSC_MAXNUM)
- return -EINVAL;
-
- if (!mpc52xx_match_psc_function(idx, uart))
- return -ENODEV;
-
- /* Init the port
[PATCH 05/10] rtc: use CONFIG_PPC instead of CONFIG_PPC_MERGE
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/Kconfig b/drivers/rtc/Kconfig index 90ab738..564a3ed 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -577,7 +577,7 @@ config RTC_DRV_RS5C313 config RTC_DRV_PPC tristate PowerPC machine dependent RTC support - depends on PPC_MERGE + depends on PPC help The PowerPC kernel has machine-specific functions for accessing the RTC. This exposes that functionality through the generic RTC -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 07/10] mpc52xx_psc_spi: remove code associated with !CONFIG_PPC_MERGE
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(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 25eda71..c3a9e5c 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -15,13 +15,7 @@
#include linux/init.h
#include linux/errno.h
#include linux/interrupt.h
-
-#if defined(CONFIG_PPC_MERGE)
#include linux/of_platform.h
-#else
-#include linux/platform_device.h
-#endif
-
#include linux/workqueue.h
#include linux/completion.h
#include linux/io.h
@@ -471,53 +465,6 @@ static int __exit mpc52xx_psc_spi_do_remove(struct device
*dev)
return 0;
}
-#if !defined(CONFIG_PPC_MERGE)
-static int __init mpc52xx_psc_spi_probe(struct platform_device *dev)
-{
- switch(dev-id) {
- case 1:
- case 2:
- case 3:
- case 6:
- return mpc52xx_psc_spi_do_probe(dev-dev,
- MPC52xx_PA(MPC52xx_PSCx_OFFSET(dev-id)),
- MPC52xx_PSC_SIZE, platform_get_irq(dev, 0), dev-id);
- default:
- return -EINVAL;
- }
-}
-
-static int __exit mpc52xx_psc_spi_remove(struct platform_device *dev)
-{
- return mpc52xx_psc_spi_do_remove(dev-dev);
-}
-
-/* work with hotplug and coldplug */
-MODULE_ALIAS(platform:mpc52xx-psc-spi);
-
-static struct platform_driver mpc52xx_psc_spi_platform_driver = {
- .remove = __exit_p(mpc52xx_psc_spi_remove),
- .driver = {
- .name = mpc52xx-psc-spi,
- .owner = THIS_MODULE,
- },
-};
-
-static int __init mpc52xx_psc_spi_init(void)
-{
- return platform_driver_probe(mpc52xx_psc_spi_platform_driver,
- mpc52xx_psc_spi_probe);
-}
-module_init(mpc52xx_psc_spi_init);
-
-static void __exit mpc52xx_psc_spi_exit(void)
-{
- platform_driver_unregister(mpc52xx_psc_spi_platform_driver);
-}
-module_exit(mpc52xx_psc_spi_exit);
-
-#else /* defined(CONFIG_PPC_MERGE) */
-
static int __init mpc52xx_psc_spi_of_probe(struct of_device *op,
const struct of_device_id *match)
{
@@ -586,8 +533,6 @@ static void __exit mpc52xx_psc_spi_exit(void)
}
module_exit(mpc52xx_psc_spi_exit);
-#endif /* defined(CONFIG_PPC_MERGE) */
-
MODULE_AUTHOR(Dragos Carp);
MODULE_DESCRIPTION(MPC52xx PSC SPI Driver);
MODULE_LICENSE(GPL);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 08/10] powerpc: convert CONFIG_PPC_MERGE to CONFIG_PPC for legacy io checks
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 +-
drivers/i2c/busses/i2c-pca-isa.c |2 +-
drivers/input/serio/i8042-io.h |2 +-
drivers/pnp/isapnp/core.c|2 +-
drivers/pnp/pnpbios/core.c |4 ++--
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
index 395f8ea..5813e0d 100644
--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -4165,7 +4165,7 @@ static int __init floppy_init(void)
int i, unit, drive;
int err, dr;
-#if defined(CONFIG_PPC_MERGE)
+#if defined(CONFIG_PPC)
if (check_legacy_ioport(FDC1))
return -ENODEV;
#endif
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index f52931e..7ca4275 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2700,7 +2700,7 @@ static __devinit void default_find_bmc(void)
if (!info)
return;
-#ifdef CONFIG_PPC_MERGE
+#ifdef CONFIG_PPC
if (check_legacy_ioport(ipmi_defaults[i].port))
continue;
#endif
diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
index a119784..28d8463 100644
--- a/drivers/i2c/busses/i2c-pca-isa.c
+++ b/drivers/i2c/busses/i2c-pca-isa.c
@@ -113,7 +113,7 @@ static int __devinit pca_isa_probe(struct device *dev,
unsigned int id)
dev_info(dev, i/o base %#08lx. irq %d\n, base, irq);
-#ifdef CONFIG_PPC_MERGE
+#ifdef CONFIG_PPC
if (check_legacy_ioport(base)) {
dev_err(dev, I/O address %#08lx is not available\n, base);
goto out;
diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
index f451c73..847f4aa 100644
--- a/drivers/input/serio/i8042-io.h
+++ b/drivers/input/serio/i8042-io.h
@@ -67,7 +67,7 @@ static inline int i8042_platform_init(void)
* On some platforms touching the i8042 data register region can do really
* bad things. Because of this the region is always reserved on such boxes.
*/
-#if defined(CONFIG_PPC_MERGE)
+#if defined(CONFIG_PPC)
if (check_legacy_ioport(I8042_DATA_REG))
return -ENODEV;
#endif
diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index 101a835..46455fb 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
@@ -1012,7 +1012,7 @@ static int __init isapnp_init(void)
printk(KERN_INFO isapnp: ISA Plug Play support disabled\n);
return 0;
}
-#ifdef CONFIG_PPC_MERGE
+#ifdef CONFIG_PPC
if (check_legacy_ioport(_PIDXR) || check_legacy_ioport(_PNPWRP))
return -EINVAL;
#endif
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index 19a4be1..0797dd1 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -519,7 +519,7 @@ static int __init pnpbios_init(void)
{
int ret;
-#if defined(CONFIG_PPC_MERGE)
+#if defined(CONFIG_PPC)
if (check_legacy_ioport(PNPBIOS_BASE))
return -ENODEV;
#endif
@@ -577,7 +577,7 @@ static int __init pnpbios_thread_init(void)
{
struct task_struct *task;
-#if defined(CONFIG_PPC_MERGE)
+#if defined(CONFIG_PPC)
if (check_legacy_ioport(PNPBIOS_BASE))
return 0;
#endif
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Compact flash on mpc8349eITX
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 HW issue, but I was hoping to verify that I am using a known good kernel configuration. Has anyone successfully communicated with a compact flash device in true IDE mode on the MPC8349eITX? If so, do you happen to know the kernel configuration and/or revision? 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). As for the backtrace you posted recently, I remeber I've noticed the similar issue long ago on some mITX board. I believe the board had hw issues indeed (or CF card I tested with). The problem could be in the IRQ line itself (for some reason it always low), or it could be IDE cmd/data lines at fault, so that IDE can't receive status read command and does not deassert the interrupt line... quite hard to tell. The logs below. (Notice that u-boot says that UPMA is configured to work with CF IDE). U-Boot 1.2.0-g5b1313fb (Jun 9 2007 - 17:29:42) MPC83XX CPU: e300c1, MPC8349E, Rev: 11 at 533.333 MHz, CSB: 266 MHz Board: Freescale MPC8349E-mITX UPMA: Configured for compact flash I2C: ready DRAM: DDR DIMM: data bus width is 64 bit without ECC DDRC ECC mode: OFF DDR RAM: 256 MB FLASH: 16 MB PCI: Bus Dev VenId DevId Class Int 00 10 1095 3114 0180 00 In:serial Out: serial Err: serial Board revision: 1.0 (PCF8475A) Net: TSEC0 IDE: Bus 0: OK Device 0: Model: KINGSTON Firm: 20060713 Ser#: KINGSTON CF 3E2C Type: Hard Disk Capacity: 495.1 MB = 0.4 GB (1014048 x 512) MPC8349E-mITX boot [...] Using MPC834x ITX machine description Linux version 2.6.27-rc1-6-g2799599 ([EMAIL PROTECTED]) (gcc version 4.2.0)) #35 Fri Aug 1 20:32:51 MSD 2008 [...] scsi0 : pata_platform ata1: PATA max PIO6 mmio cmd 0xf000 ctl 0xf20c irq 23 ata1.00: ATA-0: KINGSTON, 20060713, max MWDMA2 ata1.00: 1014048 sectors, multi 0: LBA ata1.00: configured for PIO ata1.00: configured for PIO ata1: EH complete scsi 0:0:0:0: Direct-Access ATA KINGSTON 2006 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 1014048 512-byte hardware sectors (519 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 1014048 512-byte hardware sectors (519 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 [...] # dd if=/dev/sda of=/dev/null count=2 2+0 records in 2+0 records out 1024 bytes (10 MB) copied, 1.94026 seconds, 5.3 MB/s -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
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 to it. Other things continue to pop up and time is limited at the moment as in more limited than usual). Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Compact flash on mpc8349eITX
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 with this version. As for the backtrace you posted recently, I remeber I've noticed the similar issue long ago on some mITX board. I believe the board had hw issues indeed (or CF card I tested with). The problem could be in the IRQ line itself (for some reason it always low), or it could be IDE cmd/data lines at fault, so that IDE can't receive status read command and does not deassert the interrupt line... quite hard to tell. Thanks for confirming.. I was losing my mind :-) This looks like it is indeed a HW problem with the ITX. Are you aware of any threads/documents describing the issue? We based our custom HW off the ITX schematic with regards to the CF, and I hope we didn't copy over _that_ problem :-/ Cheers, Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/10] mtd: remove code associated with !CONFIG_PPC_MERGE
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: Josh Boyer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Compact flash on mpc8349eITX
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 grabbed last week: U-Boot 1.3.4-rc1-00012-g1953d12 TIA for checking your itx with this version. U-Boot 1.3.4-rc1-00012-g1953d12 (Aug 1 2008 - 21:45:42) MPC83XX The CF still works. As for the backtrace you posted recently, I remeber I've noticed the similar issue long ago on some mITX board. I believe the board had hw issues indeed (or CF card I tested with). The problem could be in the IRQ line itself (for some reason it always low), or it could be IDE cmd/data lines at fault, so that IDE can't receive status read command and does not deassert the interrupt line... quite hard to tell. Thanks for confirming.. I was losing my mind :-) This looks like it is indeed a HW problem with the ITX. Are you aware of any threads/documents describing the issue? We based our custom HW off the ITX schematic with regards to the CF, and I hope we didn't copy over _that_ problem :-/ I don't think it was a hw design problem, more likely somebody fried the CF slot on that board (either by hot-plugging the CF, or via inserting CF 5V only flash.. either of this is forbidden for the 8349mITX boards). -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 09/10] pata_sil680: convert CONFIG_PPC_MERGE to CONFIG_PPC
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 --git a/drivers/ata/pata_sil680.c b/drivers/ata/pata_sil680.c index 720b864..9655511 100644 --- a/drivers/ata/pata_sil680.c +++ b/drivers/ata/pata_sil680.c @@ -230,7 +230,7 @@ static u8 sil680_init_chip(struct pci_dev *pdev, int *try_mmio) tmpbyte 1, tmpbyte 0x30); *try_mmio = 0; -#ifdef CONFIG_PPC_MERGE +#ifdef CONFIG_PPC if (machine_is(cell)) *try_mmio = (tmpbyte 1) || pci_resource_start(pdev, 5); #endif -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 10/10] mtd: remove code associated with !CONFIG_PPC_MERGE
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 |3 -
drivers/mtd/maps/ebony.c | 163 -
drivers/mtd/maps/ocotea.c | 154 --
drivers/mtd/maps/walnut.c | 122 -
5 files changed, 0 insertions(+), 466 deletions(-)
delete mode 100644 drivers/mtd/maps/ebony.c
delete mode 100644 drivers/mtd/maps/ocotea.c
delete mode 100644 drivers/mtd/maps/walnut.c
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index df8e00b..db667b1 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -332,30 +332,6 @@ config MTD_CFI_FLAGADM
Mapping for the Flaga digital module. If you don't have one, ignore
this setting.
-config MTD_WALNUT
- tristate Flash device mapped on IBM 405GP Walnut
- depends on MTD_JEDECPROBE WALNUT !PPC_MERGE
- help
- This enables access routines for the flash chips on the IBM 405GP
- Walnut board. If you have one of these boards and would like to
- use the flash chips on it, say 'Y'.
-
-config MTD_EBONY
- tristate Flash devices mapped on IBM 440GP Ebony
- depends on MTD_JEDECPROBE EBONY !PPC_MERGE
- help
- This enables access routines for the flash chips on the IBM 440GP
- Ebony board. If you have one of these boards and would like to
- use the flash chips on it, say 'Y'.
-
-config MTD_OCOTEA
- tristate Flash devices mapped on IBM 440GX Ocotea
- depends on MTD_CFI OCOTEA !PPC_MERGE
- help
- This enables access routines for the flash chips on the IBM 440GX
- Ocotea board. If you have one of these boards and would like to
- use the flash chips on it, say 'Y'.
-
config MTD_REDWOOD
tristate CFI Flash devices mapped on IBM Redwood
depends on MTD_CFI ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 6cda6df..b258250 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -50,9 +50,6 @@ obj-$(CONFIG_MTD_REDWOOD) += redwood.o
obj-$(CONFIG_MTD_UCLINUX) += uclinux.o
obj-$(CONFIG_MTD_NETtel) += nettel.o
obj-$(CONFIG_MTD_SCB2_FLASH) += scb2_flash.o
-obj-$(CONFIG_MTD_EBONY)+= ebony.o
-obj-$(CONFIG_MTD_OCOTEA) += ocotea.o
-obj-$(CONFIG_MTD_WALNUT)+= walnut.o
obj-$(CONFIG_MTD_H720X)+= h720x-flash.o
obj-$(CONFIG_MTD_SBC8240) += sbc8240.o
obj-$(CONFIG_MTD_NOR_TOTO) += omap-toto-flash.o
diff --git a/drivers/mtd/maps/ebony.c b/drivers/mtd/maps/ebony.c
deleted file mode 100644
index d92b7c7..000
--- a/drivers/mtd/maps/ebony.c
+++ /dev/null
@@ -1,163 +0,0 @@
-/*
- * Mapping for Ebony user flash
- *
- * Matt Porter [EMAIL PROTECTED]
- *
- * Copyright 2002-2004 MontaVista Software Inc.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include linux/module.h
-#include linux/types.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/mtd/mtd.h
-#include linux/mtd/map.h
-#include linux/mtd/partitions.h
-#include asm/io.h
-#include asm/ibm44x.h
-#include platforms/4xx/ebony.h
-
-static struct mtd_info *flash;
-
-static struct map_info ebony_small_map = {
- .name = Ebony small flash,
- .size = EBONY_SMALL_FLASH_SIZE,
- .bankwidth =1,
-};
-
-static struct map_info ebony_large_map = {
- .name = Ebony large flash,
- .size = EBONY_LARGE_FLASH_SIZE,
- .bankwidth =1,
-};
-
-static struct mtd_partition ebony_small_partitions[] = {
- {
- .name = OpenBIOS,
- .offset = 0x0,
- .size = 0x8,
- }
-};
-
-static struct mtd_partition ebony_large_partitions[] = {
- {
- .name = fs,
- .offset = 0,
- .size = 0x38,
- },
- {
- .name = firmware,
- .offset = 0x38,
- .size = 0x8,
- }
-};
-
-int __init init_ebony(void)
-{
- u8 fpga0_reg;
- u8 __iomem *fpga0_adr;
- unsigned long long small_flash_base, large_flash_base;
-
- fpga0_adr = ioremap64(EBONY_FPGA_ADDR, 16);
- if (!fpga0_adr)
- return -ENOMEM;
-
- fpga0_reg = readb(fpga0_adr);
- iounmap(fpga0_adr);
-
- if (EBONY_BOOT_SMALL_FLASH(fpga0_reg)
- !EBONY_FLASH_SEL(fpga0_reg))
- small_flash_base =
Re: [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
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 of KERNELBASE to use PAGE_OFFSET, instead. What do you do about the exception vectors? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/10] fs-enet: remove code associated with !CONFIG_PPC_MERGE
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 int fs_request_irq(struct net_device *dev, int
irq, const char *name,
{
struct fs_enet_private *fep = netdev_priv(dev);
- (*fep-ops-pre_request_irq)(dev, irq);
return request_irq(irq, irqf, IRQF_SHARED, name, dev);
}
This makes fep an unused variable. Eliminate this function entirely,
and call request_irq directly from the caller.
@@ -678,7 +677,6 @@ static void fs_free_irq(struct net_device *dev, int irq)
struct fs_enet_private *fep = netdev_priv(dev);
free_irq(irq, dev);
- (*fep-ops-post_free_irq)(dev, irq);
}
Likewise.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 MPC8xxx platform. Not just a different value, but a totally different internal clock. Sometimes is CCB, sometimes CCB/2, sometimes tsec2's clock, etc. On which SOC is it the tesc2 clock? 834x 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. Did I miss some? All 83xx other than 832x. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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; #elif defined(CONFIG_MPC831X) i2c1_clk = enc_clk; #elif defined(CONFIG_MPC837X) i2c1_clk = sdhc_clk; #endif #if !defined(CONFIG_MPC832X) i2c2_clk = csb_clk; /* i2c-2 clk is equal to csb clk */ #endif -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] Cell OProfile: SPU mutex lock fix, version 4
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 kernel buffer via a new Oprofile
function oprofile_put_buff(). The oprofile_put_buff() function
is called via a work queue enabling the funtion to acquire the
mutex lock.
The existing user controls for adjusting the per CPU buffer
size is used to control the size of the per SPU buffers.
Similarly, overflows of the SPU buffers are reported by
incrementing the per CPU buffer stats. This eliminates the
need to have architecture specific controls for the per SPU
buffers which is not acceptable to the OProfile user tool
maintainer.
The export of the oprofile add_event_entry() is removed as it
is no longer needed given this patch.
Note, this patch has not addressed the issue of indexing arrays
by the spu number. This still needs to be fixed as the spu
numbering is not guarenteed to be 0 to max_num_spus-1.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Signed-off-by: Maynard Johnson [EMAIL PROTECTED]
Index: Cell_kernel_6_26_2008/drivers/oprofile/cpu_buffer.c
===
--- Cell_kernel_6_26_2008.orig/drivers/oprofile/cpu_buffer.c
+++ Cell_kernel_6_26_2008/drivers/oprofile/cpu_buffer.c
@@ -37,11 +37,24 @@ static int work_enabled;
void free_cpu_buffers(void)
{
int i;
-
+
for_each_online_cpu(i)
vfree(per_cpu(cpu_buffer, i).buffer);
}
+unsigned long oprofile_get_cpu_buffer_size(void)
+{
+ return fs_cpu_buffer_size;
+}
+
+void oprofile_cpu_buffer_inc_smpl_lost(void)
+{
+ struct oprofile_cpu_buffer *cpu_buf
+ = __get_cpu_var(cpu_buffer);
+
+ cpu_buf-sample_lost_overflow++;
+}
+
int alloc_cpu_buffers(void)
{
int i;
Index: Cell_kernel_6_26_2008/include/linux/oprofile.h
===
--- Cell_kernel_6_26_2008.orig/include/linux/oprofile.h
+++ Cell_kernel_6_26_2008/include/linux/oprofile.h
@@ -84,13 +84,6 @@ int oprofile_arch_init(struct oprofile_o
void oprofile_arch_exit(void);
/**
- * Add data to the event buffer.
- * The data passed is free-form, but typically consists of
- * file offsets, dcookies, context information, and ESCAPE codes.
- */
-void add_event_entry(unsigned long data);
-
-/**
* Add a sample. This may be called from any context. Pass
* smp_processor_id() as cpu.
*/
@@ -160,5 +153,14 @@ int oprofilefs_ulong_from_user(unsigned
/** lock for read/write safety */
extern spinlock_t oprofilefs_lock;
+
+/**
+ * Add the contents of a circular buffer to the event buffer.
+ */
+void oprofile_put_buff(unsigned long *buf,unsigned int start,
+ unsigned int stop, unsigned int max);
+
+unsigned long oprofile_get_cpu_buffer_size(void);
+void oprofile_cpu_buffer_inc_smpl_lost(void);
#endif /* OPROFILE_H */
Index: Cell_kernel_6_26_2008/arch/powerpc/oprofile/cell/spu_profiler.c
===
--- Cell_kernel_6_26_2008.orig/arch/powerpc/oprofile/cell/spu_profiler.c
+++ Cell_kernel_6_26_2008/arch/powerpc/oprofile/cell/spu_profiler.c
@@ -23,12 +23,11 @@
static u32 *samples;
-static int spu_prof_running;
+int spu_prof_running;
static unsigned int profiling_interval;
#define NUM_SPU_BITS_TRBUF 16
#define SPUS_PER_TB_ENTRY 4
-#define SPUS_PER_NODE 8
#define SPU_PC_MASK 0x
@@ -208,6 +207,7 @@ int start_spu_profiling(unsigned int cyc
spu_prof_running = 1;
hrtimer_start(timer, kt, HRTIMER_MODE_REL);
+ schedule_delayed_work(spu_work, DEFAULT_TIMER_EXPIRE);
return 0;
}
Index: Cell_kernel_6_26_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
===
--- Cell_kernel_6_26_2008.orig/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ Cell_kernel_6_26_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -35,7 +35,106 @@ static DEFINE_SPINLOCK(buffer_lock);
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
int spu_prof_num_nodes;
-int last_guard_val[MAX_NUMNODES * 8];
+int last_guard_val[MAX_NUMNODES * SPUS_PER_NODE];
+static int spu_ctx_sw_seen[MAX_NUMNODES * SPUS_PER_NODE];
+static int sync_start_registered;
+static int delayed_work_init;
+
+struct spu_buffers spu_buff;
+struct delayed_work spu_work;
+static unsigned max_spu_buff;
+
+static void spu_buff_add(unsigned long int value, int spu)
+{
+ /* spu buff is a circular buffer. Add entries to the
+* head. Head is the index to store the next value.
+* The buffer is full when there is one available entry
+* in the queue, i.e. head and tail can't be equal.
+* That way we can tell the difference between the
+* buffer being
[PATCH 2/2] Cell OProfile: SPU mutex lock fix, version 4
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 that don't exist.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Index: Cell_kernel_6_26_2008/drivers/oprofile/cpu_buffer.c
===
--- Cell_kernel_6_26_2008.orig/drivers/oprofile/cpu_buffer.c
+++ Cell_kernel_6_26_2008/drivers/oprofile/cpu_buffer.c
@@ -38,8 +38,12 @@ void free_cpu_buffers(void)
{
int i;
- for_each_online_cpu(i)
- vfree(per_cpu(cpu_buffer, i).buffer);
+ for_each_online_cpu(i) {
+ if (per_cpu(cpu_buffer, i).buffer) {
+ vfree(per_cpu(cpu_buffer, i).buffer);
+ per_cpu(cpu_buffer, i).buffer = NULL;
+ }
+ }
}
unsigned long oprofile_get_cpu_buffer_size(void)
Index: Cell_kernel_6_26_2008/drivers/oprofile/event_buffer.c
===
--- Cell_kernel_6_26_2008.orig/drivers/oprofile/event_buffer.c
+++ Cell_kernel_6_26_2008/drivers/oprofile/event_buffer.c
@@ -92,7 +92,10 @@ out:
void free_event_buffer(void)
{
- vfree(event_buffer);
+ if (event_buffer)
+ vfree(event_buffer);
+
+ event_buffer = NULL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsl_soc: Remove some obsolete prototypes and headers.
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/powerpc/sysdev/fsl_soc.c @@ -27,8 +27,6 @@ #include linux/phy_fixed.h #include linux/spi/spi.h #include linux/fsl_devices.h -#include linux/fs_enet_pd.h -#include linux/fs_uart_pd.h #include asm/system.h #include asm/atomic.h @@ -40,9 +38,6 @@ #include mm/mmu_decl.h #include asm/cpm2.h -extern void init_fcc_ioports(struct fs_platform_info*); -extern void init_fec_ioports(struct fs_platform_info*); -extern void init_smc_ioports(struct fs_uart_platform_info*); static phys_addr_t immrbase = -1; phys_addr_t get_immrbase(void) -- 1.5.6.rc1.6.gc53ad.dirty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
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 that assume we are loaded at address 0, and by changing several uses of KERNELBASE to use PAGE_OFFSET, instead. What do you do about the exception vectors? Making a trampoline code in place of exception vectors. See this patch: [PATCH 8/8] powerpc: last bits to support kdump on ppc32 -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
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 _moved_ to u-boot, it's already there. U-boot needs it
because u-boot uses i2c.
It would need to be duplicated in linux, and then both u-boot and linux
would need to be updated each time a new platform is added.
It's pretty much a given that a u-boot binary will only work on one
platform. The same is not true with a compiled kernel. That makes it
harder to all the platform specific stuff in linux. It's a little more
than 10 lines too. Keep in mind that accessing all these devices registers
isn't as easy in linux as u-boot. In linux you have to look up the
register location in device tree and map the registers. All this code uses
a system clock as a starting point, which u-boot already passes to linux.
#if defined(CONFIG_MPC83XX)
volatile immap_t *im = (immap_t *) CFG_IMMR;
sccr = im-clk.sccr;
#if defined(CONFIG_MPC834X) || defined(CONFIG_MPC831X) ||
defined(CONFIG_MPC837X)
switch ((sccr SCCR_TSEC1CM) SCCR_TSEC1CM_SHIFT) {
case 0:
tsec1_clk = 0;
break;
case 1:
tsec1_clk = csb_clk;
break;
case 2:
tsec1_clk = csb_clk / 2;
break;
case 3:
tsec1_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_TSEC1CM value */
return -2;
}
#endif
#if defined(CONFIG_MPC834X) || defined(CONFIG_MPC837X) ||
defined(CONFIG_MPC8315)
switch ((sccr SCCR_TSEC2CM) SCCR_TSEC2CM_SHIFT) {
case 0:
tsec2_clk = 0;
break;
case 1:
tsec2_clk = csb_clk;
break;
case 2:
tsec2_clk = csb_clk / 2;
break;
case 3:
tsec2_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_TSEC2CM value */
return -4;
}
#elif defined(CONFIG_MPC8313)
tsec2_clk = tsec1_clk;
if (!(sccr SCCR_TSEC1ON))
tsec1_clk = 0;
if (!(sccr SCCR_TSEC2ON))
tsec2_clk = 0;
#endif
switch ((sccr SCCR_ENCCM) SCCR_ENCCM_SHIFT) {
case 0:
enc_clk = 0;
break;
case 1:
enc_clk = csb_clk;
break;
case 2:
enc_clk = csb_clk / 2;
break;
case 3:
enc_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_ENCCM value */
return -7;
}
#if defined(CONFIG_MPC837X)
switch ((sccr SCCR_SDHCCM) SCCR_SDHCCM_SHIFT) {
case 0:
sdhc_clk = 0;
break;
case 1:
sdhc_clk = csb_clk;
break;
case 2:
sdhc_clk = csb_clk / 2;
break;
case 3:
sdhc_clk = csb_clk / 3;
break;
default:
/* unkown SCCR_SDHCCM value */
return -8;
}
#endif
#if defined(CONFIG_MPC834X)
i2c1_clk = tsec2_clk;
#elif defined(CONFIG_MPC8360)
i2c1_clk = csb_clk;
#elif defined(CONFIG_MPC832X)
i2c1_clk = enc_clk;
#elif defined(CONFIG_MPC831X)
i2c1_clk = enc_clk;
#elif defined(CONFIG_MPC837X)
i2c1_clk = sdhc_clk;
#endif
#if !defined(CONFIG_MPC832X)
i2c2_clk = csb_clk; /* i2c-2 clk is equal to csb clk */
#endif
#elif defined (CONFIG_MPC85XX)
#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555)
gd-i2c1_clk = sys_info.freqSystemBus;
#elif defined(CONFIG_MPC8544)
volatile ccsr_gur_t *gur = (void *) CFG_MPC85xx_GUTS_ADDR;
/*
* On the 8544, the I2C clock is the same as the SEC clock. This can be
* either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See
* 4.4.3.3 of the 8544 RM. Note that this might actually work for all
* 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the
* PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544.
*/
if (gur-pordevsr2 MPC85xx_PORDEVSR2_SEC_CFG)
gd-i2c1_clk = sys_info.freqSystemBus / 3;
else
gd-i2c1_clk = sys_info.freqSystemBus / 2;
#else
/* Most 85xx SOCs use CCB/2, so this is the default behavior. */
gd-i2c1_clk = sys_info.freqSystemBus / 2;
#endif
gd-i2c2_clk = gd-i2c1_clk;
#elif defined(CONFIG_MPC86XX)
#ifdef CONFIG_MPC8610
gd-i2c1_clk = sys_info.freqSystemBus;
#else
gd-i2c1_clk = sys_info.freqSystemBus /
Re: ide pmac breakage
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
on more hardware but my time schedule is already tight enough and there are
still more fundamental things to address (which take priority). ]
-host-dev[0] = hws[0]-dev;
+host-dev[0] = hws[0]-parent ? hws[0]-parent :
hws[0]-dev;
Could you please try it together with my previous patch for
ide_device_{get,put}()?
Please test it when you have some time.
The problem in that case is access to the HW :-) I have plenty ide-pmac
based machines but only one or two old laptop (ie. Paul has one too)
with a media-bay and those are in the office. So I'll test on Monday
when I get there, unless I get a chance to pop by on Sunday but that's
unlikely.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 problem is; when the original board (the one others are claiming compatibility with) gains additional code to fixup quirks or something, then that code will get changed with no visibility that it is borking up other boards that are currently depending on it. Then just use your own .c file. It's not like it was a big deal. I don't know why it's -so- appealing to not have to do one at all. I far prefer the solution I'm currently using in 5200-land where there is a simple (boring?) board port which *explicitly* states which boards it supports (see arch/powerpc/platforms/52xx/mpc5200_simple.c). When someone goes to modify that file, it is explicit that it currently supports multiple boards. If a board becomes 'non-boring', then it is removed from the simple platform; the simple platform is *not* extended to accommodate it. As long as you stick to -never- extend the simple platform to accomodate for a variant, then I suppose that's ok I suppose, though that does raise the point of what to put in the compatible property. I *fully* agree that it is insane for the code to grow detection logic and I've been explicit about not doing anything of the sort in 5200 land. What I am suggesting is that if nothing else claims the board, then allow the simple platform to bind against it based on the fact that it uses the same SoC. See my comment in my reply to Josh about changing the board probe into a multi-pass probe so that first, we only match on the first entry of the compatible property, then we match on the second, etc... to go from more specific to less specific. However, if I can't get concensus on this approach, then I do /not/ want to go to a boards compatible with other boards scheme. It will cause breakage and pain that is non-obvious to debug for many users. As far as I'm concerned, this approach is mostly useful for revisions of a board. Oh and I'm not going to whack you with a stick if in the end, you do have a little bit of variation in a single board .c file to deal with a glitch in rev. C of the board that wired something backward for example ... it's a matter of perspective. But I would prefer a different board (from a different vendor for example) to use a different .c file even if it only differs by the same little glitch. BTW, I am also not suggesting that the .dts files themselves try to claim some kind of 'generic' compatibility. I'm proposing handling any catch-all cases in the Linux code itself, where it is easy to change because it is just an implementation detail. Trying to make the dt 'generic' doesn't make any sense because doing so is almost always wrong (or will become wrong in the future). The problem is that I don't see a sane way to do the catch all in the linux code, other than explicitely doing what you already do which is to list all supported boards in the simple platform. It's either that or adding some compatible socname,linux-simple or so property in your .dts. I don't believe matching on SoC is of any use. It will incorrectly try to match things that don't work and that's bad. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/10] powerpc: Remove use of CONFIG_PPC_MERGE
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.27? Yes, since it's just dead code removal. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Board level compatibility matching
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 identical in everything except name. By doing the library code approach, one still has to create a board.c file for a new board and plug in the library functions to ppc_md. And ? How is that a big deal ? Real products (ie not eval boards, and even those ...) will probably end up needing that due to subtle differences anyway. I didn't say it was a big deal. But I also think it's pretty pointless to carry around a bunch of C files that have to get the same set of fixes across the board when updated because they really only differ by the function names. Particularly when you could just have one C file with a list of supported boards. As I said, to me this is about cleanup and maintenance. I totally agree that truly custom boards (e.g. actual products) will likely require different board.c files and that's just fine with me. I'm just looking for the best approach to cleanup the ones that don't need to be, and the explicit list seems to be that way. Alternatively, you could do the: compatible = specific-board, similar-board approach that has been done for e.g. Bamboo and Yosemite. Again, the issue is that is that OK? Is it OK for a board to claim compatibility with another board when it might not have all the devices of that board, or might have additional devices, etc. I was of the opinion it is, and the device tree handles this just fine, as does the platform code. But it can be confusing, hence the discussion here. Well, as I said. If it stops being ok, just create your own board and it will take over provided you put it before the other one in the link order. If we generalize that approach, we might want to change the board probing code a bit to first do a full pass based on the first entry in compatible, then another full pass based on the second, etc... I don't care much either way. I guess I'd rather avoid relying on strict link order to do the probing right, if only because a simple mistake can break things. There might not be a one true way, but Grant and I thought it pertinent to bring up a discussion in case there was a very wrong way, that's all. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/10] powerpc: Remove use of CONFIG_PPC_MERGE
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 index 1ef8e30..a372f76 100644 --- a/include/asm-powerpc/irq.h +++ b/include/asm-powerpc/irq.h ... -#define SIU_INT_PC4 ((uint)0x3b + CPM_IRQ_OFFSET) -#define SIU_INT_PC3 ((uint)0x3c + CPM_IRQ_OFFSET) -#define SIU_INT_PC2 ((uint)0x3d + CPM_IRQ_OFFSET) -#define SIU_INT_PC1 ((uint)0x3e + CPM_IRQ_OFFSET) -#define SIU_INT_PC0 ((uint)0x3f + CPM_IRQ_OFFSET) - -#endif /* CONFIG_8260 */ - -#endif /* Whatever way too big #ifdef */ I'll miss that one, it made me laugh once. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
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 fails with build error snip Turning off GCOV fixes this. Not really the best solution but at least it narrows doen the search effort. Thanks. Peter, Can you have a look at how this can be fixed, if at all? Am not terribly happy with the state of the gcov patches. They STILL leave thousands of dead symlinks lying around after `make mrproper' This is caused by patch gcov-create-links-to-gcda-files-in-build-directory.patch which can be simply removed as it is no longer needed since patch gcov-add-gcov-profiling-infrastructure-revert-link-changes.patch has been added to -mm. and generally seem to muck up the kbuild system a bit, although nothing that a bit of Sam love wouldn't fix. Hm, by now the only change to kbuild is the addition of gcc options -fprofile-arcs/-ftest-coverage depending on the respective config symbols. If there is anything else that should be changed, please let me know. Plus it breaks the build on a few architectures (branch out of range, mainly), but that's a fairly minor thing which could even be worked around in Kconfig (disable the offending code if gcov is enabled) Some of the problems caused/uncovered by enabling gcov profiling for a kernel build on some architectures simply cannot be fixed by a change to the kernel patch itself. I'm wondering if it would be possible to disable this configuration option when specifying allyesconfig. That way at least generic testing wouldn't be affected. Regards, Peter ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD-FAILURE] 2.6.27-rc1-mm1 - allyesconfig build fails on powerpc
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 snip Turning off GCOV fixes this. Not really the best solution but at least it narrows doen the search effort. Peter, Can you have a look at how this can be fixed, if at all? I did some testing with a cross-compiler myself and I don't think there is a general solution to this problem. It's not one particular file that is causing the problem but seemingly the sheer size of the resulting vmlinux file - even though the toal vmlinux.o size is merely up about 100MiB (from around 1,03Gib to 1,13Gib). I think I'll need help from people with knowledge of the powerpc toolchain here. Regards, Peter ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] port ndfc driver to arch/powerpc
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/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 02f9cc3..b0d408e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -165,7 +165,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate NDFC NanD Flash Controller
- depends on 4xx !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 955959e..efb1ab6 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -21,14 +21,11 @@
#include linux/mtd/partitions.h
#include linux/mtd/ndfc.h
#include linux/mtd/mtd.h
+#include linux/proc_fs.h
+#include linux/seq_file.h
#include linux/platform_device.h
#include asm/io.h
-#ifdef CONFIG_40x
-#include asm/ibm405.h
-#else
-#include asm/ibm44x.h
-#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -103,8 +100,9 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
wmb();
ecc = __raw_readl(ndfc-ndfcbase + NDFC_ECC);
- ecc_code[0] = p[1];
- ecc_code[1] = p[2];
+ /* The NDFC uses Smart Media (SMC) bytes order */
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
@@ -234,11 +232,7 @@ static int ndfc_nand_probe(struct platform_device *pdev)
struct ndfc_controller *ndfc = ndfc_ctrl;
unsigned long long phys = settings-ndfc_erpn | res-start;
-#ifndef CONFIG_PHYS_64BIT
ndfc-ndfcbase = ioremap((phys_addr_t)phys, res-end - res-start + 1);
-#else
- ndfc-ndfcbase = ioremap64(phys, res-end - res-start + 1);
-#endif
if (!ndfc-ndfcbase) {
printk(KERN_ERR NDFC: ioremap failed\n);
return -EIO;
@@ -300,9 +294,16 @@ static int __init ndfc_nand_init(void)
init_waitqueue_head(ndfc_ctrl.ndfc_control.wq);
ret = platform_driver_register(ndfc_nand_driver);
- if (!ret)
- ret = platform_driver_register(ndfc_chip_driver);
- return ret;
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(ndfc_chip_driver);
+ if (ret) {
+ platform_driver_unregister(ndfc_nand_driver);
+ return ret;
+ }
+
+ return 0;
}
static void __exit ndfc_nand_exit(void)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: platforms/44x/warp-nand.c bogosity
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 going to look into wrt u-boot. This may need to be a config option. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
