* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Domen Puncer @ 2007-10-19 11:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20071017163555.24992.40095.stgit@trillian.cg.shawcable.net>
On 17/10/07 10:36 -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Only the MPC5200 needs this bug fix. MPC5200B is okay.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Sven, Domen;
>
> Can you please test this patch?
I found no obvious problems with it on Efika (mpc5200b)
Domen
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-19 11:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18199.63230.583536.307945@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
>>>What problem do you see arising from this?
>> Timers firing too early.
> Only if the minimum interrupt latency is less than 1 decrementer
> tick. That seems pretty unlikely to me unless you have a very slow
> timebase frequency.
Well, MPC8540 has 825 MHz CPU clock yet decrementor/timebase are clocked
with 25 MHz clock if I don't mistake. That gives us 33 CPU clocks of available
interrupt latency...
> In fact what we should program the decrementer to is:
> timeout - (is_booke? 0: 1) - min_interrupt_latency
BTW, why not handle the decrementer difference right in set_dec() where we
already have #ifdef'ed code?
> I was assuming that min_interrupt_latency (measured in timebase ticks)
> would be at least 1, but apparently some systems can have a timebase
> frequency as low as 1kHz, so we'll have to have an ifdef or something.
IMHO it's better to have #ifdef based on the decremeter model and forget
about the whole issue, rather than to #ifdef based on some bizarre system with
slowish decremeter, isn't it?
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Valentine Barshak @ 2007-10-19 11:56 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200710151529.11485.sr@denx.de>
Please, take a look at my comments below
Stefan Roese wrote:
> This patch reworks existing ibm-iic driver to support of_platform_device
> and enables it to talk to device tree directly. The "old" OCP interface
> for arch/ppc is still supported via #ifdef's and shall be removed when
> arch/ppc is gone in a few months.
>
> This is done to enable I2C support for the PPC4xx platforms now
> being moved from arch/ppc (ocp) to arch/powerpc (of).
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-ibm_iic.c | 209 +++++++++++++++++++++++++++++++++++++-
> drivers/i2c/busses/i2c-ibm_iic.h | 2 +
> 3 files changed, 211 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index de95c75..a47b5e6 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -241,7 +241,7 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on 4xx
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
> index 956b947..78c6bf4 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.c
> +++ b/drivers/i2c/busses/i2c-ibm_iic.c
> @@ -39,8 +39,13 @@
> #include <asm/io.h>
> #include <linux/i2c.h>
> #include <linux/i2c-id.h>
> +
> +#ifdef CONFIG_PPC_MERGE
> +#include <linux/of_platform.h>
> +#else
> #include <asm/ocp.h>
> #include <asm/ibm4xx.h>
> +#endif
>
> #include "i2c-ibm_iic.h"
>
> @@ -57,6 +62,10 @@ static int iic_force_fast;
> module_param(iic_force_fast, bool, 0);
> MODULE_PARM_DESC(iic_fast_poll, "Force fast mode (400 kHz)");
>
> +#ifdef CONFIG_PPC_MERGE
> +static int device_idx = -1;
> +#endif
> +
> #define DBG_LEVEL 0
>
> #ifdef DBG
> @@ -660,8 +669,205 @@ static inline u8 iic_clckdiv(unsigned int opb)
> /*
> * Register single IIC interface
> */
> -static int __devinit iic_probe(struct ocp_device *ocp){
>
> +#ifdef CONFIG_PPC_MERGE
> +/*
> + * device-tree (of) when used from arch/powerpc
> + */
> +static int __devinit iic_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct ibm_iic_private* dev;
> + struct i2c_adapter* adap;
> + struct device_node *np;
> + int ret = -ENODEV;
> + int irq, len;
> + const u32 *prop;
> + struct resource res;
> +
> + np = ofdev->node;
> + if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to allocate device data\n",
> + np->full_name);
> + return -ENOMEM;
> + }
> +
> + dev_set_drvdata(&ofdev->dev, dev);
> +
> + dev->np = np;
> + irq = irq_of_parse_and_map(np, 0);
In case of an error irq might be NO_IRQ here (0)
This could cause problems in chacking the mode (irq or poll) later.
> +
> + if (of_address_to_resource(np, 0, &res)) {
> + printk(KERN_ERR "ibd-iic(%s): Can't get registers address\n",
> + np->full_name);
> + goto fail1;
> + }
> + dev->paddr = res.start;
> +
> + if (!request_mem_region(dev->paddr, sizeof(struct iic_regs), "ibm_iic")) {
> + ret = -EBUSY;
> + goto fail1;
> + }
> + dev->vaddr = ioremap(dev->paddr, sizeof(struct iic_regs));
> +
> + if (dev->vaddr == NULL) {
> + printk(KERN_CRIT "ibm-iic(%s): failed to ioremap device regs\n",
> + dev->np->full_name);
> + ret = -ENXIO;
> + goto fail2;
> + }
> +
> + init_waitqueue_head(&dev->wq);
> +
> + dev->irq = iic_force_poll ? -1 : (irq == NO_IRQ) ? -1 : irq;
> + if (dev->irq >= 0){
If irq equals NO_IRQ (irq == 0) we shouldn't assume interrupt mode here.
I'd suggest to update the driver to use (irq != NO_IRQ) checks instead
of (irq >=0)
> + /* Disable interrupts until we finish initialization,
> + * assumes level-sensitive IRQ setup...
> + */
> + iic_interrupt_mode(dev, 0);
> + if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)) {
> + printk(KERN_ERR "ibm-iic(%s): request_irq %d failed\n",
> + dev->np->full_name, dev->irq);
> + /* Fallback to the polling mode */
> + dev->irq = -1;
> + }
> + }
> +
> + if (dev->irq < 0)
> + printk(KERN_WARNING "ibm-iic(%s): using polling mode\n",
> + dev->np->full_name);
> +
> + /* Board specific settings */
> + prop = of_get_property(np, "iic-mode", &len);
> + /* use 400kHz only if stated in dts, 100kHz otherwise */
> + dev->fast_mode = (prop && (*prop == 400));
> + /* clckdiv is the same for *all* IIC interfaces,
> + * but I'd rather make a copy than introduce another global. --ebs
> + */
> + /* Parent bus should have frequency filled */
> + prop = of_get_property(of_get_parent(np), "clock-frequency", &len);
> + if (prop == NULL) {
> + printk(KERN_ERR
> + "ibm-iic(%s):no clock-frequency prop on parent bus!\n",
> + dev->np->full_name);
> + goto fail;
> + }
> +
[ snip ]
> + dev->clckdiv = iic_clckdiv(*prop);
> + DBG("%s: clckdiv = %d\n", dev->np->full_name, dev->clckdiv);
> +
> + /* Initialize IIC interface */
> + iic_dev_init(dev);
> +
> + /* Register it with i2c layer */
> + adap = &dev->adap;
> + adap->dev.parent = &ofdev->dev;
> + strcpy(adap->name, "IBM IIC");
> + i2c_set_adapdata(adap, dev);
> + adap->id = I2C_HW_OCP;
> + adap->class = I2C_CLASS_HWMON;
> + adap->algo = &iic_algo;
> + adap->client_register = NULL;
> + adap->client_unregister = NULL;
> + adap->timeout = 1;
> + adap->retries = 1;
> +
> + dev->idx = ++device_idx;
> + adap->nr = dev->idx;
> + if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
[ snip ]
This stuff might be extracted into the common init function.
Something like this:
static int iic_adap_add(struct ibm_iic_private *dev, unsigned int opb)
{
struct i2c_adapter *adap;
/* clckdiv is the same for *all* IIC interfaces,
* but I'd rather make a copy than introduce another global. --ebs
*/
dev->clckdiv = iic_clckdiv(opb);
DBG("%d: clckdiv = %d\n", dev->idx, dev->clckdiv);
/* Initialize IIC interface */
iic_dev_init(dev);
/* Register it with i2c layer */
adap = &dev->adap;
strcpy(adap->name, "IBM IIC");
i2c_set_adapdata(adap, dev);
adap->id = I2C_HW_OCP;
adap->class = I2C_CLASS_HWMON;
adap->algo = &iic_algo;
adap->client_register = NULL;
adap->client_unregister = NULL;
adap->timeout = 1;
adap->retries = 1;
return i2c_add_adapter(adap);
}
Though, I really don't care, since OCP part is dying.
> + printk(KERN_CRIT"ibm-iic(%s): failed to register i2c adapter\n",
> + dev->np->full_name);
> + goto fail;
> + }
> +
> + printk(KERN_INFO "ibm-iic(%s): using %s mode\n", dev->np->full_name,
> + dev->fast_mode ?
> + "fast (400 kHz)" : "standard (100 kHz)");
> +
> + return 0;
> +
> +fail:
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
Please, add a call to irq_dispose_mapping(dev->irq);
> + }
> +
> + iounmap(dev->vaddr);
> +fail2:
> + release_mem_region(dev->paddr, sizeof(struct iic_regs));
> +fail1:
> + dev_set_drvdata(&ofdev->dev, NULL);
> + kfree(dev);
> +
> + return ret;
> +}
> +
> +/*
> + * Cleanup initialized IIC interface
> + */
> +static int __devexit iic_remove(struct of_device *ofdev)
> +{
> + struct ibm_iic_private *dev =
> + (struct ibm_iic_private *)dev_get_drvdata(&ofdev->dev);
> + BUG_ON(dev == NULL);
> + if (i2c_del_adapter(&dev->adap)){
> + printk(KERN_CRIT "ibm-iic(%s): failed to delete i2c adapter\n",
> + dev->np->full_name);
> + /* That's *very* bad, just shutdown IRQ ... */
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + dev->irq = -1;
> + }
> + } else {
> + if (dev->irq >= 0){
> + iic_interrupt_mode(dev, 0);
> + free_irq(dev->irq, dev);
> + }
This can be reorganized to switch to poll mode, diapose irq and check
i2c_del_adapter retval after that, instead of duplicating the free_irq
stuff.
Also irq_dispose_mapping(dev->irq); should be added:
.........
int retval;
retval = i2c_del_adapter(&dev->adap);
if (dev->irq != NO_IRQ) {
iic_interrupt_mode(dev, 0);
free_irq(dev->irq, dev);
irq_dispose_mapping(dev->irq);
}
if (retval) {
printk(KERN_CRIT "ibm-iic(%s): failed to delete i2c adapter :(\n",
dev->np->full_name);
/* That's *very* bad, just shutdown IRQ ... */
dev->irq = NO_IRQ;
return 0;
}
iounmap(dev->vaddr);
.......
> + iounmap(dev->vaddr);
> + release_mem_region(dev->paddr, sizeof(struct iic_regs));
> + kfree(dev);
> + }
> + return 0;
> +}
> +
> +static struct of_device_id ibm_iic_match[] = {
> + {
> + .type = "i2c",
> + .compatible = "ibm,iic",
> + },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, ibm_iic_match);
> +
> +static struct of_platform_driver ibm_iic_driver = {
> + .name = "ibm-iic",
> + .match_table = ibm_iic_match,
> + .probe = iic_probe,
> + .remove = iic_remove,
> +#if defined(CONFIG_PM)
> + .suspend = NULL,
> + .resume = NULL,
> +#endif
> +};
> +
> +static int __init iic_init(void)
> +{
> + printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
> + return of_register_platform_driver(&ibm_iic_driver);
> +}
> +
> +static void __exit iic_exit(void)
> +{
> + of_unregister_platform_driver(&ibm_iic_driver);
> +}
> +#else
> +/*
> + * OCP when used from arch/ppc
> + */
> +static int __devinit iic_probe(struct ocp_device *ocp)
> +{
> struct ibm_iic_private* dev;
> struct i2c_adapter* adap;
> struct ocp_func_iic_data* iic_data = ocp->def->additions;
> @@ -828,6 +1034,7 @@ static void __exit iic_exit(void)
> {
> ocp_unregister_driver(&ibm_iic_driver);
> }
> +#endif /* CONFIG_PPC_MERGE */
>
> module_init(iic_init);
> module_exit(iic_exit);
> diff --git a/drivers/i2c/busses/i2c-ibm_iic.h b/drivers/i2c/busses/i2c-ibm_iic.h
> index fdaa482..c15b091 100644
> --- a/drivers/i2c/busses/i2c-ibm_iic.h
> +++ b/drivers/i2c/busses/i2c-ibm_iic.h
> @@ -50,6 +50,8 @@ struct ibm_iic_private {
> int irq;
> int fast_mode;
> u8 clckdiv;
> + struct device_node *np;
> + phys_addr_t paddr;
> };
>
> /* IICx_CNTL register */
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Josh Boyer @ 2007-10-19 11:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <12EA14AC-6A3E-4322-9083-0C18996EC227@kernel.crashing.org>
On Thu, 18 Oct 2007 22:20:49 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote:
>
> > Kumar Gala writes:
> >
> >> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> >
> > Your commit message doesn't give any reason why you are doing this, or
> > any explanation of what goes wrong without it. In fact, the commit
> > message is completely empty. :) Please resubmit with a decent commit
> > message.
>
> I will, just as an FYI I based this on your commit for -mno-altivec
> (which has no rationale for the commit) :)
Do as he says, not as he does! ;)
josh
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-19 12:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18200.3600.459275.823335@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Sergei Shtylyov writes:
>> And now you have incomplete read_persistent_clock() implementation for
> I don't see anything incomplete about it. If you do, feel free to
> post a patch.
The xtime_lock is still grabbed by time_init()
>>example, god knows why it was preferred to mine -- well, it also implemented
> Your most recent post of your patch to implement read_persistent_clock
> was in May -- five months ago -- and you said this about it: "This
Right, the most recent was in May but that was only a recast of the
October version (i.e. year old) -- that patch got somehow dropped from later
the -rt patches IIRC.
> patch hasn't received a good testing though".
Right, it never has been tested on macines with RTC. That was a fair
warning. :-)
> You don't have to be a god to figure out why I preferred a patch that
> had been tested, where the author was responding to comments and
> posting updated versions of his patch in the period leading up to the
> merge window, over that.
Unfortunately, I didn't have time to try pusing it into every -rc1 since
2.6.18 -- there has been experimental hrtimers patchset at that time with even
x86 stuff being unmerged to mainline, so the stuff could only be pushed into
that patchset last autumn. I was going to try addressing vDSO stuff, yet there
has been too much work aside of that. Still, I've answered the mails. :-)
>> I just wanted the reasons clarified and got what I wanted -- as I thought,
>>the decision behind preferring patches was somewhat biased, nobody really
>>cared about code quality or just wasn't familiar with hrtimers enough to judge
>>on the code quality...
> You really know how to persuade people to cooperate, don't you... :P
Well, I'm not persuading anybody, sine I don't believe that I can persuade
somebody to do my work, so had to just vainly complain :-).
However, I agree that my complaints/ comments might have been somewhat
rash and unjust -- Tony's patches are *not* that bad after all. :-)
The only thing I'm still unusre about is that deterministic accounting.
Could you point me at the patch which deals with this (at least for System 390
:-)?
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-19 12:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <471899D1.2000903@ru.mvista.com>
Sergei Shtylyov writes:
> BTW, why not handle the decrementer difference right in set_dec() where we
> already have #ifdef'ed code?
Excellent idea. Let's do that.
Paul.
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Paul Mackerras @ 2007-10-19 12:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <47189EF3.7010103@ru.mvista.com>
Sergei Shtylyov writes:
> The xtime_lock is still grabbed by time_init()
That was left in there because we are setting sys_tz and do_gtod, and
do_gtod at least is only updated with the xtime_lock held. Of course,
at that early stage in the boot process, no lock is really needed, but
xtime_lock was taken for consistency with other code.
In fact there's quite a lot of stuff in there that could be removed
now. I also want to make the vdso use an algorithm more like what
getnstimeofday does.
> The only thing I'm still unusre about is that deterministic accounting.
> Could you point me at the patch which deals with this (at least for System 390
See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
for posts to lkml by Christian Borntraeger, who has been pursuing the
issue (subject "Re: [stable] 2.6.23 regression: top displaying 9999%
CPU usage").
Paul.
^ permalink raw reply
* Re: [PATCH] [POWERPC] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Jon Loeliger @ 2007-10-19 12:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <12EA14AC-6A3E-4322-9083-0C18996EC227@kernel.crashing.org>
So, like, the other day Kumar Gala mumbled:
>
> On Oct 18, 2007, at 6:19 PM, Paul Mackerras wrote:
>
> > Your commit message doesn't give any reason why you are doing this, or
> > any explanation of what goes wrong without it. In fact, the commit
> > message is completely empty. :) Please resubmit with a decent commit
> > message.
>
> I will, just as an FYI I based this on your commit for -mno-altivec
> (which has no rationale for the commit) :)
Hmmm. And also, let's not forget that the mail Subject: line
does contribute to the git log commit message as well.
Thanks,
jdl
^ permalink raw reply
* [POWERPC v2] powerpc: Add -mno-spe for ARCH=powerpc builds
From: Kumar Gala @ 2007-10-19 13:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <E1IirI4-0004Ch-3P@jdl.com>
Newer GCC's are capable of autovectorization for ISA extensions like
AltiVec and SPE. If we happen to build with one of those compilers we
will get SPE instructions in random kernel code. Today we only allow
basic interger code in the kernel and FP, AltiVec, or SPE in special
explicit locations that have handled the proper saving and restoring of
the register state (since on uniprocessor we lazy context switch the
register state for FP, AltiVec, and SPE).
-mno-spe disables the compiler for automatically generating SPE
instructions without our knowledge.
---
Hopefully this is up to Paul's double standard :)
(as normal, its in my git tree, posted here for review).
arch/powerpc/Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 4e16534..bd87626 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -107,6 +107,9 @@ endif
# No AltiVec instruction when building kernel
KBUILD_CFLAGS += $(call cc-option,-mno-altivec)
+# No SPE instruction when building kernel
+KBUILD_CFLAGS += $(call cc-option,-mno-spe)
+
# Enable unit-at-a-time mode when possible. It shrinks the
# kernel considerably.
KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH v3 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-19 13:04 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BCD@zch01exm26.fsl.freescale.net>
>>>>
>>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>>>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> [snip]
>>>> + soc837x@e0000000 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + device_type = "soc";
>>>> + ranges = <0 e0000000 00100000>;
>>>> + reg = <e0000000 00000200>;
>>>> + bus-frequency = <0>;
>>>> +
>>>> + wdt@200 {
>>>> + device_type = "watchdog";
>>>
>>> Drop this device_type.
>>>
>>>> + compatible = "mpc83xx_wdt";
>>>> + reg = <200 100>;
>>>> + };
>>>> +
>>>> + i2c@3000 {
>>>> + device_type = "i2c";
>>>
>>> And this one.
>>
>> I've asked Leo to leave this one as all other fsl boards do
>> this and the code depends on it. There was some discussion
>> about this but I wasn't sure if it was closed or not.
>
> I'm afraid not only i2c but also watchdog and spi need device_type
> now.
> Shall we proceed removing the type check?
We are NOT changing that code until 2.6.25.
- k
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-10-19 13:05 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev list, Tabi Timur-B04825
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5C9B@zch01exm26.fsl.freescale.net>
>>>>>> Export symbols of qe_lib to be used by QE drivers.
>>>>>>
>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
>>>>>> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
>>>>>> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
>>>>>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>>>>
>>
>> What happened with this?
>
> This has been merged as commit
> 65482ccf9d00bf4f68e17eb9c656d045d26e5d1f.
Ignore me I see the commit. Timur will just need to EXPORT_SYMBOL()
what additional functions he needs for the uart driver.
- k
^ permalink raw reply
* Re: Building zImage
From: Kumar Gala @ 2007-10-19 13:07 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7D8D790@corpexc01.corp.networkrobots.com>
On Oct 18, 2007, at 6:22 PM, Siva Prasad wrote:
> Hi,
>
> When I tried to build zImage (make zImage V=1) based on the 2.6.19
> kernel for 8641HPCN board, I got the following error...
>
> make -f scripts/Makefile.build obj=lib
> make -f
> /export/beavis/work/sprasad/2.6.19/linux-2.6.19/scripts/
> Makefile.modpost
> vmlinux
> scripts/mod/modpost -m -o
> /export/beavis/work/sprasad/2.6.19/linux-2.6.19/Module.symvers
> vmlinux
> rm -f .old_version
> make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> arch/powerpc/boot/zImage
> ln: accessing `arch/powerpc/boot/zImage': No such file or directory
> make[1]: *** [arch/powerpc/boot/zImage] Error 1
> make: *** [zImage] Error 2
>
> When I looked into the Makefile, "image-y" was having no value. So,
> "ln"
> was failing. Do I have to select one of the below options of zImage. I
> am not really sure which one to use for 8641 supported by FreeScale.
>
> image-$(CONFIG_PPC_PSERIES) += zImage.pseries
> image-$(CONFIG_PPC_MAPLE) += zImage.pseries
> image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
> image-$(CONFIG_PPC_CHRP) += zImage.chrp
> image-$(CONFIG_PPC_PMAC) += zImage.pmac
> image-$(CONFIG_DEFAULT_UIMAGE) += uImage
>
> Well!... we are not using U-Boot, so uImage is not an option, and that
> builds fine.
>
> Any way, I tried to make uImage, but I am not sure if it is including
> the dts file in the final uImage built, as the wrapper was passed the
> value of platform as "uboot". I am confused.
>
> Thanks for your help in advance.
uImage's do NOT include device trees as part of the image.
- k
^ permalink raw reply
* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Grant Likely @ 2007-10-19 13:09 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-dev
In-Reply-To: <20071019112916.GE27403@nd47.coderock.org>
On 10/19/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 17/10/07 10:36 -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Only the MPC5200 needs this bug fix. MPC5200B is okay.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > Sven, Domen;
> >
> > Can you please test this patch?
>
> I found no obvious problems with it on Efika (mpc5200b)
Cool, I'll add it to my list of patches for Paulus to pull
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
From: Kumar Gala @ 2007-10-19 13:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <20071019104318.edfd2ad1.sfr@canb.auug.org.au>
On Oct 18, 2007, at 7:43 PM, Stephen Rothwell wrote:
> On Thu, 18 Oct 2007 23:04:02 +0800 Li Yang <leoli@freescale.com>
> wrote:
>>
>> +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
>> +static void __init mpc837x_mds_setup_arch(void)
>> +{
>> +#ifdef CONFIG_PCI
>> + struct device_node *np;
>> +#endif
>> +
>> + if (ppc_md.progress)
>> + ppc_md.progress("mpc837x_mds_setup_arch()", 0);
>> +
>> +#ifdef CONFIG_PCI
>> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
>
> for_each_node_by_type(np, "pci")
>
>> +static int __init mpc837x_mds_probe(void)
>> +{
>> + unsigned long root = of_get_flat_dt_root();
>> +
>> + return of_flat_dt_is_compatible(root, "fsl,mpc837xmds");
>
> To call these two routines, you should include <asm/prom.h> directly.
what's the rule of thumb to know when to include <asm/prom.h> does
everything starting with of_flat_* come from there?
- k
^ permalink raw reply
* Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
From: Kumar Gala @ 2007-10-19 13:10 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Phillips Kim-R1AAHA, paulus, David Gibson
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5C7A@zch01exm26.fsl.freescale.net>
On Oct 19, 2007, at 2:31 AM, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: David Gibson [mailto:david@gibson.dropbear.id.au]
>> Sent: Friday, October 19, 2007 8:56 AM
>> To: Li Yang-r58472
>> Cc: galak@kernel.crashing.org; paulus@samba.org;
>> linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH v5 9/9] add MPC837x MDS board default device tree
>>
>> On Thu, Oct 18, 2007 at 06:16:20PM +0800, Li Yang wrote:
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> new file mode 100644
>>> index 0000000..8530de6
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
>>> @@ -0,0 +1,282 @@
>> [snip]
>>> + crypto@30000 {
>>> + model = "SEC3";
>>> + compatible = "talitos";
>>
>> That compatible doesn't look specific enough. It should at
>> least have a vendor portion. In general it's best to have
>> all the information you need to pick a driver and options in
>> compatible, rather than splitting that info into model.
>
> I think we could do this in a separate patch. Change the spec and
> then
> update all the in-tree device tree with SEC node.
agreed.
- k
^ permalink raw reply
* Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Kumar Gala @ 2007-10-19 13:23 UTC (permalink / raw)
To: cbou; +Cc: linuxppc-dev
In-Reply-To: <20071018222927.GA1475@zarina>
On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
> [...]
>>> +
>>> + flash@0,0 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>>> + reg = <0 0 2000000>;
>>> + bank-width = <2>;
>>> + device-width = <1>;
>>> +
>>
>> Are you basing the partition map on something or making it up?
>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>> rootfs?
>
> I'm making it up. From the brief look at the u-boot* git sources,
> there is no `flashboot` yet, thus I'm free to make this up...
>
> I've partitioned this flash based on these thoughts:
>
> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
> create just 64 bytes partition;
this makes sense.
> 2. Kernel - 2MB, should be enough for bootup kernels?
seems reasonable.
> 3. Rootfs - the rest up to...
do we need a small section for the device tree?
> 4. U-Boot at the end.
can we reorder partitions? not sure if there is any value in having
the things we know will always be there like hrcw & u-boot at fixed
mtd0, mtd1, etc.
>
> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>
> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
> there was flashboot, most probably.. I'll find the CD to look this
> up.
Yeah I have no idea what we ship w/regards to the BSPs.
- k
^ permalink raw reply
* Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
From: Kumar Gala @ 2007-10-19 13:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18199.60025.563689.10810@cargo.ozlabs.ibm.com>
On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote:
> Yuri Tikhonov writes:
>
>> The following patch adds support for 256KB PAGE_SIZE on ppc44x-
>> based boards.
>> The applications to be run on the kernel with 256KB PAGE_SIZE have
>> to be
>> built using the modified version of binutils, where the MAXPAGESIZE
>> definition is set to 0x40000 (as opposite to standard 0x10000).
>
> Have you measured the performance using a 64kB page size? If so, how
> does it compare with the 256kB page size?
I was wondering about this as well? Isn't this technically in
violation of the ABI?
- k
^ permalink raw reply
* Re: [PATCH v2 3/4] Implement clockevents driver for powerpc
From: Sergei Shtylyov @ 2007-10-19 13:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Thomas Gleixner, Realtime Kernel
In-Reply-To: <18200.42194.853246.935329@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
>> The xtime_lock is still grabbed by time_init()
Oops, I got distracted and hadn't finish the passage.
My patch got rid of this xtime_lock stuff -- but this was in a different
context, with all vDSO initialization code in between being killed by John's
patch. I'm not sure it still has sense to hold this lock in time_init()
around that initialization...
> That was left in there because we are setting sys_tz
My patch moved that to read_persistent_clock()...
> and do_gtod, and do_gtod at least is only updated with the xtime_lock held.
> Of course, at that early stage in the boot process, no lock is really needed, but
> xtime_lock was taken for consistency with other code.
Thanks for claryfing this.
>> The only thing I'm still unusre about is that deterministic accounting.
>>Could you point me at the patch which deals with this (at least for System 390
> See efe567fc8281661524ffa75477a7c4ca9b466c63 in Linus' tree, and look
Wait, how this is related to the hrtimer's event handlers not being able
to call account_process_time() from arch/powerpc/kernel/time.c instead of
update_process_timess()?
> for posts to lkml by Christian Borntraeger, who has been pursuing the
> issue (subject "Re: [stable] 2.6.23 regression: top displaying 9999%
> CPU usage").
Fun. :-)
> Paul.
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Medve Emilian-EMMEDVE1 @ 2007-10-19 13:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071018.173032.48505868.davem@davemloft.net>
Hello David
> It only kills the warning on 32-bit systems, the cast is wrong
> either way.
I'm not aware of the QE being present on any 64-bit PowerPC. However,
porting the entire driver to a 64-bit platform is an exercise in itself
as many other things would need tweaking the QE hardware itself. But
that's an orthogonal issue. For now I just want to fix that warning.
>=20
> > ugeth->tx_bd_ring_offset[j] =3D
> > - kmalloc((u32) (length + align),=20
> GFP_KERNEL);
> > + (u32)kmalloc(length + align,=20
> GFP_KERNEL);
> > =20
> > if (ugeth->tx_bd_ring_offset[j] !=3D 0)
> > ugeth->p_tx_bd_ring[j] =3D
>=20
> Pointers can be up to "unsigned long" in size, therefore that
> is the minimal amount of storage you need to store them into
> if they are needed in integer form for some reason.
>=20
> Any cast from pointer to integer like this is a huge red flag.
Agreed, but again, I'm not trying to fix the entire driver or to port it
to a different architecture.
For the current situation, 32-bit QE, 32-bit PowerPC, do you find the
patch acceptable?
Cheers,
Emil.
^ permalink raw reply
* Re: [PATCH v6 4/9] add platform support for MPC837x MDS board
From: Stephen Rothwell @ 2007-10-19 13:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <044B09E9-2B1B-4BCC-BDFD-31269E41CC8F@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
On Fri, 19 Oct 2007 08:10:00 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> what's the rule of thumb to know when to include <asm/prom.h> does
> everything starting with of_flat_* come from there?
Basically anything that deals with the flattened device tee should
include asm/prom.h. This may change in the future, but that will be my
problem. linux/of.h should be included for dealing with the unflattened
device tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Linux root file system with X window support for a powerpc board
From: mahendra varman @ 2007-10-19 14:00 UTC (permalink / raw)
To: XFree86
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
Hi all
Can anybody help me how to create a Linux root file system with X window
support for a powerpc 74xx based board ?
Any documents/links related to that is also welcome
Thanks in advance
R.Mahendravarman
[-- Attachment #2: Type: text/html, Size: 251 bytes --]
^ permalink raw reply
* Re: SystemACE driver problem
From: Grant Likely @ 2007-10-19 14:04 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13290652.post@talk.nabble.com>
On 10/19/07, aauer1 <aauer1@gmx.at> wrote:
>
> Hello
>
> I'm trying to boot a Linux Kernel 2.6.23-rc2 from Grant Likely (thanks for
> the great work) on a Xilinx ML403 board. I want to use the second partition
> of the Compact Flash Card as root filesystem. But the boot process hangs at
> the initialization of the SystemACE module. A strange effect is that the
> DONE LED (configuration of the FPGA is done) turns off. So, this means that
> the FPGA loses his configuration.
> Has anybody recognized a similar problem with the SystemACE module??
>
> The boot log:
> ========
> [ 0.000000] Linux version 2.6.23-rc2 (bbauer@soclin) (gcc version 4.0.0
> (DEN7
> [ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0 -> 16384
> [ 0.000000] Normal 16384 -> 16384
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[1] active PFN ranges
> [ 0.000000] 0: 0 -> 16384
> [ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
> [ 0.000000] Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
> [ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> [ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
> [ 0.000328] Console: colour dummy device 80x25
> [ 0.001390] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> [ 0.002934] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> [ 0.029759] Memory: 63244k available (1176k kernel code, 388k data, 84k
> init)
> [ 0.120774] Mount-cache hash table entries: 512
> [ 0.171986] io scheduler noop registered
> [ 0.172248] io scheduler anticipatory registered (default)
> [ 0.172300] io scheduler deadline registered
> [ 0.172508] io scheduler cfq registered
> [ 0.268807] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a uartlite
> [ 0.270399] console [ttyUL0] enabled
> [ 1.762725] RAMDISK driver initialized: 8 RAM disks of 8192K size 1024
> blocke
> [ 1.852062] Registering Xilinx SystemACE driver, major=254
> [ 1.919734] xsysace xsysace.0: ace_probe(c01638e0)
Yes, I've seen that. It means something went wrong with the setup and
caused the sysace to reload the FPGA. Is the systemace base address
and bus width set correctly?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* FDT bindings for I2C devices
From: Wolfgang Grandegger @ 2007-10-19 14:12 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
is it forseen to define and configure devices like RTC, temperature
sensors or EEPROM on the I2C bus with the Flat Device Tree? If yes, how
would the DTS entries look like?
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [PATCH v3 2/2] [POWERPC] MPC8568E-MDS: add support for flash
From: Anton Vorontsov @ 2007-10-19 14:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E7D255D6-D30B-4457-898D-1FC601F35A4B@kernel.crashing.org>
On Fri, Oct 19, 2007 at 08:23:19AM -0500, Kumar Gala wrote:
>
> On Oct 18, 2007, at 5:29 PM, Anton Vorontsov wrote:
>
>> On Thu, Oct 18, 2007 at 02:58:25PM -0500, Kumar Gala wrote:
>> [...]
>>>> +
>>>> + flash@0,0 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
>>>> + reg = <0 0 2000000>;
>>>> + bank-width = <2>;
>>>> + device-width = <1>;
>>>> +
>>>
>>> Are you basing the partition map on something or making it up?
>>> Clearly hrcw & u-boot are at fixed offsets, wondering about kernel &
>>> rootfs?
>>
>> I'm making it up. From the brief look at the u-boot* git sources,
>> there is no `flashboot` yet, thus I'm free to make this up...
>>
>> I've partitioned this flash based on these thoughts:
>>
>> 1. HRCW - whole sector, to not wear out it, plus it's impossible to
>> create just 64 bytes partition;
>
> this makes sense.
[Unrelated to the patch.
I've tried to erase first (hrcw) sector, everything passes fine, but
`md fe000000` still gives data back. Probably some hardware magic used
to prevent this? ;-)
=> erase fe000000 fe03ffff
.. done
Erased 2 sectors
=> md fe000000
fe000000: 42424242 42424242 05050505 05050505 BBBBBBBB........
fe000010: 00000000 00000000 83838383 83838383 ................
fe000020: a0a0a0a0 a0a0a0a0 60606060 60606060 ........````````
...
=> md fe020000
fe020000: ffffffff ffffffff ffffffff ffffffff ................
...]
>
>> 2. Kernel - 2MB, should be enough for bootup kernels?
>
> seems reasonable.
>
>> 3. Rootfs - the rest up to...
>
> do we need a small section for the device tree?
Yes, apparently. :-)
>> 4. U-Boot at the end.
>
> can we reorder partitions? not sure if there is any value in having the
> things we know will always be there like hrcw & u-boot at fixed mtd0, mtd1,
> etc.
Good idea.
>>
>> I'm not saying that it's best map ever, I'm open to suggestions. ;-)
>>
>> * Unfortunately I didn't look at the stock Freescale u-boot, maybe
>> there was flashboot, most probably.. I'll find the CD to look this
>> up.
>
> Yeah I have no idea what we ship w/regards to the BSPs.
Here it is:
bootcmd=run ramargs;cp.b fff00000 400000 2000;bootm ff800000 ffa00000 400000
I.e.
0xFF800000 - kernel
0xFFA00000 - ramdisk
0xFFF00000 - dtb, one sector
Reworked patch (lbus+flash) follow, using this stock partitions map:
0x00000000-0x00020000 : "hrcw" <- 128 kB
0x01f80000-0x02000000 : "u-boot" <- 512 kB
0x00020000-0x01800000 : "rootfs" <- 24448 kB
0x01800000-0x01a00000 : "kernel" <- 2048 kB
0x01a00000-0x01f00000 : "ramdisk" <- 5120 kB
0x01f00000-0x01f20000 : "dtb" <- 128 kB
0x01f20000-0x01f80000 : "spare" <- 384 kB
I'm not sure about "ramdisk" partition though, maybe concatenate
kernel+ramdisk to use with initramfs kernels instead?
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] [POWERPC] MPC8568E-MDS: create localbus node, add flash support
This patch:
- creates localbus node;
- moves bcsr into it;
- creates flash node (1 32MB Spansion x16 CFI) and its partitions;
- adds localbus to the probe path.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 61 +++++++++++++++++++++++++++-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
2 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 5439437..8ddeaf8 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -42,9 +42,64 @@
reg = <00000000 10000000>;
};
- bcsr@f8000000 {
- device_type = "board-control";
- reg = <f8000000 8000>;
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8568-localbus";
+ reg = <e0005000 d8>;
+ ranges = <1 0 f8000000 0008000
+ 0 0 fe000000 2000000>;
+
+ bcsr@1,0 {
+ device_type = "board-control";
+ reg = <1 0 8000>;
+ };
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "Spansion,S29GL256N11TFIV2O", "cfi-flash";
+ reg = <0 0 2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ hrcw@0 {
+ label = "hrcw";
+ reg = <0 20000>;
+ read-only;
+ };
+
+ uboot@1f80000 {
+ label = "u-boot";
+ reg = <1f80000 80000>;
+ read-only;
+ };
+
+ rootfs@20000 {
+ label = "rootfs";
+ reg = <20000 17e0000>;
+ };
+
+ kernel@1800000 {
+ label = "kernel";
+ reg = <1800000 200000>;
+ };
+
+ ramdisk@1a00000 {
+ label = "ramdisk";
+ reg = <1a00000 500000>;
+ };
+
+ dtb@1f00000 {
+ label = "dtb";
+ reg = <1f00000 20000>;
+ };
+
+ spare@1f20000 {
+ label = "spare";
+ reg = <1f20000 60000>;
+ };
+ };
};
soc8568@e0000000 {
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 61b3eed..45ffca4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -139,6 +139,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = "soc", },
{ .compatible = "soc", },
{ .type = "qe", },
+ { .compatible = "fsl,mpc8568-localbus", },
{},
};
--
1.5.0.6
^ permalink raw reply related
* Re: Linux root file system with X window support for a powerpc board
From: Sebastian Siewior @ 2007-10-19 14:29 UTC (permalink / raw)
To: mahendra varman; +Cc: XFree86, linuxppc-embedded
In-Reply-To: <4ac2955e0710190700q41fe7f6bw8956c5b12be1fa7f@mail.gmail.com>
* mahendra varman | 2007-10-19 19:30:37 [+0530]:
>Can anybody help me how to create a Linux root file system with X window
>support for a powerpc 74xx based board ?
>
>Any documents/links related to that is also welcome
If you are familiar with Gentoo based systems I would recommend [1].
>R.Mahendravarman
[1] http://www.gentoo.org/proj/en/base/embedded/cross-development.xml
Sebastian
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox