LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* RE: TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-03-07 14:10 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <47D12F80.3000400@denx.de>



Anatolij wrote:

> Hello,

Hello Anatoli,

> Pedro Luis D. L. wrote:
>=20
>=20
>=20
>> I tried to contact TQ but they seem not to be able to solve my
>> problem. They suggested that the problem could be in the different
>> endianness used by MPC5200 and SMI501. That problem seems to be
>> corrected in the driver. Anyway, this endianness problem may come
>> to light if I had any video output. It is possible to change the
>> endianness of SM501 chip from the u-boot writing a register.
>> I did it and it made no difference at all. The real problem is
>> still that none device is initialized or detected even when the
>> Framebuffer driver for SM501 and MFD Driver for SM501 are compiled
>> with the kernel. I checked that platform driver for both are
>> registered (using some printk output) but their probe functions
>> are never invoked.
>>=20
>> I thought that my problem could be that I don't have initialized
>> the device within the platform file tqm5200.c. I added the following
>> code (marked with +) to this file under arch/powerpc/platforms/52xx/tqm5=
200.c
>>=20
>> +static struct resource sm501_resources[] =3D {
>> +	[0]	=3D {
>> +		.start	=3D 0xE3E00000,
>> +		.end	=3D 0xE3DFFFFF,
>=20
> This is wrong as '.end' resource should be greater than '.start'.
> The value for '.end' seems to origin from the typo in TQ docs for
> TQM5200. The proper value results from adding 2MB register space
> of the SM501 to the IO base 0xe3e00000 and is 0xe3ffffff.
> Furthermore you didn't define any framebuffer memory resource
> which is strictly needed here for the framebuffer driver.

Yes, I supposed I had to add another resource, but I was not sure how to po=
int them. I didn't realize the documentation error, ups, but it is true, e3=
d is smaller than e3E... My mistake, sorry :-(


>> +		.flags	=3D IORESOURCE_MEM,
>> +	},
>> +};
>> +
>> +static struct platform_device sm501_device =3D {
>> +	.name		=3D "sm501",
>> +	.id		=3D 0,
>> +	.num_resources	=3D ARRAY_SIZE(sm501_resources),
>> +	.resource	=3D sm501_resources,
>> +};
>>=20
>> static void __init tqm5200_setup_arch(void)
>> {
>> 	if (ppc_md.progress)
>> 		ppc_md.progress("tqm5200_setup_arch()", 0);
>>=20
>> 	/* Some mpc5200 & mpc5200b related configuration */
>> 	mpc5200_setup_xlb_arbiter();
>>=20
>> 	/* Map wdt for mpc52xx_restart() */
>> 	mpc52xx_map_wdt();
>>=20
>> #ifdef CONFIG_PCI
>> 	np =3D of_find_node_by_type(NULL, "pci");
>> 	if (np) {
>> 		mpc52xx_add_bridge(np);
>> 		of_node_put(np);
>> 	}
>> #endif
>> +
>> +	platform_device_register(&sm501_device);
>> +
>> }
>>=20
>> I got this idea from the configuration files from other platforms,
>> but I still need to find out how exactly "resources" must be defined.
>> Anybody knows wheather am I pointing in the right direction and this
>> makes any sense?
>=20
> yes, the direction is right or this is at least a possible solution
> among others provided that you do it correctly.
> Calling "platform_device_register(...)" from "tqm5200_setup_arch()"
> won't work, so move this call and the resource definitions to
> sm501 platform driver. A really right direction would be adding
> sm501 resource description to the device tree and adding appropriate
> code to the sm501 platform driver, but it is more effort.

I thought about this possible solution (adding resource description to devi=
ce tree), but as far as I understood, the device tree was intended to descr=
ibe the microcontroller peripherals and tqm5200, based on the mpc5200 is so=
ld out also without sm501, so that's why I discarded this option.

>> As far as I understand now (and I may be terribly wrong), once
>> that SM501 MFD and Framebuffer drivers are registered,  I need
>> to tell the kernel where to find the device in the local bus.
>> Is it right?
>=20
> yes, try the patch below, and also ensure that
> CONFIG_VT,
> CONFIG_VT_CONSOLE,
> CONFIG_FRAMEBUFFER_CONSOLE
> are enabled in the kernel configuration.
>=20
> diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
> index afd8296..599ffe6 100644
> --- a/drivers/mfd/sm501.c
> +++ b/drivers/mfd/sm501.c
> @@ -901,6 +901,9 @@ static int sm501_init_dev(struct sm501_devdata *sm)
> =20
>  	INIT_LIST_HEAD(&sm->devices);
> =20
> +	/* switch to BE */
> +	writel(0xffffffff, sm->regs + SM501_ENDIAN_CONTROL);
> +
>  	devid =3D readl(sm->regs + SM501_DEVICEID);
> =20
>  	if ((devid & SM501_DEVICEID_IDMASK) !=3D SM501_DEVICEID_SM501) {
> @@ -1263,8 +1266,31 @@ static struct platform_driver sm501_plat_drv =3D {
>  	.resume		=3D sm501_plat_resume,
>  };
> =20
> +/* define some sm501 resources on tqm5200 */
> +#define SM501_FB_BASE	0xe0000000
> +#define SM501_IO_BASE	0xe3e00000
> +#define SM501_FB_END	((SM501_FB_BASE) + 0x7fffff)
> +#define SM501_IO_END	((SM501_IO_BASE) + 0x1fffff)
> +
> +static struct resource sm501_device0_resources[] =3D {
> +	[0] =3D {.start =3D SM501_FB_BASE, .end =3D SM501_FB_END, .flags =3D IO=
RESOURCE_MEM,},
> +	[1] =3D {.start =3D SM501_IO_BASE, .end =3D SM501_IO_END, .flags =3D IO=
RESOURCE_MEM,},
> +};
> +
> +static struct platform_device sm501_device0 =3D {
> +	.name =3D "sm501",
> +	.id =3D 0,
> +	.num_resources =3D ARRAY_SIZE(sm501_device0_resources),
> +	.resource =3D sm501_device0_resources,
> +};
> +
> +static struct platform_device *mfd_devices[] __initdata =3D {
> +	&sm501_device0,
> +};
> +
>  static int __init sm501_base_init(void)
>  {
> +	platform_add_devices(mfd_devices, ARRAY_SIZE(mfd_devices));
>  	platform_driver_register(&sm501_plat_drv);
>  	return pci_register_driver(&sm501_pci_drv);
>  }
>=20
> Best regards,
> Anatolij

It worked!! Thank you very much. The device is added and I can get some out=
put throught the LCD attached. Although the output is not correct yet (look=
s like static noise :-) ), but I think it could be because of an incorrect =
clocks and registers initialization. I should check it up right now.

I think this patch might be include within the kernel. Maybe like a configu=
ration option just in case that SM501 is attached to the tqm. I don't know =
how to do it but I'll give it a try and submit a patch to denx once I have =
a proper output when I figure out how.

Thank you very much,

Pedro L.

> --=20
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de

_________________________________________________________________
La vida de los famosos al desnudo en MSN Entretenimiento
http://entretenimiento.es.msn.com/=

^ permalink raw reply

* Re: [PATCH v2] 82xx: MGCOGE support
From: Heiko Schocher @ 2008-03-07 13:12 UTC (permalink / raw)
  To: Scott Wood, linuxppc-dev
In-Reply-To: <47A38507.1040804@freescale.com>

Hello Scott,

Scott Wood wrote:
> Heiko Schocher wrote:
>> The following patch adds support for the mpc8247 based
>> board MGCOGE from keymile.
>>
>> changes to the previous patchset:
>>
>> - Added the suggestions from Scott Wood:
>>   http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050957.html
>>
>> - The patch
>> http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050931.html
>>   is no longer needed.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
> 
> Acked-by: Scott Wood <scottwood@freescale.com>

I have some changes for this Hardware (a second Flash is now there),
how should I post this change?

a) The complete board support again, with the new Flash.
b) as an incremental Patch against the patch I postet in this Thread.

(I vote for option a, and we throw away the "v2 Patch")

thanks for helping

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

^ permalink raw reply

* Re: TQM5200 2.6-denx SM501 voyager enabling problem.
From: Anatolij Gustschin @ 2008-03-07 12:05 UTC (permalink / raw)
  To: Pedro Luis D. L.; +Cc: linuxppc-embedded
In-Reply-To: <BLU106-W3191420D0642825B53DD08CA120@phx.gbl>

Hello,

Pedro Luis D. L. wrote:

<snip>

