* RE: i2c device for a linux 2.6 in XUPV2P
From: Stephen Neuendorffer @ 2008-01-09 17:52 UTC (permalink / raw)
To: Josep Maria Batlle, linuxppc-embedded; +Cc: git
In-Reply-To: <ef1737dc0712241327t3cc7c14kcb91e9a4e550df18@mail.gmail.com>
Yes, it should be possible, however I don't believe the Linux adapter
for the i2c driver has been updated for current 2.6 kernel versions.
It's not currently on git.xilinx.com, and apparently the i2c subsystem
has changed significantly since the adapter was written, so it's not a
straightforward update.
If all you want to do is some simple configuration, then bitbanging the
i2c is straightforward. I'll send you a driver that I cooked up at one
point in a separate email.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Josep =
Maria
Batlle
> Sent: Monday, December 24, 2007 1:27 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: i2c device for a linux 2.6 in XUPV2P
>=20
> Hi all,
>=20
> I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300
config file).
> Now I am trying to use the i2c in the user-space. First of all: is it
possible?
>=20
> My first attempts have not worked. I have made this:
> 1) I enable "I2C Support" and "I2C device interface" in the kernel
recompilation.
> 2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
> 3) then I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel
> documentation) that returns this errno message: "No such device".
>=20
> I have tried to use the device number 1, 2, 3, 4 but these have not
worked. I have tried to use the
> device "i2cn" but not worked. I have tried to use all the BSP's from
the EDK (7.1i) and then only the
> "xparameters_ml300.h" in the compilation. After all of this, now I am
modifying the RFS for "mdev"...
> Somebody can tell me what I am doing wrong if this use is possible?
>=20
> I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox
1.7.2.
>=20
> Thanks.
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-09 18:05 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801051041.18173.sr@denx.de>
Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> This patch adds the maps for the taco. It also gets the ndfc.c NAND
>> driver in a compilable state. The map is guaranteed to change since the
>> exact NOR/NAND flash configuration is in flux right now when we found
>> the 256M NAND flash won't boot properly.
>>
>> Currently it configures the NOR in a reasonable fashion and leaves the
>> NAND as one honkin' parition.
>>
>
> <snip>
>
>
>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>> index 1c0e89f..f5e93cf 100644
>> --- a/drivers/mtd/nand/ndfc.c
>> +++ b/drivers/mtd/nand/ndfc.c
>> @@ -24,11 +24,6 @@
>> #include <linux/platform_device.h>
>>
>> #include <asm/io.h>
>> -#ifdef CONFIG_40x
>> -#include <asm/ibm405.h>
>> -#else
>> -#include <asm/ibm44x.h>
>> -#endif
>>
>
> You do break arch/ppc support with this patch. We have to still support
> arch/ppc a few month, so please don't break this support for now.
>
Here is an updated patch that does not break the ppc arch support.
Unfortunately, it still has the taco specific patch. I can't find
anything different between the taco and the sequoia and since this patch
fixes the problem, the hardware guys refuse to look into it. I can't
blame them as we are overloaded as it is.
But I will send out the patch anyway in case anybody needs the ndfc
driver working under the powerpc arch.
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..ca9f35a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -153,7 +153,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 1c0e89f..fe19177 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,13 @@
#include <linux/platform_device.h>
#include <asm/io.h>
+#ifndef CONFIG_PPC_MERGE
#ifdef CONFIG_40x
#include <asm/ibm405.h>
#else
#include <asm/ibm44x.h>
#endif
+#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +112,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_WARP
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the Warp!
+ */
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
/*
* Speedups for buffer read/write/verify
*
@@ -145,6 +181,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
return -EFAULT;
return 0;
}
+#endif
/*
* Initialize chip structure
@@ -236,6 +273,8 @@ static int ndfc_nand_probe(struct platform_device *pdev)
#ifndef CONFIG_PHYS_64BIT
ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
+#elif defined(CONFIG_PPC_MERGE)
+ ndfc->ndfcbase = ioremap(phys, res->end - res->start + 1);
#else
ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
#endif
^ permalink raw reply related
* Re: Linux for ml310
From: Grant Likely @ 2008-01-09 18:07 UTC (permalink / raw)
To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <524275432@web.de>
On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
> Hi again
>
> In which xparams* files should i look for the right definition?
> In the xparameters.h from the BSP I can't find it, it looks like this:
> -------------------------------------------------------------------
> /*
> * include/asm-ppc/xparameters.h
> *
> * This file includes the correct xparameters.h for the CONFIG'ed board
> *
> * Author: MontaVista Software, Inc.
> * source@mvista.com
> *
> * 2004 (c) MontaVista Software, Inc. This file is licensed under the terms
> * of the GNU General Public License version 2. This program is licensed
> * "as is" without any warranty of any kind, whether express or implied.
> */
>
> #include <linux/config.h>
>
> #if defined(CONFIG_XILINX_ML300)
> #include <platforms/4xx/xparameters/xparameters_ml300.h>
<--- Add fixups here.
> #endif
> #if defined(CONFIG_XILINX_ML40x)
> #include <platforms/4xx/xparameters/xparameters_ml40x.h>
> #endif
The fixups should look like this:
#define XPAR_UARTNS550_0_CLOCK_FREQ_HZ \
XPAR_<real-name-from-xparams-ml300>_FREQ_HZ
#define XPAR_INTC_0_UARTNS550_0_VEC_ID \
XPAR_<real-name-from-xparams-ml300>_VEC_ID
#define XPAR_UARTNS550_0_BASEADDR \
XPAR_<real-name-from-xparams-ml300>_BASEADDR
Note: when you generate the EDK bsp, *make sure* you generated it for
the "linux 2.6" target; not "standalone". If you don't then
xparams_ml300 will be missing stuff.
^ permalink raw reply
* Re: [PATCH 2/3 v2] Add initial iomega StorCenter board port.
From: Scott Wood @ 2008-01-09 18:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1JCMbN-0002mN-MD@jdl.com>
On Tue, Jan 08, 2008 at 04:07:17PM -0600, Jon Loeliger wrote:
> +static void storcenter_power_off(void)
> +{
> + /* No way to shut power off with software */
> + local_irq_disable();
> + for (;;) ;
> + /* NOTREACHED */
> +}
So leave it out, and let the generic halt function be used.
-Scott
^ permalink raw reply
* Control not branching to the instruction present at resetvec i.e 0xfffffffc
From: Siva Prasad @ 2008-01-09 18:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.1.1199581203.5432.linuxppc-embedded@ozlabs.org>
Ravi,
If you already have BDI2000, why don't you single step on it?
Thanks
Siva
Date: Sat, 5 Jan 2008 06:19:05 -0800 (PST)
From: Misbah khan <misbah_khan@engineer.com>
Subject: Re: Control not branching to the instruction present at
resetvec i.e 0xfffffffc
To: linuxppc-embedded@ozlabs.org
Message-ID: <14633599.post@talk.nabble.com>
Content-Type: text/plain; charset=3Dus-ascii
Hi Mr Ravi ...
I suggest you to post a new concern in a new thread ....
----Misbah=20
ravi.rao wrote:
>=20
> Hi All,
> We have a custom target board based on PPC-EP405. We just got the=20
> board from the hardware team .I connected the board to BDI200 and
powered=20
> it on.=20
> The control came to the resetvec address which is 0xfffffffc. I was
able=20
> to read and write to flash. So I erased the flash and burnt the
bootloader=20
> into flash from 0xfffc0000.
> I verified that the instruction at 0xfffffffc is 4bfc2104 whicis
actually=20
> a branch to 0xfffc2100. Also a memory dump of 0xfffc2100 shows the
correct=20
> code. This proved that
> the uboot bootloader was burnt properly.
> Now when I reset the board the control never reaches 0xfffc2100 i.e
for=20
> some reason the code at the resetvec is not getting executed. Any help
or=20
> pointers to resolve this is greatly appreciated.
> Thanks,
> Ravishankar Govindarao
> RFL Electronics Inc.
> E-mail : Ravi.Rao@rflelect.com
> Voice: 973.334.3100 Ext. 233
> Fax: 973.334.3863
> =20
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Josh Boyer @ 2008-01-09 18:42 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47850CEF.9060209@pikatech.com>
On Wed, 09 Jan 2008 13:05:35 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Stefan Roese wrote:
> > On Saturday 05 January 2008, Sean MacLennan wrote:
> >
> >> This patch adds the maps for the taco. It also gets the ndfc.c NAND
> >> driver in a compilable state. The map is guaranteed to change since the
> >> exact NOR/NAND flash configuration is in flux right now when we found
> >> the 256M NAND flash won't boot properly.
> >>
> >> Currently it configures the NOR in a reasonable fashion and leaves the
> >> NAND as one honkin' parition.
> >>
> >
> > <snip>
> >
> >
> >> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
> >> index 1c0e89f..f5e93cf 100644
> >> --- a/drivers/mtd/nand/ndfc.c
> >> +++ b/drivers/mtd/nand/ndfc.c
> >> @@ -24,11 +24,6 @@
> >> #include <linux/platform_device.h>
> >>
> >> #include <asm/io.h>
> >> -#ifdef CONFIG_40x
> >> -#include <asm/ibm405.h>
> >> -#else
> >> -#include <asm/ibm44x.h>
> >> -#endif
> >>
> >
> > You do break arch/ppc support with this patch. We have to still support
> > arch/ppc a few month, so please don't break this support for now.
> >
> Here is an updated patch that does not break the ppc arch support.
> Unfortunately, it still has the taco specific patch. I can't find
> anything different between the taco and the sequoia and since this patch
> fixes the problem, the hardware guys refuse to look into it. I can't
> blame them as we are overloaded as it is.
>
> But I will send out the patch anyway in case anybody needs the ndfc
> driver working under the powerpc arch.
This doesn't really get the addresses, etc from the device tree though,
correct?
josh
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Nathan Lynch @ 2008-01-09 18:44 UTC (permalink / raw)
To: Linas Vepstas; +Cc: mahuja, linuxppc-dev, lkessler, strosake
In-Reply-To: <3ae3aa420801090731r2e25e42awcae385b448e20b16@mail.gmail.com>
Hi Linas,
Linas Vepstas wrote:
>
> On 08/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> > Manish Ahuja wrote:
> > > +
> > > +The goal of hypervisor-assisted dump is to enable the dump of
> > > +a crashed system, and to do so from a fully-reset system, and
> > > +to minimize the total elapsed time until the system is back
> > > +in production use.
> >
> > Is it actually faster than kdump?
>
> This is a basic presumption;
I used the word "actually". I already know that it is intended to be
faster. :)
> it should blow it away, as, after all,
> it requires one less reboot!
There's more than rebooting going on during system dump processing.
Depending on the system type, booting may not be where most time is
spent.
> As a side effect, the system is in
> production *while* the dump is being taken;
A dubious feature IMO. Seems that the design potentially trades
reliability of first failure data capture for availability.
E.g. system crashes, reboots, resumes processing while copying dump,
crashes again before dump procedure is complete. How is that handled,
if at all?
> with kdump,
> you can't go into production until after the dump is finished,
> and the system has been rebooted a second time. On
> systems with terabytes of RAM, the time difference can be
> hours.
The difference in time it takes to resume the normal workload may be
significant, yes. But the time it takes to get a usable dump image
would seem to be the basically the same.
Since you bring up large systems... a system with terabytes of RAM is
practically guaranteed to be a NUMA configuration with dozens of cpus.
When processing a dump on such a system, I wonder how well we fare:
can we successfully boot with (say) 128 cpus and 256MB of usable
memory? Do we have to hot-online nodes as system memory is freed up
(and does that even work)? We need to be able to restore the system
to its optimal topology when the dump is finished; if the best we can
do is a degraded configuration, the workload will suffer and the
system admin is likely to just reboot the machine again so the kernel
will have the right NUMA topology.
> > > +Implementation details:
> > > +----------------------
> > > +In order for this scheme to work, memory needs to be reserved
> > > +quite early in the boot cycle. However, access to the device
> > > +tree this early in the boot cycle is difficult, and device-tree
> > > +access is needed to determine if there is a crash data waiting.
> >
> > I don't think this bit about early device tree access is correct. By
> > the time your code is reserving memory (from early_init_devtree(), I
> > think), RTAS has been instantiated and you are able to test for the
> > existence of /rtas/ibm,dump-kernel.
>
> If I remember right, it was still too early to look up this token directly,
> so we wrote some code to crawl the flat device tree to find it. But
> not only was that a lot of work, but I somehow decided that doing this
> to the flat tree was wrong, as otherwise someone would surely have
> written the access code. If this can be made to work, that would be
> great, but we couldn't make it work at the time.
>
> > > +To work around this problem, all but 256MB of RAM is reserved
> > > +during early boot. A short while later in boot, a check is made
> > > +to determine if there is dump data waiting. If there isn't,
> > > +then the reserved memory is released to general kernel use.
> >
> > So I think these gymnastics are unneeded -- unless I'm
> > misunderstanding something, you should be able to determine very early
> > whether to reserve that memory.
>
> Only if you can get at rtas, but you can't get at rtas at that point.
Sorry, but I think you are mistaken (see Michael's earlier reply).
^ permalink raw reply
* Re: [PATCH] MTD for Taco
From: Sean MacLennan @ 2008-01-09 18:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080109124243.73205d68@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 09 Jan 2008 13:05:35 -0500
> Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>
>> Stefan Roese wrote:
>>
>>> On Saturday 05 January 2008, Sean MacLennan wrote:
>>>
>>>
>>>> This patch adds the maps for the taco. It also gets the ndfc.c NAND
>>>> driver in a compilable state. The map is guaranteed to change since the
>>>> exact NOR/NAND flash configuration is in flux right now when we found
>>>> the 256M NAND flash won't boot properly.
>>>>
>>>> Currently it configures the NOR in a reasonable fashion and leaves the
>>>> NAND as one honkin' parition.
>>>>
>>>>
>>> <snip>
>>>
>>>
>>>
>>>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>>>> index 1c0e89f..f5e93cf 100644
>>>> --- a/drivers/mtd/nand/ndfc.c
>>>> +++ b/drivers/mtd/nand/ndfc.c
>>>> @@ -24,11 +24,6 @@
>>>> #include <linux/platform_device.h>
>>>>
>>>> #include <asm/io.h>
>>>> -#ifdef CONFIG_40x
>>>> -#include <asm/ibm405.h>
>>>> -#else
>>>> -#include <asm/ibm44x.h>
>>>> -#endif
>>>>
>>>>
>>> You do break arch/ppc support with this patch. We have to still support
>>> arch/ppc a few month, so please don't break this support for now.
>>>
>>>
>> Here is an updated patch that does not break the ppc arch support.
>> Unfortunately, it still has the taco specific patch. I can't find
>> anything different between the taco and the sequoia and since this patch
>> fixes the problem, the hardware guys refuse to look into it. I can't
>> blame them as we are overloaded as it is.
>>
>> But I will send out the patch anyway in case anybody needs the ndfc
>> driver working under the powerpc arch.
>>
>
> This doesn't really get the addresses, etc from the device tree though,
> correct?
>
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
No. You have to setup everything the old way. This *just* gets it
working so if you have the PPC layout, it will work.
Unless testing goes *really* well, I doubt I will have time in the short
term to port it to the of_platform. I'm afraid I will have to live with
"it works, don't touch it" for now :(
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Scott Wood @ 2008-01-09 18:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801091127400.8069@blarg.am.freescale.net>
On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
> /* reserve the sections we're already using */
> - for (i = 0; i < lmb.reserved.cnt; i++)
> - reserve_bootmem(lmb.reserved.region[i].base,
> - lmb_size_bytes(&lmb.reserved, i));
> + for (i = 0; i < lmb.reserved.cnt; i++) {
> + unsigned long addr = lmb.reserved.region[i].base +
> + lmb_size_bytes(&lmb.reserved, i) - 1;
> + if (addr < total_lowmem)
> + reserve_bootmem(lmb.reserved.region[i].base,
> + lmb_size_bytes(&lmb.reserved, i));
> + }
It looks like if the reserved area straddles the highmem boundary, it'll
only reserve the highmem portion.
-Scott
^ permalink raw reply
* [PATCH 3/2] Base Warp Platform support
From: Sean MacLennan @ 2008-01-09 18:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <478504BF.2000908@pikatech.com>
Ooops. Guess I am not perfect after all ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
--- /dev/null 2005-11-20 22:22:37.000000000 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.000000000 -0500
@@ -0,0 +1,239 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * 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/init.h>
+#include <linux/of_platform.h>
+#include <linux/kthread.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+
+#include "44x.h"
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if(!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
+ printk("ERROR: Unable to remap GPIO base.\n");
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds &= ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds &= ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ void *fpga;
+ int irq;
+ struct resource res;
+ struct task_struct *dtm_thread;
+
+ if((np = of_find_compatible_node(NULL, NULL, "pika,fpga")) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ if((irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+ * fpga space, which is over 8k.
+ */
+ if(of_address_to_resource(np, 0, &res) ||
+ (fpga = ioremap(res.start, 0x24)) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ /* Turn off the line LEDs */
+ out_be32(fpga + 8, 0);
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+
+ if(IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ printk(KERN_ERR __FILE__ ": Unable to start PIKA DTM thread\n");
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(warp_fpga_init);
+
+#define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
+
+#include <linux/platform_device.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/map.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD0000000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "nand",
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+ .ccr_settings = (NDFC_CCR_BS(CS_NAND_0) | NDFC_CCR_ARAC1),
+ .ndfc_erpn = 0,
+};
+
+static struct ndfc_chip_settings warp_chip0_settings = {
+ .bank_settings = 0x80002222,
+};
+
+struct platform_nand_ctrl warp_nand_ctrl = {
+ .priv = &warp_ndfc_settings,
+};
+
+static struct platform_device warp_ndfc_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &warp_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+};
+
+static struct nand_ecclayout nand_oob_16 = {
+ .eccbytes = 3,
+ .eccpos = { 0, 1, 2, 3, 6, 7 },
+ .oobfree = { {.offset = 8, .length = 16} }
+};
+
+static struct platform_nand_chip warp_nand_chip0 = {
+ .nr_chips = 1,
+ .chip_offset = CS_NAND_0,
+ .nr_partitions = ARRAY_SIZE(nand_parts),
+ .partitions = nand_parts,
+ .chip_delay = 50,
+ .ecclayout = &nand_oob_16,
+ .priv = &warp_chip0_settings,
+};
+
+static struct platform_device warp_nand_device = {
+ .name = "ndfc-chip",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &warp_ndfc,
+ .dev = {
+ .platform_data = &warp_nand_chip0,
+ .parent = &warp_ndfc_device.dev,
+ }
+};
+
+static int warp_setup_flash(void)
+{
+ platform_device_register(&warp_ndfc_device);
+ platform_device_register(&warp_nand_device);
+
+ return 0;
+}
+device_initcall(warp_setup_flash);
+
+#endif /* NAND_FLASH */
^ permalink raw reply
* [PATCH v4 0/3] OF-platform PATA driver
From: Anton Vorontsov @ 2008-01-09 19:08 UTC (permalink / raw)
To: linuxppc-dev, linux-ide; +Cc: Olof Johansson, Paul Mundt, Jeff Garzik
Hi all,
Here is the resend (aka v4) version of the OF-platform PATA
driver and related patches.
Changes since v3:
- Acked-by: Paul Mundt <lethal@linux-sh.org>
- In the powerpc specific patch: update defconfig and use
machine_device_initcall -- this is new call found in the
galak/powerpc.git.
Changes since v2:
- "PPC" added to PATA_PLATFORM "depends on" Kconfig entry;
I didn't remove EMBEDDED "depends on" -- this wasn't discussed
much and these patches should not depend on the decision.
- cosmetic fixes;
- "s/ioport_shift/reg_shift/g" patch dropped.
Changes since v1:
- __pata_platform_probe now accepts pio_mask argument;
- pata-platform compatible property renamed to ata-generic;
- pata_of_platform understands pio-mode property. It's used to pass
pio_mask to the __pata_platform_probe. That is, in ata-generic
context pio-mode means "pio mode the bus already configured for";
- New optional patch that renames pata_platform_info's
ioport_shift to reg_shift.
Changes since RFC:
- nuked drivers/ata/pata_platform.h;
- powerpc bits: proper localbus node added.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-09 19:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi
Thanks for your great help!
I added following lines which I found at the old xparameters=5Fml300.h, whic=
h was part of the kernel-sources but was replaced with the one of the BSP:=
--------------------------------------------------------------------------=
--------------------------------------------------------
#define XPAR=5FXUARTNS550=5FCLOCK=5FHZ 100000000
#define XPAR=5FDCR=5FINTC=5F0=5FOPB=5FUART16550=5F0=5FIP2INTC=5FIRPT=5FINTR 6
#define XPAR=5FOPB=5FUART16550=5F0=5FBASEADDR 0xA0000000
#define XPAR=5FUARTNS550=5F0=5FCLOCK=5FFREQ=5FHZ XPAR=5FXUARTNS550=5FCLOCK=5FHZ
#define XPAR=5FINTC=5F0=5FUARTNS550=5F0=5FVEC=5FID XPAR=5FDCR=5FINTC=5F0=5FOPB=5FUART16550=5F0=5FIP2=
INTC=5FIRPT=5FINTR
#define XPAR=5FUARTNS550=5F0=5FBASEADDR (XPAR=5FOPB=5FUART16550=5F0=5FBASEADDR+0x1000)
--------------------------------------------------------------------------=
--------------------------------------------------------
now the compiling ends successfully.
Thanks again
Joachim
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220
^ permalink raw reply
* [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
From: Anton Vorontsov @ 2008-01-09 19:10 UTC (permalink / raw)
To: linuxppc-dev, linux-ide; +Cc: Olof Johansson, Paul Mundt, Jeff Garzik
In-Reply-To: <20080109190852.GA18827@localhost.localdomain>
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Paul Mundt <lethal@linux-sh.org>
---
drivers/ata/pata_platform.c | 144 ++++++++++++++++++++++++----------------
include/linux/pata_platform.h | 9 +++
2 files changed, 95 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..224bb6c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
- struct pata_platform_info *info)
+ unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA << shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr = ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,13 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
+ * @__pio_mask: PIO mask
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +135,18 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
- * Simple resource validation ..
- */
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
- * Get the I/O base first
- */
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
- * Then the CTL base
- */
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,20 +157,21 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0; /* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
ap->ops = &pata_platform_port_ops;
- ap->pio_mask = pio_mask;
+ ap->pio_mask = __pio_mask;
ap->flags |= ATA_FLAG_SLAVE_POSS;
/*
@@ -209,25 +186,24 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioremap(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioremap(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
} else {
- ap->ioaddr.cmd_addr = devm_ioport_map(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioport_map(dev, io_res->start,
io_res->end - io_res->start + 1);
- ap->ioaddr.ctl_addr = devm_ioport_map(&pdev->dev, ctl_res->start,
+ ap->ioaddr.ctl_addr = devm_ioport_map(dev, ctl_res->start,
ctl_res->end - ctl_res->start + 1);
}
if (!ap->ioaddr.cmd_addr || !ap->ioaddr.ctl_addr) {
- dev_err(&pdev->dev, "failed to map IO/CTL base\n");
+ dev_err(dev, "failed to map IO/CTL base\n");
return -ENOMEM;
}
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pp_info = pdev->dev.platform_data;
- pata_platform_setup_port(&ap->ioaddr, pp_info);
+ pata_platform_setup_port(&ap->ioaddr, ioport_shift);
ata_port_desc(ap, "%s cmd 0x%llx ctl 0x%llx", mmio ? "mmio" : "ioport",
(unsigned long long)io_res->start,
@@ -235,26 +211,78 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
/* activate */
return ata_host_activate(host, irq, irq ? ata_interrupt : NULL,
- pp_info ? pp_info->irq_flags : 0,
- &pata_platform_sht);
+ irq_flags, &pata_platform_sht);
}
+EXPORT_SYMBOL_GPL(__pata_platform_probe);
/**
- * pata_platform_remove - unplug a platform interface
- * @pdev: platform device
+ * __pata_platform_remove - unplug a platform interface
+ * @dev: device
*
* A platform bus ATA device has been unplugged. Perform the needed
* cleanup. Also called on module unload for any active devices.
*/
-static int __devexit pata_platform_remove(struct platform_device *pdev)
+int __devexit __pata_platform_remove(struct device *dev)
{
- struct device *dev = &pdev->dev;
struct ata_host *host = dev_get_drvdata(dev);
ata_host_detach(host);
return 0;
}
+EXPORT_SYMBOL_GPL(__pata_platform_remove);
+
+static int __devinit pata_platform_probe(struct platform_device *pdev)
+{
+ struct resource *io_res;
+ struct resource *ctl_res;
+ struct resource *irq_res;
+ struct pata_platform_info *pp_info = pdev->dev.platform_data;
+
+ /*
+ * Simple resource validation ..
+ */
+ if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
+ dev_err(&pdev->dev, "invalid number of resources\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Get the I/O base first
+ */
+ io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (io_res == NULL) {
+ io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (unlikely(io_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * Then the CTL base
+ */
+ ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
+ if (ctl_res == NULL) {
+ ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (unlikely(ctl_res == NULL))
+ return -EINVAL;
+ }
+
+ /*
+ * And the IRQ
+ */
+ irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (irq_res)
+ irq_res->flags = pp_info ? pp_info->irq_flags : 0;
+
+ return __pata_platform_probe(&pdev->dev, io_res, ctl_res, irq_res,
+ pp_info ? pp_info->ioport_shift : 0,
+ pio_mask);
+}
+
+static int __devexit pata_platform_remove(struct platform_device *pdev)
+{
+ return __pata_platform_remove(&pdev->dev);
+}
static struct platform_driver pata_platform_driver = {
.probe = pata_platform_probe,
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 5799e8d..6a7a92d 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -15,4 +15,13 @@ struct pata_platform_info {
unsigned int irq_flags;
};
+extern int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask);
+
+extern int __devexit __pata_platform_remove(struct device *dev);
+
#endif /* __LINUX_PATA_PLATFORM_H */
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2008-01-09 19:10 UTC (permalink / raw)
To: linuxppc-dev, linux-ide; +Cc: Olof Johansson, Paul Mundt, Jeff Garzik
In-Reply-To: <20080109190852.GA18827@localhost.localdomain>
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Also add || PPC to the PATA_PLATFORM's "depends on" Kconfig entry,
needed for PA Semi Electra.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Reviewed-by: Olof Johansson <olof@lixom.net>
---
drivers/ata/Kconfig | 12 ++++-
drivers/ata/Makefile | 1 +
drivers/ata/pata_of_platform.c | 104 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..64b4964 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -607,13 +607,23 @@ config PATA_WINBOND_VLB
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EMBEDDED || ARCH_RPC
+ depends on EMBEDDED || ARCH_RPC || PPC
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM) += pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI) += pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 0000000..b7bc4e4
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,104 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/pata_platform.h>
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int reg_shift = 0;
+ int pio_mode = 0;
+ int pio_mask;
+ const u32 *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = of_get_property(dn, "reg-shift", NULL);
+ if (prop)
+ reg_shift = *prop;
+
+ prop = of_get_property(dn, "pio-mode", NULL);
+ if (prop) {
+ pio_mode = *prop;
+ if (pio_mode > 6) {
+ dev_err(&ofdev->dev, "invalid pio-mode\n");
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
+ }
+
+ pio_mask = 1 << pio_mode;
+ pio_mask |= (1 << pio_mode) - 1;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+ reg_shift, pio_mask);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = "ata-generic", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pata_of_platform_match);
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table = pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pata_of_platform_remove),
+};
+
+static int __init pata_of_platform_init(void)
+{
+ return of_register_platform_driver(&pata_of_platform_driver);
+}
+module_init(pata_of_platform_init);
+
+static void __exit pata_of_platform_exit(void)
+{
+ of_unregister_platform_driver(&pata_of_platform_driver);
+}
+module_exit(pata_of_platform_exit);
+
+MODULE_DESCRIPTION("OF-platform PATA driver");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.2.2
^ permalink raw reply related
* [PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
From: Anton Vorontsov @ 2008-01-09 19:11 UTC (permalink / raw)
To: linuxppc-dev, linux-ide; +Cc: Olof Johansson, Paul Mundt, Jeff Garzik
In-Reply-To: <20080109190852.GA18827@localhost.localdomain>
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also updates defconfig and adds some code to probe localbus.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Olof Johansson <olof@lixom.net>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 17 ++++++++++++++++-
arch/powerpc/configs/mpc834x_itx_defconfig | 3 ++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 12 ++++++++++++
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
index e354f26..06d5b9c 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -253,6 +253,21 @@
device_type = "pci";
};
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349e-localbus",
+ "fsl,pq2pro-localbus";
+ reg = <e0005000 d8>;
+ ranges = <3 0 f0000000 210>;
-
+ pata@3,0 {
+ compatible = "fsl,mpc8349emitx-pata", "ata-generic";
+ reg = <3 0 10 3 20c 4>;
+ reg-shift = <1>;
+ pio-mode = <6>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
};
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig b/arch/powerpc/configs/mpc834x_itx_defconfig
index 6feb86e..2fbe4e5 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -570,7 +570,8 @@ CONFIG_SATA_SIL=y
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
-# CONFIG_PATA_PLATFORM is not set
+CONFIG_PATA_PLATFORM=y
+CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..50e8f63 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
+#include <linux/of_platform.h>
#include <asm/system.h>
#include <asm/atomic.h>
@@ -37,6 +38,17 @@
#include "mpc83xx.h"
+static struct of_device_id __initdata mpc834x_itx_ids[] = {
+ { .compatible = "fsl,pq2pro-localbus", },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ return of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+}
+machine_device_initcall(mpc834x_itx, mpc834x_itx_declare_of_platform_devices);
+
/* ************************************************************************
*
* Setup the architecture
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] MTD for Taco
From: Josh Boyer @ 2008-01-09 19:04 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47851781.90105@pikatech.com>
On Wed, 09 Jan 2008 13:50:41 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> No. You have to setup everything the old way. This *just* gets it
> working so if you have the PPC layout, it will work.
>
> Unless testing goes *really* well, I doubt I will have time in the short
> term to port it to the of_platform. I'm afraid I will have to live with
> "it works, don't touch it" for now :(
That's fine for you, nobody expects you to have to do all the porting
for everything :).
I don't want it actually ported to of_platform anyway. What I really
want, and what Stefan has started some time ago, is to make it get the
values from the device tree but still create the regular platform
devices.
josh
^ permalink raw reply
* Re: Use 2G RAM in 8548, vmalloc fail, adjust_total_lowmem
From: Scott Wood @ 2008-01-09 18:59 UTC (permalink / raw)
To: jay_chen; +Cc: linuxppc-embedded
In-Reply-To: <OF590B6FCB.576A8335-ON482573CB.00169CC3@alphanetworks.com>
jay_chen wrote:
> Hello, all~~~
>
> I am using a MCP8548 board with 2.6.14.5 kernel.
> And I would like to upgrade memory from 512MB to 2048MB.
> Finally, I realize this is not so easy as I think. I encounter several
> problems. :~~
Well, it should be easy if you use highmem...
> First, I change mem=512M to mem=2048M.
>
> 1. vmalloc fail problem
Are you saying you have vmalloc failures if you don't do any of the
below, and enable highmem, with 2GB RAM? Could you provide more details?
> So, I change kernel config in "advanced setup"
> Change "Set maximum low memory" from 0x30000000 to 0x80000000.
> Change "Virtual address of kernel base" from 0xC0000000 to 0x60000000.
> Change "Set custom user task size" from 0x80000000 to 0x60000000
>
> Someone said that he could change "Virtual address of kernel base" to
> 0xA0000000 without problem.
> Could I change it to 0x60000000? Any possible problem?
There are always *possible* problems. :-)
In theory it should work, but it's not a very well tread path.
> In adjust_total_lowmem(), fsl_booke_mmu.c
> It always limits the low memory to 768MB. (no matter we set mem=768MB or
> mem=1024MB, or mem=2048MB)
> __max_low_memory = max_low_mem = __cam0 + __cam1 + __cam2; (each TLB could
> map up to 256MB)
>
> My question is could I use more than 3 TLBs here? Such as 8 TLBs to map 2G
> ram?
Yes.
> Or could I use e500v2 new feature, that is 1 TLB could map up to 4G?
Yes.
-Scott
^ permalink raw reply
* Re: Base Warp Platform support
From: Josh Boyer @ 2008-01-09 19:10 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <478504BF.2000908@pikatech.com>
On Wed, 09 Jan 2008 12:30:39 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> So no comments? I got it perfect the first time :D
Not quite.. :)
The way you have the patches laid out right now will break compiling
and git bisecting.
Could you take these and roll them up into distinct patches that can
all apply without breaking a compile individually? I recommend doing
it this way:
Patch 1) platform files in arch/powerpc/platforms/44x/
Patch 2) DTS
Patch 3) boot files in arch/powerpc/boot
Patch 4) defconfig
or something along those lines.
That way we can apply them in that order, nothing breaks for the
compile, and they aren't scattered about. If you start a new email
thread with those I think most of it looked fairly good otherwise.
^ permalink raw reply
* Re: Linux for ml310
From: Grant Likely @ 2008-01-09 19:16 UTC (permalink / raw)
To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <524369371@web.de>
On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
> Hi
>
> Thanks for your great help!
> I added following lines which I found at the old xparameters_ml300.h, which was part of the kernel-sources but was replaced with the one of the BSP:
> ----------------------------------------------------------------------------------------------------------------------------------
> #define XPAR_XUARTNS550_CLOCK_HZ 100000000
> #define XPAR_DCR_INTC_0_OPB_UART16550_0_IP2INTC_IRPT_INTR 6
> #define XPAR_OPB_UART16550_0_BASEADDR 0xA0000000
> #define XPAR_UARTNS550_0_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
> #define XPAR_INTC_0_UARTNS550_0_VEC_ID XPAR_DCR_INTC_0_OPB_UART16550_0_IP2INTC_IRPT_INTR
> #define XPAR_UARTNS550_0_BASEADDR (XPAR_OPB_UART16550_0_BASEADDR+0x1000)
wait... Are you using the value from the *old* or *new*
xparameters_ml300.h? The values from the old file *will* *not* *work*
for your design. You must find the appropriate values from your new
xparams file.
Hmmm.... but, this whole discussion assmues that your using a 16550
serial port. If you are using the uartlite instead then all of the
above is unnecessary; you just need to turn off 16550 console support
in the kernel config.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Josh Boyer @ 2008-01-09 19:18 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <478503B6.3060402@pikatech.com>
On Wed, 09 Jan 2008 12:26:14 -0500
Sean MacLennan <smaclennan@pikatech.com> wrote:
> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
This one needs to go to the linux-usb list and David Brownell.
Although I'm not sure what the benefit here really is. You can still
set this in the defconfig without adding this patch... I don't see a
need to do a default.
josh
> ---
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 7580aa5..2660f30 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
> # PPC:
> default y if STB03xxx
> default y if PPC_MPC52xx
> + default y if 440EP
> # MIPS:
> default y if SOC_AU1X00
> # more:
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Sean MacLennan @ 2008-01-09 19:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20080109131807.4cb2af29@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Wed, 09 Jan 2008 12:26:14 -0500
> Sean MacLennan <smaclennan@pikatech.com> wrote:
>
>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>>
>
> This one needs to go to the linux-usb list and David Brownell.
>
> Although I'm not sure what the benefit here really is. You can still
> set this in the defconfig without adding this patch... I don't see a
> need to do a default.
>
Without the default, I was unable to select this option. I may have
solved it the wrong way. It seems if there is no string after the
tristate or boolean, you are not allowed to set the variable, it can
only default. So with no default, I cannot enable this option and
therefore cannot enable the ohci driver.
Again, I think the "default PCI" case catches most boards and all
PCI-less, or possibly PCI-less, boards need a default.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Kumar Gala @ 2008-01-09 19:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080109185349.GC4337@loki.buserror.net>
On Jan 9, 2008, at 12:53 PM, Scott Wood wrote:
> On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
>> /* reserve the sections we're already using */
>> - for (i = 0; i < lmb.reserved.cnt; i++)
>> - reserve_bootmem(lmb.reserved.region[i].base,
>> - lmb_size_bytes(&lmb.reserved, i));
>> + for (i = 0; i < lmb.reserved.cnt; i++) {
>> + unsigned long addr = lmb.reserved.region[i].base +
>> + lmb_size_bytes(&lmb.reserved, i) - 1;
>> + if (addr < total_lowmem)
>> + reserve_bootmem(lmb.reserved.region[i].base,
>> + lmb_size_bytes(&lmb.reserved, i));
>> + }
>
> It looks like if the reserved area straddles the highmem boundary,
> it'll
> only reserve the highmem portion.
Yeah, I thought about that. I'm wondering if we should warn about
this.. its seems like a bad thing to do.
- k
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Manish Ahuja @ 2008-01-09 19:28 UTC (permalink / raw)
To: Nathan Lynch; +Cc: mahuja, linuxppc-dev, Linas Vepstas, lkessler, strosake
In-Reply-To: <20080109184437.GU14201@localdomain>
>
> I used the word "actually". I already know that it is intended to be
> faster. :)
>
>> it should blow it away, as, after all,
>> it requires one less reboot!
>
> There's more than rebooting going on during system dump processing.
> Depending on the system type, booting may not be where most time is
> spent.
>
>
>> As a side effect, the system is in
>> production *while* the dump is being taken;
>
> A dubious feature IMO. Seems that the design potentially trades
> reliability of first failure data capture for availability.
> E.g. system crashes, reboots, resumes processing while copying dump,
> crashes again before dump procedure is complete. How is that handled,
> if at all?
This is a simple version. The intent was not to have a complex dump taking
mechanism in version 1. Subsequent versions will see planned improvement
on the way the pages are tracked and freed.
Also it is very easily possible now, to register for another dump as soon as the
scratch area is copied to a user designated region. But for now this simple implementation
exists.
It is also possible to extend this further to only preserve pages that are
kernel pages and free the non required pages like user/data pages etc. This
would reduce the space preserved and would prevent any issues that are
caused by reserving everything in memory except for the first 256 MB.
Improvements and future versions are planned to make this efficient. But for
now the intent is to get this off the ground and handle simple cases.
>
>
>> with kdump,
>> you can't go into production until after the dump is finished,
>> and the system has been rebooted a second time. On
>> systems with terabytes of RAM, the time difference can be
>> hours.
>
> The difference in time it takes to resume the normal workload may be
> significant, yes. But the time it takes to get a usable dump image
> would seem to be the basically the same.
>
> Since you bring up large systems... a system with terabytes of RAM is
> practically guaranteed to be a NUMA configuration with dozens of cpus.
> When processing a dump on such a system, I wonder how well we fare:
> can we successfully boot with (say) 128 cpus and 256MB of usable
> memory? Do we have to hot-online nodes as system memory is freed up
> (and does that even work)? We need to be able to restore the system
> to its optimal topology when the dump is finished; if the best we can
> do is a degraded configuration, the workload will suffer and the
> system admin is likely to just reboot the machine again so the kernel
> will have the right NUMA topology.
>
>
>>>> +Implementation details:
>>>> +----------------------
>>>> +In order for this scheme to work, memory needs to be reserved
>>>> +quite early in the boot cycle. However, access to the device
>>>> +tree this early in the boot cycle is difficult, and device-tree
>>>> +access is needed to determine if there is a crash data waiting.
>>> I don't think this bit about early device tree access is correct. By
>>> the time your code is reserving memory (from early_init_devtree(), I
>>> think), RTAS has been instantiated and you are able to test for the
>>> existence of /rtas/ibm,dump-kernel.
>> If I remember right, it was still too early to look up this token directly,
>> so we wrote some code to crawl the flat device tree to find it. But
>> not only was that a lot of work, but I somehow decided that doing this
>> to the flat tree was wrong, as otherwise someone would surely have
>> written the access code. If this can be made to work, that would be
>> great, but we couldn't make it work at the time.
>>
>>>> +To work around this problem, all but 256MB of RAM is reserved
>>>> +during early boot. A short while later in boot, a check is made
>>>> +to determine if there is dump data waiting. If there isn't,
>>>> +then the reserved memory is released to general kernel use.
>>> So I think these gymnastics are unneeded -- unless I'm
>>> misunderstanding something, you should be able to determine very early
>>> whether to reserve that memory.
>> Only if you can get at rtas, but you can't get at rtas at that point.
>
> Sorry, but I think you are mistaken (see Michael's earlier reply).
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Scott Wood @ 2008-01-09 19:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3B831CF0-E978-42E7-BA26-7598BC27A5F6@kernel.crashing.org>
Kumar Gala wrote:
> On Jan 9, 2008, at 12:53 PM, Scott Wood wrote:
>> It looks like if the reserved area straddles the highmem boundary, it'll
>> only reserve the highmem portion.
>
> Yeah, I thought about that. I'm wondering if we should warn about
> this.. its seems like a bad thing to do.
How is the firmware supposed to know where Linux sets its lowmem limit?
I think this is something that needs to be handled.
-Scott
^ permalink raw reply
* Help with device tree binding for SMC serial
From: Rune Torgersen @ 2008-01-09 19:18 UTC (permalink / raw)
To: linuxppc-dev
Hi
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried to make one.
is this anywhere close to workable?
serial@11a80 {
device_type =3D "serial";
compatible =3D "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg =3D <11a80 10 87fc 2>;
interrupts =3D <4 8>;
interrupt-parent =3D <&PIC>;
fsl,cpm-brg =3D <7>;
fsl,cpm-command =3D <01000000>;
};
^ 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