* Re: patch status
From: Josh Boyer @ 2009-12-08 0:52 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C0872CE8B@SDCEXCHANGE01.ad.amcc.com>
On Mon, Dec 07, 2009 at 02:01:58PM -0800, Tirumala Reddy Marri wrote:
>Hi Ben,
>
> Did you get the chance to review the patch I sent it on Dec-1 2009
>
>
>
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.html
Ben has to review lots of patches. Please be patient. Also, your patch is
tracked via patchwork here:
http://patchwork.ozlabs.org/patch/39865/
so you can see the state as it progresses.
Further, it would have been helpful to CC the maintainer of the 4xx sub-arch
(me) since it impacts that platform and you could have gotten some review more
quickly. I didn't notice it until this afternoon.
Lastly, your patch has lots of magical values in it. While I have no doubt
they are correct, I can't find any documentation for 460SX on the AMCC website
aside from some small product briefs. Perhaps I've overlooked the CPU manual,
but since I don't have such a board or the manual for it, it would be nice to
know what kind of testing has been done with this patch. A simple statement
such as "tested on kernel <version> with a <network, raid, whatever> pci-e
card successfully" would go a long way.
This is not a rant or complaint about the code. Just a reminder that the
community doesn't always move at the pace we would all like :). I'll try and
look over the patch more carefully tomorrow.
josh
^ permalink raw reply
* Re: BUG: Bad page map in process
From: Sean MacLennan @ 2009-12-08 0:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259925535.2076.1275.camel@pasglop>
On Fri, 04 Dec 2009 22:18:55 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Ok, I'll have a look next week. In the meantime, Sean, can you give
> me a hint of what you do to trigger it ? Boot time ? specific
> workload ?
I have not been able to reproduce the problem :( I haven't had a lot of
time to run tests... but every once in a while I have been firing off
test runs.
Maybe writing this email will get it to crash ;)
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Michael Ellerman @ 2009-12-08 1:27 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20091207034714.GC3421@kryten>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Mon, 2009-12-07 at 14:47 +1100, Anton Blanchard wrote:
> The pseries and ppc64 defconfigs have drifted apart over the years. Reduce
> some of the differences while still keeping the idea that the ppc64 defconfig
> is cross platform but enables fewer features than pseries, eg:
>
> - NR_CPUS is lower
> - No NUMA support
Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
thought.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Benjamin Herrenschmidt @ 2009-12-08 1:32 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1260235641.4668.1.camel@concordia>
On Tue, 2009-12-08 at 12:27 +1100, Michael Ellerman wrote:
> > The pseries and ppc64 defconfigs have drifted apart over the years.
> Reduce
> > some of the differences while still keeping the idea that the ppc64
> defconfig
> > is cross platform but enables fewer features than pseries, eg:
> >
> > - NR_CPUS is lower
> > - No NUMA support
>
> Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
> thought.
Also no NUMA is going to hurt Cell too. I think we should leave that in.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Michael Ellerman @ 2009-12-08 1:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1260235944.10809.23.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Tue, 2009-12-08 at 12:32 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-08 at 12:27 +1100, Michael Ellerman wrote:
> > > The pseries and ppc64 defconfigs have drifted apart over the years.
> > Reduce
> > > some of the differences while still keeping the idea that the ppc64
> > defconfig
> > > is cross platform but enables fewer features than pseries, eg:
> > >
> > > - NR_CPUS is lower
> > > - No NUMA support
> >
> > Hmm, most of the modern 64 bit platforms are NUMA aren't they? Just a
> > thought.
>
> Also no NUMA is going to hurt Cell too. I think we should leave that in.
It wasn't in, but maybe we should put it in.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Anton Blanchard @ 2009-12-08 1:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1260235944.10809.23.camel@pasglop>
Hi,
> Also no NUMA is going to hurt Cell too. I think we should leave that in.
It was never enabled in the ppc64 defconfig :) I'm happy to turn it on though.
Anton
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: Reduce differences between pseries and ppc64 defconfigs
From: Benjamin Herrenschmidt @ 2009-12-08 1:39 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <20091208013528.GA2716@kryten>
On Tue, 2009-12-08 at 12:35 +1100, Anton Blanchard wrote:
> It was never enabled in the ppc64 defconfig :) I'm happy to turn it on
> though.
Yeah please.
Cheers,
Ben.
^ permalink raw reply
* RE: patch status
From: Tirumala Reddy Marri @ 2009-12-08 1:41 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20091208005257.GL2937@zod.rchland.ibm.com>
Josh,
Sorry for my ignorance that I did not copy you first. From now on I
will make sure you are cc'ed . I will send you the copy of user manual
which is available on external website.=20
Should I send new patch with what is tested with this change or is it
enough to write in email ?
Regards,
Marri
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]=20
Sent: Monday, December 07, 2009 4:53 PM
To: Tirumala Reddy Marri
Cc: benh@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: patch status
On Mon, Dec 07, 2009 at 02:01:58PM -0800, Tirumala Reddy Marri wrote:
>Hi Ben,
>
> Did you get the chance to review the patch I sent it on Dec-1 2009
>
>=20
>
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078436.htm
l
Ben has to review lots of patches. Please be patient. Also, your patch
is
tracked via patchwork here:
http://patchwork.ozlabs.org/patch/39865/
so you can see the state as it progresses.
Further, it would have been helpful to CC the maintainer of the 4xx
sub-arch
(me) since it impacts that platform and you could have gotten some
review more
quickly. I didn't notice it until this afternoon.
Lastly, your patch has lots of magical values in it. While I have no
doubt
they are correct, I can't find any documentation for 460SX on the AMCC
website
aside from some small product briefs. Perhaps I've overlooked the CPU
manual,
but since I don't have such a board or the manual for it, it would be
nice to
know what kind of testing has been done with this patch. A simple
statement
such as "tested on kernel <version> with a <network, raid, whatever>
pci-e
card successfully" would go a long way.
This is not a rant or complaint about the code. Just a reminder that
the
community doesn't always move at the pace we would all like :). I'll
try and
look over the patch more carefully tomorrow.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: mpc8xxx_gpio: Add ability to mask off unused GPIO pins
From: Anton Vorontsov @ 2009-12-08 2:16 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <1260202998.23828.13344.camel@localhost.localdomain>
On Mon, Dec 07, 2009 at 10:23:18AM -0600, Peter Tyser wrote:
[...]
> > Yes, badly designed hardware deserves ugly hacks in the platform
> > code. ;-) So for this problem, just request these gpios in the
> > platform code.
>
> I'd wager lots of boards have GPIO pins that a user shouldn't play
> around with once Linux boots up. Like GPIO pins used to program an
> FPGA,
What if I do want to program/upgrade an FPGA, say from the userspace?
[...]
> In any case, my high-level thought process is:
> 1. Currently, the "ngpio" value is wrong for some processors and should
> be fixed.
> 2. Adding a new "fsl,gpio-mask" gpio solves #1, and has the benefit of
> allowing the device tree to easily reserve GPIO pins which should not be
> used in Linux.
OK, if you're so eager to fix this... I'd suggest to not put this
stuff into device tree. We have compatible property that describes
the device.
So, in the driver, you can just do
if (of_device_is_compatible("fsl,foo-gpiochip"))
mask = ...;
else if (of_device_is_compatible("fsl,bar-gpiochip"))
mask = ...;
If you want to solve "dangerous" GPIOs problem, then I'd say
chosen {
linux,dangerous-gpios = <&pio1 0 0 &pio1 1 0
&pio2 4 0 &pio1 5 0>;
};
And then you can have a generic driver that looks for
linux,dangerous-gpios and requests them at boot.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: 林志平 @ 2009-12-08 2:25 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20091207180511.GA8914@loki.buserror.net>
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
2009/12/8 Scott Wood <scottwood@freescale.com>
> On Mon, Dec 07, 2009 at 11:53:22AM +0800, 林志平 wrote:
> > Does dtc1.2.0 can compile dts files under linux2.6.23?
>
> Probably not -- 2.6.23 is very old, and I think newer dtcs only support the
> newer dts syntax.
>
> > Another question is that I found linux2.6.31 does not support
> > board mpc8544ds,
>
> It should. What problems do you see?
=> bootm 0x1000000 0x1800000 0x800000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-2.6.31
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2185099 Bytes = 2.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01800000 ...
Image Name: Simple Embedded Linux Framework
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1859256 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00800000
Booting using the fdt blob at 0x800000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
booting kernel using flat tree
It then stops and never print any more, I use mpc85xx_defconfig, I select
mpc85xxds in the menuconfig and deselect other options like mpc8540ads etc.
>
> > And I never boot linux-2.6.31 on my board, why linux-2.6.31 doesnot
> > provide a config file like mpc8544_ds_defconfig?
>
> Does mpc85xx_defconfig not work?
>
Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the menuconfig,
but no mpc8544ds. And when I down load the generated uImage, It does not
work.
> -Scott
>
[-- Attachment #2: Type: text/html, Size: 2692 bytes --]
^ permalink raw reply
* Re: using different format for hugetlbfs
From: David Gibson @ 2009-12-08 2:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-ppc list
In-Reply-To: <1260147877.2076.1346.camel@pasglop>
On Mon, Dec 07, 2009 at 12:04:37PM +1100, Benjamin Herrenschmidt wrote:
>
> >
> > Even than, does that preclude the format I suggested? I'm assuming
> > that pgd_t/pud_t/pmd_t are always a double word so the low order 4-
> > bits should be 0 (on 64-bit),
Double word alignment only gives us 3 low bits.
> so using the lsb as the flag between
> > hugetlb and normal pointer should still work.
>
> Might do, depends if David has enough bits ... David ?
Well, the flag can go at the bottom, but that will mean grabbing more
bits at the bottom. At the moment to cover all the page table sizes
that are wanted on the various setups we have, I need 5 bits, this
would push it to 6. At present, I just force up the minimum alignment
of any page directory (even if it's natural alignment is smaller) so
as to make sure I have those bits. That's pretty easy to adjust, but
pushing it up too high will start wasting memory, of course.
If we move to a variable sized encoding, as Ben and I have discussed
on a couple of occasions, I think we could do this though.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: patch status
From: Josh Boyer @ 2009-12-08 2:59 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C0872CF47@SDCEXCHANGE01.ad.amcc.com>
On Mon, Dec 07, 2009 at 05:41:35PM -0800, Tirumala Reddy Marri wrote:
>Josh,
> Sorry for my ignorance that I did not copy you first. From now on I
No reason to apologize. Working with the Linux community is a learning
process.
>will make sure you are cc'ed . I will send you the copy of user manual
>which is available on external website.
A URL to it would be fine. I still haven't managed to find it, but perhaps
the 'ALL available documents/types listed' link on this page:
http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_detail.jsp?productID=PPC460SX
doesn't really mean all?
>
> Should I send new patch with what is tested with this change or is it
>enough to write in email ?
Just reply to the patch is fine. No need to send a new one if there are no
code changes.
josh
^ permalink raw reply
* Re: + iseries-convert-to-proc_fops.patch added to -mm tree
From: Benjamin Herrenschmidt @ 2009-12-08 4:42 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, adobriyan
In-Reply-To: <200912012205.nB1M5Z3n025210@imap1.linux-foundation.org>
On Tue, 2009-12-01 at 14:05 -0800, akpm@linux-foundation.org wrote:
> The patch titled
> iseries: convert to proc_fops
> has been added to the -mm tree. Its filename is
> iseries-convert-to-proc_fops.patch
I was looking at that patch since It was in my queue, and while I
have no firm objection, I started wondering what was the point :-)
IE. What does seq_file buys us here since the conversion adds more
code than it removes and adds a hope via kmalloc that isn't necessary
before the said conversion ?
Those files are only ever one line long (and one of them is only one
character) so the seq_file doesn't really gets us any benefit does it ?
Cheers,
Ben.
> Before you just go and hit "reply", please:
> a) Consider who else should be cc'ed
> b) Prefer to cc a suitable mailing list as well
> c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> out what to do about this
>
> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
>
> ------------------------------------------------------
> Subject: iseries: convert to proc_fops
> From: Alexey Dobriyan <adobriyan@gmail.com>
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> arch/powerpc/platforms/iseries/mf.c | 147 ++++++++++++++------------
> 1 file changed, 83 insertions(+), 64 deletions(-)
>
> diff -puN arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops arch/powerpc/platforms/iseries/mf.c
> --- a/arch/powerpc/platforms/iseries/mf.c~iseries-convert-to-proc_fops
> +++ a/arch/powerpc/platforms/iseries/mf.c
> @@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_ti
> }
>
> #ifdef CONFIG_PROC_FS
> -
> -static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_cmdline_proc_show(struct seq_file *m, void *v)
> {
> - int len;
> - char *p;
> + char *page, *p;
> struct vsp_cmd_data vsp_cmd;
> int rc;
> dma_addr_t dma_addr;
>
> /* The HV appears to return no more than 256 bytes of command line */
> - if (off >= 256)
> - return 0;
> - if ((off + count) > 256)
> - count = 256 - off;
> + page = kmalloc(256, GFP_KERNEL);
> + if (!page)
> + return -ENOMEM;
>
> - dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
> - if (dma_addr == DMA_ERROR_CODE)
> + dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
> + if (dma_addr == DMA_ERROR_CODE) {
> + kfree(page);
> return -ENOMEM;
> - memset(page, 0, off + count);
> + }
> + memset(page, 0, 256);
> memset(&vsp_cmd, 0, sizeof(vsp_cmd));
> vsp_cmd.cmd = 33;
> vsp_cmd.sub_data.kern.token = dma_addr;
> vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
> - vsp_cmd.sub_data.kern.side = (u64)data;
> - vsp_cmd.sub_data.kern.length = off + count;
> + vsp_cmd.sub_data.kern.side = (u64)m->private;
> + vsp_cmd.sub_data.kern.length = 256;
> mb();
> rc = signal_vsp_instruction(&vsp_cmd);
> - iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
> - if (rc)
> + iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
> + if (rc) {
> + kfree(page);
> return rc;
> - if (vsp_cmd.result_code != 0)
> + }
> + if (vsp_cmd.result_code != 0) {
> + kfree(page);
> return -ENOMEM;
> + }
> p = page;
> - len = 0;
> - while (len < (off + count)) {
> - if ((*p == '\0') || (*p == '\n')) {
> - if (*p == '\0')
> - *p = '\n';
> - p++;
> - len++;
> - *eof = 1;
> + while (p - page < 256) {
> + if (*p == '\0' || *p == '\n') {
> + *p = '\n';
> break;
> }
> p++;
> - len++;
> - }
>
> - if (len < off) {
> - *eof = 1;
> - len = 0;
> }
> - return len;
> + seq_write(m, page, p - page);
> + kfree(page);
> + return 0;
> +}
> +
> +static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
> }
>
> #if 0
> @@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *pa
> }
> #endif
>
> -static int proc_mf_dump_side(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_side_proc_show(struct seq_file *m, void *v)
> {
> - int len;
> char mf_current_side = ' ';
> struct vsp_cmd_data vsp_cmd;
>
> @@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page,
> }
> }
>
> - len = sprintf(page, "%c\n", mf_current_side);
> + seq_printf(m, "%c\n", mf_current_side);
> + return 0;
> +}
>
> - if (len <= (off + count))
> - *eof = 1;
> - *start = page + off;
> - len -= off;
> - if (len > count)
> - len = count;
> - if (len < 0)
> - len = 0;
> - return len;
> +static int mf_side_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_side_proc_show, NULL);
> }
>
> -static int proc_mf_change_side(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> char side;
> u64 newSide;
> @@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct fi
> return count;
> }
>
> +static const struct file_operations mf_side_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_side_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_side_proc_write,
> +};
> +
> #if 0
> static void mf_getSrcHistory(char *buffer, int size)
> {
> @@ -1087,8 +1089,7 @@ static void mf_getSrcHistory(char *buffe
> }
> #endif
>
> -static int proc_mf_dump_src(char *page, char **start, off_t off,
> - int count, int *eof, void *data)
> +static int mf_src_proc_show(struct seq_file *m, void *v)
> {
> #if 0
> int len;
> @@ -1109,8 +1110,13 @@ static int proc_mf_dump_src(char *page,
> #endif
> }
>
> -static int proc_mf_change_src(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static int mf_src_proc_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, mf_src_proc_show, NULL);
> +}
> +
> +static ssize_t mf_src_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> char stkbuf[10];
>
> @@ -1135,9 +1141,19 @@ static int proc_mf_change_src(struct fil
> return count;
> }
>
> -static int proc_mf_change_cmdline(struct file *file, const char __user *buffer,
> - unsigned long count, void *data)
> +static const struct file_operations mf_src_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_src_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_src_proc_write,
> +};
> +
> +static ssize_t mf_cmdline_proc_write(struct file *file, const char __user *buffer,
> + size_t count, loff_t *pos)
> {
> + void *data = PDE(file->f_path.dentry->d_inode)->data;
> struct vsp_cmd_data vsp_cmd;
> dma_addr_t dma_addr;
> char *page;
> @@ -1172,6 +1188,15 @@ out:
> return ret;
> }
>
> +static const struct file_operations mf_cmdline_proc_fops = {
> + .owner = THIS_MODULE,
> + .open = mf_cmdline_proc_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = mf_cmdline_proc_write,
> +};
> +
> static ssize_t proc_mf_change_vmlinux(struct file *file,
> const char __user *buf,
> size_t count, loff_t *ppos)
> @@ -1246,12 +1271,10 @@ static int __init mf_proc_init(void)
> if (!mf)
> return 1;
>
> - ent = create_proc_entry("cmdline", S_IFREG|S_IRUSR|S_IWUSR, mf);
> + ent = proc_create_data("cmdline", S_IRUSR|S_IWUSR, mf,
> + &mf_cmdline_proc_fops, (void *)(long)i);
> if (!ent)
> return 1;
> - ent->data = (void *)(long)i;
> - ent->read_proc = proc_mf_dump_cmdline;
> - ent->write_proc = proc_mf_change_cmdline;
>
> if (i == 3) /* no vmlinux entry for 'D' */
> continue;
> @@ -1263,19 +1286,15 @@ static int __init mf_proc_init(void)
> return 1;
> }
>
> - ent = create_proc_entry("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
> + ent = proc_create("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
> + &mf_side_proc_fops);
> if (!ent)
> return 1;
> - ent->data = (void *)0;
> - ent->read_proc = proc_mf_dump_side;
> - ent->write_proc = proc_mf_change_side;
>
> - ent = create_proc_entry("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
> + ent = proc_create("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
> + &mf_src_proc_fops);
> if (!ent)
> return 1;
> - ent->data = (void *)0;
> - ent->read_proc = proc_mf_dump_src;
> - ent->write_proc = proc_mf_change_src;
>
> return 0;
> }
> _
>
> Patches currently in -mm which might be from adobriyan@gmail.com are
>
> linux-next.patch
> thinkpad_acpi-convert-to-seq_file.patch
> asus_acpi-convert-to-seq_file.patch
> toshiba_acpi-convert-to-seq_file.patch
> arm-convert-proc-cpu-aligment-to-seq_file.patch
> proc_fops-convert-av7110.patch
> proc_fops-convert-cpia.patch
> proc_fops-convert-drivers-isdn-to-seq_file.patch
> proc_fops-convert-drivers-isdn-to-seq_file-fix.patch
> mpt-fusion-convert-to-seq_file.patch
> const-constify-remaining-dev_pm_ops.patch
> uml-irq-register-race-condition.patch
> make-debug_bugverbose-default-to-y.patch
> proc-rename-de_get-to-pde_get-and-inline-it.patch
> pnpbios-convert-to-seq_file.patch
> const-constify-remaining-pipe_buf_operations.patch
> ufs-pass-qstr-instead-of-dentry-where-necessary-for-nfs.patch
> ufs-nfs-support.patch
> reiserfs-remove-proc-fs-reiserfs-version.patch
> reiserfs-dont-compile-procfso-at-all-if-no-support.patch
> uml-convert-to-seq_file-proc_fops.patch
> alpha-convert-srm-code-to-seq_file.patch
> iseries-convert-to-proc_fops.patch
> clps711xfb-convert-to-proc_fops.patch
> parisc-convert-proc-pdc-lcdled-to-seq_file.patch
> via-pmu-convert-to-proc_fops-seq_file.patch
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Benjamin Herrenschmidt @ 2009-12-08 4:56 UTC (permalink / raw)
To: Joe Perches
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Jean Delvare,
Darrick J. Wong
In-Reply-To: <1259947019.22783.116.camel@Joe-Laptop.home>
On Fri, 2009-12-04 at 09:16 -0800, Joe Perches wrote:
> On Fri, 2009-12-04 at 20:59 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-12-04 at 10:34 +0100, Jean Delvare wrote:
> > > I've sent it to linuxppc-dev@ozlabs.org on October 14th. This is the
> > > address which is listed 22 times in MAINTAINERS. If it isn't correct,
> > > then please update MAINTAINERS.
> > No it's fine both shoul work. Your patches are there, just waiting for
> > me to pick them up, I was just firing a reminder to the rest of the CC
> > list :-) (and I do remember fwd'ing a couple of your patches to the
> > list, for some reason they didn't make it to patchwork back then, that
> > was a few month ago).
> > Anyways, I've been stretched thin with all sort of stuff lately, so bear
> > with me if I'm a bit slow at taking or testing stuff, I'm doing my best.
>
> Adding patterns to the PowerPC sections of MAINTAINERS is useful.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Are you going to submit that yourself or do you want me to carry it in
the powerpc tree ?
Cheers,
Ben.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4f96ac8..c7f8e5a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3193,6 +3193,7 @@ LINUX FOR IBM pSERIES (RS/6000)
> M: Paul Mackerras <paulus@au.ibm.com>
> W: http://www.ibm.com/linux/ltc/projects/ppc
> S: Supported
> +F: arch/powerpc/boot/rs6000.h
>
> LINUX FOR POWERPC (32-BIT AND 64-BIT)
> M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> @@ -3201,18 +3202,24 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> S: Supported
> +F: Documentation/powerpc/
> +F: arch/powerpc/
>
> LINUX FOR POWER MACINTOSH
> M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> +F: arch/powerpc/platforms/powermac/
> +F: drivers/macintosh/
>
> LINUX FOR POWERPC EMBEDDED MPC5XXX
> M: Grant Likely <grant.likely@secretlab.ca>
> L: linuxppc-dev@ozlabs.org
> T: git git://git.secretlab.ca/git/linux-2.6.git
> S: Maintained
> +F: arch/powerpc/platforms/512x/
> +F: arch/powerpc/platforms/52xx/
>
> LINUX FOR POWERPC EMBEDDED PPC4XX
> M: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> @@ -3221,6 +3228,8 @@ W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
> S: Maintained
> +F: arch/powerpc/platforms/40x/
> +F: arch/powerpc/platforms/44x/
>
> LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
> M: Grant Likely <grant.likely@secretlab.ca>
> @@ -3228,6 +3237,8 @@ W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
> L: linuxppc-dev@ozlabs.org
> T: git git://git.secretlab.ca/git/linux-2.6.git
> S: Maintained
> +F: arch/powerpc/*/*virtex*
> +F: arch/powerpc/*/*/*virtex*
>
> LINUX FOR POWERPC EMBEDDED PPC8XX
> M: Vitaly Bordug <vitb@kernel.crashing.org>
> @@ -3241,12 +3252,16 @@ M: Kumar Gala <galak@kernel.crashing.org>
> W: http://www.penguinppc.org/
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> +F: arch/powerpc/platforms/83xx/
>
> LINUX FOR POWERPC PA SEMI PWRFICIENT
> M: Olof Johansson <olof@lixom.net>
> W: http://www.pasemi.com/
> L: linuxppc-dev@ozlabs.org
> S: Supported
> +F: arch/powerpc/platforms/pasemi/
> +F: drivers/*/*pasemi*
> +F: drivers/*/*/*pasemi*
>
> LINUX SECURITY MODULE (LSM) FRAMEWORK
> M: Chris Wright <chrisw@sous-sol.org>
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add PowerPC patterns
From: Joe Perches @ 2009-12-08 5:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, LKML, Colin Leroy, Paul Mackerras, Jean Delvare,
Darrick J. Wong
In-Reply-To: <1260248197.10809.32.camel@pasglop>
On Tue, 2009-12-08 at 15:56 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-04 at 09:16 -0800, Joe Perches wrote:
> > Adding patterns to the PowerPC sections of MAINTAINERS is useful.
> > Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Are you going to submit that yourself or do you want me to carry it in
> the powerpc tree ?
It'd be better if you carry it.
cheers, Joe
^ permalink raw reply
* Build failure with fsl_msi.c
From: Benjamin Herrenschmidt @ 2009-12-08 6:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
The ppc64e_defconfig gives me that:
No big deal since nothing currently uses Book3E HW with fsl_msi but
probably something you should fix.
cc1: warnings being treated as errors
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c: In function ‘fsl_msi_cascade’:
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c:189: error: cast from pointer to integer of different size
LDS arch/powerpc/kernel/vdso32/vdso32.lds
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c: In function ‘fsl_of_msi_probe’:
/home/benh/linux-powerpc-test/arch/powerpc/sysdev/fsl_msi.c:307: error: cast to pointer from integer of different size
make[2]: *** [arch/powerpc/sysdev/fsl_msi.o] Error 1
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v6 0/2] pseries: Add cede support for cpu-offline
From: Benjamin Herrenschmidt @ 2009-12-08 6:14 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: Peter Zijlstra, Gautham R Shenoy, linux-kernel, Arun R Bharadwaj,
Andrew Morton, linuxppc-dev, Ingo Molnar
In-Reply-To: <20091126195121.29159.66098.stgit@drishya>
Some of these patches (Gautham or Nathan, I haven't bisected) break
pseries build without CONFIG_SMP. I'll apply them anyways for now
to next and push them out today since nobody ever builds pseries without
CONFIG_SMP but I would appreciate if you could send a fix regardless.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2] powerpc/pseries: Track previous CPPR values to correctly EOI interrupts
From: Mark Nelson @ 2009-12-08 6:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200912031607.50465.markn@au1.ibm.com>
At the moment when we EOI an interrupt we set the CPPR back to 0xFF
regardless of its previous value. This could lead to problems if we
take an interrupt with a priority of 5, but before EOIing it we get
an IPI which has a priority of 4. The problem is that at the moment
when we EOI the IPI we will set the CPPR to 0xFF, but it should
really be set back to 5 (the previous priority).
To keep track of the previous CPPR values we create the xics_cppr
structure that has an array for CPPR values and an index pointing
to the current priority. This can easily grow if new priorities get
added in the future.
This will also be useful because the partition adjunct option of
upcoming machines will update the H_XIRR hcall to accept the CPPR
as a parameter.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
changes since v1:
* simplified function names to push_cppr() and pop_cppr()
* added checking for empty and full stack of cppr
* make sure to set cpu priority only when we're not already taking an interrupt
arch/powerpc/platforms/pseries/xics.c | 56 ++++++++++++++++++++++++++++++----
1 file changed, 51 insertions(+), 5 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/xics.c
+++ upstream/arch/powerpc/platforms/pseries/xics.c
@@ -20,6 +20,7 @@
#include <linux/cpu.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/percpu.h>
#include <asm/firmware.h>
#include <asm/io.h>
@@ -46,6 +47,12 @@ static struct irq_host *xics_host;
*/
#define IPI_PRIORITY 4
+/* The least favored priority */
+#define LOWEST_PRIORITY 0xFF
+
+/* The number of priorities defined above */
+#define MAX_NUM_PRIORITIES 3
+
static unsigned int default_server = 0xFF;
static unsigned int default_distrib_server = 0;
static unsigned int interrupt_server_size = 8;
@@ -56,6 +63,12 @@ static int ibm_set_xive;
static int ibm_int_on;
static int ibm_int_off;
+struct xics_cppr {
+ unsigned char stack[MAX_NUM_PRIORITIES];
+ int index;
+};
+
+static DEFINE_PER_CPU(struct xics_cppr, xics_cppr);
/* Direct hardware low level accessors */
@@ -284,6 +297,19 @@ static inline unsigned int xics_xirr_vec
return xirr & 0x00ffffff;
}
+static void push_cppr(unsigned int vec)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ if (WARN_ON(os_cppr->index >= MAX_NUM_PRIORITIES - 1))
+ return;
+
+ if (vec == XICS_IPI)
+ os_cppr->stack[++os_cppr->index] = IPI_PRIORITY;
+ else
+ os_cppr->stack[++os_cppr->index] = DEFAULT_PRIORITY;
+}
+
static unsigned int xics_get_irq_direct(void)
{
unsigned int xirr = direct_xirr_info_get();
@@ -294,8 +320,10 @@ static unsigned int xics_get_irq_direct(
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ push_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have rtas mask it. */
xics_mask_unknown_vec(vec);
@@ -315,8 +343,10 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ push_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have RTAS mask it. */
xics_mask_unknown_vec(vec);
@@ -326,12 +356,22 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
}
+static unsigned char pop_cppr(void)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ if (WARN_ON(os_cppr->index < 1))
+ return LOWEST_PRIORITY;
+
+ return os_cppr->stack[--os_cppr->index];
+}
+
static void xics_eoi_direct(unsigned int virq)
{
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- direct_xirr_info_set((0xff << 24) | irq);
+ direct_xirr_info_set((pop_cppr() << 24) | irq);
}
static void xics_eoi_lpar(unsigned int virq)
@@ -339,7 +379,7 @@ static void xics_eoi_lpar(unsigned int v
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- lpar_xirr_info_set((0xff << 24) | irq);
+ lpar_xirr_info_set((pop_cppr() << 24) | irq);
}
static int xics_set_affinity(unsigned int virq, const struct cpumask *cpumask)
@@ -746,6 +786,12 @@ void __init xics_init_IRQ(void)
static void xics_set_cpu_priority(unsigned char cppr)
{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ BUG_ON(os_cppr->index != 0);
+
+ os_cppr->stack[os_cppr->index] = cppr;
+
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_cppr_info(cppr);
else
@@ -772,7 +818,7 @@ static void xics_set_cpu_giq(unsigned in
void xics_setup_cpu(void)
{
- xics_set_cpu_priority(0xff);
+ xics_set_cpu_priority(LOWEST_PRIORITY);
xics_set_cpu_giq(default_distrib_server, 1);
}
^ permalink raw reply
* Re: + iseries-convert-to-proc_fops.patch added to -mm tree
From: Andrew Morton @ 2009-12-08 6:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, adobriyan
In-Reply-To: <1260247339.10809.31.camel@pasglop>
On Tue, 08 Dec 2009 15:42:19 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Tue, 2009-12-01 at 14:05 -0800, akpm@linux-foundation.org wrote:
> > The patch titled
> > iseries: convert to proc_fops
> > has been added to the -mm tree. Its filename is
> > iseries-convert-to-proc_fops.patch
>
> I was looking at that patch since It was in my queue, and while I
> have no firm objection, I started wondering what was the point :-)
>
> IE. What does seq_file buys us here since the conversion adds more
> code than it removes and adds a hope via kmalloc that isn't necessary
> before the said conversion ?
>
> Those files are only ever one line long (and one of them is only one
> character) so the seq_file doesn't really gets us any benefit does it ?
Might be related to this:
: Convert code away from ->read_proc/->write_proc interfaces. Switch to
: proc_create()/proc_create_data() which make addition of proc entries
: reliable wrt NULL ->proc_fops, NULL ->data and so on.
:
: Problem with ->read_proc et al is described here commit
: 786d7e1612f0b0adb6046f19b906609e4fe8b1ba "Fix rmmod/read/write races in
: /proc entries"
but the real answer is: I have no idea.
Hopefully Andrey is now cured of his tendency to send unchangelogged
patches.
Andrey, please send along changelogs for
iseries-convert-to-proc_fops.patch
via-pmu-convert-to-proc_fops-seq_file.patch
proc_fops-convert-av7110.patch
proc_fops-convert-cpia.patch
proc_fops-convert-drivers-isdn-to-seq_file.patch
uml-convert-to-seq_file-proc_fops.patch
clps711xfb-convert-to-proc_fops.patch
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: 林志平 @ 2009-12-08 6:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <8148211e0912071825t22ffa590va2fe22272f6aaf62@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
PING works now, after modifying the code of gianfar-mii.c
2009/12/8 林志平 <solyn123@gmail.com>
>
> 2009/12/8 Scott Wood <scottwood@freescale.com>
>
> On Mon, Dec 07, 2009 at 11:53:22AM +0800, 林志平 wrote:
>> > Does dtc1.2.0 can compile dts files under linux2.6.23?
>>
>> Probably not -- 2.6.23 is very old, and I think newer dtcs only support
>> the
>> newer dts syntax.
>>
>> > Another question is that I found linux2.6.31 does not support
>> > board mpc8544ds,
>>
>> It should. What problems do you see?
>
> => bootm 0x1000000 0x1800000 0x800000
> ## Booting kernel from Legacy Image at 01000000 ...
> Image Name: Linux-2.6.31
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 2185099 Bytes = 2.1 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 01800000 ...
> Image Name: Simple Embedded Linux Framework
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 1859256 Bytes = 1.8 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00800000
> Booting using the fdt blob at 0x800000
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
> booting kernel using flat tree
> It then stops and never print any more, I use mpc85xx_defconfig, I select
> mpc85xxds in the menuconfig and deselect other options like mpc8540ads etc.
>
>>
>> > And I never boot linux-2.6.31 on my board, why linux-2.6.31 doesnot
>> > provide a config file like mpc8544_ds_defconfig?
>>
>> Does mpc85xx_defconfig not work?
>>
> Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the
> menuconfig, but no mpc8544ds. And when I down load the generated uImage, It
> does not work.
>
>
>> -Scott
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3076 bytes --]
^ permalink raw reply
* Re: Ping does not work on my MPC8544 board, using linux2.6.23
From: hank peng @ 2009-12-08 7:12 UTC (permalink / raw)
To: 林志平; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <8148211e0912071825t22ffa590va2fe22272f6aaf62@mail.gmail.com>
2009/12/8 =E6=9E=97=E5=BF=97=E5=B9=B3 <solyn123@gmail.com>:
>
> 2009/12/8 Scott Wood <scottwood@freescale.com>
>>
>> On Mon, Dec 07, 2009 at 11:53:22AM +0800, =E6=9E=97=E5=BF=97=E5=B9=B3 wr=
ote:
>> > Does dtc1.2.0 can compile dts files under linux2.6.23?
>>
>> Probably not -- 2.6.23 is very old, and I think newer dtcs only support
>> the
>> newer dts syntax.
>>
>> > Another question is that I found linux2.6.31 does not support
>> > board mpc8544ds,
>>
>> It should. =C2=A0What problems do you see?
>
> =3D> bootm 0x1000000 0x1800000 0x800000
> ## Booting kernel from Legacy Image at 01000000 ...
> =C2=A0=C2=A0 Image Name:=C2=A0=C2=A0 Linux-2.6.31
> =C2=A0=C2=A0 Image Type:=C2=A0=C2=A0 PowerPC Linux Kernel Image (gzip com=
pressed)
> =C2=A0=C2=A0 Data Size:=C2=A0=C2=A0=C2=A0 2185099 Bytes =3D=C2=A0 2.1 MB
> =C2=A0=C2=A0 Load Address: 00000000
> =C2=A0=C2=A0 Entry Point:=C2=A0 00000000
> =C2=A0=C2=A0 Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 01800000 ...
> =C2=A0=C2=A0 Image Name:=C2=A0=C2=A0 Simple Embedded Linux Framework
> =C2=A0=C2=A0 Image Type:=C2=A0=C2=A0 PowerPC Linux RAMDisk Image (gzip co=
mpressed)
> =C2=A0=C2=A0 Data Size:=C2=A0=C2=A0=C2=A0 1859256 Bytes =3D=C2=A0 1.8 MB
> =C2=A0=C2=A0 Load Address: 00000000
> =C2=A0=C2=A0 Entry Point:=C2=A0 00000000
> =C2=A0=C2=A0 Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00800000
> =C2=A0=C2=A0 Booting using the fdt blob at 0x800000
> =C2=A0=C2=A0 Uncompressing Kernel Image ... OK
> =C2=A0=C2=A0 Loading Ramdisk to 1fca7000, end 1fe6ceb8 ... OK
> booting kernel using flat tree
> It then stops and never print any more,=C2=A0 I use mpc85xx_defconfig, I =
select
> mpc85xxds in the menuconfig and deselect other options like mpc8540ads et=
c.
>>
Try to change "link_address=3D'0x400000'" tp "link_address=3D'0x800000'"
in arch/powerpc/boot/wrapper.
If you have result, remember to give me a feedback.
>> > And I never boot linux-2.6.31 on my board, why linux-2.6.31 doesnot
>> > provide a config file like mpc8544_ds_defconfig?
>>
>> Does mpc85xx_defconfig not work?
>
> Yes mcp85xx_defconfig does not work, I can see mpc8540ads in the menuconf=
ig,
> but no mpc8544ds. And when I down load the generated uImage, It does not
> work.
>
>>
>> -Scott
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* [PATCH 1/3] powerpc/fsl: 85xx: document cache sram bindings
From: Vivek Mahajan @ 2009-12-08 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
Adds binding documentation for cache sram for the PQ3 and
some QorIQ based platforms.
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
.../powerpc/dts-bindings/fsl/85xx_cache_sram.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt b/Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt
new file mode 100644
index 0000000..781955f
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/85xx_cache_sram.txt
@@ -0,0 +1,20 @@
+* Freescale PQ3 and QorIQ based Cache SRAM
+
+Freescale's mpc85xx and some QorIQ platforms provide an
+option of configuring a part of (or full) cache memory
+as SRAM. This cache SRAM representation in the device
+tree should be done as under:-
+
+Required properties:
+
+- compatible : should be "fsl,p2020-cache-sram"
+- fsl,cache-sram-ctlr-handle : points to the L2 controller
+- reg : offset and length of the cache-sram.
+
+Example:
+
+cache-sram@fff00000 {
+ fsl,cache-sram-ctlr-handle = <&L2>;
+ reg = <0 0xfff00000 0 0x10000>;
+ compatible = "fsl,p2020-cache-sram";
+};
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/3] powerpc/fsl: 85xx: p2020rdb: add cache sram node
From: Vivek Mahajan @ 2009-12-08 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1260257477-21942-1-git-send-email-vivek.mahajan@freescale.com>
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
arch/powerpc/boot/dts/p2020rdb.dts | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index da4cb0d..8a26050 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -583,4 +583,10 @@
0x0 0x100000>;
};
};
+
+ cache-sram@fff00000 {
+ fsl,cache-sram-ctlr-handle = <&L2>;
+ reg = <0 0xfff00000 0 0x10000>;
+ compatible = "fsl,p2020-cache-sram";
+ };
};
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/3] powerpc/fsl: 85xx: add cache-sram support
From: Vivek Mahajan @ 2009-12-08 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
In-Reply-To: <1260257477-21942-2-git-send-email-vivek.mahajan@freescale.com>
It adds PQ3 and some QorIQ based cache-sram support as under:
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
* Supports only one contiguous SRAM window
* Drivers can do the following in Kconfig to use these APIs
"select FSL_85XX_CACHE_SRAM if FSL_SOC_BOOKE"
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 48 ++++
arch/powerpc/platforms/85xx/Kconfig | 4 +
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 3 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h | 95 ++++++++
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 298 ++++++++++++++++++++++++
6 files changed, 449 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_85xx_cache_sram.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
create mode 100644 arch/powerpc/sysdev/fsl_85xx_cache_sram.c
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
new file mode 100644
index 0000000..d39e266
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Cache SRAM handling for PQ3 and some QorIQ platforms
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+#define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
+
+#include <asm/rheap.h>
+#include <linux/spinlock.h>
+
+/*
+ * Cache-SRAM
+ */
+
+struct mpc85xx_cache_sram {
+ phys_addr_t base_phys;
+ void *base_virt;
+ unsigned int size;
+ rh_info_t *rh;
+ spinlock_t lock;
+};
+
+extern void mpc85xx_cache_sram_free(void *ptr);
+extern void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align);
+
+#endif /* __AMS_POWERPC_FSL_85XX_CACHE_SRAM_H__ */
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index d951218..74df154 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -157,6 +157,10 @@ config P4080_DS
help
This option enables support for the P4080 DS board
+config FSL_85XX_CACHE_SRAM
+ bool
+ select PPC_LIB_RHEAP
+
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 088f30b..070b54b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -113,6 +113,9 @@ static struct of_device_id __initdata mpc85xxrdb_ids[] = {
{ .compatible = "soc", },
{ .compatible = "simple-bus", },
{ .compatible = "gianfar", },
+#if defined(CONFIG_FSL_85XX_CACHE_SRAM)
+ { .compatible = "fsl,p2020-cache-sram", },
+#endif
{},
};
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 5642924..4dc7e1d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o
+obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
obj-$(CONFIG_RAPIDIO) += fsl_rio.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
new file mode 100644
index 0000000..3f51c1b
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_ctlr.h
@@ -0,0 +1,95 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc
+ *
+ * PQ3 or some QorIQ based Cache Controller Memory Mapped Registers
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __FSL_85XX_CACHE_CTLR_H__
+#define __FSL_85XX_CACHE_CTLR_H__
+
+#define L2CR_L2FI 0x40000000 /* L2 flash invalidate */
+#define L2CR_L2IO 0x00200000 /* L2 instruction only */
+#define L2CR_SRAM_ZERO 0x00000000 /* L2SRAM zero size */
+#define L2CR_SRAM_FULL 0x00010000 /* L2SRAM full size */
+#define L2CR_SRAM_HALF 0x00020000 /* L2SRAM half size */
+#define L2CR_SRAM_TWO_HALFS 0x00030000 /* L2SRAM two half sizes */
+#define L2CR_SRAM_QUART 0x00040000 /* L2SRAM one quarter size */
+#define L2CR_SRAM_TWO_QUARTS 0x00050000 /* L2SRAM two quarter size */
+#define L2CR_SRAM_EIGHTH 0x00060000 /* L2SRAM one eighth size */
+#define L2CR_SRAM_TWO_EIGHTH 0x00070000 /* L2SRAM two eighth size */
+
+#define L2SRAM_OPTIMAL_SZ_SHIFT 0x00000003 /* Optimum size for L2SRAM */
+
+#define L2SRAM_BAR_MSK_LO18 0xFFFFC000 /* Lower 18 bits */
+#define L2SRAM_BARE_MSK_HI4 0x0000000F /* Upper 4 bits */
+
+enum cache_sram_lock_ways {
+ LOCK_WAYS_ZERO,
+ LOCK_WAYS_EIGHTH,
+ LOCK_WAYS_TWO_EIGHTH,
+ LOCK_WAYS_HALF = 4,
+ LOCK_WAYS_FULL = 8,
+};
+
+struct mpc85xx_l2ctlr {
+ u32 ctl; /* 0x000 - L2 control */
+ u8 res1[0xC];
+ u32 ewar0; /* 0x010 - External write address 0 */
+ u32 ewarea0; /* 0x014 - External write address extended 0 */
+ u32 ewcr0; /* 0x018 - External write ctrl */
+ u8 res2[4];
+ u32 ewar1; /* 0x020 - External write address 1 */
+ u32 ewarea1; /* 0x024 - External write address extended 1 */
+ u32 ewcr1; /* 0x028 - External write ctrl 1 */
+ u8 res3[4];
+ u32 ewar2; /* 0x030 - External write address 2 */
+ u32 ewarea2; /* 0x034 - External write address extended 2 */
+ u32 ewcr2; /* 0x038 - External write ctrl 2 */
+ u8 res4[4];
+ u32 ewar3; /* 0x040 - External write address 3 */
+ u32 ewarea3; /* 0x044 - External write address extended 3 */
+ u32 ewcr3; /* 0x048 - External write ctrl 3 */
+ u8 res5[0xB4];
+ u32 srbar0; /* 0x100 - SRAM base address 0 */
+ u32 srbarea0; /* 0x104 - SRAM base addr reg ext address 0 */
+ u32 srbar1; /* 0x108 - SRAM base address 1 */
+ u32 srbarea1; /* 0x10C - SRAM base addr reg ext address 1 */
+ u8 res6[0xCF0];
+ u32 errinjhi; /* 0xE00 - Error injection mask high */
+ u32 errinjlo; /* 0xE04 - Error injection mask low */
+ u32 errinjctl; /* 0xE08 - Error injection tag/ecc control */
+ u8 res7[0x14];
+ u32 captdatahi; /* 0xE20 - Error data high capture */
+ u32 captdatalo; /* 0xE24 - Error data low capture */
+ u32 captecc; /* 0xE28 - Error syndrome */
+ u8 res8[0x14];
+ u32 errdet; /* 0xE40 - Error detect */
+ u32 errdis; /* 0xE44 - Error disable */
+ u32 errinten; /* 0xE48 - Error interrupt enable */
+ u32 errattr; /* 0xE4c - Error attribute capture */
+ u32 erradrrl; /* 0xE50 - Error address capture low */
+ u32 erradrrh; /* 0xE54 - Error address capture high */
+ u32 errctl; /* 0xE58 - Error control */
+ u8 res9[0x1A4];
+};
+
+extern int instantiate_cache_sram(struct of_device *dev, unsigned int size);
+extern void remove_cache_sram(struct of_device *dev);
+
+#endif /* __FSL_85XX_CACHE_CTLR_H__ */
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
new file mode 100644
index 0000000..5aaacf6
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -0,0 +1,298 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * Simple memory allocator abstraction for PQ3 and
+ * some QorIQ based Cache-SRAM
+ *
+ * Author: Vivek Mahajan <vivek.mahajan@freescale.com>
+ *
+ * This file is derived from the original work done
+ * by Sylvain Munaut for the Bestcomm SRAM allocator.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/pgtable.h>
+#include <asm/fsl_85xx_cache_sram.h>
+
+#include "fsl_85xx_cache_ctlr.h"
+
+struct mpc85xx_cache_sram *cache_sram;
+
+void *mpc85xx_cache_sram_alloc(unsigned int size,
+ phys_addr_t *phys, unsigned int align)
+{
+ unsigned long offset;
+ unsigned long flags;
+
+ if (!size || (size > cache_sram->size) || (align > cache_sram->size)) {
+ pr_err("%s(): size(=%x) or align(=%x) zero or too big\n",
+ __func__, size, align);
+ return NULL;
+ }
+
+ if ((align & (align - 1)) || align <= 1) {
+ pr_err("%s(): align(=%x) must be power of two and >1\n",
+ __func__, align);
+ return NULL;
+ }
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ offset = rh_alloc_align(cache_sram->rh, size, align, NULL);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+
+ if (IS_ERR_VALUE(offset))
+ return NULL;
+
+ *phys = cache_sram->base_phys + offset;
+
+ return (unsigned char *)cache_sram->base_virt + offset;
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_alloc);
+
+void mpc85xx_cache_sram_free(void *ptr)
+{
+ unsigned long flags;
+ BUG_ON(!ptr);
+
+ spin_lock_irqsave(&cache_sram->lock, flags);
+ rh_free(cache_sram->rh, ptr - cache_sram->base_virt);
+ spin_unlock_irqrestore(&cache_sram->lock, flags);
+}
+EXPORT_SYMBOL(mpc85xx_cache_sram_free);
+
+static int l2ctlr_init(struct of_device *dev, phys_addr_t *sram_start,
+ unsigned long *sram_size)
+{
+ long rval;
+ unsigned int rem;
+ unsigned char ways;
+ const phandle *ph;
+ const unsigned int *prop;
+ unsigned int l2cache_size;
+ struct device_node *np;
+ struct resource sram_rsrc;
+ struct mpc85xx_l2ctlr __iomem *l2ctlr;
+
+ ph = of_get_property(dev->node, "fsl,cache-sram-ctlr-handle", NULL);
+ if (!ph) {
+ dev_err(&dev->dev, "Missing cache-ctlr-handle\n");
+ return -EINVAL;
+ }
+
+ np = of_find_node_by_phandle(*ph);
+ if (!np) {
+ dev_err(&dev->dev, "Missing L2 controller node\n");
+ return -EINVAL;
+ }
+
+ prop = of_get_property(np, "cache-size", NULL);
+ if (!prop) {
+ dev_err(&dev->dev, "Missing L2 cache-size\n");
+ of_node_put(np);
+ return -EINVAL;
+ }
+ l2cache_size = *prop;
+
+ if (of_address_to_resource(dev->node, 0, &sram_rsrc)) {
+ dev_err(&dev->dev, "Can't read cache sram window\n");
+ of_node_put(np);
+ return -EFAULT;
+ }
+
+ *sram_start = sram_rsrc.start;
+ rval = (unsigned long)(sram_rsrc.end - sram_rsrc.start) + 1;
+ if (rval <= 0) {
+ dev_err(&dev->dev,
+ "Entire L2 as cache, Aborting cache sram stuff\n");
+ of_node_put(np);
+ return -EINVAL;
+ }
+
+ rem = l2cache_size % (unsigned int)rval;
+ ways = LOCK_WAYS_FULL * (unsigned int)rval / l2cache_size;
+ if (rem || (ways & (ways - 1))) {
+ dev_err(&dev->dev, "Illegal cache-size in the node\n");
+ of_node_put(np);
+ return -EINVAL;
+ }
+
+ *sram_size = (unsigned long)rval;
+
+ l2ctlr = of_iomap(np, 0);
+ of_node_put(np);
+ if (!l2ctlr) {
+ dev_err(&dev->dev, "Can't map L2 controller\n");
+ return -EINVAL;
+ }
+
+ /*
+ * Write bits[0-17] to srbar0
+ */
+ out_be32(&l2ctlr->srbar0,
+ (unsigned long)(*sram_start) & L2SRAM_BAR_MSK_LO18);
+
+ /*
+ * Write bits[18-21] to srbare0
+ */
+ out_be32(&l2ctlr->srbarea0,
+ (((unsigned long)(*sram_start)) >> 10) & L2SRAM_BARE_MSK_HI4);
+
+ clrsetbits_be32(&l2ctlr->ctl, L2CR_L2E, L2CR_L2FI);
+
+ switch (ways) {
+ case LOCK_WAYS_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_EIGHTH);
+ break;
+
+ case LOCK_WAYS_TWO_EIGHTH:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_QUART);
+ break;
+
+ case LOCK_WAYS_HALF:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_HALF);
+ break;
+
+ case LOCK_WAYS_FULL:
+ default:
+ setbits32(&l2ctlr->ctl,
+ L2CR_L2E | L2CR_L2FI | L2CR_SRAM_FULL);
+ break;
+ }
+ eieio();
+
+ iounmap(l2ctlr);
+ return 0;
+}
+
+static int __devinit mpc85xx_cache_sram_of_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ phys_addr_t sram_start;
+ unsigned long sram_size;
+
+ if (cache_sram) {
+ dev_err(&dev->dev, "Already initialized cache-sram\n");
+ return -EBUSY;
+ }
+
+ if (!dev->node) {
+ dev_err(&dev->dev, "Device's OF-node is NULL\n");
+ return -EINVAL;
+ }
+
+ if (l2ctlr_init(dev, &sram_start, &sram_size) < 0) {
+ dev_err(&dev->dev, "l2ctlr_init() fails\n");
+ return -EINVAL;
+ }
+
+ cache_sram = kzalloc(sizeof(struct mpc85xx_cache_sram), GFP_KERNEL);
+ if (!cache_sram) {
+ dev_err(&dev->dev, "Out of memory for cache_sram structure\n");
+ return -ENOMEM;
+ }
+
+ cache_sram->base_phys = sram_start;
+ cache_sram->size = sram_size;
+
+ if (!request_mem_region(cache_sram->base_phys, cache_sram->size,
+ "fsl_85xx_cache_sram")) {
+ dev_err(&dev->dev, "%s: request memory failed\n",
+ dev->node->full_name);
+ kfree(cache_sram);
+ return -ENXIO;
+ }
+
+ cache_sram->base_virt = ioremap_flags(cache_sram->base_phys,
+ cache_sram->size, _PAGE_COHERENT | PAGE_KERNEL);
+ if (!cache_sram->base_virt) {
+ dev_err(&dev->dev, "%s: ioremap_flags failed\n",
+ dev->node->full_name);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return -ENOMEM;
+ }
+
+ cache_sram->rh = rh_create(sizeof(unsigned int));
+ if (IS_ERR(cache_sram->rh)) {
+ dev_err(&dev->dev, "%s: Unable to create remote heap\n",
+ dev->node->full_name);
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+ kfree(cache_sram);
+ return PTR_ERR(cache_sram->rh);
+ }
+
+ rh_attach_region(cache_sram->rh, 0, cache_sram->size);
+ spin_lock_init(&cache_sram->lock);
+
+ dev_info(&dev->dev, "[base:0x%x, size:0x%x] configured and loaded\n",
+ cache_sram->base_phys, cache_sram->size);
+ return 0;
+}
+
+static int __devexit mpc85xx_cache_sram_remove(struct of_device *dev)
+{
+ BUG_ON(!cache_sram);
+
+ rh_detach_region(cache_sram->rh, 0, cache_sram->size);
+ rh_destroy(cache_sram->rh);
+
+ iounmap(cache_sram->base_virt);
+ release_mem_region(cache_sram->base_phys, cache_sram->size);
+
+ kfree(cache_sram);
+ cache_sram = NULL;
+
+ dev_info(&dev->dev, "MPC85xx cache SRAM driver unloaded\n");
+ return 0;
+}
+
+static struct of_device_id mpc85xx_cache_sram_of_match[] = {
+ {
+ .compatible = "fsl,p2020-cache-sram",
+ },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, mpc85xx_cache_sram_of_match);
+
+static struct of_platform_driver mpc85xx_cache_sram_driver = {
+ .name = "fsl-85xx-cache-sram",
+ .match_table = mpc85xx_cache_sram_of_match,
+ .probe = mpc85xx_cache_sram_of_probe,
+ .remove = __devexit_p(mpc85xx_cache_sram_remove),
+};
+
+static int __init mpc85xx_cache_sram_init(void)
+{
+ return of_register_platform_driver(&mpc85xx_cache_sram_driver);
+}
+
+static void __exit mpc85xx_cache_sram_exit(void)
+{
+ of_unregister_platform_driver(&mpc85xx_cache_sram_driver);
+}
+
+subsys_initcall(mpc85xx_cache_sram_init);
+module_exit(mpc85xx_cache_sram_exit);
+
+MODULE_DESCRIPTION("Freescale MPC85xx cache SRAM driver");
+MODULE_LICENSE("GPL v2");
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-12-08 8:38 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <4B14465A.3080804@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 30/11/2009 23:25:30:
>
> Benjamin Herrenschmidt wrote:
> > On Fri, 2009-11-27 at 11:57 +0100, Joakim Tjernlund wrote:
> >> Scott and Rex, I think we need you s-o-b to make it into the kernel proper.
> >>
> >> Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
> >> Have you seen this? What do you think?
> >
> > I think Marcelo isn't much involved with 8xx anymore. I'd say if Scott
> > and Vitaly are ok, then the patches are good. But I'll wait for at least
> > Scott to give an Ack as he can at least test which I can't :-)
>
> ACK
Can't see these patches in next yet, did they go somewhere else?
^ 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