* Re: [PATCH 3/7] Update the [register,unregister]_memory routines
From: Nathan Fontenot @ 2010-07-13 15:46 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152044.7ec8c9ae.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:20 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:44:10 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch moves the register/unregister_memory routines to
>> avoid a forward declaration. It also moves the sysfs file
>> creation and deletion for each directory into the register/
>> unregister routines to avoid duplicating it with these updates.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> drivers/base/memory.c | 93 +++++++++++++++++++++++++-------------------------
>> 1 file changed, 48 insertions(+), 45 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:17.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> @@ -87,31 +87,6 @@
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> /*
>> - * register_memory - Setup a sysfs device for a memory block
>> - */
>> -static
>> -int register_memory(struct memory_block *memory, struct mem_section *section)
>> -{
>> - int error;
>> -
>> - memory->sysdev.cls = &memory_sysdev_class;
>> - memory->sysdev.id = __section_nr(section);
>> -
>> - error = sysdev_register(&memory->sysdev);
>> - return error;
>> -}
>> -
>> -static void
>> -unregister_memory(struct memory_block *memory)
>> -{
>> - BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
>> -
>> - /* drop the ref. we got in remove_memory_block() */
>> - kobject_put(&memory->sysdev.kobj);
>> - sysdev_unregister(&memory->sysdev);
>> -}
>> -
>> -/*
>> * use this as the physical section index that this memsection
>> * uses.
>> */
>> @@ -346,6 +321,53 @@
>> sysdev_remove_file(&mem->sysdev, &attr_##attr_name)
>>
>> /*
>> + * register_memory - Setup a sysfs device for a memory block
>> + */
>> +static
>> +int register_memory(struct memory_block *memory, struct mem_section *section,
>> + int nid, enum mem_add_context context)
>> +{
>> + int ret;
>> +
>> + memory->sysdev.cls = &memory_sysdev_class;
>> + memory->sysdev.id = __section_nr(section);
>> +
> Why not block-ID but section-ID ?
Using the beginning section id as the id here makes the splitting of
memory_block's easier since we can assume that the id is unique.
>
> -Kame
>
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: Nathan Fontenot @ 2010-07-13 15:51 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152854.ec1f4d6a.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:28 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:45:25 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch introduces the new 'split' file in each memory sysfs
>> directory and the associated routines needed to handle splitting
>> a directory.
>>
>> Signed-off-by; Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>
> pleae check diff option...
>
>
>> drivers/base/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 98 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:38:09.000000000 -0500
>> @@ -32,6 +32,9 @@
>>
>> static int sections_per_block;
>>
>> +static int register_memory(struct memory_block *, struct mem_section *,
>> + int, enum mem_add_context);
>> +
>> static inline int base_memory_block_id(int section_nr)
>> {
>> return (section_nr / sections_per_block) * sections_per_block;
>> @@ -309,11 +312,100 @@
>> return sprintf(buf, "%d\n", mem->phys_device);
>> }
>>
>> +static void update_memory_block_phys_indexes(struct memory_block *mem)
>> +{
>> + struct list_head *pos;
>> + struct memory_block_section *mbs;
>> + unsigned long min_index = 0xffffffff;
>> + unsigned long max_index = 0;
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->phys_index < min_index)
>> + min_index = mbs->phys_index;
>> +
>> + if (mbs->phys_index > max_index)
>> + max_index = mbs->phys_index;
>> + }
>> +
>> + mem->start_phys_index = min_index;
>> + mem->end_phys_index = max_index;
>> +}
>> +
>> +static ssize_t
>> +store_mem_split_block(struct sys_device *dev, struct sysdev_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct memory_block *mem, *new_mem_blk;
>> + struct memory_block_section *mbs;
>> + struct list_head *pos, *tmp;
>> + struct mem_section *section;
>> + int min_scn_nr = 0;
>> + int max_scn_nr = 0;
>> + int total_scns = 0;
>> + int new_blk_min, new_blk_total;
>> + int ret = -EINVAL;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> +
>> + if (list_is_singular(&mem->sections))
>> + return -EINVAL;
>
> What this means ?
list_is_singular() will return true if there is only one item
on the list. In this case we cannot split a memory_block with
only one memory_block_section.
>
>
>> +
>> + mutex_lock(&mem->state_mutex);
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + total_scns++;
>> +
>> + if (min_scn_nr > mbs->phys_index)
>> + min_scn_nr = mbs->phys_index;
>> +
>> + if (max_scn_nr < mbs->phys_index)
>> + max_scn_nr = mbs->phys_index;
>> + }
>> +
>> + new_mem_blk = kzalloc(sizeof(*new_mem_blk), GFP_KERNEL);
>> + if (!new_mem_blk)
>> + return -ENOMEM;
>> +
>> + mutex_init(&new_mem_blk->state_mutex);
>> + INIT_LIST_HEAD(&new_mem_blk->sections);
>> + new_mem_blk->state = mem->state;
>> +
>> + mutex_lock(&new_mem_blk->state_mutex);
>> +
>> + new_blk_total = total_scns / 2;
>> + new_blk_min = max_scn_nr - new_blk_total + 1;
>> +
>> + section = __nr_to_section(new_blk_min);
>> + ret = register_memory(new_mem_blk, section, 0, HOTPLUG);
>> +
> 'nid' is always 0 ?
Ahh.. good catch. it may not be. I'll look into finding the correct nid.
>
> And for what purpose this interface is ? Does this split memory block into 2 pieces
> of the same size ?? sounds __very__ strange interface to me.
Yes, this splits the memory_block into two blocks of the same size. This was
suggested as something we may want to do. From ppc perspective I am not sure we
would use this.
The split functionality is not required. The main goal of the patch set is to
reduce the number of memory sysfs directories created. From a ppc perspective
the split functionality is not really needed.
>
> If this is necessary, I hope move the whole things to configfs rather than
> something tricky.
>
> Bye.
> -Kame
>
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Nathan Fontenot @ 2010-07-13 15:59 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3C718C.6080402@linux.vnet.ibm.com>
On 07/13/2010 09:00 AM, Brian King wrote:
> On 07/12/2010 10:42 AM, Nathan Fontenot wrote:
>> @@ -123,13 +130,20 @@
>> static ssize_t show_mem_removable(struct sys_device *dev,
>> struct sysdev_attribute *attr, char *buf)
>> {
>> - unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + struct list_head *pos, *tmp;
>> + struct memory_block *mem;
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + struct memory_block_section *mbs;
>> + unsigned long start_pfn;
>> +
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>
> I don't see you deleting anyting from the list in this loop. Why do you need
> to use list_for_each_safe? That won't protect you if someone else is messing
> with the list.
Yes, Kame pointed this out too. I think I'll need to update the patches to
always take the mutex when walking the list and use list_for_each_entry
>
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> return sprintf(buf, "%d\n", ret);
>> }
>>
>
>
>> @@ -238,19 +252,40 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> + struct list_head *pos;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>
> Would it be better here to loop through all the sections and ensure they
> are in the proper state first before starting to change the state of any
> of them? Then you could easily return -EINVAL if one or more is in
> the incorrect state and wouldn't need to the code below.
The code below is needed in cases where the add/remove of one of the
memory_block_sections fails. The code can then return all of the
memory_block_sections in the memory_block to the original state.
>
>> + if (ret) {
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section,
>> + next);
>> +
>> + if (mbs->state == from_state_req)
>> + continue;
>> +
>> + if (memory_block_action(mbs, to_state))
>> + printk(KERN_ERR "Could not re-enable memory "
>> + "section %lx\n", mbs->phys_index);
>> + }
>> }
>>
>> - ret = memory_block_action(mem, to_state);
>> if (!ret)
>> mem->state = to_state;
>>
>> -out:
>> mutex_unlock(&mem->state_mutex);
>> return ret;
>> }
>
>
>> @@ -498,19 +496,97 @@
>>
>> return mem;
>> }
>> +static int add_mem_block_section(struct memory_block *mem,
>> + int section_nr, unsigned long state)
>> +{
>> + struct memory_block_section *mbs;
>> +
>> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
>> + if (!mbs)
>> + return -ENOMEM;
>> +
>> + mbs->phys_index = section_nr;
>> + mbs->state = state;
>> +
>> + list_add(&mbs->next, &mem->sections);
>
> I don't think there is sufficient protection for this list. Don't we
> need to be holding a lock of some sort when adding/deleting/iterating
> through this list?
You're right. we should be holding the mutex.
I think there are a couple other places that I missed with this. I'll fix
it for a v2 of the patches.
>
>> + return 0;
>> +}
>
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 16:02 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279033177.515.16.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Could be a GPU lockup again, possibly due to still using AGP 4x with
> modeset=3D0.
[cut]
> What does the log file contain with modeset=3D1?
We have no message, after the X.org freeze.
messages.log:
[...]
Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
Jul 13 17:13:39 jim kernel: Using PowerMac machine description
(we have rebooted)
In Xorg.0.log there aren't information after the crash, only a right startu=
p.
Maybe I could try to connect via ssh and see if there are some
informations which aren't written to disk...
At this time, I think it isn't a kernel problem, am I right? Also, we
have the same problem (freeze in glxgears or other program using glx)
both from normal user and from root.
Thank you again
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 16:09 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTik154EFPIzMZy5v-Mj6mhWt-hCaFYvLPi5oLWFD@mail.gmail.com>
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote:=20
> 2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
> > What does the log file contain with modeset=3D1?
>=20
> We have no message, after the X.org freeze.
>=20
> messages.log:
> [...]
> Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
> Jul 13 17:13:39 jim kernel: Using PowerMac machine description
>=20
> (we have rebooted)
>=20
> In Xorg.0.log there aren't information after the crash, only a right star=
tup.
Are you looking at the right log file, not the one from the new X server
after the reboot?
Maybe you could post the full dmesg, Xorg.0.log and X server stderr
output (should be captured in the gdm/kdm log file) from trying with
modeset=3D1.
> At this time, I think it isn't a kernel problem, am I right?
With modeset=3D1 it most likely is a kernel (configuration) problem.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 17:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279037396.515.19.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Are you looking at the right log file, not the one from the new X server
> after the reboot?
Yes, I looked to .old, when referring to Xorg.0.log.
> Maybe you could post the full dmesg, Xorg.0.log and X server stderr
> output (should be captured in the gdm/kdm log file) from trying with
> modeset=3D1.
>
>> At this time, I think it isn't a kernel problem, am I right?
>
> With modeset=3D1 it most likely is a kernel (configuration) problem.
So, I've now the acceleration. The main problem was radeon.agpmode,
setting it to -1 (and removing all files in xorg.conf.d related to
radeon) fixes all issue (also the freeze on glxgears). Now I have
~1500 FPS, and I'm fine with it (before I got 100 FPS).
I get the acceleration also with a non-KMS capable kernel, so I think
we got the point. I will add the option to modprobe.conf for archPPC.
I tried a program which use a lot opengl, the only thing I see is
ERROR: GL error 1282
ERROR: Ignoring 1 openGL errors
but the topic-error is fixed.
Thank you.
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 17:22 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikR0HRoBawbUJyS_cEkhEu9Sj6q8hR2F0v6CLDK@mail.gmail.com>
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote:=20
>=20
> So, I've now the acceleration. The main problem was radeon.agpmode,
> setting it to -1 (and removing all files in xorg.conf.d related to
> radeon) fixes all issue (also the freeze on glxgears). Now I have
> ~1500 FPS, and I'm fine with it (before I got 100 FPS).
>=20
> I get the acceleration also with a non-KMS capable kernel, so I think
> we got the point. I will add the option to modprobe.conf for archPPC.
Note that e.g. on my PowerBook agpmode=3D1 works (mostly) stable, and if
AGP works it performs significantly better than PCI.
> I tried a program which use a lot opengl, the only thing I see is
> ERROR: GL error 1282
> ERROR: Ignoring 1 openGL errors
Something the app does causes Mesa to raise a GL_INVALID_OPERATION
error. This may be a bug in the app or in Mesa.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: optimized script [Was: ARM defconfig files]
From: Olof Johansson @ 2010-07-13 18:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Nicolas Pitre, Kevin Hilman, linux-arm-msm, linuxppc-dev,
Linux Kernel Mailing List, Eric Miao, linux-omap, Linus Torvalds,
linux-arm-kernel
In-Reply-To: <20100713080705.GA20978@pengutronix.de>
On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> > Hi
> >
> > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > >> Then all architectures could benefit from it. Having the defconfig
> > > >> files contain only those options which are different from the defaults
> > > >> is certainly more readable, even on x86.
> > > >
> > > > Quite possible. But maintainers would need to be on the lookout of
> > > > people actually using the script, and refusing to apply patches that
> > > > re-introduce the whole big thing.
> > >
> > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > I think we can do the same. After the defconfigs are trimmed, I
> > > certainly won't pick up any more full defconfigs.
> > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > assume they complete in a few days time.
> So Stephen was faster than me. I don't know yet how he optimised my
> script, meanwhile I put some efforts into it, too by just checking lines
> that match "^(# )?CONFIG_".
>
> Find it attached.
>
> I will start to reduce the remaining configs (i.e. all but arm and
> powerpc).
I added just a simple heuristic: If I could remove a line, I attempted
to remove twice the amount next time around (and fall back to 1 if it failed).
I.e. main loop:
i = 0
lines = 1
while i < len(config):
print 'test for %r + %d' % (config[i], lines)
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + lines:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i:i+lines]
lines *= 2
else:
if lines > 1:
lines = 1
else:
i += 1
I didn't measure what the actual improvement was, but I saw a fair amount
of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting
the resulting patch though. :P
While this script is great, it is somewhat painful to run given that it
attempts one config per line. Even on a fast machine that tends to take
a while.
-Olof
^ permalink raw reply
* [PATCH] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 18:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] powerpc:prom Export device tree physical address via proc
From: Timur Tabi @ 2010-07-13 18:55 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1279047011-28989-1-git-send-email-msm@freescale.com>
Matthew McClintock wrote:
> + if (prop)
> + prom_remove_property(node, prop);
> + prop = of_find_property(node, "linux,devietree-end", NULL);
Either the indentation is wrong, or you're missing some braces here.
> + if (prop)
> + prom_remove_property(node, prop);
> +
> + flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
> + flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
> + + initial_boot_params->totalsize;
I think these should be u64, not unsigned long, to ensure support for 64-bit
physical addresses.
^ permalink raw reply
* [PATCH V2] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
Removed unneeded cast, and fixed indentation screwup
arch/powerpc/kernel/prom.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..6a8400e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,46 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = (unsigned long)virt_to_phys(initial_boot_params);
+ flat_dt_end = (unsigned long)virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* [PATCH V3] powerpc:prom Export device tree physical address via proc
From: Matthew McClintock @ 2010-07-13 19:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, Kumar Gala
To build a proper flat device tree for kexec we need to know which
memreserve region was used for the device tree for the currently
running kernel, so we can remove it and replace it with the new
memreserve for the kexec'ed kernel
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
V3: Remove unneeded cast, and fixed indentation screw up
V2: messed up changes
arch/powerpc/kernel/prom.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index fd9359a..79c1f35 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/bootmem.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -911,3 +912,47 @@ static int __init export_flat_device_tree(void)
}
__initcall(export_flat_device_tree);
#endif
+
+#ifdef CONFIG_KEXEC
+static phys_addr_t flat_dt_start;
+static phys_addr_t flat_dt_end;
+
+static struct property flat_dt_start_prop = {
+ .name = "linux,devicetree-start",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_start,
+};
+
+static struct property flat_dt_end_prop = {
+ .name = "linux,devicetree-end",
+ .length = sizeof(phys_addr_t),
+ .value = &flat_dt_end,
+};
+
+static int __init export_flat_device_tree_phys_addr(void)
+{
+ struct property *prop;
+ struct device_node *node;
+
+ node = of_find_node_by_path("/chosen");
+ if (!node)
+ return -ENOENT;
+
+ prop = of_find_property(node, "linux,devicetree-start", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, "linux,devietree-end", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ flat_dt_start = virt_to_phys(initial_boot_params);
+ flat_dt_end = virt_to_phys(initial_boot_params)
+ + initial_boot_params->totalsize;
+ prom_add_property(node, &flat_dt_start_prop);
+ prom_add_property(node, &flat_dt_end_prop);
+
+ return 0;
+}
+__initcall(export_flat_device_tree_phys_addr);
+#endif
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
From: Michal Marek @ 2010-07-13 20:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Andrew Morton, Linus, LKML, Catalin Marinas
In-Reply-To: <20100713114322.57c8b166.sfr@canb.auug.org.au>
On 07/13/2010 03:43 AM, Stephen Rothwell wrote:
> After this change, doing a "make xxx_defconfig" will check first for
> a file called arch/<arch>/configs/Kconfig.xxx and use that to generate
> the .config (effectively starting from an allnoconfig). If that file
> doesn't exist, it will use arch/<ARCH>/configs/xxx_defconfig as now.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> scripts/kconfig/Makefile | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> Hi Linus,
>
> Is this more the direction you want to take?
>
> There are still 2 main problems with is approach:
>
> - there are some config options that are globally and
> unconditionally enabled that some platforms may not want. The only way
> currently to turn them off is to reproduce the config entry with the
> different default. I am not sure if we need a wa to turn them off or to
> just change them to being neede to be selected by those that do want them.
> - we have no way to select options that are neither bool or
> tristate to suitable values. Again the only way to do that currently is
> to reproduce the config entry with a different default value.
Hi Stephen,
how are these Kconfig.xxx files going look like? A list of 'select FOO'
and 'include "Kconfig.other"' statements?
What about adding support for an include statement to the .config file
format and using that in the defconfigs instead? The VARIABLE=VALUE
grammar seems much more suitable for this than the kconfig language.
Michal
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-07-13 22:13 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <582531.52335.qm@web180310.mail.gq1.yahoo.com>
On Mon, 2010-07-12 at 16:55 -0700, David Brownell wrote:
> Please remove all the changes not related to
> this Synopsis IP ...
Could you clarify what is not Synopsis IP related in the patch?
> and make the OTG functionality
> key on the generic OTG symbol, not a DW-specific one.
>
>
Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Thanks,
Fushen
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: Chuck Meade @ 2010-07-13 22:16 UTC (permalink / raw)
To: Fushen Chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <12789766042434-git-send-email-fchen@apm.com>
On 07/12/2010 07:16 PM, Fushen Chen wrote:
> The DWC OTG driver module provides the initialization and cleanup
> entry points for the DWC OTG USB driver.
>
> Signed-off-by: Fushen Chen <fchen@apm.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> ---
This reply is to the patch series, not just this 1/9 patch section.
Fushen, why did you pick and choose which fixes to incorporate from the Denx
tree's version of the dwc_otg driver?
I'm not taking the time here to go through this multipart patch and check that
you incorporated every fix, but I *did* randomly pick one fix that I made to that
driver, to see if you incorporated it, and it appears you did not.
I would have expected that you would have incorporated the fixes that were made
to this driver in the Denx tree.
The one that I checked is in the data toggle error interrupt handling, in
handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It looks
like you left out the fix I made to this logic that averts an interrupt storm.
I assume that since I checked one particular fix, and it was missing from your
patch series, that there are likely more fixes you omitted. Can you explain why
you would leave this out, after Stefan asked you to incorporate the code changes
made in the Denx tree's version of the driver?
Chuck
^ permalink raw reply
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: David Brownell @ 2010-07-13 22:50 UTC (permalink / raw)
To: fushen chen; +Cc: linuxppc-dev, chuck, linux-usb, Mark Miesfeld, gregkh
In-Reply-To: <1279059214.29212.13.camel@localhost.localdomain>
> > and make the OTG functionality
> > key on the generic OTG symbol, not a DW-specific one.
> >
> >
> Use "drivers/usb/otg/otg.c and include/linux/usb/otg.h"?
Maybe; CONFIG_USB_OTG specifically, though
(or whatever that generic symbol is) ...
^ permalink raw reply
* [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:04 UTC (permalink / raw)
To: linuxppc-dev, Nicolas Pitre, Benjamin Herrenschmidt, linux-kbuild,
linux-kernel, linux-arm-kernel, Linus Torvalds, Russell King
Cc: Tony Lindgren, Daniel Walker, Uwe Kleine-König
This is a proof of concept at the moment, but if the corner cases
can be sorted out, then this might be the best way to replace
the defconfig functionality. This patch implements Linus' idea
for using Kconfig fragments to replicate the *_defconfig functionality
Essentially, this patch adds a new <board>_defconfig target that is
processed if a <board>.Kconfig file is present in the $(ARCH)/configs
directory instead of the current <board>_defconfig file. The target
works by passing the $(ARCH)/configs/<board>.Kconfig to Kconfig
instead of the architecture's default $(ARCH)/Kconfig file.
<board>.Kconfig defines new board specific config items (prefixed with
"generateconfig_" which default to 'y' or 'm' and select the options
that the platform cares about. It also then either the architecture
default Kconfig, or another Kconfig fragment that includes the default
one (therefore the fragments can be 'stacked' to include, say, default
options for the architecture, or particular chipset).
This patch includes sample Kconfig fragments for the PowerPC 83xx and
5200 platforms to demonstrate the concept, but it should work in exactly
the same way for ARM or any other architecture. With the sample,
'mpc5200_defconfig', 'mpc83xx_defconfig' and even 'ppc32_defconfig' are
all valid targets (although the ppc32_defconfig won't actually include
any particular board support).
An interesting side effect of this approach is that it can be used to
'overlay' the configuration for a board over top of the existing config.
I went ahead and added the %_oldconfig option to do this which could
be useful for building a kernel that supports multiple boards, or for
adding in a set of debug options.
Another advantage of this approach is that it doesn't immediately
eliminate the old defconfig files so that platforms can be migrated to
this new method one at a time.
Current problems:
- I haven't figured out a way for the fragment to force an option to
be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
This may require changing the syntax.
- It still doesn't resolve dependencies. A solver would help with this.
For the time being I work around the problem by running the generated
config through 'oldconfig' and looking for differences. If the files
differ (ignoring comments and generateconfig_* options) after oldconfig,
then the <board>_defconfig target returns a failure. (but leaves the
new .config intact so the user can resolve it with menuconfig). This
way at least the user is told when a Kconfig fragment is invalid.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/configs/mpc5200.Kconfig | 24 +++++++++++++++++++++
arch/powerpc/configs/mpc83xx.Kconfig | 35 +++++++++++++++++++++++++++++++
arch/powerpc/configs/ppc32.Kconfig | 39 ++++++++++++++++++++++++++++++++++
scripts/kconfig/Makefile | 18 +++++++++++++++-
4 files changed, 115 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/configs/mpc5200.Kconfig
create mode 100644 arch/powerpc/configs/mpc83xx.Kconfig
create mode 100644 arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc5200.Kconfig b/arch/powerpc/configs/mpc5200.Kconfig
new file mode 100644
index 0000000..1281dd1
--- /dev/null
+++ b/arch/powerpc/configs/mpc5200.Kconfig
@@ -0,0 +1,24 @@
+config generateconfig_MPC5200_YES
+ def_bool y
+ select PPC_MPC52xx
+ select PPC_MPC5200_SIMPLE
+ select PPC_EFIKA
+ select PPC_LITE5200
+ select PPC_MEDIA5200
+ select PPC_MPC5200_BUGFIX
+ select PPC_MPC5200_GPIO
+ select PPC_MPC5200_LPBFIFO
+ select PPC_BESTCOMM
+ select SIMPLE_GPIO
+ select SERIAL_MPC52xx
+ select SERIAL_MPC52xx_CONSOLE
+ select MTD
+ select PATA_MPC52xx
+ select SPI_MPC52xx
+ select SPI_MPC52xx_PSC
+ select I2C_MPC
+ select FEC_MPC52xx
+ select LXT_PHY
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/mpc83xx.Kconfig b/arch/powerpc/configs/mpc83xx.Kconfig
new file mode 100644
index 0000000..818fdec
--- /dev/null
+++ b/arch/powerpc/configs/mpc83xx.Kconfig
@@ -0,0 +1,35 @@
+config generateconfig_MPC83xx_YES
+ def_bool y
+ select PPC_83xx
+ select EMBEDDED
+ select MPC831x_RDB
+ select MPC832x_MDS
+ select MPC832x_RDB
+ select MPC834x_MDS
+ select MPC834x_ITX
+ select MPC836x_MDS
+ select MPC836x_RDK
+ select MPC837x_MDS
+ select MPC837x_RDB
+ select SBC834x
+ select ASP834x
+ select QUICC_ENGINE
+ select OE_GPIO
+ select MATH_EMULATION
+ select SATA_FSL
+ select SATA_SIL
+ select MARVELL_PHY
+ select DAVICOM_PHY
+ select VITESSE_PHY
+ select ICPLUS_PHY
+ select FIXED_PHY
+ select FSL_PQ_MDIO
+ select GIANFAR
+ select UCC_GETH
+ select SERIAL_8250
+ select SERIAL_8250_CONSOLE
+ select I2C_MPC
+ select GPIOLIB
+ select WATCHDOG
+
+source arch/powerpc/configs/ppc32.Kconfig
diff --git a/arch/powerpc/configs/ppc32.Kconfig b/arch/powerpc/configs/ppc32.Kconfig
new file mode 100644
index 0000000..66e39f0
--- /dev/null
+++ b/arch/powerpc/configs/ppc32.Kconfig
@@ -0,0 +1,39 @@
+config generateconfig_PPC32_YES
+ def_bool y
+ select EXPERIMENTAL
+ select DEVTMPFS
+ select PPC32
+ select SYSVIPC
+ select BLK_DEV_INITRD
+ select NO_HZ
+ select HIGH_RES_TIMERS
+ select GPIO
+ select SPI
+ select SPI_SPIDEV
+ select I2C
+ select I2C_CHARDEV
+ select USB
+ select NET
+ select SCSI
+ select BLK_DEV_SD
+ select ATA
+ select PACKET
+ select UNIX
+ select INET
+ select IP_MULTICAST
+ select IP_PNP
+ select IP_PNP_DHCP
+ select NETDEVICES
+ select NET_ETHERNET
+ select PROC_DEVICETREE
+ select INOTIFY
+ select TMPFS
+ select NFS_FS
+ select ROOT_NFS
+ select PRINTK_TIME
+
+config generateconfig_PPC32_MODULE
+ def_tristate m
+
+source arch/powerpc/Kconfig
+
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 7ea649d..4e9afd9 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -117,7 +117,23 @@ else
$(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig)
endif
-%_defconfig: $(obj)/conf
+# New-style defconfig using Kconfig fragments
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -D /dev/null arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)sed '/^#/d;/^CONFIG_generateconfig_/d' $(objtree)/.config > $(objtree)/.config-diff1
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig test to make sure it doesn't change
+ $(Q)sed '/^#/d' $(objtree)/.config > $(objtree)/.config-diff2
+ $(Q)diff -u $(objtree)/.config-diff1 $(objtree)/.config-diff2
+
+# This is kind of useful. The new-style defconfig using Kconfig fragments
+# can also be used to successively pull in the options a defconfig cares
+# about overtop of the current config.
+%_oldconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig
+ $(Q)$< -o arch/$(SRCARCH)/configs/$*.Kconfig
+ $(Q)$< -o $(Kconfig) > /dev/null # oldconfig to clear out the temporary items
+
+# Old-style defconfig using full (or trimmed) .config files.
+%_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%_defconfig
$(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig)
# Help text used by make help
^ permalink raw reply related
* Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
From: Feng Kan @ 2010-07-13 23:02 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-dev, linux-usb, Mark Miesfeld, gregkh, Fushen Chen
In-Reply-To: <4C3CE5BA.5060302@ThePTRGroup.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Chuck:
Thanks for the information. Sorry that we missed the patch. It was not done
out of specific reason.
As you have commented, it is a very large patch with alot of changes. We
wanted to submit
the patch to make sure the fundamental structure of the driver align with
the kernel. Once that
is in place, additional patch will be easier. Fushen will make sure this
change is in place on
the next submission.
Thanks
Feng Kan
On Tue, Jul 13, 2010 at 3:16 PM, Chuck Meade <chuck@theptrgroup.com> wrote:
> On 07/12/2010 07:16 PM, Fushen Chen wrote:
> > The DWC OTG driver module provides the initialization and cleanup
> > entry points for the DWC OTG USB driver.
> >
> > Signed-off-by: Fushen Chen <fchen@apm.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
> > ---
>
> This reply is to the patch series, not just this 1/9 patch section.
>
> Fushen, why did you pick and choose which fixes to incorporate from the
> Denx
> tree's version of the dwc_otg driver?
>
> I'm not taking the time here to go through this multipart patch and check
> that
> you incorporated every fix, but I *did* randomly pick one fix that I made
> to that
> driver, to see if you incorporated it, and it appears you did not.
> I would have expected that you would have incorporated the fixes that were
> made
> to this driver in the Denx tree.
>
> The one that I checked is in the data toggle error interrupt handling, in
> handle_hc_chhltd_intr_dma() (see your 5/9 email in this patch series). It
> looks
> like you left out the fix I made to this logic that averts an interrupt
> storm.
>
> I assume that since I checked one particular fix, and it was missing from
> your
> patch series, that there are likely more fixes you omitted. Can you
> explain why
> you would leave this out, after Stefan asked you to incorporate the code
> changes
> made in the Denx tree's version of the driver?
>
> Chuck
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
Feng Kan
[-- Attachment #2: Type: text/html, Size: 2865 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:11 UTC (permalink / raw)
To: linuxppc-dev, Nicolas Pitre, Benjamin Herrenschmidt, linux-kbuild,
linux-kernel, linux-arm-kernel, Linus Torvalds, Russell King
Cc: Tony Lindgren, Daniel Walker, Uwe Kleine-König
In-Reply-To: <20100713230352.6781.18644.stgit@angua>
Typo correction:
2010/7/13 Grant Likely <grant.likely@secretlab.ca>:
[...]
> <board>.Kconfig defines new board specific config items (prefixed with
> "generateconfig_" which default to 'y' or 'm' and select the options
> that the platform cares about. =A0It also then either the architecture
s/either the/either includes the/
> default Kconfig, or another Kconfig fragment that includes the default
> one (therefore the fragments can be 'stacked' to include, say, default
> options for the architecture, or particular chipset).
[...]
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Grant Likely @ 2010-07-13 23:21 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1279062881.4609.34.camel@c-dwalke-linux.qualcomm.com>
On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wro=
te:
> On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
>
>> - I haven't figured out a way for the fragment to force an option to
>> =A0 be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=3D16".
>> =A0 This may require changing the syntax.
>> - It still doesn't resolve dependencies. =A0A solver would help with thi=
s.
>> =A0 For the time being I work around the problem by running the generate=
d
>> =A0 config through 'oldconfig' and looking for differences. =A0If the fi=
les
>> =A0 differ (ignoring comments and generateconfig_* options) after oldcon=
fig,
>> =A0 then the <board>_defconfig target returns a failure. =A0(but leaves =
the
>> =A0 new .config intact so the user can resolve it with menuconfig). =A0T=
his
>> =A0 way at least the user is told when a Kconfig fragment is invalid.
>
> The solver would fix the whole issues with the defconfigs , we wouldn't
> need this Kconfig change .. From my perspective we shouldn't be fooling
> around with anything but the solver approach ..
The solver would complement Kconfig fragments, but it doesn't
implement all the functionality. For instance, it doesn't help a
board config picking up a bunch of options from an SoC or Architecture
config file, especially things that are developer/maintainer choices
as opposed to hard requirements). Solver on its own is an incremental
improvement over what we currently have, but it doesn't solve the
whole problem.
> It just doesn't feel like Kconfig was meant to do this, it feel like
> somewhat of an abuse ..
Why? It uses the Kconfig language itself to specify additional
constraints on the final configuration. Seems to be the essence of
elegance to me. :-)
g.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Daniel Walker @ 2010-07-13 23:14 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20100713230352.6781.18644.stgit@angua>
On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> - I haven't figured out a way for the fragment to force an option to
> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> This may require changing the syntax.
> - It still doesn't resolve dependencies. A solver would help with this.
> For the time being I work around the problem by running the generated
> config through 'oldconfig' and looking for differences. If the files
> differ (ignoring comments and generateconfig_* options) after oldconfig,
> then the <board>_defconfig target returns a failure. (but leaves the
> new .config intact so the user can resolve it with menuconfig). This
> way at least the user is told when a Kconfig fragment is invalid.
The solver would fix the whole issues with the defconfigs , we wouldn't
need this Kconfig change .. From my perspective we shouldn't be fooling
around with anything but the solver approach ..
It just doesn't feel like Kconfig was meant to do this, it feel like
somewhat of an abuse ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Daniel Walker @ 2010-07-13 23:33 UTC (permalink / raw)
To: Grant Likely
Cc: linux-kbuild, Tony Lindgren, Nicolas Pitre, linux-kernel,
Linus Torvalds, Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <AANLkTin69tN3NQHD2wvkA0G-lj3f9tSZEnhzdyJdTh9m@mail.gmail.com>
On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > On Tue, 2010-07-13 at 17:04 -0600, Grant Likely wrote:
> >
> >> - I haven't figured out a way for the fragment to force an option to
> >> be "n", or to set a value, for example "CONFIG_LOG_BUF_SHIFT=16".
> >> This may require changing the syntax.
> >> - It still doesn't resolve dependencies. A solver would help with this.
> >> For the time being I work around the problem by running the generated
> >> config through 'oldconfig' and looking for differences. If the files
> >> differ (ignoring comments and generateconfig_* options) after oldconfig,
> >> then the <board>_defconfig target returns a failure. (but leaves the
> >> new .config intact so the user can resolve it with menuconfig). This
> >> way at least the user is told when a Kconfig fragment is invalid.
> >
> > The solver would fix the whole issues with the defconfigs , we wouldn't
> > need this Kconfig change .. From my perspective we shouldn't be fooling
> > around with anything but the solver approach ..
>
> The solver would complement Kconfig fragments, but it doesn't
> implement all the functionality. For instance, it doesn't help a
> board config picking up a bunch of options from an SoC or Architecture
> config file, especially things that are developer/maintainer choices
> as opposed to hard requirements). Solver on its own is an incremental
> improvement over what we currently have, but it doesn't solve the
> whole problem.
I don't understand what your saying here.. Imagine a defconfig that you
have now only drastically smaller. The solver picks the stuff that
doesn't exist already in the defconfig. You would just apply the solver
to whatever is in the defconfig.
Then that allows us to keep the current defconfig format without mass
converting to something else. It's would also be built on a solver that
helps with other issues within Kconfig.
> > It just doesn't feel like Kconfig was meant to do this, it feel like
> > somewhat of an abuse ..
>
> Why? It uses the Kconfig language itself to specify additional
> constraints on the final configuration. Seems to be the essence of
> elegance to me. :-)
To my mind the only problem with the current defconfig formatting is the
size of the files. If those files are 5-10 lines instead of 2000 lines,
then I think the readability problem isn't really an issue any more..
The point of using Kconfig was the readability..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
From: Nicolas Pitre @ 2010-07-14 0:07 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kbuild, Tony Lindgren, linux-kernel, Linus Torvalds,
Russell King, Uwe Kleine-König, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1279064008.4609.48.camel@c-dwalke-linux.qualcomm.com>
On Tue, 13 Jul 2010, Daniel Walker wrote:
> On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote:
> > On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker <dwalker@codeaurora.org> wrote:
> > > It just doesn't feel like Kconfig was meant to do this, it feel like
> > > somewhat of an abuse ..
> >
> > Why? It uses the Kconfig language itself to specify additional
> > constraints on the final configuration. Seems to be the essence of
> > elegance to me. :-)
>
> To my mind the only problem with the current defconfig formatting is the
> size of the files. If those files are 5-10 lines instead of 2000 lines,
> then I think the readability problem isn't really an issue any more..
That's one issue indeed.
But there is another issue that is somewhat related, which is to be able
to categorize config options.
Currently the defconfig files carry information about the proper driver
to enable in order to support devices soldered on the board and
therefore which are not "optional". That might be a particular RTC
chip, or a particular ethernet block integrated into a SOC, etc. Of
course we want to preserve the ability to disable support for those
things, but by default people want to have all the right drivers
selected for all the built-in hardware when selecting a target
machine/board without having to dig into a datasheet for that target.
The defconfig files also carry config options that are totally
arbitrary. What type of filesystem, what kind of network protocol, what
USB device drivers (not host controller driver), what amount of
debugging options, all those are unrelated to the actual hardware and
may vary from one user to another.
Furthermore, in order to reduce the number of defconfig files, we tried
to combine as many targets into a single kernel image. That increases
build test coverage with fewer builds which is good, but then the info
about specific drivers required for a specific target but not for
another target in the same defconfig is now lost. It is therefore quite
hard to produce a highly optimized configuration for a single target
without doing some digging again.
So it is really in the Kconfig file that all those hardware specific
options can be expressed in a clear and readable way. When BOARD_XYZ is
selected and STD_CONFIG is selected, then automatically select RTC_FOO,
select ETH_BAR, select LED_BAZ, etc. Of course we would want required
dependencies to be automatically selected as well.
But all the rest is arbitrary and could be part of common shared
profiles or the like in defconfig format.
Nicolas
^ permalink raw reply
* Re: optimized script [Was: ARM defconfig files]
From: Nicolas Pitre @ 2010-07-13 23:39 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Kevin Hilman, linux-arm-msm, linuxppc-dev,
Linux Kernel Mailing List, Eric Miao, Uwe Kleine-König,
linux-omap, Linus Torvalds, linux-arm-kernel
In-Reply-To: <20100713180402.GA1422@lixom.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2203 bytes --]
On Tue, 13 Jul 2010, Olof Johansson wrote:
> On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> > > Hi
> > >
> > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > > >> Then all architectures could benefit from it. Having the defconfig
> > > > >> files contain only those options which are different from the defaults
> > > > >> is certainly more readable, even on x86.
> > > > >
> > > > > Quite possible. But maintainers would need to be on the lookout of
> > > > > people actually using the script, and refusing to apply patches that
> > > > > re-introduce the whole big thing.
> > > >
> > > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > > I think we can do the same. After the defconfigs are trimmed, I
> > > > certainly won't pick up any more full defconfigs.
> > > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > > assume they complete in a few days time.
> > So Stephen was faster than me. I don't know yet how he optimised my
> > script, meanwhile I put some efforts into it, too by just checking lines
> > that match "^(# )?CONFIG_".
> >
> > Find it attached.
> >
> > I will start to reduce the remaining configs (i.e. all but arm and
> > powerpc).
>
> I added just a simple heuristic: If I could remove a line, I attempted
> to remove twice the amount next time around (and fall back to 1 if it failed).
>
[...]
>
> While this script is great, it is somewhat painful to run given that it
> attempts one config per line. Even on a fast machine that tends to take
> a while.
The optimal solution is to add that .config reduction ability straight
into the Kconfig parser (scripts/kconfig/*). There you can find out
right away what are the non default state for each config option without
actually trying them out one by one.
Nicolas
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: KAMEZAWA Hiroyuki @ 2010-07-14 0:35 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel, Dave Hansen
In-Reply-To: <4C3C8B9E.7000208@austin.ibm.com>
On Tue, 13 Jul 2010 10:51:58 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> >
> > And for what purpose this interface is ? Does this split memory block into 2 pieces
> > of the same size ?? sounds __very__ strange interface to me.
>
> Yes, this splits the memory_block into two blocks of the same size. This was
> suggested as something we may want to do. From ppc perspective I am not sure we
> would use this.
>
> The split functionality is not required. The main goal of the patch set is to
> reduce the number of memory sysfs directories created. From a ppc perspective
> the split functionality is not really needed.
>
Okay, this is an offer from me.
1. I think you can add an boot option as "don't create memory sysfs".
please do.
2. I'd like to write a configfs module for handling memory hotplug even when
sysfs directroy is not created.
Because configfs support rmdir/mkdir, the user (ppc's daemon?) has to do
When offlining section X.
# insmod configfs_memory.ko
# mount -t configfs none /configfs
# mkdir /configfs/memoryX
# echo offline > /configfs/memoryX/state
# rmdir /configfs/memoryX
And making this operation as the default bahavior for all arch's memory hotplug may
be better...
Dave, how do you think ? Because ppc guys uses "probe" interface already,
this can be handled... no ?
One problem is that I don't have enough knowledge about configfs..it seems complex.
Thanks,
-Kame
^ 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