LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Jon Smirl @ 2008-07-22 16:38 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie, timur, liam.girdwood
In-Reply-To: <20080722065352.7306.60679.stgit@trillian.secretlab.ca>

On 7/22/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
>  Simple utility layer for creating ASoC machine instances based on data
>  in the OpenFirmware device tree.  OF aware platform drivers and codec
>  drivers register themselves with this framework and the framework
>  automatically instantiates a machine driver.  At the moment, the driver
>  is not very capable and it is expected to be extended as more features
>  are needed for specifying the configuration in the device tree.
>
>  This is most likely temporary glue code to work around limitations in
>  the ASoC v1 framework.  When v2 is merged, most of this driver will
>  need to be reworked.
>
>  Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>  ---
>
>   include/sound/soc-of-simple.h |   21 +++++
>   sound/soc/fsl/Kconfig         |    3 +
>   sound/soc/fsl/Makefile        |    3 +
>   sound/soc/fsl/soc-of-simple.c |  171 +++++++++++++++++++++++++++++++++++++++++
>   4 files changed, 198 insertions(+), 0 deletions(-)
>
>  diff --git a/include/sound/soc-of-simple.h b/include/sound/soc-of-simple.h
>  new file mode 100644
>  index 0000000..696fc51
>  --- /dev/null
>  +++ b/include/sound/soc-of-simple.h
>  @@ -0,0 +1,21 @@
>  +/*
>  + * OF helpers for ALSA SoC
>  + *
>  + * Copyright (C) 2008, Secret Lab Technologies Ltd.
>  + */
>  +
>  +#ifndef _INCLUDE_SOC_OF_H_
>  +#define _INCLUDE_SOC_OF_H_
>  +
>  +#include <linux/of.h>
>  +#include <sound/soc.h>
>  +
>  +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
>  +                             void *codec_data, struct snd_soc_dai *dai,
>  +                             struct device_node *node);
>  +
>  +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
>  +                                struct device_node *node,
>  +                                struct snd_soc_dai *cpu_dai);
>  +

This doesn't compile for me.  Where is struct snd_soc_dai being defined?

It used to be....

+int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
+			      void *codec_data, struct snd_soc_codec_dai *dai,
+			      struct device_node *node);
+
+int of_snd_soc_register_platform(struct snd_soc_platform *platform,
+				 struct device_node *node,
+				 struct snd_soc_cpu_dai *cpu_dai);



>  +#endif /* _INCLUDE_SOC_OF_H_ */
>  diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
>  index 3368ace..398f002 100644
>  --- a/sound/soc/fsl/Kconfig
>  +++ b/sound/soc/fsl/Kconfig
>  @@ -1,3 +1,6 @@
>  +config SND_SOC_OF_SIMPLE
>  +       tristate
>  +
>   config SND_SOC_MPC8610
>         bool "ALSA SoC support for the MPC8610 SOC"
>         depends on MPC8610_HPCD
>  diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
>  index 62f680a..aa2100b 100644
>  --- a/sound/soc/fsl/Makefile
>  +++ b/sound/soc/fsl/Makefile
>  @@ -1,3 +1,6 @@
>  +# Simple machine driver that extracts configuration from the OF device tree
>  +obj-$(CONFIG_SND_SOC_OF_SIMPLE) += soc-of-simple.o
>  +
>   # MPC8610 HPCD Machine Support
>   obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
>
>  diff --git a/sound/soc/fsl/soc-of-simple.c b/sound/soc/fsl/soc-of-simple.c
>  new file mode 100644
>  index 0000000..0382fda
>  --- /dev/null
>  +++ b/sound/soc/fsl/soc-of-simple.c
>  @@ -0,0 +1,171 @@
>  +/*
>  + * OF helpers for ALSA SoC Layer
>  + *
>  + * Copyright (C) 2008, Secret Lab Technologies Ltd.
>  + */
>  +
>  +#include <linux/module.h>
>  +#include <linux/moduleparam.h>
>  +#include <linux/init.h>
>  +#include <linux/delay.h>
>  +#include <linux/pm.h>
>  +#include <linux/bitops.h>
>  +#include <linux/platform_device.h>
>  +#include <linux/of.h>
>  +#include <sound/core.h>
>  +#include <sound/pcm.h>
>  +#include <sound/pcm_params.h>
>  +#include <sound/soc.h>
>  +#include <sound/soc-of-simple.h>
>  +#include <sound/initval.h>
>  +
>  +MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
>  +MODULE_LICENSE("GPL");
>  +MODULE_DESCRIPTION("ALSA SoC OpenFirmware bindings");
>  +
>  +static DEFINE_MUTEX(of_snd_soc_mutex);
>  +static LIST_HEAD(of_snd_soc_device_list);
>  +static int of_snd_soc_next_index;
>  +
>  +struct of_snd_soc_device {
>  +       int id;
>  +       struct list_head list;
>  +       struct snd_soc_device device;
>  +       struct snd_soc_machine machine;
>  +       struct snd_soc_dai_link dai_link;
>  +       struct platform_device *pdev;
>  +       struct device_node *platform_node;
>  +       struct device_node *codec_node;
>  +};
>  +
>  +static struct snd_soc_ops of_snd_soc_ops = {
>  +};
>  +
>  +static struct of_snd_soc_device *
>  +of_snd_soc_get_device(struct device_node *codec_node)
>  +{
>  +       struct of_snd_soc_device *of_soc;
>  +
>  +       list_for_each_entry(of_soc, &of_snd_soc_device_list, list) {
>  +               if (of_soc->codec_node == codec_node)
>  +                       return of_soc;
>  +       }
>  +
>  +       of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
>  +       if (!of_soc)
>  +               return NULL;
>  +
>  +       /* Initialize the structure and add it to the global list */
>  +       of_soc->codec_node = codec_node;
>  +       of_soc->id = of_snd_soc_next_index++;
>  +       of_soc->machine.dai_link = &of_soc->dai_link;
>  +       of_soc->machine.num_links = 1;
>  +       of_soc->device.machine = &of_soc->machine;
>  +       of_soc->dai_link.ops = &of_snd_soc_ops;
>  +       list_add(&of_soc->list, &of_snd_soc_device_list);
>  +
>  +       return of_soc;
>  +}
>  +
>  +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
>  +{
>  +       struct platform_device *pdev;
>  +       int rc;
>  +
>  +       /* Only register the device if both the codec and platform have
>  +        * been registered */
>  +       if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
>  +               return;
>  +
>  +       pr_info("platform<-->codec match achieved; registering machine\n");
>  +
>  +       pdev = platform_device_alloc("soc-audio", of_soc->id);
>  +       if (!pdev) {
>  +               pr_err("of_soc: platform_device_alloc() failed\n");
>  +               return;
>  +       }
>  +
>  +       pdev->dev.platform_data = of_soc;
>  +       platform_set_drvdata(pdev, &of_soc->device);
>  +       of_soc->device.dev = &pdev->dev;
>  +
>  +       /* The ASoC device is complete; register it */
>  +       rc = platform_device_add(pdev);
>  +       if (rc) {
>  +               pr_err("of_soc: platform_device_add() failed\n");
>  +               return;
>  +       }
>  +
>  +}
>  +
>  +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
>  +                             void *codec_data, struct snd_soc_dai *dai,
>  +                             struct device_node *node)
>  +{
>  +       struct of_snd_soc_device *of_soc;
>  +       int rc = 0;
>  +
>  +       pr_info("registering ASoC codec driver: %s\n", node->full_name);
>  +
>  +       mutex_lock(&of_snd_soc_mutex);
>  +       of_soc = of_snd_soc_get_device(node);
>  +       if (!of_soc) {
>  +               rc = -ENOMEM;
>  +               goto out;
>  +       }
>  +
>  +       /* Store the codec data */
>  +       of_soc->device.codec_data = codec_data;
>  +       of_soc->device.codec_dev = codec_dev;
>  +       of_soc->dai_link.name = (char *)node->name;
>  +       of_soc->dai_link.stream_name = (char *)node->name;
>  +       of_soc->dai_link.codec_dai = dai;
>  +
>  +       /* Now try to register the SoC device */
>  +       of_snd_soc_register_device(of_soc);
>  +
>  + out:
>  +       mutex_unlock(&of_snd_soc_mutex);
>  +       return rc;
>  +}
>  +EXPORT_SYMBOL_GPL(of_snd_soc_register_codec);
>  +
>  +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
>  +                                struct device_node *node,
>  +                                struct snd_soc_dai *cpu_dai)
>  +{
>  +       struct of_snd_soc_device *of_soc;
>  +       struct device_node *codec_node;
>  +       const phandle *handle;
>  +       int len, rc = 0;
>  +
>  +       pr_info("registering ASoC platform driver: %s\n", node->full_name);
>  +
>  +       handle = of_get_property(node, "codec-handle", &len);
>  +       if (!handle || len < sizeof(handle))
>  +               return -ENODEV;
>  +       codec_node = of_find_node_by_phandle(*handle);
>  +       if (!codec_node)
>  +               return -ENODEV;
>  +       pr_info("looking for codec: %s\n", codec_node->full_name);
>  +
>  +       mutex_lock(&of_snd_soc_mutex);
>  +       of_soc = of_snd_soc_get_device(codec_node);
>  +       if (!of_soc) {
>  +               rc = -ENOMEM;
>  +               goto out;
>  +       }
>  +
>  +       of_soc->platform_node = node;
>  +       of_soc->dai_link.cpu_dai = cpu_dai;
>  +       of_soc->device.platform = platform;
>  +       of_soc->machine.name = of_soc->dai_link.cpu_dai->name;
>  +
>  +       /* Now try to register the SoC device */
>  +       of_snd_soc_register_device(of_soc);
>  +
>  + out:
>  +       mutex_unlock(&of_snd_soc_mutex);
>  +       return rc;
>  +}
>  +EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Help: Kernel BUG with U-boot 1.1.4 and kernel 2.6.23 scanning PCIe on a MPC8641D board
From: Jon Loeliger @ 2008-07-22 16:57 UTC (permalink / raw)
  To: joachim.bader; +Cc: linuxppc-embedded