> I tried to contact TQ but they seem not to be able to solve my
> problem. They suggested that the problem could be in the different
> endianness used by MPC5200 and SMI501. That problem seems to be
> corrected in the driver. Anyway, this endianness problem may come
> to light if I had any video output. It is possible to change the
> endianness of SM501 chip from the u-boot writing a register.
> I did it and it made no difference at all. The real problem is
> still that none device is initialized or detected even when the
> Framebuffer driver for SM501 and MFD Driver for SM501 are compiled
> with the kernel. I checked that platform driver for both are
> registered (using some printk output) but their probe functions
> are never invoked.
> 
> I thought that my problem could be that I don't have initialized
> the device within the platform file tqm5200.c. I added the following
> code (marked with +) to this file under arch/powerpc/platforms/52xx/tqm5200.c
> 
> +static struct resource sm501_resources[] = {
> +	[0]	= {
> +		.start	= 0xE3E00000,
> +		.end	= 0xE3DFFFFF,

This is wrong as '.end' resource should be greater than '.start'.
The value for '.end' seems to origin from the typo in TQ docs for
TQM5200. The proper value results from adding 2MB register space
of the SM501 to the IO base 0xe3e00000 and is 0xe3ffffff.
Furthermore you didn't define any framebuffer memory resource
which is strictly needed here for the framebuffer driver.

> +		.flags	= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device sm501_device = {
> +	.name		= "sm501",
> +	.id		= 0,
> +	.num_resources	= ARRAY_SIZE(sm501_resources),
> +	.resource	= sm501_resources,
> +};
> 
> static void __init tqm5200_setup_arch(void)
> {
> 	if (ppc_md.progress)
> 		ppc_md.progress("tqm5200_setup_arch()", 0);
> 
> 	/* Some mpc5200 & mpc5200b related configuration */
> 	mpc5200_setup_xlb_arbiter();
> 
> 	/* Map wdt for mpc52xx_restart() */
> 	mpc52xx_map_wdt();
> 
> #ifdef CONFIG_PCI
> 	np = of_find_node_by_type(NULL, "pci");
> 	if (np) {
> 		mpc52xx_add_bridge(np);
> 		of_node_put(np);
> 	}
> #endif
> +
> +	platform_device_register(&sm501_device);
> +
> }
> 
> I got this idea from the configuration files from other platforms,
> but I still need to find out how exactly "resources" must be defined.
> Anybody knows wheather am I pointing in the right direction and this
> makes any sense?

yes, the direction is right or this is at least a possible solution
among others provided that you do it correctly.
Calling "platform_device_register(...)" from "tqm5200_setup_arch()"
won't work, so move this call and the resource definitions to
sm501 platform driver. A really right direction would be adding
sm501 resource description to the device tree and adding appropriate
code to the sm501 platform driver, but it is more effort.

> As far as I understand now (and I may be terribly wrong), once
> that SM501 MFD and Framebuffer drivers are registered,  I need
> to tell the kernel where to find the device in the local bus.
> Is it right?

yes, try the patch below, and also ensure that
CONFIG_VT,
CONFIG_VT_CONSOLE,
CONFIG_FRAMEBUFFER_CONSOLE
are enabled in the kernel configuration.

diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index afd8296..599ffe6 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -901,6 +901,9 @@ static int sm501_init_dev(struct sm501_devdata *sm)
 
 	INIT_LIST_HEAD(&sm->devices);
 
+	/* switch to BE */
+	writel(0xffffffff, sm->regs + SM501_ENDIAN_CONTROL);
+
 	devid = readl(sm->regs + SM501_DEVICEID);
 
 	if ((devid & SM501_DEVICEID_IDMASK) != SM501_DEVICEID_SM501) {
@@ -1263,8 +1266,31 @@ static struct platform_driver sm501_plat_drv = {
 	.resume		= sm501_plat_resume,
 };
 
+/* define some sm501 resources on tqm5200 */
+#define SM501_FB_BASE	0xe0000000
+#define SM501_IO_BASE	0xe3e00000
+#define SM501_FB_END	((SM501_FB_BASE) + 0x7fffff)
+#define SM501_IO_END	((SM501_IO_BASE) + 0x1fffff)
+
+static struct resource sm501_device0_resources[] = {
+	[0] = {.start = SM501_FB_BASE, .end = SM501_FB_END, .flags = IORESOURCE_MEM,},
+	[1] = {.start = SM501_IO_BASE, .end = SM501_IO_END, .flags = IORESOURCE_MEM,},
+};
+
+static struct platform_device sm501_device0 = {
+	.name = "sm501",
+	.id = 0,
+	.num_resources = ARRAY_SIZE(sm501_device0_resources),
+	.resource = sm501_device0_resources,
+};
+
+static struct platform_device *mfd_devices[] __initdata = {
+	&sm501_device0,
+};
+
 static int __init sm501_base_init(void)
 {
+	platform_add_devices(mfd_devices, ARRAY_SIZE(mfd_devices));
 	platform_driver_register(&sm501_plat_drv);
 	return pci_register_driver(&sm501_pci_drv);
 }

Best regards,
Anatolij

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de

^ permalink raw reply related

* Re: [PATCH] PPC: in celleb_show_cpuinfo() convert strncpy(x, y, sizeof(x)) to strlcpy
From: Ishizaki Kou @ 2008-03-07  8:06 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, 12o3l, linux-kernel, arnd
In-Reply-To: <47CFEF82.10709@tiscali.nl>

Roel Kluin <12o3l@tiscali.nl> wrote:
> Roel Kluin wrote:
> > This patch was not yet tested. Please confirm it's right.
> 
> was too quick with the send button. the batch below is probably better
> ---
> strncpy does not append '\0' if the length of the source string equals
> the size parameter, strlcpy does.
> 
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>

Acked-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>

I tested Roel's 2nd patch and it works good on Celleb.

> ---
> diff --git a/arch/powerpc/platforms/celleb/setup.c b/arch/powerpc/platforms/celleb/setup.c
> index f27ae1e..cbe09d9 100644
> --- a/arch/powerpc/platforms/celleb/setup.c
> +++ b/arch/powerpc/platforms/celleb/setup.c
> @@ -81,8 +81,7 @@ static void celleb_show_cpuinfo(struct seq_file *m)
>  
>  static int __init celleb_machine_type_hack(char *ptr)
>  {
> -	strncpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
> -	celleb_machine_type[sizeof(celleb_machine_type)-1] = 0;
> +	strlcpy(celleb_machine_type, ptr, sizeof(celleb_machine_type));
>  	return 0;
>  }
>  
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: RAW Sockets - HDLC or Ethernet
From: Norbert van Bolhuis @ 2008-03-07  7:53 UTC (permalink / raw)
  To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000001c87f6b$e1d5e9e0$6405a8c0@absolut>


I guess this is what a raw packet socket is supposed to do.
It's not a bug it's a feature.
Can't you somehow recognize your own packet (and skip it) ?

Btw. this question can probably be better addressed in
comp.os.linux.development.system

---
N. van Bolhuis.


Russell McGuire wrote:
> Anyone,
> 
> Yet another mysterious question, at least to me.
> 
> I have written to simple utilities to send and receive a file / data through
> a newly created driver, HDLC using an MPC8360E. 
> Though I doubt this question is limited to that specific HW.
> 
> The main question is that everything I send though device HDLC0 I can
> immediately read from HDLC0 even though logically there is no connection
> there. It as if the kernel is immediately allowing me to read from the same
> device, what a separate application just wrote.???
> HOW CAN THIS BE?
> 
> Details:
> I have two applications: send and receive.  (pseudo code as follows)
> 
> Send opens a socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)).
> And binds it (AF_PACKET, ETH_P_HLDC, if_index(hdlc0))
> 
> Receive opens a socket to the same device 
> socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))
> bind(AF_PACKET, ETH_P_ALL, if_index(hdlc0)
> 
> Note they are opening the same device.
> 
> Now if I send anything through the send application, I immediately receive
> it via the receive application??
> Note, entirely separate processes!
> 
> Note, there is NO hardware loopback, this should be a dead end, and I should
> get nothing back at least as far as HW is concerned.
> 
> What am I missing, that causes all my TX data to show up immediately in the
> RX app? Note I have verified my HDLC drier is not actually receiving
> anything, so is there something in the kernel that is bridging the TX / RX
> paths, or am I just missing the function of this? If so how can I use RAW
> mode, while not mixing this, or at least keeping them separate in the
> applications?
> 
> -Russ
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded


-- 
This message has been scanned for viruses and is believed to be clean

^ permalink raw reply

* Re: [PATCH 2/11] celleb: move the base part for celleb support
From: Ishizaki Kou @ 2008-03-07  7:04 UTC (permalink / raw)
  To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <200803051236.57425.arnd@arndb.de>

Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 05 March 2008, Ishizaki Kou wrote:
> > This patch moves the base code for celleb support into platforms/cell/.
> > All files in this patch are used by celleb-beat and celleb-native commonly.
> 
> Moving around the files this way is good, but
> 
> > +++ b/arch/powerpc/platforms/cell/Makefile       2008-03-04 14:00:28.000000000  +0900 
> > @@ -26,3 +26,20 @@
> >                                          ? spufs/
> > 
> >  obj-$(CONFIG_PCI_MSI)                  += axon_msi.o
> > +
> > +
> > +# celleb stuff
> > +ifeq ($(CONFIG_PPC_CELLEB),y)
> > +obj-y                                  += celleb_setup.o \
> > +                                          celleb_pci.o celleb_scc_epci.o \
> > +                                          celleb_scc_pciex.o \
> > +                                          celleb_scc_uhc.o \
> > +                                          beat.o beat_htab.o beat_hvCall.o \
> > +                                          beat_interrupt.o beat_iommu.o \
> > +                                          io-workarounds.o spider-pci.o
> > +
> > +obj-$(CONFIG_SMP)                      += beat_smp.o
> > +obj-$(CONFIG_PPC_UDBG_BEAT)            += beat_udbg.o
> > +obj-$(CONFIG_SERIAL_TXX9)              += celleb_scc_sio.o
> > +obj-$(CONFIG_SPU_BASE)                 += beat_spu_priv1.o
> > +endif
> 
> This looks like you are referencing files in the Makefile that are moved
> in the later patches. In order to make the git-bisect work correctly
> on the kernel after the patches are applied, I'd suggest either moving
> all files at once, or to modify the Makefile in every step of the way
> so that the kernel still builds.

Thanks for your advice.

I'll split changing the Makefile because the moving patches is too
large to be one patch.

Best regards,
Kou Ishizaki

^ permalink raw reply

* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Segher Boessenkool @ 2008-03-07  3:39 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <20080307002730.GB24142@localhost.localdomain>

> This isn't a problem with this device tree, but it's probably time we
> started establishing some conventional generic names for nand flash
> and board-control devices.
>
> So, to start the ball rolling, I've seen several names for nand flash
> nodes, I'd suggest we standardise on "nand-flash".

What's wrong with the already well-established generic name "flash"?

> I've seen several variants for board control devices (cpld, bcsr,
> fpga, etc.) I suggest we standardise on "board-control"

Fine with me, but it's very vague (hard to avoid though).


Segher

^ permalink raw reply

* Re: [PATCH 1/5] generic __remove_pages() support
From: Yasunori Goto @ 2008-03-07  1:35 UTC (permalink / raw)
  To: Badari Pulavarty; +Cc: linuxppc-dev, Andrew Morton, Dave Hansen, lkml, paulus
In-Reply-To: <1204839763.6272.8.camel@dyn9047017100.beaverton.ibm.com>

Hi Badari-san.

> On Thu, 2008-03-06 at 12:54 -0800, Dave Hansen wrote:
> > On Thu, 2008-03-06 at 10:55 -0800, Badari Pulavarty wrote:
> > > +               if (memmap)
> > > +                       __kfree_section_memmap(memmap, PAGES_PER_SECTION);
> > > +               return;
> > > +       }
> > > +
> > > +       /*
> > > +        * Allocations came from bootmem - how do I free up ?
> > > +        */
> > > +
> > 
> > Shouldn't we figure this one out before merging?
> > 
> > I think we at least need a printk() there.
> 
> I can add a printk(). I am hoping Yasunori Goto has something to
> handle this, before we really merge into mainline.

Ah, yes. 
I'm making patches for around here. I'm sorry for your waiting.

BTW, do you hurry for merging your patch? 
To be honest, I would like to solve not only here
but also some other issues.
But, if you hurry, I'll concentrate to solve only this.

Bye.

-- 
Yasunori Goto 

^ permalink raw reply

* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: Olof Johansson @ 2008-03-07  1:57 UTC (permalink / raw)
  To: Alexandr Smirnov, linuxppc-dev
In-Reply-To: <20080307002959.GC24142@localhost.localdomain>

On Fri, Mar 07, 2008 at 11:29:59AM +1100, David Gibson wrote:
> On Thu, Mar 06, 2008 at 06:14:51PM +0300, Alexandr Smirnov wrote:
> > Add device tree file for Emerson KSI8560 board.
> > 
> > Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>
> 
> [snip]
> > +	soc@fdf00000 {
> > +		#address-cells = <1>;
> > +		#size-cells = <1>;
> > +		device_type = "soc";
> 
> Since this is a new board, is it feasible to require it to have a
> sufficient new u-boot version that we don't require this old
> device_type entry.

Here's a novel idea:

What if the device tree police spent a little more time on fixing up
existing DTS files and booting-without-of.txt, and a little less time
making it as hard as possible for people to get new board ports in?

That way, at least they would be demanding of new submissions what is
documented and already accepted.

Current booting-without-of.txt still claims that /soc should have
device_type "soc".


-Olof

^ permalink raw reply

* CFI_DEF_CFA instruction
From: Bai Shuwei @ 2008-03-07  1:47 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

hi,
   all, from the web i find the definition is:
      .cfi_def_cfa defines a rule for computing CFA as: take adress from
register and add offeset to it.

There is a concept CFA i can't understand, what means of the CFA, and this
address point to where?

Best Regards!

Bai Shuwei


-- 
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
Email: baishuwei@gmail.com, buroc@126.com

[-- Attachment #2: Type: text/html, Size: 599 bytes --]

^ permalink raw reply

* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Olof Johansson @ 2008-03-07  1:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: hskinnemoen, shannon.nelson, linux-kernel, linuxppc-dev,
	pasemi-linux, dan.j.williams
In-Reply-To: <20080307113150.c0874344.sfr@canb.auug.org.au>

On Fri, Mar 07, 2008 at 11:31:50AM +1100, Stephen Rothwell wrote:
> Hi Olof,
> 
> Just one thing I noticed ...
> 
> On Thu, 6 Mar 2008 17:39:00 -0600 Olof Johansson <olof@lixom.net> wrote:
> >
> > +	dma_dev->device_dependency_added = pasemi_dma_dependency_added;
> 
> device_dependency_added is going away in 2.6.26 ...

Thanks, I guess I need to base this on top of both powerpc and the
async-tx git trees and just merge it late.


-Olof

^ permalink raw reply

* Re: [PATCH] The MPC83xx family doesn't support performance monitor instructions
From: Jerry Van Baren @ 2008-03-07  0:51 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <74F2472D-65F2-422B-821B-554EC81A3494@kernel.crashing.org>

Kumar Gala wrote:
> On Mar 5, 2008, at 6:33 PM, Gerald Van Baren wrote:
> 
>> "Errata to MPC8349EA PowerQUICC[tm] II Pro Integrated Host Processor  
>> Family
>> Reference Manual, Rev. 1" (Freescale)
>>
>> Signed-off-by: Gerald Van Baren <vanbaren@cideas.com>
>> ---
>>
>> Hi Kumar,
>>
>> Please apply this fix to 2.6.25rc4 if possible.  Without this
>> patch, the PPC_83xx family configuration is broken (will not compile).
> 
> What's the compile issue?  Some of the 83xx family have perf mon so we  
> need to fix the compile issue.
> 
> - k

Hi Kumar,

The mpc8360 and mpc8349 do not have a perfmon register (I don't find it 
at all in the MPC8360RM and the mpc8349 errata I referenced says the 
MPC8349RM is in error).

The result is that the assembler dies with an error.  If the assembler 
didn't die with an error, I presume the kernel would since it is an 
invalid SPR.

   CC      arch/powerpc/kernel/pmc.o
{standard input}: Assembler messages:
{standard input}:7: Error: Unrecognized opcode: `mfpmr'
{standard input}:11: Error: Unrecognized opcode: `mtpmr'
make[1]: *** [arch/powerpc/kernel/pmc.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

This is using ELDK4.1 (also 4.2rc) using the ppc_6xx- version of the 
compiler (which symlinks to powerpc-linux-gcc).

If some of the mpc83xx processors have perfmon registers, we need a more 
granular way of selecting the CONFIG_FSL_EMB_PERFMON option (or a Plan 
B, but I don't know what Plan B would be).

Best regards,
gvb

^ permalink raw reply

* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Stephen Rothwell @ 2008-03-07  0:31 UTC (permalink / raw)
  To: Olof Johansson
  Cc: hskinnemoen, shannon.nelson, linux-kernel, linuxppc-dev,
	pasemi-linux, dan.j.williams
In-Reply-To: <20080306233900.GA3969@lixom.net>

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

Hi Olof,

Just one thing I noticed ...

On Thu, 6 Mar 2008 17:39:00 -0600 Olof Johansson <olof@lixom.net> wrote:
>
> +	dma_dev->device_dependency_added = pasemi_dma_dependency_added;

device_dependency_added is going away in 2.6.26 ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH 3/4] Emerson KSI8560 device tree
From: David Gibson @ 2008-03-07  0:29 UTC (permalink / raw)
  To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080306151451.GA25251@ru.mvista.com>

On Thu, Mar 06, 2008 at 06:14:51PM +0300, Alexandr Smirnov wrote:
> Add device tree file for Emerson KSI8560 board.
> 
> Signed-off-by: Alexandr Smirnov <asmirnov@ru.mvista.com>

[snip]
> +	soc@fdf00000 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";

Since this is a new board, is it feasible to require it to have a
sufficient new u-boot version that we don't require this old
device_type entry.

-- 
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

^ permalink raw reply

* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: David Gibson @ 2008-03-07  0:27 UTC (permalink / raw)
  To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1204800155-11613-1-git-send-email-leoli@freescale.com>

[snip]
> +		bcsr@1,0 {
> +			reg = <1 0x0 0x8000>;
> +			compatible = "fsl,mpc837xmds-bcsr";
> +		};
> +
> +		nand@3,0 {

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

-- 
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

^ permalink raw reply

* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Benjamin Herrenschmidt @ 2008-03-07  0:19 UTC (permalink / raw)
  To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080307001025.GA27321@netgate.macqel>


On Fri, 2008-03-07 at 01:10 +0100, Philippe De Muyter wrote:
> 
> But I already noticed that the interrupt numbers that the arch/powerpc tree
> uses for the parts that do already work (compact-flash and serials) are
> different from the ones I saw on the running arch/ppc tree.  e.g.,
> the serial lines used irq 26 with the arch/ppc tree and now use 42 with
> the powerpc tree.  For the pci4520, irqs changed from 53, 54 and 55 in the
> arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel.
> That's a little bit confusing.
> 
> There must be something hidden in the sources of the openpic driver to
> explain that difference.  Could it be fixed by a setting in the dts-file ?

The interrupt numbers that you see in /proc/interrupts and that drivers
see are "virtual". They have no direct relationship to the hardware
interrupt lines (well, the kernel attempts sometimes at keeping them the
same but not always).

Basially, when the kernel establishes interrupt routing when probing
devices, it gets dynamically assigned numbers and that's what drivers
and /proc/interrupts will see, and internally "binds" them to a given HW
source on a given interrupt controller.

This is done for several reasons, the main ones being that we have to
routinely deal with multiple controllers each having it's own hardware
number space, some systems have very large HW interrupt numbers not
suitable for the irq_desc array, and we reserve virtual numbers 0 as
always invalid and 1...15 for an ISA-type 8259 controller to avoid
problems with x86-oirignated legacy junk that tries to hard code those
numbers. 

There's an compile option to see the mapping between virtual numbers and
HW numbers in debugfs, try enabling debugfs, CONFIG_VIRQ_DEBUG, and
mount debugfs somewhere. You'll see a powerpc/virq_mapping file in there
with the mapping.

Ben.

^ permalink raw reply

* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-07  0:10 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1204760811.21545.231.camel@pasglop>

Hi Ben,

On Thu, Mar 06, 2008 at 10:46:51AM +1100, Benjamin Herrenschmidt wrote:
> 
> > >>From your .dts, I see you've been doing some swizzling of slots using
> > > interrupts 1...4 ... do that correspond to EXTIRQ 5....8 ?
> > 
> > No, those correspond to the EXT1-4 that are the other side of the #ifdef 
> > for this board in arch/ppc. :-)
> 
> Yes, that's what I was thinking. So that's what he got wrong in
> his .dts.
> 
> Philippe, you need to fix those numbers so they map your EXTIRQ.
> 
> (that is 1 -> 5, 2 -> 6, etc... )
> 
> And of course you need to make sure you have the right routing to the
> chip. it's funny the way you keep providing all sort of info but -never-
> the one we actually asked for :-)

I did not have that.  The board has been designed, and the original linux
port has been made, by a third-party, and the documentation is scarce :(

> 
> We basically, to help you, need to know for each PCI device connected to
> the SoC, or PCI slot if you have such, which address line is used for
> IDSEL, and to which MPIC interrupt inputs.

Well, i have finally an answer for IDSEL : it is connected to AD18 (18 is
decimal), but we knew that actually, because the chip appears as 0000:00:12.0,
0000:00:12.1 and 0000:00:12.2 in the kernel messages.

The pci4520 chip does not have pins labelled inta, intb, intc, or intd,
but pins labelled mfunc0, mfunc1 ... mfunc6.
The pci4520 datasheet does not seem very clear to me about the relation
between the mfunc0..6 pins and the inta..d interrupts :(
Luckily, the running linux kernel shows in /proc/interrupts :

         55:      18797   OpenPIC   Level     yenta, ide0
         54:          1   OpenPIC   Level     yenta
         55:         79   OpenPIC   Level     ohci1394

I can thus deduce that each function of the pci4520 chip uses only
one interrupt line.  With the kernel messages at startup, I also
know that the two yenta's are 12.0 and 12.1 and the ohci1394 is 12.2.
I wrote then the following in my dts file :

        pci@e0008000 {
/*
                                      f800 masks idsel address line
                                      07 masks (sub)function number
                                               7 masks INTA, INTB, INTC or INTD
*/
                interrupt-map-mask = <ff00 0 0 7>;
                interrupt-map = <
                        /* IDSEL 0x12 func 0 */
                        9000 0 0 1 &mpic 5 1
                        9000 0 0 2 &mpic 5 1
                        9000 0 0 3 &mpic 5 1
                        9000 0 0 4 &mpic 5 1

                        /* IDSEL 0x12 func 1 */
                        9100 0 0 1 &mpic 6 1
                        9100 0 0 2 &mpic 6 1
                        9100 0 0 3 &mpic 6 1
                        9100 0 0 4 &mpic 6 1

                        /* IDSEL 0x12 func 2 */
                        9200 0 0 1 &mpic 7 1
                        9200 0 0 2 &mpic 7 1
                        9200 0 0 3 &mpic 7 1
                        9200 0 0 4 &mpic 7 1
                        >;

And it works :) : my board boots and finds its compact-flash disk.  When
writing this, I realize I may simplify my interrupt-map and write
only one config line per function, thus :

                interrupt-map-mask = <ff00 0 0 0>;
                interrupt-map = <
                        /* IDSEL 0x12 func 0 */
                        9000 0 0 0 &mpic 5 1

                        /* IDSEL 0x12 func 1 */
                        9100 0 0 0 &mpic 6 1

                        /* IDSEL 0x12 func 2 */
                        9200 0 0 0 &mpic 7 1
                        >;

Maybe you should explain in booting_without_of.txt the relation between
the idsel and the pci device notation used by lspci or the kernel, and
also document the "function" part ?

> 
> Once you have given us that, we'll be able to help.
> 
> It appears that just looking at the arch/ppc code is a bit too messy and
> confusing (and not necessarily right).
> 
> In addition, you will also need to do proper interrupt routing for you
> other devices (RTC, etc...) but we can look at that separately.

That's for tomorrow.

But I already noticed that the interrupt numbers that the arch/powerpc tree
uses for the parts that do already work (compact-flash and serials) are
different from the ones I saw on the running arch/ppc tree.  e.g.,
the serial lines used irq 26 with the arch/ppc tree and now use 42 with
the powerpc tree.  For the pci4520, irqs changed from 53, 54 and 55 in the
arch/ppc kernel to 17, 18 and 19 with the arch/powerpc kernel.
That's a little bit confusing.

There must be something hidden in the sources of the openpic driver to
explain that difference.  Could it be fixed by a setting in the dts-file ?

Thanks for you help

Philippe

^ permalink raw reply

* [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Olof Johansson @ 2008-03-06 23:39 UTC (permalink / raw)
  To: dan.j.williams, shannon.nelson
  Cc: linuxppc-dev, pasemi-linux, linux-kernel, hskinnemoen

pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
    
First cut at a dma copy offload driver for PA Semi PWRficient. It uses the
platform-specific functions to allocate channels, etc.

Signed-off-by: Olof Johansson <olof@lixom.net>


---

This has some dependencies on other patches currently queued up in the
powerpc git trees for 2.6.26. I'd appreciate reviews and acked-bys, but
it might be easiest to just merge it up the powerpc path due to the
dependencies.


-Olof

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 27340a7..bbeaf10 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -54,6 +54,13 @@ config FSL_DMA_SELFTEST
 	  Enable the self test for each DMA channel. A self test will be
 	  performed after the channel probed to ensure the DMA works well.
 
+config PASEMI_DMA
+	tristate "PA Semi DMA Engine support"
+	depends on PPC_PASEMI
+	select DMA_ENGINE
+	help
+	  Enable support for the DMA Engine on PA Semi PWRficient SoCs
+
 config DMA_ENGINE
 	bool
 
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index c8036d9..6729959 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
 ioatdma-objs := ioat.o ioat_dma.o ioat_dca.o
 obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
 obj-$(CONFIG_FSL_DMA) += fsldma.o
+obj-$(CONFIG_PASEMI_DMA) += pasemi_dma.o
diff --git a/drivers/dma/pasemi_dma.c b/drivers/dma/pasemi_dma.c
new file mode 100644
index 0000000..844ab11
--- /dev/null
+++ b/drivers/dma/pasemi_dma.c
@@ -0,0 +1,478 @@
+/*
+ * Driver for the PA Semi PWRficient DMA Engine (copy parts)
+ * Copyright (c) 2007,2008 Olof Johansson, PA Semi, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/dmaengine.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/pasemi_dma.h>
+
+#define MAX_CH	16
+#define MAX_XFER 0x40000
+#define RING_SZ	8192
+
+struct pasemi_dma_desc {
+	u64 src;
+	u64 dest;
+	dma_addr_t	src_dma;
+	dma_addr_t	dest_dma;
+	size_t len;
+	struct list_head node;
+	int tx_cnt;
+	struct dma_async_tx_descriptor async_tx;
+	struct pasemi_dma_chan *chan;
+};
+
+struct pasemi_dma_chan {
+	struct pasemi_dmachan chan;
+	spinlock_t	   ring_lock;	/* Protects the ring only */
+	spinlock_t	   desc_lock;	/* Protects the descriptor list */
+	struct pasemi_dma *dma_dev;
+	struct pasemi_dma_desc *ring_info[RING_SZ]; /* softc */
+	unsigned int	   next_to_fill;
+	unsigned int	   next_to_clean;
+	struct dma_chan	   common;
+	struct list_head   free_desc;
+	int		   desc_count;
+	int		   in_use;
+};
+
+struct pasemi_dma {
+	struct pci_dev *pdev;
+	struct dma_device common;
+	struct pasemi_dma_chan *chans[MAX_CH];
+};
+
+static unsigned int channels = 4;
+module_param(channels, uint, S_IRUGO);
+MODULE_PARM_DESC(channels, "Number of channels for copy (default: 2)");
+
+#define to_pasemi_dma_chan(chan) container_of(chan, struct pasemi_dma_chan, \
+					      common)
+#define to_pasemi_dma_desc(lh) container_of(lh, struct pasemi_dma_desc, node)
+#define tx_to_desc_sw(tx) container_of(tx, struct pasemi_dma_desc, async_tx)
+
+static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
+{
+	int old, new, i;
+	unsigned long flags;
+	struct pasemi_dma_desc *desc;
+	spin_lock_irqsave(&chan->desc_lock, flags);
+
+	old = chan->next_to_clean;
+
+	new = *chan->chan.status & PAS_STATUS_PCNT_M;
+	new <<= 2;
+	new &= (RING_SZ-1);
+
+	if (old > new)
+		new += RING_SZ;
+
+	for (i = old; i < new; i += 4) {
+		if (unlikely(chan->chan.ring_virt[i & (RING_SZ-1)] & XCT_COPY_O))
+			break;
+		desc = chan->ring_info[i & (RING_SZ-1)];
+		list_add_tail(&desc->node, &chan->free_desc);
+	}
+
+	chan->next_to_clean = i & (RING_SZ-1);
+
+	spin_unlock_irqrestore(&chan->desc_lock, flags);
+}
+
+static int pasemi_dma_intr(int irq, void *data)
+{
+	struct pasemi_dma_chan *chan = data;
+	unsigned int cmdsta;
+
+	cmdsta = pasemi_read_dma_reg(PAS_DMA_TXCHAN_TCMDSTA(chan->chan.chno));
+
+	return IRQ_HANDLED;
+}
+
+static int pasemi_dma_alloc_chan_resources(struct dma_chan *chan)
+{
+	struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+	u32 val;
+	unsigned int cfg;
+	int ret, chno;
+
+	if (ch->in_use)
+		return RING_SZ;
+
+	spin_lock_init(&ch->ring_lock);
+	spin_lock_init(&ch->desc_lock);
+
+	chno = ch->chan.chno;
+
+	ret = pasemi_dma_alloc_ring(&ch->chan, RING_SZ);
+	if (ret) {
+		printk(KERN_INFO "pasemi_dma: Failed to allocate descriptor ring: %d\n", ret);
+		return ret;
+	}
+
+	ch->in_use = 1;
+
+	/* We can really set CNTTH to anything, since we never
+	 * re-enable it after the first interrupt at the moment.
+	 */
+	pasemi_write_iob_reg(PAS_IOB_DMA_TXCH_CFG(chno),
+			     PAS_IOB_DMA_TXCH_CFG_CNTTH(0));
+
+	pasemi_write_iob_reg(PAS_IOB_DMA_TXCH_RESET(chno), 0x30);
+
+	pasemi_write_dma_reg(PAS_DMA_TXCHAN_BASEL(chno),
+			   PAS_DMA_TXCHAN_BASEL_BRBL(ch->chan.ring_dma));
+
+	val = PAS_DMA_TXCHAN_BASEU_BRBH(ch->chan.ring_dma >> 32);
+	val |= PAS_DMA_TXCHAN_BASEU_SIZ(ch->chan.ring_size >> 3);
+
+	pasemi_write_dma_reg(PAS_DMA_TXCHAN_BASEU(chno), val);
+
+	cfg = PAS_DMA_TXCHAN_CFG_TY_COPY |
+	      PAS_DMA_TXCHAN_CFG_UP |
+	      PAS_DMA_TXCHAN_CFG_LPDQ |
+	      PAS_DMA_TXCHAN_CFG_LPSQ |
+	      PAS_DMA_TXCHAN_CFG_WT(4);
+
+	pasemi_write_dma_reg(PAS_DMA_TXCHAN_CFG(chno), cfg);
+
+	pasemi_dma_start_chan(&ch->chan, PAS_DMA_TXCHAN_TCMDSTA_SZ |
+			     PAS_DMA_TXCHAN_TCMDSTA_DB |
+			     PAS_DMA_TXCHAN_TCMDSTA_DE |
+			     PAS_DMA_TXCHAN_TCMDSTA_DA);
+
+	ch->next_to_fill = 0;
+	ch->next_to_clean = 0;
+	ch->desc_count = 0;
+
+	return ch->chan.ring_size/4;
+}
+
+static void pasemi_dma_free_chan_resources(struct dma_chan *chan)
+{
+	struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+
+	if (ch->in_use)
+		pasemi_dma_free_ring(&ch->chan);
+
+	ch->in_use = 0;
+
+	return;
+}
+
+static enum dma_status pasemi_dma_is_complete(struct dma_chan *chan,
+					      dma_cookie_t cookie,
+					      dma_cookie_t *done,
+					      dma_cookie_t *used)
+{
+	struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+	dma_cookie_t clean, fill;
+	int tries = 1;
+	enum dma_status ret;
+
+	pasemi_dma_clean(ch);
+
+	do {
+		clean = (ch->next_to_clean - 4) & (RING_SZ-1);
+		fill = (ch->next_to_fill - 1) & (RING_SZ-1) ;
+
+		if (done)
+			*done = clean;
+		if (used)
+			*used = fill;
+
+		ret = dma_async_is_complete(cookie, clean, fill);
+	} while (ret != DMA_SUCCESS && --tries);
+
+	return ret;
+}
+
+
+static void pasemi_dma_issue_pending(struct dma_chan *chan)
+{
+	return;
+}
+
+static void pasemi_dma_dependency_added(struct dma_chan *chan)
+{
+	return;
+}
+
+
+static dma_cookie_t
+pasemi_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	struct pasemi_dma_desc *desc = tx_to_desc_sw(tx);
+	struct pasemi_dma_chan *chan = desc->chan;
+	unsigned long flags;
+	u64 xct[4], *ring;
+	int idx, len;
+
+	len = desc->len;
+	if (unlikely(!len)) {
+		xct[0] = XCT_COPY_DTY_PREF;
+		len = 1;
+	} else
+		xct[0] = 0;
+
+	xct[0] |= XCT_COPY_O | XCT_COPY_LLEN(len);
+	xct[1]  = XCT_PTR_LEN(len) | XCT_PTR_ADDR(desc->dest) | XCT_PTR_T;
+	xct[2]  = XCT_PTR_LEN(len) | XCT_PTR_ADDR(desc->src);
+	xct[3]  = 0;
+
+	spin_lock_irqsave(&chan->ring_lock, flags);
+
+	idx = chan->next_to_fill;
+
+	ring = chan->chan.ring_virt;
+
+	/* This is where we copy stuff to the ring */
+
+	ring[idx & (RING_SZ-1)] = xct[0];
+	ring[(idx+1) & (RING_SZ-1)] = xct[1];
+	ring[(idx+2) & (RING_SZ-1)] = xct[2];
+	ring[(idx+3) & (RING_SZ-1)] = xct[3];
+
+	chan->next_to_fill = (chan->next_to_fill + 4) & (RING_SZ-1);
+
+	chan->ring_info[idx] = desc;
+
+	pasemi_write_dma_reg(PAS_DMA_TXCHAN_INCR(chan->chan.chno), 2);
+
+	spin_unlock_irqrestore(&chan->ring_lock, flags);
+	return idx;
+}
+
+static struct pasemi_dma_desc *
+pasemi_dma_alloc_descriptor(struct pasemi_dma_chan *ch, gfp_t flags)
+{
+	struct pasemi_dma_desc *desc;
+	struct pasemi_dma *dev;
+
+	dev = ch->dma_dev;
+
+	desc = kzalloc(sizeof(*desc), flags);
+	if (unlikely(!desc))
+		return NULL;
+
+	dma_async_tx_descriptor_init(&desc->async_tx, &ch->common);
+	desc->async_tx.tx_submit = pasemi_tx_submit;
+	desc->chan = ch;
+	INIT_LIST_HEAD(&desc->async_tx.tx_list);
+
+	return desc;
+}
+
+static struct dma_async_tx_descriptor *
+pasemi_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dma_dest,
+		       dma_addr_t dma_src, size_t len, unsigned long flags)
+{
+	struct pasemi_dma_chan *ch = to_pasemi_dma_chan(chan);
+	struct pasemi_dma_desc *desc;
+	int retries = 0;
+
+	if (len >= MAX_XFER) {
+		if (printk_ratelimit())
+			printk(KERN_WARNING "pasemi_dma: Copy request too long (%ld > %d)\n",
+			       len, MAX_XFER);
+		return NULL;
+	}
+
+retry:
+
+	spin_lock_bh(&ch->desc_lock);
+
+	if (!list_empty(&ch->free_desc)) {
+		desc = list_entry(ch->free_desc.next, struct pasemi_dma_desc,
+				  node);
+		list_del(&desc->node);
+	} else {
+		if (ch->desc_count >= (RING_SZ/2)) {
+			spin_unlock_bh(&ch->desc_lock);
+			if (!retries++) {
+				pasemi_dma_clean(ch);
+				goto retry;
+			}
+			return NULL;
+		}
+		ch->desc_count++;
+		/* try to get another desc */
+		spin_unlock_bh(&ch->desc_lock);
+		desc = pasemi_dma_alloc_descriptor(ch, GFP_KERNEL);
+		spin_lock_bh(&ch->desc_lock);
+		/* will this ever happen? */
+		BUG_ON(!desc);
+	}
+	spin_unlock_bh(&ch->desc_lock);
+
+	desc->len = len;
+	desc->dest = dma_dest;
+	desc->src = dma_src;
+
+	return &desc->async_tx;
+}
+
+static int enumerate_dma_channels(struct pasemi_dma *device)
+{
+	int i, ret;
+	struct pasemi_dma_chan *ch;
+
+	device->common.chancnt = channels;
+
+	for (i = 0; i < device->common.chancnt; i++) {
+		ch = pasemi_dma_alloc_chan(TXCHAN, sizeof(*ch),
+					   offsetof(struct pasemi_dma_chan,
+						    chan));
+		ch->dma_dev = device;
+		ch->common.device = &device->common;
+		ret = request_irq(ch->chan.irq, &pasemi_dma_intr, IRQF_DISABLED,
+				  "pasemi_dma", ch);
+		if (ret) {
+			printk(KERN_INFO "pasemi_dma: request of irq %d failed: %d\n",
+			       ch->chan.irq, ret);
+			return ret;
+		}
+		INIT_LIST_HEAD(&ch->free_desc);
+		list_add_tail(&ch->common.device_node,
+			      &device->common.channels);
+	}
+	return device->common.chancnt;
+}
+
+static int __devinit pasemi_dma_probe(struct pci_dev *pdev,
+				      const struct pci_device_id *ent)
+{
+	int err;
+	struct pasemi_dma *device;
+	struct dma_device *dma_dev;
+
+	err = pci_enable_device(pdev);
+	if (err)
+		goto err_enable_device;
+
+	device = kzalloc(sizeof(*device), GFP_KERNEL);
+	if (!device) {
+		err = -ENOMEM;
+		goto err_kzalloc;
+	}
+
+	device->pdev = pdev;
+	pci_set_drvdata(pdev, device);
+
+	dma_dev = &device->common;
+
+	INIT_LIST_HEAD(&dma_dev->channels);
+	enumerate_dma_channels(device);
+
+	dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
+	dma_dev->device_alloc_chan_resources = pasemi_dma_alloc_chan_resources;
+	dma_dev->device_free_chan_resources = pasemi_dma_free_chan_resources;
+	dma_dev->device_prep_dma_memcpy = pasemi_dma_prep_memcpy;
+	dma_dev->device_is_tx_complete = pasemi_dma_is_complete;
+	dma_dev->device_issue_pending = pasemi_dma_issue_pending;
+	dma_dev->device_dependency_added = pasemi_dma_dependency_added;
+	dma_dev->dev = &pdev->dev;
+
+	printk(KERN_INFO "PA Semi DMA Engine found, using %d channels for copy\n",
+		dma_dev->chancnt);
+
+	err = dma_async_device_register(dma_dev);
+
+	return err;
+
+err_kzalloc:
+	pci_disable_device(pdev);
+err_enable_device:
+
+	printk(KERN_ERR "PA Semi DMA Engine initialization failed\n");
+
+	return err;
+}
+
+static void pasemi_dma_shutdown(struct pci_dev *pdev)
+{
+	struct pasemi_dma *device;
+	device = pci_get_drvdata(pdev);
+
+	dma_async_device_unregister(&device->common);
+}
+
+static void __devexit pasemi_dma_remove(struct pci_dev *pdev)
+{
+	struct pasemi_dma *device;
+	struct dma_chan *chan, *_chan;
+	struct pasemi_dma_chan *pasemi_ch;
+
+	device = pci_get_drvdata(pdev);
+	dma_async_device_unregister(&device->common);
+
+	list_for_each_entry_safe(chan, _chan, &device->common.channels,
+				 device_node) {
+		pasemi_ch = to_pasemi_dma_chan(chan);
+		free_irq(pasemi_ch->chan.irq, pasemi_ch);
+		list_del(&chan->device_node);
+		pasemi_dma_free_chan(&pasemi_ch->chan);
+	}
+
+	pci_disable_device(pdev);
+	kfree(device);
+}
+
+static struct pci_device_id pasemi_dma_pci_tbl[] = {
+	{ PCI_DEVICE(PCI_VENDOR_ID_PASEMI, 0xa007) },
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, pasemi_dma_pci_tbl);
+
+static struct pci_driver pasemi_dma_pci_driver = {
+	.name	= "pasemi_dma",
+	.id_table = pasemi_dma_pci_tbl,
+	.probe	= pasemi_dma_probe,
+	.shutdown = pasemi_dma_shutdown,
+	.remove	= __devexit_p(pasemi_dma_remove),
+};
+
+
+static int __init pasemi_dma_init_module(void)
+{
+	int err;
+
+	err = pasemi_dma_init();
+	if (err)
+		return err;
+
+	return pci_register_driver(&pasemi_dma_pci_driver);
+}
+
+module_init(pasemi_dma_init_module);
+
+static void __exit pasemi_dma_exit_module(void)
+{
+	pci_unregister_driver(&pasemi_dma_pci_driver);
+}
+
+module_exit(pasemi_dma_exit_module);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Olof Johansson <olof@lixom.net>");
+MODULE_DESCRIPTION("PA Semi PWRficient DMA Engine driver");

^ permalink raw reply related

* Re: [PATCH 1/5] generic __remove_pages() support
From: Badari Pulavarty @ 2008-03-06 23:37 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: linuxppc-dev, Andrew Morton, paulus, lkml, Yasunori Goto
In-Reply-To: <20080306110847.11d7cb26.randy.dunlap@oracle.com>

Here is the latest version, addressing Randy and Dave's comments.

Thanks,
Badari

Generic helper function to remove section mappings and sysfs entries
for the section of the memory we are removing.  offline_pages() correctly 
adjusted zone and marked the pages reserved.

Issue: If mem_map, usemap allocation could come from different places -
kmalloc, vmalloc, alloc_pages or bootmem. There is no easy way
to find and free up bootmem allocations.

Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>

---
 include/linux/memory_hotplug.h |    6 +++-
 mm/memory_hotplug.c            |   55 +++++++++++++++++++++++++++++++++++++++++
 mm/sparse.c                    |   45 +++++++++++++++++++++++++++++++--
 3 files changed, 102 insertions(+), 4 deletions(-)

Index: linux-2.6.25-rc3.save/mm/memory_hotplug.c
===================================================================
--- linux-2.6.25-rc3.save.orig/mm/memory_hotplug.c	2008-03-05 10:44:30.000000000 -0800
+++ linux-2.6.25-rc3.save/mm/memory_hotplug.c	2008-03-06 15:08:45.000000000 -0800
@@ -102,6 +102,21 @@ static int __add_section(struct zone *zo
 	return register_new_memory(__pfn_to_section(phys_start_pfn));
 }
 
+static int __remove_section(struct zone *zone, struct mem_section *ms)
+{
+	int ret = -EINVAL;
+
+	if (!valid_section(ms))
+		return ret;
+
+	ret = unregister_memory_section(ms);
+	if (ret)
+		return ret;
+
+	sparse_remove_one_section(zone, ms);
+	return 0;
+}
+
 /*
  * Reasonably generic function for adding memory.  It is
  * expected that archs that support memory hotplug will
@@ -135,6 +150,46 @@ int __add_pages(struct zone *zone, unsig
 }
 EXPORT_SYMBOL_GPL(__add_pages);
 
+/**
+ * __remove_pages() - remove sections of pages from a zone
+ * @zone: zone from which pages need to be removed
+ * @phys_start_pfn: starting pageframe (must be aligned to start of a section)
+ * @nr_pages: number of pages to remove (must be multiple of section size)
+ *
+ * Generic helper function to remove section mappings and sysfs entries
+ * for the section of the memory we are removing. Caller needs to make
+ * sure that pages are marked reserved and zones are adjust properly by
+ * calling offline_pages().
+ */
+int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,
+		 unsigned long nr_pages)
+{
+	unsigned long i, ret = 0;
+	int sections_to_remove;
+	unsigned long flags;
+	struct pglist_data *pgdat = zone->zone_pgdat;
+
+	/*
+	 * We can only remove entire sections
+	 */
+	BUG_ON(phys_start_pfn & ~PAGE_SECTION_MASK);
+	BUG_ON(nr_pages % PAGES_PER_SECTION);
+
+	release_mem_region(phys_start_pfn << PAGE_SHIFT, nr_pages * PAGE_SIZE);
+
+	sections_to_remove = nr_pages / PAGES_PER_SECTION;
+	for (i = 0; i < sections_to_remove; i++) {
+		unsigned long pfn = phys_start_pfn + i*PAGES_PER_SECTION;
+		pgdat_resize_lock(pgdat, &flags);
+		ret = __remove_section(zone, __pfn_to_section(pfn));
+		pgdat_resize_unlock(pgdat, &flags);
+		if (ret)
+			break;
+	}
+	return ret;
+}
+EXPORT_SYMBOL_GPL(__remove_pages);
+
 static void grow_zone_span(struct zone *zone,
 		unsigned long start_pfn, unsigned long end_pfn)
 {
Index: linux-2.6.25-rc3.save/mm/sparse.c
===================================================================
--- linux-2.6.25-rc3.save.orig/mm/sparse.c	2008-03-05 10:44:30.000000000 -0800
+++ linux-2.6.25-rc3.save/mm/sparse.c	2008-03-06 15:15:18.000000000 -0800
@@ -198,12 +198,13 @@ static unsigned long sparse_encode_mem_m
 }
 
 /*
- * We need this if we ever free the mem_maps.  While not implemented yet,
- * this function is included for parity with its sibling.
+ * Decode mem_map from the coded memmap
  */
-static __attribute((unused))
+static
 struct page *sparse_decode_mem_map(unsigned long coded_mem_map, unsigned long pnum)
 {
+	/* mask off the extra low bits of information */
+	coded_mem_map &= SECTION_MAP_MASK;
 	return ((struct page *)coded_mem_map) + section_nr_to_pfn(pnum);
 }
 
@@ -363,6 +364,28 @@ static void __kfree_section_memmap(struc
 }
 #endif /* CONFIG_SPARSEMEM_VMEMMAP */
 
+static void free_section_usemap(struct page *memmap, unsigned long *usemap)
+{
+	if (!usemap)
+		return;
+
+	/*
+	 * Check to see if allocation came from hot-plug-add
+	 */
+	if (PageSlab(virt_to_page(usemap))) {
+		kfree(usemap);
+		if (memmap)
+			__kfree_section_memmap(memmap, PAGES_PER_SECTION);
+		return;
+	}
+
+	/*
+	 * TODO: Allocations came from bootmem - how do I free up ?
+	 */
+	printk(KERN_WARNING "Not freeing up allocations from bootmem "
+			"- leaking memory\n");
+}
+
 /*
  * returns the number of sections whose mem_maps were properly
  * set.  If this is <=0, then that means that the passed-in
@@ -415,4 +438,20 @@ out:
 	}
 	return ret;
 }
+
+void sparse_remove_one_section(struct zone *zone, struct mem_section *ms)
+{
+	struct page *memmap = NULL;
+	unsigned long *usemap = NULL;
+
+	if (ms->section_mem_map) {
+		usemap = ms->pageblock_flags;
+		memmap = sparse_decode_mem_map(ms->section_mem_map,
+						__section_nr(ms));
+		ms->section_mem_map = 0;
+		ms->pageblock_flags = NULL;
+	}
+
+	free_section_usemap(memmap, usemap);
+}
 #endif
Index: linux-2.6.25-rc3.save/include/linux/memory_hotplug.h
===================================================================
--- linux-2.6.25-rc3.save.orig/include/linux/memory_hotplug.h	2008-03-05 10:44:30.000000000 -0800
+++ linux-2.6.25-rc3.save/include/linux/memory_hotplug.h	2008-03-06 15:02:13.000000000 -0800
@@ -8,6 +8,7 @@
 struct page;
 struct zone;
 struct pglist_data;
+struct mem_section;
 
 #ifdef CONFIG_MEMORY_HOTPLUG
 /*
@@ -64,9 +65,11 @@ extern int offline_pages(unsigned long, 
 /* reasonably generic interface to expand the physical pages in a zone  */
 extern int __add_pages(struct zone *zone, unsigned long start_pfn,
 	unsigned long nr_pages);
+extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
+	unsigned long nr_pages);
 
 /*
- * Walk thorugh all memory which is registered as resource.
+ * Walk through all memory which is registered as resource.
  * arg is (start_pfn, nr_pages, private_arg_pointer)
  */
 extern int walk_memory_resource(unsigned long start_pfn,
@@ -188,5 +191,6 @@ extern int arch_add_memory(int nid, u64 
 extern int remove_memory(u64 start, u64 size);
 extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
 								int nr_pages);
+extern void sparse_remove_one_section(struct zone *zone, struct mem_section *ms);
 
 #endif /* __LINUX_MEMORY_HOTPLUG_H */

^ permalink raw reply

* Re: Please pull pasemi.git for-2.6.26 branch
From: Olof Johansson @ 2008-03-06 22:32 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, pasemi-linux, jgarzik
In-Reply-To: <18384.27914.34609.721913@cargo.ozlabs.ibm.com>

On Fri, Mar 07, 2008 at 09:15:38AM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
> 
> > Please pull from 'for-2.6.26' branch of
> > 
> >   master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.26
> > 
> > to receive the following updates. They have all been posted to the list
> > previously, and had only minor updates to remove a couple of compiler
> > warnings:
> > 
> >  arch/powerpc/platforms/pasemi/dma_lib.c |  144 ++++++++++++++
> >  drivers/net/Makefile                    |    3 
> >  drivers/net/pasemi_mac.c                |  324 ++++++++++++++++++++++++++------
> >  drivers/net/pasemi_mac.h                |   35 +++
> >  drivers/net/pasemi_mac_ethtool.c        |  159 +++++++++++++++
> >  include/asm-powerpc/pasemi_dma.h        |   77 +++++++
> >  6 files changed, 681 insertions(+), 61 deletions(-)
> 
> Is Jeff Garzik OK with those pasemi_mac_* updates going via my tree?

Yes, he explicitly asked for it last week:

http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052227.html


-Olof

^ permalink raw reply

* RE: Xilinx Temac link detect
From: John Linn @ 2008-03-06 22:14 UTC (permalink / raw)
  To: khollan, linuxppc-embedded
In-Reply-To: <15883376.post@talk.nabble.com>

Hi Kevin,

I couldn't find any example laying around, so I took a shot at it based
on other non-network examples we had. I've not personally done it so
bear that in mind.

I have not tried to compile any of this, just stole parts for places and
pasted in.

Hope it helps,
John

#include <ioctl.h>

	/*
 	 * FD of the IIC device opened.
 	 */
	int Fdtemac;

	struct mii_ioctl_data ioctl_data;=09

	/*
	 * Open the device.
	 */
	Fdtemac =3D open("/dev/TBD", O_RDWR);
	if(Fdtemac < 0)
	{
		printf("Cannot open the temac device\n");
		return -1;
	}

	/* setup the inputs to the ioctl call */

	ioctl_data.phy_num =3D TBD;
	ioctl_data.reg_num =3D TBD;
=09
	/*
	 * Read the phy register
	 */
	Register =3D ioctl(Fdtemac, SIOCGMIIREG, &ioctl_data);
	if(Status < 0)
	{
		/* failure */
		return 0;
	}

	/* results should be in ioctl_data.val_out I think

}

>From the temac linux adapter, a snippet showing the the ioctl function.

xenet_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
    struct mii_ioctl_data *data =3D (struct mii_ioctl_data *)
&rq->ifr_data;

    case SIOCGMIIREG:   /* Read GMII PHY register. */
        ret =3D XTemac_PhyRead(&lp->Emac, data->phy_id,
                       data->reg_num, &data->val_out);
}

