[PATCH] powerpc: reduce the size of the defconfigs
This uses Uwe's script (modified by Olof Johansson to speed it up somewhat) to reduce the size of all the powerpc defconfigs. The resulting files have been verified to produce the same .config files by generating them before and after this patch and comparing the results. Signed-off-by: Stephen Rothwell --- arch/powerpc/configs/40x/acadia_defconfig | 1002 -- arch/powerpc/configs/40x/ep405_defconfig | 1211 arch/powerpc/configs/40x/hcu4_defconfig | 1064 -- arch/powerpc/configs/40x/kilauea_defconfig| 1197 --- arch/powerpc/configs/40x/makalu_defconfig | 1005 -- arch/powerpc/configs/40x/virtex_defconfig | 1105 --- arch/powerpc/configs/40x/walnut_defconfig | 1089 -- arch/powerpc/configs/44x/arches_defconfig | 1059 -- arch/powerpc/configs/44x/bamboo_defconfig | 1020 -- arch/powerpc/configs/44x/canyonlands_defconfig| 1263 arch/powerpc/configs/44x/ebony_defconfig | 1103 --- arch/powerpc/configs/44x/eiger_defconfig | 1177 --- arch/powerpc/configs/44x/icon_defconfig | 1335 - arch/powerpc/configs/44x/iss476-smp_defconfig | 938 - arch/powerpc/configs/44x/katmai_defconfig | 1088 -- arch/powerpc/configs/44x/rainier_defconfig| 1090 -- arch/powerpc/configs/44x/redwood_defconfig| 1168 --- arch/powerpc/configs/44x/sam440ep_defconfig | 1319 - arch/powerpc/configs/44x/sequoia_defconfig| --- arch/powerpc/configs/44x/taishan_defconfig| 1097 --- arch/powerpc/configs/44x/virtex5_defconfig| --- arch/powerpc/configs/44x/warp_defconfig | 1389 - arch/powerpc/configs/52xx/cm5200_defconfig| 1232 arch/powerpc/configs/52xx/lite5200b_defconfig | 1257 arch/powerpc/configs/52xx/motionpro_defconfig | 1265 arch/powerpc/configs/52xx/pcm030_defconfig| 1219 arch/powerpc/configs/52xx/tqm5200_defconfig | 1367 - arch/powerpc/configs/83xx/asp8347_defconfig | 1432 -- arch/powerpc/configs/83xx/kmeter1_defconfig | 927 - arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1729 arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1798 - arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 1328 - arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 1475 -- arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1567 --- arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 1453 -- arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 1262 arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 1403 - arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1304 arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 1333 - arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1471 -- arch/powerpc/configs/83xx/sbc834x_defconfig | 1398 - arch/powerpc/configs/85xx/ksi8560_defconfig | 1119 --- arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 992 -- arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 1139 --- arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 1155 --- arch/powerpc/configs/85xx/sbc8548_defconfig | 1001 -- arch/powerpc/configs/85xx/sbc8560_defconfig | 1029 -- arch/powerpc/configs/85xx/socrates_defconfig | 1645 arch/powerpc/configs/85xx/stx_gp3_defconfig | 1528 -- arch/powerpc/configs/85xx/tqm8540_defconfig | 1318 - arch/powerpc/configs/85xx/tqm8541_defconfig | 1364 - arch/powerpc/configs/85xx/tqm8548_defconfig | 1355 +- arch/powerpc/configs/85xx/tqm8555_defconfig | 1364 - arch/powerpc/configs/85xx/tqm8560_defconfig | 1364 - arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1786 - arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1736 arch/powerpc/configs/86xx/gef_sbc310_defconfig| 1625 --- arch/powerpc/configs/86xx/gef_sbc610_defconfig| 1819 - arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1634 --- arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 1640 arch/powerpc/configs/86xx/sbc8641d_defconfig | 1432 -- arch/powerpc/configs/adder875_defconfig | 913 - arch/powerpc/configs/amigaone_defconfig | 1490 -- arch/powerpc/configs/c2k_defconfig| 1608 --- arch/powerpc/configs/cell_defconfig | 1314 + arch/powerpc/configs/celleb_defconfig
Re: [PATCH] powerpc: reduce the size of the defconfigs
On Tue, Jul 13, 2010 at 05:09:45PM +1000, Stephen Rothwell wrote: > This uses Uwe's script (modified by Olof Johansson to speed it up > somewhat) to reduce the size of all the powerpc defconfigs. The resulting IMHO we should add the script to the source, too. And if it's only for me to see Olof's optimisation. :-) > files have been verified to produce the same .config files by generating > them before and after this patch and comparing the results. > > Signed-off-by: Stephen Rothwell > --- > 100 files changed, 51 insertions(+), 133815 deletions(-) Nice. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
optimized script [Was: ARM defconfig files]
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
> > wrote:
> > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre 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).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-König
import getopt
import re
import os
import subprocess
import sys
# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'
re_interesting = re.compile(r'^(# )?CONFIG_')
opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src='])
src = ''
arch = 'arm'
for o, a in opts:
if o == '--arch':
arch = a
elif o == '--src':
src = a
configdir = os.path.join(src, 'arch', arch, 'configs')
def all_defconfigs():
lc = len(configdir)
for root, dirs, files in os.walk(configdir):
root = root[lc + 1:]
for f in filter(lambda s: s.endswith('_defconfig'), files):
yield os.path.join(root, f)
if not args:
args = all_defconfigs()
for target in args:
defconfig_src = os.path.join(configdir, target)
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
origconfig = list(open('.config'))
config = list(origconfig)
config_size = os.stat('.config').st_size
i = 0
while i < len(config):
mo = re_interesting.match(config[i])
if mo:
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + 1:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and
list(open('.config')) == origconfig:
print '-%s' % config[i][:-1]
del config[i]
else:
print ' %s' % config[i][:-1]
i += 1
else:
del config[i]
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config)
defconfig.close()
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: section .data..init_task
On Mon, Jul 12, 2010 at 08:34:35PM -0400, Sean MacLennan wrote:
> On Mon, 28 Jun 2010 00:59:00 -0400
> Sean MacLennan wrote:
>
> > Anybody else seeing these messages?
> >
> > ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> > overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> > section .data..init_task lma 0xc03a2000 overlaps previous sections
> > ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000
> > overlaps previous sections
> >
> > Or does anybody know what they mean? They started showing up in
> > 2.6.35.
> >
> > Very easy to reproduce, so don't hesitate to ask for more info.
>
> I had a bit of time, so I tracked this down. This patch seems to be
> the culprit: http://lkml.org/lkml/2010/2/19/366
>
> Specifically, this code:
>
> /* The initial task and kernel stack */
> - .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
> - INIT_TASK_DATA(THREAD_SIZE)
> - }
> + INIT_TASK_DATA_SECTION(THREAD_SIZE)
>
> If I change it back to:
>
> /* The initial task and kernel stack */
> .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {
> INIT_TASK_DATA(THREAD_SIZE)
> }
>
> not only do the warnings go away, but the kernel now boots again!
It looks like a missing AT() in the output section.
The following patch should also fix it.
Please test and let us know.
Thanks,
Sam
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 48c5299..3c4bf03 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
*/
#define INIT_TASK_DATA_SECTION(align) \
. = ALIGN(align); \
- .data..init_task : {\
+ .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
INIT_TASK_DATA(align) \
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[
>From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg
Date: Tue, 13 Jul 2010 11:39:42 +0200
Subject: [PATCH] vmlinux.lds: fix .data..init_task output section (fix popwerpc
boot)
The .data..init_task output section was missing
a load offset causing a popwerpc target to fail to boot.
Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().
There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.
Fix INIT_TASK_DATA_SECTION() to specify load offset like
all other output sections.
Reported-by: Sean MacLennan
Signed-off-by: Sam Ravnborg
---
On the assumption that Sean reports that it fixes
the warnings/boot issue here is a real patch.
Ben - will you take it via the popwerpc tree
or shall I ask Michal to take it via kbuild?
Sam
include/asm-generic/vmlinux.lds.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 48c5299..cdfff74 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
*/
#define INIT_TASK_DATA_SECTION(align) \
. = ALIGN(align); \
- .data..init_task : {\
+ .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
INIT_TASK_DATA(align) \
}
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: reduce the size of the defconfigs
Uwe Kleine-König wrote: > On Tue, Jul 13, 2010 at 05:09:45PM +1000, Stephen Rothwell wrote: > >> This uses Uwe's script (modified by Olof Johansson to speed it up >> somewhat) to reduce the size of all the powerpc defconfigs. The resulting >> > IMHO we should add the script to the source, too. And if it's only for > me to see Olof's optimisation. :-) > > As the person who introduced the gef_* PPC defconfigs to the kernel (I understood this to be best practice), I'm happy to go along with whatever - as long as I can build a bootable kernel from the mainline kernel. I think I understand Linus' wish not to see all the defconfig churn (I get fed up diffing defconfigs, just to read through loads of additions and removals of undef'ed entires from just the few configs I'm interested in). I assume I'm not alone among those attempting to add board support to the mainline kernel in not being able to keep up with the LKML mailing list and therefore have missed most of this discussion (think I've managed to read some of it now). I would very much appreciate some documentation / guidance on how to use this script - preferably provided as a comment in the head of the script or/and some pointers in "Documentation/". Martyn >> files have been verified to produce the same .config files by generating >> them before and after this patch and comparing the results. >> >> Signed-off-by: Stephen Rothwell >> --- >> 100 files changed, 51 insertions(+), 133815 deletions(-) >> > Nice. > > Best regards > Uwe > > -- Martyn Welch (Principal Software Engineer) | Registered in England and GE Intelligent Platforms | Wales (3828642) at 100 T +44(0)127322748| Barbirolli Square, Manchester, E martyn.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
High process latencies due to MPC5200 FEC hard- soft-irq processing
Hello, we realized, that multiple ping floods (ping -f) can cause very large high-priority process latencies (up to a many seconds) on a MPC5200 PowerPC system with FEC NAPI support. The latencies are measured with # cyclictest -p 80 -n The problem is that processing of the ICMP pakets in the Hard-Irq and Soft-IRQ context can last for a long time without returning to the scheduler. Reducing MAX_SOFTIRQ_RESTART from 10 to 2 helps - the latency goes down to 35 ms with 2 "ping -f" - but it's not a configurable parameter, even if it somehow depends on the CPU power. And using the -rt patches seems overkill to me. Any other ideas or comments on how to get rid of such high process latencies? Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] Split the memory_block structure
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.
>
> - 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.
> + 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?
> + return 0;
> +}
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
2.6.35-rc4 ppc crash when loading radeon modeset=1
Hello to all. Sorry if these aren't right place, please point me to the right direction if you can :) When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried to setup KMS acceleration for radeon based machine. We have removed radeonfb, and all others framebuffer driver, and added fbcon and KMS enabled by default for radeon driver. With a clean start, the screen freeze, when the control pass from yaboot to kernel. If we start with video=fbcon (or video=radeondrmfb), we could reach the loading modules point, but after the loading of radeon, the screen goes black, without any log information. Loading kernel with video=fbcon radeon.modeset=0 allow us to reach the end of init stage, and we could load X.org. In this case, acceleration is disabled. If we log out and do the following command: modprobe -r radeon drm modprobe drm debug=1 modprobe radeon modeset=1 The screen goes black, but at next boot we have found the logs. Any hint? System information: Xorg server: 1.8.1 xf86-video-ati 6.13.0 ati-dri 7.8.1 mesa 7.8.1 linux 2.6.35-rc4-00131-ge467e10 There are logs (most relevant part): [...] Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal Jul 13 15:29:50 jim kernel: Machine check in kernel mode. Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer error ack signal [] Jul 13 15:31:28 jim kernel: [drm] Module unloaded Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810 Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled. Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting (RV350 0x1002:0x4E50). Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB000 Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536 Jul 13 15:31:39 jim kernel: [drm] Using generic clock info Jul 13 15:31:39 jim kernel: agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: GTT: 256M 0x - 0x0FFF Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using max accessible memory Jul 13 15:31:39 jim kernel: radeon :00:10.0: VRAM: 64M 0xB800 - 0xBBFF (64M used) Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized. Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics memory: 384990 kiB. Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics memory: 516062 kiB. Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator. Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready. Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready. Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x0001 last fence id 0x) Jul 13 15:31:40 jim kernel: NIP: f260fda4 LR: f260fda4 CTR: 0001 Jul 13 15:31:40 jim kernel: REGS: ef3a3b90 TRAP: 0700 Not tainted (2.6.35-rc4-NAT-00131-ge467e10) Jul 13 15:31:40 jim kernel: MSR: 00029032 CR: 22822484 XER: 2000 Jul 13 15:31:40 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000 Jul 13 15:31:40 jim kernel: GPR00: f260fda4 ef3a3c40 eedb9ac0 0040 416d5d8c c04db984 416d5d09 Jul 13 15:31:40 jim kernel: GPR08: 416d5d8c 0001 000a 22822482 100238a8 Jul 13 15:31:40 jim kernel: GPR16: 007d c04a f26a1d54 0001 ef3a2000 Jul 13 15:31:40 jim kernel: GPR24: c005f328 ef3a3c54 eed386cc ef3a3c48 eed38000 ef085d40 Jul 13 15:31:40 jim kernel: NIP [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] Jul 13 15:31:40 jim kernel: LR [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] Jul 13 15:31:40 jim kernel: Call Trace: Jul 13 15:31:40 jim kernel: [ef3a3c40] [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon] (unreliable) Jul 13 15:31:40 jim kernel: [ef3a3cb0] [f2638234] r100_ib_test+0x158/0x280 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3ce0] [f26383a4] r100_ib_init+0x28/0xc8 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3cf0] [f263f65c] r300_startup+0xd4/0x1e4 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon] Jul 13 15:31:40 jim kernel: [ef3a3d10] [f25fc514] radeon_device_init+0x2b0/0x418 [radeon] Jul 13 15:31:40
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:03 +0200, jjDaNiMoTh wrote: > > When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried > to setup KMS acceleration for radeon based machine. > We have removed radeonfb, and all others framebuffer driver, and added > fbcon and KMS enabled by default for radeon driver. > > With a clean start, the screen freeze, when the control pass from > yaboot to kernel. > > If we start with video=fbcon (or video=radeondrmfb), we could reach > the loading modules point, [...] Which framebuffer device (if any) is it trying to initialize otherwise? OFfb? The first paragraph above implies none, but then I'm not sure why the video= parameters would make any difference. > Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810 > Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled. > Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting > (RV350 0x1002:0x4E50). > Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB000 > Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536 > Jul 13 15:31:39 jim kernel: [drm] Using generic clock info > Jul 13 15:31:39 jim kernel: agpgart-uninorth :00:0b.0: putting AGP > V2 device into 4x mode > Jul 13 15:31:39 jim kernel: radeon :00:10.0: putting AGP V2 device > into 4x mode > Jul 13 15:31:39 jim kernel: radeon :00:10.0: GTT: 256M 0x > - 0x0FFF > Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using > max accessible memory > Jul 13 15:31:39 jim kernel: radeon :00:10.0: VRAM: 64M 0xB800 > - 0xBBFF (64M used) > Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized. > Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M > Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR > Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics > memory: 384990 kiB. > Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics > memory: 516062 kiB. > Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator. > Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready > Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready. > Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. > Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode > Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x > Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs > Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready. So far, so good. > Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x0001 last > fence id 0x) The GPU locks up, and things go downhill from there... Does KMS work better with radeon.agpmode=1 (or 2 or -1)? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
Hey all-
About 2 years ago now, I sent this patch upstream to allow makedumpfile
to properly filter cores on ppc64:
http://www.mail-archive.com/ke...@lists.infradead.org/msg02426.html
It got acks from the kexec folks so I pulled it into RHEL, but I never checked
back here to make sure it ever made it in, which apparently it didn't. It still
needs to be included, so I'm reposting it here, making sure to copy all the ppc
folks this time. I've retested it on the latest linus kernel and it works fine,
allowing makedumpfile to find all the symbols it needs to properly strip a
vmcore on ppc64.
Neil
Signed-off-by: Neil Horman
machine_kexec.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..0df7031 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -45,6 +45,18 @@ void machine_kexec_cleanup(struct kimage *image)
ppc_md.machine_kexec_cleanup(image);
}
+void arch_crash_save_vmcoreinfo(void)
+{
+
+#ifdef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(node_data);
+ VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
+#endif
+#ifndef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(contig_page_data);
+#endif
+}
+
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer :
[cut]
> Which framebuffer device (if any) is it trying to initialize otherwise?
> OFfb? The first paragraph above implies none, but then I'm not sure why
> the video= parameters would make any difference.
We tried and with 2.6.35-rc4 we could boot without video=. First good news :)
[cut]
> Does KMS work better with radeon.agpmode=1 (or 2 or -1)?
with radeon.agpmode=-1, we could start X server (no black screen),
with both radeon.modeset={0,1}. In all cases, Xorg works fine, except
when we try to load an OpenGL application (like glxgears), Xorg
freeze, we could move only the mouse, we couldn't switch to a backup
console. Same situations with glxgears in both modeset=0 and =1. In
the log (Xorg.0.log) we have found:
[.. other xorg log, no EE only WW]
[65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
[65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
[65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
[65.249] Unhandled monitor type 0
[65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
[ 137.813] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[ 137.813]
Backtrace:
[ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
[ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
[ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
[ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
[ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
(0xf38+0x3d88) [0xf383d88]
[ 137.814] 5: /usr/bin/X (0x1000+0x68784) [0x10068784]
[ 137.814] 6: /usr/bin/X (0x1000+0x11a7e4) [0x1011a7e4]
[ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
[ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x48534) [0xf43d534]
[ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
[ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
[ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x46944) [0xf43b944]
[ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x64d8c) [0xf459d8c]
[ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x40f78) [0xf970f78]
[ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x44be4) [0xf974be4]
[ 137.814] 15: /usr/bin/X (0x1000+0x34a24) [0x10034a24]
[ 137.815] 16: /usr/bin/X (0x1000+0x18bc4) [0x10018bc4]
[ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
[ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Many thanks
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:51 +0200, jjDaNiMoTh wrote:
> 2010/7/13 Michel Dänzer :
> > Does KMS work better with radeon.agpmode=1 (or 2 or -1)?
>
> with radeon.agpmode=-1, we could start X server (no black screen),
> with both radeon.modeset={0,1}.
Note that radeon.agpmode is only effective with radeon.modeset=1,
otherwise you need to use Option "AGPMode" in xorg.conf (and vice
versa).
> In all cases, Xorg works fine, except when we try to load an OpenGL
> application (like glxgears), Xorg freeze, we could move only the
> mouse, we couldn't switch to a backup console.
Could be a GPU lockup again, possibly due to still using AGP 4x with
modeset=0.
> Same situations with glxgears in both modeset=0 and =1. In the log
> (Xorg.0.log) we have found:
>
> [.. other xorg log, no EE only WW]
> [65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
> [65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
> [65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
> [65.249] Unhandled monitor type 0
> [65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
> [ 137.813] [mi] EQ overflowing. The server is probably stuck in an
> infinite loop.
> [ 137.813]
> Backtrace:
> [ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
> [ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
> [ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
> [ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
> [ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
> (0xf38+0x3d88) [0xf383d88]
> [ 137.814] 5: /usr/bin/X (0x1000+0x68784) [0x10068784]
> [ 137.814] 6: /usr/bin/X (0x1000+0x11a7e4) [0x1011a7e4]
> [ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
> [ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x48534) [0xf43d534]
> [ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
> [ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
> [ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x46944) [0xf43b944]
> [ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x64d8c) [0xf459d8c]
> [ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf93+0x40f78) [0xf970f78]
> [ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf93+0x44be4) [0xf974be4]
> [ 137.814] 15: /usr/bin/X (0x1000+0x34a24) [0x10034a24]
> [ 137.815] 16: /usr/bin/X (0x1000+0x18bc4) [0x10018bc4]
> [ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
> [ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
What does the log file contain with modeset=1?
> Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Shouldn't be necessary.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: section .data..init_task
On Tue, 13 Jul 2010 10:54:19 +0200 Sam Ravnborg wrote: > It looks like a missing AT() in the output section. > The following patch should also fix it. > > Please test and let us know. > > Thanks, > Sam Applied the patch and it solves the problem. Thanks. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: section .data..init_task
On Tue, Jul 13, 2010 at 11:26:10AM -0400, Sean MacLennan wrote: > On Tue, 13 Jul 2010 10:54:19 +0200 > Sam Ravnborg wrote: > > > It looks like a missing AT() in the output section. > > The following patch should also fix it. > > > > Please test and let us know. > > > > Thanks, > > Sam > > Applied the patch and it solves the problem. Thanks. Thanks for the quick feedback! Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] Split the memory_block structure
Thanks for the review, answers below...
-Nathan
On 07/13/2010 01:18 AM, KAMEZAWA Hiroyuki wrote:
>
> plz cc linux-mm in the next time...
> And please incudes updates for Documentation/memory-hotplug.txt.
>
will do.
>
> On Mon, 12 Jul 2010 10:42:06 -0500
> Nathan Fontenot wrote:
>
>> This patch splits the memory_block struct into a memory_block
>> struct to cover each sysfs directory and a new memory_block_section
>> struct for each memory section covered by the sysfs directory.
>>
>> This also updates the routine handling memory_block creation
>> and manipulation to use these updated structures.
>>
>
> Could you clarify the number of memory_block_section per memory_block ?
The default number of memory_block_sections per memory block is 1. The
memory_block_size() routine (defined as __weak) sets the size of the
memory block, and thus the number of memory_block_sections.
The current view of memory in sysfs where each directory covers a single
memory section should still hold for everyone, unless a arch defines
their own memory_section_size routine to alter the behavior.
>
>
>> Signed -off-by: Nathan Fontenot
>> ---
>> drivers/base/memory.c | 228
>> +++--
>> include/linux/memory.h | 11 +-
>> 2 files changed, 172 insertions(+), 67 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-08 11:27:21.0
>> -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:09.0 -0500
>> @@ -28,6 +28,14 @@
>> #include
>>
>> #define MEMORY_CLASS_NAME "memory"
>> +#define MIN_MEMORY_BLOCK_SIZE (1 << SECTION_SIZE_BITS)
>> +
>> +static int sections_per_block;
>> +
> some default value, plz. Does this can be determined only by .config ?
The default is 1. This is determined in the get_memory_block_size() which
is called from the memory sysfs init routine.
>
>
>> +static inline int base_memory_block_id(int section_nr)
>> +{
>> +return (section_nr / sections_per_block) * sections_per_block;
>> +}
>>
>> static struct sysdev_class memory_sysdev_class = {
>> .name = MEMORY_CLASS_NAME,
>> @@ -94,10 +102,9 @@
>> }
>>
>> static void
>> -unregister_memory(struct memory_block *memory, struct mem_section *section)
>> +unregister_memory(struct memory_block *memory)
>> {
>> BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
>> -BUG_ON(memory->sysdev.id != __section_nr(section));
>>
>> /* drop the ref. we got in remove_memory_block() */
>> kobject_put(&memory->sysdev.kobj);
>> @@ -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);
>
> list_for_each_entry ?
I went with list_for_each_safe() here since I am not holding the mutex
while walking the list. Perhaps this should be changed to take the
mutex and use list_for_each_entry().
>
>
>
>> +start_pfn = section_nr_to_pfn(mbs->phys_index);
>> +ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> +}
>
> Hmm, them, only when the whole memory block is removable, it's shown as
> removable. Right ?
> Does it meets ppc guy's requirements ?
Yes, and yes.
>
>>
>> -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);
>> }
>
> Hmm...can't you print removable information as bitmap, here ?
> overkill ?
We could print it as a bitmap, but I think it would be overkill. The
memory add/remove routines work on a memory_block such that all
memory_block_sections in the memory_block are added/removed as a whole.
Given this, I figured we only needed to know if the entire memory_block
is removable.
>
>
>>
>> @@ -182,16 +196,16 @@
>> * OK to have direct references to sparsemem variables in here.
>> */
>> static int
>> -memory_block_action(struct memory_block *mem, unsigned long action)
>> +memory_block_action(struct memory_block_section *mbs, unsigned long action)
>> {
>> int i;
>> unsigned long psection;
>> unsigned long start_pfn, start_paddr;
>> struct page *first_page;
>> int ret;
>> -int old_state = mem->state;
>> ot-option-to-disable-memory-hotplug.patch
>> +int old_state = mbs->state;
>
> Where is this noise from
Re: [PATCH 3/7] Update the [register,unregister]_memory routines
On 07/13/2010 01:20 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:44:10 -0500
> Nathan Fontenot 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
>> ---
>> 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.0
>> -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:20.0 -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
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] Allow sysfs memory directories to be split
On 07/13/2010 01:28 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:45:25 -0500
> Nathan Fontenot 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
>> ---
>
> 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.0
>> -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:38:09.0 -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 = 0x;
>> +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
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] Split the memory_block structure
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;
>> +}
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer : [cut] > Could be a GPU lockup again, possibly due to still using AGP 4x with > modeset=0. [cut] > What does the log file contain with modeset=1? 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 startup. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote: > 2010/7/13 Michel Dänzer : > > What does the log file contain with modeset=1? > > 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 startup. 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=1. > At this time, I think it isn't a kernel problem, am I right? With modeset=1 it most likely is a kernel (configuration) problem. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
2010/7/13 Michel Dänzer : [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=1. > >> At this time, I think it isn't a kernel problem, am I right? > > With modeset=1 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote: > > 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. Note that e.g. on my PowerBook agpmode=1 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. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: optimized script [Was: ARM defconfig files]
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
> > > wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre
> > > > 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc:prom Export device tree physical address via proc
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
---
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
#include
#include
+#include
#include
#include
@@ -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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc:prom Export device tree physical address via proc
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2] powerpc:prom Export device tree physical address via proc
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
---
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
#include
#include
+#include
#include
#include
@@ -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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3] powerpc:prom Export device tree physical address via proc
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
---
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
#include
#include
+#include
#include
#include
@@ -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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
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//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//configs/xxx_defconfig as now. > > Signed-off-by: Stephen Rothwell > --- > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
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 > Signed-off-by: Mark Miesfeld > --- 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
Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
> > 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) ... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 _defconfig target that is processed if a .Kconfig file is present in the $(ARCH)/configs directory instead of the current _defconfig file. The target works by passing the $(ARCH)/configs/.Kconfig to Kconfig instead of the architecture's default $(ARCH)/Kconfig file. .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 _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 --- 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 000..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 000..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 + se
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
Typo correction: 2010/7/13 Grant Likely : [...] > .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 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). [...] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker 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 _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. > 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9 v1.01] Add Synopsys DesignWare HS USB OTG Controller driver.
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 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 > > Signed-off-by: Mark Miesfeld > > --- > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
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 _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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig
On Tue, 2010-07-13 at 17:21 -0600, Grant Likely wrote: > On Tue, Jul 13, 2010 at 5:14 PM, Daniel Walker 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 _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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: optimized script [Was: ARM defconfig files]
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 > > > > wrote: > > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre > > > > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] Allow sysfs memory directories to be split
On Tue, 13 Jul 2010 10:51:58 -0500 Nathan Fontenot 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
[cc'ing rmk and linux-arm-kernel] On Mon, Jul 12, 2010 at 7:43 PM, Stephen Rothwell wrote: > After this change, doing a "make xxx_defconfig" will check first for > a file called 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//configs/xxx_defconfig as now. Oops, I hadn't seen this patch when I wrote mine this afternoon[1]. :-) A few minor differences, but essentially the same solution. [1] http://patchwork.ozlabs.org/patch/58823/ I chose to use -D /dev/null (defconfig from an empty file) instead of -n (allnoconfig) so that default values in Kconfig would get respected. For the benefit of everyone else, here's an excerpt from our IRC conversation this afternoon: 19:49 < gcl> sfr: [...] Your patch and my patch are essentially doing exactly the same thing, except that I used '-d' and you used '-n'. 19:50 < gcl> s/-d/-D/ 19:55 < sfr> right 19:55 < sfr> Linus wanted us to use -n 19:55 < sfr> because that way you get what you asked for, not what the defaults say ... 19:58 < gcl> I suppose we don't currently have a way to say "select FOO=n", so I suppose that makes sense 19:58 < gcl> although I think using the defaults unless told not to is a better approach in the long run 19:59 < gcl> most of the time I *don't want* to ask for something in the defconfig. :-) 20:00 < gcl> I just want TheBestOrCorrectAnswer to be chosen for me 20:04 < sfr> gcl: go read Linus' vision :-) > Signed-off-by: Stephen Rothwell > --- > 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. For both of the above problems, what if we added syntax like the following to Kconfig? config FOO bool select BAR = n select FOO_VALUE = 54 > I am currently working towards using this to recreate the PowerPC > defconfigs, but it is a slow process as they have some much stuff enabled > in them and some of it is probably actually not relevant. If the trimmed configs are merged, then there is no rush on this. We can keep them around and switch them over as people want to make changes. > This process is made easier by the recent commit "kbuild: Warn on > selecting symbols with unmet direct dependencies" that is in the kbuild > tree (and linux-next). Ah, I didn't know that change was being merged. That indeed makes things easier, and eliminates the post-test that I do to make sure that the resulting config is actually valid. > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile > index 7ea649d..1ab8f45 100644 > --- a/scripts/kconfig/Makefile > +++ b/scripts/kconfig/Makefile > @@ -117,9 +117,21 @@ else > $(Q)$< -D arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG) $(Kconfig) > endif > > -%_defconfig: $(obj)/conf > +configs_dir := $(srctree)/arch/$(SRCARCH)/configs > +# We check a level of sub directories because arch/powerpc > +# has its defconfig files arranged that way > +old_defconfigs := $(patsubst $(configs_dir)/%,%,\ > + $(wildcard $(configs_dir)/*_defconfig) \ > + $(wildcard $(configs_dir)/*/*_defconfig)) > +defconfigs := $(patsubst $(configs_dir)/Kconfig.%,%_defconfig,\ > + $(wildcard $(configs_dir)/Kconfig.*)) > + Ugh. My first impression is that all this shouldn't be necessary, and it should be okay to just make the two following rules include a pattern dependency for the source file. However, as I play with it, I cannot seem to get the rules right to handle the sub directories. The $(defconfigs) patsubst at least could be done solely with dependencies on the target rule if the files were named *.Kconfig instead of Kconfig.* (because subdirectories are not handled in that case). For example: %_defconfig: $(obj)/conf arch/$(SRCARCH)/configs/%.Kconfig $(Q)$< -n arch/$(SRCARCH)/configs/$*.Kconfig > +$(old_defconfigs): %_defconfig: $(obj)/conf > $(Q)$< -D arch/$(SRCARCH)/configs/$@ $(Kconfig) > > +$(defconfigs): %_defconfig: $(obj)/conf > + $(Q)$< -n arch/$(SRCARCH)/configs/Kconfig.$* > + > # Help text used by make help > help: > �...@echo ' config - Update current config utilising a > line-oriented program' Cheers, g. -- Gra
Re: [PATCH 4/7] Allow sysfs memory directories to be split
On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote: > On Tue, 13 Jul 2010 10:51:58 -0500 > Nathan Fontenot 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. I posted a patch to do that a week or so ago, it didn't go over very well. > > 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 ? ppc would still require the existance of the 'probe' interface. Are you objecting to the 'split' functionality? If so I do not see any reason from ppc perspective that it is needed. This was something Dave suggested, unless I am missing something. Since ppc needs the 'probe' interface in sysfs, and for ppc having mutliple memory_block_sections reside under a single memory_block makes memory hotplug simpler. On ppc we do emory hotplug operations on an LMB size basis. With my patches this now lets us set each memory_block to span an LMB's worth of memory. Now we could do emory hotplug in a single operation instead of multiple operations to offline/online all of the memory sections in an LMB. Of course the easy solution would be to increase SECTION_SIZE_BITS, but we need support hardware that can have LMB's from 16 MB to 256 MB in size so the SECTION_SIZE_BITS value has to remain small. > > One problem is that I don't have enough knowledge about configfs..it seems > complex. Me neither, thoug I will take a look at it. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] Allow sysfs memory directories to be split
On Wed, 2010-07-14 at 09:35 +0900, KAMEZAWA Hiroyuki wrote: > 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 ? I think creating a interface to duplicate the existing sysfs one is a bad idea. I also think removing the existing sysfs one isn't feasible since there are users, and it's truly part of the ABI. So, I'm not really a fan on the configfs interface. :( I really do think the sysfs interface is fixable. We should at least give it a good shot before largely duplicating its functionality. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7] Allow sysfs memory directories to be split
On Tue, 13 Jul 2010 22:18:03 -0500 Nathan Fontenot wrote: > On 07/13/2010 07:35 PM, KAMEZAWA Hiroyuki wrote: > > On Tue, 13 Jul 2010 10:51:58 -0500 > > Nathan Fontenot 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. > > I posted a patch to do that a week or so ago, it didn't go over very well. > > > > > 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 ? > > ppc would still require the existance of the 'probe' interface. > > Are you objecting to the 'split' functionality? yes. > If so I do not see any reason from ppc > perspective that it is needed. This was something Dave suggested, unless I > am missing > something. > > Since ppc needs the 'probe' interface in sysfs, and for ppc having mutliple > memory_block_sections reside under a single memory_block makes memory hotplug > simpler. On ppc we do emory hotplug operations on an LMB size basis. With my > patches this now lets us set each memory_block to span an LMB's worth of > memory. Now we could do emory hotplug in a single operation instead of > multiple > operations to offline/online all of the memory sections in an LMB. > Why per-section memory offlining is provided is for allowing good success-rate of memory offlining. Because memory-hotplug has to "migrate or free" all used page under a section, possibility of memory unplug depends on usage of memory. If a section contains unmovable page(kernel page), we can't offline sectin. For example, comparing 1. offlining 128MB of memory at once 2. offlining 8 chunks of 16MB memory "2" can get very good possibility and system-busy time can be much reduced. IIUC, ppc's 1st requirement is "resizing" not "hot-removing some memory device", "2" is much welcomed. So, some fine-grained interface to section_size is appreciated. So, "multiple operations" is much better than single operation. As I posted show/hide patch, I'm writing it in configfs. I think it meets IBM's requirements. _But_, it's IBM's issue not Fujitsu's. So, final decistion will depend on you guys. Anyway, I don't like a too fancy interface as "split". Thanks, -Kame ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Hi: I used your patch and test it on MPC8548 board. Today, I found a problem when doing raid5 recovering. talitos e003.crypto: master data transfer error talitos e003.crypto: xor operation: talitos error -22 [ cut here ] Kernel BUG at c02dcb6c [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] MPC85xx CDS Modules linked in: iscsi_trgt NIP: c02dcb6c LR: c02dcb6c CTR: c023e7a8 REGS: e8b8d820 TRAP: 0700 Not tainted (2.6.31.6) MSR: 00029000 CR: 22008022 XER: 2000 TASK = ef8cb2e0[1897] 'md2_raid5' THREAD: e8b8c000 GPR00: c02dcb6c e8b8d8d0 ef8cb2e0 0040 7c99 c023bccc 7c5f GPR08: c04a5c60 c049b5fc 7c99 4000 80008022 3fff5700 c3374754 GPR16: c337474c ffea 0001 000186a0 GPR24: ffea ffea ef81f850 000c 00029000 ffea ef81f850 efb1d580 NIP [c02dcb6c] talitos_release_xor+0xfc/0x104 LR [c02dcb6c] talitos_release_xor+0xfc/0x104 Call Trace: [e8b8d8d0] [c02dcb6c] talitos_release_xor+0xfc/0x104 (unreliable) [e8b8d8f0] [c02db928] flush_channel+0x11c/0x178 [e8b8d920] [c02dd344] talitos_interrupt+0x320/0x9e8 [e8b8d970] [c0060b3c] handle_IRQ_event+0x5c/0x140 [e8b8d990] [c006280c] handle_fasteoi_irq+0x68/0x118 [e8b8d9a0] [c0004f08] do_IRQ+0x94/0xb0 [e8b8d9c0] [c000fe00] ret_from_except+0x0/0x18 [e8b8da80] [c02b47a0] release_stripe+0x24/0x3c [e8b8da90] [c02ba4ec] raid5_end_read_request+0x160/0x3f8 [e8b8dae0] [c00ba36c] bio_endio+0x48/0x6c [e8b8daf0] [c01f80e0] req_bio_endio+0xa4/0x128 [e8b8db10] [c01f81f0] blk_update_request+0x8c/0x43c [e8b8db40] [c01f85c0] blk_update_bidi_request+0x20/0x88 [e8b8db60] [c01f92c4] blk_end_bidi_request+0x1c/0x58 [e8b8db80] [c01f9314] blk_end_request+0x14/0x24 [e8b8db90] [c025ece0] scsi_io_completion+0x8c/0x4ac [e8b8dbd0] [c0257fd0] scsi_finish_command+0xd0/0xf4 [e8b8dbf0] [c025f1c8] scsi_softirq_done+0xc8/0x150 [e8b8dc10] [c01fe114] blk_done_softirq+0x80/0xa0 [e8b8dc30] [c003a0d8] __do_softirq+0xa8/0x128 [e8b8dc70] [c0004e70] do_softirq+0x54/0x58 [e8b8dc80] [c0039f4c] irq_exit+0x94/0x98 [e8b8dc90] [c0004f0c] do_IRQ+0x98/0xb0 [e8b8dcb0] [c000fe00] ret_from_except+0x0/0x18 [e8b8dd70] [c00679c8] mempool_alloc_slab+0x1c/0x2c [e8b8ddb0] [c02b6814] ops_run_io+0x1ac/0x2b8 [e8b8ddf0] [c02b93e4] handle_stripe5+0xa80/0x15c0 [e8b8de70] [c02bb408] handle_stripe+0x34/0x12d4 [e8b8df10] [c02bc8ec] raid5d+0x244/0x458 [e8b8df70] [c02c9624] md_thread+0x5c/0x124 [e8b8dfc0] [c004ab24] kthread+0x78/0x7c [e8b8dff0] [c000f52c] kernel_thread+0x4c/0x68 Instruction dump: bb61000c 38210020 7c0803a6 4bffefac 4bf63bc9 80be0008 7c641b78 3c60c042 7fa6eb78 38631ccc 4cc63182 4bd58b9d <0fe0> 4800 9421ffd0 7c0802a6 Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 1 seconds.. [ cut here ] Badness at c0223124 [verbose debug info unavailable] NIP: c0223124 LR: c0223308 CTR: REGS: e8b8d580 TRAP: 0700 Tainted: G D (2.6.31.6) MSR: 00021000 CR: 82008088 XER: 2000 TASK = ef8cb2e0[1897] 'md2_raid5' THREAD: e8b8c000 GPR00: 0001 e8b8d630 ef8cb2e0 e84f1d60 e84f1d60 e84f1d7c c04a1364 GPR08: c04a5c60 e8b8c000 873b e8b8d650 82008088 3fff5700 c3374754 GPR16: c337474c ffea 0001 000186a0 GPR24: ffea ffea 1106 e84f1d60 NIP [c0223124] pci_get_dev_by_id+0x34/0x98 LR [c0223308] pci_get_subsys+0x64/0xa4 Call Trace: [e8b8d630] [c021e378] no_pci_devices+0x34/0x50 (unreliable) [e8b8d650] [c0223308] pci_get_subsys+0x64/0xa4 [e8b8d670] [c0017be0] mpc85xx_cds_restart+0x24/0x90 [e8b8d690] [c000e7d0] machine_restart+0x34/0x4c [e8b8d6a0] [c00447e0] emergency_restart+0x14/0x24 [e8b8d6b0] [c003473c] panic+0x118/0x158 [e8b8d700] [c000cf24] die+0x160/0x16c [e8b8d720] [c000d1b0] _exception+0x12c/0x154 [e8b8d810] [c000fdb4] ret_from_except_full+0x0/0x4c [e8b8d8d0] [c02dcb6c] talitos_release_xor+0xfc/0x104 [e8b8d8f0] [c02db928] flush_channel+0x11c/0x178 [e8b8d920] [c02dd344] talitos_interrupt+0x320/0x9e8 [e8b8d970] [c0060b3c] handle_IRQ_event+0x5c/0x140 [e8b8d990] [c006280c] handle_fasteoi_irq+0x68/0x118 [e8b8d9a0] [c0004f08] do_IRQ+0x94/0xb0 [e8b8d9c0] [c000fe00] ret_from_except+0x0/0x18 [e8b8da80] [c02b47a0] release_stripe+0x24/0x3c [e8b8da90] [c02ba4ec] raid5_end_read_request+0x160/0x3f8 [e8b8dae0] [c00ba36c] bio_endio+0x48/0x6c [e8b8daf0] [c01f80e0] req_bio_endio+0xa4/0x128 [e8b8db10] [c01f81f0] blk_update_request+0x8c/0x43c [e8b8db40] [c01f85c0] blk_update_bidi_request+0x20/0x88 [e8b8db60] [c01f92c4] blk_end_bidi_request+0x1c/0x58 [e8b8db80] [c01f9314] blk_end_request+0x14/0x24 [e8b8db90] [c025ece0] scsi_io_completion+0x8c/0x4ac [e8b8dbd0] [c0257fd0] scsi_finish_command+0xd0/0xf4 [e8b8dbf0] [c025f1c8] scsi_softirq_done+0xc8/0x150 [e8b8dc10] [c01fe114] blk_done_softirq+0x80/0xa0 [e8b8dc30] [c003a0d8] __do_softirq+0xa8/0x128 [e8b8dc70] [c0004e70] do_softirq+0x54/0x58 [e8b8dc80] [c0039f4c] irq_exit+0x94/0x98 [e8b
Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
On Tue, Jul 13, 2010 at 7:26 PM, Grant Likely wrote: > > I chose to use -D /dev/null (defconfig from an empty file) instead of > -n (allnoconfig) so that default values in Kconfig would get > respected. For the benefit of everyone else, here's an excerpt from > our IRC conversation this afternoon: > > 19:49 < gcl> sfr: [...] Your patch and my patch are > essentially doing exactly the same thing, except that I used '-d' > and you used '-n'. > 19:50 < gcl> s/-d/-D/ > 19:55 < sfr> right > 19:55 < sfr> Linus wanted us to use -n Just a note: Linus doesn't really care. IOW, I used -n not because of any fundamental belief that it is correct, but just because ti happened to be how I happened to decide to solve it. It's entirely possible that starting from the Kconfig defaults (rather than "no") is the right way to go. I think either approach is likely fine. The -D /dev/null approach would presumably give smaller Kconfig.xyz files, assuming our defaults are sane (an maybe that could be at least a partial validation of the defaults we do have). While the -n approach is in some ways more stable, in that the resulting Kconfig.xyz entires would presumably be more stand-alone, and there wouldn't be any subtle interactions when somebody changes a default value int he Kconfig file. So I can see advantages to either model. And either model clearly would want the improvements to "select" that are independent (ie warn about unsatisfied 'depends on' constraints, and select recursively. Maybe we already fixed the recursive select thing, I forget). I also think we need to allow setting of actual values. I don't know what the syntax would be. A "set" statement that overrides a default in the Kconfig file, so that you can do set NODES_SHIFT 10 which would basically be equivalent to a "select" of a tristate variable, but instead set the actual value? I dunno. And quite frankly, maybe somebody comes up with a better model entirely. I like the Kconfig.xyz model, in that it should be human-readable/writable and shouldn't introduce any fundamentally new concepts (except the fairly simple extensions to the Kconfig language), but maybe there are better models. Regardless, I don't have anything against either set of patches (Grant's or Stephen's). Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/13] powerpc/book3e: Add generic 64-bit idle powersave support
On Fri, 2010-07-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: > We use a similar technique to ppc32: We set a thread local flag > to indicate that we are about to enter or have entered the stop > state, and have fixup code in the async interrupt entry code that > reacts to this flag to make us return to a different location > (sets NIP to LINK in our case). .../... Commenting on my own patch ... :-) This has issues: > +_GLOBAL(book3e_idle) > + /* Save LR for later */ > + mflrr0 > + std r0,16(r1) > + > + /* Hard disable interrupts */ > + wrteei 0 > + > + /* Now check if an interrupt came in while we were soft disabled > + * since we may otherwise lose it (doorbells etc...). We know > + * that since PACAHARDIRQEN will have been cleared in that case. > + */ > + lbz r3,PACAHARDIRQEN(r13) > + cmpwi cr0,r3,0 > + beqlr > + > + /* Now we are going to mark ourselves as soft and hard enables in > + * order to be able to take interrupts while asleep. We inform lockdep > + * of that. We don't actually turn interrupts on just yet tho. > + */ > +#ifdef CONFIG_TRACE_IRQFLAGS > + bl .trace_hardirqs_on Oops... we just clobbered our saved LR on the stack. Need a stackframe > +#endif > + li r0,1 > + stb r0,PACASOFTIRQEN(r13) > + stb r0,PACAHARDIRQEN(r13) > + > + /* Interrupts will make use return to LR, so get something we want > + * in there > + */ > + bl 1f We return here with IRQs enabled, we really need to turn them back off or bad things will happen if an interrupt pops before we clear TFL_NAPPING. I'll send a respin. Cheers, Ben. > + /* We are back from the interrupt, the caller will local_irq_enable() > + * so to avoid stupid warning, let's turn them off here if irqtrace > + * is enabled. > + */ > +#ifdef CONFIG_TRACE_IRQFLAGS > + li r0,0 > + stb r0,PACASOFTIRQEN(r13) > + bl .trace_hardirqs_off > +#endif > + ld r0,16(r1) > + mtlrr0 > + blr > + > +1: /* Let's set the _TLF_NAPPING flag so interrupts make us return > + * to the right spot > + */ > + clrrdi r11,r1,THREAD_SHIFT > + ld r10,TI_LOCAL_FLAGS(r11) > + ori r10,r10,_TLF_NAPPING > + std r10,TI_LOCAL_FLAGS(r11) > + > + /* We can now re-enable hard interrupts and go to sleep */ > + wrteei 1 > +1: PPC_WAIT(0) > + b 1b > + > +#endif /* CONFIG_PPC64 */ > \ No newline at end of file ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/book3e: Add generic 64-bit idle powersave
We use a similar technique to ppc32: We set a thread local flag to indicate that we are about to enter or have entered the stop state, and have fixup code in the async interrupt entry code that reacts to this flag to make us return to a different location (sets NIP to LINK in our case). Signed-off-by: Benjamin Herrenschmidt -- v2. Fix lockdep bug Re-mask interrupts when coming back from idle --- arch/powerpc/include/asm/machdep.h |1 + arch/powerpc/kernel/Makefile |2 +- arch/powerpc/kernel/exceptions-64e.S | 23 + arch/powerpc/kernel/idle_book3e.S| 86 ++ 4 files changed, 111 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/kernel/idle_book3e.S diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h index 2bad6e5..adc8e6c 100644 --- a/arch/powerpc/include/asm/machdep.h +++ b/arch/powerpc/include/asm/machdep.h @@ -278,6 +278,7 @@ extern void e500_idle(void); extern void power4_idle(void); extern void power4_cpu_offline_powersave(void); extern void ppc6xx_idle(void); +extern void book3e_idle(void); /* * ppc_md contains a copy of the machine description structure for the diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 8a33318..77d831a 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -37,7 +37,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \ obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o obj-$(CONFIG_PPC_BOOK3S_64)+= cpu_setup_ppc970.o cpu_setup_pa6t.o obj64-$(CONFIG_RELOCATABLE)+= reloc_64.o -obj-$(CONFIG_PPC_BOOK3E_64)+= exceptions-64e.o +obj-$(CONFIG_PPC_BOOK3E_64)+= exceptions-64e.o idle_book3e.o obj-$(CONFIG_PPC64)+= vdso64/ obj-$(CONFIG_ALTIVEC) += vecemu.o obj-$(CONFIG_PPC_970_NAP) += idle_power4.o diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S index a42637c..316465a 100644 --- a/arch/powerpc/kernel/exceptions-64e.S +++ b/arch/powerpc/kernel/exceptions-64e.S @@ -204,11 +204,30 @@ exc_##n##_bad_stack: \ lis r,tsr_...@h;\ mtspr SPRN_TSR,r +/* Used by asynchronous interrupt that may happen in the idle loop. + * + * This check if the thread was in the idle loop, and if yes, returns + * to the caller rather than the PC. This is to avoid a race if + * interrupts happen before the wait instruction. + */ +#define CHECK_NAPPING() \ + clrrdi r11,r1,THREAD_SHIFT;\ + ld r10,TI_LOCAL_FLAGS(r11);\ + andi. r9,r10,_TLF_NAPPING;\ + beq+1f; \ + ld r8,_LINK(r1); \ + rlwinm r7,r10,0,~_TLF_NAPPING; \ + std r8,_NIP(r1);\ + std r7,TI_LOCAL_FLAGS(r11); \ +1: + + #define MASKABLE_EXCEPTION(trapnum, label, hdlr, ack) \ START_EXCEPTION(label); \ NORMAL_EXCEPTION_PROLOG(trapnum, PROLOG_ADDITION_MASKABLE) \ EXCEPTION_COMMON(trapnum, PACA_EXGEN, INTS_DISABLE_ALL) \ ack(r8);\ + CHECK_NAPPING();\ addir3,r1,STACK_FRAME_OVERHEAD; \ bl hdlr; \ b .ret_from_except_lite; @@ -257,6 +276,7 @@ interrupt_end_book3e: CRIT_EXCEPTION_PROLOG(0x100, PROLOG_ADDITION_NONE) // EXCEPTION_COMMON(0x100, PACA_EXCRIT, INTS_DISABLE_ALL) // bl special_reg_save_crit +// CHECK_NAPPING(); // addir3,r1,STACK_FRAME_OVERHEAD // bl .critical_exception // b ret_from_crit_except @@ -268,6 +288,7 @@ interrupt_end_book3e: // EXCEPTION_COMMON(0x200, PACA_EXMC, INTS_DISABLE_ALL) // bl special_reg_save_mc // addir3,r1,STACK_FRAME_OVERHEAD +// CHECK_NAPPING(); // bl .machine_check_exception // b ret_from_mc_except b . @@ -338,6 +359,7 @@ interrupt_end_book3e: CRIT_EXCEPTION_PROLOG(0x9f0, PROLOG_ADDITION_NONE) // EXCEPTION_COMMON(0x9f0, PACA_EXCRIT, INTS_DISABLE_ALL) // bl special_reg_save_crit +// CHECK_NAPPING(); // addir3,r1,STACK_FRAME_OVERHEAD // bl .unknown_exception // b ret_from_crit_except @@ -434,6 +456,7 @@ kernel_dbg_exc: CRIT_EXCEPTION_PROLOG(0x2080, PROLOG_ADDITION_NONE) // EXCEPTION_COMMON(0x2080, PA
Re: [PATCH] kbuild: Enable building defconfigs from Kconfig files
On Tue, Jul 13, 2010 at 10:04 PM, Linus Torvalds wrote: > On Tue, Jul 13, 2010 at 7:26 PM, Grant Likely > wrote: >> >> I chose to use -D /dev/null (defconfig from an empty file) instead of >> -n (allnoconfig) so that default values in Kconfig would get >> respected. For the benefit of everyone else, here's an excerpt from >> our IRC conversation this afternoon: >> >> 19:49 < gcl> sfr: [...] Your patch and my patch are >> essentially doing exactly the same thing, except that I used '-d' >> and you used '-n'. >> 19:50 < gcl> s/-d/-D/ >> 19:55 < sfr> right >> 19:55 < sfr> Linus wanted us to use -n > > Just a note: Linus doesn't really care. > > IOW, I used -n not because of any fundamental belief that it is > correct, but just because ti happened to be how I happened to decide > to solve it. It's entirely possible that starting from the Kconfig > defaults (rather than "no") is the right way to go. > > I think either approach is likely fine. The -D /dev/null approach > would presumably give smaller Kconfig.xyz files, assuming our defaults > are sane (an maybe that could be at least a partial validation of the > defaults we do have). While the -n approach is in some ways more > stable, in that the resulting Kconfig.xyz entires would presumably be > more stand-alone, and there wouldn't be any subtle interactions when > somebody changes a default value int he Kconfig file. Okay, well I advocate for the -D /dev/null approach then. I think that validating our defaults, and looking for the subtle interactions are exactly what we want to be doing when it comes to defconfigs. The fact that a defconfig does *not* want the default value is exactly what the defconfigs should be capturing. > So I can see advantages to either model. And either model clearly > would want the improvements to "select" that are independent (ie warn > about unsatisfied 'depends on' constraints, and select recursively. > Maybe we already fixed the recursive select thing, I forget). > > I also think we need to allow setting of actual values. I don't know > what the syntax would be. A "set" statement that overrides a default > in the Kconfig file, so that you can do > > set NODES_SHIFT 10 > > which would basically be equivalent to a "select" of a tristate > variable, but instead set the actual value? I dunno. I'm partial to extending select statements myself because it fits nicely into the existing grammer; but I can see value in having a set statement too. It would eliminate the temporary config options that both my and Stephen's patch would add. > And quite frankly, maybe somebody comes up with a better model > entirely. I like the Kconfig.xyz model, in that it should be > human-readable/writable and shouldn't introduce any fundamentally new > concepts (except the fairly simple extensions to the Kconfig > language), but maybe there are better models. Perhaps, but I can't think of anything and this one is simple, elegant, and easy to implement. > Regardless, I don't have anything against either set of patches > (Grant's or Stephen's). I think we should run with this. Since the patch has been merged to warn on unmet Kconfig dependences, the only major hole left is being able to do negative selects and to select specific values. Stephen, I'm happy to either keep working on this, or drop my patch in favor of yours. Whichever you prefer. I'll try to find some time to look at the Kconfig grammer. The solver would also be useful and could further reduce the size of the Kconfig fragments, but it isn't necessary so we don't need to wait for it to get implemented to take this approach.. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
