* Re : kernel 2.6.26 & gcc 4.0.0
From: Fabien Oriede @ 2008-08-07 10:06 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4310 bytes --]
No, I did not modify this file.
----- Message d'origine ----
De : Marco Stornelli <marco.stornelli@coritel.it>
À : Fabien Oriede <fabien.oriede@yahoo.fr>
Cc : linuxppc-embedded@ozlabs.org
Envoyé le : Jeudi, 7 Août 2008, 11h59mn 19s
Objet : Re: kernel 2.6.26 & gcc 4.0.0
Fabien Oriede ha scritto:
> Hello all,
> I'm trying to put a cramfs image on my custom board, and for this, I have followed this topic : http://www.denx.de/wiki/view/DULG/RootFileSystemOnACramfsFileSystem
> Now I have my cramfs image, but I have seen that I need to download my cramfs image in a mtdblock and for that, I need to set some MTD options in the kernel. (http://www.denx.de/wiki/view/DULG/FlashFilesystemsMTD)
> But when I make the command "make uImage", I have this problem :
> [root@xxxx linux-2.6.26]# make uImage
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> CALL arch/powerpc/kernel/systbl_chk.sh
> CC arch/ppc/syslib/m8xx_setup.o
> arch/ppc/syslib/m8xx_setup.c:68: error: array type has incomplete element type
> arch/ppc/syslib/m8xx_setup.c:70: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:70: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c:71: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:71: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c:72: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:72: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c:73: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:73: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c:73: error: 'MTD_WRITEABLE' undeclared here (not in a function)
> arch/ppc/syslib/m8xx_setup.c:75: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:75: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c:76: error: field name not in record or union initializer
> arch/ppc/syslib/m8xx_setup.c:76: error: (near initialization for 'mpc8xxads_partitions')
> arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_show_percpuinfo':
> arch/ppc/syslib/m8xx_setup.c:312: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
> arch/ppc/syslib/m8xx_setup.c:312: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
> arch/ppc/syslib/m8xx_setup.c: In function 'platform_init':
> arch/ppc/syslib/m8xx_setup.c:451: warning: assignment from incompatible pointer type
> make[1]: *** [arch/ppc/syslib/m8xx_setup.o] Erreur 1
> make: *** [arch/ppc/syslib] Erreur 2
>
> [root@xxxx linux-2.6.26]# powerpc-linux-gcc --version
> powerpc-linux-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
> It seems that this is a problem with the version 4 of the gcc, and I would like to know if I need to change for an old version of gcc ? like 3.0. Or may be a patch exists to bring down this problem ?
> Thanks in advance.
> Regards,
> Fabien.
>
>
> _____________________________________________________________________________
> Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Have you modified that file?
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
_____________________________________________________________________________
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
[-- Attachment #2: Type: text/html, Size: 5707 bytes --]
^ permalink raw reply
* Re: Re : kernel 2.6.26 & gcc 4.0.0
From: Marco Stornelli @ 2008-08-07 10:18 UTC (permalink / raw)
To: Fabien Oriede; +Cc: linuxppc-embedded
In-Reply-To: <292718.59127.qm@web27401.mail.ukl.yahoo.com>
Maybe the problem is in the ppc tree. Since 2.6.27 ppc will be removed,
perhaps, for your board the code isn't really tested in that tree. Check
out if your board is under powerpc tree. However strange errors, it
seems a lack of a semicolon or something like this.
Fabien Oriede ha scritto:
> No, I did not modify this file.
>
>
> ----- Message d'origine ----
> De : Marco Stornelli <marco.stornelli@coritel.it>
> À : Fabien Oriede <fabien.oriede@yahoo.fr>
> Cc : linuxppc-embedded@ozlabs.org
> Envoyé le : Jeudi, 7 Août 2008, 11h59mn 19s
> Objet : Re: kernel 2.6.26 & gcc 4.0.0
>
> Fabien Oriede ha scritto:
>> Hello all,
>> I'm trying to put a cramfs image on my custom board, and for this, I have followed this topic : http://www.denx.de/wiki/view/DULG/RootFileSystemOnACramfsFileSystem
>> Now I have my cramfs image, but I have seen that I need to download my cramfs image in a mtdblock and for that, I need to set some MTD options in the kernel. (http://www.denx.de/wiki/view/DULG/FlashFilesystemsMTD)
>> But when I make the command "make uImage", I have this problem :
>> [root@xxxx linux-2.6.26]# make uImage
>> CHK include/linux/version.h
>> CHK include/linux/utsrelease.h
>> CALL scripts/checksyscalls.sh
>> CHK include/linux/compile.h
>> CALL arch/powerpc/kernel/systbl_chk.sh
>> CC arch/ppc/syslib/m8xx_setup.o
>> arch/ppc/syslib/m8xx_setup.c:68: error: array type has incomplete element type
>> arch/ppc/syslib/m8xx_setup.c:70: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:70: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c:71: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:71: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c:72: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:72: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c:73: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:73: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c:73: error: 'MTD_WRITEABLE' undeclared here (not in a function)
>> arch/ppc/syslib/m8xx_setup.c:75: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:75: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c:76: error: field name not in record or union initializer
>> arch/ppc/syslib/m8xx_setup.c:76: error: (near initialization for 'mpc8xxads_partitions')
>> arch/ppc/syslib/m8xx_setup.c: In function 'm8xx_show_percpuinfo':
>> arch/ppc/syslib/m8xx_setup.c:312: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
>> arch/ppc/syslib/m8xx_setup.c:312: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
>> arch/ppc/syslib/m8xx_setup.c: In function 'platform_init':
>> arch/ppc/syslib/m8xx_setup.c:451: warning: assignment from incompatible pointer type
>> make[1]: *** [arch/ppc/syslib/m8xx_setup.o] Erreur 1
>> make: *** [arch/ppc/syslib] Erreur 2
>>
>> [root@xxxx linux-2.6.26]# powerpc-linux-gcc --version
>> powerpc-linux-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
>> Copyright (C) 2005 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
>> It seems that this is a problem with the version 4 of the gcc, and I would like to know if I need to change for an old version of gcc ? like 3.0. Or may be a patch exists to bring down this problem ?
>> Thanks in advance.
>> Regards,
>> Fabien.
>>
>>
>> _____________________________________________________________________________
>> Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> Have you modified that file?
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Wolfgang Grandegger @ 2008-08-07 10:20 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev
In-Reply-To: <20080807102126.5980c761@hyperion.delvare>
Jean Delvare wrote:
> Hi Grant, Wolgang,
>
> On Thu, 17 Jul 2008 12:02:50 -0600, Grant Likely wrote:
>> On Thu, Jul 17, 2008 at 4:37 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>> This patch suppresses I2C device probing by clearing the class field
>>> of the "struct i2c_adapter" for the MPC I2C bus adapters. Some board
>>> configurations which rely on probing must be fixed up by adding a
>>> proper I2C device node to the DTS file, like the TQM85xx modules.
>>>
>>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>>
>>> ---
>>> drivers/i2c/busses/i2c-mpc.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> Index: powerpc/drivers/i2c/busses/i2c-mpc.c
>>> ===================================================================
>>> --- powerpc.orig/drivers/i2c/busses/i2c-mpc.c
>>> +++ powerpc/drivers/i2c/busses/i2c-mpc.c
>>> @@ -312,7 +312,6 @@ static struct i2c_adapter mpc_ops = {
>>> .name = "MPC adapter",
>>> .id = I2C_HW_MPC107,
>>> .algo = &mpc_algo,
>>> - .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>>> .timeout = 1,
>>> };
>
> Unless you intend to push this patch upstream yourself (through the ppc
> tree), you should send it to Ben Dooks (who is in charge of this part
> of the i2c subsystem) with Cc to the i2c list.
I just want to mention, that other I2 bus drivers set I2C_CLASS_HWMON as well.
Here are the PowerPC related ones:
$ grep I2C_CLASS_HWMON *
i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
It would be consequent to remove them as well.
Wolfgang.
^ permalink raw reply
* Re: Powerpc and ioremap
From: Juergen Beisert @ 2008-08-07 10:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Sébastien Chrétien
In-Reply-To: <319b0ac50808070254x27606b48sb15fb4ee6105c6c6@mail.gmail.com>
Am Donnerstag, 7. August 2008 11:54 schrieb S=E9bastien Chr=E9tien:
> Hello,
>
> I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26 a=
nd
> gcc 3.4.5.
> I have used Uboot 1.2.
> Linux seems running from _start to udbg_early_init(). That's why I
> develloped a udbg_driver.
> It must write in a register which is located at 0x2001b044. So I wrote :
>
> void __iomem *p;
> p=3Dioremap(0x2001b044,4);
> iowrite32('O',p);
> iowrite32('K',p);
try
p=3Dioremap(0x2001b000, 0x1000);
iowrite32('O',p + 0x44);
iowrite32('K',p + 0x44);
instead.
jbe
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
From: Michael Ellerman @ 2008-08-07 10:32 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141427.GG1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> @@ -51,6 +50,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
> else {
> /* FIXME Merge this with xmon_save_regs ?? */
> unsigned long tmp1, tmp2;
> +#ifdef __powerpc64__
> __asm__ __volatile__ (
> "std 0,0(%2)\n"
> "std 1,8(%2)\n"
> @@ -99,16 +99,58 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
> : "=&r" (tmp1), "=&r" (tmp2)
> : "b" (newregs)
> : "memory");
> +#else /* __powerpc64__ */
> + __asm__ __volatile__ (
> + "stw 0,0(%2)\n"
> + "stw 1,4(%2)\n"
> + "stw 2,8(%2)\n"
> + "stw 3,12(%2)\n"
> + "stw 4,16(%2)\n"
> + "stw 5,20(%2)\n"
> + "stw 6,24(%2)\n"
> + "stw 7,28(%2)\n"
> + "stw 8,32(%2)\n"
..
Hi Anton,
You should be able to avoid any use of #ifdefs in this routine. Look at
SAVE_GPR() and friends in asm/ppc_asm.h.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
From: Michael Ellerman @ 2008-08-07 10:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141414.GA1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Refactor the setting of kexec OF properties, moving the common code
> from machine_kexec_64.c to machine_kexec.c where it can be used on
> both ppc64 and ppc32. This is needed for kexec to work on ppc32
> platforms.
Hi Anton,
> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> index aab7688..a625673 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
...
> +
> +static int __init kexec_setup(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_node_by_path("/chosen");
> + if (!node)
> + return -ENOENT;
> +
> + kernel_end = __pa(_end);
> + prom_add_property(node, &kernel_end_prop);
> +
> + of_node_put(node);
> + return 0;
> +}
> +__initcall(kexec_setup);
__initcall() is supposedly deprecated, use device_initcall() instead.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
From: Michael Ellerman @ 2008-08-07 10:47 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080801141425.GF1161@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> Refactor the setting of kexec OF properties, moving the common code
> from machine_kexec_64.c to machine_kexec.c where it can be used on
> both ppc64 and ppc32. This will be needed for kdump to work on ppc32
> platforms.
Hi Anton,
> diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> index ac42cfb..bfef717 100644
> --- a/arch/powerpc/kernel/machine_kexec.c
> +++ b/arch/powerpc/kernel/machine_kexec.c
> @@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
>
> static int __init kexec_setup(void)
> {
> struct device_node *node;
> @@ -135,6 +171,8 @@ static int __init kexec_setup(void)
> kernel_end = __pa(_end);
> prom_add_property(node, &kernel_end_prop);
>
> + export_crashk_values(node);
> +
> of_node_put(node);
> return 0;
> }
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> index c30678d..2aab296 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
...
> -
> static int __init kexec_setup(void)
> {
> export_htab_values();
> - export_crashk_values();
> return 0;
> }
> __initcall(kexec_setup);
This leaves us with two routines called kexec_setup(), do you mind
getting rid of this one and making export_htab_values() an initcall
directly.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Jochen Friedrich @ 2008-08-07 10:50 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Jean Delvare, Linuxppc-dev
In-Reply-To: <489ACC69.5070701@grandegger.com>
Hi Wolfgang,
> $ grep I2C_CLASS_HWMON *
> i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>
> It would be consequent to remove them as well.
ACK for the i2c-cpm part.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Jean Delvare @ 2008-08-07 11:07 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linuxppc-dev
In-Reply-To: <489AD363.6070608@scram.de>
On Thu, 07 Aug 2008 12:50:11 +0200, Jochen Friedrich wrote:
> Hi Wolfgang,
>
> > $ grep I2C_CLASS_HWMON *
> > i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> > i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
> > i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> > i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> > i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
> >
> > It would be consequent to remove them as well.
>
> ACK for the i2c-cpm part.
No objection on my side. It's really up to each platform to choose the
way they want to handle i2c device creation, and stick to it.
As I understand it, the removal of the adapter class needs to be
synchronized with platform code changes. Thus it might make sense to
push these through their respective arch trees, rather than the i2c
tree.
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
From: Anton Vorontsov @ 2008-08-07 11:11 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1218106051.7914.12.camel@localhost>
On Thu, Aug 07, 2008 at 08:47:31PM +1000, Michael Ellerman wrote:
> On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > Refactor the setting of kexec OF properties, moving the common code
> > from machine_kexec_64.c to machine_kexec.c where it can be used on
> > both ppc64 and ppc32. This will be needed for kdump to work on ppc32
> > platforms.
>
> Hi Anton,
Hi,
> > diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
> > index ac42cfb..bfef717 100644
> > --- a/arch/powerpc/kernel/machine_kexec.c
> > +++ b/arch/powerpc/kernel/machine_kexec.c
> > @@ -117,6 +117,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long size)
> >
>
> > static int __init kexec_setup(void)
> > {
> > struct device_node *node;
> > @@ -135,6 +171,8 @@ static int __init kexec_setup(void)
> > kernel_end = __pa(_end);
> > prom_add_property(node, &kernel_end_prop);
> >
> > + export_crashk_values(node);
> > +
> > of_node_put(node);
> > return 0;
> > }
> > diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> > index c30678d..2aab296 100644
> > --- a/arch/powerpc/kernel/machine_kexec_64.c
> > +++ b/arch/powerpc/kernel/machine_kexec_64.c
> ...
>
> > -
> > static int __init kexec_setup(void)
> > {
> > export_htab_values();
> > - export_crashk_values();
> > return 0;
> > }
> > __initcall(kexec_setup);
>
> This leaves us with two routines called kexec_setup(), do you mind
> getting rid of this one and making export_htab_values() an initcall
> directly.
Yup, good idea. Will do this, and will address your other comments,
too.
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
From: Anton Vorontsov @ 2008-08-07 11:38 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218104362.29628.41.camel@Gundam>
On Thu, Aug 07, 2008 at 06:19:22PM +0800, Li Yang wrote:
> On Wed, 2008-08-06 at 19:24 +0400, Anton Vorontsov wrote:
> > On Wed, Aug 06, 2008 at 03:04:41PM +0800, Li Yang wrote:
> > > Signed-off-by: Li Yang <leoli@freescale.com>
> > > ---
> > > arch/powerpc/sysdev/cpm2.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
> > > index f1c3395..021480e 100644
> > > --- a/arch/powerpc/sysdev/cpm2.c
> > > +++ b/arch/powerpc/sysdev/cpm2.c
> > > @@ -52,6 +52,7 @@ cpm_cpm2_t __iomem *cpmp; /* Pointer to comm processor space */
> > > * the communication processor devices.
> > > */
> > > cpm2_map_t __iomem *cpm2_immr;
> > > +EXPORT_SYMBOL(cpm2_immr);
> >
> > This is uneeded if you'll start using cpm_muram_* functions
> > from include/asm-powerpc/cpm.h.
>
> Right. But there are still a few in tree drivers rely on this such as
> fs_enet.
Probably they should be fixed... Only two users left:
$ git-grep cpm2_immr drivers/
drivers/mtd/maps/wr_sbc82xx_flash.c: volatile memctl_cpm2_t *mc = &cpm2_immr->im_memctl;
drivers/mtd/maps/wr_sbc82xx_flash.c: mc = &cpm2_immr->im_memctl;
drivers/net/fs_enet/fs_enet-main.c: fs_enet_immap = cpm2_immr;
drivers/net/fs_enet/mac-fcc.c: fep->fcc.mem = (void __iomem *)cpm2_immr;
I think wr_sbc82xx_flash.c is superseded by the physmap_of driver. There
is no single CONFIG_MTD_SBC8240 enabled in the powerpc/configs.
Plus, I wonder how they didn't break the build all that time w/o
EXPORT_SYMBOL(). Probably nobody tried to build them as modules.
> Ps: In your cpm_muram_init() you re-mapped the muram space separately .
> Are we planning to get rid of cpm2_immr completely and manage memory
> mapping by each block?
At least I always thought so...
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Powerpc and ioremap
From: Sébastien Chrétien @ 2008-08-07 12:15 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <200808071223.11156.j.beisert@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
Thanks for your answer.
But it doesn't work.
I think ioremap create a kernel panic. But I can't see because i have no
UART ready.
Is there a way in order to trace the failure ?
2008/8/7, Juergen Beisert <j.beisert@pengutronix.de>:
>
> Am Donnerstag, 7. August 2008 11:54 schrieb Sébastien Chrétien:
>
> > Hello,
> >
> > I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26
> and
> > gcc 3.4.5.
> > I have used Uboot 1.2.
> > Linux seems running from _start to udbg_early_init(). That's why I
> > develloped a udbg_driver.
> > It must write in a register which is located at 0x2001b044. So I wrote :
> >
> > void __iomem *p;
> > p=ioremap(0x2001b044,4);
> > iowrite32('O',p);
> > iowrite32('K',p);
>
>
> try
>
> p=ioremap(0x2001b000, 0x1000);
> iowrite32('O',p + 0x44);
> iowrite32('K',p + 0x44);
>
> instead.
>
> jbe
>
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
>
[-- Attachment #2: Type: text/html, Size: 1695 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Matthias Fuchs @ 2008-08-07 12:48 UTC (permalink / raw)
To: linuxppc-dev
This patch fixes the setting of the Book-E watchdog timer interval setup
on initialization and by ioctl().
Tested on PPC440EPx sequoia evaluation board.
Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
---
drivers/watchdog/booke_wdt.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 7708244..9db5478 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -42,8 +42,10 @@ u32 booke_wdt_period = WDT_PERIOD_DEFAULT;
#ifdef CONFIG_FSL_BOOKE
#define WDTP(x) ((((63-x)&0x3)<<30)|(((63-x)&0x3c)<<15))
+#define WDTP_MASK (WDTP(63))
#else
#define WDTP(x) (TCR_WP(x))
+#define WDTP_MASK (TCR_WP_MASK)
#endif
static DEFINE_SPINLOCK(booke_wdt_lock);
@@ -65,6 +67,7 @@ static void __booke_wdt_enable(void *data)
/* clear status before enabling watchdog */
__booke_wdt_ping(NULL);
val = mfspr(SPRN_TCR);
+ val &= ~WDTP_MASK;
val |= (TCR_WIE|TCR_WRC(WRC_CHIP)|WDTP(booke_wdt_period));
mtspr(SPRN_TCR, val);
@@ -106,7 +109,8 @@ static int booke_wdt_ioctl(struct inode *inode, struct file *file,
case WDIOC_SETTIMEOUT:
if (get_user(booke_wdt_period, p))
return -EFAULT;
- mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(booke_wdt_period));
+ tmp = mfspr(SPRN_TCR) & ~WDTP_MASK;
+ mtspr(SPRN_TCR, tmp | WDTP(booke_wdt_period));
return 0;
case WDIOC_GETTIMEOUT:
return put_user(booke_wdt_period, p);
--
1.5.3
^ permalink raw reply related
* Re: Powerpc and ioremap
From: Sébastien Chrétien @ 2008-08-07 12:56 UTC (permalink / raw)
To: Juergen Beisert; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808070515o7a28cf34ue190dd3dba0ee157@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
Can we call ioremap() during udbg_early_init ?
2008/8/7, Sébastien Chrétien <sebastien.chretien.enseirb@gmail.com>:
>
> Thanks for your answer.
> But it doesn't work.
> I think ioremap create a kernel panic. But I can't see because i have no
> UART ready.
> Is there a way in order to trace the failure ?
>
> 2008/8/7, Juergen Beisert <j.beisert@pengutronix.de>:
>>
>> Am Donnerstag, 7. August 2008 11:54 schrieb Sébastien Chrétien:
>>
>> > Hello,
>> >
>> > I am trying to port linux on my Powerpc Board. I have used Linux 2.6.26
>> and
>> > gcc 3.4.5.
>> > I have used Uboot 1.2.
>> > Linux seems running from _start to udbg_early_init(). That's why I
>> > develloped a udbg_driver.
>> > It must write in a register which is located at 0x2001b044. So I wrote :
>> >
>> > void __iomem *p;
>> > p=ioremap(0x2001b044,4);
>> > iowrite32('O',p);
>> > iowrite32('K',p);
>>
>>
>> try
>>
>> p=ioremap(0x2001b000, 0x1000);
>> iowrite32('O',p + 0x44);
>> iowrite32('K',p + 0x44);
>>
>> instead.
>>
>> jbe
>>
>> --
>> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>> Pengutronix - Linux Solutions for Science and Industry
>> Handelsregister: Amtsgericht Hildesheim, HRA 2686
>> Hannoversche Str. 2, 31134 Hildesheim, Germany
>> Phone: +49-5121-206917-7 | Fax: +49-5121-206917-9
>>
>
>
[-- Attachment #2: Type: text/html, Size: 2358 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] gianfar: Magic Packet and suspend/resume support.
From: Kumar Gala @ 2008-08-07 12:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Scott Wood, linuxppc-dev, netdev
In-Reply-To: <489AAB3E.8020507@pobox.com>
On Aug 7, 2008, at 2:58 AM, Jeff Garzik wrote:
> Scott Wood wrote:
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> ---
>> Documentation/powerpc/booting-without-of.txt | 5 +-
>> arch/powerpc/sysdev/fsl_soc.c | 3 +
>> drivers/net/gianfar.c | 118 ++++++++++++++++
>> +++++++++-
>> drivers/net/gianfar.h | 12 ++-
>> drivers/net/gianfar_ethtool.c | 41 +++++++++-
>> include/linux/fsl_devices.h | 1 +
>> 6 files changed, 172 insertions(+), 8 deletions(-)
>
> did this ever get ack'd by Kumar? I don't have a record of it.
>
A version of this is already in linus's tree. I just forgot to add
your Ack to it (and I apologize for that).
git commit d87eb12785c14de1586e3bad86ca2c0991300339
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Kumar Gala @ 2008-08-07 13:19 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200808071448.06183.matthias.fuchs@esd-electronics.com>
On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:
> This patch fixes the setting of the Book-E watchdog timer interval
> setup
> on initialization and by ioctl().
>
> Tested on PPC440EPx sequoia evaluation board.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
> ---
> drivers/watchdog/booke_wdt.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
can you be more explicit about what the bug was.
- k
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
From: Anton Vorontsov @ 2008-08-07 13:23 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218101504.29628.32.camel@Gundam>
On Thu, Aug 07, 2008 at 05:31:44PM +0800, Li Yang wrote:
[...]
> >
> > > reg = <0x6c0 0x40 0x8b00 0x100>;
> > > interrupts = <11>;
> > > interrupt-parent = <&qeic>;
> > > mode = "slave";
> >
> > I'd suggest to rename this to "peripheral" as we use for fsl dual-role
> > usb controller.
>
> As there will be two drivers chosen by compatible, I'm now inclined to
> put this information in compatible.
Please don't. I deliberately wrote bindings w/o specifing "udc" or
"host" in the compatible entry.
"udc"/"host" is the modes of an USB controller, but the controller
itself is the same: "fsl,mpc8323-qe-usb" (the first chip with QE USB).
So the driver should always match this device, but it can return
-ENODEV if mode is unspecified or !peripheral.
> > > + usb-clock = <21>;
> > > + pio-handle = <&pio_usb>;
> >
> > Can we not introduce new pio maps? The pio setup should be done
> > by the firmware, or at least fixed up via the board file, as in
> > arch/powerpc/platforms/83xx/mpc832x_rdb.c.
>
> Actually I am more apt to leaving full hardware access to kernel than
> firmware, especially for devices that are not used in firmware. The
> reason why I made the pin-configuration flexible is that for development
> boards the role of pins are often changeable.
[...]
> Pio config is board and board configuration specific. It's better to
> make it configurable by device tree.
Device tree isn't configuration file. The bad thing about pio-map is that
it is passing raw values instead of actually describing the hardware.
For example,
pio-map = <1 6 2 0 1 0>;
The thing describes bankB/pin6.. but you'll can't tell what exactly
this pin supposed to do. :-/
Basically "pio-map" is expanded version of this:
fsl,cpodr-reg = <0x...>;
fsl,cppar1-reg = <0x...>;
fsl,cppar2-reg = <0x...>;
...
Instead, it would be great to have something like this:
usb@... {
/*
* gpio/pinmux pin
* controller
*/
pio-map = <&pinmuxA 1 /* bindings says first pin is clk */
&pinmuxB 14 /* bindings says second pin is usboe */
...>;
};
ucc@... {
pio-map = <&pinmuxA 2 /* bindings says first pin is clk */
&pinmuxB 24 /* bindings says second pin is rxd0 */
&pinmuxB 21 /* bindings says second pin is rxd1 */
...>;
};
Then drivers would call something like this in probe():
clk = qe_get_clock(node, "fsl,fullspeed-clock");
qe_set_pinmux(pin0, QE_PIN_FUNC_CLK(clk));
qe_set_pinmux(pin1, QE_PIN_FUNC_USB_OE);
...or ucc ethernet...
qe_set_pinmux(pin[rx_n], QE_PIN_FUNC_UCC_RXD(ucc_num, rx_n));
Obviously, this is quite hard to implement (and expensive, too), since
each SoC implementation has its own function<->pin<->regvalue mapping..
Thus nobody even think to bother with this.
Anyway, I'm not that opposed to the current pio-maps, but it
would be great if we could avoid them where possible.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
From: Matthias Fuchs @ 2008-08-07 14:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <A4CCB071-0FCE-490A-B563-399FCA74C71E@kernel.crashing.org>
Sure,
the former line:
mtspr(SPRN_TCR, (mfspr(SPRN_TCR)&~WDTP(0))|WDTP(booke_wdt_period));
tries to mask the wdt interval period bits by and'ing with ~WDTP(0) which
is 0xffffffff. So no bits are cleared and or'ing a new value does not change anything.
The default interval is '3' which is the maximum, so any attempt to set a new
interval keeps the former '3'.
The patch correctly masks the period bits in SPRN_TCR before writing the new value.
That's all.
Matthias
On Thursday 07 August 2008 15:19, Kumar Gala wrote:
>
> On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:
>
> > This patch fixes the setting of the Book-E watchdog timer interval
> > setup
> > on initialization and by ioctl().
> >
> > Tested on PPC440EPx sequoia evaluation board.
> >
> > Signed-off-by: Matthias Fuchs <matthias.fuchs@esd-electronics.com>
> > ---
> > drivers/watchdog/booke_wdt.c | 6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
>
> can you be more explicit about what the bug was.
>
> - k
>
>
^ permalink raw reply
* Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
From: Scott Wood @ 2008-08-07 14:19 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218081014.29628.9.camel@Gundam>
On Thu, Aug 07, 2008 at 11:50:14AM +0800, Li Yang wrote:
> udc is a common name for USB device mode drivers to work with Linux
> gadget. We will have two separate drivers for USB host and device.
> Probably we can have two compatibles "fsl,qe_udc" and "fsl,qe-usb-host"
1. If you have separate compatibles, what do you need the "mode" property
for?
2. mpc8272 is not QE.
3. fsl,cpm2-usb-slave would be much more readable than fsl,qe_udc.
-Scott
^ permalink raw reply
* Re: [PATCH] i2c-mpc: suppress I2C device probing
From: Grant Likely @ 2008-08-07 14:33 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linuxppc-dev
In-Reply-To: <20080807130717.56694249@hyperion.delvare>
On Thu, Aug 7, 2008 at 5:07 AM, Jean Delvare <khali@linux-fr.org> wrote:
> On Thu, 07 Aug 2008 12:50:11 +0200, Jochen Friedrich wrote:
>> Hi Wolfgang,
>>
>> > $ grep I2C_CLASS_HWMON *
>> > i2c-cpm.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>> > i2c-mpc.c: .class = I2C_CLASS_HWMON | I2C_CLASS_SPD,
>> > i2c-ibm_iic.c: adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> > i2c-pasemi.c: smbus->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> > i2c-mv64xxx.c: drv_data->adapter.class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
>> >
>> > It would be consequent to remove them as well.
>>
>> ACK for the i2c-cpm part.
>
> No objection on my side. It's really up to each platform to choose the
> way they want to handle i2c device creation, and stick to it.
>
> As I understand it, the removal of the adapter class needs to be
> synchronized with platform code changes. Thus it might make sense to
> push these through their respective arch trees, rather than the i2c
> tree.
All right, I'm happy to pick these patches up if nobody objects.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-08-07 16:06 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <1218052249.10907.125.camel@nimitz>
On (06/08/08 12:50), Dave Hansen didst pronounce:
> On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote:
> > > That said, this particular patch doesn't appear *too* bound to hugetlb
> > > itself. But, some of its limitations *do* come from the filesystem,
> > > like its inability to handle VM_GROWS...
> >
> > The lack of VM_GROWSX is an issue, but on its own it does not justify
> > the amount of churn necessary to support direct pagetable insertions for
> > MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would
> > really benefit from direct insertions to pagetables instead of hugetlbfs so
> > that the path would get adequately tested.
>
> I'm jumping around here a bit, but I'm trying to get to the core of what
> my problem with these patches is. I'll see if I can close the loop
> here.
>
> The main thing this set of patches does that I care about is take an
> anonymous VMA and replace it with a hugetlb VMA. It does this on a
> special cue, but does it nonetheless.
>
This is not actually a new thing. For a long time now, it has been possible to
back malloc() with hugepages at a userspace level using the morecore glibc
hook. That is replacing anonymous memory with a file-backed VMA. It happens
in a different place but it's just as deliberate as backing stack and the
end result is very similar. As the file is ram-based, it doesn't have the
same types of consequences like dirty page syncing that you'd ordinarily
watch for when moving from anonymous to file-backed memory.
> This patch has crossed a line in that it is really the first
> *replacement* of a normal VMA with a hugetlb VMA instead of the creation
> of the VMAs at the user's request.
We crossed that line with morecore, it's back there somewhere. We're just
doing in kernel this time because backing stacks with hugepages in userspace
turned out to be a hairy endevour.
Properly supporting anonymous hugepages would either require larger
changes to the core or reimplementing yet more of mm/ in mm/hugetlb.c.
Neither is a particularly appealing approach, nor is it likely to be a
very popular one.
> I'm really curious what the plan is
> to follow up on this. Will this stack stuff turn out to be one-off
> code, or is this *the* route for getting transparent large pages in the
> future?
>
Conceivably, we could also implement MAP_LARGEPAGE for MAP_ANONYMOUS
which would use the same hugetlb_file_setup() as for shmem and stacks
with this patch. It would be a reliavely straight-forward patch if reusing
hugetlb_file_setup() as the flags can be passed through almost verbatim. In
that case, hugetlbfs still makes a good fit without making direct pagetable
insertions necessary.
> Because of the limitations like its inability to grow the VMA, I can't
> imagine that this would be a generic mechanism that we can use
> elsewhere.
>
What other than a stack even cares about VM_GROWSDOWN working? Besides,
VM_GROWSDOWN could be supported in a hugetlbfs file by mapping the end of
the file and moving the offset backwards (yeah ok, it ain't the prettiest
but it's less churn than introducing significantly different codepaths). It's
just not something that needs to be supported at first cut.
brk() if you wanted to back hugepages with it conceivably needs a resizing
VMA but in that case it's growing up in which case just extend the end of
the VMA and increase the size of the file.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [RFC] Driver helper functions.....
From: Sean MacLennan @ 2008-08-07 16:22 UTC (permalink / raw)
To: linuxppc-dev, Josh Boyer
The design of the warp is basically a processor, an FPGA, some RAM,
some flash, and some glue logic. As the number of drivers rapidly
expands... we are starting to hit inter-driver conflicts with a select
few FPGA registers.
So we need a few "helper" functions to handle locking. Basically
something like this:
static DEFINE_SPINLOCK(fpga_lock);
void warp_fpga_set_imr(imr)
{ /* imr = interrupt mask register */
lock
read/modify/write imr
unlock
}
void warp_fpga_clear_imr(imr);
int warp_fpga_indirect_read();
int warp_fpga_indirect_write();
Maybe a couple more, but I think it would basically be four functions.
So I see a few solutions:
1) Write an fpga driver. That seems overkill for basically exporting
four functions.
2) Add a non-static spinlock to the platform code and export that. This
adds minimal code to the platform code but gives eveybody a lock that
is always there.
3) Add the above functions to the platform code.
So my questions are, what would be best practice? Would adding the
functions and/or spinlock to the platform code be kosher?
And if I did add the spinlock and/or functions to the platform code,
where would I put the include file to export them from? In the arch
code itself? i.e. arch/powerpc/platforms/44x/warp.h?
Cheers,
Sean
^ permalink raw reply
* Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Scott Wood @ 2008-08-07 16:45 UTC (permalink / raw)
To: Grant Likely; +Cc: paulus, miltonm, linuxppc-dev
In-Reply-To: <fa686aa40808061611p616208bp2baf9a0d5e095870@mail.gmail.com>
On Wed, Aug 06, 2008 at 05:11:08PM -0600, Grant Likely wrote:
> I do this particular test to make absolute sure that the caller
> absolutely understands the limitations of the block mapping. If they
> call this with something that isn't 128k aligned, then I make it fail
> immediately so the coder is forced to go and understand what they are
> allowed to do. Basically, I'm reinforcing the fact that this is not
> the same as ioremap().
>
> I haven't decided yet if I should test size in the same way. Thoughts?
I'd prefer it round up the size as needed to cover the requested mapping
and needed alignment.
The minimum size is going to be different on Book E, for example, and I
can think of at least one user that will be shared between Book E and
classic (CPM2 early console).
-Scott
^ permalink raw reply
* RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Yoder Stuart @ 2008-08-07 17:28 UTC (permalink / raw)
To: David Gibson, TABI TIMUR
Cc: linuxppc-dev, devicetree-discuss, paulus, miltonm
In-Reply-To: <20080807061254.GB12571@yookeroo.seuss>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of David Gibson
> Sent: Thursday, August 07, 2008 1:13 AM
> To: Tabi Timur
> Cc: linuxppc-dev@ozlabs.org; paulus@samba.org; miltonm@bga.com
> Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout()=20
> utility function
>=20
> On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote:
> > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely=20
> <grant.likely@secretlab.ca> wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > of_lookup_stdout() is useful for figuring out what device=20
> to use as output
> > > for early boot progress messages. It returns the node=20
> pointed to by the
> > > linux,stdout-path property in the chosen node.
> >=20
> > I thought linux,stdout-path is deprecated are we're supposed to be
> > using the aliases node instead?
>=20
> During the ePAPR process this idea came up - standardising a 'stdout'
> alias that would replace linux,stdout-path in chosen. However that
> was done in ignorance of the history of the linux,stdout-path property
> and its connection to the stdout ihandle in chosen. In any case, the
> proposed 'stdout' alias didn't make the final cut for ePAPR, so how to
> address this for flat-tree systems is still an open question.
In the ePAPR discussion I think we generally agreed that
an alias was better than a property under /chosen. There
were 2 things that caused us to delete the /aliases/stdout.
One was discussions around whether we needed to support
multiple consoles somehow.
The second was the idea that we may need a /aliases/stdin as well.
You could conceptually have stdout be a monitor and a stdin
be a keyboard.
Stuart
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Dave Hansen @ 2008-08-07 17:29 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <20080807160605.GA9200@csn.ul.ie>
On Thu, 2008-08-07 at 17:06 +0100, Mel Gorman wrote:
> On (06/08/08 12:50), Dave Hansen didst pronounce:
> > The main thing this set of patches does that I care about is take an
> > anonymous VMA and replace it with a hugetlb VMA. It does this on a
> > special cue, but does it nonetheless.
>
> This is not actually a new thing. For a long time now, it has been possible to
> back malloc() with hugepages at a userspace level using the morecore glibc
> hook. That is replacing anonymous memory with a file-backed VMA. It happens
> in a different place but it's just as deliberate as backing stack and the
> end result is very similar. As the file is ram-based, it doesn't have the
> same types of consequences like dirty page syncing that you'd ordinarily
> watch for when moving from anonymous to file-backed memory.
Yes, it has already been done in userspace. That's fine. It isn't
adding any complexity to the kernel. This is adding behavior that the
kernel has to support as well as complexity.
> > This patch has crossed a line in that it is really the first
> > *replacement* of a normal VMA with a hugetlb VMA instead of the creation
> > of the VMAs at the user's request.
>
> We crossed that line with morecore, it's back there somewhere. We're just
> doing in kernel this time because backing stacks with hugepages in userspace
> turned out to be a hairy endevour.
>
> Properly supporting anonymous hugepages would either require larger
> changes to the core or reimplementing yet more of mm/ in mm/hugetlb.c.
> Neither is a particularly appealing approach, nor is it likely to be a
> very popular one.
I agree. It is always much harder to write code that can work
generically (and get it accepted) than just write the smallest possible
hack and stick it in fs/exec.c.
Could this patch at least get fixed up to look like it could be used
more generically? Some code to look up and replace anonymous VMAs with
hugetlb-backed ones.
> > Because of the limitations like its inability to grow the VMA, I can't
> > imagine that this would be a generic mechanism that we can use
> > elsewhere.
>
> What other than a stack even cares about VM_GROWSDOWN working? Besides,
> VM_GROWSDOWN could be supported in a hugetlbfs file by mapping the end of
> the file and moving the offset backwards (yeah ok, it ain't the prettiest
> but it's less churn than introducing significantly different codepaths). It's
> just not something that needs to be supported at first cut.
>
> brk() if you wanted to back hugepages with it conceivably needs a resizing
> VMA but in that case it's growing up in which case just extend the end of
> the VMA and increase the size of the file.
I'm more worried about a small huge page size (say 64k) and not being
able to merge the VMAs. I guess it could start in the *middle* of a
file and map both directions.
I guess you could always just have a single (very sparse) hugetlb file
per mm to do all of this 'anonymous' hugetlb memory memory stuff, and
just map its offsets 1:1 on to the process's virtual address space.
That would make sure you could always merge VMAs, no matter how they
grew together.
-- Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox