* Re: Support for S29JL064 in MPC8272ADS?
From: Scott Wood @ 2009-10-09 17:04 UTC (permalink / raw)
To: Roberto Guerra; +Cc: linuxppc-dev
In-Reply-To: <7c4144600910090714g524bad07ubf6cad3aaf8085ff@mail.gmail.com>
On Fri, Oct 09, 2009 at 10:14:56AM -0400, Roberto Guerra wrote:
> Hello,
> My uboot can read my flash chip, finding the uImage and the initramfs,
> and booting the kernel fine. However, I'd like the Linux kernel to
> read my flash chip so that it can update files in it.
Have you described your flash chip in the device tree?
> However, the kernel does not detect any flash chip (nor there's any
> indication that a CFI probe is being performed).
The stock device tree for mpc8272ads only specifies it as a JEDEC
flash, not CFI.
-Scott
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Wolfram Sang @ 2009-10-09 16:20 UTC (permalink / raw)
To: Nate Case; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <1255096871.16018.49.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
> I can submit that soon, but it probably makes sense for Wolfram to
> voice whatever his concerns were about "questionable" properties before
> I document what's there.
Please don't feel offended. The things I noticed are:
a) no documentation
b) 'polarity' is a direct mapping to the register which IMO is a hint to look
closer. I haven't checked in detil, but maybe the active_low-flag could be used
for this?
I mainly got alarmed that properties were mainlined without being reviewed; as
the device-tree is based on convention (which is hard to change afterwards), I
try to make sure this will not so easily happen again (thus the
get_maintainer-patch on lkml).
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Grant Likely @ 2009-10-09 16:13 UTC (permalink / raw)
To: Nate Case; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <1255095793.16018.32.camel@localhost.localdomain>
On Fri, Oct 9, 2009 at 7:43 AM, Nate Case <ncase@xes-inc.com> wrote:
> On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote:
>> And while doing this and figuring the pro/cons of those methods, I
>> stumbled over this commit:
>>
>> =A0 =A0 =A0 =A0 gpio: pca953x: Get platform_data from OpenFirmware
>> =A0 =A0 =A0 =A0 (1965d30356c1c65660ba3330927671cfe81acdd5)
>
> Aside from any issues you have with the properties themselves, what's
> your take on this approach?
As I mentioned in an earlier email, I don't think quite the right form
has been found yet, but I like the direction things are moving.
> Personally, I just got tired of waiting for someone else to solve the
> pdata/OF problem. =A0So I submitted that commit as an attempt at somethin=
g
> very simple and unobtrusive to the device driver itself. =A0It seems
> pretty clean to me, but I'm curious to see if others have any better
> ideas.
Yup, that's good. Between Anton's, Wolfram's and your work things are
going the right way.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Wolfram Sang @ 2009-10-09 16:12 UTC (permalink / raw)
To: Nate Case; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <1255095793.16018.32.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
> Aside from any issues you have with the properties themselves, what's
> your take on this approach?
Well, my approach for AT24 looked very similar to your approach. In fact, even
the motivation was the same as yours :) Well, the outcome of this is the
current thread and no definite solution yet. The archdata surely helps for this
issue, it just seems that a bit more generalization is needed.
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Grant Likely @ 2009-10-09 16:09 UTC (permalink / raw)
To: Nate Case; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <1255096871.16018.49.camel@localhost.localdomain>
On Fri, Oct 9, 2009 at 8:01 AM, Nate Case <ncase@xes-inc.com> wrote:
> On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
>> For your future reference, patches that look at the device tree should
>> also cc: devicetree-discuss@lists.ozlabs.org so that new bindings can
>> be reviewed and common mistakes can be avoided. =A0It is expected that
>> new device tree bindings are accompanied with documentation describing
>> what the binding is for and how it should be used (see
>> Documentation/powerpc/dts-bindings).
>>
>> I know this change is already in mainline, but can you please post the
>> device tree fragment that you're using to describe this chip? =A0I want
>> to make sure we don't get stuck with things in the kernel that will be
>> hard to maintain in the long term.
>
> Hi Grant,
>
> Sorry for neglecting to include devicetree-discuss on that one. =A0I was
> in fact aware of this list, and subscribe to it. =A0I really just forgot
> in this case.
No worries, it happens.
> I also have a documentation patch for it that went along with it, but it
> wasn't ready in time and so it's been sitting in our local patch queue.
> I can submit that soon, =A0but it probably makes sense for Wolfram to
> voice whatever his concerns were about "questionable" properties before
> I document what's there.
Yes, please post it as soon as you can.
> Here's an example device tree node for this case:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 gpio1: gpio@18 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "nxp,pca955=
7";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x18>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0#gpio-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gpio-controller;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0polarity =3D <0x00>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>
> In this case, the linux,gpio-base property wasn't specified. =A0But, the
> use case is identical to the pdata->gpio_base field. =A0"polarity" is use=
d
> for specifying polarity inversion for each line, and is in the same
> format of the 'polarity inversion' register on the chip. =A0My reasoning
> in the property naming was as follows:
>
> =A0 =A0linux,gpio-base: Linux-specific as it relates to internal GPIO
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 numbering. =A0So, it's prefixed w=
ith "linux,"
This would be the 'questionable' property. :-) The device tree is
supposed to be OS agnostic, so I get the heebee geebees when I see new
'linux,<blah>' properties defined because it means Linux internal
implementation details are getting leaked out into the data blob. The
problem leakage is that the device tree should not be impacted by
internal Linux code changes.
In this particular case, specifying the exact GPIO base number doesn't
really belong in the device tree because Linux is able to assign and
manage GPIO numbers on its own just like all other OF GPIO controller
drivers currently do. In fact, that goes for pretty much all
enumeration, not just GPIO. In general, a particular device instance
(uart, gpio, phy, whatever) should be resolved from its node in the
device tree, and not by some arbitrary number assigned by the .dts
author. The problem with arbitrary numbers is they don't expose the
linkage between nodes in the same way a 'phandle' does (A phandle can
be searched for. An arbitrary number assignment, good luck?), and
they don't expose intended usage (its just a meaningless number, and
it only works because userspace just happens to 'agree' to use the
same number).
> =A0 =A0polarity: Dictated by how hardware is wired up, so it's needed
> =A0 =A0 =A0 =A0 =A0 =A0 =A0regardless of the OS.
Typically GPIO drivers have been handling this by using #gpio-cells
set to 2, and using the 2nd cell for flags. The priority can be
encoded as a flag.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: ppc_md.SMI replacement for 2.6
From: Donald Kayser @ 2009-10-09 15:49 UTC (permalink / raw)
To: linuxppc-dev, linuxkernel
In-Reply-To: <200910091550.25032.arnd@arndb.de>
I have more information on this PPC HPPB target. I compared the
EXCEPTION macro between 2.4 and 2.6 with respect to SMI Exceptions. I
noticed that in the 2.4 kernel a macro named STD_EXCEPTION was used
and in the 2.6 kernel their is a new EXCEPTION macro structure. In the
2.6 kernel, it is much different, but with the TAUException I noticed
that it used an EXC_XFER_STD instead of EXC_XFER_EE, so I tried it and
with great news, I am actually getting the exceptions correctly now.
My question to anyone who understands is: is it OK to change the line
in arch/powerpc/kernel/head_32.S from
EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_EE)
to
EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_STD)
I have not decoded assembler to determine the exact differences, and I
will do so, but I wanted to know if there was anyone who knew why this
would make my SMI interrupt behave correctly.
Also, as noted earlier in this post, there is no hook for notification
of the SMI. The vendor who did the 2.4 port provided his own hook
through ppc_md global variable. Would anyone care to suggest the 'best/
preferred' method to provide a callback to the SMI Exception.
Thanks
Donald
linux@kayser.net
On Oct 9, 2009, at 8:50 AM, Arnd Bergmann wrote:
> On Friday 09 October 2009, Donald Kayser wrote:
>> On further comparison, this section of code has been added by the
>> vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
>> anyone would like to lend a thought towards System Managment
>> Exceptions on PPC, please cc me at linux@kayser.net. I will be
>> stopping the subscription to this list shortly. Regards, Donald
>
> Hi Donald,
>
> You should ask ppc specific questions on the linuxppc-dev@ozlabs.org
> mailing list instead of the global linux-kernel list to increase the
> chances of someone reading it who knows the answer.
>
> The world of powerpc linux has changed a lot since 2.4, as you
> undoubtedly found out. You are certainly encouraged to submit
> your platform code for inclusion in the mainline kernel (if you
> can do the usual cleanups necessary to do that), even for
> old code.
>
> I don't know a specific reason why the SMI callback was removed,
> but I would guess that if you have a platform that requires it
> and want it in the mainline kernel, a callback for it can be
> added back, either through ppc_md or some other method.
>
> Arnd <><
>
>> On Oct 8, 2009, at 8:37 AM, Donald Kayser wrote:
>>
>>> I have found the differences between the 2.4 and 2.6 kernel. It is
>>> in linux-2.4/arch/ppc/kernel/traps.c and linux-2.6/arch/powerpc/
>>> kernel/traps.c in the function SMIException(). There is no longer
>>> the code segment
>>>
>>> if (ppc_md.SMI)
>>> {
>>> ppc_md.SMI(regs);
>>> return;
>>> }
>>>
>>> There is now only a
>>>
>>> die("System Management Interrupt", regs, SIGABRT);
>>>
>>> I am guessing that the SMI callback is no longer needed by the linux
>>> community at large, so I modified the code for my specific hardware
>>> (HPPB) and acknowledged the exception as in the 2.4 kernel, and
>>> returned from the exception without the call to die(). My problem
>>> now is that it doesn't seem to work. Does anyone have a reason why
>>> the SMI exception might hang the system when it has been provided a
>>> handler?
>>>
>>> Thanks in advance.
>>>
>>> Donald Kayser
>>>
>>> On Oct 7, 2009, at 10:06 AM, Donald Kayser wrote:
>>>
>>>> I have ported the 2.6 kernel to an embedded PPC target (old stuff).
>>>> I have managed to figure everything out, but can't find any
>>>> replacement for a SMI handler. The original 2.4 version for this
>>>> target has a bit of code ppc_md.SMI == SmiFuncHandler; I have not
>>>> been able to find in the current source anything like this. I am
>>>> not certain that I need to provide a handler at all, but the
>>>> original developers saw some reason for including it. The
>>>> particular handler does not do anything more than cancel a watchdog
>>>> listener for this specific target. I have been living without the
>>>> handler, but would like to find any kind of replacement if it is
>>>> supported.
>>>>
>>>> Thanks,
>>>> Donald Kayser
>>>> linux@kayser.net
>
>
^ permalink raw reply
* Re: [PATCH 10/16] percpu: make percpu symbols in powerpc unique
From: Arnd Bergmann @ 2009-10-09 15:44 UTC (permalink / raw)
To: Tejun Heo
Cc: Christoph Lameter, Frederic Weisbecker, Heiko Carstens,
linuxppc-dev, Paul Mackerras, H. Peter Anvin, Masami Hiramatsu,
Nick Piggin, Herbert Xu, Robert Richter, x86,
Anil S Keshavamurthy, Ingo Molnar, Avi Kivity, Fenghua Yu,
Rusty Russell, Steven Rostedt, Chris Wright, Al Viro,
Thomas Gleixner, Tony Luck, Jeremy Fitzhardinge, Marcelo Tosatti,
linux-kernel, Chuck Ebbert, Martin Schwidefsky, Andrew Morton,
Koichi Yasutake, David S. Miller
In-Reply-To: <1254913285-6251-11-git-send-email-tj@kernel.org>
On Wednesday 07 October 2009, Tejun Heo wrote:
> This patch updates percpu related symbols in powerpc such that percpu
> symbols are unique and don't clash with local symbols. This serves
> two purposes of decreasing the possibility of global percpu symbol
> collision and allowing dropping per_cpu__ prefix from percpu symbols.
>
> * arch/powerpc/kernel/perf_callchain.c: s/callchain/cpu_perf_callchain/
>
> * arch/powerpc/kernel/setup-common.c: s/pvr/cpu_pvr/
>
> * arch/powerpc/platforms/pseries/dtl.c: s/dtl/cpu_dtl/
>
> * arch/powerpc/platforms/cell/interrupt.c: s/iic/cpu_iic/
>
> Partly based on Rusty Russell's "alloc_percpu: rename percpu vars
> which cause name clashes" patch.
Patch looks good, I checked both the cell bits I'm maintaining
and the other powerpc parts.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [RFC] scripts/get_maintainer: add emails based on keywords in the patch
From: Grant Likely @ 2009-10-09 15:46 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Joe Perches, linuxppc-dev, devicetree-discuss, linux-kernel
In-Reply-To: <1255084379-12954-1-git-send-email-w.sang@pengutronix.de>
On Fri, Oct 9, 2009 at 4:32 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> Make get_maintainer.pl scan the modifying lines of a patch for a list of
> keywords and add an associated email if found. The first user is the
> devicetree-discuss mailing list which should always be cc'ed if a device =
tree
> property is inserted/removed (keyword 'of_get_property'). This patch is t=
he
> result from commit 1965d30356c1c65660ba3330927671cfe81acdd5 entering main=
line
> which seems to have been missed by all parties interested in the device t=
ree
> (and at least had the documentation missing). As adding properties can ha=
ppen
> anywhere and so there is no fitting fileglob, this keyword based approach=
is
> proposed.
Nice. I cannot comment on the implementation, but I like the approach.
g.
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Joe Perches <joe@perches.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> =A0scripts/get_maintainer.pl | =A0 24 ++++++++++++++++--------
> =A01 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index cdb44b6..e1150ea 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -44,6 +44,11 @@ my $help =3D 0;
>
> =A0my $exit =3D 0;
>
> +my %keywords_to_mail =3D (
> + =A0 =A0 =A0 'of_get_property' =3D> 'L: devicetree-discuss@lists.ozlabs.=
org',
> +);
> +my $keywords_to_mail_match =3D join('|', keys %keywords_to_mail);
> +
> =A0my @penguin_chief =3D ();
> =A0push(@penguin_chief,"Linus Torvalds:torvalds\@linux-foundation.org");
> =A0#Andrew wants in on most everything - 2009/01/14
> @@ -188,6 +193,12 @@ if ($email_remove_duplicates) {
>
> =A0my @files =3D ();
> =A0my @range =3D ();
> +my @email_to =3D ();
> +my @list_to =3D ();
> +my @scm =3D ();
> +my @web =3D ();
> +my @subsystem =3D ();
> +my @status =3D ();
>
> =A0foreach my $file (@ARGV) {
> =A0 =A0 ##if $file is a directory and it lacks a trailing slash, add one
> @@ -213,7 +224,11 @@ foreach my $file (@ARGV) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ($email_git_blame) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0push(@range, "$lastfile:$1:$2");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 =A0 =A0 }
> + =A0 =A0 =A0 =A0 =A0 # Check the lines which a patch modifies for keywor=
ds; add mail if found.
> + =A0 =A0 =A0 =A0 =A0 } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 (my $keyword_mail =3D $keywords_to_mail{$1}=
) =3D~ s/^([LM]): //;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 push( @{ ($1 eq 'L') ? \@list_to : \@email_=
to }, $keyword_mail );
> + =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0close(PATCH);
> =A0 =A0 =A0 =A0if ($file_cnt =3D=3D @files) {
> @@ -224,13 +239,6 @@ foreach my $file (@ARGV) {
> =A0 =A0 }
> =A0}
>
> -my @email_to =3D ();
> -my @list_to =3D ();
> -my @scm =3D ();
> -my @web =3D ();
> -my @subsystem =3D ();
> -my @status =3D ();
> -
> =A0# Find responsible parties
>
> =A0foreach my $file (@files) {
> --
> 1.6.3.3
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
From: Robert Jennings @ 2009-10-09 14:43 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, linux-kernel, linuxppc-dev, Martin Schwidefsky,
Badari Pulavarty, Brian King, Paul Mackerras, Ingo Molnar
In-Reply-To: <20091009112136.GB24845@csn.ul.ie>
* Mel Gorman (mel@csn.ul.ie) wrote:
> On Fri, Oct 02, 2009 at 01:44:58PM -0500, Robert Jennings wrote:
> > Memory balloon drivers can allocate a large amount of memory which
> > is not movable but could be freed to accomodate memory hotplug remove.
> >
> > Prior to calling the memory hotplug notifier chain the memory in the
> > pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
> > isolation will not proceed, causing the memory removal for that page
> > range to fail.
> >
> > Rather than failing pageblock isolation if the the migrateteype is not
>
> s/the the migrateteype/the migratetype/
>
> > MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
> > are owned by a registered balloon driver (or other entity) using a
> > notifier chain. If all of the non-movable pages are owned by a balloon,
> > they can be freed later through the memory notifier chain and the range
> > can still be isolated in set_migratetype_isolate().
> >
> > Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> >
> > ---
> > drivers/base/memory.c | 19 +++++++++++++++++++
> > include/linux/memory.h | 26 ++++++++++++++++++++++++++
> > mm/page_alloc.c | 45 ++++++++++++++++++++++++++++++++++++++-------
> > 3 files changed, 83 insertions(+), 7 deletions(-)
> >
> > Index: b/drivers/base/memory.c
> > ===================================================================
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
> > }
> > EXPORT_SYMBOL(unregister_memory_notifier);
> >
> > +static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
> > +
> > +int register_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + return blocking_notifier_chain_register(&memory_isolate_chain, nb);
> > +}
> > +EXPORT_SYMBOL(register_memory_isolate_notifier);
> > +
> > +void unregister_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + blocking_notifier_chain_unregister(&memory_isolate_chain, nb);
> > +}
> > +EXPORT_SYMBOL(unregister_memory_isolate_notifier);
> > +
> > /*
> > * register_memory - Setup a sysfs device for a memory block
> > */
> > @@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
> > return blocking_notifier_call_chain(&memory_chain, val, v);
> > }
> >
> > +int memory_isolate_notify(unsigned long val, void *v)
> > +{
> > + return blocking_notifier_call_chain(&memory_isolate_chain, val, v);
> > +}
> > +
> > /*
> > * MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
> > * OK to have direct references to sparsemem variables in here.
> > Index: b/include/linux/memory.h
> > ===================================================================
> > --- a/include/linux/memory.h
> > +++ b/include/linux/memory.h
> > @@ -50,6 +50,18 @@ struct memory_notify {
> > int status_change_nid;
> > };
> >
> > +/*
> > + * During pageblock isolation, count the number of pages in the
> > + * range [start_pfn, start_pfn + nr_pages)
> > + */
> >
>
> The comment could have been slightly better. The count of pages in the
> range is nr_pages - memory_holes but what you're counting is the number
> of pages owned by the balloon driver in the notification chain.
Right, it is misleading. I'll fix this.
> > +#define MEM_ISOLATE_COUNT (1<<0)
> > +
> > +struct memory_isolate_notify {
> > + unsigned long start_pfn;
> > + unsigned int nr_pages;
> > + unsigned int pages_found;
> > +};
> > +
> > struct notifier_block;
> > struct mem_section;
> >
> > @@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
> > {
> > return 0;
> > }
> > +static inline int register_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + return 0;
> > +}
> > +static inline void unregister_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > +}
> > +static inline int memory_isolate_notify(unsigned long val, void *v)
> > +{
> > + return 0;
> > +}
> > #else
> > extern int register_memory_notifier(struct notifier_block *nb);
> > extern void unregister_memory_notifier(struct notifier_block *nb);
> > +extern int register_memory_isolate_notifier(struct notifier_block *nb);
> > +extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
> > extern int register_new_memory(int, struct mem_section *);
> > extern int unregister_memory_section(struct mem_section *);
> > extern int memory_dev_init(void);
> > extern int remove_memory_block(unsigned long, struct mem_section *, int);
> > extern int memory_notify(unsigned long val, void *v);
> > +extern int memory_isolate_notify(unsigned long val, void *v);
> > extern struct memory_block *find_memory_block(struct mem_section *);
> > #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
> > enum mem_add_context { BOOT, HOTPLUG };
> > Index: b/mm/page_alloc.c
> > ===================================================================
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -48,6 +48,7 @@
> > #include <linux/page_cgroup.h>
> > #include <linux/debugobjects.h>
> > #include <linux/kmemleak.h>
> > +#include <linux/memory.h>
> > #include <trace/events/kmem.h>
> >
> > #include <asm/tlbflush.h>
> > @@ -4985,23 +4986,53 @@ void set_pageblock_flags_group(struct pa
> > int set_migratetype_isolate(struct page *page)
> > {
> > struct zone *zone;
> > - unsigned long flags;
> > + unsigned long flags, pfn, iter;
> > + unsigned long immobile = 0;
> > + struct memory_isolate_notify arg;
> > + int notifier_ret;
> > int ret = -EBUSY;
> > int zone_idx;
> >
> > zone = page_zone(page);
> > zone_idx = zone_idx(zone);
> > +
> > spin_lock_irqsave(&zone->lock, flags);
> > + if (get_pageblock_migratetype(page) == MIGRATE_MOVABLE ||
> > + zone_idx == ZONE_MOVABLE) {
> > + ret = 0;
> > + goto out;
> > + }
> > +
> > + pfn = page_to_pfn(page);
> > + arg.start_pfn = pfn;
> > + arg.nr_pages = pageblock_nr_pages;
> > + arg.pages_found = 0;
> > +
> > /*
> > - * In future, more migrate types will be able to be isolation target.
> > + * The pageblock can be isolated even if the migrate type is
> > + * not *_MOVABLE. The memory isolation notifier chain counts
> > + * the number of pages in this pageblock that can be freed later
> > + * through the memory notifier chain. If all of the pages are
> > + * accounted for, isolation can continue.
>
> This comment could have been clearer as well
>
> * It may be possible to isolate a pageblock even if the migratetype is
> * not MIGRATE_MOVABLE. The memory isolation notifier chain is used by
> * balloon drivers to return the number of pages in a range that are held
> * by the balloon driver to shrink memory. If all the pages are accounted
> * for by balloons or are free, isolation can continue
* It may be possible to isolate a pageblock even if the migratetype is
* not MIGRATE_MOVABLE. The memory isolation notifier chain is used by
* balloon drivers to return the number of pages in a range that are held
* by the balloon driver to shrink memory. If all the pages are accounted
* for by balloons, are free, or on the LRU, isolation can continue.
* Later, for example, when memory hotplug notifier runs, these pages
* reported as "can be isolated" should be isolated(freed) by the balloon
* driver through the memory notifier chain.
> > */
> > - if (get_pageblock_migratetype(page) != MIGRATE_MOVABLE &&
> > - zone_idx != ZONE_MOVABLE)
> > + notifier_ret = memory_isolate_notify(MEM_ISOLATE_COUNT, &arg);
> > + notifier_ret = notifier_to_errno(notifier_ret);
> > + if (notifier_ret || !arg.pages_found)
> > goto out;
> > - set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> > - move_freepages_block(zone, page, MIGRATE_ISOLATE);
> > - ret = 0;
> > +
> > + for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++)
> > + if (page_count(pfn_to_page(iter)))
> > + immobile++;
> > +
>
> This part here is not safe when CONFIG_HOLES_IN_ZONE is set. You need to
> make it something like
>
> for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++) {
> if (!pfn_valid_within(pfn))
> continue;
>
> if (page_count(pfn_to_page(iter)))
> immobile++;
> }
>
> You shouldn't need to run pfn_valid() as you're always starting from a valid
> page and never going outside MAX_ORDER_NR_PAGES in this iterator.
>
I will make this change.
> > + if (arg.pages_found == immobile)
> > + ret = 0;
> > +
>
> Ok, so if all pages in a range that are in use match the count returned
> by the balloon, then it's ok to isolate.
Correct.
> > out:
> > + if (!ret) {
> > + set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> > + move_freepages_block(zone, page, MIGRATE_ISOLATE);
> > + }
> > +
> > spin_unlock_irqrestore(&zone->lock, flags);
> > if (!ret)
> > drain_all_pages();
> >
>
> The patch looks more or less sane. It would be nice to have a follow-on patch
> that clarified some details but it's not necessary. The pfn_valid_within()
> should be done as a follow-on patch. I haven't actually tested this but
> otherwise it looks ok. Once the pfn_valid_within() is sorted out, it has
> my Ack.
I'll be sending out a new revision of this patch rather than a
follow-on due to other changes (change from BLOCKING_NOTIFIER_HEAD to
ATOMIC_NOTIFIER_HEAD) and I will include changes discussed here. Thank
you for the review.
^ permalink raw reply
* Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
From: Robert Jennings @ 2009-10-09 14:33 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-mm, Mel Gorman, linux-kernel, linuxppc-dev,
Martin Schwidefsky, Badari Pulavarty, Brian King, Paul Mackerras,
Ingo Molnar
In-Reply-To: <20091009094740.fe84e46a.kamezawa.hiroyu@jp.fujitsu.com>
* KAMEZAWA Hiroyuki (kamezawa.hiroyu@jp.fujitsu.com) wrote:
> On Fri, 2 Oct 2009 13:44:58 -0500
> Robert Jennings <rcj@linux.vnet.ibm.com> wrote:
>
> > Memory balloon drivers can allocate a large amount of memory which
> > is not movable but could be freed to accomodate memory hotplug remove.
> >
> > Prior to calling the memory hotplug notifier chain the memory in the
> > pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
> > isolation will not proceed, causing the memory removal for that page
> > range to fail.
> >
> > Rather than failing pageblock isolation if the the migrateteype is not
> > MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
> > are owned by a registered balloon driver (or other entity) using a
> > notifier chain. If all of the non-movable pages are owned by a balloon,
> > they can be freed later through the memory notifier chain and the range
> > can still be isolated in set_migratetype_isolate().
> >
> > Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
> >
> > ---
> > drivers/base/memory.c | 19 +++++++++++++++++++
> > include/linux/memory.h | 26 ++++++++++++++++++++++++++
> > mm/page_alloc.c | 45 ++++++++++++++++++++++++++++++++++++++-------
> > 3 files changed, 83 insertions(+), 7 deletions(-)
> >
> > Index: b/drivers/base/memory.c
> > ===================================================================
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
> > }
> > EXPORT_SYMBOL(unregister_memory_notifier);
> >
> > +static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
> > +
>
> IIUC, this notifier is called under zone->lock.
> please ATOMIC_NOTIFIER_HEAD().
I will correct this.
> > +int register_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + return blocking_notifier_chain_register(&memory_isolate_chain, nb);
> > +}
> > +EXPORT_SYMBOL(register_memory_isolate_notifier);
> > +
> > +void unregister_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + blocking_notifier_chain_unregister(&memory_isolate_chain, nb);
> > +}
> > +EXPORT_SYMBOL(unregister_memory_isolate_notifier);
> > +
> > /*
> > * register_memory - Setup a sysfs device for a memory block
> > */
> > @@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
> > return blocking_notifier_call_chain(&memory_chain, val, v);
> > }
> >
> > +int memory_isolate_notify(unsigned long val, void *v)
> > +{
> > + return blocking_notifier_call_chain(&memory_isolate_chain, val, v);
> > +}
> > +
> > /*
> > * MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
> > * OK to have direct references to sparsemem variables in here.
> > Index: b/include/linux/memory.h
> > ===================================================================
> > --- a/include/linux/memory.h
> > +++ b/include/linux/memory.h
> > @@ -50,6 +50,18 @@ struct memory_notify {
> > int status_change_nid;
> > };
> >
> > +/*
> > + * During pageblock isolation, count the number of pages in the
> > + * range [start_pfn, start_pfn + nr_pages)
> > + */
> > +#define MEM_ISOLATE_COUNT (1<<0)
> > +
> > +struct memory_isolate_notify {
> > + unsigned long start_pfn;
> > + unsigned int nr_pages;
> > + unsigned int pages_found;
> > +};
>
> Could you add commentary for each field ?
This will be documented in the next version of the patch.
> > +
> > struct notifier_block;
> > struct mem_section;
> >
> > @@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
> > {
> > return 0;
> > }
> > +static inline int register_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > + return 0;
> > +}
> > +static inline void unregister_memory_isolate_notifier(struct notifier_block *nb)
> > +{
> > +}
> > +static inline int memory_isolate_notify(unsigned long val, void *v)
> > +{
> > + return 0;
> > +}
> > #else
> > extern int register_memory_notifier(struct notifier_block *nb);
> > extern void unregister_memory_notifier(struct notifier_block *nb);
> > +extern int register_memory_isolate_notifier(struct notifier_block *nb);
> > +extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
> > extern int register_new_memory(int, struct mem_section *);
> > extern int unregister_memory_section(struct mem_section *);
> > extern int memory_dev_init(void);
> > extern int remove_memory_block(unsigned long, struct mem_section *, int);
> > extern int memory_notify(unsigned long val, void *v);
> > +extern int memory_isolate_notify(unsigned long val, void *v);
> > extern struct memory_block *find_memory_block(struct mem_section *);
> > #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
> > enum mem_add_context { BOOT, HOTPLUG };
> > Index: b/mm/page_alloc.c
> > ===================================================================
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -48,6 +48,7 @@
> > #include <linux/page_cgroup.h>
> > #include <linux/debugobjects.h>
> > #include <linux/kmemleak.h>
> > +#include <linux/memory.h>
> > #include <trace/events/kmem.h>
> >
> > #include <asm/tlbflush.h>
> > @@ -4985,23 +4986,53 @@ void set_pageblock_flags_group(struct pa
> > int set_migratetype_isolate(struct page *page)
> > {
> > struct zone *zone;
> > - unsigned long flags;
> > + unsigned long flags, pfn, iter;
> > + unsigned long immobile = 0;
> > + struct memory_isolate_notify arg;
> > + int notifier_ret;
> > int ret = -EBUSY;
> > int zone_idx;
> >
> > zone = page_zone(page);
> > zone_idx = zone_idx(zone);
> > +
> > spin_lock_irqsave(&zone->lock, flags);
> > + if (get_pageblock_migratetype(page) == MIGRATE_MOVABLE ||
> > + zone_idx == ZONE_MOVABLE) {
> > + ret = 0;
> > + goto out;
> > + }
> > +
> > + pfn = page_to_pfn(page);
> > + arg.start_pfn = pfn;
> > + arg.nr_pages = pageblock_nr_pages;
> > + arg.pages_found = 0;
> > +
> > /*
> > - * In future, more migrate types will be able to be isolation target.
> > + * The pageblock can be isolated even if the migrate type is
> > + * not *_MOVABLE. The memory isolation notifier chain counts
> > + * the number of pages in this pageblock that can be freed later
> > + * through the memory notifier chain. If all of the pages are
> > + * accounted for, isolation can continue.
> > */
>
> Could add explanation like this ?
> ==
> Later, for example, when memory hotplug notifier runs, these pages reported as
> "can be isoalted" should be isolated(freed) by callbacks.
> ==
I'll change this comment. You and Mel both gave me good direction here.
> > - if (get_pageblock_migratetype(page) != MIGRATE_MOVABLE &&
> > - zone_idx != ZONE_MOVABLE)
> > + notifier_ret = memory_isolate_notify(MEM_ISOLATE_COUNT, &arg);
> > + notifier_ret = notifier_to_errno(notifier_ret);
> > + if (notifier_ret || !arg.pages_found)
> > goto out;
> > - set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> > - move_freepages_block(zone, page, MIGRATE_ISOLATE);
> > - ret = 0;
> > +
> > + for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++)
> > + if (page_count(pfn_to_page(iter)))
> > + immobile++;
> > +
> > + if (arg.pages_found == immobile)
> > + ret = 0;
> > +
>
> I can't understand this part. Does this mean all pages under this pageblock
> are used by balloon driver ?
> IOW, memory is hotpluggable only when all pages under this pageblock is used
> by balloon ?
>
>
> Hmm. Can't we do this kind of check..?
> ==
> for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++) {
> page = pfn_to_page(iter);
> if (!page_count(page) || PageLRU(page)) // This page is movable.
> continue;
> immobile++
> }
> ==
> Then, if a page is luckyly on LRU, we have more chances.
> (This check can fail if a page is on percpu pagevec etc...)
>
> Thanks,
> -Kame
I like this change, it will be in my next patch after I finish testing.
Thank you for your review.
> > out:
> > + if (!ret) {
> > + set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> > + move_freepages_block(zone, page, MIGRATE_ISOLATE);
> > + }
> > +
> > spin_unlock_irqrestore(&zone->lock, flags);
> > if (!ret)
> > drain_all_pages();
> >
> > --
^ permalink raw reply
* Support for S29JL064 in MPC8272ADS?
From: Roberto Guerra @ 2009-10-09 14:14 UTC (permalink / raw)
To: linuxppc-dev
Hello,
My uboot can read my flash chip, finding the uImage and the initramfs,
and booting the kernel fine. However, I'd like the Linux kernel to
read my flash chip so that it can update files in it.
My flash chip is the Spansion S29JL064H (AMD), 16 bit wide, 64 Mbit.
The chip is mapped from FF800000 to FFFFFFFF. The rootfs.jffs2 was
written on 0XFF990000 and is 0x390000 long.
I know that the JFFS is written correctly, because it is detected by uboot:
=> fsinfo
### filesystem type is JFFS2
Scanning JFFS2 FS: ....... done.
Compression: NONE
frag count: 523
compressed sum: 138074
uncompressed sum: 138074
Compression: ZERO
frag count: 0
compressed sum: 0
uncompressed sum: 0
Compression: RTIME
frag count: 1
compressed sum: 48
uncompressed sum: 52
Compression: RUBINMIPS
frag count: 0
compressed sum: 0
uncompressed sum: 0
Compression: COPY
frag count: 0
compressed sum: 0
uncompressed sum: 0
Compression: DYNRUBIN
frag count: 0
compressed sum: 0
uncompressed sum: 0
Compression: ZLIB
frag count: 2031
compressed sum: 3370991
uncompressed sum: 7598685
=> flinfo
Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 142 Sectors
AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E0201
Erase timeout: 8192 ms, write timeout: 1 ms
Sector Start Addresses:
FF800000 FF802000 FF804000 FF806000 FF808000
FF80A000 FF80C000 FF80E000 FF810000 FF820000
FF830000 FF840000 FF850000 FF860000 FF870000
FF880000 FF890000 FF8A0000 FF8B0000 FF8C0000
FF8D0000 FF8E0000 FF8F0000 FF900000 FF910000
FF920000 FF930000 FF940000 FF950000 FF960000
FF970000 FF980000 FF990000 FF9A0000 FF9B0000
FF9C0000 FF9D0000 FF9E0000 FF9F0000 FFA00000
FFA10000 FFA20000 FFA30000 FFA40000 FFA50000
FFA60000 FFA70000 FFA80000 FFA90000 FFAA0000
FFAB0000 FFAC0000 FFAD0000 FFAE0000 FFAF0000
FFB00000 FFB10000 FFB20000 FFB30000 FFB40000
FFB50000 FFB60000 FFB70000 FFB80000 FFB90000
FFBA0000 FFBB0000 FFBC0000 FFBD0000 FFBE0000
FFBF0000 FFC00000 FFC10000 FFC20000 FFC30000
FFC40000 FFC50000 FFC60000 FFC70000 FFC80000
FFC90000 FFCA0000 FFCB0000 FFCC0000 FFCD0000
FFCE0000 FFCF0000 FFD00000 FFD10000 FFD20000
FFD30000 FFD40000 FFD50000 FFD60000 FFD70000
FFD80000 FFD90000 FFDA0000 FFDB0000 FFDC0000
FFDD0000 FFDE0000 FFDF0000 FFE00000 FFE10000
FFE20000 FFE30000 FFE40000 FFE50000 FFE60000
FFE70000 FFE80000 FFE90000 FFEA0000 FFEB0000
FFEC0000 FFED0000 FFEE0000 FFEF0000 FFF00000 RO
FFF10000 RO FFF20000 RO FFF30000 RO FFF40000 RO FFF50000 RO
FFF60000 RO FFF70000 RO FFF80000 FFF90000 FFFA0000
FFFB0000 FFFC0000 FFFD0000 FFFE0000 FFFF0000
FFFF2000 FFFF4000 FFFF6000 FFFF8000 FFFFA000
FFFFC000 FFFFE000
My bootargs are:
bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw
mtdparts=phys:1600K(ROM)ro,6M(root),512K(U-Boot)ro,512K(unused)
However, the kernel does not detect any flash chip (nor there's any
indication that a CFI probe is being performed).
My flash kconfig section:
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
# CONFIG_MTD_CFI_NOSWAP is not set
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
CONFIG_MTD_CFI_LE_BYTE_SWAP=y
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
Roberto Guerra
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Nate Case @ 2009-10-09 14:01 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <fa686aa40910082240w7fb2a194tcc80e7afe182e781@mail.gmail.com>
On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
> For your future reference, patches that look at the device tree should
> also cc: devicetree-discuss@lists.ozlabs.org so that new bindings can
> be reviewed and common mistakes can be avoided. It is expected that
> new device tree bindings are accompanied with documentation describing
> what the binding is for and how it should be used (see
> Documentation/powerpc/dts-bindings).
>
> I know this change is already in mainline, but can you please post the
> device tree fragment that you're using to describe this chip? I want
> to make sure we don't get stuck with things in the kernel that will be
> hard to maintain in the long term.
Hi Grant,
Sorry for neglecting to include devicetree-discuss on that one. I was
in fact aware of this list, and subscribe to it. I really just forgot
in this case.
I also have a documentation patch for it that went along with it, but it
wasn't ready in time and so it's been sitting in our local patch queue.
I can submit that soon, but it probably makes sense for Wolfram to
voice whatever his concerns were about "questionable" properties before
I document what's there.
Here's an example device tree node for this case:
gpio1: gpio@18 {
compatible = "nxp,pca9557";
reg = <0x18>;
#gpio-cells = <2>;
gpio-controller;
polarity = <0x00>;
};
In this case, the linux,gpio-base property wasn't specified. But, the
use case is identical to the pdata->gpio_base field. "polarity" is used
for specifying polarity inversion for each line, and is in the same
format of the 'polarity inversion' register on the chip. My reasoning
in the property naming was as follows:
linux,gpio-base: Linux-specific as it relates to internal GPIO
numbering. So, it's prefixed with "linux,"
polarity: Dictated by how hardware is wired up, so it's needed
regardless of the OS.
- Nate
^ permalink raw reply
* Re: ppc_md.SMI replacement for 2.6
From: Arnd Bergmann @ 2009-10-09 13:50 UTC (permalink / raw)
To: Donald Kayser, linuxppc-dev; +Cc: linuxkernel
In-Reply-To: <449C2FDE-42DD-490C-8288-CF03224BDA34@kayser.net>
On Friday 09 October 2009, Donald Kayser wrote:
> On further comparison, this section of code has been added by the
> vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
> anyone would like to lend a thought towards System Managment
> Exceptions on PPC, please cc me at linux@kayser.net. I will be
> stopping the subscription to this list shortly. Regards, Donald
Hi Donald,
You should ask ppc specific questions on the linuxppc-dev@ozlabs.org
mailing list instead of the global linux-kernel list to increase the
chances of someone reading it who knows the answer.
The world of powerpc linux has changed a lot since 2.4, as you
undoubtedly found out. You are certainly encouraged to submit
your platform code for inclusion in the mainline kernel (if you
can do the usual cleanups necessary to do that), even for
old code.
I don't know a specific reason why the SMI callback was removed,
but I would guess that if you have a platform that requires it
and want it in the mainline kernel, a callback for it can be
added back, either through ppc_md or some other method.
Arnd <><
> On Oct 8, 2009, at 8:37 AM, Donald Kayser wrote:
>
> > I have found the differences between the 2.4 and 2.6 kernel. It is
> > in linux-2.4/arch/ppc/kernel/traps.c and linux-2.6/arch/powerpc/
> > kernel/traps.c in the function SMIException(). There is no longer
> > the code segment
> >
> > if (ppc_md.SMI)
> > {
> > ppc_md.SMI(regs);
> > return;
> > }
> >
> > There is now only a
> >
> > die("System Management Interrupt", regs, SIGABRT);
> >
> > I am guessing that the SMI callback is no longer needed by the linux
> > community at large, so I modified the code for my specific hardware
> > (HPPB) and acknowledged the exception as in the 2.4 kernel, and
> > returned from the exception without the call to die(). My problem
> > now is that it doesn't seem to work. Does anyone have a reason why
> > the SMI exception might hang the system when it has been provided a
> > handler?
> >
> > Thanks in advance.
> >
> > Donald Kayser
> >
> > On Oct 7, 2009, at 10:06 AM, Donald Kayser wrote:
> >
> >> I have ported the 2.6 kernel to an embedded PPC target (old stuff).
> >> I have managed to figure everything out, but can't find any
> >> replacement for a SMI handler. The original 2.4 version for this
> >> target has a bit of code ppc_md.SMI == SmiFuncHandler; I have not
> >> been able to find in the current source anything like this. I am
> >> not certain that I need to provide a handler at all, but the
> >> original developers saw some reason for including it. The
> >> particular handler does not do anything more than cancel a watchdog
> >> listener for this specific target. I have been living without the
> >> handler, but would like to find any kind of replacement if it is
> >> supported.
> >>
> >> Thanks,
> >> Donald Kayser
> >> linux@kayser.net
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Nate Case @ 2009-10-09 13:43 UTC (permalink / raw)
To: Wolfram Sang; +Cc: devicetree-discuss, linux-embedded, linuxppc-dev, linux-i2c
In-Reply-To: <20091009051409.GA2361@pengutronix.de>
On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote:
> And while doing this and figuring the pro/cons of those methods, I
> stumbled over this commit:
>
> gpio: pca953x: Get platform_data from OpenFirmware
> (1965d30356c1c65660ba3330927671cfe81acdd5)
Aside from any issues you have with the properties themselves, what's
your take on this approach?
Personally, I just got tired of waiting for someone else to solve the
pdata/OF problem. So I submitted that commit as an attempt at something
very simple and unobtrusive to the device driver itself. It seems
pretty clean to me, but I'm curious to see if others have any better
ideas.
- Nate
^ permalink raw reply
* Re: [PATCH 0/6] 8xx MMU fixes
From: Joakim Tjernlund @ 2009-10-09 12:30 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091009064649.GA9660@compile2.chatsunix.int.mrv.com>
Rex Feany <RFeany@mrv.com> wrote on 09/10/2009 08:46:49:
>
> Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
>
> > Rex Feany <RFeany@mrv.com> wrote on 09/10/2009 02:15:27:
>
> > > open("/proc/mounts", O_RDONLY) = 3
> > > fstat64(0x3, 0x7fe7e2a8) = 0
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =0x3001f000
> > > read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address)
> > > exit_group(0) = ?
> >
> > Try making the tlbil_va in fault.c unconditional, just to make sure
> > there isn't any old TLBs around.
>
> didn't make a difference
Perhaps you are suffering from a buggy dcbst insn? I tested it
on a RO mapping and it SEGVs. Clearing the store bit manually
at least fixes the SEGVs.
Here is a patch for that.
Jocke
>From 07dbca0cf9dc13cf0fbccf54d577e3bc1c5dfdf1 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Fri, 9 Oct 2009 14:18:21 +0200
Subject: [PATCH] 8xx: dcbst sets store bit in DTLB error, workaround.
dcbst should not set the store bit(bit 6, DSISR) when
trapping into a DTLB Error. Clear this bit while doing
the dcbX missing DAR workaround.
---
arch/powerpc/kernel/head_8xx.S | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 292bd87..7b31feb 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -630,6 +630,30 @@ FixDAR: /* Entry point for dcbx workaround. */
tophys (r11, r10)
beq- 139b /* Branch if user space address */
140: lwz r11,0(r11)
+/* Check if it really is a dcbx instruction. */
+/* dcbt and dcbtst does not generate DTLB Misses/Errors,
+ * no need to include them here */
+ srwi r10, r11, 26 /* check if major OP code is 31 */
+ cmpwi cr0, r10, 31
+ bne- 141f
+ rlwinm r10, r11, 0, 21, 30
+ cmpwi cr0, r10, 2028 /* Is dcbz? */
+ beq+ 142f
+ cmpwi cr0, r10, 940 /* Is dcbi? */
+ beq+ 142f
+ cmpwi cr0, r10, 108 /* Is dcbst? */
+ beq+ 144f /* Fix up store bit! */
+ cmpwi cr0, r10, 172 /* Is dcbf? */
+ beq+ 142f
+ cmpwi cr0, r10, 1964 /* Is icbi? */
+ beq+ 142f
+141: mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */
+ b DARfix /* Nope, go back to normal TLB processing */
+
+144: mfspr r10, SPRN_DSISR
+ rlwinm r10, r10,0,7,5 /* Clear store bit for buggy dcbst insn */
+ mtspr SPRN_DSISR, r10
+142: /* continue, it was a dcbx, dcbi instruction. */
#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0) /* restore r3 from memory */
#endif
--
1.6.4.4
^ permalink raw reply related
* [RESEND][PATCH]Ftrace - fix function_graph tracer OOPS
From: Sachin Sant @ 2009-10-09 12:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, rostedt
This time sending the patch as inline and not as an attachment.
Enabling function graph causes oops due to usage of LOAD_REG_IMMEDIATE().
As explained by Ben the usage of LOAD_REG_IMMEDIATE generates relocs that are
not supported when CONFIG_RELOCATABLE is set.
Switch to LOAD_REG_ADDR().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp old/arch/powerpc/kernel/entry_64.S new/arch/powerpc/kernel/entry_64.S
--- old/arch/powerpc/kernel/entry_64.S 2009-10-08 18:37:44.000000000 +0530
+++ new/arch/powerpc/kernel/entry_64.S 2009-10-08 18:34:33.000000000 +0530
@@ -1038,8 +1038,8 @@ _GLOBAL(mod_return_to_handler)
* We are in a module using the module's TOC.
* Switch to our TOC to run inside the core kernel.
*/
- LOAD_REG_IMMEDIATE(r4,ftrace_return_to_handler)
- ld r2, 8(r4)
+ ld r2, PACATOC(r13)
+ LOAD_REG_ADDR(r4,ftrace_return_to_handler)
bl .ftrace_return_to_handler
nop
^ permalink raw reply
* Re: [PATCH][v2] powerpc/4xx: Add 16K FIFO size DTS entries on supported platforms
From: Josh Boyer @ 2009-10-09 11:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Dave Mitchell
In-Reply-To: <1255054554.2355.28.camel@pasglop>
On Fri, Oct 09, 2009 at 01:15:54PM +1100, Benjamin Herrenschmidt wrote:
>On Thu, 2009-10-08 at 11:33 -0500, Dave Mitchell wrote:
>> Adding tx/rx-fifo-size-gige to EMAC fields for evaluation kit DTS
>> files where appropriate.
>>
>> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
>> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>> Acked-by: Victor Gallardo <vgallardo@appliedmicro.com>
>> Acked-by: Loc Ho <lho@appliedmicro.com>
>> ---
>> v1->v2: local date/time was out-of-sync and thus mail was as well
>
>I'll have to wait for the EMAC patch to go in, so ping me if you don't
>see me take that one after that happens.
I have some other DTS changes I'll be making soon. Mind if I pick it up
in my tree to avoid headaches? I will, of course, wait until the EMAC
patch is merged.
josh
^ permalink raw reply
* Re: linux booting fails on ppc440x5 with SRAM
From: Wolfgang Denk @ 2009-10-09 11:33 UTC (permalink / raw)
To: Vineeth _; +Cc: Johnny Hung, linuxppc-dev
In-Reply-To: <a9b543570910090320t1444f8f1qf4c8ab7dbbef679f@mail.gmail.com>
Dear Vineeth _,
In message <a9b543570910090320t1444f8f1qf4c8ab7dbbef679f@mail.gmail.com> you wrote:
> We ported the uboot Memory test and tested the 15MB ram and it was
> successful.interestingly we have only 16MB SRAM in our board.We used 1
Such a memory test means nothing. The only thing you can learn from it
is that basic read and write accesses are working. You don;t get any
information about the behaviour for burst mode accesses from such a
test. See the FAQ at
http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly and at
http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I mean, I . . . think to understand you, I just don't know what you
are saying ... - Terry Pratchett, _Soul Music_
^ permalink raw reply
* Re: [RFC] scripts/get_maintainer: add emails based on keywords in the patch
From: Joe Perches @ 2009-10-09 11:23 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss, linux-kernel
In-Reply-To: <1255084379-12954-1-git-send-email-w.sang@pengutronix.de>
On Fri, 2009-10-09 at 12:32 +0200, Wolfram Sang wrote:
> +my %keywords_to_mail = (
> + 'of_get_property' => 'L: devicetree-discuss@lists.ozlabs.org',
maybe: '\bof_get_property\b'
> + # Check the lines which a patch modifies for keywords; add mail if found.
> + } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
> + (my $keyword_mail = $keywords_to_mail{$1}) =~ s/^([LM]): //;
> + push( @{ ($1 eq 'L') ? \@list_to : \@email_to }, $keyword_mail );
> + }
If this facility is desired by many others, it might be
better to have a separate file of 'regex generates email'
read at initialization.
^ permalink raw reply
* Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
From: Mel Gorman @ 2009-10-09 11:21 UTC (permalink / raw)
To: Ingo Molnar, Badari Pulavarty, Brian King, Benjamin Herrenschmidt,
Paul Mackerras, Martin Schwidefsky, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <20091002184458.GC4908@austin.ibm.com>
On Fri, Oct 02, 2009 at 01:44:58PM -0500, Robert Jennings wrote:
> Memory balloon drivers can allocate a large amount of memory which
> is not movable but could be freed to accomodate memory hotplug remove.
>
> Prior to calling the memory hotplug notifier chain the memory in the
> pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
> isolation will not proceed, causing the memory removal for that page
> range to fail.
>
> Rather than failing pageblock isolation if the the migrateteype is not
s/the the migrateteype/the migratetype/
> MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
> are owned by a registered balloon driver (or other entity) using a
> notifier chain. If all of the non-movable pages are owned by a balloon,
> they can be freed later through the memory notifier chain and the range
> can still be isolated in set_migratetype_isolate().
>
> Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
>
> ---
> drivers/base/memory.c | 19 +++++++++++++++++++
> include/linux/memory.h | 26 ++++++++++++++++++++++++++
> mm/page_alloc.c | 45 ++++++++++++++++++++++++++++++++++++++-------
> 3 files changed, 83 insertions(+), 7 deletions(-)
>
> Index: b/drivers/base/memory.c
> ===================================================================
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
> }
> EXPORT_SYMBOL(unregister_memory_notifier);
>
> +static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
> +
> +int register_memory_isolate_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&memory_isolate_chain, nb);
> +}
> +EXPORT_SYMBOL(register_memory_isolate_notifier);
> +
> +void unregister_memory_isolate_notifier(struct notifier_block *nb)
> +{
> + blocking_notifier_chain_unregister(&memory_isolate_chain, nb);
> +}
> +EXPORT_SYMBOL(unregister_memory_isolate_notifier);
> +
> /*
> * register_memory - Setup a sysfs device for a memory block
> */
> @@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
> return blocking_notifier_call_chain(&memory_chain, val, v);
> }
>
> +int memory_isolate_notify(unsigned long val, void *v)
> +{
> + return blocking_notifier_call_chain(&memory_isolate_chain, val, v);
> +}
> +
> /*
> * MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
> * OK to have direct references to sparsemem variables in here.
> Index: b/include/linux/memory.h
> ===================================================================
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -50,6 +50,18 @@ struct memory_notify {
> int status_change_nid;
> };
>
> +/*
> + * During pageblock isolation, count the number of pages in the
> + * range [start_pfn, start_pfn + nr_pages)
> + */
>
The comment could have been slightly better. The count of pages in the
range is nr_pages - memory_holes but what you're counting is the number
of pages owned by the balloon driver in the notification chain.
> +#define MEM_ISOLATE_COUNT (1<<0)
> +
> +struct memory_isolate_notify {
> + unsigned long start_pfn;
> + unsigned int nr_pages;
> + unsigned int pages_found;
> +};
> +
> struct notifier_block;
> struct mem_section;
>
> @@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
> {
> return 0;
> }
> +static inline int register_memory_isolate_notifier(struct notifier_block *nb)
> +{
> + return 0;
> +}
> +static inline void unregister_memory_isolate_notifier(struct notifier_block *nb)
> +{
> +}
> +static inline int memory_isolate_notify(unsigned long val, void *v)
> +{
> + return 0;
> +}
> #else
> extern int register_memory_notifier(struct notifier_block *nb);
> extern void unregister_memory_notifier(struct notifier_block *nb);
> +extern int register_memory_isolate_notifier(struct notifier_block *nb);
> +extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
> extern int register_new_memory(int, struct mem_section *);
> extern int unregister_memory_section(struct mem_section *);
> extern int memory_dev_init(void);
> extern int remove_memory_block(unsigned long, struct mem_section *, int);
> extern int memory_notify(unsigned long val, void *v);
> +extern int memory_isolate_notify(unsigned long val, void *v);
> extern struct memory_block *find_memory_block(struct mem_section *);
> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
> enum mem_add_context { BOOT, HOTPLUG };
> Index: b/mm/page_alloc.c
> ===================================================================
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -48,6 +48,7 @@
> #include <linux/page_cgroup.h>
> #include <linux/debugobjects.h>
> #include <linux/kmemleak.h>
> +#include <linux/memory.h>
> #include <trace/events/kmem.h>
>
> #include <asm/tlbflush.h>
> @@ -4985,23 +4986,53 @@ void set_pageblock_flags_group(struct pa
> int set_migratetype_isolate(struct page *page)
> {
> struct zone *zone;
> - unsigned long flags;
> + unsigned long flags, pfn, iter;
> + unsigned long immobile = 0;
> + struct memory_isolate_notify arg;
> + int notifier_ret;
> int ret = -EBUSY;
> int zone_idx;
>
> zone = page_zone(page);
> zone_idx = zone_idx(zone);
> +
> spin_lock_irqsave(&zone->lock, flags);
> + if (get_pageblock_migratetype(page) == MIGRATE_MOVABLE ||
> + zone_idx == ZONE_MOVABLE) {
> + ret = 0;
> + goto out;
> + }
> +
> + pfn = page_to_pfn(page);
> + arg.start_pfn = pfn;
> + arg.nr_pages = pageblock_nr_pages;
> + arg.pages_found = 0;
> +
> /*
> - * In future, more migrate types will be able to be isolation target.
> + * The pageblock can be isolated even if the migrate type is
> + * not *_MOVABLE. The memory isolation notifier chain counts
> + * the number of pages in this pageblock that can be freed later
> + * through the memory notifier chain. If all of the pages are
> + * accounted for, isolation can continue.
This comment could have been clearer as well
* It may be possible to isolate a pageblock even if the migratetype is
* not MIGRATE_MOVABLE. The memory isolation notifier chain is used by
* balloon drivers to return the number of pages in a range that are held
* by the balloon driver to shrink memory. If all the pages are accounted
* for by balloons or are free, isolation can continue
> */
> - if (get_pageblock_migratetype(page) != MIGRATE_MOVABLE &&
> - zone_idx != ZONE_MOVABLE)
> + notifier_ret = memory_isolate_notify(MEM_ISOLATE_COUNT, &arg);
> + notifier_ret = notifier_to_errno(notifier_ret);
> + if (notifier_ret || !arg.pages_found)
> goto out;
> - set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> - move_freepages_block(zone, page, MIGRATE_ISOLATE);
> - ret = 0;
> +
> + for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++)
> + if (page_count(pfn_to_page(iter)))
> + immobile++;
> +
This part here is not safe when CONFIG_HOLES_IN_ZONE is set. You need to
make it something like
for (iter = pfn; iter < (pfn + pageblock_nr_pages); iter++) {
if (!pfn_valid_within(pfn))
continue;
if (page_count(pfn_to_page(iter)))
immobile++;
}
You shouldn't need to run pfn_valid() as you're always starting from a valid
page and never going outside MAX_ORDER_NR_PAGES in this iterator.
> + if (arg.pages_found == immobile)
> + ret = 0;
> +
Ok, so if all pages in a range that are in use match the count returned
by the balloon, then it's ok to isolate.
> out:
> + if (!ret) {
> + set_pageblock_migratetype(page, MIGRATE_ISOLATE);
> + move_freepages_block(zone, page, MIGRATE_ISOLATE);
> + }
> +
> spin_unlock_irqrestore(&zone->lock, flags);
> if (!ret)
> drain_all_pages();
>
The patch looks more or less sane. It would be nice to have a follow-on patch
that clarified some details but it's not necessary. The pfn_valid_within()
should be done as a follow-on patch. I haven't actually tested this but
otherwise it looks ok. Once the pfn_valid_within() is sorted out, it has
my Ack.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH 0/6] 8xx MMU fixes
From: Joakim Tjernlund @ 2009-10-09 11:04 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091009064649.GA9660@compile2.chatsunix.int.mrv.com>
Rex Feany <RFeany@mrv.com> wrote on 09/10/2009 08:46:49:
>
> Thus spake Joakim Tjernlund (joakim.tjernlund@transmode.se):
>
> > Rex Feany <RFeany@mrv.com> wrote on 09/10/2009 02:15:27:
>
> > > open("/proc/mounts", O_RDONLY) = 3
> > > fstat64(0x3, 0x7fe7e2a8) = 0
> > > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =0x3001f000
> > > read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address)
> > > exit_group(0) = ?
> >
> > Try making the tlbil_va in fault.c unconditional, just to make sure
> > there isn't any old TLBs around.
>
> didn't make a difference
OK, so how about:
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 6541855..f4b5dca 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -339,9 +339,9 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
- /* r10=(r10&~_PAGE_PRESENT)|((r10&_PAGE_ACCESSED)>>5) */
- rlwimi. r10, r10, 27, 31, 31
- beq- cr0, 2f /* Can be removed, costs a ITLB Err */
+ andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
+ cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
+ bne- cr0, 2f
#if 0 /* Dont' bother with PP lsb, bit 21 for now */
/* r10 = (r10 & ~0x0400) | ((r10 & _PAGE_EXEC) << 7) */
@@ -429,9 +429,11 @@ DataStoreTLBMiss:
/* Need to know if load/store -> force a TLB Error
* by copying ACCESSED to PRESENT.
*/
- /* r10=(r10&~_PAGE_PRESENT)|((r10&_PAGE_ACCESSED)>>5) */
- rlwimi r10, r10, 27, 31, 31
-
+ andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
+ cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
+ beq+ cr0, 6f
+ rlwinm r10, r10, 0, 0, 30 /* Clear _PAGE_PRESENT */
+6:
#if 0 /* Not yet */
/* Honour kernel RO, User NA */
andi. r11, r10, _PAGE_USER | _PAGE_RW
@@ -492,7 +494,7 @@ DataTLBError:
cmpwi cr0, r10, 0x00f0
beq- FixDAR /* must be a buggy dcbX, icbi insn. */
DARFix: /* Return from dcbx instruction bug workaround, r10 holds value of DAR */
-
+ b 2f /* Do DIRTY in C */
mfspr r11, SPRN_DSISR
andis. r11, r11, 0x4800 /* !translation or protection */
bne 2f /* branch if either is set */
^ permalink raw reply related
* [RFC] scripts/get_maintainer: add emails based on keywords in the patch
From: Wolfram Sang @ 2009-10-09 10:32 UTC (permalink / raw)
To: linux-kernel; +Cc: devicetree-discuss, linuxppc-dev, Joe Perches
Make get_maintainer.pl scan the modifying lines of a patch for a list of
keywords and add an associated email if found. The first user is the
devicetree-discuss mailing list which should always be cc'ed if a device tree
property is inserted/removed (keyword 'of_get_property'). This patch is the
result from commit 1965d30356c1c65660ba3330927671cfe81acdd5 entering mainline
which seems to have been missed by all parties interested in the device tree
(and at least had the documentation missing). As adding properties can happen
anywhere and so there is no fitting fileglob, this keyword based approach is
proposed.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Joe Perches <joe@perches.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
---
scripts/get_maintainer.pl | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index cdb44b6..e1150ea 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -44,6 +44,11 @@ my $help = 0;
my $exit = 0;
+my %keywords_to_mail = (
+ 'of_get_property' => 'L: devicetree-discuss@lists.ozlabs.org',
+);
+my $keywords_to_mail_match = join('|', keys %keywords_to_mail);
+
my @penguin_chief = ();
push(@penguin_chief,"Linus Torvalds:torvalds\@linux-foundation.org");
#Andrew wants in on most everything - 2009/01/14
@@ -188,6 +193,12 @@ if ($email_remove_duplicates) {
my @files = ();
my @range = ();
+my @email_to = ();
+my @list_to = ();
+my @scm = ();
+my @web = ();
+my @subsystem = ();
+my @status = ();
foreach my $file (@ARGV) {
##if $file is a directory and it lacks a trailing slash, add one
@@ -213,7 +224,11 @@ foreach my $file (@ARGV) {
if ($email_git_blame) {
push(@range, "$lastfile:$1:$2");
}
- }
+ # Check the lines which a patch modifies for keywords; add mail if found.
+ } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
+ (my $keyword_mail = $keywords_to_mail{$1}) =~ s/^([LM]): //;
+ push( @{ ($1 eq 'L') ? \@list_to : \@email_to }, $keyword_mail );
+ }
}
close(PATCH);
if ($file_cnt == @files) {
@@ -224,13 +239,6 @@ foreach my $file (@ARGV) {
}
}
-my @email_to = ();
-my @list_to = ();
-my @scm = ();
-my @web = ();
-my @subsystem = ();
-my @status = ();
-
# Find responsible parties
foreach my $file (@files) {
--
1.6.3.3
^ permalink raw reply related
* Re: linux booting fails on ppc440x5 with SRAM
From: Vineeth _ @ 2009-10-09 10:20 UTC (permalink / raw)
To: Johnny Hung; +Cc: linuxppc-dev
In-Reply-To: <cb9ecdfa0910021017s5eece937ve7af90473d5a1a33@mail.gmail.com>
We ported the uboot Memory test and tested the 15MB ram and it was
successful.interestingly we have only 16MB SRAM in our board.We used 1
MB of RAM for the bootloader to execute and tested the other 15 MB.
i couldnt see any reason why the DEAR, MSR value become identical.
checked the objcopy of my linux image and the instruction on that
particular location was an ordinary branch instruction. !
On Fri, Oct 2, 2009 at 10:47 PM, Johnny Hung <johnny.hacking@gmail.com> wro=
te:
> It's seems a RAM initialize problem. Try to use ICE or your bootloader
> to test initialized RAM wirh write/read operation.
> Ex, use mtest in uboot to check memory. For ICE, it should be an
> detailed memory test function like hardware diagnostic.
>
> 2009/9/24 Benjamin Herrenschmidt <benh@kernel.crashing.org>:
>> On Wed, 2009-09-23 at 20:19 +0530, Vineeth _ wrote:
>>> I am trying to port linux on IBM powerpc-440x5. I have this board
>>> which has this processor, a 16MB SRAM sits on location 0x0, uart and a
>>> flash.I have a simple bootloader which does the following.
>>> =A0 =A0 1. Initialize the processor (as part of it, we Generates the tl=
bs
>>> for UART,16MB flash,16MB SRAM)
>>> =A0 =A0 2. Initialize the UART
>>> =A0 =A0 3. Copy the simple-boot linux_image (binary file) from flash to
>>> 0x400000 location of SRAM.
>>> =A0 =A0 4. Kernel entry to 0x400000
>>
>> Not sure yet, looks like things are being overwritten during boot.
>> Interestingly enough, the DEAR value looks like an MSR value..
>>
>> Hard to tell what's up. You'll have to dig a bit more youself to
>> figure out how come the kernel's getting that bad pointer.
>>
>> All I can tell you is that things work fine on 440x5 cores, though
>> I haven't tested a configuration with so little memory in a while.
>>
>> Ben.
>>
>>> zImage starting: loaded at 0x00400000 (sp: 0x004deeb0)
>>> Allocating 0x1dad84 bytes for kernel ...
>>> gunzipping (0x00000000 <- 0x0040c000:0x004dd3f1)...done 0x1c31cc bytes
>>>
>>> Linux/PowerPC load: console=3DttyS0 root=3D/dev/ram
>>> Finalizing device tree... flat tree at 0x4eb300
>>> id mach(): done
>>> inside skybeam_register_console function
>>> MMU:enterMMU:hw initMMU:mapinMMU:setioMMU:exitinside
>>> _setup_arch-begininginside _setup_arch-1inside
>>> _setup_arch-2setup_arch: bootmemarch: exit<7>Top of RAM: 0x1000000,
>>> Total RAM: 0x1000000
>>> Zone PFN ranges:
>>> =A0DMA =A0 =A0 =A00x00000000 -> 0x00001000
>>> =A0Normal =A0 0x00001000 -> 0x00001000
>>> Movable zone start PFN for each node
>>> early_node_map[1] active PFN ranges
>>> =A0 =A00: 0x00000000 -> 0x00001000
>>> MMU: Allocated 1088 bytes of context maps for 255 contexts
>>> Built 1 zonelists in Zone order, mobility grouping off. =A0Total pages:=
4064
>>> Kernel command line: console=3DttyS0 root=3D/dev/ram
>>> Unable to handle kernel paging request for data at address 0x00021000
>>> Faulting instruction address: 0xc010a7c4
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> PREEMPT PowerPC 44x Platform
>>> Modules linked in:
>>> NIP: c010a7c4 LR: c010dc50 CTR: 00000000
>>> REGS: c01bfeb0 TRAP: 0300 =A0 Not tainted =A0(2.6.30)
>>> MSR: 00021000 <ME,CE> =A0CR: 24000044 =A0XER: 00000000
>>> DEAR: 00021000, ESR: 00000000
>>> TASK =3D c01a94b8[0] 'swapper' THREAD: c01be000
>>> GPR00: 00001180 c01bff60 c01a94b8 00021000 00000025 00000008 c0104968 0=
0000000
>>> GPR08: 2f72616d c0110000 c0155938 c01a0000 22000024 00000000 fffff104 0=
0000000
>>> GPR16: 00000000 00000000 00000000 00000000 fffffff8 000008b8 c010d758 c=
0104968
>>> GPR24: 00001198 00001190 c018a001 c01c5498 000008c0 00001188 00021000 c=
01c42f0
>>> NIP [c010a7c4] strchr+0x0/0x3c
>>> LR [c010dc50] match_token+0x138/0x228
>>> Call Trace:
>>> [c01bff60] [c016b99c] 0xc016b99c (unreliable)
>>> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
>>> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
>>> [c01bffc0] [c018c734] start_kernel+0x140/0x288
>>> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
>>> Instruction dump:
>>> 7ca903a6 88040000 38a5ffff 38840001 2f800000 98090000 39290001 419e0010
>>> 4200ffe4 98a90000 4e800020 4e800020 <88030000> 5484063e 7f802000 4d9e00=
20
>>> ---[ end trace 31fd0ba7d8756001 ]---
>>> Kernel panic - not syncing: Attempted to kill the idle task!
>>> Call Trace:
>>> [c01bfd90] [c0005d5c] show_stack+0x4c/0x16c (unreliable)
>>> [c01bfdd0] [c002f17c] panic+0xa0/0x168
>>> [c01bfe20] [c0032eb8] do_exit+0x61c/0x638
>>> [c01bfe60] [c000b60c] kernel_bad_stack+0x0/0x4c
>>> [c01bfe90] [c000f310] bad_page_fault+0x90/0xd8
>>> [c01bfea0] [c000e184] handle_page_fault+0x7c/0x80
>>> [c01bff60] [c016b99c] 0xc016b99c
>>> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
>>> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
>>> [c01bffc0] [c018c734] start_kernel+0x140/0x288
>>> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
>>> Rebooting in 180 seconds..
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines.
From: Arun R Bharadwaj @ 2009-10-09 9:39 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-arch, linux-kernel, linux-acpi, Arun Bharadwaj, Ingo Molnar,
linuxppc-dev, Arjan van de Ven
In-Reply-To: <1255004737.26976.307.camel@twins>
* Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-10-08 14:25:37]:
> On Thu, 2009-10-08 at 17:31 +0530, Arun R Bharadwaj wrote:
> >
> > > Uhm, no, it would mean ACPI putting its idle routines on the same level
> > > as all others.
> > >
> >
> > Putting them all on the same level would mean, we need an
> > enable/disable routine to enable only the currently active routines.
>
> What's this enable/disable stuff about?
>
> > Also, the way governor works is that, it assumes that idle routines
> > are indexed in the increasing order of power benefit that can be got
> > out of the state. So this would get messed up.
>
> Right, which is why I initially had a power-savings field in my
> proposal, so it could weight the power savings vs the wakeup latency.
>
> http://lkml.org/lkml/2009/8/27/159
>
> There it was said that was exactly what these governors were doing,
> seems its not.
>
> > > Sounds like something is wrong alright. If you can register an idle
> > > routine you should be able to unregister it too.
> > >
> >
> > Yes, we can register and unregister in a clean way now.
> > Consider this. We have a set of routines A, B, C currently registered.
> > Now a module comes and registers D and E, and later on at some point
> > of time wants to unregister. So how do you keep track of what all idle
> > routines the module registered and unregister only those?
> > Best way to do that is a stack, which is how I have currently
> > implemented.
>
> Right, so destroy that inner set thing, that way we only have one
> left ;-)
>
I'm not convinced with your argument. Why dont we do this
incrementally. Right now, this set of sets mechanism works fine and
doesn't look like it has any obvious flaws in it. We have a clean
register/unregister mechanism which solves all the earlier problems we
started out to solve.
We can gradually build on this and try to come up with a single set
of idle states for a governor to choose from.
thanks,
arun
^ permalink raw reply
* [PATCH v4 4/4] pseries: Serialize cpu hotplug operations during deactivate Vs deallocate
From: Gautham R Shenoy @ 2009-10-09 8:31 UTC (permalink / raw)
To: Nathan Fontenot, Benjamin Herrenschmidt, linuxppc-dev,
Peter Zijlstra, linux-kernel
Cc: Arun R Bharadwaj
In-Reply-To: <20091009082952.32381.32794.stgit@sofia.in.ibm.com>
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables "probe" during allocation
and "release" during deallocation.
At the sametime, the userspace can independently online/offline the CPUs of
the system using the sysfs tunable "online".
It is quite possible that when a userspace tool offlines a CPU
for the purpose of deallocation and is in the process of updating the device
tree, some other userspace tool could bring the CPU back online by writing to
the "online" sysfs tunable thereby causing the deallocate process to fail.
The solution to this is to serialize writes to the "probe/release" sysfs
tunable with the writes to the "online" sysfs tunable.
This patch employs a mutex to provide this serialization, which is a no-op on
all architectures except PPC_PSERIES
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 26 ++++++++++++++++++++++----
drivers/base/cpu.c | 2 ++
include/linux/cpu.h | 13 +++++++++++++
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 9752386..fc261e6 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -644,6 +644,18 @@ static ssize_t memory_release_store(struct class *class, const char *buf,
return rc ? -1 : count;
}
+static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
+
+void cpu_hotplug_driver_lock()
+{
+ mutex_lock(&pseries_cpu_hotplug_mutex);
+}
+
+void cpu_hotplug_driver_unlock()
+{
+ mutex_unlock(&pseries_cpu_hotplug_mutex);
+}
+
static ssize_t cpu_probe_store(struct class *class, const char *buf,
size_t count)
{
@@ -656,14 +668,15 @@ static ssize_t cpu_probe_store(struct class *class, const char *buf,
if (rc)
return -EINVAL;
+ cpu_hotplug_driver_lock();
rc = acquire_drc(drc_index);
if (rc)
- return rc;
+ goto out;
dn = configure_connector(drc_index);
if (!dn) {
release_drc(drc_index);
- return rc;
+ goto out;
}
/* fixup dn name */
@@ -672,7 +685,8 @@ static ssize_t cpu_probe_store(struct class *class, const char *buf,
if (!cpu_name) {
free_cc_nodes(dn);
release_drc(drc_index);
- return -ENOMEM;
+ rc = -ENOMEM;
+ goto out;
}
sprintf(cpu_name, "/cpus/%s", dn->full_name);
@@ -684,6 +698,8 @@ static ssize_t cpu_probe_store(struct class *class, const char *buf,
release_drc(drc_index);
rc = online_node_cpus(dn);
+out:
+ cpu_hotplug_driver_unlock();
return rc ? rc : count;
}
@@ -705,6 +721,7 @@ static ssize_t cpu_release_store(struct class *class, const char *buf,
return -EINVAL;
}
+ cpu_hotplug_driver_lock();
rc = offline_node_cpus(dn);
if (rc)
@@ -713,7 +730,7 @@ static ssize_t cpu_release_store(struct class *class, const char *buf,
rc = release_drc(*drc_index);
if (rc) {
of_node_put(dn);
- return rc;
+ goto out;
}
rc = remove_device_tree_nodes(dn);
@@ -723,6 +740,7 @@ static ssize_t cpu_release_store(struct class *class, const char *buf,
of_node_put(dn);
out:
+ cpu_hotplug_driver_unlock();
return rc ? rc : count;
}
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index e62a4cc..07c3f05 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -35,6 +35,7 @@ static ssize_t __ref store_online(struct sys_device *dev, struct sysdev_attribut
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
ssize_t ret;
+ cpu_hotplug_driver_lock();
switch (buf[0]) {
case '0':
ret = cpu_down(cpu->sysdev.id);
@@ -49,6 +50,7 @@ static ssize_t __ref store_online(struct sys_device *dev, struct sysdev_attribut
default:
ret = -EINVAL;
}
+ cpu_hotplug_driver_unlock();
if (ret >= 0)
ret = count;
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 4753619..b0ad4e1 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -115,6 +115,19 @@ extern void put_online_cpus(void);
#define unregister_hotcpu_notifier(nb) unregister_cpu_notifier(nb)
int cpu_down(unsigned int cpu);
+#ifdef CONFIG_PPC_PSERIES
+extern void cpu_hotplug_driver_lock(void);
+extern void cpu_hotplug_driver_unlock(void);
+#else
+static inline void cpu_hotplug_driver_lock(void)
+{
+}
+
+static inline void cpu_hotplug_driver_unlock(void)
+{
+}
+#endif
+
#else /* CONFIG_HOTPLUG_CPU */
#define get_online_cpus() do { } while (0)
^ permalink raw reply related
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