In-Reply-To: <OFB15FD6AA.EA941C67-ONC125748E.00488CEE-C125748E.004A8A08@diehl-gruppe.de>

joachim.bader@diehl-aerospace.de wrote:
> 
> Hello folks,
> 
> we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4 
> and Linux kernel 2.6.23
> 

> I read in the logs some messages that 2.6.23 does contain some bugs 
> related to PCIe

Correct.

> and it would be a good choice to upgrade to 2.6.25. Is 
> this one of that cases?

Almost certainly.  You should pick up top of tree if you can.

> Currently we would like to prevent switching the kernel version.

You could back-port the PCIe bug fixes and rewrite if you wanted.
My guess is that a _trial_ run of the current top of tree,
or at least 2.6.26 might Just Work and fix your issues.

It would be less work to try it than do discover-n-back-port...

jdl

^ permalink raw reply

* Re: [RFC v3 PATCH 6/4] Use LOAD_REG_IMMEDIATE macros
From: Segher Boessenkool @ 2008-07-22 17:13 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: ppcdev, naren, Milton Miller
In-Reply-To: <18565.32839.382335.638503@cargo.ozlabs.ibm.com>

>> All of the variables references through @got translated into 
>> relocation
>> type R_PPC64_GOT16_DS entries. All these entries correspond to one of
>> the above entries in the .got section. But none of the entries in .got
>> section are relocated.
>
> If that last statement is really true, then that would be an absolute
> show-stopper, since you're not going to stop the compiler generating
> loads from the TOC to get addresses of things.
>
> However, I don't think it's true.  I compiled up a kernel using
> --emit-relocs on the final link, and with readelf -e I can see a
> .rela.got section containing a bunch of R_PPC64_ADDR64 relocs for
> entries in the .got section.
>
> So the problem appears to be either just that you are ignoring
> R_PPC64_ADDR64 relocs, or else that your relocs.c program has a bug
> and isn't seeing the .rela.got section.

I analysed this further.

.rela.got does have lots of relocs in it, but _not_ for relocations
create with @got in the assembler code.  GCC never does this AFAICS,
it explicitly creates a TOC entry and uses that.

So, the workaround would be to manually create TOC entries in the
LOAD_REG_ADDR code as well.  I'll work on that, feel free to beat me
to it of course.

>> Now I have two options left:
>> 1. Check for R_PPC64_GOT16_DS entries and check whether the contents
>> addressed by r2+offset is relocated or not and apply relocation if 
>> its not.
>> 2. Change all LOAD_REG_ADDR macros to LOAD_REG_IMMEDIATE. This I have
>> already done.
>
> I was trying to point out that this can't possibly be a viable
> solution to the problem, because most of the TOC loads in the binary
> are generated by the C compiler, and only a few of them come from use
> of the LOAD_REG_ADDR macro in assembly code.

binutils has a problem only with the @gotXXX relocations, where the
_linker_ creates the GOT entry (it doesn't emit a reloc for -emit-relocs
in that case).


Segher

^ permalink raw reply

* Re: [alsa-devel] [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-22 17:51 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur, liam.girdwood
In-Reply-To: <9e4733910807220938k7452f40co8d51e4b03e79ee8b@mail.gmail.com>

On Tue, Jul 22, 2008 at 12:38:30PM -0400, Jon Smirl wrote:
> On 7/22/08, Grant Likely <grant.likely@secretlab.ca> wrote:

> >  +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> >  +                                struct device_node *node,
> >  +                                struct snd_soc_dai *cpu_dai);
> >  +

> This doesn't compile for me.  Where is struct snd_soc_dai being defined?

> It used to be....

In ALSA and ASoC git struct snd_soc_{cpu,codec}_dai have been replaced
by a shared snd_soc_dai defined in soc.h as the previous two were.

^ permalink raw reply

* Re: 2.6.26 does not boot on Pegasos
From: Segher Boessenkool @ 2008-07-22 17:54 UTC (permalink / raw)
  To: Matt Sealey; +Cc: linuxppc-dev list
In-Reply-To: <48808914.20702@genesi-usa.com>

>>> If you built this kernel yourself, you need to do it from a system 
>>> with
>>> an up-to-date binutils (2.18) otherwise, it does this.
>
> Note to the linux-ppc guys; is there any changelog entry which reports
> this requirement somewhere? I didn't find one...

That's because there is no such requirement.  2.18 is the latest
version, so it's always wise to test with that in case you have
some problems; but it wouldn't be nice if the kernel can be built
with only one binutils major version.

Please try my build patch for a similar problem, it went into
BenH's tree today.  Would be nice if it was the same problem;
if not, send a proper, _detailed_ bug report here and I'll look
into it.


Segher

^ permalink raw reply

* Re: Failure of request_irq()  for MPC8313 using arch=powerpc
From: Scott Wood @ 2008-07-22 17:55 UTC (permalink / raw)
  To: Duy-Ky Nguyen; +Cc: Liu Dave, linuxppc-embedded
In-Reply-To: <BLU119-DAV61F2F984D2E145D1E4AA1BB8F0@phx.gbl>

On Tue, Jul 15, 2008 at 08:43:59PM -0700, Duy-Ky Nguyen wrote:
> Hi Dave,
> 
> I've just tried it and it failed.

Could you elaborate on exactly what you tried?  Did you pass the GPIO device
tree node?

> Before I had tried using the function
> int virq = of_irq_to_resource(GPIO_IRQ, 0, NULL);
> and it failed the same way

The first argument of of_irq_to_resource is a device node pointer, not an
IRQ number.  Surely the compiler warned you about this.

-Scott

^ permalink raw reply

* Re: Problem with cuImage Linux entry from old U-boot
From: Scott Wood @ 2008-07-22 18:05 UTC (permalink / raw)
  To: Stephen Horton; +Cc: linuxppc-embedded
In-Reply-To: <295C5089A56CE143B316E5F67CA99CB001D0626A@cowboy.inovate.inovate.com>

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry point.
> I'm not sure if I'm trying to jump into the kernel at the wrong address,
> or if I have a serial console issue that prevents me from seeing anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=bootp root=/dev/nfs rw nfsroot=/opt/gentoo
> console=ttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
> 
>  
> 
> ------
> 
>  
> 
> If I run 'nm' on my elf image, I expect to find some entry point address
> that corresponds to 0x7423a0, but this is not the case. 

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an entry
point; the entry point to the kernel is zero.

-Scott

^ permalink raw reply

* RE: Problem with cuImage Linux entry from old U-boot
From: Mike Timmons @ 2008-07-22 18:13 UTC (permalink / raw)
  To: Scott Wood, Stephen Horton; +Cc: linuxppc-embedded
In-Reply-To: <20080722180506.GB13940@loki.buserror.net>

Related question: I'm using a newer U-boot and managing the load of the
kernel and the device tree from separate partitions of my boot media.

Having the two partitions and managing the kernel and the tree
separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
I just use that "static" file name option when I build the kernel, load
the cuImage, and just invoke=20

bootm <cuImageLoadAddress> ?

Will it work to just leave off the - <device tree Ram address>

I think I had it set-p right yesterday and I gave it a try, but no joy.

Can it be this simple to statically link the device tree with the kernel
build? For my application I don't see a benefit in keeping them separate
(the kernel and the tree).

Thanks,
Mike


-----Original Message-----
From: linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+mike_timmons=3Dtrimble.com@ozlabs.org]
On Behalf Of Scott Wood
Sent: Tuesday, July 22, 2008 1:05 PM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Problem with cuImage Linux entry from old U-boot

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
point.
> I'm not sure if I'm trying to jump into the kernel at the wrong
address,
> or if I have a serial console issue that prevents me from seeing
anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel
from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=3Dbootp root=3D/dev/nfs rw =
nfsroot=3D/opt/gentoo
> console=3DttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
>=20
> =20
>=20
> ------
>=20
> =20
>=20
> If I run 'nm' on my elf image, I expect to find some entry point
address
> that corresponds to 0x7423a0, but this is not the case.=20

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an
entry
point; the entry point to the kernel is zero.

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

^ permalink raw reply

* Re: Problem with cuImage Linux entry from old U-boot
From: Scott Wood @ 2008-07-22 18:20 UTC (permalink / raw)
  To: Mike Timmons; +Cc: Stephen Horton, linuxppc-embedded
In-Reply-To: <161B3BAD77161449A144FF054231C3D60249D825@uss-am-xch-01.am.trimblecorp.net>

Mike Timmons wrote:
> Related question: I'm using a newer U-boot and managing the load of the
> kernel and the device tree from separate partitions of my boot media.
> 
> Having the two partitions and managing the kernel and the tree
> separately is a bit cumbersome, or maybe I'm just lazy. Regardless, can
> I just use that "static" file name option when I build the kernel, load
> the cuImage, and just invoke 
> 
> bootm <cuImageLoadAddress> ?
> 
> Will it work to just leave off the - <device tree Ram address>
> 
> I think I had it set-p right yesterday and I gave it a try, but no joy.
> 
> Can it be this simple to statically link the device tree with the kernel
> build? For my application I don't see a benefit in keeping them separate
> (the kernel and the tree).

Yes, you can use cuImage to bundle the device tree with the kernel (note 
that the type of image you use *must* match the type of bootm command 
you use), though it's not recommended if you have a u-boot that can 
properly pass a device tree.  cuImage relies on the bd_t to get 
information from u-boot, and this is a very fragile structure, and 
contains less information than the device tree.

-Scott

^ permalink raw reply

* Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Jon Smirl @ 2008-07-22 18:28 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, broonie, timur, liam.girdwood
In-Reply-To: <20080722065358.7306.9412.stgit@trillian.secretlab.ca>

What about the mpc5200b?

+/* Match table for of_platform binding */
+static struct of_device_id psc_i2s_match[] __devinitdata = {
+       { .compatible = "fsl,mpc5200-psc-i2s", },
+       {}
+};
+MODULE_DEVICE_TABLE(of, psc_i2s_match);
+

I'm just being grumpy because updating to linus/master made me fix
over a hundred merge conflicts, now I have to test everything again.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver
From: Mark Brown @ 2008-07-22 18:39 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur, liam.girdwood
In-Reply-To: <9e4733910807220752o4d220f90o770d55e70f493642@mail.gmail.com>

On Tue, Jul 22, 2008 at 10:52:20AM -0400, Jon Smirl wrote:

> I'm just going to ignore 2.6.27 and wait for 2.6.28.  This driver only

If you want to get changes in for 2.6.28 it's probably best to be
working on them now - it's not clear if this driver will be merged for
2.6.27 at all and the sooner the stuff gets in the safer it is for
2.6.28 and the closer the code base will be to 2.6.26.  It's up to you
obviously but I think it may work best.

> partially implement i2s support and assumes external clocking. There's
> no way to add a ASOC machine driver. It's not a general purpose
> driver. Adding the rest of the features probably means device tree
> changes.

of-soc is a machine driver - other machine drivers should be able to
bind to the driver as normal (though I'd expect that users would want to
add more configurablilty to the driver prior to using it).  Or at least
that was the usage I was expecting, anyway.

Implementing only partial support for devices is pretty much normal when
the driver isn't contributed by the vendor - people tend to only work on
the features they're using.

^ permalink raw reply

* Re: [PATCH 04/16 v3] powerpc: Split retrieval of processor entitlement data into a helper routine
From: Nathan Fontenot @ 2008-07-22 18:49 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Brian King, linuxppc-dev, David Darrington
In-Reply-To: <18565.30231.361341.295825@cargo.ozlabs.ibm.com>

Paul Mackerras wrote:
> Robert Jennings writes:
> 
>> Split the retrieval of processor entitlement data returned in the H_GET_PPP
>> hcall into its own helper routine.
> 
> This seems to change the value reported for pool_capacity radically:
> 
>>  		/* report pool_capacity in percentage */
>> -		seq_printf(m, "pool_capacity=%ld\n",
>> -			   ((h_resource >> 2 * 8) & 0xffff) * 100);
>> +		seq_printf(m, "pool_capacity=%d\n", ppp_data.group_num * 100);
> 
> On a Power6 partition here with your patch series applied, I see
> 
> pool_capacity=3277200
> 
> in /proc/ppc64/lparcfg.  Without your patches, I get
> 
> pool_capacity=400
> pool_idle_time=0
> pool_num_procs=0
>
> This looks like an incompatible user-visible change to me, and we
> haven't even changed the lparcfg version number at the beginning of
> the /proc/ppc64/lparcfg output.  Why is the pool_capacity so
> different, and why do the pool_idle_time and pool_num_procs lines
> disappear?
>

ok, three problems, three new patches.

The reporting of pool_capacity was a bug in using the wrong information
reported by h_get_ppp in the patch.  This is in a new patch 4/16.

The failure to report the pool_idle_time and pool_num_procs was due to
an update to h_pic where we started checking the return code of the
h_call for H_PIC.  The values were not reported if the h_call fails,
which on my partition it fails with -10 (H_Authority).  I have reverted
this back to the previous behavior and report the values of pool_idle_time
and pool_num_procs regardless of the h_call return code.  This is
in a new patch 2/16.

Yes, the lparcfg version number should have been updated.  I missed that.
Fixed in a new patch 3/16.

-Nathan 
 
> Regards,
> Paul.

^ permalink raw reply

* Re: [PATCH 02/16 v3] powerpc: Split processor entitlement retrieval and gathering to helper routines
From: Nathan Fontenot @ 2008-07-22 18:53 UTC (permalink / raw)
  To: Robert Jennings; +Cc: Brian King, linuxppc-dev, paulus, David Darrington
In-Reply-To: <20080704125122.GC1310@linux.vnet.ibm.com>

Updated patch to remove checking the return code from the h_call for
H_PIC.  This reverts the reporting back to its original state.

Split the retrieval and setting of processor entitlement and weight into
helper routines.  This also removes the printing of the raw values
returned from h_get_ppp, the values are already parsed and printed.

Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>

---
 arch/powerpc/kernel/lparcfg.c |  168 ++++++++++++++++++++++-------------------
 1 file changed, 90 insertions(+), 78 deletions(-)

Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c	2008-07-22 10:35:13.000000000 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c	2008-07-22 12:50:47.000000000 -0500
@@ -167,7 +167,8 @@
 	return rc;
 }
 
-static void h_pic(unsigned long *pool_idle_time, unsigned long *num_procs)
+static unsigned h_pic(unsigned long *pool_idle_time,
+		      unsigned long *num_procs)
 {
 	unsigned long rc;
 	unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
@@ -176,6 +177,51 @@
 
 	*pool_idle_time = retbuf[0];
 	*num_procs = retbuf[1];
+
+	return rc;
+}
+
+/*
+ * parse_ppp_data
+ * Parse out the data returned from h_get_ppp and h_pic
+ */
+static void parse_ppp_data(struct seq_file *m)
+{
+	unsigned long h_entitled, h_unallocated;
+	unsigned long h_aggregation, h_resource;
+	int rc;
+
+	rc = h_get_ppp(&h_entitled, &h_unallocated, &h_aggregation,
+		       &h_resource);
+	if (rc)
+		return;
+
+	seq_printf(m, "partition_entitled_capacity=%ld\n", h_entitled);
+	seq_printf(m, "group=%ld\n", (h_aggregation >> 2 * 8) & 0xffff);
+	seq_printf(m, "system_active_processors=%ld\n",
+		   (h_resource >> 0 * 8) & 0xffff);
+
+	/* pool related entries are apropriate for shared configs */
+	if (lppaca[0].shared_proc) {
+		unsigned long pool_idle_time, pool_procs;
+
+		seq_printf(m, "pool=%ld\n", (h_aggregation >> 0 * 8) & 0xffff);
+
+		/* report pool_capacity in percentage */
+		seq_printf(m, "pool_capacity=%ld\n",
+			   ((h_resource >> 2 * 8) & 0xffff) * 100);
+
+		h_pic(&pool_idle_time, &pool_procs);
+		seq_printf(m, "pool_idle_time=%ld\n", pool_idle_time);
+		seq_printf(m, "pool_num_procs=%ld\n", pool_procs);
+	}
+
+	seq_printf(m, "unallocated_capacity_weight=%ld\n",
+		   (h_resource >> 4 * 8) & 0xFF);
+
+	seq_printf(m, "capacity_weight=%ld\n", (h_resource >> 5 * 8) & 0xFF);
+	seq_printf(m, "capped=%ld\n", (h_resource >> 6 * 8) & 0x01);
+	seq_printf(m, "unallocated_capacity=%ld\n", h_unallocated);
 }
 
 #define SPLPAR_CHARACTERISTICS_TOKEN 20
@@ -302,60 +348,11 @@
 	partition_active_processors = lparcfg_count_active_processors();
 
 	if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
-		unsigned long h_entitled, h_unallocated;
-		unsigned long h_aggregation, h_resource;
-		unsigned long pool_idle_time, pool_procs;
-		unsigned long purr;
-
-		h_get_ppp(&h_entitled, &h_unallocated, &h_aggregation,
-			  &h_resource);
-
-		seq_printf(m, "R4=0x%lx\n", h_entitled);
-		seq_printf(m, "R5=0x%lx\n", h_unallocated);
-		seq_printf(m, "R6=0x%lx\n", h_aggregation);
-		seq_printf(m, "R7=0x%lx\n", h_resource);
-
-		purr = get_purr();
-
 		/* this call handles the ibm,get-system-parameter contents */
 		parse_system_parameter_string(m);
+		parse_ppp_data(m);
 
-		seq_printf(m, "partition_entitled_capacity=%ld\n", h_entitled);
-
-		seq_printf(m, "group=%ld\n", (h_aggregation >> 2 * 8) & 0xffff);
-
-		seq_printf(m, "system_active_processors=%ld\n",
-			   (h_resource >> 0 * 8) & 0xffff);
-
-		/* pool related entries are apropriate for shared configs */
-		if (lppaca[0].shared_proc) {
-
-			h_pic(&pool_idle_time, &pool_procs);
-
-			seq_printf(m, "pool=%ld\n",
-				   (h_aggregation >> 0 * 8) & 0xffff);
-
-			/* report pool_capacity in percentage */
-			seq_printf(m, "pool_capacity=%ld\n",
-				   ((h_resource >> 2 * 8) & 0xffff) * 100);
-
-			seq_printf(m, "pool_idle_time=%ld\n", pool_idle_time);
-
-			seq_printf(m, "pool_num_procs=%ld\n", pool_procs);
-		}
-
-		seq_printf(m, "unallocated_capacity_weight=%ld\n",
-			   (h_resource >> 4 * 8) & 0xFF);
-
-		seq_printf(m, "capacity_weight=%ld\n",
-			   (h_resource >> 5 * 8) & 0xFF);
-
-		seq_printf(m, "capped=%ld\n", (h_resource >> 6 * 8) & 0x01);
-
-		seq_printf(m, "unallocated_capacity=%ld\n", h_unallocated);
-
-		seq_printf(m, "purr=%ld\n", purr);
-
+		seq_printf(m, "purr=%ld\n", get_purr());
 	} else {		/* non SPLPAR case */
 
 		seq_printf(m, "system_active_processors=%d\n",
@@ -382,6 +379,41 @@
 	return 0;
 }
 
+static ssize_t update_ppp(u64 *entitlement, u8 *weight)
+{
+	unsigned long current_entitled;
+	unsigned long dummy;
+	unsigned long resource;
+	u8 current_weight, new_weight;
+	u64 new_entitled;
+	ssize_t retval;
+
+	/* Get our current parameters */
+	retval = h_get_ppp(&current_entitled, &dummy, &dummy, &resource);
+	if (retval)
+		return retval;
+
+	current_weight = (resource >> 5 * 8) & 0xFF;
+
+	if (entitlement) {
+		new_weight = current_weight;
+		new_entitled = *entitlement;
+	} else if (weight) {
+		new_weight = *weight;
+		new_entitled = current_entitled;
+	} else
+		return -EINVAL;
+
+	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
+		 __FUNCTION__, current_entitled, current_weight);
+
+	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
+		 __FUNCTION__, new_entitled, new_weight);
+
+	retval = plpar_hcall_norets(H_SET_PPP, new_entitled, new_weight);
+	return retval;
+}
+
 /*
  * Interface for changing system parameters (variable capacity weight
  * and entitled capacity).  Format of input is "param_name=value";
@@ -399,12 +431,6 @@
 	char *tmp;
 	u64 new_entitled, *new_entitled_ptr = &new_entitled;
 	u8 new_weight, *new_weight_ptr = &new_weight;
-
-	unsigned long current_entitled;	/* parameters for h_get_ppp */
-	unsigned long dummy;
-	unsigned long resource;
-	u8 current_weight;
-
 	ssize_t retval = -ENOMEM;
 
 	if (!firmware_has_feature(FW_FEATURE_SPLPAR) ||
@@ -432,33 +458,17 @@
 		*new_entitled_ptr = (u64) simple_strtoul(tmp, &endp, 10);
 		if (endp == tmp)
 			goto out;
-		new_weight_ptr = &current_weight;
+
+		retval = update_ppp(new_entitled_ptr, NULL);
 	} else if (!strcmp(kbuf, "capacity_weight")) {
 		char *endp;
 		*new_weight_ptr = (u8) simple_strtoul(tmp, &endp, 10);
 		if (endp == tmp)
 			goto out;
-		new_entitled_ptr = &current_entitled;
-	} else
-		goto out;
 
-	/* Get our current parameters */
-	retval = h_get_ppp(&current_entitled, &dummy, &dummy, &resource);
-	if (retval) {
-		retval = -EIO;
+		retval = update_ppp(NULL, new_weight_ptr);
+	} else
 		goto out;
-	}
-
-	current_weight = (resource >> 5 * 8) & 0xFF;
-
-	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
-		 __func__, current_entitled, current_weight);
-
-	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
-		 __func__, *new_entitled_ptr, *new_weight_ptr);
-
-	retval = plpar_hcall_norets(H_SET_PPP, *new_entitled_ptr,
-				    *new_weight_ptr);
 
 	if (retval == H_SUCCESS || retval == H_CONSTRAINED) {
 		retval = count;

^ permalink raw reply

* Re: [PATCH 03/16 v3] powerpc: Add memory entitlement capabilities to /proc/ppc64/lparcfg
From: Nathan Fontenot @ 2008-07-22 18:55 UTC (permalink / raw)
  To: Robert Jennings; +Cc: Brian King, linuxppc-dev, paulus, David Darrington
In-Reply-To: <20080704125147.GD1310@linux.vnet.ibm.com>

Updated patch, increment the lparcfg module version number.

Update /proc/ppc64/lparcfg to enable displaying of Cooperative Memory
Overcommitment statistics as reported by the H_GET_MPP hcall.  This also
updates the lparcfg interface to allow setting memory entitlement and
weight.

Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>

---
 arch/powerpc/kernel/lparcfg.c |  119 ++++++++++++++++++++++++++++++++++++++++++
 include/asm-powerpc/hvcall.h  |   18 ++++++
 2 files changed, 136 insertions(+), 1 deletion(-)

Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c	2008-07-22 12:50:47.000000000 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c	2008-07-22 13:16:58.000000000 -0500
@@ -35,7 +35,7 @@
 #include <asm/prom.h>
 #include <asm/vdso_datapage.h>
 
-#define MODULE_VERS "1.7"
+#define MODULE_VERS "1.8"
 #define MODULE_NAME "lparcfg"
 
 /* #define LPARCFG_DEBUG */
@@ -129,6 +129,35 @@
 /*
  * Methods used to fetch LPAR data when running on a pSeries platform.
  */
+/**
+ * h_get_mpp
+ * H_GET_MPP hcall returns info in 7 parms
+ */
+int h_get_mpp(struct hvcall_mpp_data *mpp_data)
+{
+	int rc;
+	unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+
+	rc = plpar_hcall9(H_GET_MPP, retbuf);
+
+	mpp_data->entitled_mem = retbuf[0];
+	mpp_data->mapped_mem = retbuf[1];
+
+	mpp_data->group_num = (retbuf[2] >> 2 * 8) & 0xffff;
+	mpp_data->pool_num = retbuf[2] & 0xffff;
+
+	mpp_data->mem_weight = (retbuf[3] >> 7 * 8) & 0xff;
+	mpp_data->unallocated_mem_weight = (retbuf[3] >> 6 * 8) & 0xff;
+	mpp_data->unallocated_entitlement = retbuf[3] & 0xffffffffffff;
+
+	mpp_data->pool_size = retbuf[4];
+	mpp_data->loan_request = retbuf[5];
+	mpp_data->backing_mem = retbuf[6];
+
+	return rc;
+}
+EXPORT_SYMBOL(h_get_mpp);
+
 /*
  * H_GET_PPP hcall returns info in 4 parms.
  *  entitled_capacity,unallocated_capacity,
@@ -224,6 +253,44 @@
 	seq_printf(m, "unallocated_capacity=%ld\n", h_unallocated);
 }
 
+/**
+ * parse_mpp_data
+ * Parse out data returned from h_get_mpp
+ */
+static void parse_mpp_data(struct seq_file *m)
+{
+	struct hvcall_mpp_data mpp_data;
+	int rc;
+
+	rc = h_get_mpp(&mpp_data);
+	if (rc)
+		return;
+
+	seq_printf(m, "entitled_memory=%ld\n", mpp_data.entitled_mem);
+
+	if (mpp_data.mapped_mem != -1)
+		seq_printf(m, "mapped_entitled_memory=%ld\n",
+		           mpp_data.mapped_mem);
+
+	seq_printf(m, "entitled_memory_group_number=%d\n", mpp_data.group_num);
+	seq_printf(m, "entitled_memory_pool_number=%d\n", mpp_data.pool_num);
+
+	seq_printf(m, "entitled_memory_weight=%d\n", mpp_data.mem_weight);
+	seq_printf(m, "unallocated_entitled_memory_weight=%d\n",
+	           mpp_data.unallocated_mem_weight);
+	seq_printf(m, "unallocated_io_mapping_entitlement=%ld\n",
+	           mpp_data.unallocated_entitlement);
+
+	if (mpp_data.pool_size != -1)
+		seq_printf(m, "entitled_memory_pool_size=%ld bytes\n",
+		           mpp_data.pool_size);
+
+	seq_printf(m, "entitled_memory_loan_request=%ld\n",
+	           mpp_data.loan_request);
+
+	seq_printf(m, "backing_memory=%ld bytes\n", mpp_data.backing_mem);
+}
+
 #define SPLPAR_CHARACTERISTICS_TOKEN 20
 #define SPLPAR_MAXLENGTH 1026*(sizeof(char))
 
@@ -351,6 +418,7 @@
 		/* this call handles the ibm,get-system-parameter contents */
 		parse_system_parameter_string(m);
 		parse_ppp_data(m);
+		parse_mpp_data(m);
 
 		seq_printf(m, "purr=%ld\n", get_purr());
 	} else {		/* non SPLPAR case */
@@ -414,6 +482,43 @@
 	return retval;
 }
 
+/**
+ * update_mpp
+ *
+ * Update the memory entitlement and weight for the partition.  Caller must
+ * specify either a new entitlement or weight, not both, to be updated
+ * since the h_set_mpp call takes both entitlement and weight as parameters.
+ */
+static ssize_t update_mpp(u64 *entitlement, u8 *weight)
+{
+	struct hvcall_mpp_data mpp_data;
+	u64 new_entitled;
+	u8 new_weight;
+	ssize_t rc;
+
+	rc = h_get_mpp(&mpp_data);
+	if (rc)
+		return rc;
+
+	if (entitlement) {
+		new_weight = mpp_data.mem_weight;
+		new_entitled = *entitlement;
+	} else if (weight) {
+		new_weight = *weight;
+		new_entitled = mpp_data.entitled_mem;
+	} else
+		return -EINVAL;
+
+	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
+	         __FUNCTION__, mpp_data.entitled_mem, mpp_data.mem_weight);
+
+	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
+	         __FUNCTION__, new_entitled, new_weight);
+
+	rc = plpar_hcall_norets(H_SET_MPP, new_entitled, new_weight);
+	return rc;
+}
+
 /*
  * Interface for changing system parameters (variable capacity weight
  * and entitled capacity).  Format of input is "param_name=value";
@@ -467,6 +572,20 @@
 			goto out;
 
 		retval = update_ppp(NULL, new_weight_ptr);
+	} else if (!strcmp(kbuf, "entitled_memory")) {
+		char *endp;
+		*new_entitled_ptr = (u64) simple_strtoul(tmp, &endp, 10);
+		if (endp == tmp)
+			goto out;
+
+		retval = update_mpp(new_entitled_ptr, NULL);
+	} else if (!strcmp(kbuf, "entitled_memory_weight")) {
+		char *endp;
+		*new_weight_ptr = (u8) simple_strtoul(tmp, &endp, 10);
+		if (endp == tmp)
+			goto out;
+
+		retval = update_mpp(NULL, new_weight_ptr);
 	} else
 		goto out;
 
Index: linux-2.6.git/include/asm-powerpc/hvcall.h
===================================================================
--- linux-2.6.git.orig/include/asm-powerpc/hvcall.h	2008-07-22 12:48:55.000000000 -0500
+++ linux-2.6.git/include/asm-powerpc/hvcall.h	2008-07-22 13:16:36.000000000 -0500
@@ -210,7 +210,9 @@
 #define H_JOIN			0x298
 #define H_VASI_STATE            0x2A4
 #define H_ENABLE_CRQ		0x2B0
-#define MAX_HCALL_OPCODE	H_ENABLE_CRQ
+#define H_SET_MPP		0x2D0
+#define H_GET_MPP		0x2D4
+#define MAX_HCALL_OPCODE	H_GET_MPP
 
 #ifndef __ASSEMBLY__
 
@@ -270,6 +272,20 @@
 };
 #define HCALL_STAT_ARRAY_SIZE	((MAX_HCALL_OPCODE >> 2) + 1)
 
+struct hvcall_mpp_data {
+	unsigned long entitled_mem;
+	unsigned long mapped_mem;
+	unsigned short group_num;
+	unsigned short pool_num;
+	unsigned char mem_weight;
+	unsigned char unallocated_mem_weight;
+	unsigned long unallocated_entitlement;  /* value in bytes */
+	unsigned long pool_size;
+	signed long loan_request;
+	unsigned long backing_mem;
+};
+
+int h_get_mpp(struct hvcall_mpp_data *);
 #endif /* __ASSEMBLY__ */
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_HVCALL_H */

^ permalink raw reply

* Re: [PATCH 04/16 v3] powerpc: Split retrieval of processor entitlement data into a helper routine
From: Nathan Fontenot @ 2008-07-22 18:56 UTC (permalink / raw)
  To: Robert Jennings; +Cc: Brian King, linuxppc-dev, paulus, David Darrington
In-Reply-To: <20080704125207.GE1310@linux.vnet.ibm.com>

Updated patch to correct the reporting of pool_capcity.

Split the retrieval of processor entitlement data returned in the H_GET_PPP
hcall into its own helper routine.

Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>

---
 arch/powerpc/kernel/lparcfg.c |   80 ++++++++++++++++++++++++------------------
 1 file changed, 45 insertions(+), 35 deletions(-)

Index: linux-2.6.git/arch/powerpc/kernel/lparcfg.c
===================================================================
--- linux-2.6.git.orig/arch/powerpc/kernel/lparcfg.c	2008-07-22 13:16:58.000000000 -0500
+++ linux-2.6.git/arch/powerpc/kernel/lparcfg.c	2008-07-22 13:17:25.000000000 -0500
@@ -158,6 +158,18 @@
 }
 EXPORT_SYMBOL(h_get_mpp);
 
+struct hvcall_ppp_data {
+	u64	entitlement;
+	u64	unallocated_entitlement;
+	u16	group_num;
+	u16	pool_num;
+	u8	capped;
+	u8	weight;
+	u8	unallocated_weight;
+	u16	active_procs_in_pool;
+	u16	active_system_procs;
+};
+
 /*
  * H_GET_PPP hcall returns info in 4 parms.
  *  entitled_capacity,unallocated_capacity,
@@ -178,20 +190,24 @@
  *              XXXX - Active processors in Physical Processor Pool.
  *                  XXXX  - Processors active on platform.
  */
-static unsigned int h_get_ppp(unsigned long *entitled,
-			      unsigned long *unallocated,
-			      unsigned long *aggregation,
-			      unsigned long *resource)
+static unsigned int h_get_ppp(struct hvcall_ppp_data *ppp_data)
 {
 	unsigned long rc;
 	unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
 
 	rc = plpar_hcall(H_GET_PPP, retbuf);
 
-	*entitled = retbuf[0];
-	*unallocated = retbuf[1];
-	*aggregation = retbuf[2];
-	*resource = retbuf[3];
+	ppp_data->entitlement = retbuf[0];
+	ppp_data->unallocated_entitlement = retbuf[1];
+
+	ppp_data->group_num = (retbuf[2] >> 2 * 8) & 0xffff;
+	ppp_data->pool_num = retbuf[2] & 0xffff;
+
+	ppp_data->capped = (retbuf[3] >> 6 * 8) & 0x01;
+	ppp_data->weight = (retbuf[3] >> 5 * 8) & 0xff;
+	ppp_data->unallocated_weight = (retbuf[3] >> 4 * 8) & 0xff;
+	ppp_data->active_procs_in_pool = (retbuf[3] >> 2 * 8) & 0xffff;
+	ppp_data->active_system_procs = retbuf[3] & 0xffff;
 
 	return rc;
 }
@@ -216,41 +232,40 @@
  */
 static void parse_ppp_data(struct seq_file *m)
 {
-	unsigned long h_entitled, h_unallocated;
-	unsigned long h_aggregation, h_resource;
+	struct hvcall_ppp_data ppp_data;
 	int rc;
 
-	rc = h_get_ppp(&h_entitled, &h_unallocated, &h_aggregation,
-		       &h_resource);
+	rc = h_get_ppp(&ppp_data);
 	if (rc)
 		return;
 
-	seq_printf(m, "partition_entitled_capacity=%ld\n", h_entitled);
-	seq_printf(m, "group=%ld\n", (h_aggregation >> 2 * 8) & 0xffff);
-	seq_printf(m, "system_active_processors=%ld\n",
-		   (h_resource >> 0 * 8) & 0xffff);
+	seq_printf(m, "partition_entitled_capacity=%ld\n",
+	           ppp_data.entitlement);
+	seq_printf(m, "group=%d\n", ppp_data.group_num);
+	seq_printf(m, "system_active_processors=%d\n",
+	           ppp_data.active_system_procs);
 
 	/* pool related entries are apropriate for shared configs */
 	if (lppaca[0].shared_proc) {
 		unsigned long pool_idle_time, pool_procs;
 
-		seq_printf(m, "pool=%ld\n", (h_aggregation >> 0 * 8) & 0xffff);
+		seq_printf(m, "pool=%d\n", ppp_data.pool_num);
 
 		/* report pool_capacity in percentage */
-		seq_printf(m, "pool_capacity=%ld\n",
-			   ((h_resource >> 2 * 8) & 0xffff) * 100);
+		seq_printf(m, "pool_capacity=%d\n",
+			   ppp_data.active_procs_in_pool * 100);
 
 		h_pic(&pool_idle_time, &pool_procs);
 		seq_printf(m, "pool_idle_time=%ld\n", pool_idle_time);
 		seq_printf(m, "pool_num_procs=%ld\n", pool_procs);
 	}
 
-	seq_printf(m, "unallocated_capacity_weight=%ld\n",
-		   (h_resource >> 4 * 8) & 0xFF);
-
-	seq_printf(m, "capacity_weight=%ld\n", (h_resource >> 5 * 8) & 0xFF);
-	seq_printf(m, "capped=%ld\n", (h_resource >> 6 * 8) & 0x01);
-	seq_printf(m, "unallocated_capacity=%ld\n", h_unallocated);
+	seq_printf(m, "unallocated_capacity_weight=%d\n",
+		   ppp_data.unallocated_weight);
+	seq_printf(m, "capacity_weight=%d\n", ppp_data.weight);
+	seq_printf(m, "capped=%d\n", ppp_data.capped);
+	seq_printf(m, "unallocated_capacity=%ld\n",
+		   ppp_data.unallocated_entitlement);
 }
 
 /**
@@ -449,31 +464,27 @@
 
 static ssize_t update_ppp(u64 *entitlement, u8 *weight)
 {
-	unsigned long current_entitled;
-	unsigned long dummy;
-	unsigned long resource;
-	u8 current_weight, new_weight;
+	struct hvcall_ppp_data ppp_data;
+	u8 new_weight;
 	u64 new_entitled;
 	ssize_t retval;
 
 	/* Get our current parameters */
-	retval = h_get_ppp(&current_entitled, &dummy, &dummy, &resource);
+	retval = h_get_ppp(&ppp_data);
 	if (retval)
 		return retval;
 
-	current_weight = (resource >> 5 * 8) & 0xFF;
-
 	if (entitlement) {
-		new_weight = current_weight;
+		new_weight = ppp_data.weight;
 		new_entitled = *entitlement;
 	} else if (weight) {
 		new_weight = *weight;
-		new_entitled = current_entitled;
+		new_entitled = ppp_data.entitlement;
 	} else
 		return -EINVAL;
 
 	pr_debug("%s: current_entitled = %lu, current_weight = %u\n",
-		 __FUNCTION__, current_entitled, current_weight);
+	         __FUNCTION__, ppp_data.entitlement, ppp_data.weight);
 
 	pr_debug("%s: new_entitled = %lu, new_weight = %u\n",
 		 __FUNCTION__, new_entitled, new_weight);

^ permalink raw reply

* [OT] write flash on MPC5200 board via jtag
From: Albrecht Dreß @ 2008-07-22 18:56 UTC (permalink / raw)
  To: LinuxPPC Embedded

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

Hi,

sorry for a somewhat off-topic question...

I want to design a mpc5200b board which is roughly derived from  
Freescale's 5200B Lite demo.  Obviously, I have the problem to  
initially write u-boot into the boot nor flash.  I believe this would  
be possible using the jtag/bsm interface (is that true?).

Can you recommend any good hardware and software solution for that, if  
possible running on linux (OSS?)?  I don't need a "real" debugger  
(maybe an interface to gdb), just something to write the flash, so  
u-boot comes up.

Thanks for any help,
Albrecht.

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

^ permalink raw reply

* RE: Problem with cuImage Linux entry from old U-boot
From: Stephen Horton @ 2008-07-22 19:23 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080722180506.GB13940@loki.buserror.net>

Thanks Scott for the tip. I'll redouble my efforts to compare the code
in my older 1.1.2 U-boot source (that the board boots from) with my new
.dts and cuboot source.

-----Original Message-----
From: Scott Wood [mailto:scottwood@freescale.com]=20
Sent: Tuesday, July 22, 2008 1:05 PM
To: Stephen Horton
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Problem with cuImage Linux entry from old U-boot

On Mon, Jul 21, 2008 at 03:39:55PM -0500, Stephen Horton wrote:
> I have made great strides with help from this mailing list and its
> archives. I now have a compiled cuImage ready to boot from my older
> working u-boot 1.1.2. I now seem to be stuck at the kernel entry
point.
> I'm not sure if I'm trying to jump into the kernel at the wrong
address,
> or if I have a serial console issue that prevents me from seeing
anymore
> progress.

Most likely the latter, or some other issue that prevents the kernel
from
booting to the point where the serial console functions.

> Linux/PowerPC load: ip=3Dbootp root=3D/dev/nfs rw =
nfsroot=3D/opt/gentoo
> console=3DttyMM0,9600n8
> Finalizing device tree... flat tree at 0x7423a0
>=20
> =20
>=20
> ------
>=20
> =20
>=20
> If I run 'nm' on my elf image, I expect to find some entry point
address
> that corresponds to 0x7423a0, but this is not the case.=20

Why would you expect that?  It's a dynamically allocated chunk of memory
that holds the device tree that is passed to the kernel.  It's not an
entry
point; the entry point to the kernel is zero.

-Scott

^ permalink raw reply

* Re: latest tree build failure -- cpm uart & gpio
From: David Brownell @ 2008-07-22 19:33 UTC (permalink / raw)
  To: avorontsov; +Cc: linuxppc-dev list, Kumar Gala, Linux Kernel list, Alan Cox
In-Reply-To: <20080722145330.GA2315@polina.dev.rtsoft.ru>

On Tuesday 22 July 2008, Anton Vorontsov wrote:
> On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> > can someone look at the following compile failure in linus's tree.  I'm 
> > guessing part of this has to do with Alan's tty changes (and might  
> > already be addressed?).
> >
> > include/asm-generic/gpio.h:131: error: implicit declaration of function 
> > 'gpio_get_value'
> > include/asm-generic/gpio.h:137: error: implicit declaration of function 
> > 'gpio_set_value'
> 
> I think this patch should help:
> 
> [OF] of_gpio: should use new <linux/gpio.h> header
> http://patchwork.ozlabs.org/linuxppc/patch?id=18750

Is that confirmed as fixing this, vs just being the Right Thing To Do?

 
> David, can you please Ack it? See Benjamin's mail:
> http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html

If you like ... but this is an OF-specific change, making
it conform with the interface spec, so I wouldn't expect
this to need more approvals than it's already got.

Acked-by: David Brownell <dbrownell@users.sourceforge.net>


> 
> -- 
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
> 

^ permalink raw reply

* Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x
From: Victor Gallardo @ 2008-07-22 19:35 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20080719094417.4c49cd36@zod.rchland.ibm.com>


>As you might have noticed, this has generated quite a bit of discussion
>on whether this is the right approach or not.  If you can wait for a
>week, we plan on talking it over at OLS.  Then I can give you a better
>idea as to whether we're going to stick with this or use a different
>approach.
>
>Overall your patches are fairly clean, so you've done a good job so
>far.  Have a little patience with us as we figure out the right way to
>go :).
>
>josh

OK. I watch the mailing list for updates.

Thanks,

Victor Gallardo
-- 
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18597016.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* netif_schedule and mpc5200_fec
From: Jon Smirl @ 2008-07-22 19:47 UTC (permalink / raw)
  To: ppc-dev, netdev

I just updated to linus/master and mpc5200_fec won't boot.

Guessing it is this patch but I haven't looked at it yet.

commit 263ba3204a434d0ca851e1321b31cd58376b86cb
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jul 15 03:47:41 2008 -0700

    netdev: Convert all drivers away from netif_schedule().

    They logically all want to trigger a schedule for all device
    TX queues.

    Signed-off-by: David S. Miller <davem@davemloft.net>


Sending DHCP requests .<0>------------[ cut here ]------------
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
GPR08: c382dfb4 c0330000 00000000 c031e468 3181b461 ffffffff 03ffe000 ffffffff
GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
PHY: f0003000:00 - Link is Up - 100/Full
., OK


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: How to create custom ramdisk
From: Ron Sass @ 2008-07-22 19:49 UTC (permalink / raw)
  To: Neeraj Garg; +Cc: linuxppc-embedded
In-Reply-To: <4885DCA4.9050709@cdac.in>


Under my home page, I have links to the courses I teach.

http://rcs.uncc.edu/~rsass/

Follow the links to "Fundamentals of Reconfigurable
Computing"  specifically,

http://rcs.uncc.edu/~rsass/courses/2008-Fall/6890/

There are labs and tutorials there.  Under Labs, (Lab 3 in
particular) we build Linux-based systems.  Lab 3 is has a tutorial
based on Secret Lab's git repository and some in-house scripts.
The students use RHEL5 machines but in our research lab we Fedora
Core and CentOS4 machines.

Also we have a wiki with other tutorials.  Sorry, it's not very
organized (or up to date...)

http://www.rcs.uncc.edu/wiki/index.php/Main_Page

Ron


> 
> Hi,
> 
> I want to create a custom ramdisk (initrd which can be placed in 
> arch/ppc/boot/images). Can anybody guide me steps to built the same. My 
> host have RHEL-4.
> 
> -- 
> 
> -------------------------------------------------------------------
> Neeraj Garg
> 
> 
> 
> --------------080207080004080602090709
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>   <title></title>
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Hi,<br>
> <br>
> I want to create a custom ramdisk (initrd which can be placed in
> arch/ppc/boot/images). Can anybody guide me steps to built
> the same. My host have RHEL-4.<br>
> <br>
> <div class="moz-signature">-- <br>
> <pre><!-- img src="file:///E:/htdg.jpg" border="0" alt="C-DAC"-->------------
> -------------------------------------------------------
> Neeraj Garg
> 
> </pre>
> </div>
> </body>
> </html>
> 
> --------------080207080004080602090709--
> 
> 
> --===============0773240910==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> --===============0773240910==--
> 

^ permalink raw reply

* BUG with U-boot 1.1.4 and kernel 2.6.23 scanning PCIe on a MPC8641D board
From: Siva Prasad @ 2008-07-22 20:09 UTC (permalink / raw)
  To: joachim.bader, linuxppc-embedded
In-Reply-To: <mailman.363.1216733649.2828.linuxppc-embedded@ozlabs.org>

Hi Joachim,

We did not had a crash, but had some problem with assigning resources
for PCI bus on 8641D. Your issue may be related or not, I am not really
sure.

You might want to check out MSI patch. Currently this is already there
for few other FSL processors like 85xx, but not for 86xx.

- Siva
=20


joachim.bader@diehl-aerospace.de Wrote:

Hello folks,

we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4
and=20
Linux kernel 2.6.23

First of all, we are no experts in PCIe-Bus handling and management.
We started with the problem that U-Boot was able to scan the devices=20
connected to PCIe-Bus where the kernel fails.
Using the information provided by Vince Asbridge regarding the different

numbering of devices on PCIe bus by U-Boot and kernel we were able to
get=20
the kernel up recognizing the devices correctly.
Thanks for this info.

But now we are blocked by an exception in kernel mode during=20
initialisation of the PCIe-Buses and devices. We instrumented the kernel

additional to the standard print outs to get more information and to=20
understand the behavior of the scan and allocation process. But now we
get=20
lost. I assume that the problem is caused by the transparent bridges.

I appent here after the trace log. Perhaps someone knows this problem=20
already or can give me a hint .

I read in the logs some messages that 2.6.23 does contain some bugs=20
related to PCIe and it would be a good choice to upgrade to 2.6.25. Is=20
this one of that cases?
Currently we would like to prevent switching the kernel version.

Any help is appreciated.

Thanks in advance.

Joachim

^ permalink raw reply

* Re: [PATCH] fs_enet: Remove unused fields in the fs_mii_bb_platform_info structure.
From: Jeff Garzik @ 2008-07-22 20:09 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: linuxppc-dev, vbordug, netdev
In-Reply-To: <200807221743.47807.laurentp@cse-semaphore.com>

Laurent Pinchart wrote:
> The mdio_port, mdio_bit, mdc_port and mdc_bit fields in the
> fs_mii_bb_platform_info structure are left-overs from the move to the Phy
> Abstraction Layer subsystem. They are not used anymore and can be safely
> removed.
> 
> Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
> ---
>  include/linux/fs_enet_pd.h    |    4 ----
>  1 files changed, 0 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
> index 9bc045b..decc4b5 100644
> --- a/include/linux/fs_enet_pd.h
> +++ b/include/linux/fs_enet_pd.h
> @@ -103,10 +103,6 @@ struct fs_mii_bb_platform_info {
>  	struct fs_mii_bit 	mdio_dir;
>  	struct fs_mii_bit 	mdio_dat;
>  	struct fs_mii_bit	mdc_dat;
> -	int mdio_port;	/* port & bit for MDIO */
> -	int mdio_bit;
> -	int mdc_port;	/* port & bit for MDC  */
> -	int mdc_bit;
>  	int delay;	/* delay in us         */
>  	int irq[32]; 	/* irqs per phy's */

applied

^ permalink raw reply

* Re: gigantci pages patches
From: Jon Tollefson @ 2008-07-22 20:22 UTC (permalink / raw)
  To: Stephen Rothwell, benh, paulus, npiggin, Jon Tollefson, ppc-dev,
	Andrew Morton
In-Reply-To: <20080722033417.GD14888@yookeroo.seuss>

David Gibson wrote:
> On Fri, Jul 11, 2008 at 05:45:15PM +1000, Stephen Rothwell wrote:
>   
>> Hi all,
>>
>> Could people take one last look at these patches and if there are no
>> issues, please send Ack-bys to Andrew who will push them to Linus for
>> 2.6.27.
>>
>> [PATCH 1/6 v2] allow arch specific function for allocating gigantic pages
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18437
>> Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18438
>> Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18439
>> Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18440
>> Patch: [PATCH 5/6 v2] check for overflow
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18441
>> Patch: [PATCH 6/6] powerpc: support multiple huge page sizes
>> http://patchwork.ozlabs.org/linuxppc/patch?&id=18442
>>     
>
> Sorry, I should have looked at these properly when they went past in
> May, but obviously I missed them.
>
> They mostly look ok.  I'm a bit confused on 2/6 though - it seems the
> new powerpc alloc_bootmem_huge_page() function is specific to the 16G
> gigantic pages.  But can't that function also get called for the
> normal 16M hugepages depending on how the hugepage pool is
> initialized.
>
> Or am I missing something (wouldn't surprise me given my brain's
> sluggishness today)?
>   
The alloc_bootmem_huge_page() function is only called for pages >=
MAX_ORDER.  The 16M pages are always allocated within the generic
hugetlbfs code with alloc_pages_node().

Jon

^ permalink raw reply

* Re: latest tree build failure -- cpm uart & gpio
From: Anton Vorontsov @ 2008-07-22 20:48 UTC (permalink / raw)
  To: David Brownell; +Cc: linuxppc-dev list, Kumar Gala, Linux Kernel list, Alan Cox
In-Reply-To: <200807221233.16723.david-b@pacbell.net>

On Tue, Jul 22, 2008 at 12:33:16PM -0700, David Brownell wrote:
> On Tuesday 22 July 2008, Anton Vorontsov wrote:
> > On Tue, Jul 22, 2008 at 08:54:16AM -0500, Kumar Gala wrote:
> > > can someone look at the following compile failure in linus's tree.  I'm 
> > > guessing part of this has to do with Alan's tty changes (and might  
> > > already be addressed?).
> > >
> > > include/asm-generic/gpio.h:131: error: implicit declaration of function 
> > > 'gpio_get_value'
> > > include/asm-generic/gpio.h:137: error: implicit declaration of function 
> > > 'gpio_set_value'
> > 
> > I think this patch should help:
> > 
> > [OF] of_gpio: should use new <linux/gpio.h> header
> > http://patchwork.ozlabs.org/linuxppc/patch?id=18750
> 
> Is that confirmed as fixing this, vs just being the Right Thing To Do?

Just applied the patch locally and the issue is not reproducible
anymore.

> > David, can you please Ack it? See Benjamin's mail:
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/060109.html
> 
> If you like ... but this is an OF-specific change, making
> it conform with the interface spec, so I wouldn't expect
> this to need more approvals than it's already got.
> 
> Acked-by: David Brownell <dbrownell@users.sourceforge.net>

Thanks.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply


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