* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Grant Likely @ 2007-10-03 4:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191365012.22572.33.camel@pasglop>
On 10/2/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > My opinion is that since it is driver-specific code anyway, then it
> > belongs with the driver. Plus a driver writer for ARM doesn't need to
> > write them. It's the powerpc or microblaze developer who will do it.
> > If the driver maintainer doesn't want the binding in the main driver
> > .c file, then the binding can easily be in an additional .c file
> > without needing to add a constructor. (Kind of like how many USB host
> > controllers are managed)
>
> The main advantage is that it keeps the OF specific code localized to a
> single function, whether that function lives in the driver or the arch
> code, it makes it self contained and easier to deal with by the driver
> author.
>
> Having multiple device types on which the driver can attach is a pain
> from a driver standpoint. It needs multiple
> probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
> maintainance burden in the long run.
For many drivers, I think that is already the case. USB OHCI is a
prime example where there are both PCI and platform_bus bindings among
others. It seems to me that the bus binding effectively translates
down to "where do I go to get the needed information". I think it
results in less of a maintenance burden to explicitly separate bus
binding from device setup as opposed to adding constructor code.
> The important thing however, with the constructor approach is to try as
> much as possible to keep the proper tree structure, and thus, try to
> find a way to instanciate the devices with proper parent/child
> relationship so that ordering for things like suspend/resume operations
> is maintained.
I'm not sure I follow. Example?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 4:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003011909.GG9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
On Wed, 2007-10-03 at 11:19 +1000, Tony Breeds wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
Better .. but .. :D
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..73401c8 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> -
> +static int logging_enabled; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
Until we initialise what exactly?
> static int error_log_cnt;
>
> /*
> @@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> }
>
> /* Write error to NVRAM */
> - if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
> + if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
> nvram_write_error_log(buf, len, err_type, error_log_cnt);
>
> /*
> @@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> printk_log_rtas(buf, len);
>
> /* Check to see if we need to or have stopped logging */
> - if (fatal || no_more_logging) {
> - no_more_logging = 1;
> + if (fatal || !logging_enabled) {
> + logging_enabled = 0;
> spin_unlock_irqrestore(&rtasd_log_lock, s);
> return;
> }
Hmmm, this routine has 4 separate lock-dropping exit paths ..
> @@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
>
> spin_lock_irqsave(&rtasd_log_lock, s);
> /* if it's 0, then we know we got the last one (the one in NVRAM) */
> - if (rtas_log_size == 0 && !no_more_logging)
> + if (rtas_log_size == 0 && logging_enabled)
> nvram_clear_error_log();
> spin_unlock_irqrestore(&rtasd_log_lock, s);
>
> @@ -414,6 +415,8 @@ static int rtasd(void *unused)
> memset(logdata, 0, rtas_error_log_max);
> rc = nvram_read_error_log(logdata, rtas_error_log_max,
> &err_type, &error_log_cnt);
> + /* We can use rtas_log_buf now */
> + logging_enabled = 1;
>
> if (!rc) {
> if (err_type != ERR_FLAG_ALREADY_LOGGED) {
What exactly happens that allows us to do logging? I don't see any
ordering between anything else and the setting of the flag, and AFAICT
we're not inside a spinlock or anything here.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 3:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <18179.1934.821688.836972@cargo.ozlabs.ibm.com>
On Wed, Oct 03, 2007 at 01:07:58PM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > > This makes the kernel use 1TB segments for all kernel mappings and for
> > > user addresses of 1TB and above, on machines which support them
> > > (currently POWER5+ and POWER6).
> >
> > PA6T supports them as well :)
>
> In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
> in the cputable entry for any processor; instead we look in the
> ibm,processor-segment-sizes property in the cpu node(s) in the device
> tree.
Yep, I see that. I just wanted to clarify it for the (future) commit
message.
> Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
> cputable entry for the PA6T, or will your firmware gives the
> ibm,processor-segment-sizes property in the device tree?
Thanks, but we've already got the properties there so it just works.
> > Wouldn't it be possible to stick with 1TB segments for the low range
> > for 64-bit processes as well, and have them allocate their hugepages
> > at >1TB?
>
> You mean, forbid hugepages below 1TB? That would be a user-visible
> ABI change. There are linker scripts for generating executables whose
> text and/or data can go in hugepages, and I believe they put the
> text/data below 1TB.
Hm, good point. Bummer.
-Olof
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:13 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Jon Tollefson
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Will Schmidt writes:
> I still need to test this code for performance issues, and this version
> could still use some cosmetic touchups, so I dont think we want this to
> go into a tree yet. I am reposting this primarily to indicate the prior
> version isnt quite right, and so Jon can rebase to this version. :-)
The way we scan the ibm,processor-segment-sizes property could be
nicer. Where there any other cosmetic touchups you were thinking of,
and if so what were they? I didn't notice any leftover debugging
printks or anything else that obviously needed cleaning up.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <20071003021105.GA6553@lixom.net>
Olof Johansson writes:
> > This makes the kernel use 1TB segments for all kernel mappings and for
> > user addresses of 1TB and above, on machines which support them
> > (currently POWER5+ and POWER6).
>
> PA6T supports them as well :)
In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
in the cputable entry for any processor; instead we look in the
ibm,processor-segment-sizes property in the cpu node(s) in the device
tree. Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
cputable entry for the PA6T, or will your firmware gives the
ibm,processor-segment-sizes property in the device tree?
> Wouldn't it be possible to stick with 1TB segments for the low range
> for 64-bit processes as well, and have them allocate their hugepages
> at >1TB?
You mean, forbid hugepages below 1TB? That would be a user-visible
ABI change. There are linker scripts for generating executables whose
text and/or data can go in hugepages, and I believe they put the
text/data below 1TB.
Paul.
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Paul Mackerras @ 2007-10-03 2:51 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Klein, Arnd Bergmann, Jan-Bernd Themann, Paul Mackerras,
LKML, LinuxPPC-Dev, Christoph Raisch, Stefan Roscher
In-Reply-To: <200709261145.51926.fenkes@de.ibm.com>
Joachim Fenkes writes:
> Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> and struct of_platform_driver, respectively. Match the external ibmebus
> interface and drivers using it.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_classes.h | 2 +-
> drivers/net/ehea/ehea.h | 2 +-
> include/asm-powerpc/ibmebus.h | 38 +++------------
> arch/powerpc/kernel/ibmebus.c | 28 ++++++-----
> drivers/infiniband/hw/ehca/ehca_eq.c | 6 +-
> drivers/infiniband/hw/ehca/ehca_main.c | 32 ++++++------
> drivers/net/ehea/ehea_main.c | 72 ++++++++++++++--------------
This is somewhat difficult as this patch touches files that are the
responsibility of three different maintainers. Is it possible to
split the patch into three, one for each maintainer (possibly by
keeping both old and new interfaces around for a little while)?
If not, then you need to get an Acked-by and an agreement that this
change can go via the powerpc.git tree from Roland Dreier and Jeff
Garzik.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 2:11 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Jon Tollefson, Paul Mackerras
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Hi,
On Tue, Oct 02, 2007 at 01:37:54PM -0500, Will Schmidt wrote:
> [RFC v2] 1TB Segment size support
>
> From: <>
>
> 1TB Segment size support
>
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6).
PA6T supports them as well :)
> We don't currently use 1TB segments
> for user addresses < 1T, since that would effectively prevent 32-bit
> processes from using huge pages unless we also had a way to revert to
> using 256MB segments.
Wouldn't it be possible to stick with 1TB segments for the low range
for 64-bit processes as well, and have them allocate their hugepages
at >1TB?
-Olof
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: KAMEZAWA Hiroyuki @ 2007-10-03 1:19 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1191366653.6106.68.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 02 Oct 2007 16:10:53 -0700
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > code to be able to do this.
> >
> > Isn't it just a matter of abstracting the test for a valid range of
> > memory? If it's really hard to abstract that, then I guess we can put
> > RAM in iomem_resource, but I'd rather not.
> >
>
> Sure. I will work on it and see how ugly it looks.
>
> KAME, are you okay with abstracting the find_next_system_ram() and
> let arch provide whatever implementation they want ? (since current
> code doesn't work for x86-64 also ?).
>
Hmm, registering /proc/iomem is complicated ? If too complicated, adding config
like
CONFIG_ARCH_SUPPORT_IORESOURCE_RAM or something can do good work.
you can define your own "check_pages_isolated" (you can rename this to
arch_check_apges_isolated().)
BTW, I shoudl ask people how to describe conventional memory
A. #define IORESOURCE_RAM IORESOURCE_MEM (ia64)
B. #define IORESOURCE_RAM IORESOURCE_MEM | IORESOUCE_BUSY (i386, x86_64)
Sad to say, memory hot-add registers new memory just as IORESOURCE_MEM.
Thanks,
-Kame
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 1:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <1191371416.8073.1.camel@concordia>
On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> I realise it'll make the patch bigger, but this doesn't seem like a
> particularly good name for the variable anymore.
Sure, what about?
Clarify when RTAS logging is enabled.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..73401c8 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
-
+static int logging_enabled; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
static int error_log_cnt;
/*
@@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
}
/* Write error to NVRAM */
- if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
+ if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
@@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
printk_log_rtas(buf, len);
/* Check to see if we need to or have stopped logging */
- if (fatal || no_more_logging) {
- no_more_logging = 1;
+ if (fatal || !logging_enabled) {
+ logging_enabled = 0;
spin_unlock_irqrestore(&rtasd_log_lock, s);
return;
}
@@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && !no_more_logging)
+ if (rtas_log_size == 0 && logging_enabled)
nvram_clear_error_log();
spin_unlock_irqrestore(&rtasd_log_lock, s);
@@ -414,6 +415,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ logging_enabled = 1;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Josh Boyer @ 2007-10-03 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18178.55231.813138.369480@cargo.ozlabs.ibm.com>
On Wed, 2007-10-03 at 09:43 +1000, Paul Mackerras wrote:
> Valentine Barshak writes:
>
> > No need for memset to zero memory here, since we use kzalloc.
> >
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> > drivers/mtd/maps/physmap_of.c | 1 -
>
> Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
> Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
> get them upstream.
Except when I screw up and pull them into my tree. Which won't happen
again.
josh
^ permalink raw reply
* Re: [PATCH v3 2/4] Implement generic time of day clocksource for powerpc machines.
From: Paul Mackerras @ 2007-10-03 0:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Stephen Rothwell, Thomas Gleixner, Realtime Kernel, linuxppc-dev
In-Reply-To: <20070921213552.GD9814@bakeyournoodle.com>
Tony Breeds writes:
> @@ -982,6 +906,10 @@ void __init time_init(void)
>
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> + /* Register the clocksource, if we're not running on iSeries */
> + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> + clocksource_init();
This breaks the 32-bit compile.
Is it possible to adjust the frequency of a clocksource after it has
been registered? Or could the timebase clocksource be unregistered
and reregistered in iSeries_tb_recal?
Paul.
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 0:30 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003002646.GD9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
On Wed, 2007-10-03 at 10:26 +1000, Tony Breeds wrote:
> On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> > On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > > Seeing the following from an older power LPAR, pretty sure we had
> > > this in the previous -mm also:
> >
> > I haven't forgetten about this ... and am looking at it now.
> > Seems that whenever I go to reserve the machine pSeries-102,
> > someone else is using it :-)
>
> This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
> (79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
> branch. It looks to me that we have logging enabled too early now.
>
> I think the following is a reasonable fix?
>
> ---
> Explicitly enable RTAS error logging, when it should be ready.
>
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
>
> arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..0df5d0d 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> +static int no_more_logging = 1; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
> +
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 0:26 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071002232819.GN4338@austin.ibm.com>
On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > Seeing the following from an older power LPAR, pretty sure we had
> > this in the previous -mm also:
>
> I haven't forgetten about this ... and am looking at it now.
> Seems that whenever I go to reserve the machine pSeries-102,
> someone else is using it :-)
This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
(79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
branch. It looks to me that we have logging enabled too early now.
I think the following is a reasonable fix?
---
Explicitly enable RTAS error logging, when it should be ready.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..0df5d0d 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
+static int no_more_logging = 1; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
+
static int error_log_cnt;
@@ -414,6 +417,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ no_more_logging = 0;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Paul Mackerras @ 2007-10-02 23:43 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071002155328.GA3574@ru.mvista.com>
Valentine Barshak writes:
> No need for memset to zero memory here, since we use kzalloc.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> drivers/mtd/maps/physmap_of.c | 1 -
Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
get them upstream.
Paul.
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Linas Vepstas @ 2007-10-02 23:28 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20070924123531.GC30855@shadowen.org>
On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> Seeing the following from an older power LPAR, pretty sure we had
> this in the previous -mm also:
I haven't forgetten about this ... and am looking at it now.
Seems that whenever I go to reserve the machine pSeries-102,
someone else is using it :-)
--linas
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: Badari Pulavarty @ 2007-10-02 23:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
In-Reply-To: <18178.52359.953289.638736@cargo.ozlabs.ibm.com>
On Wed, 2007-10-03 at 08:56 +1000, Paul Mackerras wrote:
> Badari Pulavarty writes:
>
> > I am trying to get hotplug memory remove working on ppc64.
> > In order to verify a given memory region, if its valid or not -
> > current hotplug-memory patches used /proc/iomem. On IA64 and
> > x86-64 /proc/iomem shows all memory regions.
> >
> > I am wondering, if its acceptable to do the same on ppc64 also ?
>
> I am a bit hesitant to do that, since /proc/iomem is user visible and
> is therefore part of the user/kernel ABI. Also it feels a bit weird
> to have system RAM in something whose name suggests it's about MMIO.
Yes. That was my first reaction. Until last week, I never realized
that /proc/iomem contains entire memory layout on i386/x86-64 :(
Since i386, x86-64 and ia64 are all doing same thing, I thought breakage
would be minimal (if any) if we do the same on ppc64.
> > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > code to be able to do this.
>
> Isn't it just a matter of abstracting the test for a valid range of
> memory? If it's really hard to abstract that, then I guess we can put
> RAM in iomem_resource, but I'd rather not.
>
Sure. I will work on it and see how ugly it looks.
KAME, are you okay with abstracting the find_next_system_ram() and
let arch provide whatever implementation they want ? (since current
code doesn't work for x86-64 also ?).
Thanks,
Badari
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: Paul Mackerras @ 2007-10-02 22:56 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
In-Reply-To: <1191346196.6106.20.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty writes:
> I am trying to get hotplug memory remove working on ppc64.
> In order to verify a given memory region, if its valid or not -
> current hotplug-memory patches used /proc/iomem. On IA64 and
> x86-64 /proc/iomem shows all memory regions.
>
> I am wondering, if its acceptable to do the same on ppc64 also ?
I am a bit hesitant to do that, since /proc/iomem is user visible and
is therefore part of the user/kernel ABI. Also it feels a bit weird
to have system RAM in something whose name suggests it's about MMIO.
> Otherwise, we need to add arch-specific hooks in hotplug-remove
> code to be able to do this.
Isn't it just a matter of abstracting the test for a valid range of
memory? If it's really hard to abstract that, then I guess we can put
RAM in iomem_resource, but I'd rather not.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Benjamin Herrenschmidt @ 2007-10-02 22:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710020910u3a679ea2m15b005d0ba5fb054@mail.gmail.com>
> My opinion is that since it is driver-specific code anyway, then it
> belongs with the driver. Plus a driver writer for ARM doesn't need to
> write them. It's the powerpc or microblaze developer who will do it.
> If the driver maintainer doesn't want the binding in the main driver
> .c file, then the binding can easily be in an additional .c file
> without needing to add a constructor. (Kind of like how many USB host
> controllers are managed)
The main advantage is that it keeps the OF specific code localized to a
single function, whether that function lives in the driver or the arch
code, it makes it self contained and easier to deal with by the driver
author.
Having multiple device types on which the driver can attach is a pain
from a driver standpoint. It needs multiple
probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
maintainance burden in the long run.
The important thing however, with the constructor approach is to try as
much as possible to keep the proper tree structure, and thus, try to
find a way to instanciate the devices with proper parent/child
relationship so that ordering for things like suspend/resume operations
is maintained.
Ben.
^ permalink raw reply
* Re: Problem with OF interrupt parsing code
From: Benjamin Herrenschmidt @ 2007-10-02 22:03 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20071002123849.242670@gmx.net>
On Tue, 2007-10-02 at 14:38 +0200, Gerhard Pircher wrote:
> I know that it's ugly, but the problem is how to distinguish the
> boards.
> The only real difference I know of is the PCI interrupt mapping. The
> northbridges chip revision for example is always the same, but CPU
> type,
> amount of memory and PCI devices can appear in all possible
> combinations.
> The firmware doesn't tell me, which board the kernel is runnning on,
> so I
> would like to rely on this fall back here until I get the chance to
> update the firmware (which is beyond my control).
And how does the firmware know ? There must be a strap somewhere...
Ben.
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Benjamin Herrenschmidt @ 2007-10-02 22:02 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071002122005.GA6425@localhost.localdomain>
>
> Exactly, this is what that patch is trying to do. QEIC cascade handler is
> calling mpic's eoi() (end() actually, as it's flow level, but end == eoi.
> Is it main objection? Ok, I can get rid of it, and use chip level eoi()
> directly).
Yes, use eoi() directly, don't add end()
> Yup, exactly. Actually, QEIC's cascade handlers do not really know
> what needs to be done, but they're good at guessing (if (chip->eoi)).
>
> Sure, I can place board-specific QEIC handlers in the board file, but
> that will be quite big code duplication for all machines using QEIC.
Maybe you can provide a set of common ones, and then just pick the one
you want from the board file ?
Or have some board code call into a QEIC init routine specifying the
type of cascade handler to use ... or whatevre you like here.
Just don't add end() where it doesn't belong.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Linas Vepstas @ 2007-10-02 21:59 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20071002012730.GO12049@parisc-linux.org>
On Mon, Oct 01, 2007 at 07:27:30PM -0600, Matthew Wilcox wrote:
>
> Fine by me. Do you have the ability to produce failures on a whim on
> your platforms?
Yes, although it is very platform specific -- there are actually
transistors in the pci bridge chip, which actually short out lines,
and so, from the point of view of the rest of the chip, it did
actually see a "real" error. Its supposed to be a very realistic
test.
> I've been vaguely musing a PCI device failure patch for
> x86, just so people can test driver failure paths.
That would be good ... I've recently agreed to accept a fedex
to test someone elses card for them, which is outside my usual
activities.
There's also supposed to be some PCI-X riser card out there,
(never seen one) which has the ability to inject actual pci
errors. Its the Agilent PCI BestX card; I got the impression
they might not sell it anymore; dunno.
One guy in the lab used to brush a grounding strap across
the pins; this usually got a rise out of the audience.
--linas
^ permalink raw reply
* [PATCH] powerpc: another use of zalloc_maybe_bootmem()
From: Linas Vepstas @ 2007-10-02 21:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20071002133753.662397db.sfr@canb.auug.org.au>
Use alloc_maybe_bootmem() which wraps the if(mem_init_done)
malloc clause.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
On Tue, Oct 02, 2007 at 01:37:53PM +1000, Stephen Rothwell wrote:
> This patch introduces zalloc_maybe_bootmem and uses it so that we don;t
> have to mark a whole (largish) routine as __init_ref_ok.
sfr missed a spot -- may as well get rid of this one too.
arch/powerpc/kernel/pci-common.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/kernel/pci-common.c 2007-09-26 15:02:41.000000000 -0500
+++ linux-2.6.23-rc8-mm1/arch/powerpc/kernel/pci-common.c 2007-10-02 16:28:16.000000000 -0500
@@ -65,14 +65,11 @@ static void __devinit pci_setup_pci_cont
spin_unlock(&hose_spinlock);
}
-__init_refok struct pci_controller * pcibios_alloc_controller(struct device_node *dev)
+struct pci_controller * pcibios_alloc_controller(struct device_node *dev)
{
struct pci_controller *phb;
- if (mem_init_done)
- phb = kmalloc(sizeof(struct pci_controller), GFP_KERNEL);
- else
- phb = alloc_bootmem(sizeof (struct pci_controller));
+ phb = alloc_maybe_bootmem(sizeof(struct pci_controller), GFP_KERNEL);
if (phb == NULL)
return NULL;
pci_setup_pci_controller(phb);
^ permalink raw reply
* [PATCH] [POWERPC] update immap_86xx.h for the 8610
From: Timur Tabi @ 2007-10-02 21:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Timur Tabi
Update the definition of the global utilities structure (ccsr_guts) in
immap_86xx.h and add some related macros for the Freescale 8610 SOC.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch is for 2.6.24.
include/asm-powerpc/immap_86xx.h | 86 ++++++++++++++++++++++++++++++++++----
1 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/include/asm-powerpc/immap_86xx.h b/include/asm-powerpc/immap_86xx.h
index c83d7ad..0ad4e65 100644
--- a/include/asm-powerpc/immap_86xx.h
+++ b/include/asm-powerpc/immap_86xx.h
@@ -38,7 +38,8 @@ struct ccsr_guts {
__be32 pmuxcr; /* 0x.0060 - Alternate Function Signal Multiplex Control */
u8 res6[0x70 - 0x64];
__be32 devdisr; /* 0x.0070 - Device Disable Control */
- u8 res7[0x80 - 0x74];
+ __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
+ u8 res7[0x80 - 0x78];
__be32 powmgtcsr; /* 0x.0080 - Power Management Status and Control Register */
u8 res8[0x90 - 0x84];
__be32 mcpsumr; /* 0x.0090 - Machine Check Summary Register */
@@ -48,18 +49,87 @@ struct ccsr_guts {
__be32 svr; /* 0x.00a4 - System Version Register */
u8 res10[0xB0 - 0xA8];
__be32 rstcr; /* 0x.00b0 - Reset Control Register */
- u8 res11[0xB20 - 0xB4];
- __be32 ddr1clkdr; /* 0x.0b20 - DDRC1 Clock Disable Register */
- __be32 ddr2clkdr; /* 0x.0b24 - DDRC2 Clock Disable Register */
- u8 res12[0xE00 - 0xB28];
+ u8 res11[0xC0 - 0xB4];
+ __be32 elbcvselcr; /* 0x.00c0 - eLBC Voltage Select Ctrl Reg */
+ u8 res12[0x800 - 0xC4];
+ __be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
+ u8 res13[0x900 - 0x804];
+ __be32 ircr; /* 0x.0900 - Infrared Control Register */
+ u8 res14[0x908 - 0x904];
+ __be32 dmacr; /* 0x.0908 - DMA Control Register */
+ u8 res15[0x914 - 0x90C];
+ __be32 elbccr; /* 0x.0914 - eLBC Control Register */
+ u8 res16[0xB20 - 0x918];
+ __be32 ddr1clkdr; /* 0x.0b20 - DDR1 Clock Disable Register */
+ __be32 ddr2clkdr; /* 0x.0b24 - DDR2 Clock Disable Register */
+ __be32 ddrclkdr; /* 0x.0b28 - DDR Clock Disable Register */
+ u8 res17[0xE00 - 0xB2C];
__be32 clkocr; /* 0x.0e00 - Clock Out Select Register */
- u8 res13[0xF04 - 0xE04];
+ u8 res18[0xE10 - 0xE04];
+ __be32 ddrdllcr; /* 0x.0e10 - DDR DLL Control Register */
+ u8 res19[0xE20 - 0xE14];
+ __be32 lbcdllcr; /* 0x.0e20 - LBC DLL Control Register */
+ u8 res20[0xF04 - 0xE24];
__be32 srds1cr0; /* 0x.0f04 - SerDes1 Control Register 0 */
__be32 srds1cr1; /* 0x.0f08 - SerDes1 Control Register 0 */
- u8 res14[0xF40 - 0xF0C];
+ u8 res21[0xF40 - 0xF0C];
__be32 srds2cr0; /* 0x.0f40 - SerDes1 Control Register 0 */
__be32 srds2cr1; /* 0x.0f44 - SerDes1 Control Register 0 */
-};
+} __attribute__ ((packed));
+
+#define CCSR_GUTS_DMACR_DEV_SSI 0 /* DMA controller/channel set to SSI */
+#define CCSR_GUTS_DMACR_DEV_IR 1 /* DMA controller/channel set to IR */
+
+/*
+ * Set the DMACR register in the GUTS
+ *
+ * The DMACR register determines the source of initiated transfers for each
+ * channel on each DMA controller. Rather than have a bunch of repetitive
+ * macros for the bit patterns, we just have a function that calculates
+ * them.
+ *
+ * guts: Pointer to GUTS structure
+ * co: The DMA controller (1 or 2)
+ * ch: The channel on the DMA controller (0, 1, 2, or 3)
+ * device: The device to set as the source (CCSR_GUTS_DMACR_DEV_xx)
+ */
+static inline void guts_set_dmacr(struct ccsr_guts __iomem *guts,
+ unsigned int co, unsigned int ch, unsigned int device)
+{
+ unsigned int shift = 16 + (8 * (2 - co) + 2 * (3 - ch));
+
+ clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
+}
+
+#define CCSR_GUTS_PMUXCR_LDPSEL 0x00010000
+#define CCSR_GUTS_PMUXCR_SSI1_MASK 0x0000C000 /* Bitmask for SSI1 */
+#define CCSR_GUTS_PMUXCR_SSI1_LA 0x00000000 /* Latched address */
+#define CCSR_GUTS_PMUXCR_SSI1_HI 0x00004000 /* High impedance */
+#define CCSR_GUTS_PMUXCR_SSI1_SSI 0x00008000 /* Used for SSI1 */
+#define CCSR_GUTS_PMUXCR_SSI2_MASK 0x00003000 /* Bitmask for SSI2 */
+#define CCSR_GUTS_PMUXCR_SSI2_LA 0x00000000 /* Latched address */
+#define CCSR_GUTS_PMUXCR_SSI2_HI 0x00001000 /* High impedance */
+#define CCSR_GUTS_PMUXCR_SSI2_SSI 0x00002000 /* Used for SSI2 */
+#define CCSR_GUTS_PMUXCR_LA_22_25_LA 0x00000000 /* Latched Address */
+#define CCSR_GUTS_PMUXCR_LA_22_25_HI 0x00000400 /* High impedance */
+#define CCSR_GUTS_PMUXCR_DBGDRV 0x00000200 /* Signals not driven */
+#define CCSR_GUTS_PMUXCR_DMA2_0 0x00000008
+#define CCSR_GUTS_PMUXCR_DMA2_3 0x00000004
+#define CCSR_GUTS_PMUXCR_DMA1_0 0x00000002
+#define CCSR_GUTS_PMUXCR_DMA1_3 0x00000001
+
+#define CCSR_GUTS_CLKDVDR_PXCKEN 0x80000000
+#define CCSR_GUTS_CLKDVDR_SSICKEN 0x20000000
+#define CCSR_GUTS_CLKDVDR_PXCKINV 0x10000000
+#define CCSR_GUTS_CLKDVDR_PXCKDLY_SHIFT 25
+#define CCSR_GUTS_CLKDVDR_PXCKDLY_MASK 0x06000000
+#define CCSR_GUTS_CLKDVDR_PXCKDLY(x) \
+ (((x) & 3) << CCSR_GUTS_CLKDVDR_PXCKDLY_SHIFT)
+#define CCSR_GUTS_CLKDVDR_PXCLK_SHIFT 16
+#define CCSR_GUTS_CLKDVDR_PXCLK_MASK 0x001F0000
+#define CCSR_GUTS_CLKDVDR_PXCLK(x) (((x) & 31) << CCSR_GUTS_CLKDVDR_PXCLK_SHIFT)
+#define CCSR_GUTS_CLKDVDR_SSICLK_MASK 0x000000FF
+#define CCSR_GUTS_CLKDVDR_SSICLK(x) ((x) & CCSR_GUTS_CLKDVDR_SSICLK_MASK)
#endif /* __ASM_POWERPC_IMMAP_86XX_H__ */
#endif /* __KERNEL__ */
--
1.5.2.4
^ permalink raw reply related
* [PATCH] [11/11] pasemi_mac: enable iommu support
From: Olof Johansson @ 2007-10-02 21:28 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no longer supported, and needs a pile of other
workarounds that are not being submitted for mainline inclusion. So the
fact that this breaks old hardware is not a problem at this time.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -243,9 +243,9 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXINT_BASEU_SIZ(RX_RING_SIZE >> 3));
write_dma_reg(mac, PAS_DMA_RXINT_CFG(mac->dma_if),
- PAS_DMA_RXINT_CFG_DHL(3) |
- PAS_DMA_RXINT_CFG_L2 |
- PAS_DMA_RXINT_CFG_LW);
+ PAS_DMA_RXINT_CFG_DHL(3) | PAS_DMA_RXINT_CFG_L2 |
+ PAS_DMA_RXINT_CFG_LW | PAS_DMA_RXINT_CFG_RBP |
+ PAS_DMA_RXINT_CFG_HEN);
ring->next_to_fill = 0;
ring->next_to_clean = 0;
@@ -402,13 +402,12 @@ static void pasemi_mac_free_rx_resources
static void pasemi_mac_replenish_rx_ring(struct net_device *dev, int limit)
{
struct pasemi_mac *mac = netdev_priv(dev);
- int start = mac->rx->next_to_fill;
- unsigned int fill, count;
+ int fill, count;
if (limit <= 0)
return;
- fill = start;
+ fill = mac->rx->next_to_fill;
for (count = 0; count < limit; count++) {
struct pasemi_mac_buffer *info = &RX_RING_INFO(mac, fill);
u64 *buff = &RX_BUFF(mac, fill);
@@ -446,10 +445,10 @@ static void pasemi_mac_replenish_rx_ring
wmb();
- write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count);
write_dma_reg(mac, PAS_DMA_RXINT_INCR(mac->dma_if), count);
- mac->rx->next_to_fill += count;
+ mac->rx->next_to_fill = (mac->rx->next_to_fill + count) &
+ (RX_RING_SIZE - 1);
}
static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac)
@@ -517,15 +516,19 @@ static int pasemi_mac_clean_rx(struct pa
int count;
struct pasemi_mac_buffer *info;
struct sk_buff *skb;
- unsigned int i, len;
+ unsigned int len;
u64 macrx;
dma_addr_t dma;
+ int buf_index;
+ u64 eval;
spin_lock(&mac->rx->lock);
n = mac->rx->next_to_clean;
- for (count = limit; count; count--) {
+ prefetch(RX_RING(mac, n));
+
+ for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
if ((macrx & XCT_MACRX_E) ||
@@ -537,21 +540,14 @@ static int pasemi_mac_clean_rx(struct pa
info = NULL;
- /* We have to scan for our skb since there's no way
- * to back-map them from the descriptor, and if we
- * have several receive channels then they might not
- * show up in the same order as they were put on the
- * interface ring.
- */
+ BUG_ON(!(macrx & XCT_MACRX_RR_8BRES));
- dma = (RX_RING(mac, n+1) & XCT_PTR_ADDR_M);
- for (i = mac->rx->next_to_fill;
- i < (mac->rx->next_to_fill + RX_RING_SIZE);
- i++) {
- info = &RX_RING_INFO(mac, i);
- if (info->dma == dma)
- break;
- }
+ eval = (RX_RING(mac, n+1) & XCT_RXRES_8B_EVAL_M) >>
+ XCT_RXRES_8B_EVAL_S;
+ buf_index = eval-1;
+
+ dma = (RX_RING(mac, n+2) & XCT_PTR_ADDR_M);
+ info = &RX_RING_INFO(mac, buf_index);
skb = info->skb;
@@ -600,9 +596,9 @@ static int pasemi_mac_clean_rx(struct pa
/* Need to zero it out since hardware doesn't, since the
* replenish loop uses it to tell when it's done.
*/
- RX_BUFF(mac, i) = 0;
+ RX_BUFF(mac, buf_index) = 0;
- n += 2;
+ n += 4;
}
if (n > RX_RING_SIZE) {
@@ -610,8 +606,16 @@ static int pasemi_mac_clean_rx(struct pa
write_iob_reg(mac, PAS_IOB_COM_PKTHDRCNT, 0);
n &= (RX_RING_SIZE-1);
}
+
mac->rx->next_to_clean = n;
- pasemi_mac_replenish_rx_ring(mac->netdev, limit-count);
+
+ /* Increase is in number of 16-byte entries, and since each descriptor
+ * with an 8BRES takes up 3x8 bytes (padded to 4x8), increase with
+ * count*2.
+ */
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count << 1);
+
+ pasemi_mac_replenish_rx_ring(mac->netdev, count);
spin_unlock(&mac->rx->lock);
@@ -927,6 +931,8 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_replenish_rx_ring(dev, RX_RING_SIZE);
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), RX_RING_SIZE>>1);
+
flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
Index: k.org/drivers/net/pasemi_mac.h
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -206,12 +206,15 @@ enum {
#define PAS_DMA_RXINT_RCMDSTA_DROPS_M 0xfffe0000
#define PAS_DMA_RXINT_RCMDSTA_DROPS_S 17
#define PAS_DMA_RXINT_CFG(i) (0x204+(i)*_PAS_DMA_RXINT_STRIDE)
+#define PAS_DMA_RXINT_CFG_RBP 0x80000000
+#define PAS_DMA_RXINT_CFG_ITRR 0x40000000
#define PAS_DMA_RXINT_CFG_DHL_M 0x07000000
#define PAS_DMA_RXINT_CFG_DHL_S 24
#define PAS_DMA_RXINT_CFG_DHL(x) (((x) << PAS_DMA_RXINT_CFG_DHL_S) & \
PAS_DMA_RXINT_CFG_DHL_M)
#define PAS_DMA_RXINT_CFG_LW 0x00200000
#define PAS_DMA_RXINT_CFG_L2 0x00100000
+#define PAS_DMA_RXINT_CFG_HEN 0x00080000
#define PAS_DMA_RXINT_CFG_WIF 0x00000002
#define PAS_DMA_RXINT_CFG_WIL 0x00000001
@@ -425,10 +428,9 @@ enum {
/* Receive descriptor fields */
#define XCT_MACRX_T 0x8000000000000000ull
#define XCT_MACRX_ST 0x4000000000000000ull
-#define XCT_MACRX_NORES 0x0000000000000000ull
-#define XCT_MACRX_8BRES 0x1000000000000000ull
-#define XCT_MACRX_24BRES 0x2000000000000000ull
-#define XCT_MACRX_40BRES 0x3000000000000000ull
+#define XCT_MACRX_RR_M 0x3000000000000000ull
+#define XCT_MACRX_RR_NORES 0x0000000000000000ull
+#define XCT_MACRX_RR_8BRES 0x1000000000000000ull
#define XCT_MACRX_O 0x0400000000000000ull
#define XCT_MACRX_E 0x0200000000000000ull
#define XCT_MACRX_FF 0x0100000000000000ull
@@ -476,6 +478,17 @@ enum {
#define XCT_PTR_ADDR(x) ((((long)(x)) << XCT_PTR_ADDR_S) & \
XCT_PTR_ADDR_M)
+/* Receive interface 8byte result fields */
+#define XCT_RXRES_8B_L4O_M 0xff00000000000000ull
+#define XCT_RXRES_8B_L4O_S 56
+#define XCT_RXRES_8B_RULE_M 0x00ffff0000000000ull
+#define XCT_RXRES_8B_RULE_S 40
+#define XCT_RXRES_8B_EVAL_M 0x000000ffff000000ull
+#define XCT_RXRES_8B_EVAL_S 24
+#define XCT_RXRES_8B_HTYPE_M 0x0000000000f00000ull
+#define XCT_RXRES_8B_HASH_M 0x00000000000fffffull
+#define XCT_RXRES_8B_HASH_S 0
+
/* Receive interface buffer fields */
#define XCT_RXB_LEN_M 0x0ffff00000000000ull
#define XCT_RXB_LEN_S 44
^ permalink raw reply
* [PATCH] [10/11] pasemi_mac: use buffer index pointer in clean_rx()
From: Olof Johansson @ 2007-10-02 21:27 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071002212421.GA2282@lixom.net>
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no longer supported, and needs a pile of other
workarounds that are not being submitted for mainline inclusion. So the
fact that this breaks old hardware is not a problem at this time.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: k.org/drivers/net/pasemi_mac.c
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_mac.c
@@ -243,9 +243,9 @@ static int pasemi_mac_setup_rx_resources
PAS_DMA_RXINT_BASEU_SIZ(RX_RING_SIZE >> 3));
write_dma_reg(mac, PAS_DMA_RXINT_CFG(mac->dma_if),
- PAS_DMA_RXINT_CFG_DHL(3) |
- PAS_DMA_RXINT_CFG_L2 |
- PAS_DMA_RXINT_CFG_LW);
+ PAS_DMA_RXINT_CFG_DHL(3) | PAS_DMA_RXINT_CFG_L2 |
+ PAS_DMA_RXINT_CFG_LW | PAS_DMA_RXINT_CFG_RBP |
+ PAS_DMA_RXINT_CFG_HEN);
ring->next_to_fill = 0;
ring->next_to_clean = 0;
@@ -402,13 +402,12 @@ static void pasemi_mac_free_rx_resources
static void pasemi_mac_replenish_rx_ring(struct net_device *dev, int limit)
{
struct pasemi_mac *mac = netdev_priv(dev);
- int start = mac->rx->next_to_fill;
- unsigned int fill, count;
+ int fill, count;
if (limit <= 0)
return;
- fill = start;
+ fill = mac->rx->next_to_fill;
for (count = 0; count < limit; count++) {
struct pasemi_mac_buffer *info = &RX_RING_INFO(mac, fill);
u64 *buff = &RX_BUFF(mac, fill);
@@ -446,10 +445,10 @@ static void pasemi_mac_replenish_rx_ring
wmb();
- write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count);
write_dma_reg(mac, PAS_DMA_RXINT_INCR(mac->dma_if), count);
- mac->rx->next_to_fill += count;
+ mac->rx->next_to_fill = (mac->rx->next_to_fill + count) &
+ (RX_RING_SIZE - 1);
}
static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac)
@@ -517,15 +516,19 @@ static int pasemi_mac_clean_rx(struct pa
int count;
struct pasemi_mac_buffer *info;
struct sk_buff *skb;
- unsigned int i, len;
+ unsigned int len;
u64 macrx;
dma_addr_t dma;
+ int buf_index;
+ u64 eval;
spin_lock(&mac->rx->lock);
n = mac->rx->next_to_clean;
- for (count = limit; count; count--) {
+ prefetch(RX_RING(mac, n));
+
+ for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
if ((macrx & XCT_MACRX_E) ||
@@ -537,21 +540,14 @@ static int pasemi_mac_clean_rx(struct pa
info = NULL;
- /* We have to scan for our skb since there's no way
- * to back-map them from the descriptor, and if we
- * have several receive channels then they might not
- * show up in the same order as they were put on the
- * interface ring.
- */
+ BUG_ON(!(macrx & XCT_MACRX_RR_8BRES));
- dma = (RX_RING(mac, n+1) & XCT_PTR_ADDR_M);
- for (i = mac->rx->next_to_fill;
- i < (mac->rx->next_to_fill + RX_RING_SIZE);
- i++) {
- info = &RX_RING_INFO(mac, i);
- if (info->dma == dma)
- break;
- }
+ eval = (RX_RING(mac, n+1) & XCT_RXRES_8B_EVAL_M) >>
+ XCT_RXRES_8B_EVAL_S;
+ buf_index = eval-1;
+
+ dma = (RX_RING(mac, n+2) & XCT_PTR_ADDR_M);
+ info = &RX_RING_INFO(mac, buf_index);
skb = info->skb;
@@ -600,9 +596,9 @@ static int pasemi_mac_clean_rx(struct pa
/* Need to zero it out since hardware doesn't, since the
* replenish loop uses it to tell when it's done.
*/
- RX_BUFF(mac, i) = 0;
+ RX_BUFF(mac, buf_index) = 0;
- n += 2;
+ n += 4;
}
if (n > RX_RING_SIZE) {
@@ -610,8 +606,16 @@ static int pasemi_mac_clean_rx(struct pa
write_iob_reg(mac, PAS_IOB_COM_PKTHDRCNT, 0);
n &= (RX_RING_SIZE-1);
}
+
mac->rx->next_to_clean = n;
- pasemi_mac_replenish_rx_ring(mac->netdev, limit-count);
+
+ /* Increase is in number of 16-byte entries, and since each descriptor
+ * with an 8BRES takes up 3x8 bytes (padded to 4x8), increase with
+ * count*2.
+ */
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), count << 1);
+
+ pasemi_mac_replenish_rx_ring(mac->netdev, count);
spin_unlock(&mac->rx->lock);
@@ -927,6 +931,8 @@ static int pasemi_mac_open(struct net_de
pasemi_mac_replenish_rx_ring(dev, RX_RING_SIZE);
+ write_dma_reg(mac, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), RX_RING_SIZE>>1);
+
flags = PAS_MAC_CFG_PCFG_S1 | PAS_MAC_CFG_PCFG_PE |
PAS_MAC_CFG_PCFG_PR | PAS_MAC_CFG_PCFG_CE;
Index: k.org/drivers/net/pasemi_mac.h
===================================================================
--- k.org.orig/drivers/net/pasemi_mac.h
+++ k.org/drivers/net/pasemi_mac.h
@@ -206,12 +206,15 @@ enum {
#define PAS_DMA_RXINT_RCMDSTA_DROPS_M 0xfffe0000
#define PAS_DMA_RXINT_RCMDSTA_DROPS_S 17
#define PAS_DMA_RXINT_CFG(i) (0x204+(i)*_PAS_DMA_RXINT_STRIDE)
+#define PAS_DMA_RXINT_CFG_RBP 0x80000000
+#define PAS_DMA_RXINT_CFG_ITRR 0x40000000
#define PAS_DMA_RXINT_CFG_DHL_M 0x07000000
#define PAS_DMA_RXINT_CFG_DHL_S 24
#define PAS_DMA_RXINT_CFG_DHL(x) (((x) << PAS_DMA_RXINT_CFG_DHL_S) & \
PAS_DMA_RXINT_CFG_DHL_M)
#define PAS_DMA_RXINT_CFG_LW 0x00200000
#define PAS_DMA_RXINT_CFG_L2 0x00100000
+#define PAS_DMA_RXINT_CFG_HEN 0x00080000
#define PAS_DMA_RXINT_CFG_WIF 0x00000002
#define PAS_DMA_RXINT_CFG_WIL 0x00000001
@@ -425,10 +428,9 @@ enum {
/* Receive descriptor fields */
#define XCT_MACRX_T 0x8000000000000000ull
#define XCT_MACRX_ST 0x4000000000000000ull
-#define XCT_MACRX_NORES 0x0000000000000000ull
-#define XCT_MACRX_8BRES 0x1000000000000000ull
-#define XCT_MACRX_24BRES 0x2000000000000000ull
-#define XCT_MACRX_40BRES 0x3000000000000000ull
+#define XCT_MACRX_RR_M 0x3000000000000000ull
+#define XCT_MACRX_RR_NORES 0x0000000000000000ull
+#define XCT_MACRX_RR_8BRES 0x1000000000000000ull
#define XCT_MACRX_O 0x0400000000000000ull
#define XCT_MACRX_E 0x0200000000000000ull
#define XCT_MACRX_FF 0x0100000000000000ull
@@ -476,6 +478,17 @@ enum {
#define XCT_PTR_ADDR(x) ((((long)(x)) << XCT_PTR_ADDR_S) & \
XCT_PTR_ADDR_M)
+/* Receive interface 8byte result fields */
+#define XCT_RXRES_8B_L4O_M 0xff00000000000000ull
+#define XCT_RXRES_8B_L4O_S 56
+#define XCT_RXRES_8B_RULE_M 0x00ffff0000000000ull
+#define XCT_RXRES_8B_RULE_S 40
+#define XCT_RXRES_8B_EVAL_M 0x000000ffff000000ull
+#define XCT_RXRES_8B_EVAL_S 24
+#define XCT_RXRES_8B_HTYPE_M 0x0000000000f00000ull
+#define XCT_RXRES_8B_HASH_M 0x00000000000fffffull
+#define XCT_RXRES_8B_HASH_S 0
+
/* Receive interface buffer fields */
#define XCT_RXB_LEN_M 0x0ffff00000000000ull
#define XCT_RXB_LEN_S 44
^ 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