Re: [PATCH] Add support for the digsy MTC board.
Grant Likely wrote: > On Mon, Feb 2, 2009 at 4:58 PM, Wolfgang Denk wrote: >> Dear Grzegorz Bernacki, >> >> In message <49872268.10...@semihalf.com> you wrote: We also had this kind of problem - after feeding some nfs options it worked : rsize=8192,wsize=8192,soft,intr,tcp,nolock >>> it seems that it helps. >> Can you please find out which of these changes is the relevant part? > > Probably the ",tcp" bit > > g. > Yes, it's 'tcp' Grzesiek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
On Tue, Feb 3, 2009 at 7:21 AM, Benjamin Herrenschmidt wrote: > >> >> Could this comment instead be maybe: >> >> Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI >> resources may live above that, we ignore the map offset for maps of type >> _DRM_FRAMEBUFFER or _DRM_REGISTERS. It is assumed that each driver will >> have only one resource of each type. >> >> (I want to remember later what exact ABI problem was in question) > > Fair enough. I'll repost. > Don't worry I've applied the patches with Erics comment replacing your one. All 3 are queued in drm-next. Dave. > Cheers, > Ben. > > > -- > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > -- > ___ > Dri-devel mailing list > dri-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
therm_adt746x: CPU fan speed inversion
On my PowerBook5,8, every now and then (haven't figured out any pattern to when it happens) the therm_adt746x module stops controlling the fan speed properly. The problem seems to be that the fan speed range is inverted, i.e. the fan stops when therm_adt746x thinks it's setting it to full speed and vice versa. See below for a log of therm_adt746x loaded with verbose=1 while the problem is in effect; while it looks like the fan speed ramps up and down again, the GNOME sensors applet agrees with my ears that the opposite happened. I haven't found any way to recover from this other than rebooting. Has anyone else seen this? Any ideas what the problem could be, or how to track it down? FWIW I'm currently running 2.6.28 kernels self-built from the kernel.org stable tree, but I first noticed this a long time ago, possibly forever since I've used this module. Now it's finally bothered me enough to report it. :) [150811.783627] adt746x: version 1 (supported) [150811.783639] adt746x: Thermostat bus: 0, address: 0x2e, limit_adjust: 0, fan_speed: -1 [150811.783648] sensor 0: CPU/INTREPID BOTTOMSIDE [150811.783653] sensor 1: CPU BOTTOMSIDE [150811.783658] sensor 2: PWR SUPPLY BOTTOMSIDE [150811.800813] adt746x: ADT7467 initializing [150811.803623] adt746x: Lowering max temperatures from 81, 80, 87 to 70, 50, 70 [150811.803699] adt746x: Setting speed to 0 for CPU BOTTOMSIDE fan. [153827.141765] adt746x: Setting fans speed to 64 (limit exceeded by 0 on CPU BOTTOMSIDE) [153827.141773] adt746x: Setting speed to 64 for CPU BOTTOMSIDE fan. [153861.697327] adt746x: Setting fans speed to 91 (limit exceeded by 2 on CPU BOTTOMSIDE) [153861.697335] adt746x: Setting speed to 91 for CPU BOTTOMSIDE fan. [153898.391372] adt746x: Setting fans speed to 145 (limit exceeded by 4 on CPU BOTTOMSIDE) [153898.391379] adt746x: Setting speed to 145 for CPU BOTTOMSIDE fan. [153936.733051] adt746x: Setting fans speed to 199 (limit exceeded by 6 on CPU BOTTOMSIDE) [153936.733059] adt746x: Setting speed to 199 for CPU BOTTOMSIDE fan. [153977.150356] adt746x: Setting fans speed to 253 (limit exceeded by 8 on CPU BOTTOMSIDE) [153977.150363] adt746x: Setting speed to 253 for CPU BOTTOMSIDE fan. [154017.403671] adt746x: Setting fans speed to 199 (limit exceeded by 6 on CPU BOTTOMSIDE) [154017.403682] adt746x: Setting speed to 199 for CPU BOTTOMSIDE fan. [154047.440196] adt746x: Setting fans speed to 145 (limit exceeded by 4 on CPU BOTTOMSIDE) [154047.440208] adt746x: Setting speed to 145 for CPU BOTTOMSIDE fan. [154073.466771] adt746x: Setting fans speed to 91 (limit exceeded by 2 on CPU BOTTOMSIDE) [154073.466783] adt746x: Setting speed to 91 for CPU BOTTOMSIDE fan. [154101.502629] adt746x: Setting fans speed to 64 (limit exceeded by 0 on CPU BOTTOMSIDE) [154101.502640] adt746x: Setting speed to 64 for CPU BOTTOMSIDE fan. [154153.606437] adt746x: Stopping fans. [154153.606449] adt746x: Setting speed to 0 for CPU BOTTOMSIDE fan. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add support for the digsy MTC board.
Grant Likely wrote: > Hey Grzegorz, > > I've pulled your patch into my -next tree, but I made a few changes first: > - I dropped the defconfig changes because they conflict with the > defconfig update that Ben just pulled from me > - I updated the .dts file to reflect changes I was already making to > all the other .dts files > - I added the digsy-mtc board to the Kconfig documentation. > > I've pushed my whole queue of changes out to my -next tree. Please > pull it down and try it out. (Note, this tree will get rebased at > least once before I ask Ben to pull it, so be aware). Make sure that > I haven't broken your .dts file. To get the defconfig change in, you > can either send me another patch with just the defconfig change, or > you can pop my version of your patch off the top of my -next tree and > rebase your entire patch on top it. Whatever you prefer. > > One more note; the new digsy-mtc.dts file from my tree will probably > not work with older kernels. Kernels need to be backward compatible > with older .dts files, but the same is not true for the other way > around. > > Here's my -next tree: > > git://git.secretlab.ca/git/linux-2.6-mpc52xx next > Hi Grant, Thanks for pulling and updating my patch. I got your tree and now I try to build kernel image for digsy, but I get following errors: arch/powerpc/platforms/52xx/mpc52xx_gpt.c:77: error: field 'of_gc' has incomplete type arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function 'mpc52xx_gpt_gpio_setup':arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: error: parameter name omitted arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: error: parameter name omitted They disappear when I add support for OF gpio, but I think that parts of mpc52xx_gpt.c file should be inside '#ifdef CONFIG_OF_GPIO' clause. regards, Grzesiek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
> Don't worry I've applied the patches with Erics comment replacing your one. > > All 3 are queued in drm-next. Thanks ! I'll let you know when I finally get a chance to tackle the other issues. BTW. Do you guys want me to remove the drm_local_map_t typedef completely in favor of struct drm_local_map ? I have a patch here going part way through that, it's fairly trivial, so if you want it, I can easily finish it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.29-rc3-git4 build break : truncated relocation
On Tue, 2009-02-03 at 14:50 +0530, Sachin P. Sant wrote: > 2.6.29-rc3-git4 allyesconfig build breaks with following error I think it's the recurrent problem of allyesconfig generating a kernel too big for our linker especially when ftrace is enabled. We need to see if it's worth the pain of working around it with the toolchain guys. Probably not tho... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
> > BTW. Do you guys want me to remove the drm_local_map_t typedef > completely in favor of struct drm_local_map ? I have a patch here going > part way through that, it's fairly trivial, so if you want it, I can > easily finish it. One less typedef is always welcome. Dave. > > Cheers, > Ben. > > > > -- > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > -- > ___ > Dri-devel mailing list > dri-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add support for the digsy MTC board.
Grant Likely wrote: On Mon, Feb 2, 2009 at 4:58 PM, Wolfgang Denk wrote: Dear Grzegorz Bernacki, In message <49872268.10...@semihalf.com> you wrote: We also had this kind of problem - after feeding some nfs options it worked : rsize=8192,wsize=8192,soft,intr,tcp,nolock it seems that it helps. Can you please find out which of these changes is the relevant part? Probably the ",tcp" bit g. yes - obviously the retry counter of lost udp packets is pretty small inside the nfs client or server. The problem only occurs when there's fairly high traffic and/or low performance switches are used and UDP packets get lost frequently. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing
Benjamin Herrenschmidt wrote: commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744 Author: Benjamin Herrenschmidt powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED I tried reverting it, but as I had kinda thought, that really didn't help. I'm just recompiling to check that I didn't screw-up during the bisection. Is this a chip that must not have M set ? Or something else ? You guys have to help if you CC me, I have about 0 idea what a MPC8661d is :-) Sorry, my fault. It's a Freescale SOC with two e600 cores. Beyond that, I'm afraid I'm a little out of my depth. Also, does 4c456a67f501b8b15542c7c21c28812bf88f484b help ? I believe that to be included in 2.6.29-rc3 if my (rather rudimentary) git skills haven't let me down? The problem persists in 2.6.29-rc3. Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Fix address decoding setup of PCI 2.x cells
On Mon, Feb 02, 2009 at 11:24:18AM +1100, Benjamin Herrenschmidt wrote: >The PCI 2.x cells used on some 44x SoCs only let us configure the decode >for the low 32-bit of the incoming PLB addresses. The top 4 bits (this >is a 36-bit bus) are hard wired to different values depending on the >specific SoC in use. Our code used to work "by accident" until I added >support for the ISA memory holes and while at it added more validity >checking of the addresses. > >This patch should bring it back to working condition. It still relies >on the device-tree being correct but that's somewhat a pre-requisite >for anything to work anyway. > >Signed-off-by: Benjamin Herrenschmidt >--- > >This is untested. Geert, can you give it a go on Sequoia and let me >know if it fixes your problem ? Since Geert tested it somewhat successfully, perhaps we should get this one into 2.6.29. I have no other fixes outstanding, so feel free to pull it in yourself. Acked-by: Josh Boyer josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/44x: Fix address decoding setup of PCI 2.x cells
On Tue, 3 Feb 2009, Josh Boyer wrote: > On Mon, Feb 02, 2009 at 11:24:18AM +1100, Benjamin Herrenschmidt wrote: > >The PCI 2.x cells used on some 44x SoCs only let us configure the decode > >for the low 32-bit of the incoming PLB addresses. The top 4 bits (this > >is a 36-bit bus) are hard wired to different values depending on the > >specific SoC in use. Our code used to work "by accident" until I added > >support for the ISA memory holes and while at it added more validity > >checking of the addresses. > > > >This patch should bring it back to working condition. It still relies > >on the device-tree being correct but that's somewhat a pre-requisite > >for anything to work anyway. > > > >Signed-off-by: Benjamin Herrenschmidt > >--- > > > >This is untested. Geert, can you give it a go on Sequoia and let me > >know if it fixes your problem ? > > Since Geert tested it somewhat successfully, perhaps we should get > this one into 2.6.29. I have no other fixes outstanding, so feel > free to pull it in yourself. Could it be my USB failures were due to the PPC440 USB host needing the various CONFIG*USB*BIG_ENDIAN* options, which may conflict with USB hosts on PCI plug-in cards? The E1000 did work fine. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.29-rc3-git5 build failure : drivers/staging/panel
2.6.29-rc3-git5 randconfig build on powerpc fails with following error CALLarch/powerpc/kernel/systbl_chk.sh CALLarch/powerpc/kernel/prom_init_check.sh CC [M] drivers/staging/panel/panel.o drivers/staging/panel/panel.c:625: error: conflicting types for set_bits /home/sachin/linux-2.6.29-rc3-git5/arch/powerpc/include/asm/bitops.h:216: error: previous definition of set_bits was here make[3]: *** [drivers/staging/panel/panel.o] Error 1 make[2]: *** [drivers/staging/panel] Error 2 make[1]: *** [drivers/staging] Error 2 make: *** [drivers] Error 2 Will provide .config if required. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch] fix lcd panel driver build failure
* Fix build break for lcd panel driver.
Signed-off-by : Sachin Sant
---
* Fix build break for lcd panel driver.
Signed-off-by : Sachin Sant
---
diff -Naurp a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
--- a/drivers/staging/panel/panel.c 2009-02-03 23:34:18.0 +0530
+++ b/drivers/staging/panel/panel.c 2009-02-03 23:33:16.0 +0530
@@ -622,7 +622,7 @@ static int set_ctrl_bits(void)
}
/* sets ctrl & data port bits according to current signals values */
-static void set_bits(void)
+static void panel_set_bits(void)
{
set_data_bits();
set_ctrl_bits();
@@ -707,12 +707,12 @@ static void lcd_send_serial(int byte)
*/
for (bit = 0; bit < 8; bit++) {
bits.cl = BIT_CLR; /* CLK low */
- set_bits();
+ panel_set_bits();
bits.da = byte & 1;
- set_bits();
+ panel_set_bits();
udelay(2); /* maintain the data during 2 us before CLK up */
bits.cl = BIT_SET; /* CLK high */
- set_bits();
+ panel_set_bits();
udelay(1); /* maintain the strobe during 1 us */
byte >>= 1;
}
@@ -727,7 +727,7 @@ static void lcd_backlight(int on)
/* The backlight is activated by seting the AUTOFEED line to +5V */
spin_lock(&pprt_lock);
bits.bl = on;
- set_bits();
+ panel_set_bits();
spin_unlock(&pprt_lock);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.29-rc3-git5 build failure : drivers/staging/panel
Hi, On Tue, Feb 03, 2009 at 08:45:38PM +0530, Sachin P. Sant wrote: > 2.6.29-rc3-git5 randconfig build on powerpc fails with following error > > CALLarch/powerpc/kernel/systbl_chk.sh > CALLarch/powerpc/kernel/prom_init_check.sh > CC [M] drivers/staging/panel/panel.o > drivers/staging/panel/panel.c:625: error: conflicting types for set_bits > /home/sachin/linux-2.6.29-rc3-git5/arch/powerpc/include/asm/bitops.h:216: > error: previous definition of set_bits was here > make[3]: *** [drivers/staging/panel/panel.o] Error 1 > make[2]: *** [drivers/staging/panel] Error 2 > make[1]: *** [drivers/staging] Error 2 > make: *** [drivers] Error 2 > > Will provide .config if required. I don't think any config will be needed. The problem is that we have conflicting names between global and local functions. Could you please try to rename "set_bits" as weel as the few references to this function in panel.c ? I'd suggest you name it "panel_set_bits". I can work on a patch if needed, but since the fix is really easy I'd prefer to get a confirmation that it's enough. Thanks for the report, Willy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] fix lcd panel driver build failure
Thanks Sachin !
Greg, could you please merge this one into your staging tree ?
Thanks,
Willy
On Tue, Feb 03, 2009 at 09:10:58PM +0530, Sachin P. Sant wrote:
> * Fix build break for lcd panel driver.
>
> Signed-off-by : Sachin Sant
Signed-off-by: Willy Tarreau
> ---
>
>
> * Fix build break for lcd panel driver.
>
> Signed-off-by : Sachin Sant
> ---
>
> diff -Naurp a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
> --- a/drivers/staging/panel/panel.c 2009-02-03 23:34:18.0 +0530
> +++ b/drivers/staging/panel/panel.c 2009-02-03 23:33:16.0 +0530
> @@ -622,7 +622,7 @@ static int set_ctrl_bits(void)
> }
>
> /* sets ctrl & data port bits according to current signals values */
> -static void set_bits(void)
> +static void panel_set_bits(void)
> {
> set_data_bits();
> set_ctrl_bits();
> @@ -707,12 +707,12 @@ static void lcd_send_serial(int byte)
>*/
> for (bit = 0; bit < 8; bit++) {
> bits.cl = BIT_CLR; /* CLK low */
> - set_bits();
> + panel_set_bits();
> bits.da = byte & 1;
> - set_bits();
> + panel_set_bits();
> udelay(2); /* maintain the data during 2 us before CLK up
> */
> bits.cl = BIT_SET; /* CLK high */
> - set_bits();
> + panel_set_bits();
> udelay(1); /* maintain the strobe during 1 us */
> byte >>= 1;
> }
> @@ -727,7 +727,7 @@ static void lcd_backlight(int on)
> /* The backlight is activated by seting the AUTOFEED line to +5V */
> spin_lock(&pprt_lock);
> bits.bl = on;
> - set_bits();
> + panel_set_bits();
> spin_unlock(&pprt_lock);
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing
Martyn Welch wrote: Benjamin Herrenschmidt wrote: commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744 Author: Benjamin Herrenschmidt powerpc/mm: Rework usage of _PAGE_COHERENT/NO_CACHE/GUARDED I tried reverting it, but as I had kinda thought, that really didn't help. I'm just recompiling to check that I didn't screw-up during the bisection. Is this a chip that must not have M set ? Or something else ? You guys have to help if you CC me, I have about 0 idea what a MPC8661d is :-) Sorry, my fault. It's a Freescale SOC with two e600 cores. Beyond that, I'm afraid I'm a little out of my depth. Also, does 4c456a67f501b8b15542c7c21c28812bf88f484b help ? I believe that to be included in 2.6.29-rc3 if my (rather rudimentary) git skills haven't let me down? The problem persists in 2.6.29-rc3. I've done a bit more investigation: The primary CPU is spinning in smp_generic_give_timebase() waiting for "!tbsync->ack". The secondary CPU has made it into smp_generic_take_timebase() and has apparently (according to some printk's I put in there) set "tbsync->ack=1". After that I don't get any printk's, I guess that the one I have put in the "!tbsync->handshake" while loop is making it to the print buffer, but with both processors spinning it's not getting to the serial console. At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744 seems to be the point that it stopped working correctly, that "tbsync" is now somehow becoming cached? Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 729849476 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch] fix lcd panel driver build failure
On Tue, Feb 03, 2009 at 04:47:56PM +0100, Willy Tarreau wrote: > Thanks Sachin ! > > Greg, could you please merge this one into your staging tree ? I will do that, thanks. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
* Anton Vorontsov wrote: > According to this discussion: > > http://lkml.org/lkml/2008/7/25/338 > http://lkml.org/lkml/2008/7/26/72 > > Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug > makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h > requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. [...] hm, why not add PPC to FRAME_POINTERS list of architectures, and select it from the powerpc arch Kconfig? Does that cause complications somewhere? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux2.6.23-rc2 enable apu for xilinx virtex4 ml403 board-ppc405
Hi, I am now using impulse c and xilinx virtex4 ml403 board to do a project. And I want to run the application through APU in the linux environment. So I need to enable the apu for the linux 2.6.23-rc kernel. Then use cross compiler(crosstool-0.43) to make zImage. Does anybody have patch for linux 2.6 to enable apu/fpu? Or any guide for this? I am a new guy in this field, hope can get help! Thanks very much! Best regards, Li Jun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote: > > * Anton Vorontsov wrote: > > > According to this discussion: > > > > http://lkml.org/lkml/2008/7/25/338 > > http://lkml.org/lkml/2008/7/26/72 > > > > Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug > > makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h > > requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. [...] > > hm, why not add PPC to FRAME_POINTERS list of architectures, and select it > from the powerpc arch Kconfig? Does that cause complications somewhere? -fno-omit-frame-pointers makes the code worse w/o any actual benefit that we would use. Plus, there is a long standing bug in gcc that makes -fno-omit-frame-pointer generate wrong code for PPC targets: http://lkml.org/lkml/2008/9/2/25 That is, the only tracer that needs[1] -fno-omit-frame-pointer is "FUNCTION_TRCER", but we workaround the issue via -mno-sched-epilog, quoting arch/powerpc/Makefile: # Work around a gcc code-gen bug with -fno-omit-frame-pointer. ifeq ($(CONFIG_FUNCTION_TRACER),y) KBUILD_CFLAGS += -mno-sched-epilog endif [1] Btw, why exactly do we need the -fno-omit-frame-pointer for "FUNCTION_TRCER" tracer? Why just -pg isn't sufficient?.. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
On Tue, 2009-02-03 at 19:19 +0300, Anton Vorontsov wrote: > On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote: > [1] Btw, why exactly do we need the -fno-omit-frame-pointer for > "FUNCTION_TRCER" tracer? Why just -pg isn't sufficient?.. > The problem is this that is in the toplevel Makefile: ifdef CONFIG_FRAME_POINTER KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls else KBUILD_CFLAGS += -fomit-frame-pointer endif -pg is incompatible with -fomit-frame-pointer -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.29-rc3-git4 build break : truncated relocation
Stephen Rothwell wrote: Hi Sachin, To make allyesconfig build currently, you need to turn CONFIG_PROFILE_ALL_BRANCHES off. It makes drivers/built-in.o too large (increases the text size from about 32M to 47M) and the linker can't add the usual trampolines because we prelink it. Ok will enable this option. Thanks -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.29-rc3-git4 build break : truncated relocation
Hi Sachin, To make allyesconfig build currently, you need to turn CONFIG_PROFILE_ALL_BRANCHES off. It makes drivers/built-in.o too large (increases the text size from about 32M to 47M) and the linker can't add the usual trampolines because we prelink it. Paulus suggested an old solution, but it seemed to hit a binutils limitation. I will have another try ... -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpKhspIgncMk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
According to this discussion: http://lkml.org/lkml/2008/7/25/338 http://lkml.org/lkml/2008/7/26/72 Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. Therefore tracing is completely useless on PowerPC: [...] -0 0X.h32us+: 0:140:R + [000] 1733:120:S mvtsd -0 0X.h39us+: 0 (0) -0 0X..3 72us : 0 (0) -0 0X..3 73us : 0:140:R ==> [000] 1733:120:R mvtsd This patch introduces a ARCH_HAS_NORMAL_FRAME_POINTERS Kconfig symbol, when selected the CALLER_ADDR macros are available without the FRAME_POINTER Kconfig symbol. With this patch the trace output turns into: [...] -0 0X.h32us+: 0:140:R + [000] 1740:120:S mvtsd -0 0X.h39us+: hrtimer_wakeup (__run_hrtimer) -0 0X..3 87us : cpu_idle (__got2_end) -0 0X..3 89us : 0:140:R ==> [000] 1740:120:R mvtsd Signed-off-by: Anton Vorontsov --- On Mon, Feb 02, 2009 at 09:04:15AM -0500, Steven Rostedt wrote: [...] > > > -#ifdef CONFIG_FRAME_POINTER > > > +#if defined(CONFIG_FRAME_POINTER) || defined(CONFIG_PPC) > > Perhaps we should add a HAVE_NORMAL_FRAME_POINTERS in > arch/powerpc/Kconfig under PPC and then we can change the above line to: > > #if defined(CONFIG_FRAME_POINTERS) || \ > defined(CONFIG_HAVE_NORMAL_FRAME_POINTERS) > > This way when another arch wants to belong to this, we do not need to > have a list of archs here. Would it be better if we introduce ARCH_HAS_NORMAL_FRAME_POINTERS in lib/Kconfig.debug, along with ARCH_WANT_FRAME_POINTERS? Note that we can't use ARCH_WANT_FRAME_POINTERS for our needs since that symbol is used for other (mostly cosmetic) purposes: whether we we want CONFIG_FRAME_POINTER depend on CONFIG_DEBUG_KERNEL, and whether frame pointers should be default =y (see commit da4276b8299a6544dc41ac2485d3ffca5811b3fb). arch/powerpc/Kconfig |1 + include/linux/ftrace.h |3 ++- lib/Kconfig.debug |6 ++ 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 74cc312..d1c67bd 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -111,6 +111,7 @@ config PPC select HAVE_FTRACE_MCOUNT_RECORD select HAVE_DYNAMIC_FTRACE select HAVE_FUNCTION_TRACER + select ARCH_HAS_NORMAL_FRAME_POINTERS select ARCH_WANT_OPTIONAL_GPIOLIB select HAVE_IDE select HAVE_IOREMAP_PROT diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h index 7840e71..ede3fe2 100644 --- a/include/linux/ftrace.h +++ b/include/linux/ftrace.h @@ -237,7 +237,8 @@ static inline void __ftrace_enabled_restore(int enabled) #endif } -#ifdef CONFIG_FRAME_POINTER +#if defined(CONFIG_FRAME_POINTER) || \ + defined(CONFIG_ARCH_HAS_NORMAL_FRAME_POINTERS) /* TODO: need to fix this for ARM */ # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) # define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1)) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 29044f5..808f4e2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -579,6 +579,12 @@ config ARCH_WANT_FRAME_POINTERS bool help +config ARCH_HAS_NORMAL_FRAME_POINTERS + bool + help + Architectures should select this symbol if their ABI implies + having a frame pointer. + config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
On Tue, Feb 03, 2009 at 11:32:18AM -0500, Steven Rostedt wrote: > > On Tue, 2009-02-03 at 19:19 +0300, Anton Vorontsov wrote: > > On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote: > > > [1] Btw, why exactly do we need the -fno-omit-frame-pointer for > > "FUNCTION_TRCER" tracer? Why just -pg isn't sufficient?.. > > > > The problem is this that is in the toplevel Makefile: > > > ifdef CONFIG_FRAME_POINTER > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls > else > KBUILD_CFLAGS += -fomit-frame-pointer > endif > > > -pg is incompatible with -fomit-frame-pointer Ah... $ gcc -pg -fomit-frame-pointer -S c.c gcc: -pg and -fomit-frame-pointer are incompatible It's hard-coded in gcc, in the code that don't know about architecture details. But on PowerPC -O1 implies -fomit-frame-pointer, that is gcc -pg -O1 -fno-omit-frame-pointer and gcc -pg -O1 produce different outputs. Thus -pg -O should be the same as "-pg -O -fomit-framepointer". -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Calling wait_event_interruptible_timeout() in I2C wait functions
In i2c-mpc.c, the i2c_wait() function has this:
} else {
/* Interrupt mode */
result = wait_event_interruptible_timeout(i2c->queue,
(i2c->interrupt & CSR_MIF), timeout * HZ);
if (unlikely(result < 0)) {
pr_debug("I2C: wait interrupted\n");
writeccr(i2c, 0);
} else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
That is, the driver calls wait_event_interruptible_timeout() to wait for
a response from the I2C controller after a read or write operation.
However, it appears that this is not common behavior for I2C driver. In
fact, only these six drivers ever call wait_event_interruptible_timeout():
i2c-cpm.c
i2c-ibm_iic.c
i2c-mpc.c
i2c-taos-evm.c
i2c-iop3xx.c
i2c-mv64xxx.c
Although one would think that calling wait_event_interruptible_timeout()
is a good idea, it fails in one situation: when the abrupt termination
of a process causes an I2C operation to occur. That is, you press ^C in
your application, and the driver issues a final I2C operation to shut
down the device. In this situation, wait_event_interruptible_timeout()
returns -ERESTARTSYS, which is then passed up through
i2c_smbus_write_byte_data().
So my question is, is i2c-mpc.c wrong in using
wait_event_interruptible_timeout()?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Add support for the digsy MTC board.
On Tue, Feb 3, 2009 at 1:56 AM, Grzegorz Bernacki wrote: > Grant Likely wrote: >> Hey Grzegorz, >> >> I've pulled your patch into my -next tree, but I made a few changes first: >> - I dropped the defconfig changes because they conflict with the >> defconfig update that Ben just pulled from me >> - I updated the .dts file to reflect changes I was already making to >> all the other .dts files >> - I added the digsy-mtc board to the Kconfig documentation. >> >> I've pushed my whole queue of changes out to my -next tree. Please >> pull it down and try it out. (Note, this tree will get rebased at >> least once before I ask Ben to pull it, so be aware). Make sure that >> I haven't broken your .dts file. To get the defconfig change in, you >> can either send me another patch with just the defconfig change, or >> you can pop my version of your patch off the top of my -next tree and >> rebase your entire patch on top it. Whatever you prefer. >> >> One more note; the new digsy-mtc.dts file from my tree will probably >> not work with older kernels. Kernels need to be backward compatible >> with older .dts files, but the same is not true for the other way >> around. >> >> Here's my -next tree: >> >> git://git.secretlab.ca/git/linux-2.6-mpc52xx next >> > > Hi Grant, > > Thanks for pulling and updating my patch. > I got your tree and now I try to build kernel image for digsy, but I get > following errors: > arch/powerpc/platforms/52xx/mpc52xx_gpt.c:77: error: field 'of_gc' has > incomplete type > arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function > 'mpc52xx_gpt_gpio_setup':arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: > error: parameter name omitted > arch/powerpc/platforms/52xx/mpc52xx_gpt.c:350: error: parameter name omitted > > They disappear when I add support for OF gpio, but I think that parts of > mpc52xx_gpt.c file should be inside '#ifdef CONFIG_OF_GPIO' clause. Good catch. Thanks. I've fixed the patch and I'll repost and refresh my tree shortly. 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: [PATCH] powerpc/44x: Fix address decoding setup of PCI 2.x cells
> Could it be my USB failures were due to the PPC440 USB host needing the > various > CONFIG*USB*BIG_ENDIAN* options, which may conflict with USB hosts on PCI > plug-in cards? > > The E1000 did work fine. You need to enable support for both endians, that's supposed to work. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
On Tue, 2009-02-03 at 21:59 +0300, Anton Vorontsov wrote: > On Tue, Feb 03, 2009 at 11:32:18AM -0500, Steven Rostedt wrote: > > > > On Tue, 2009-02-03 at 19:19 +0300, Anton Vorontsov wrote: > > > On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote: > > > > > [1] Btw, why exactly do we need the -fno-omit-frame-pointer for > > > "FUNCTION_TRCER" tracer? Why just -pg isn't sufficient?.. > > > > > > > The problem is this that is in the toplevel Makefile: > > > > > > ifdef CONFIG_FRAME_POINTER > > KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls > > else > > KBUILD_CFLAGS += -fomit-frame-pointer > > endif > > And don't forget the gcc bug that miscompiles function epilogues on ppc with -fno-omit-frame-pointer (iirc), which we need to work around using -mno-sched-epilog. Currently, we set that only if CONFIG_FUNCTION_TRACER is set, ie, we assume that we only set -fno-omit-frame-pointer when CONFIG_FUNCTION_TRACER is set. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing
On Tue, 2009-02-03 at 15:50 +, Martyn Welch wrote: > > The primary CPU is spinning in smp_generic_give_timebase() waiting for > "!tbsync->ack". The secondary CPU has made it into > smp_generic_take_timebase() and has apparently (according to some > printk's I put in there) set "tbsync->ack=1". After that I don't get > any printk's, I guess that the one I have put in the "! > tbsync->handshake" while loop is making it to the print buffer, but > with both processors spinning it's not getting to the serial console. > > At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744 > seems to be the point that it stopped working correctly, that "tbsync" > is now somehow becoming cached? > Maybe we are missing the M bit in the mapping ? Let's see... the kernel mapping is done via BATs on those guys (ie, e600 is a hash table based processor right ? some kind of 74xx). The code that sets them up is in arch/powerpc/mm/ppc_mmu_32.c In mmu_mapin_ram() we call setbat() multiple times. The last argument is the "flags" which is set to _PAGE_RAM. That should contain _PAGE_COHERENT when CONFIG_SMP is set unless I screwed up. IE. _PAGE_RAM is _PAGE_KERNEL | _PAGE_HWEXEC. _PAGE_KERNEL is _PAGE_BASE plus things, and _PAGE_BASE should contains _PAGE_COHERENT if CONFIG_SMP or CONFIG_PPC_STD_MMU are set and they should both be in your case. setbat() itself will clear _PAGE_COHERENT under some circumstances however. Either if the flags contain _PAGE_NO_CACHE, which should not be the case here, or if the CPU feature bit CPU_FTR_NEED_COHERENT is -not- set. I think that could be the cause of the problem. CPU_FTR_NEED_COHERENT is set as part of CPU_FTR_COMMON if CONFIG_SMP is set (among other things). So it -should- be set for you. since CPU_FTR_COMMON should be OR'ed with all CPU table entries. So I'm a bit at a loss here... unless something else went wrong. Please let me know what you find out. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
Forwarding Eli's patch below, since PowerPC guys may have missed it. I guess the question for Ben et al is whether there is any issue with exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel it's an internal detail). It would probably make sense to roll this change into the mlx4 change that Eli alludes to below and merge through my tree (with ppc maintainer acks of course), rather than splitting this patch out and introducing cross-tree dependencies (and also separating the rationale for the change from the change itself). Thanks, Roland Drivers may want to take advantage of the large pages used for memory obtained from hugetlbfs. One example is mlx4_ib which can use much less MTT entries (in the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus scale significantly better when registering larger memory regions. Other drivers could also benefit from this. Signed-off-by: Eli Cohen --- arch/powerpc/mm/hash_utils_64.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 8d5b475..6cff8c7 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -104,6 +104,7 @@ int mmu_highuser_ssize = MMU_SEGSIZE_256M; u16 mmu_slb_size = 64; #ifdef CONFIG_HUGETLB_PAGE unsigned int HPAGE_SHIFT; +EXPORT_SYMBOL(HPAGE_SHIFT); #endif #ifdef CONFIG_PPC_64K_PAGES int mmu_ci_restrictions; -- 1.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] USB: Fixes for fsl_qe_udc driver
On Mon, Feb 02, 2009 at 06:50:04PM +0300, Anton Vorontsov wrote: > On Tue, Jan 13, 2009 at 08:40:01AM -0800, Greg KH wrote: > > On Tue, Jan 13, 2009 at 09:49:39AM -0600, Kumar Gala wrote: > > > On Jan 6, 2009, at 10:53 PM, Greg KH wrote: > > >> On Tue, Jan 06, 2009 at 10:44:13PM -0600, Kumar Gala wrote: > > >>> On Dec 25, 2008, at 8:14 AM, Anton Vorontsov wrote: > > Hi all, > > > > Just resending some fixes that seem to be lost... > > >>> > > >>> Greg, > > >>> > > >>> What happened w/this patch set? > > >> > > >> As it was sent during the hollidays (on Christmas day at that), it's > > >> still in my "to-review" queue. I'll get to it in a few days after I > > >> resync the USB tree with Linus. > > > > > > Any update on the review of these 6 patches? > > > > It's in my queue, been busy with "real work" for a bit right now, > > sorry... > > Hello Greg, > > Can you please look into these patches? I think they all are 2.6.29 > material, since the QE UDC driver is barely usable w/o these fixes. My appologies, I've now applied them all and will queue them up to Linus before .29 is out. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote: > Forwarding Eli's patch below, since PowerPC guys may have missed it. I > guess the question for Ben et al is whether there is any issue with > exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel > it's an internal detail). It would probably make sense to roll this > change into the mlx4 change that Eli alludes to below and merge through > my tree (with ppc maintainer acks of course), rather than splitting this > patch out and introducing cross-tree dependencies (and also separating > the rationale for the change from the change itself). > > Thanks, > Roland > > > Drivers may want to take advantage of the large pages used for memory obtained > from hugetlbfs. One example is mlx4_ib which can use much less MTT entries (in > the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus scale > significantly better when registering larger memory regions. Other drivers > could also benefit from this. Except that we support multiple large page sizes nowadays ... I think the size can be specified per mountpoint of hugetlbfs no ? Thus things like mellanox would have to query the page size used for a given mapping. Do the generic hugetlbfs code provides such an API ? If not, we may need to add one. Cheers, Ben. > Signed-off-by: Eli Cohen > --- > arch/powerpc/mm/hash_utils_64.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c > index 8d5b475..6cff8c7 100644 > --- a/arch/powerpc/mm/hash_utils_64.c > +++ b/arch/powerpc/mm/hash_utils_64.c > @@ -104,6 +104,7 @@ int mmu_highuser_ssize = MMU_SEGSIZE_256M; > u16 mmu_slb_size = 64; > #ifdef CONFIG_HUGETLB_PAGE > unsigned int HPAGE_SHIFT; > +EXPORT_SYMBOL(HPAGE_SHIFT); > #endif > #ifdef CONFIG_PPC_64K_PAGES > int mmu_ci_restrictions; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
> +struct cr_hdr_cpu {
> + struct pt_regs pt_regs;
> + /* relevant fields from thread_struct */
> + double fpr[32][TS_FPRWIDTH];
> + unsigned int fpscr;
> + int fpexc_mode;
> + /* unsigned int align_ctl; this is never updated? */
> + unsigned long dabr;
> +};
Is there some version or other identification somewhere ? If not there
should be. ie, we're going to add things here. For example, what about
the vector registers ? Also, some CPUs will have more HW debug registers
than just the DABR (we plan to add support for all the BookE architected
IACs and DACs for example), etc...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Ignore vmlinux.strip
On Wed, 2009-01-28 at 14:50 -0500, Sean MacLennan wrote: > Not sure if this is PPC specific or not. I use the following patch to > get a clean git status. Does nobody else see this file? Or am I missing > a step somewhere? Looks good actually. > Cheers, >Sean > > Ignore the vmlinux.strip file. > > Signed-off-by: Sean MacLennan > diff --git a/.gitignore b/.gitignore > index 869e1a3..f7e924a 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -32,6 +32,7 @@ > tags > TAGS > vmlinux > +vmlinux.strip > System.map > Module.markers > Module.symvers > ___ > 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 v2 1/4] Add platform support for AmigaOne
> + hose->first_busno = bus_range ? bus_range[0] : 0; > + hose->last_busno = bus_range ? bus_range[1] : 0xff; > + > + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0); Minor in the context of amigaone but still... the above should come from the device-tree... I suppose those are really just IO space addresses cf8 and cfc, in which case, an option is to call that first: > + /* Interpret the "ranges" property */ > + /* This also maps the I/O region and sets isa_io/mem_base */ > + pci_process_bridge_OF_ranges(hose, dev, 1); And -then- use hose->io_resource.start + 0xcf8 / 0xcfc, the later can be hard coded as they are pretty standard values. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] Generic device tree for all AmigaOne boards
On Mon, 2009-02-02 at 22:39 +0100, Gerhard Pircher wrote:
> This device tree does not provide the correct CPU name, as various CPU
> models and revisions are used in AmigaOnes. Also the PCI root node does
> not contain a interrupt mapping property, as all boards have different
> interrupt routing. However the kernel can do a 1:1 mapping of all PCI
> interrupts, as only i8259 legacy interrupts are used.
Looks ok for the purpose, but please remove the commented bits etc...
Ben.
> Signed-off-by: Gerhard Pircher
> ---
> arch/powerpc/boot/dts/amigaone.dts | 183
>
> 1 files changed, 183 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/amigaone.dts
>
> diff --git a/arch/powerpc/boot/dts/amigaone.dts
> b/arch/powerpc/boot/dts/amigaone.dts
> new file mode 100644
> index 000..54d49e0
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/amigaone.dts
> @@ -0,0 +1,183 @@
> +/*
> + * AmigaOne Device Tree Source
> + *
> + * Copyright 2008 Gerhard Pircher (gerhard_pirc...@gmx.net)
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "AmigaOne";
> + compatible = "eyetech,amigaone";
> + coherency-off;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #cpus = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + c...@0 {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <32>; // 32 bytes
> + i-cache-line-size = <32>; // 32 bytes
> + d-cache-size = <32768>; // L1, 32K
> + i-cache-size = <32768>; // L1, 32K
> + timebase-frequency = <0>; // 33.3 MHz, from U-boot
> + clock-frequency = <0>; // From U-boot
> + bus-frequency = <0>;// From U-boot
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0>;// From U-boot
> + };
> +
> + p...@8000 {
> + device_type = "pci";
> + compatible = "mai-logic,articia-s";
> + bus-frequency = <>;
> + bus-range = <0 0xff>;
> + ranges = <0x0100 0 0x 0xfe00 0 0x00c0
> // PCI I/O
> + 0x0200 0 0x8000 0x8000 0 0x7d00
> // PCI memory
> + 0x0200 0 0x 0xfd00 0 0x0100>;
> // PCI alias memory (ISA)
> + 8259-interrupt-acknowledge = <0xfef0>;
> + // Do not define a interrupt-parent here, if there is no
> + // interrupt-map property.
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + i...@7 {
> + device_type = "isa";
> + compatible = "pciclass,0601";
> + vendor-id = <0x1106>;
> + device-id = <0x0686>;
> + revision-id = <0x0010>;
> + class-code = <0x00060100>;
> + subsystem-id = <0>;
> + subsystem-vendor-id = <0>;
> + devsel-speed = <0x0001>;
> + min-grant = <0>;
> + max-latency = <0>;
> + /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on
> ISA. */
> + ranges = <0x0001 0 0x0100 0 0x
> 0x0001>;
> + interrupt-parent = <&i8259>;
> + #interrupt-cells = <2>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + dma-control...@0 {
> + compatible = "pnpPNP,200";
> + reg = <1 0x 0x0020
> +1 0x0080 0x0010
> +1 0x00c0 0x0020>;
> + /* Channel 4 reserverd, cascade mode, 2x32k
> transfer/counter
> + * widths and bus master capability.
> + */
> +/* dma = <0x4 0x4 0x20 0x20 0x1>; */
> + };
> +
> + i8259: interrupt-control...@20 {
> + device_type = "interrupt-controller";
> + compatible = "pnpPNP,000";
> + interrupt-controller;
> + reg = <1 0x0020 0x0002
> +
Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
> Acked-by: Jean Delvare Jean, you'll take that in your tree or should I take it in mine ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: use common cpu_die
> --- work.git.orig/arch/powerpc/platforms/powermac/setup.c 2009-01-05
> 02:09:08.0 -0600
> +++ work.git/arch/powerpc/platforms/powermac/setup.c 2009-01-05
> 02:27:23.0 -0600
> @@ -672,7 +672,7 @@ static int pmac_pci_probe_mode(struct pc
> /* access per cpu vars from generic smp.c */
> DECLARE_PER_CPU(int, cpu_state);
>
> -static void pmac_cpu_die(void)
> +static void pmac64_cpu_die(void)
> {
> /*
.../...
> --- work.git.orig/arch/powerpc/platforms/powermac/smp.c 2009-01-05
> 02:09:08.0 -0600
> +++ work.git/arch/powerpc/platforms/powermac/smp.c2009-01-05
> 02:27:23.0 -0600
.../...
>
> -void cpu_die(void)
> +void pmac32_cpu_die(void)
> {
> local_irq_disable();
> cpu_dead[smp_processor_id()] = 1;
Hi Milton ! Any chance you can move both pmac32 and pmac64 variants into
the same file ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Check name property to determine partition nodes.
On Fri, 2009-01-23 at 17:18 +0100, Benjamin Krill wrote:
> SLOF has a further node which could not be evaluate
> by the current routine. The current routine returns
> because the node hasn't the required reg property. As
> fix this patch adds a check to determine the partition
> child nodes. If the node is not an partition the number
> of total partitions will be decreased and loop continue
> with the next nodes.
Somebody on the MTD list is taking that ? David ? Or should I merge it
via powerpc ?
Cheers,
Ben.
> Signed-off-by: Benjamin Krill
> ---
> drivers/mtd/ofpart.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
> index 9e45b3f..3e164f0 100644
> --- a/drivers/mtd/ofpart.c
> +++ b/drivers/mtd/ofpart.c
> @@ -46,6 +46,13 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
> const u32 *reg;
> int len;
>
> + /* check if this is a partition node */
> + partname = of_get_property(pp, "name", &len);
> + if (strcmp(partname, "partition") != 0) {
> + nr_parts--;
> + continue;
> + }
> +
> reg = of_get_property(pp, "reg", &len);
> if (!reg || (len != 2 * sizeof(u32))) {
> of_node_put(pp);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
On Fri, 2009-01-09 at 15:58 +0300, Ilya Yanok wrote:
> This patch rewrites consistent dma allocations support to use vmalloc
> layer to allocate virtual memory space from vmalloc pool and get rid
> of CONFIG_CONSISTENT_{START,SIZE}.
So as commented before, please drop the defconfig updates.
I'm happy with the idea but I have a few nits with the implementation:
> -/*
> * Allocate DMA-coherent memory space and return both the kernel remapped
> * virtual and bus address for that space.
> */
> @@ -151,19 +41,17 @@ void *
> __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
> {
> struct page *page;
> - struct vm_region *c;
> unsigned long order;
> + void *v;
> + int i;
> + struct page *pages[PAGE_ALIGN(size)>>PAGE_SHIFT];
I'm not -too- fan of that page list one the stack up there.
I understand why you don't wantto kmalloc something here etc... but
that's what __vmalloc_area() does and it's somewhat useful to keep track
of the page array that way, it might prove handy in the future.
Might even be worth adding a generic patch to add a VM_COHERENT_DMA flag
so they can be listed as such and make sure you set the "caller" field
yourself with your own caller.
(Hint: look at the output of /proc/vmallocinfo)
Also, the mucking around with PG_Reserved shouldn't be of any use
anymore.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt wrote: > On Tue, 2009-02-03 at 17:08 -0800, Roland Dreier wrote: > > Forwarding Eli's patch below, since PowerPC guys may have missed it. I > > guess the question for Ben et al is whether there is any issue with > > exporting HPAGE_SHIFT for modules (can be EXPORT_SYMBOL_GPL if you feel > > it's an internal detail). It would probably make sense to roll this > > change into the mlx4 change that Eli alludes to below and merge through > > my tree (with ppc maintainer acks of course), rather than splitting this > > patch out and introducing cross-tree dependencies (and also separating > > the rationale for the change from the change itself). > > > > Thanks, > > Roland > > > > > > Drivers may want to take advantage of the large pages used for memory > > obtained > > from hugetlbfs. One example is mlx4_ib which can use much less MTT entries > > (in > > the order of HPAGE_SIZE / PAGE_SIZE) when registering such memory, thus > > scale > > significantly better when registering larger memory regions. Other drivers > > could also benefit from this. > > Except that we support multiple large page sizes nowadays ... I think > the size can be specified per mountpoint of hugetlbfs no ? Thus things > like mellanox would have to query the page size used for a given > mapping. > > Do the generic hugetlbfs code provides such an API ? If not, we may need > to add one. > I think it's something like huge_page_size(page_hstate(page)) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Wire up /proc/vmallocinfo to our ioremap()
This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.
Note the small addition to the generic code exposing a __get_vm_area_caller()
which we need for the ppc64 implementation.
Signed-off-by: Benjamin Herrenschmidt
---
Can some mm person review the generic bit and maybe ack it ?
Cheers,
Ben.
arch/powerpc/include/asm/io.h|6 ++
arch/powerpc/include/asm/machdep.h |2 +-
arch/powerpc/mm/pgtable_32.c | 14 +++---
arch/powerpc/mm/pgtable_64.c | 25 +
arch/powerpc/platforms/cell/io-workarounds.c |4 ++--
arch/powerpc/platforms/iseries/setup.c |2 +-
include/linux/vmalloc.h |3 +++
mm/vmalloc.c |8
8 files changed, 49 insertions(+), 15 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/io.h 2009-02-04
15:37:43.0 +1100
+++ linux-work/arch/powerpc/include/asm/io.h2009-02-04 15:38:30.0
+1100
@@ -632,6 +632,9 @@ static inline void iosync(void)
* ioremap_flags and cannot be hooked (but can be used by a hook on one
* of the previous ones)
*
+ * * __ioremap_caller is the same as above but takes an explicit caller
+ * reference rather than using __builtin_return_address(0)
+ *
* * __iounmap, is the low level implementation used by iounmap and cannot
* be hooked (but can be used by a hook on iounmap)
*
@@ -646,6 +649,9 @@ extern void iounmap(volatile void __iome
extern void __iomem *__ioremap(phys_addr_t, unsigned long size,
unsigned long flags);
+extern void __iomem *__ioremap_caller(phys_addr_t, unsigned long size,
+ unsigned long flags, void *caller);
+
extern void __iounmap(volatile void __iomem *addr);
extern void __iomem * __ioremap_at(phys_addr_t pa, void *ea,
Index: linux-work/arch/powerpc/include/asm/machdep.h
===
--- linux-work.orig/arch/powerpc/include/asm/machdep.h 2009-02-04
15:35:20.0 +1100
+++ linux-work/arch/powerpc/include/asm/machdep.h 2009-02-04
15:35:25.0 +1100
@@ -90,7 +90,7 @@ struct machdep_calls {
void(*tce_flush)(struct iommu_table *tbl);
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
- unsigned long flags);
+ unsigned long flags, void *caller);
void(*iounmap)(volatile void __iomem *token);
#ifdef CONFIG_PM
Index: linux-work/arch/powerpc/mm/pgtable_32.c
===
--- linux-work.orig/arch/powerpc/mm/pgtable_32.c2009-02-04
15:40:22.0 +1100
+++ linux-work/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:41:43.0
+1100
@@ -129,7 +129,8 @@ pgtable_t pte_alloc_one(struct mm_struct
void __iomem *
ioremap(phys_addr_t addr, unsigned long size)
{
- return __ioremap(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED);
+ return __ioremap_caller(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED,
+ __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap);
@@ -143,13 +144,20 @@ ioremap_flags(phys_addr_t addr, unsigned
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
flags &= ~(_PAGE_USER | _PAGE_EXEC | _PAGE_HWEXEC);
- return __ioremap(addr, size, flags);
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap_flags);
void __iomem *
__ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
+
+void __iomem *
+__ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
+void *caller)
+{
unsigned long v, i;
phys_addr_t p;
int err;
@@ -212,7 +220,7 @@ __ioremap(phys_addr_t addr, unsigned lon
if (mem_init_done) {
struct vm_struct *area;
- area = get_vm_area(size, VM_IOREMAP);
+ area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
v = (unsigned long) area->addr;
Index: linux-work/arch/powerpc/mm/pgtable_64.c
===
--- linux-work.orig/arch/powerpc/mm/pgtable_64.c2009-02-04
15:31:20.0 +1100
+++ linux-work/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:50:54.0
+1100
@@ -144,8 +144,8 @@ void __iounmap_at(void *ea, unsigned lon
unmap_kernel_range((unsigned long)ea, size);
}
-void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
-
Re: [PATCH 1/2] powerpc: G4 oprofile: variable number of counters
On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote: > For ppc750 processors which use 4 performance counters instead of the > 6 G4 uses but otherwise is compatible with G4. > > Signed-off-by: Octavian Purdila > --- > arch/powerpc/oprofile/op_model_7450.c | 21 +++-- > 1 files changed, 11 insertions(+), 10 deletions(-) > > diff --git a/arch/powerpc/oprofile/op_model_7450.c > b/arch/powerpc/oprofile/op_model_7450.c > index cc599eb..97348f5 100644 > --- a/arch/powerpc/oprofile/op_model_7450.c > +++ b/arch/powerpc/oprofile/op_model_7450.c > @@ -29,7 +29,7 @@ > static unsigned long reset_value[OP_MAX_COUNTER]; > > static int oprofile_running; > -static u32 mmcr0_val, mmcr1_val, mmcr2_val; > +static u32 mmcr0_val, mmcr1_val, mmcr2_val, ctrs; This may be static but it's still a global scope as far as kernel symbols are concerned. Care to give it a slightly better name ? num_pmcs would probably be already more telling. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote: > On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt > > Do the generic hugetlbfs code provides such an API ? If not, we may need > > to add one. > > I think it's something like > > huge_page_size(page_hstate(page)) That would work if you have a page, yes. If you want to query which hugepage sizes are available, then you probably want for_each_hstate() (which is only within mm/hugetlb.c at the moment, but I have no objections to exporting it and symbols it requires). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> I think it's something like > > huge_page_size(page_hstate(page)) That would suit. I assume the intention is for that to be usable by driver modules on any architecture? - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Tue, 03 Feb 2009 22:16:08 -0800 Roland Dreier wrote: > > I think it's something like > > > >huge_page_size(page_hstate(page)) > > That would suit. I assume the intention is for that to be usable by > driver modules on any architecture? > erm, you overestimate the amount of planning and forethought which goes into these things ;) The lack of any EXPORT_SYMBOL(size_to_hstate) is a broadish hint. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wed, 04 Feb 2009 12:50:48 +1100 Benjamin Herrenschmidt >>> Do the generic hugetlbfs code provides such an API ? If not, we may need >>> to add one. On Wednesday 04 February 2009 16:13:29 Andrew Morton wrote: >> I think it's something like >> huge_page_size(page_hstate(page)) On Wed, Feb 04, 2009 at 04:31:38PM +1100, Nick Piggin wrote: > That would work if you have a page, yes. If you want to query which hugepage > sizes are available, then you probably want for_each_hstate() (which is only > within mm/hugetlb.c at the moment, but I have no objections to exporting it > and symbols it requires). Exciting things have happened in mm/hugetlb.c while I was out sick. I've got quite some catching up to do. -- wli ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c: i2c-ibm_iic message can be confusing
Hi Ben, On Wed, 04 Feb 2009 14:55:33 +1100, Benjamin Herrenschmidt wrote: > > > Acked-by: Jean Delvare > > Jean, you'll take that in your tree or should I take it in mine ? No, I'm not taking it, i2c-ibm_iic is under Ben Dooks' jurisdiction. So it's up to either him or you. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