from linux/mii.h

/* This structure is used in all SIOCxMIIxxx ioctl calls */
struct mii_ioctl_data {
	__u16		phy_id;
	__u16		reg_num;
	__u16		val_in;
	__u16		val_out;
};

from linux/if.h

struct ifreq=20
{
#define IFHWADDRLEN	6
	union
	{
		char	ifrn_name[IFNAMSIZ];		/* if name, e.g.
"en0" */
	} ifr_ifrn;
=09
	union {
		struct	sockaddr ifru_addr;
		struct	sockaddr ifru_dstaddr;
		struct	sockaddr ifru_broadaddr;
		struct	sockaddr ifru_netmask;
		struct  sockaddr ifru_hwaddr;
		short	ifru_flags;
		int	ifru_ivalue;
		int	ifru_mtu;
		struct  ifmap ifru_map;
		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
		char	ifru_newname[IFNAMSIZ];
		void __user *	ifru_data;
		struct	if_settings ifru_settings;
	} ifr_ifru;
};

-----Original Message-----
From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org] On
Behalf Of khollan
Sent: Thursday, March 06, 2008 1:44 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Xilinx Temac link detect



I figure I could write a C program to talk to the ioctl in the TEMAC
driver
and read the PHY register.  Does anyone have example code for talking to
network ioctl's?

Thanks

Kevin
--=20
View this message in context:
http://www.nabble.com/Xilinx-Temac-link-detect-tp15616042p15883376.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: Please pull pasemi.git for-2.6.26 branch
From: Paul Mackerras @ 2008-03-06 22:15 UTC (permalink / raw)
  To: Olof Johansson; +Cc: linuxppc-dev, pasemi-linux
In-Reply-To: <20080306214406.GA2631@lixom.net>

Olof Johansson writes:

> Please pull from 'for-2.6.26' branch of
> 
>   master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.26
> 
> to receive the following updates. They have all been posted to the list
> previously, and had only minor updates to remove a couple of compiler
> warnings:
> 
>  arch/powerpc/platforms/pasemi/dma_lib.c |  144 ++++++++++++++
>  drivers/net/Makefile                    |    3 
>  drivers/net/pasemi_mac.c                |  324 ++++++++++++++++++++++++++------
>  drivers/net/pasemi_mac.h                |   35 +++
>  drivers/net/pasemi_mac_ethtool.c        |  159 +++++++++++++++
>  include/asm-powerpc/pasemi_dma.h        |   77 +++++++
>  6 files changed, 681 insertions(+), 61 deletions(-)

Is Jeff Garzik OK with those pasemi_mac_* updates going via my tree?

Paul.

^ permalink raw reply

* Please pull pasemi.git for-2.6.26 branch
From: Olof Johansson @ 2008-03-06 21:44 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev, pasemi-linux

Hi Paul,

Please pull from 'for-2.6.26' branch of

  master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.26

to receive the following updates. They have all been posted to the list
previously, and had only minor updates to remove a couple of compiler
warnings:

 arch/powerpc/platforms/pasemi/dma_lib.c |  144 ++++++++++++++
 drivers/net/Makefile                    |    3 
 drivers/net/pasemi_mac.c                |  324 ++++++++++++++++++++++++++------
 drivers/net/pasemi_mac.h                |   35 +++
 drivers/net/pasemi_mac_ethtool.c        |  159 +++++++++++++++
 include/asm-powerpc/pasemi_dma.h        |   77 +++++++
 6 files changed, 681 insertions(+), 61 deletions(-)

Olof Johansson (6):
      pasemi_mac: Move RX/TX section enablement to dma_lib
      [POWERPC] pasemi: Add flag management functions to dma_lib
      [POWERPC] pasemi: Add function engine management functions to dma_lib
      pasemi_mac: jumbo frame support
      pasemi_mac: Enable GSO by default
      pasemi_mac: basic ethtool support

^ permalink raw reply

* Re: [PATCH 1/5] generic __remove_pages() support
From: Badari Pulavarty @ 2008-03-06 21:42 UTC (permalink / raw)
  To: Dave Hansen; +Cc: linuxppc-dev, Andrew Morton, paulus, lkml, Yasunori Goto
In-Reply-To: <1204836859.4772.32.camel@nimitz.home.sr71.net>

On Thu, 2008-03-06 at 12:54 -0800, Dave Hansen wrote:
> On Thu, 2008-03-06 at 10:55 -0800, Badari Pulavarty wrote:
> > +               if (memmap)
> > +                       __kfree_section_memmap(memmap, PAGES_PER_SECTION);
> > +               return;
> > +       }
> > +
> > +       /*
> > +        * Allocations came from bootmem - how do I free up ?
> > +        */
> > +
> 
> Shouldn't we figure this one out before merging?
> 
> I think we at least need a printk() there.

I can add a printk(). I am hoping Yasunori Goto has something to
handle this, before we really merge into mainline.

Thanks,
Badari

^ permalink raw reply

* Re: [PATCH 1/5] generic __remove_pages() support
From: Dave Hansen @ 2008-03-06 20:54 UTC (permalink / raw)
  To: Badari Pulavarty; +Cc: linuxppc-dev, Andrew Morton, paulus, lkml, Yasunori Goto
In-Reply-To: <1204829734.7939.61.camel@dyn9047017100.beaverton.ibm.com>

On Thu, 2008-03-06 at 10:55 -0800, Badari Pulavarty wrote:
> +               if (memmap)
> +                       __kfree_section_memmap(memmap, PAGES_PER_SECTION);
> +               return;
> +       }
> +
> +       /*
> +        * Allocations came from bootmem - how do I free up ?
> +        */
> +

Shouldn't we figure this one out before merging?

I think we at least need a printk() there.

-- Dave

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox