Re: [PATCH 2/3] gianfar: Magic Packet and suspend/resume support.
Scott Wood wrote: Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: suppress I2C device probing
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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> Acked-by: Grant Likely <[EMAIL PROTECTED]>
>
> > ---
> > 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.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
Hi Anton,
On Wed, 2008-08-06 at 16:07 +0400, Anton Vorontsov wrote:
> Hello Li,
>
> On Wed, Aug 06, 2008 at 03:04:44PM +0800, Li Yang wrote:
> > Signed-off-by: Li Yang <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/mpc836x_mds.dts | 15 ++-
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 19 -
> > arch/powerpc/platforms/83xx/mpc83xx.h |1 +
> > arch/powerpc/platforms/83xx/usb.c | 67
> > +
> > 4 files changed, 100 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
> > b/arch/powerpc/boot/dts/mpc836x_mds.dts
> > index a3b76a7..596377b 100644
> > --- a/arch/powerpc/boot/dts/mpc836x_mds.dts
> > +++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
> > @@ -235,6 +235,17 @@
> > 0 2 1 0 1 0>; /* MDC */
> > };
> >
> > + pio_usb: [EMAIL PROTECTED] {
> > + pio-map = <
> > + /* port pin dir open_drain assignment has_irq */
> > + 1 2 1 0 3 0/* USBOE */
> > + 1 3 1 0 3 0/* USBTP */
> > + 1 8 1 0 1 0/* USBTN */
> > + 1 10 2 0 3 0/* USBRXD */
> > + 1 9 2 1 3 0/* USBRP */
> > + 1 11 2 1 3 0>; /* USBRN */
> > + };
> > +
> > };
> > };
> >
> > @@ -280,11 +291,13 @@
> > };
> >
> > [EMAIL PROTECTED] {
> > - compatible = "qe_udc";
> > + compatible = "fsl,qe_udc";
>
> You might want to reuse existing bindings as described in
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt.
Ok. I didn't notice your addition to the binding. I will try to update
it for device mode.
>
> > 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.
>
> > + 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.
>
> [...]
> > +#ifdef CONFIG_QUICC_ENGINE
> > +/* QE USB_CLOCK configure functions */
> > +int qe_usb_clock_set(struct device_node *np)
>
> We already have this function, in arch/powerpc/sysdev/qe_lib/usb.c
I just saw this. Will try to reuse it.
>
> It does not parse any of properties though, driver should do this.
>
> > +{
> > + u32 tmpreg = 0;
> > + struct qe_mux *qemux = NULL;
> > + const int *clock;
> > +
> > + qemux = &qe_immr->qmx;
> > +
> > + clock = of_get_property(np, "usb-clock", NULL);
> > + if (!clock)
> > + return -EINVAL;
> > +
> > + /* CLK21 -> USBCLK on MPC8360-PB*/
> > + tmpreg = in_be32(&qemux->cmxgcr) & ~QE_CMXGCR_USBCS;
> > + switch (*clock) {
> > + case 21:
> > + tmpreg |= 0x8;
> > + out_be32(&qemux->cmxgcr, tmpreg);
> > + par_io_config_pin(2, 20, 2, 0, 1, 0); /* PC20 for CLK21 */
>
> No, pio config is very board-specific. This should be done by the
> firmware (ideally) or by the board file.
Pio config is board and board configuration specific. It's better to
make it configurable by device tree.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Powerpc and ioremap
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);
But when he exectuted ioremap, he looped in the __delay function.
Can you help me to solve this probleme ?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
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 <[EMAIL PROTECTED]> > > --- > > 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. 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? - Leo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: suppress I2C device probing
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
---
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/8] powerpc: implement crash_setup_regs for ppc32
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <[EMAIL PROTECTED]>
>
> Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> @@ -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__ (
> "std0,0(%2)\n"
> "std1,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__ (
> + "stw0,0(%2)\n"
> + "stw1,4(%2)\n"
> + "stw2,8(%2)\n"
> + "stw3,12(%2)\n"
> + "stw4,16(%2)\n"
> + "stw5,20(%2)\n"
> + "stw6,24(%2)\n"
> + "stw7,28(%2)\n"
> + "stw8,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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc: set up OF properties for ppc32 kexec
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <[EMAIL PROTECTED]>
>
> 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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
On Fri, 2008-08-01 at 18:14 +0400, Anton Vorontsov wrote:
> From: Dale Farnsworth <[EMAIL PROTECTED]>
>
> 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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: suppress I2C device probing
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: suppress I2C device probing
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] powerpc: set up OF properties for ppc32 kdump
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 <[EMAIL PROTECTED]>
> >
> > 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: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6] powerpc: export cpm2_immr symbol for CPM2 drivers to compile as module
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 <[EMAIL PROTECTED]> > > > --- > > > 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: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerpc and ioremap
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerpc and ioremap
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 <[EMAIL PROTECTED]>:
>
> 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
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix Book-E watchdog timer interval setting
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 <[EMAIL PROTECTED]> --- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Powerpc and ioremap
Can we call ioremap() during udbg_early_init ?
2008/8/7, Sébastien Chrétien <[EMAIL PROTECTED]>:
>
> 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 <[EMAIL PROTECTED]>:
>>
>> 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
>>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] gianfar: Magic Packet and suspend/resume support.
On Aug 7, 2008, at 2:58 AM, Jeff Garzik wrote: Scott Wood wrote: Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
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 <[EMAIL PROTECTED]> --- drivers/watchdog/booke_wdt.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) can you be more explicit about what the bug was. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
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:
[EMAIL PROTECTED] {
/*
* gpio/pinmuxpin
* controller
*/
pio-map = <&pinmuxA 1 /* bindings says first pin is clk */
&pinmuxB14 /* bindings says second pin is usboe */
...>;
};
[EMAIL PROTECTED] {
pio-map = <&pinmuxA 2 /* bindings says first pin is clk */
&pinmuxB24 /* bindings says second pin is rxd0 */
&pinmuxB21 /* 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: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting
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 0x. 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 <[EMAIL PROTECTED]> > > --- > > drivers/watchdog/booke_wdt.c |6 +- > > 1 files changed, 5 insertions(+), 1 deletions(-) > > can you be more explicit about what the bug was. > > - k > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: suppress I2C device probing
On Thu, Aug 7, 2008 at 5:07 AM, Jean Delvare <[EMAIL PROTECTED]> 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. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] Driver helper functions.....
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of David Gibson > Sent: Thursday, August 07, 2008 1:13 AM > To: Tabi Timur > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() > utility function > > On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote: > > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely > <[EMAIL PROTECTED]> wrote: > > > From: Grant Likely <[EMAIL PROTECTED]> > > > > > > of_lookup_stdout() is useful for figuring out what device > to use as output > > > for early boot progress messages. It returns the node > pointed to by the > > > linux,stdout-path property in the chosen node. > > > > I thought linux,stdout-path is deprecated are we're supposed to be > > using the aliases node instead? > > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5121 pci 1/3] powerpc: 83xx: pci: Remove need for get_immrbase from mpc83xx_add_bridge.
Modify mpc83xx_add_bridge to get config space register base address from the
device
tree instead of immr + hardcoded offset.
83xx pci nodes have these changes:
register properties now contain two address length tuples:
First is the pci bridge register base, this has always been there.
Second is the config base, this is new.
The primary pci bus should have the "primary" property.
These are documented in Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
The changes accomplish these things:
mpc83xx_add_bridge no longer needs to call get_immrbase
it uses hard coded addresses if the second register value is missing
it no longer needs to devine primary property from register base
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
.../powerpc/dts-bindings/fsl/83xx-512x-pci.txt | 43
arch/powerpc/boot/dts/mpc8313erdb.dts |4 +-
arch/powerpc/boot/dts/mpc8315erdb.dts |4 +-
arch/powerpc/boot/dts/mpc832x_mds.dts |4 +-
arch/powerpc/boot/dts/mpc832x_rdb.dts |4 +-
arch/powerpc/boot/dts/mpc8349emitx.dts |7 ++-
arch/powerpc/boot/dts/mpc8349emitxgp.dts |4 +-
arch/powerpc/boot/dts/mpc834x_mds.dts |7 ++-
arch/powerpc/boot/dts/mpc836x_mds.dts |4 +-
arch/powerpc/boot/dts/mpc836x_rdk.dts |4 +-
arch/powerpc/boot/dts/mpc8377_mds.dts |4 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts |4 +-
arch/powerpc/boot/dts/mpc8378_mds.dts |4 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts |4 +-
arch/powerpc/boot/dts/mpc8379_mds.dts |4 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts |4 +-
arch/powerpc/boot/dts/sbc8349.dts |4 +-
arch/powerpc/sysdev/fsl_pci.c | 53 +--
18 files changed, 131 insertions(+), 35 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
b/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
new file mode 100644
index 000..51214a0
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt
@@ -0,0 +1,43 @@
+* Freescale 83xx and 512x PCI bridges
+
+Freescale 83xx and 512x SOCs include the same pci bridge core.
+
+83xx/512x specific notes:
+- reg: should contain two address length tuples
+The first is for the internal pci bridge registers
+The second is for the pci config space access registers
+- primary:
+This property should be present for the primary pci bridge
+
+Example (MPC8313ERDB)
+ pci0: [EMAIL PROTECTED] {
+ cell-index = <1>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0E -mini PCI */
+0x7000 0x0 0x0 0x1 &ipic 18 0x8
+0x7000 0x0 0x0 0x2 &ipic 18 0x8
+0x7000 0x0 0x0 0x3 &ipic 18 0x8
+0x7000 0x0 0x0 0x4 &ipic 18 0x8
+
+ /* IDSEL 0x0F - PCI slot */
+0x7800 0x0 0x0 0x1 &ipic 17 0x8
+0x7800 0x0 0x0 0x2 &ipic 18 0x8
+0x7800 0x0 0x0 0x3 &ipic 17 0x8
+0x7800 0x0 0x0 0x4 &ipic 18 0x8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <66 0x8>;
+ bus-range = <0x0 0x0>;
+ ranges = <0x0200 0x0 0x9000 0x9000 0x0 0x1000
+ 0x4200 0x0 0x8000 0x8000 0x0 0x1000
+ 0x0100 0x0 0x 0xe200 0x0 0x0010>;
+ clock-frequency = <>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access
registers */
+ compatible = "fsl,mpc8349-pci";
+ device_type = "pci";
+ primary;
+ };
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 2a94ae0..f4d84bb 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -359,9 +359,11 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0xe0008500 0x100>;
+ reg = <0xe0008500 0x100 /* internal registers */
+ 0xe0008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc8349-pci";
[PATCH 5121 pci 2/3] powerpc: 5121: Add PCI support.
Uses mpc83xx_add_bridge in fsl_pci.c
Adds second register tuple to pci node register property
as previously done for 83xx device trees in a previous patch.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc5121ads.dts |4 +++-
arch/powerpc/platforms/512x/Kconfig |2 ++
arch/powerpc/platforms/512x/mpc5121_ads.c | 10 ++
arch/powerpc/sysdev/fsl_pci.c |4 ++--
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index 1f9036c..b5444f7 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -403,8 +403,10 @@
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
- reg = <0x80008500 0x100>;
+ reg = <0x80008500 0x100 /* internal registers */
+ 0x80008300 0x8>; /* config space access
registers */
compatible = "fsl,mpc5121-pci";
device_type = "pci";
+ primary;
};
};
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index c62f893..326852c 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -3,6 +3,8 @@ config PPC_MPC512x
select FSL_SOC
select IPIC
select PPC_CLOCK
+ select PPC_PCI_CHOICE
+ select FSL_PCI if PCI
config PPC_MPC5121
bool
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index 5ebf693..441abc4 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -22,16 +22,26 @@
#include
#include
+#include
+
#include "mpc512x.h"
#include "mpc5121_ads.h"
static void __init mpc5121_ads_setup_arch(void)
{
+#ifdef CONFIG_PCI
+ struct device_node *np;
+#endif
printk(KERN_INFO "MPC5121 ADS board from Freescale Semiconductor\n");
/*
* cpld regs are needed early
*/
mpc5121_ads_cpld_map();
+
+#ifdef CONFIG_PCI
+ for_each_compatible_node(np, "pci", "fsl,mpc5121-pci")
+ mpc83xx_add_bridge(np);
+#endif
}
static void __init mpc5121_ads_init_IRQ(void)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index c4bdfc2..0acdd1e 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -251,7 +251,7 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8641D,
quirk_fsl_pcie_header);
DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8610, quirk_fsl_pcie_header);
#endif /* CONFIG_PPC_85xx || CONFIG_PPC_86xx */
-#if defined(CONFIG_PPC_83xx)
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
int __init mpc83xx_add_bridge(struct device_node *dev)
{
int len;
@@ -313,7 +313,7 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 4, 0);
- printk(KERN_INFO "Found MPC83xx PCI host bridge at 0x%016llx. "
+ printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
"Firmware bus number: %d->%d\n",
(unsigned long long)rsrc_reg.start, hose->first_busno,
hose->last_busno);
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5121 pci 3/3] powerpc: pci: 5121: Hide pci bridge.
The class of the MPC5121 pci host bridge is PCI_CLASS_BRIDGE_OTHER
while other freescale host bridges have class set to
PCI_CLASS_PROCESSOR_POWERPC.
This patch makes fixup_hide_host_resource_fsl match
PCI_CLASS_BRIDGE_OTHER in addition to PCI_CLASS_PROCESSOR_POWERPC.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 88db4ff..162c3a8 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -54,11 +54,12 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
-fixup_hide_host_resource_fsl(struct pci_dev* dev)
+fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
- if ((class == PCI_CLASS_PROCESSOR_POWERPC) &&
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC ||
+class == PCI_CLASS_BRIDGE_OTHER) &&
(dev->hdr_type == PCI_HEADER_TYPE_NORMAL) &&
(dev->bus->parent == NULL)) {
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Yoder Stuart wrote: > 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. I don't think the hypervisor console subsystem supports this. I don't see any way of registering separate clients for input vs. output. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 7, 2008, at 11:45 AM, Scott Wood wrote: 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). Which is how ioremap works today. We ask for a size of 3 bytes and it rounds up to a 4k page. The same should be true of the new interface (and round up to whatever the smallest size the HW we are using can handle). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
TimurTabi wrote: > Yoder Stuart wrote: > > > 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. > > I don't think the hypervisor console subsystem supports > this. I don't see any way of registering separate clients > for input vs. output. Why should what the hvc driver support have any effect on what the binding should be? And anyways, both the boot wrapper and udbg (and hence early debug console) have totally indepenedent functions for reading and writing. And for that matter, we also support output on monitor and input on keyboard for linear frame buffer on 6xx via the btext output (but only adb input). milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Milton Miller wrote: > Why should what the hvc driver support have any effect on > what the binding should be? Because my hypervisor console driver uses the hypervisor console/tty subsystem. If the subsystem assumes one stdout/stdin device, then I must abide by that. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
Timur Tabi wrote: Milton Miller wrote: Why should what the hvc driver support have any effect on what the binding should be? Because my hypervisor console driver uses the hypervisor console/tty subsystem. If the subsystem assumes one stdout/stdin device, then I must abide by that. So fix the subsystem, don't use the subsystem, or live with the fact that you support a subset of what the device tree can express. Don't cripple the device tree because of that. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device tree question
I have added a compact flash to the external bus of a Sequoia
(PPC440EPx) evaluation board. It is wired to CS1, and U-boot is set to
configure CS1 to be at address 0xc100. U-boot can access the
device, and reports the correct partition table, etc. so I believe the
hardware is ok.
I've created a device-tree entry under the EBC0 section of the
sequoia.dts file:
[EMAIL PROTECTED],0 {
compatible = "harris,hydra_temp-pata", "ata-generic";
bank-width = <2>;
reg = <1 0 20 1 80 20>;
reg-shift = <4>;
pio-mode = <4>;
interrupts = <27 4>;
interrupt-parent = <&UIC0>;
};
};
This seems to be correct, because if I turn on debug in prom_parse, I
see a translation that looks reasonable:
OF: translating address: 0001
OF: parent bus is default (na=1, ns=1) on /plb/opb
OF: walking ranges...
OF: default map, cp=0, s=400, da=1
OF: default map, cp=1, s=10, da=1
OF: parent translation for: c100
OF: with offset: 0
OF: one level translation: c100
OF: parent bus is default (na=2, ns=1) on /plb
OF: walking ranges...
OF: default map, cp=0, s=8000, da=c100
OF: default map, cp=8000, s=8000, da=c100
OF: parent translation for: 0001 8000
OF: with offset: 4100
OF: one level translation: 0001 c100
OF: parent bus is default (na=2, ns=1) on /
OF: no ranges, 1:1 translation
OF: parent translation for:
OF: with offset: 1c100
OF: one level translation: 0001 c100
OF: reached root node
OF: ** translation for device /plb/opb/ebc/[EMAIL PROTECTED],0 **
OF: bus is default (na=2, ns=1) on /plb/opb/ebc
(There is another translation for the alternate registers but I'll omit
it for brevity.)
However, there is something wrong, because I get an oops:
Machine check in kernel mode.
Data Write PLB Error
Oops: Machine check, sig: 7 [#1]
LTT NESTING LEVEL : 0
Hydra_temp
Modules linked in:
NIP: c01e4618 LR: c01e4608 CTR: c01e4078
REGS: c0398f50 TRAP: 0214 Not tainted (2.6.25.4-00021-g4b3b5ea-dirty)
MSR: 00029000 CR: 24044028 XER: 2007
TASK = cf808400[1] 'swapper' THREAD: cf826000
GPR00: 0008 cf827ce0 cf808400 cf3ac000 d1078080 0001
c03869c0
GPR08: c01e4078 cf3ac000 0001 24044022 c02e977c
c02e97e0
GPR16: c02e97c8 c036a8bc c02e97f4 c02e9808 c037c0a8 c0386978
cf360190
GPR24: 0027 c0386a64 cf360190 cf360194
cf3ac000
NIP [c01e4618] ata_bmdma_freeze+0x44/0x70
LR [c01e4608] ata_bmdma_freeze+0x34/0x70
Call Trace:
[cf827ce0] [001f] 0x1f (unreliable)
[cf827cf0] [c01e4c14] __ata_port_freeze+0x3c/0x5c
[cf827d00] [c01e4fa4] ata_eh_freeze_port+0x40/0x5c
[cf827d20] [c01d6868] ata_host_start+0xd8/0x208
[cf827d40] [c01dd2f4] ata_host_activate+0x28/0x124
[cf827d70] [c02a60c4] 0xc02a60c4
[cf827db0] [c02a642c] 0xc02a642c
[cf827e50] [c0222a7c] of_platform_device_probe+0x5c/0x560
[cf827e70] [c01b3148] driver_probe_device+0xb8/0x1e8
[cf827e90] [c01b3470] __driver_attach+0xcc/0xf8
[cf827eb0] [c01b21c4] bus_for_each_dev+0x5c/0x98
[cf827ee0] [c01b2f50] driver_attach+0x24/0x34
[cf827ef0] [c01b2da8] bus_add_driver+0x1d8/0x258
[cf827f20] [c01b371c] driver_register+0x48/0x114
[cf827f40] [c0222950] of_register_driver+0x54/0x70
[cf827f50] [c035ed08] pata_of_platform_init+0x20/0x30
[cf827f60] [c03471cc] kernel_init+0xc8/0x2ac
[cf827ff0] [c000e44c] original_kernel_thread+0x44/0x60
My question is: Did I do the device-tree entry incorrectly or is
something else wrong? I'll keep trying to figure it out on my own, but
if anyone has any tips on debugging this, I'd love to hear them.
Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, 2008-08-06 at 20:49 -0500, Kumar Gala wrote: > On Aug 6, 2008, at 5:28 PM, Benjamin Herrenschmidt wrote: > > > > >> there is a bunch of error checking and difference in semantics that > >> you need to fix. I think introduce a new API for this is silly, > >> especially since we expect there to only be one actual invocation of > >> the API for serial console access. > > > > Not necessarily > > > > There's another aspect to BAT mappings here. First, they should be > > permanent (ie, not unmappable). That way, we have ioremap just use > > an existing BAT mapping when asked for a device that is covered > > by a BAT. This allows to have platform code do something like setup > > a BAT over a bunch of SOC registers or over a device, to automagically > > get drivers doing ioremap to that area benefit from it. > > why should they be permanent.. We could implement reference counting > around the regions and free BATs if the count = 0. Do we care ? > I'm more concerned about this being implemented around the existing > ioremap core in __ioremap(). We can easily use a flag bit to say use > "large mappings" or the fact that mem_init_done == 0. mem_init_done isn't a good indication. We can do page tables when it's 0, we would have to use a separate mem_preinit_done or something :-) I initially also though about a flag to ioremap_prot to be honest. But it does obfuscate the normal ioremap code path and if there's a flag, that means that callers know the difference and thus may as well call a separate function, don't you think ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, 2008-08-06 at 17:11 -0600, Grant Likely wrote: > I'm not sure what you're asking. Are you asking about this particular > test, or are you asking why I don't also test the size? Badly worded. I meant BAT sizes are masks of bits. IE, they are power of 2 and the BAT address must be aligned to that power of 2 (ie, the BAT matching uses the size as a bit mask of relevant bits to compare). Unless I misread, your code doesn't provide the necessary tests/rounding of size and alignment of the virtual address.. does it ? > 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? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, 2008-08-06 at 00:35 -0600, Grant Likely wrote: > On Wed, Aug 6, 2008 at 12:32 AM, David Miller <[EMAIL PROTECTED]> wrote: > > From: Grant Likely <[EMAIL PROTECTED]> > > Date: Wed, 06 Aug 2008 00:02:44 -0600 > > > >> of_lookup_stdout() is useful for figuring out what device to use as output > >> for early boot progress messages. It returns the node pointed to by the > >> linux,stdout-path property in the chosen node. > >> > >> Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > > > On sparc platforms this is obtained differently. We obtain the 32-bit > > instance value of "/chosen/stdout" and convert that into a prom device > > node path using "instance-to-path". > > How about if I modify it to try both methods? The sparc method however cannot be used on powerpc because it requires a call to OF to do the "live" conversion (ie, instance-to-path). In fact, our /chosen/linux,stdout-path is just a cached result of that conversion done during boot. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
> It's not what we do with flattened device trees blobs though. In the > flattened tree we're not using a /chosen/stdout property, just the > linux,stdout-path one. > > The question that remains is; should there be? Should the dt blobs > use /chosen/stdout also? (I'm not familiar enough with real OF to > know the answer. I'm assuming that an instance value is not the same > as a phandle). Yup, there are two issues there: - The instance value would have to be converted to a phandle while OF is still alive. I initially did that and added a stdout-node or so property, but that still hit the next issue. - IBM machines has this weird distinction between the real phandle and the ibm,phandle, the later being the same except for things that get hotplugged ... and some of the vdevices. We got really confused trying to sort that out with the output device. So in the end, I decided to just convert the ihandle to a path and stick that path in the device-tree. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
On Wed, 2008-08-06 at 11:46 -0500, Timur Tabi wrote: > On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely <[EMAIL PROTECTED]> wrote: > > From: Grant Likely <[EMAIL PROTECTED]> > > > > of_lookup_stdout() is useful for figuring out what device to use as output > > for early boot progress messages. It returns the node pointed to by the > > linux,stdout-path property in the chosen node. > > I thought linux,stdout-path is deprecated are we're supposed to be > using the aliases node instead? You are mixing two completely different things afaik. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 7, 2008, at 5:13 PM, Benjamin Herrenschmidt wrote: On Wed, 2008-08-06 at 20:49 -0500, Kumar Gala wrote: On Aug 6, 2008, at 5:28 PM, Benjamin Herrenschmidt wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. why should they be permanent.. We could implement reference counting around the regions and free BATs if the count = 0. Do we care ? probably not for BATs but for other things we might. I'm more concerned about this being implemented around the existing ioremap core in __ioremap(). We can easily use a flag bit to say use "large mappings" or the fact that mem_init_done == 0. mem_init_done isn't a good indication. We can do page tables when it's 0, we would have to use a separate mem_preinit_done or something :-) I initially also though about a flag to ioremap_prot to be honest. But it does obfuscate the normal ioremap code path and if there's a flag, that means that callers know the difference and thus may as well call a separate function, don't you think ? I'm ok with exposing a separate function as far as the API goes.. I'm not ok with duplicating the logic of __ioremap(). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: problem in booting kernel with mpc836x_mds.dtb
[EMAIL PROTECTED] wrote: Hi, I have the following problem, when i am trying to boot linux on MPC8360E MDS board with the mpc836x_mds.dtb created using dtc and mpc836x_mds.dts in from /arch/powerpc/boot/platforms/dts/ directory of linux-2.6.22 version. fdt_chosen: FDT_ERR_BADMAGIC after this it is trying to re boot. how to resolve this issue, so i need to apply any pathces to mpc836x_mds.dts file. NOTE: i am using dtc compiled from linux-2.6.26 version. Regards Surendra Hi Surendra, Is the error message coming from u-boot or linux? More lines from the boot sequence (like most or all of them) would be useful. The error message is saying that whatever you are passing to the kernel (or setting in u-boot with "fdt addr") for your dtb blob is not a valid dtb blob. Display memory where you think your blob resides: if it doesn't have 0xd00dfeed in that location, it isn't a valid binary blob. I suspect you will find either you didn't compile your .dts file correctly or your blob address is wrong. If you gave us your dtc command line, that might be helpful. HTH, gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
