Re: ppc manual paging question
I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) from x86 to ppc, I think I'm near the ending except the above problem. xtratum is doing things like xen but it's much simpler (it's aimed for realtime), it need provides memory space sperations for it's domains, so I need manually paging. Each domain is loaded by a userspace program (instead of the root domain as a kernel module), the loader will load the domain's (ELF staticly excutable) PT_LOAD section into memory, and then raise a properly system call (passing the structurized loaded data as arguments) to load the domain via load_domain_sys(), and at the last step of loading the domain, xtratum will jump to the entry code of the new domain(asm wrappered start() routine) and then everything should be fine. The problem now is as follow: under my ppc (440GR/440EP) platform, start() is always at 0x10a0, but I guess there is something wrong with my mm code so after the domain is loaded, the virt addres 0x10a0 just point to garbage instead of the right start() routine. So how can I setup paging properly so that the virtual memory could be translated to proper data? Are you aware that the 440 MMU doesn't actually know what a page table is and doesn't load PTEs from memory ? It's a software loaded TLB, you'll have to put translations in the TLB yourself. You'll need to design your own data structures for that, tho you can use a page table for tracking, like we do in linux, and then have your own TLB miss handler to fill the TLB from that. Your initial code probably need to bolt a TLB entry for the kernel itself. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc manual paging question
On Monday 22 October 2007 14:01:33, Benjamin Herrenschmidt wrote: I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) from x86 to ppc, I think I'm near the ending except the above problem. xtratum is doing things like xen but it's much simpler (it's aimed for realtime), it need provides memory space sperations for it's domains, so I need manually paging. Each domain is loaded by a userspace program (instead of the root domain as a kernel module), the loader will load the domain's (ELF staticly excutable) PT_LOAD section into memory, and then raise a properly system call (passing the structurized loaded data as arguments) to load the domain via load_domain_sys(), and at the last step of loading the domain, xtratum will jump to the entry code of the new domain(asm wrappered start() routine) and then everything should be fine. The problem now is as follow: under my ppc (440GR/440EP) platform, start() is always at 0x10a0, but I guess there is something wrong with my mm code so after the domain is loaded, the virt addres 0x10a0 just point to garbage instead of the right start() routine. So how can I setup paging properly so that the virtual memory could be translated to proper data? Are you aware that the 440 MMU doesn't actually know what a page table is and doesn't load PTEs from memory ? Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's almost nothing like in ppc 4xx/44x. It's a software loaded TLB, you'll have to put translations in the TLB yourself. You'll need to design your own data structures for that, tho you can use a page table for tracking, like we do in linux, and then have your own TLB miss handler to fill the TLB from that. OK, Shall I look for the DataTLBError code in head.S? I realized that I've got DataTLBError sometimes via BDI2000/kgdb (the fault address is within DataTLBError), Shall I should also look for arch/ppc/mm/fault.c? Your initial code probably need to bolt a TLB entry for the kernel itself. I don't understand this clearly, how can I do this? Ben. Regards, Wang -- Wang, Baojun Lanzhou University Distributed Embedded System Lab http://dslab.lzu.edu.cn School of Information Science and Engeneering [EMAIL PROTECTED] Tianshui South Road 222. Lanzhou 73 .P.R.China Tel:+86-931-8912025 Fax:+86-931-8912022 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc manual paging question
Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's almost nothing like in ppc 4xx/44x. You'll have to get yourself a 44x manual :-) It's a software loaded TLB, you'll have to put translations in the TLB yourself. You'll need to design your own data structures for that, tho you can use a page table for tracking, like we do in linux, and then have your own TLB miss handler to fill the TLB from that. OK, Shall I look for the DataTLBError code in head.S? I realized that I've got DataTLBError sometimes via BDI2000/kgdb (the fault address is within DataTLBError), Shall I should also look for arch/ppc/mm/fault.c? head_44x.S is where you'll find some guidance Your initial code probably need to bolt a TLB entry for the kernel itself. I don't understand this clearly, how can I do this? Well, you insert a TLB entry manually and avoid replacing it later on Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc manual paging question
On Monday 22 October 2007 15:34:24, Benjamin Herrenschmidt wrote: Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's almost nothing like in ppc 4xx/44x. You'll have to get yourself a 44x manual :-) It's a software loaded TLB, you'll have to put translations in the TLB yourself. You'll need to design your own data structures for that, tho you can use a page table for tracking, like we do in linux, and then have your own TLB miss handler to fill the TLB from that. OK, Shall I look for the DataTLBError code in head.S? I realized that I've got DataTLBError sometimes via BDI2000/kgdb (the fault address is within DataTLBError), Shall I should also look for arch/ppc/mm/fault.c? head_44x.S is where you'll find some guidance Yup, I've found how does the kernel handle tlbs, I think the most important thing is I forgot read/write the SPRN_SPRG3 register as _switch does. Your initial code probably need to bolt a TLB entry for the kernel itself. I don't understand this clearly, how can I do this? Well, you insert a TLB entry manually and avoid replacing it later on I've add the _PAGE_PRESENT flag to the related PTE Ben. Thanks very much I'm now getting much clearer about my question:) Regards, Wang -- Wang, Baojun Lanzhou University Distributed Embedded System Lab http://dslab.lzu.edu.cn School of Information Science and Engeneering [EMAIL PROTECTED] Tianshui South Road 222. Lanzhou 73 .P.R.China Tel:+86-931-8912025 Fax:+86-931-8912022 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc manual paging question
Yup, I've found how does the kernel handle tlbs, I think the most important thing is I forgot read/write the SPRN_SPRG3 register as _switch does. SPRG3 is for use by the operating system for whatever you want... if you are copying linux code, then you probably indeed want to get that right but you don't have to use SPRG3. I've add the _PAGE_PRESENT flag to the related PTE Hrm.. that has nothing ot do with the PTE. Bolting is more a property of your replacement algorithm in the TLB miss handler. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
So, like, the other day Segher Boessenkool mumbled: Property names have been limited to start with characters from the set [a-zA-Z,._#?]. That is, the digits and the expression symbols have been removed. This cannot work; many property names start with a digit, for example. Are any of those property names in use in any of our DTS files or b-w-o.txt? Not really, no. In fact, with this lexical change, all of our DTS files still produce byte-identical results. I really think this is one of those areas where we may need to stray from the other guideline. Is there a compelling reason somewhere? Really? jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: Doing it that way will make the kernel specific to the target device. Currently I can load the same mpc5200 kernel on several different target devices since the platform specific code is triggered in the probe machine phase. Maybe I need to take a look at your code, but the fabric driver is, in effect, a platform-specific driver. Its job is to figure out what hardware is on the board, how it's connected, and then initialize and connect the other drivers as appropriate. I tried making the fabric driver into a platform driver instead of an openfirmware driver, but the mpc5200 code is not initializing platform drivers correctly. Yeah, that wouldn't work. Platform drivers are initialized way too early. I could insert calls into arch/powerpc/platforms/52xx/whatever to load the specific asoc fabric, but doing that is a mess. There must be a way to trigger loading of machine specific drivers Either you do it at driver __init time, or via a probe. The probe actually occurs at __init time, anyway, so they're kinda the same thing. The only thing the probe gets you is that you're called multiple times for each instance of a node in the tree. Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay attention to what they do. Those Apple drivers are very similar to asoc drivers. They could easily be folded into the asoc code. Perhaps, but that's a job for another day (and another developer). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
Hello David, No piece of code in the kernel should live in a vacuum. In order to improve overall code quality, every piece of driver code should avoid assuming things about pointer sizes and things of this nature. I'm afraid we might be talking about orthogonal issues here. I actively agree that all code (not only kernel) should be written up to the coding/quality standards you mention above, but I see a difference between fixing a warning and making a driver portable (to 64-bit PowerPCs, to other platforms, etc.). If there is a kernel todo list somewhere lets add to it the task to make the ucc_geth more portable. Then the driver can get enabled into the build on every platform, and therefore nobody will break the build of this driver again since it will get hit by allmodconfig et al. builds even on platforms other than the one it is meant for. This hack fix is not acceptable, really. Are you suggesting we leave those warnings there until somebody decides to fix all the portability issues of this driver? My patch is a small and insignificant improvement and not the revolution you're asking for, but is an small improvement today (I dislike warnings) vs. an improbable big one in the future. Leo, as author and maintainer of this driver, what's your take on this? Cheers, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [bug] block subsystem related crash on Legacy iSeries viodasd.c
On Sun, 2007-10-21 at 14:44 +0200, Jens Axboe wrote: On Fri, Oct 19 2007, Will Schmidt wrote: Hi Jens, Stephen, and Everyone else. ... You need this, will remember to fix that up for the new branch as well. diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c index e824b67..2ce3622 100644 --- a/drivers/block/viodasd.c +++ b/drivers/block/viodasd.c @@ -270,6 +270,7 @@ static int send_request(struct request *req) d = req-rq_disk-private_data; /* Now build the scatter-gather list */ + memset(sg, 0, sizeof(sg)); nsg = blk_rq_map_sg(req-q, req, sg); nsg = dma_map_sg(d-dev, sg, nsg, direction); That appears to do the trick. Thanks! Tested-By: Will Schmidt [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/2] powerpc: irqtrace support to 64-bit powerpc
On Mon, 2007-10-15 at 17:28 +1000, Benjamin Herrenschmidt wrote: This adds the low level irq tracing hooks to the powerpc architecture needed to enable full lockdep functionality Some rework from Johannes initial version, removing the asm trampoline that isn't needed (thus improving perfs) and fixing a couple of bugs such as incorrect initial preempt_count on the softirq alternate stack. Hmm. It breaks booting on my quad, I finally got around to testing without this patch and it turns out that it caused the boot failure I reported in another mail. This is with v2.6.23-6623-g55b70a0, a clean tree boots fine but with these two patches applied and configured in it fails during boot, hanging at some point, apparently when userspace is entered. On the other hand, it is fine with my original version. I'll have to find some time to check the differences hunk by hunk I guess. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
Jon Smirl wrote: I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. I think it should. For one thing, ASoC requires a pointer to a structure in the codec device driver so that it knows which functions to call to change volume. What if you have multiple i2s/ac97 devices and multiple codecs? You'll need to know which i2s device is connected to which codec. The only way to distinguish that is by having a node for the codec under the i2s node. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ppc44x: support for 256K PAGE_SIZE
On Friday 19 October 2007 17:24, Kumar Gala wrote: On Oct 18, 2007, at 6:21 PM, Paul Mackerras wrote: Yuri Tikhonov writes: The following patch adds support for 256KB PAGE_SIZE on ppc44x- based boards. The applications to be run on the kernel with 256KB PAGE_SIZE have to be built using the modified version of binutils, where the MAXPAGESIZE definition is set to 0x4 (as opposite to standard 0x1). Have you measured the performance using a 64kB page size? If so, how does it compare with the 256kB page size? I was wondering about this as well? Isn't this technically in violation of the ABI? No it isn't the violation. As stated in System V ABI. PowerPC processor supplement (on which the Linux Standard Base Core Specification for PPC32 is based): ... Virtual addresses and file offsets for the PowerPC processor family segments are congruent modulo 64 Kbytes (0x1) or larger powers of 2 So, 256 Kbytes is just a larger case. -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Make fdt_string() return a const pointer
So, like, the other day David Gibson mumbled: Currently, fdt_string() returns a (non-const) char *, despite taking a const void *fdt. This is inconsistent with all the other read-only functions which all return const pointers into the blob. This patch fixes that. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Make helper macros in trees.S more flexible
So, like, the other day David Gibson mumbled: This patch makes the helper macros in trees.S use separate labels for the end of each dt subblock, rather than using only start labels. This means that the macros can now be used to create trees with the subblocks in non-standard orders. In addition, it adds a bunch of extra ; after lines of asm code in macros, making them safe to use in nested macros. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: libfdt: Add missing RW_CHECK_HEADER to fdt_del_node()
So, like, the other day David Gibson mumbled: fdt_del_node(), unlike most of the rw functions does not check the fdt's header with RW_CHECK_HEADER. However, it could make a mess of things if the conditions in RW_CHECK_HEADER aren't met. So, this patch adds the omitted check. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: Disable semantic checks by default
So, like, the other day David Gibson mumbled: At present, dtc makes a lot of semantic checks on the device tree by default, and will refuse to produce output if they fail. This means people tend to need -f to force output despite failing semantic checks rather a lot. This patch splits the device tree checks into structural checks (no bad or duplicate names or phandles) and semantic checks (everything else). By default, only the structural checks are performed, and are fatal. -f will force output even with structural errors (using this in -Idts mode would essentially always be a bad idea, but it might be useful in -Idtb mode for examining a malformed dtb). Semantic checks are only performed if the new -c command line option is supplied, and are always warnings only. Semantic checks will never be performed on a tree with structural errors. This patch is only a stopgap before implementing proper fine-grained error/warning handling, but it should at least get rid of the far-too-frequent need for -f for the time being. This patch removes the -f from the dtc testcases now that it's no longer necessary. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dtc: data.c doesn't need to include dtc-parser.tab.h
So, like, the other day David Gibson mumbled: Presumably we used this #include once, but it's certainly not necessary now. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] DTC: Reformat grammar rules to not mix language syntax and yacc syntax.
So, like, the other day David Gibson mumbled: On Fri, Oct 19, 2007 at 12:42:32PM -0500, Jon Loeliger wrote: Use consistent indenting on all rule actions. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Meh, I kind of did it that way to keep the simple rules less bulky, but I don't really care much either way. Acked-by: David Gibson [EMAIL PROTECTED] Cool. Thanks. Applied. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
request_irq fails to get interrupt 12
Freescale experts. Why on earth can't I request the IRQ for Timer1? static int __init dvr_ph_init(void) { u32 rv; int k; //rv = driver_register(dvr_ph_driver); for (k=0;k64;k++) { rv = request_irq(k,dvrph_isr , 0, dvr_ph, NULL); if (rv!=-38) printkplus(request_irq for %d returns %d, k,rv); } return rv; } Results in: dvr_ph_init145 - enter the routine dvr_ph_init155 - dvr_ph_init161 - request_irq for 16 returns -16 (vector 16 = TMCNT) dvr_ph_init161 - request_irq for 32 returns 0 (vector 32 = FCC1) dvr_ph_init161 - request_irq for 33 returns -16 (vector 33 = FCC2) dvr_ph_init161 - request_irq for 40 returns 0 (vector 40 = SCC1) dvr_ph_init161 - request_irq for 43 returns 0 (vector 43 = SCC4) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
So, like, the other day David Gibson mumbled: On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote: David Gibson [EMAIL PROTECTED] writes: What compiler/platform is this? I can't off the top of my head think of one where size_t shouldn't be promoted to int automatically. Only types narrower than int are subject to integer promotion. Duh, yes. Sorry. So, Hmm. You want the patch as I wrote it applied? Or do you want to use %z in the format instead? It does seem like there is precedent to do that (in the kernel): % grep -r '%z' arch/ arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3 ... arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3 arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */ arch/um/drivers/cow_user.c:limited to %zd characters\n, backing_file, arch/x86/kernel/pci-nommu_64.c: nommu_%s: overflow %Lx+%zu of device mask %Lx\n, Opinions? Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
On Mon, 22 Oct 2007 11:50:52 -0500 Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day David Gibson mumbled: On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote: David Gibson [EMAIL PROTECTED] writes: What compiler/platform is this? I can't off the top of my head think of one where size_t shouldn't be promoted to int automatically. Only types narrower than int are subject to integer promotion. Duh, yes. Sorry. So, Hmm. You want the patch as I wrote it applied? Or do you want to use %z in the format instead? It does seem like there is precedent to do that (in the kernel): % grep -r '%z' arch/ arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3 ... arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3 arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */ arch/um/drivers/cow_user.c:limited to %zd characters\n, backing_file, arch/x86/kernel/pci-nommu_64.c: nommu_%s: overflow %Lx+%zu of device mask %Lx\n, Opinions? %z is fairly common now-a-days. The kernel janitors tend to LART people for not using it rather quickly. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michal Simek Sent: Friday, October 19, 2007 7:28 PM To: [EMAIL PROTECTED] Cc: Stephen Neuendorffer; Grant Likely; Leonid; Arnd Bergmann; linuxppc-dev@ozlabs.org; Wolfgang Reissnegger Subject: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices Hi Steve and all, Here's a full .dts generated using an updated version of gen_mhs_devtree.py, following the proposal. It happens to be a microblaze system, but you get the idea. I think that is no good idea generate dts with all information. Especially information about PVR - number 2 means - Full PVR and you can obtain information directly from PVR. It is waste of memory space. xilinx,pvr = 2; PowerPC does something with the powerpc equivalent of the PVR. We should just do what they do... In my opinion will be better generate only parameters which you want not all. That smells with unusable parameters. In the long term, this may be true. In the short term: 1) dtb size is not the key problem 2) making sure that everything works is a key problem. 3) The code that generates the dts should be as simple as possible, so that we can easily document what it does. In the long term, I'm all for optimizing the device tree that gets built, assuming that it appears to be a problem in real systems. Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
It seems to me there are four issues here: 1) How to describe the audio transport controller; 2) How to describe the codecs; 3) How the various parts are connected together in the device tree; 4) How to describe the layout. How do we want to be consistent with the Efika which uses an AC97 codec that only connects to i2s? Huh? AC'97 isn't I2S. Yeah you probably could hook it up to some I2S device if you do all the interleaving and whatever stuff by hand -- but then you probably shouldn't call the I2S host an I2S anymore, but name it ac97 in the device tree, or this-or-that-i2s-controller-hooked-up- in-this-particular-crazy-way. You will want to know which driver to use for the device, and if it's hooked up in strange and unforeseen ways you want to know about it. I meant an ac97 bus. ac97 is conceptually the same as i2s with the control signals also routed over it. ac97 and i2s are handled in the same PSC on the 5200. Okay. On any specific board, there can _only_ be ac97 or _only_ i2s codecs hooked onto the bus; the device node for the PSC should say which it is, either by having different compatible entries for the different modes, or by having some device-specific property in there saying which it is. Ideally, the name of the node would be i2s resp. ac97 as well. This handles 1). I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Every codec gets its own device node, and its compatible entry describes it uniquely. This is a very basic property of device trees. This handles 2). Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. asoc has a generic ac97 driver. Should the ac97 bus be required to have a entry for the generic ac97 device? It would make loading the driver much easier. If the kernel driver does _not_ recognise the codec in the device tree, it could use a generic ac97 codec driver, if such a thing indeed exists. If on the other hand it knows about the specific codec, it can use a chip- specific driver. AC'97 codecs are addressed over the AC'97 bus, so the codecs should be children of the ac97 bus in the device tree, and have fully qualified names like [EMAIL PROTECTED] or [EMAIL PROTECTED] etc. I2S codecs that are addressed (== its configuration registers written) over I2C should be children of their I2C bus in the device tree, with fully qualified names like [EMAIL PROTECTED]; they should show which I2S bus they sit on, for example by having an i2s-bus property (containing the phandle of the i2s bus) in the codec node. This is 3). Now for 4), the layout thing; you could try to describe the layout in the device tree, but that would probably fail; there just is too much variance. If I understand you correctly, you have a platform-specific layout driver; now you need to find a nice way to probe this from the device tree. Maybe you should just look at the properties in the root node of the device tree for this. _Please_ don't name busses that are not plain I2S i2s in the device tree. At best this means you'll need a quirk in the kernel code to deal with this later. the i2s and ac97 drivers for the mpc5200 already exist. I'm using these preexisting drivers. Sure, but that doesn't mean you cannot fix the way things are probed in those drivers. Bugs are there to fix ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Fri, Oct 19, 2007 at 05:53:08PM -0700, David Miller wrote: From: [EMAIL PROTECTED] (Linas Vepstas) Date: Fri, 19 Oct 2007 19:46:10 -0500 FWIW, it looks like not all that many arches do this; the output for grep -r address_hi * is pretty thin. Then, looking at i386/kernel/io_apic.c as an example, one can see that the msi state save happens by accident if CONFIG_SMP is enabled; and so its surely broekn on uniprocesor machines. I don't see this, in all cases write_msi_msg() will transfer the given *msg to entry-msg by this assignment in drivers/pci/msi.c: void write_msi_msg(unsigned int irq, struct msi_msg *msg) { ... entry-msg = *msg; } So as long as write_msi_msg() is invoked, it will be saved properly. As Michael Ellerman points out, the pseries msi setup is done by firmware, and so this bit never happens. As discussed in the other thread, I'll try to set up a patch for an arch callback for restoring msi state. -linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq fails to get interrupt 12
Ok, so what does it take to expose an interrupt vector on a pq2 PIC?? -Alan Current: / localbus{ ... fundevice1 { interrupts = c 8; interrupt-parent = PIC; }; ... [EMAIL PROTECTED] { PIC: [EMAIL PROTECTED] { #interrupt-cells = 2; interrupt-controller; reg = 10c00 80; compatible = fsl,mpc8248-pic, fsl,pq2-pic; }; Is the above device tree enough on its own? Do I have to write some platform code beyond: static void __init ep8248_pic_init(void) { struct device_node *np = of_find_compatible_node(NULL, NULL, fsl,pq2-pic); if (!np) { printk(KERN_ERR PIC init: can not find cpm-pic node\n); return; } cpm2_pic_init(np); of_node_put(np); } -Alan Hello, Freescale experts. Why on earth can't I request the IRQ for Timer1? Please consule my question on [1] and the answers. [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html bye Silvio Fricke -- -- S. Fricke - MAILTO:[EMAIL PROTECTED] -- Diplom-Informatiker (FH) Linux-Entwicklung ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/2] powerpc: irqtrace support to 64-bit powerpc
On Mon, 2007-10-22 at 15:35 +0200, Johannes Berg wrote: On Mon, 2007-10-15 at 17:28 +1000, Benjamin Herrenschmidt wrote: This adds the low level irq tracing hooks to the powerpc architecture needed to enable full lockdep functionality Some rework from Johannes initial version, removing the asm trampoline that isn't needed (thus improving perfs) and fixing a couple of bugs such as incorrect initial preempt_count on the softirq alternate stack. Hmm. It breaks booting on my quad, I finally got around to testing without this patch and it turns out that it caused the boot failure I reported in another mail. This is with v2.6.23-6623-g55b70a0, a clean tree boots fine but with these two patches applied and configured in it fails during boot, hanging at some point, apparently when userspace is entered. On the other hand, it is fine with my original version. I'll have to find some time to check the differences hunk by hunk I guess. Or I can try on my quad :-) I'll have a look. It did boot on some other machines though. Funny. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: request_irq fails to get interrupt 12
On Mon, 2007-10-22 at 13:55 -0600, Alan Bennett wrote: Ok, so what does it take to expose an interrupt vector on a pq2 PIC?? -Alan Also, if it's the default PIC or if you happen to have the PIC struct irq_host pointer at hand, a quickish way for internal device interrupts is to directly call irq_create_mapping() though using the device-tree is nicer. Ben. Current: / localbus{ ... fundevice1 { interrupts = c 8; interrupt-parent = PIC; }; ... [EMAIL PROTECTED] { PIC: [EMAIL PROTECTED] { #interrupt-cells = 2; interrupt-controller; reg = 10c00 80; compatible = fsl,mpc8248-pic, fsl,pq2-pic; }; Is the above device tree enough on its own? Do I have to write some platform code beyond: static void __init ep8248_pic_init(void) { struct device_node *np = of_find_compatible_node(NULL, NULL, fsl,pq2-pic); if (!np) { printk(KERN_ERR PIC init: can not find cpm-pic node\n); return; } cpm2_pic_init(np); of_node_put(np); } -Alan Hello, Freescale experts. Why on earth can't I request the IRQ for Timer1? Please consule my question on [1] and the answers. [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042061.html bye Silvio Fricke -- -- S. Fricke - MAILTO:[EMAIL PROTECTED] -- Diplom-Informatiker (FH) Linux-Entwicklung ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: On pseries there's a chance it will work for PCI error recovery, but if so it's just lucky that firmware has left everything configured the same way. ? The papr is quite clear that i is up to the OS to restore the msi state after an eeh error. Via direct config space access or via firmware change-msi calls ? Yes I think so. That way we can properly reconfigure via the firmware interface. The other option would be to design some new arch hook to do resume, but just doing a disable/enable seems simpler to me. Err, If you read the code for suspend/resume, it never actually calls disable/enable (and thus doesn't go to the firmware); it calls restore_msi_state() function! If suspend/resume needs to call firmware to restore the state, then, at the moment, suspend/resume is broken. As I mentioned earlier, I presumed that no powerpc laptops currently use msi-enabled devices, as otherwise, this would have been flushed out. I don't know why you keep talking about powerpc laptops here ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] DTC: Minor grammar rule shuffle.
I like to see the basis cases established early in the rule sets, so place empty reduction first. Purely cosmetic. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- dtc-parser.y | 62 +- 1 files changed, 31 insertions(+), 31 deletions(-) diff --git a/dtc-parser.y b/dtc-parser.y index 0d140e5..c213526 100644 --- a/dtc-parser.y +++ b/dtc-parser.y @@ -86,13 +86,13 @@ sourcefile: ; memreserves: - memreserve memreserves + /* empty */ { - $$ = chain_reserve_entry($1, $2); + $$ = NULL; } - | /* empty */ + | memreserve memreserves { - $$ = NULL; + $$ = chain_reserve_entry($1, $2); } ; @@ -122,13 +122,13 @@ nodedef: ; proplist: - proplist propdef + /* empty */ { - $$ = chain_property($2, $1); + $$ = NULL; } - | /* empty */ + | proplist propdef { - $$ = NULL; + $$ = chain_property($2, $1); } ; @@ -164,7 +164,11 @@ propdata: ; propdataprefix: - propdata ',' + /* empty */ + { + $$ = empty_data; + } + | propdata ',' { $$ = $1; } @@ -172,10 +176,6 @@ propdataprefix: { $$ = data_add_label($1, $2); } - | /* empty */ - { - $$ = empty_data; - } ; opt_cell_base: @@ -187,7 +187,11 @@ opt_cell_base: ; celllist: - celllist opt_cell_base DT_CELL + /* empty */ + { + $$ = empty_data; + } + | celllist opt_cell_base DT_CELL { $$ = data_append_cell($1, cell_from_string($3, $2)); @@ -200,14 +204,14 @@ celllist: { $$ = data_add_label($1, $2); } - | /* empty */ - { - $$ = empty_data; - } ; bytestring: - bytestring DT_BYTE + /* empty */ + { + $$ = empty_data; + } + | bytestring DT_BYTE { $$ = data_append_byte($1, $2); } @@ -215,20 +219,16 @@ bytestring: { $$ = data_add_label($1, $2); } - | /* empty */ - { - $$ = empty_data; - } ; subnodes: - subnode subnodes + /* empty */ { - $$ = chain_node($1, $2); + $$ = NULL; } - | /* empty */ + | subnode subnodes { - $$ = NULL; + $$ = chain_node($1, $2); } ; @@ -251,13 +251,13 @@ nodename: ; label: - DT_LABEL + /* empty */ { - $$ = $1; + $$ = NULL; } - | /* empty */ + | DT_LABEL { - $$ = NULL; + $$ = $1; } ; -- 1.5.3.1.139.g9346b ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] DTC: Remove an unneeded %token definition.
Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- dtc-parser.y |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/dtc-parser.y b/dtc-parser.y index c213526..61ed250 100644 --- a/dtc-parser.y +++ b/dtc-parser.y @@ -55,7 +55,6 @@ extern struct boot_info *the_boot_info; %token str DT_CELL %token byte DT_BYTE %token data DT_STRING -%token str DT_UNIT %token str DT_LABEL %token str DT_REF -- 1.5.3.1.139.g9346b ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] DTC: Rewrite the propdata and propdataprefix rules.
After staring at these two rules for a bit, and not quite groking them, I rewrote them into something I think is a bit clearer. With any luck, it's the same language still. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- You be the judge too! dtc-parser.y | 31 ++- 1 files changed, 14 insertions(+), 17 deletions(-) diff --git a/dtc-parser.y b/dtc-parser.y index 61ed250..f0b0178 100644 --- a/dtc-parser.y +++ b/dtc-parser.y @@ -59,7 +59,6 @@ extern struct boot_info *the_boot_info; %token str DT_REF %type data propdata -%type data propdataprefix %type re memreserve %type re memreserves %type cbase opt_cell_base @@ -143,37 +142,35 @@ propdef: ; propdata: - propdataprefix DT_STRING + DT_STRING { - $$ = data_merge($1, $2); + $$ = data_merge(empty_data, $1); } - | propdataprefix '' celllist '' + | '' celllist '' { - $$ = data_merge(data_append_align($1, - sizeof(cell_t)), $3); + $$ = data_merge(data_append_align(empty_data, + sizeof(cell_t)), $2); } - | propdataprefix '[' bytestring ']' + | '[' bytestring ']' { - $$ = data_merge($1, $3); + $$ = data_merge(empty_data, $2); } | propdata DT_LABEL { $$ = data_add_label($1, $2); } - ; - -propdataprefix: - /* empty */ + | propdata ',' DT_STRING { - $$ = empty_data; + $$ = data_merge($1, $3); } - | propdata ',' + | propdata ',' '' celllist '' { - $$ = $1; + $$ = data_merge(data_append_align($1, + sizeof(cell_t)), $4); } - | propdataprefix DT_LABEL + | propdata ',' '[' bytestring ']' { - $$ = data_add_label($1, $2); + $$ = data_merge($1, $4); } ; -- 1.5.3.1.139.g9346b ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Rewrite the propdata and propdataprefix rules.
So, like, the other day Jon Loeliger mumbled: After staring at these two rules for a bit, and not quite groking them, I rewrote them into something I think is a bit clearer. With any luck, it's the same language still. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- You be the judge too! Yeah, so, I botched this one. It's NOT the same language, so don't apply it or think about it at all... jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Bugfix to commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834
From: Grant Likely [EMAIL PROTECTED] Commit 4f9a58d75bfe82ab2b8ba5b8506dfb190a267834 changes the size of AT_VECTOR_SIZE from hard coded '44' to a calculation based on the value of AT_VECTOR_SIZE_ARCH and AT_VECTOR_SIZE_BASE. The change works for arch/powerpc, but it breaks arch/ppc because the needed AT_VECTOR_SIZE_ARCH is not present in include/asm-ppc/system.h and a default value of 0 is used instead. This results in AT_VECTOR_SIZE being too small and it causes a kernel crash on loading init. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- I think this bug fix needs to go in ASAP. I cannot boot my Virtex ppc405 platform without it. Olaf, do I have the correct solution here? Thanks, g. include/asm-ppc/system.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-ppc/system.h b/include/asm-ppc/system.h index cc45780..51df94c 100644 --- a/include/asm-ppc/system.h +++ b/include/asm-ppc/system.h @@ -33,6 +33,7 @@ #define set_mb(var, value) do { var = value; mb(); } while (0) +#define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */ #ifdef CONFIG_SMP #define smp_mb() mb() #define smp_rmb() rmb() ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Tue, Oct 23, 2007 at 07:24:27AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: On pseries there's a chance it will work for PCI error recovery, but if so it's just lucky that firmware has left everything configured the same way. ? The papr is quite clear that i is up to the OS to restore the msi state after an eeh error. Via direct config space access or via firmware change-msi calls ? Direct config space access. It says that the OS is supposed to read the MSI config (after its been set up), save it, and restore it, (via direct config space writes) if the device is ever reset. I don't know why you keep talking about powerpc laptops here ... Well, there are Apple laptops, right? Aren't those the powermac platform? Now, I don't know if they support MSI, but if they do, I get the impression that they might not restore msi state correctly, after being put into hardware suspend. But perhaps I'm mistaken; I was simply grepping for various msi-related functions in various arch subdirectories, comparing x86 to other arches, and noticed that code that would restore msi state seems to be missing for most arches and most powerpc platforms. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git master branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master to get five more commits that fix some bugs for systems using the Freescale embedded 52xx processors and enable them to restart properly. Thanks, Paul. .../powerpc/mpc52xx-device-tree-bindings.txt |4 + arch/powerpc/boot/dts/lite5200.dts | 26 +++ arch/powerpc/boot/dts/lite5200b.dts| 26 +++ arch/powerpc/platforms/52xx/lite5200.c |4 + arch/powerpc/platforms/52xx/mpc52xx_common.c | 71 +++- arch/powerpc/sysdev/bestcomm/bestcomm.c|9 ++- drivers/watchdog/mpc5200_wdt.c |3 + include/asm-powerpc/mpc52xx.h |9 +++ 8 files changed, 109 insertions(+), 43 deletions(-) Grant Likely (1): [POWERPC] bestcomm: Restrict bus prefetch bugfix to original mpc5200 silicon. Marian Balakowicz (4): [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions [POWERPC] Update device tree binding for mpc5200 gpt [POWERPC] Add restart support for mpc52xx based platforms [POWERPC] Enable restart support for lite5200 board ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: [EMAIL PROTECTED] (Linas Vepstas) Date: Mon, 22 Oct 2007 14:54:52 -0500 As discussed in the other thread, I'll try to set up a patch for an arch callback for restoring msi state. Thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
I don't know why you keep talking about powerpc laptops here ... Well, there are Apple laptops, right? Aren't those the powermac platform? Now, I don't know if they support MSI, but if they do, I get the impression that they might not restore msi state correctly, after being put into hardware suspend. But perhaps I'm mistaken; I was simply grepping for various msi-related functions in various arch subdirectories, comparing x86 to other arches, and noticed that code that would restore msi state seems to be missing for most arches and most powerpc platforms. Ah ok, i see. Well, platforms that use write_msi_msg() shouldn't need anything special right ? So only pSeries is an issue here PowerBooks don't indeed have MSI support, though G5's do and some people have been toying around with suspend/resume on them (hibernation only at that stage) but it doesn't matter at this stage. We are specifically talking about pSeries which is the special case here. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 17:23 -0700, David Miller wrote: From: [EMAIL PROTECTED] (Linas Vepstas) Date: Mon, 22 Oct 2007 14:54:52 -0500 As discussed in the other thread, I'll try to set up a patch for an arch callback for restoring msi state. From what it looks like at this stage, pSeries might need to differenciate restoring MSI state after a device reset (PCI error recovery) from restoring MSI state after suspend/resume (if we ever implement that one). The former apparently require manual saving restoring of the config space bits. (Linas, do you have a pointer to the bit of PAPR spec that specifies that we need to save restore the MSI message ourselves ?) For the later (suspend/resume), that will definitely not work, or at least, will not be enough, especially with something like suspend to disk, where we'll need to have the firmware reconfigure the MSIs for us (to make sure, among others, that the interrupt controllers are properly configured for MSIs etc...). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
On Mon, Oct 22, 2007 at 07:36:57AM -0500, Jon Loeliger wrote: So, like, the other day Segher Boessenkool mumbled: Property names have been limited to start with characters from the set [a-zA-Z,._#?]. That is, the digits and the expression symbols have been removed. This cannot work; many property names start with a digit, for example. Are any of those property names in use in any of our DTS files or b-w-o.txt? Not really, no. In fact, with this lexical change, all of our DTS files still produce byte-identical results. I really think this is one of those areas where we may need to stray from the other guideline. Is there a compelling reason somewhere? Really? We may have deprecated te '64-bit' and '32-64-bridge' properties in cpu nodes for the flattened tree, but it already exists in a great number of Apple and IBM trees. It would be poor form for dtc to choke on these trees. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
On Mon, Oct 22, 2007 at 11:55:11AM -0500, Josh Boyer wrote: On Mon, 22 Oct 2007 11:50:52 -0500 Jon Loeliger [EMAIL PROTECTED] wrote: So, like, the other day David Gibson mumbled: On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote: David Gibson [EMAIL PROTECTED] writes: What compiler/platform is this? I can't off the top of my head think of one where size_t shouldn't be promoted to int automatically. Only types narrower than int are subject to integer promotion. Duh, yes. Sorry. So, Hmm. You want the patch as I wrote it applied? Or do you want to use %z in the format instead? It does seem like there is precedent to do that (in the kernel): % grep -r '%z' arch/ arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/alpha/boot/tools/mkbb.c: fprintf(stderr, expected %zd, got %d\n, sizeof(bootblock), nread); arch/m68k/ifpsp060/src/itest.S: mulu.l (0x00.w,%a3,%za4.l*8),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (-0x10.w,%za3,%a4.l*1),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l (ea_77_mem+0x00.w,%pc,%za4.l*8),%d2:%d3 ... arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc,%zd4.l*1]),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%pc],%zd4.l*8,0x20.l),%d2:%d3 arch/m68k/ifpsp060/src/itest.S: mulu.l ([EASTORE.l,%zpc],%d4.l*8),%d2:%d3 arch/um/drivers/cow_user.c: /* Below, %zd is for a size_t value */ arch/um/drivers/cow_user.c:limited to %zd characters\n, backing_file, arch/x86/kernel/pci-nommu_64.c: nommu_%s: overflow %Lx+%zu of device mask %Lx\n, Opinions? %z is fairly common now-a-days. The kernel janitors tend to LART people for not using it rather quickly. Yes, I think %z is preferable. It used to be a glibc (et al) extension, but I think it's now specified in C99 (we should double check that). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Minor grammar rule shuffle.
On Mon, Oct 22, 2007 at 04:59:45PM -0500, Jon Loeliger wrote: I like to see the basis cases established early in the rule sets, so place empty reduction first. Purely cosmetic. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] As with the change of { } formatting, I don't really care much either way on this one. So Acked-by: David Gibson [EMAIL PROTECTED] -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Remove an unneeded %token definition.
On Mon, Oct 22, 2007 at 05:00:34PM -0500, Jon Loeliger wrote: Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Oops. Can't even remeber what that one was ever there for. Acked-by: David Gibson [EMAIL PROTECTED] -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Rewrite the propdata and propdataprefix rules.
On Mon, Oct 22, 2007 at 05:37:57PM -0500, Jon Loeliger wrote: So, like, the other day Jon Loeliger mumbled: After staring at these two rules for a bit, and not quite groking them, I rewrote them into something I think is a bit clearer. With any luck, it's the same language still. Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- You be the judge too! Yeah, so, I botched this one. It's NOT the same language, so don't apply it or think about it at all... Yeah, I remember finding the whole propdataprefix confusing myself. But the form was suggested by someone (forgotten whom now), and I never did figure out a better way of doing it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
Property names have been limited to start with characters from the set [a-zA-Z,._#?]. That is, the digits and the expression symbols have been removed. This cannot work; many property names start with a digit, for example. Are any of those property names in use in any of our DTS files or b-w-o.txt? Not really, no. In fact, with this lexical change, all of our DTS files still produce byte-identical results. I really think this is one of those areas where we may need to stray from the other guideline. Is there a compelling reason somewhere? Really? We may have deprecated te '64-bit' and '32-64-bridge' properties in cpu nodes for the flattened tree, but it already exists in a great number of Apple and IBM trees. Huh? 64-bit isn't deprecated I hope, just the 32-bit thing (that never was defined) is. It would be poor form for dtc to choke on these trees. Yah. Small incompatibilities add up :-( Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
Yes, I think %z is preferable. It used to be a glibc (et al) extension, but I think it's now specified in C99 (we should double check that). It is. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Audio codec device tree entries
Is this what the device tree entries should look like? First example is ac97 audio: [EMAIL PROTECTED] { // PSC1 device_type = sound; compatible = mpc5200b-psc-ac97\0mpc5200-psc-ac97; cell-index = 0; reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; codec-handle = codec0 }; [EMAIL PROTECTED] { // use to trigger loading platform specific fabric driver device_type = pseudo-sound }; codec0:[EMAIL PROTECTED] { device_type = codec compatible = stac9766\0ac97 }; Second is i2s/i2c connected: How do I link this to the i2c bus? [EMAIL PROTECTED] { // PSC1 device_type = sound; compatible = mpc5200b-psc-i2s\0mpc5200-psc-i2s; cell-index = 0; reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; codec-handle = codec0 }; [EMAIL PROTECTED] { device_type = i2c; compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c; cell-index = 0; reg = 3d00 40; interrupts = 2 f 0; interrupt-parent = mpc5200_pic; fsl5200-clocking; }; [EMAIL PROTECTED] { // use to trigger loading platform specific fabric driver device_type = pseudo-sound }; codec0:[EMAIL PROTECTED] { device_type = codec compatible = tas5508 }; -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Allow sysfs_remove_group() to be called on non-added groups
On 9/13/07, Michael Ellerman [EMAIL PROTECTED] wrote: It would be nice to be able to do: for_each_thing(thing) { error = sysfs_create_group(thing-kobj, attrs); if (error) { for_each_thing(thing) sysfs_remove_group(thing-kobj, attrs); return error; } } But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes were never added. As discussed here ... http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html .. we should just return in that case instead of BUG'ing. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- fs/sysfs/group.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c index f318b73..a256775 100644 --- a/fs/sysfs/group.c +++ b/fs/sysfs/group.c @@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj, if (grp-name) { sd = sysfs_get_dirent(dir_sd, grp-name); - BUG_ON(!sd); + if (!sd) + return; } else sd = sysfs_get(dir_sd); Hi Greg, I didn't see this in your series, any objections? AFAICT it still applies. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] DTC: Remove the need for the GLR Parser.
On Mon, Oct 22, 2007 at 04:13:54PM -0500, Jon Loeliger wrote: Previously, there were a few shift/reduce and reduce/reduce errors in the grammar that were being handled by the not-so-popular GLR Parser technique. I haven't actually heard anyone whinge about glr-parser... Flip a right-recursive stack-abusing rule into a left-recursive stack-friendly rule and clear up three messes in one shot: No more conflicts, no need for the GLR parser, and friendlier stackness. Ouch. I'm feeling a bit stupid now, I really thought our conflicts were somewhere else. Specifically I thought the problem was that we needed to look ahead more tokens that we were able to differentiate between property and subnode definitions, i.e. between: label propname = and label propname { Except... I'm almost certain the conflicts first appeared when I added labels, and I can't see how that would affect this. Well, colour me baffled. Especially since the comments and content of commit 4102d840d993e7cce7d5c5aea8ef696dc81236fc (second commit in the entire history!) appear to back up my memory of this. I used to have a lookahead hack in the lexer to remove the conflict. But this patch certainly seems to make the conflicts go away, so I'm confused. Well, regardless of that, I have a few concerns. First, a trivial one: I remember leaving this as a right-recursion, despite the stack-nastiness, because that way the properties end up in the same order as in the source. I think that behaviour is worth preserving, but of course we can do it with left-recursion by changing chain_property() to add to the end of the list instead of the beginning. Also, if we're going to avoid right-recursion here, we should do so for the 'subnodes' productions as well, which is completely analogous. More significantly, I don't know that we want to burn our bridges with glr-parser. glr-parser is a beautiful algorithm which means we can use essentially whatever form of grammar is the easiest to work with without having to fiddle about to ensure it's LALR(1). This could still be useful if we encounter some less easily finessable grammar construct in future. And even without glr-parser, I'm still uncomfortable with the lexer-parser execution ordering issues with the current /dts-version/ proposal. It may now be true that the order is guaranteed to be correct, but it's still not exactly obvious. It seems to me that the version change introduces a lexical change to the input format, and should therefore be handled at the lexical level. And I think there are other potential advantages to parsing the version identifier as a token, rather than as an integer (such as being able to define entirely different grammars for different versions, if we have to). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On Mon, Oct 22, 2007 at 09:59:00PM -0400, Jon Smirl wrote: Is this what the device tree entries should look like? First example is ac97 audio: [EMAIL PROTECTED] { // PSC1 device_type = sound; Kill all these device_type values. compatible = mpc5200b-psc-ac97\0mpc5200-psc-ac97; dtc now supports the more readable: compatible = mpc5200b-psc-ac97, mpc5200-psc-ac97; Use it. cell-index = 0; cell-index should only be present if the device is within a system-on-chip *and* that device number is used to program some global register somewhere. reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; codec-handle = codec0 }; [EMAIL PROTECTED] { // use to trigger loading platform specific fabric driver device_type = pseudo-sound }; This looks completely bogus. The device tree should represent actual hardware. codec0:[EMAIL PROTECTED] { Space after the : please. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Device trees and audio codecs
On 10/21/07, Jon Smirl [EMAIL PROTECTED] wrote: I have received conflicting opinions as to whether a codec hooked to an ac97 bus should get a chip specific codec entry in the device tree. Without the codec specific entry only generic ac97 features can be used. The Efika has a STA9766. Looking at the data sheet for the chip I see that it implements some proprietary functions in addition to the standard ones. You definitely want the codec node on the control bus. This is analogous to how Ethernet PHYs are handled. The PHY nodes are children of an MDIO node (because that's the control path). The ethernet MAC node contains a phandle to the PHY. In I2S/I2C terms, the CODEC ~= MAC, I2C ~= MDIO and I2S ~= MAC. In AC97 terms this analogy doesn't work because AC97 doesn't separate the control and data interfaces. An AC97 codec is simply a child of an AC97 controller. For the MPC5200; the device tree should reflect the required mode. If the PSC needs to be in AC97 mode, then the device tree should say compatible = fsl,mpc5200b-psc-ac97. If the PSC needs to be in I2C mode, then it should be compatible = fsl,mpc5200b-psc-i2s. For the 5200 PSCs, the device node not only reflects the hardware (a PSC core), but also reflects the schematic design (it is wired either as an I2S bus or an AC97 bus). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
-Original Message- From: Medve Emilian-EMMEDVE1 Sent: Monday, October 22, 2007 9:48 PM To: David Miller Cc: [EMAIL PROTECTED]; Li Yang-r58472; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org Subject: RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings Hello David, No piece of code in the kernel should live in a vacuum. In order to improve overall code quality, every piece of driver code should avoid assuming things about pointer sizes and things of this nature. I'm afraid we might be talking about orthogonal issues here. I actively agree that all code (not only kernel) should be written up to the coding/quality standards you mention above, but I see a difference between fixing a warning and making a driver portable (to 64-bit PowerPCs, to other platforms, etc.). If there is a kernel todo list somewhere lets add to it the task to make the ucc_geth more portable. Then the driver can get enabled into the build on every platform, and therefore nobody will break the build of this driver again since it will get hit by allmodconfig et al. builds even on platforms other than the one it is meant for. This hack fix is not acceptable, really. Are you suggesting we leave those warnings there until somebody decides to fix all the portability issues of this driver? My patch is a small and insignificant improvement and not the revolution you're asking for, but is an small improvement today (I dislike warnings) vs. an improbable big one in the future. I'd say we can not use our way of doing things while working with the community. The community has to consider the kernel as a whole and thus has its own virtue. The warning has been there for some time. It stays as an indicator that we have something to do to improve the portability. I will work on a patch to fix this portability issue. - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Audio codec device tree entries
On 10/22/07, Jon Smirl [EMAIL PROTECTED] wrote: Is this what the device tree entries should look like? First example is ac97 audio: [EMAIL PROTECTED] { // PSC1 device_type = sound; compatible = mpc5200b-psc-ac97\0mpc5200-psc-ac97; This format is so, like. 3 months ago. :-) dtc now supports a comma separated format: property = string1, string2, string3 Embedded nulls no longer needed. cell-index = 0; reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; codec-handle = codec0 }; Isn't this the ac97 bus node? Can't the ac97 codecs simply be children of this bus? [EMAIL PROTECTED] { // use to trigger loading platform specific fabric driver device_type = pseudo-sound }; I don't think this is a good idea. The device tree is for describing your hardware; so the layout should reflect that. Make the platform code do the right thing with the real nodes. codec0:[EMAIL PROTECTED] { device_type = codec compatible = stac9766\0ac97 }; Second is i2s/i2c connected: How do I link this to the i2c bus? [EMAIL PROTECTED] { // PSC1 device_type = sound; compatible = mpc5200b-psc-i2s\0mpc5200-psc-i2s; cell-index = 0; reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; codec-handle = codec0 }; [EMAIL PROTECTED] { device_type = i2c; compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c; cell-index = 0; reg = 3d00 40; interrupts = 2 f 0; interrupt-parent = mpc5200_pic; fsl5200-clocking; }; [EMAIL PROTECTED] { // use to trigger loading platform specific fabric driver device_type = pseudo-sound }; codec0:[EMAIL PROTECTED] { device_type = codec compatible = tas5508 }; I think this is what you want: [EMAIL PROTECTED] { // PSC1 compatible = fsl,mpc5200b-psc-ac97,fsl,mpc5200-psc-ac97; cell-index = 0; reg = 2000 100; #address-cells = 1; #size-cells = 0; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; // The following codec stuff could be a little off; It has been a while since I've looked // at ac97 codec interfacing, but if I remember correctly you can have multiple // codecs on an ac97 bus; an audio codec and a modem codec. The following // reflects that understanding... [EMAIL PROTECTED] { // This could be the audio codec reg = 0; compatible = stac9766,ac97-audio }; [EMAIL PROTECTED] { // This could be the modem codec reg = 1; compatible = super-sexy-modem-codec,ac97-modem }; }; // Now here's a big example for i2c. // I've shown 3 audio interfaces; 2 i2s busses and 1 i2c controller. // This may not be realistic on a 5200, but it is a possible scenario and this shows // that it can be handled elegantly. [EMAIL PROTECTED] { // PSC1 compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s; cell-index = 0; reg = 2000 100; interrupts = 2 1 0; interrupt-parent = mpc5200_pic; // There are 2 codecs on this i2s bus; either only one at a time can be used, or // (if both the i2s controller and codecs support it) both at the same time if audio // stream interleaving is supported. codec-handle = codec0 codec2; }; [EMAIL PROTECTED] { // PSC2 compatible = fsl,mpc5200b-psc-i2s,fsl,mpc5200-psc-i2s; cell-index = 0; reg = 2200 100; interrupts = 2 2 0; interrupt-parent = mpc5200_pic; codec-handle = codec1; }; [EMAIL PROTECTED] { compatible = fsl,mpc5200b-i2c, fsl,mpc5200-i2c, fsl-i2c; #address-cells = 1; #size-cells = 0; cell-index = 0; reg = 3d00 40; interrupts = 2 f 0; interrupt-parent = mpc5200_pic; fsl5200-clocking; codec0: [EMAIL PROTECTED] { compatible = mfg,tas5508; reg = 0; }; codec1: [EMAIL PROTECTED] { compatible = mfg,tas5508; reg = 1; }; codec2: [EMAIL PROTECTED] { compatible = mfg,tas5508; reg = 2; }; }; So, this scheme describes the hardware, but it does not describe 2 of your questions: 1. How does the device tree describe the myriad of possible circuits that an audio codec can get dropped into, and 2. How do the drivers get probed For question #1, I think the answer is simple... it doesn't try. :-) As was described in the previous thread, trying to describe the circuit is very complex and figuring out what software would do with such a description is even worse. Instead, I propose the following: - as much as possible, make the board firmware and the platform setup code configure the GPIOs, port_config, and other 'fixed' configuration - make the driver code look at either the board model/compatible properties or add a
powerpc: Fix fallout from sg_page() changes
Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15: In file included from include/linux/dma-mapping.h:52, from drivers/base/dma-mapping.c:10: include/asm/dma-mapping.h: In function 'dma_map_sg': include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page' include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page' include/asm/dma-mapping.h:288: error: 'struct scatterlist' has no member named 'page' include/asm/dma-mapping.h:289: error: 'struct scatterlist' has no member named 'page' include/asm/dma-mapping.h:290: error: 'struct scatterlist' has no member named 'page' include/asm/dma-mapping.h: In function 'dma_sync_sg_for_cpu': include/asm/dma-mapping.h:331: error: 'struct scatterlist' has no member named 'page' drivers/scsi/ps3rom.c: In function 'fetch_to_dev_buffer': drivers/scsi/ps3rom.c:150: error: 'struct scatterlist' has no member named 'page' Signed-off-by: Olof Johansson [EMAIL PROTECTED] diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h index 65be95d..ff52013 100644 --- a/include/asm-powerpc/dma-mapping.h +++ b/include/asm-powerpc/dma-mapping.h @@ -285,9 +285,9 @@ dma_map_sg(struct device *dev, struct scatterlist *sgl, int nents, BUG_ON(direction == DMA_NONE); for_each_sg(sgl, sg, nents, i) { - BUG_ON(!sg-page); - __dma_sync_page(sg-page, sg-offset, sg-length, direction); - sg-dma_address = page_to_bus(sg-page) + sg-offset; + BUG_ON(!sg_page(sg)); + __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction); + sg-dma_address = page_to_bus(sg_page(sg)) + sg-offset; } return nents; @@ -328,7 +328,7 @@ static inline void dma_sync_sg_for_cpu(struct device *dev, BUG_ON(direction == DMA_NONE); for_each_sg(sgl, sg, nents, i) - __dma_sync_page(sg-page, sg-offset, sg-length, direction); + __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction); } static inline void dma_sync_sg_for_device(struct device *dev, @@ -341,7 +341,7 @@ static inline void dma_sync_sg_for_device(struct device *dev, BUG_ON(direction == DMA_NONE); for_each_sg(sgl, sg, nents, i) - __dma_sync_page(sg-page, sg-offset, sg-length, direction); + __dma_sync_page(sg_page(sg), sg-offset, sg-length, direction); } static inline int dma_mapping_error(dma_addr_t dma_addr) diff --git a/drivers/scsi/ps3rom.c b/drivers/scsi/ps3rom.c index 03f19b8..17b4a7c 100644 --- a/drivers/scsi/ps3rom.c +++ b/drivers/scsi/ps3rom.c @@ -147,7 +147,7 @@ static int fetch_to_dev_buffer(struct scsi_cmnd *cmd, void *buf) req_len = fin = 0; scsi_for_each_sg(cmd, sgpnt, scsi_sg_count(cmd), k) { - kaddr = kmap_atomic(sg_page(sgpnt-page), KM_IRQ0); + kaddr = kmap_atomic(sg_page(sgpnt), KM_IRQ0); len = sgpnt-length; if ((req_len + len) buflen) { len = buflen - req_len; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
In my opinion will be better generate only parameters which you want not all. That smells with unusable parameters. In the long term, this may be true. In the short term: 1) dtb size is not the key problem Yes of course 2) making sure that everything works is a key problem. 3) The code that generates the dts should be as simple as possible, so that we can easily document what it does. Yes but you must document every parameter which your generate do. The better way is document only parameters which you want use. In the long term, I'm all for optimizing the device tree that gets built, assuming that it appears to be a problem in real systems. We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu) where you can simply add parameter which you want to use. If you want use any parameter add it. For microblaze cpu - line 1184. And for others peripherals lines 926-980. (The last parameter of function call). Which parameters do you want for PPC405, Grant? Regards, Michal Simek This is example of generator. / { model = mONStR; chosen { linux,platform = 600; bootargs = root=/dev/xsysace/disc0/part2; } ; cpus { #size-cells = 0; #cpus = 0 ; #address-cells = 1; microblaze_0,5.00.c { 32-bit; linux,boot-cpu; device_type = cpu; reg = 0; clock-frequency = 5f5e1000; timebase-frequency = 1FCA055; i-cache-line-size = 2000; i-cache-size = 10; d-cache-line-size = 2000; d-cache-size = 10; xilinx,pvr = 0; xilinx,debug-enabled = 1; xilinx,fsl-links = 0; } ; } ; [EMAIL PROTECTED] { compatible = opb_mdm_2.00.a\0opb_mdm; name = debug_module; reg = 4140 1 ; device_type = opb_mdm; xilinx,mb-dbg-ports = 1; xilinx,uart-width = 8; xilinx,use-uart = 1; } ; [EMAIL PROTECTED] { compatible = opb_uartlite_1.00.b\0opb_uartlite; name = RS232_Uart_1; interrupts = 4 0 ; reg = 4060 1 ; device_type = opb_uartlite; xilinx,baudrate = 2580; xilinx,data-bits = 8; xilinx,clk-freq = 5f5e100; xilinx,odd-parity = 0; xilinx,use-parity = 0; } ; [EMAIL PROTECTED] { compatible = opb_ethernet_1.04.a\0opb_ethernet; name = Ethernet_MAC; interrupts = 3 0 ; reg = 40c0 1 ; device_type = opb_ethernet; xilinx,cam-exist = 0; xilinx,dev-blk-id = 1; xilinx,dev-mir-enable = 1; xilinx,dma-present = 1; xilinx,include-dev-pencoder = 1; xilinx,ipif-rdfifo-depth = 8000; xilinx,ipif-wrfifo-depth = 8000; xilinx,mii-exist = 1; } ; [EMAIL PROTECTED] { compatible = opb_sysace_1.00.c\0opb_sysace; name = SysACE_CompactFlash; reg = 4182 1 ; device_type = opb_sysace; xilinx,mem-width = 10; } ; [EMAIL PROTECTED] { compatible = opb_gpio_3.01.b\0opb_gpio; name = LEDs_4Bit; reg = 4000 1 ; device_type = opb_gpio; xilinx,gpio-width = 4; xilinx,is-dual = 0; } ; [EMAIL PROTECTED] { edk_name = DDR_256MB_32MX64_rank1_row13_col10_cl2_5; compatible = opb_ddr; memreg:reg = 3000 1000 ; device_type = memory; } ; [EMAIL PROTECTED] { compatible = opb_ps2_dual_ref_1.00.a\0opb_ps2_dual_ref; name = PS2_Ports; interrupts = 2 0 ; interrupts = 1 0 ; reg = 7a40 1 ; device_type = opb_ps2_dual_ref; } ; [EMAIL PROTECTED] { compatible = opb_timer_1.00.b\0opb_timer; name = opb_timer_1; interrupts = 0 0 ; reg = 41c0 1 ; device_type = opb_timer; xilinx,count-width = 20; xilinx,one-timer-only = 0; } ; [EMAIL PROTECTED] { compatible = opb_intc_1.00.c\0opb_intc; name = opb_intc_0; reg = 4120 1 ; device_type = opb_intc;
[PATCH] Allow sysfs_remove_group() to be called on non-added groups
It would be nice to be able to do: for_each_thing(thing) { error = sysfs_create_group(thing-kobj, attrs); if (error) { for_each_thing(thing) sysfs_remove_group(thing-kobj, attrs); return error; } } But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes were never added. As discussed here ... http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html .. we should just return in that case instead of BUG'ing. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- fs/sysfs/group.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c index f318b73..a256775 100644 --- a/fs/sysfs/group.c +++ b/fs/sysfs/group.c @@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj, if (grp-name) { sd = sysfs_get_dirent(dir_sd, grp-name); - BUG_ON(!sd); + if (!sd) + return; } else sd = sysfs_get(dir_sd); -- 1.5.1.3.g7a33b ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with allyesconfig kernel build
On Tue, 23 Oct 2007 14:02:31 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: This was first noted with the -mm tree, but has now migrated into Linus' tree. Yeah, sorry, I didn't know what to do about that. I'm not even sure which patch caused it. An allyesconfig build dies in the link stage like this: /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x8160): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern /usr/bin/ld: arch/powerpc/kernel/head_64.o(.text+0x81c4): sibling call optimization to `.text.init.refok' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text.init.refok' extern /usr/bin/ld: final link failed: Bad value We already compile with -mminimal-toc and adding -fno-optimize-sibling-call did not help. Intuiting the obvious, I changed all the _INIT_STATIC and _INIT_GLOBAL uses in head_64.S back to _STATIC and _GLOBAL (which just moves the code from .text.init.refok to .text). Now the linker segfaults instead. :-) /bin/sh: line 1: 5260 Segmentation fault ld -m elf64ppc -Bstatic --emit-relocs --build-id -o .tmp_vmlinux1 -T arch/powerpc/kernel/vmlinux.lds arch/powerpc/kernel/head_64.o arch/powerpc/kernel/entry_64.o arch/powerpc/kernel/fpu.o init/built-in.o --start-group usr/built-in.o arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o arch/powerpc/platforms/built-in.o arch/powerpc/xmon/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a lib/built-in.o drivers/built-in.o sound/built-in.o arch/powerpc/oprofile/built-in.o net/built-in.o --end-group make[1]: *** [.tmp_vmlinux1] Error 139 $ ld --version GNU ld (GNU Binutils for Debian) 2.18 I take this as an improvement :-) We link .text.init.refok immediately after .text, but with allyesconfig, .text ends up very large. The --emit-relocs is a product of something else I am working on. So I took that out and now get a whole lot more messages like: /usr/bin/ld: net/built-in.o(.fixup+0x4): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern /usr/bin/ld: net/built-in.o(.fixup+0xc): sibling call optimization to `.text' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `.text' extern Anyone have any ideas? I still don't know ;) What did we do which caused all this to start happening? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Mon, 2007-10-22 at 13:13 -0500, Linas Vepstas wrote: On Mon, Oct 22, 2007 at 11:49:24AM +1000, Michael Ellerman wrote: On pseries there's a chance it will work for PCI error recovery, but if so it's just lucky that firmware has left everything configured the same way. ? The papr is quite clear that i is up to the OS to restore the msi state after an eeh error. Perhaps. I see R1-7.3.10.5.1-10, which says we should restore the config space after a reset operation, but after an isolate/unisolate we must recall RTAS. I thought EEH was doing the isolate/unisolate, but if it's just a reset then just blatting the config space back should work. Yes I think so. That way we can properly reconfigure via the firmware interface. The other option would be to design some new arch hook to do resume, but just doing a disable/enable seems simpler to me. Err, If you read the code for suspend/resume, it never actually calls disable/enable (and thus doesn't go to the firmware); it calls restore_msi_state() function! I know. That was a proposed solution, to explicitly call disable/enable instead of restore_msi_state(). If suspend/resume needs to call firmware to restore the state, then, at the moment, suspend/resume is broken. As I mentioned earlier, I presumed that no powerpc laptops currently use msi-enabled devices, as otherwise, this would have been flushed out. On _pseries_ suspend/resume with MSI is broken. The other powerpc platforms that implement MSI should be fine, although I don't think anyone's tested them, because they're not laptops and so suspend/resume is not that interesting. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a commit that adds Vitaly Bordug as a maintainer for the powerpc embedded 8xx processors. This is something that Marcelo asked me to push ages ago, but it kept falling through the cracks. Thanks, Paul. MAINTAINERS |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Marcelo Tosatti (1): [POWERPC] Add Vitaly Bordug as PPC8xx maintainer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
IB/ehca: Fix sg_page() fallout
More fallout from sg_page changes, found with powerpc allyesconfig: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1': drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate': drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2': drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page' Signed-off-by: Olof Johansson [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c index da88738..a3037f3 100644 --- a/drivers/infiniband/hw/ehca/ehca_mrmw.c +++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c @@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo *pginfo, list_for_each_entry_continue( chunk, ((pginfo-u.usr.region-chunk_list)), list) { for (i = pginfo-u.usr.next_nmap; i chunk-nmap; ) { - pgaddr = page_to_pfn(chunk-page_list[i].page) + pgaddr = page_to_pfn(sg_page(chunk-page_list[i])) PAGE_SHIFT ; *kpage = phys_to_abs(pgaddr + (pginfo-next_hwpage * @@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist *page_list, { int t; for (t = start_idx; t = end_idx; t++) { - u64 pgaddr = page_to_pfn(page_list[t].page) PAGE_SHIFT; + u64 pgaddr = page_to_pfn(sg_page(page_list[t])) PAGE_SHIFT; ehca_gen_dbg(chunk_page=%lx value=%016lx, pgaddr, *(u64 *)abs_to_virt(phys_to_abs(pgaddr))); if (pgaddr - PAGE_SIZE != *prev_pgaddr) { @@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo *pginfo, chunk, ((pginfo-u.usr.region-chunk_list)), list) { for (i = pginfo-u.usr.next_nmap; i chunk-nmap; ) { if (nr_kpages == kpages_per_hwpage) { - pgaddr = ( page_to_pfn(chunk-page_list[i].page) + pgaddr = ( page_to_pfn(sg_page(chunk-page_list[i])) PAGE_SHIFT ); *kpage = phys_to_abs(pgaddr); if ( !(*kpage) ) { ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] bootwrapper: Allow wrapper script to execute verbosely
From: Grant Likely [EMAIL PROTECTED] Allow wrapper script to print verbose progress when the V is set in the environment. Signed-off-by: Grant Likely [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] --- arch/powerpc/boot/wrapper |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index 39b27e5..347639c 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -21,6 +21,11 @@ # (default ./arch/powerpc/boot) # -W dir specify working directory for temporary files (default .) +# Allow for verbose output +if [ $V = 1 ]; then +set -x +fi + # defaults kernel= ofile=zImage ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] Device tree bindings for Xilinx devices
From: Grant Likely [EMAIL PROTECTED] Signed-off-by: Grant Likely [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] --- Documentation/powerpc/booting-without-of.txt | 261 ++ 1 files changed, 261 insertions(+), 0 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index a96e853..59df69d 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -52,6 +52,7 @@ Table of Contents i) Freescale QUICC Engine module (QE) j) CFI or JEDEC memory-mapped NOR flash k) Global Utilities Block + l) Xilinx IP cores VII - Specifying interrupt information for devices 1) interrupts property @@ -2242,6 +2243,266 @@ platforms are moved over to use the flattened-device-tree model. available. For Axon: 0x012a + l) Xilinx IP cores + + The Xilinx EDK toolchain ships with a set of IP cores (devices) for use + in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range + of standard device types (network, serial, etc.) and miscellanious + devices (gpio, LCD, spi, etc). Also, since these devices are + implemented within the fpga fabric every instance of the device can be + synthesised with different options that change the behaviour. + + Each IP-core has a set of parameters which the FPGA designer can use to + control how the core is synthesized. Historically, the EDK tool would + extract the device parameters relevant to device drivers and copy them + into an 'xparameters.h' in the form of #define symbols. This tells the + device drivers how the IP cores are configured, but it requres the kernel + to be recompiled every time the FPGA bitstream is resynthesized. + + The new approach is to export the parameters into the device tree and + generate a new device tree each time the FPGA bitstream changes. The + parameters which used to be exported as #defines will now become + properties of the device node. In general, device nodes for IP-cores + will take the following form: + + (name)@(base-address) { + compatible = xlnx,(ip-core-name)-(HW_VER) +[, (list of compatible devices), ...]; + reg = (baseaddr) (size); + interrupt-parent = interrupt-controller-phandle; + interrupts = ... ; + xlnx,(parameter1) = (string-value); + xlnx,(parameter2) = (int-value); + }; + + (ip-core-name): the name of the ip block (given after the BEGIN + directive in system.mhs). Should be in lowercase + and all underscores '_' converted to dashes '-'. + (name): is derived from the PARAMETER INSTANCE value. + (parameter#): C_* parameters from system.mhs. The C_ prefix is + dropped from the parameter name, the name is converted + to lowercase and all underscore '_' characters are + converted to dashes '-'. + (baseaddr): the C_BASEADDR parameter. + (HW_VER): from the HW_VER parameter. + (size): equals C_HIGHADDR - C_BASEADDR + 1 + + Typically, the compatible list will include the exact IP core version + followed by an older IP core version which implements the same + interface or any other device with the same interface. + + 'reg', 'interrupt-parent' and 'interrupts' are all optional properties. + + For example, the following block from system.mhs: + + BEGIN opb_uartlite + PARAMETER INSTANCE = opb_uartlite_0 + PARAMETER HW_VER = 1.00.b + PARAMETER C_BAUDRATE = 115200 + PARAMETER C_DATA_BITS = 8 + PARAMETER C_ODD_PARITY = 0 + PARAMETER C_USE_PARITY = 0 + PARAMETER C_CLK_FREQ = 5000 + PARAMETER C_BASEADDR = 0xEC10 + PARAMETER C_HIGHADDR = 0xEC10 + BUS_INTERFACE SOPB = opb_7 + PORT OPB_Clk = CLK_50MHz + PORT Interrupt = opb_uartlite_0_Interrupt + PORT RX = opb_uartlite_0_RX + PORT TX = opb_uartlite_0_TX + PORT OPB_Rst = sys_bus_reset_0 + END + + becomes the following device tree node: + + [EMAIL PROTECTED] { + device_type = serial; + compatible = xlnx,opb-uartlite-1.00.b; + reg = ec10 1; + interrupt-parent = opb-intc; + interrupts = 1 0; // got this from the opb_intc parameters + current-speed = d#115200; // standard serial device prop + clock-frequency = d#5000; // standard serial device prop + xlnx,data-bits = 8; + xlnx,odd-parity = 0; + xlnx,use-parity = 0; +
[PATCH 2/4] bootwrapper: Bail from script if any command fails
From: Grant Likely [EMAIL PROTECTED] Add the 'set -e' command to the wrapper script so that if any command fails then the script will automatically exit Signed-off-by: Grant Likely [EMAIL PROTECTED] Acked-by: David Gibson [EMAIL PROTECTED] --- arch/powerpc/boot/wrapper | 27 ++- 1 files changed, 10 insertions(+), 17 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index 347639c..5ae48f4 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -21,6 +21,9 @@ # (default ./arch/powerpc/boot) # -W dir specify working directory for temporary files (default .) +# Stop execution if any command fails +set -e + # Allow for verbose output if [ $V = 1 ]; then set -x @@ -116,7 +119,7 @@ if [ -n $dts ]; then if [ -z $dtb ]; then dtb=$platform.dtb fi -dtc -O dtb -o $dtb -b 0 -V 16 $dts || exit 1 +dtc -O dtb -o $dtb -b 0 -V 16 $dts fi if [ -z $kernel ]; then @@ -287,23 +290,13 @@ ps3) rm -f $object/otheros.bld -msg=$(dd if=$ofile.bin of=$ofile.bin conv=notrunc \ -skip=$overlay_dest seek=$system_reset_kernel \ -count=$overlay_size bs=1 21) - -if [ $? -ne 0 ]; then - echo $msg - exit 1 -fi +dd if=$ofile.bin of=$ofile.bin conv=notrunc \ +skip=$overlay_dest seek=$system_reset_kernel \ +count=$overlay_size bs=1 -msg=$(dd if=$ofile.bin of=$ofile.bin conv=notrunc \ -skip=$system_reset_overlay seek=$overlay_dest \ -count=$overlay_size bs=1 21) - -if [ $? -ne 0 ]; then - echo $msg - exit 2 -fi +dd if=$ofile.bin of=$ofile.bin conv=notrunc \ +skip=$system_reset_overlay seek=$overlay_dest \ +count=$overlay_size bs=1 gzip --force -9 --stdout $ofile.bin $object/otheros.bld ;; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] Misc patches for the 2.6.24 merge window
Paulus, Here is the last set of patches that I'd like to get in before Linus slams the merge window shut. They're pretty minor changes. The wrapper patches make it easier to debug and catch errors and David has already okayed them. There's a speedup on the uartlite driver, and then a chunk of documentation for the Xilinx device tree bindings. Josh, can you please ack or nack the documentation change? Peter, any issues with the uartlite change? Cheers, g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [microblaze-uclinux] Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
On Tue, Oct 23, 2007 at 06:07:56AM +0200, Michal Simek wrote: In my opinion will be better generate only parameters which you want not all. That smells with unusable parameters. In the long term, this may be true. In the short term: 1) dtb size is not the key problem Yes of course 2) making sure that everything works is a key problem. 3) The code that generates the dts should be as simple as possible, so that we can easily document what it does. Yes but you must document every parameter which your generate do. The better way is document only parameters which you want use. In the long term, I'm all for optimizing the device tree that gets built, assuming that it appears to be a problem in real systems. We can optimize now. I made new version of my generator u-boot_v3_00_a (monstr.eu) where you can simply add parameter which you want to use. If you want use any parameter add it. For microblaze cpu - line 1184. And for others peripherals lines 926-980. (The last parameter of function call). Which parameters do you want for PPC405, Grant? Regards, Michal Simek This is example of generator. / { model = mONStR; chosen { linux,platform = 600; linux,platform is long obsolete. Kill it. bootargs = root=/dev/xsysace/disc0/part2; } ; cpus { #size-cells = 0; #cpus = 0 ; #address-cells = 1; microblaze_0,5.00.c { Still missing an @0 here. 32-bit; linux,boot-cpu; 32-bit and linux,boot-cpu are both obsolete (the first was never specified anywhere) and should be removed. device_type = cpu; reg = 0; clock-frequency = 5f5e1000; timebase-frequency = 1FCA055; i-cache-line-size = 2000; i-cache-size = 10; d-cache-line-size = 2000; d-cache-size = 10; xilinx,pvr = 0; xilinx,debug-enabled = 1; xilinx,fsl-links = 0; } ; } ; [EMAIL PROTECTED] { compatible = opb_mdm_2.00.a\0opb_mdm; Please use the new opb_mdm_2.00.a, opb_mdm syntax. name = debug_module; Don't create properties called 'name'. In real OF the 'name' property is a synonym for the node name without the @address part. Although it's possible to encode a name property in a flattened tree with a different value, it's a bad idea since it will clash with the OF notion of this property. In Linux this will cause a collision when the tree is unflattened. We should probably fix dtc to reject this, in fact. reg = 4140 1 ; device_type = opb_mdm; Get rid of all your device_type values, they're all bogus. The only devices which should have device_type at all are the ethernets and maybe the uarts, and in these cases the values should be network and serial respectively. xilinx,mb-dbg-ports = 1; xilinx,uart-width = 8; xilinx,use-uart = 1; } ; [EMAIL PROTECTED] { compatible = opb_uartlite_1.00.b\0opb_uartlite; name = RS232_Uart_1; interrupts = 4 0 ; reg = 4060 1 ; device_type = opb_uartlite; xilinx,baudrate = 2580; xilinx,data-bits = 8; xilinx,clk-freq = 5f5e100; xilinx,odd-parity = 0; xilinx,use-parity = 0; } ; [EMAIL PROTECTED] { The generic names convention means this should be called [EMAIL PROTECTED] compatible = opb_ethernet_1.04.a\0opb_ethernet; name = Ethernet_MAC; interrupts = 3 0 ; reg = 40c0 1 ; device_type = opb_ethernet; xilinx,cam-exist = 0; xilinx,dev-blk-id = 1; xilinx,dev-mir-enable = 1; xilinx,dma-present = 1; xilinx,include-dev-pencoder = 1; xilinx,ipif-rdfifo-depth = 8000; xilinx,ipif-wrfifo-depth = 8000; xilinx,mii-exist = 1; } ; [EMAIL PROTECTED] { compatible = opb_sysace_1.00.c\0opb_sysace; name = SysACE_CompactFlash; reg = 4182 1 ; device_type = opb_sysace; xilinx,mem-width = 10; } ; [EMAIL PROTECTED] { compatible = opb_gpio_3.01.b\0opb_gpio; name = LEDs_4Bit; reg = 4000 1 ; device_type = opb_gpio; xilinx,gpio-width = 4; xilinx,is-dual = 0; } ; [EMAIL PROTECTED] { edk_name = DDR_256MB_32MX64_rank1_row13_col10_cl2_5;
Re: Problems with allyesconfig kernel build
On Mon, 22 Oct 2007 21:18:36 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 23 Oct 2007 14:02:31 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: This was first noted with the -mm tree, but has now migrated into Linus' tree. Yeah, sorry, I didn't know what to do about that. I'm not even sure which patch caused it. Not your fault. What did we do which caused all this to start happening? We just grew too big, probably :-( -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpz99nKqCdc0.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IB/ehca: Fix sg_page() fallout
More fallout from sg_page changes: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1': drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate': drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2': drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page' Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- On Tue, Oct 23, 2007 at 07:05:12AM +0200, Jens Axboe wrote: On Mon, Oct 22 2007, Olof Johansson wrote: More fallout from sg_page changes, found with powerpc allyesconfig: drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1': drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_check_kpages_per_ate': drivers/infiniband/hw/ehca/ehca_mrmw.c:1835: error: 'struct scatterlist' has no member named 'page' drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user2': drivers/infiniband/hw/ehca/ehca_mrmw.c:1870: error: 'struct scatterlist' has no member named 'page' Thanks a lot Olof, applied both fixups! I messed up the second fix. :( please replace with this. -Olof diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c index da88738..ead7230 100644 --- a/drivers/infiniband/hw/ehca/ehca_mrmw.c +++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c @@ -1776,7 +1776,7 @@ static int ehca_set_pagebuf_user1(struct ehca_mr_pginfo *pginfo, list_for_each_entry_continue( chunk, ((pginfo-u.usr.region-chunk_list)), list) { for (i = pginfo-u.usr.next_nmap; i chunk-nmap; ) { - pgaddr = page_to_pfn(chunk-page_list[i].page) + pgaddr = page_to_pfn(sg_page(chunk-page_list[i])) PAGE_SHIFT ; *kpage = phys_to_abs(pgaddr + (pginfo-next_hwpage * @@ -1832,7 +1832,7 @@ static int ehca_check_kpages_per_ate(struct scatterlist *page_list, { int t; for (t = start_idx; t = end_idx; t++) { - u64 pgaddr = page_to_pfn(page_list[t].page) PAGE_SHIFT; + u64 pgaddr = page_to_pfn(sg_page(page_list[t])) PAGE_SHIFT; ehca_gen_dbg(chunk_page=%lx value=%016lx, pgaddr, *(u64 *)abs_to_virt(phys_to_abs(pgaddr))); if (pgaddr - PAGE_SIZE != *prev_pgaddr) { @@ -1867,7 +1867,7 @@ static int ehca_set_pagebuf_user2(struct ehca_mr_pginfo *pginfo, chunk, ((pginfo-u.usr.region-chunk_list)), list) { for (i = pginfo-u.usr.next_nmap; i chunk-nmap; ) { if (nr_kpages == kpages_per_hwpage) { - pgaddr = ( page_to_pfn(chunk-page_list[i].page) + pgaddr = ( page_to_pfn(sg_page(chunk-page_list[i])) PAGE_SHIFT ); *kpage = phys_to_abs(pgaddr); if ( !(*kpage) ) { ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev