LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 09/11] [POWERPC] Motion-PRO: Add LED support.
From: Grant Likely @ 2007-10-24 14:18 UTC (permalink / raw)
  To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <20071023231358.29359.90259.stgit@hekate.izotz.org>

On 10/23/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Add LED driver for Promess Motion-PRO board.
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
>
>  drivers/leds/Kconfig          |    7 +
>  drivers/leds/Makefile         |    3 -
>  drivers/leds/leds-motionpro.c |  222 +++++++++++++++++++++++++++++++++++++++++
>  include/asm-powerpc/mpc52xx.h |    5 +
>  4 files changed, 236 insertions(+), 1 deletions(-)
>  create mode 100644 drivers/leds/leds-motionpro.c
>
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index ec568fa..1567ed6 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -55,6 +55,13 @@ config LEDS_TOSA
>           This option enables support for the LEDs on Sharp Zaurus
>           SL-6000 series.
>
> +config LEDS_MOTIONPRO
> +       tristate "Motion-PRO LEDs Support"
> +       depends on LEDS_CLASS && PPC_MPC5200
> +       help
> +         This option enables support for status and ready LEDs connected
> +         to GPIO lines on Motion-PRO board.
> +
>  config LEDS_S3C24XX
>         tristate "LED Support for Samsung S3C24XX GPIO LEDs"
>         depends on LEDS_CLASS && ARCH_S3C2410
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index a60de1b..a56d399 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -18,7 +18,8 @@ obj-$(CONFIG_LEDS_H1940)              += leds-h1940.o
>  obj-$(CONFIG_LEDS_COBALT_QUBE)         += leds-cobalt-qube.o
>  obj-$(CONFIG_LEDS_COBALT_RAQ)          += leds-cobalt-raq.o
>  obj-$(CONFIG_LEDS_GPIO)                        += leds-gpio.o
> -obj-$(CONFIG_LEDS_CM_X270)              += leds-cm-x270.o
> +obj-$(CONFIG_LEDS_CM_X270)             += leds-cm-x270.o
> +obj-$(CONFIG_LEDS_MOTIONPRO)           += leds-motionpro.o
>
>  # LED Triggers
>  obj-$(CONFIG_LEDS_TRIGGER_TIMER)       += ledtrig-timer.o
> diff --git a/drivers/leds/leds-motionpro.c b/drivers/leds/leds-motionpro.c
> new file mode 100644
> index 0000000..d4b872c
> --- /dev/null
> +++ b/drivers/leds/leds-motionpro.c
> @@ -0,0 +1,222 @@
> +/*
> + * LEDs driver for the Motionpro board.
> + *
> + * Copyright (C) 2007 Semihalf
> + *
> + * Author: Jan Wrobel <wrr@semihalf.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc., 51
> + * Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + *
> + * This driver enables control over Motionpro's status and ready LEDs through
> + * sysfs. LEDs can be controlled by writing to sysfs files:
> + * class/leds/motionpro-(ready|status)led/(brightness|delay_off|delay_on).
> + * See Documentation/leds-class.txt for more details
> + *
> + * Before user issues first control command via sysfs, LED blinking is
> + * controlled by the kernel. By default status LED is blinking fast and ready
> + * LED is turned off.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/leds.h>
> +
> +#include <asm/mpc52xx.h>
> +#include <asm/io.h>
> +
> +/* Led status */
> +#define LED_NOT_REGISTERED     0
> +#define LED_KERNEL_CONTROLLED  1
> +#define LED_USER_CONTROLLED    2
> +
> +/* Led control bits */
> +#define LED_ON MPC52xx_GPT_OUTPUT_1
> +
> +static void mpled_set(struct led_classdev *led_cdev,
> +                     enum led_brightness brightness);
> +
> +struct motionpro_led{
> +       /* Protects the led data */
> +       spinlock_t led_lock;
> +
> +       /* Path to led's control register DTS node */
> +       char *reg_compat;
> +
> +       /* Address to access led's register */
> +       void __iomem *reg_addr;
> +
> +       int status;
> +
> +       /* Blinking timer used when led is controlled by the kernel */
> +       struct timer_list kernel_mode_timer;
> +
> +       /*
> +        * Delay between blinks when led is controlled by the kernel.
> +        * If set to 0 led blinking is off.
> +        */
> +       int kernel_mode_delay;
> +
> +       struct led_classdev classdev;
> +};
> +
> +static struct motionpro_led led[] = {
> +       {
> +               .reg_compat = "promess,motionpro-statusled",
> +               .reg_addr = 0,
> +               .led_lock = SPIN_LOCK_UNLOCKED,
> +               .status = LED_NOT_REGISTERED,
> +               .kernel_mode_delay = HZ / 10,
> +               .classdev = {
> +                       .name = "motionpro-statusled",
> +                       .brightness_set = mpled_set,
> +                       .default_trigger = "timer",
> +               },
> +       },
> +       {
> +               .reg_compat = "promess,motionpro-readyled",
> +               .reg_addr = 0,
> +               .led_lock = SPIN_LOCK_UNLOCKED,
> +               .status = LED_NOT_REGISTERED,
> +               .kernel_mode_delay = 0,
> +               .classdev = {
> +                       .name = "motionpro-readyled",
> +                       .brightness_set = mpled_set,
> +                       .default_trigger = "timer",
> +               }
> +       }
> +};
> +
> +/* Timer event - blinks led before user takes control over it */
> +static void mpled_timer_toggle(unsigned long ptr)
> +{
> +       struct motionpro_led *mled = (struct motionpro_led *) ptr;
> +
> +       spin_lock_bh(&mled->led_lock);
> +       if (mled->status == LED_KERNEL_CONTROLLED){
> +               u32 reg = in_be32(mled->reg_addr);
> +               reg ^= LED_ON;
> +               out_be32(mled->reg_addr, reg);
> +               led->kernel_mode_timer.expires = jiffies +
> +                       led->kernel_mode_delay;
> +               add_timer(&led->kernel_mode_timer);
> +       }
> +       spin_unlock_bh(&mled->led_lock);
> +}
> +
> +
> +/*
> + * Turn on/off led according to user settings in sysfs.
> + * First call to this function disables kernel blinking.
> + */
> +static void mpled_set(struct led_classdev *led_cdev,
> +                     enum led_brightness brightness)
> +{
> +       struct motionpro_led *mled;
> +       u32 reg;
> +
> +       mled = container_of(led_cdev, struct motionpro_led, classdev);
> +
> +       spin_lock_bh(&mled->led_lock);
> +       mled->status = LED_USER_CONTROLLED;
> +
> +       reg = in_be32(mled->reg_addr);
> +       if (brightness)
> +               reg |= LED_ON;
> +       else
> +               reg &= ~LED_ON;
> +       out_be32(mled->reg_addr, reg);
> +
> +       spin_unlock_bh(&mled->led_lock);
> +}
> +
> +static void mpled_init_led(void __iomem *reg_addr)
> +{
> +       u32 reg = in_be32(reg_addr);
> +       reg |= MPC52xx_GPT_ENABLE_OUTPUT;
> +       reg &= ~LED_ON;
> +       out_be32(reg_addr, reg);
> +}
> +
> +static void mpled_clean(void)
> +{
> +       int i;
> +       for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> +               if (led[i].status != LED_NOT_REGISTERED){
> +                       spin_lock_bh(&led[i].led_lock);
> +                       led[i].status = LED_NOT_REGISTERED;
> +                       spin_unlock_bh(&led[i].led_lock);
> +                       led_classdev_unregister(&led[i].classdev);
> +               }
> +               if (led[i].reg_addr){
> +                       iounmap(led[i].reg_addr);
> +                       led[i].reg_addr = 0;
> +               }
> +       }
> +}
> +
> +static int __init mpled_init(void)
> +{
> +       int i, error;
> +
> +       for (i = 0; i < sizeof(led) / sizeof(struct motionpro_led); i++){
> +               led[i].reg_addr = mpc52xx_find_and_map(led[i].reg_compat);

Please use of-platform-bus bindings instead.  Let the of-platform bus
take care of scanning the tree for you.  Don't do it manually.

> +               if (!led[i].reg_addr){
> +                       printk(KERN_ERR __FILE__ ": "
> +                              "Error while mapping GPIO register for LED %s\n",
> +                              led[i].classdev.name);
> +                       error = -EIO;
> +                       goto err;
> +               }
> +
> +               mpled_init_led(led[i].reg_addr);
> +               led[i].status = LED_KERNEL_CONTROLLED;
> +               if (led[i].kernel_mode_delay){
> +                       init_timer(&led[i].kernel_mode_timer);
> +                       led[i].kernel_mode_timer.function = mpled_timer_toggle;
> +                       led[i].kernel_mode_timer.data = (unsigned long)&led[i];
> +                       led[i].kernel_mode_timer.expires =
> +                               jiffies + led[i].kernel_mode_delay;
> +                       add_timer(&led[i].kernel_mode_timer);
> +               }
> +
> +               if ((error = led_classdev_register(NULL, &led[i].classdev)) < 0){
> +                       printk(KERN_ERR __FILE__ ": "
> +                              "Error while registering class device for LED "
> +                              "%s\n",
> +                              led[i].classdev.name);
> +                       goto err;
> +               }
> +       }
> +
> +       printk("Motionpro LEDs driver initialized\n");
> +       return 0;
> +err:
> +       mpled_clean();
> +       return error;
> +}
> +
> +static void __exit mpled_exit(void)
> +{
> +       mpled_clean();
> +}
> +
> +module_init(mpled_init);
> +module_exit(mpled_exit);
> +
> +MODULE_LICENSE("GPL")
> +MODULE_DESCRIPTION("LEDs support for Motionpro");
> +MODULE_AUTHOR("Jan Wrobel <wrr@semihalf.com>");
> diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
> index 859ffb0..7e20f54 100644
> --- a/include/asm-powerpc/mpc52xx.h
> +++ b/include/asm-powerpc/mpc52xx.h
> @@ -140,6 +140,11 @@ struct mpc52xx_gpio {
>  #define MPC52xx_GPIO_PSC_CONFIG_UART_WITH_CD   5
>  #define MPC52xx_GPIO_PCI_DIS                   (1<<15)
>
> +/* Enables GPT register to operate as simple GPIO output register */
> +#define MPC52xx_GPT_ENABLE_OUTPUT      0x00000024
> +/* Puts 1 on GPT output pin */
> +#define MPC52xx_GPT_OUTPUT_1           0x00000010
> +
>  /* GPIO with WakeUp*/
>  struct mpc52xx_gpio_wkup {
>         u8 wkup_gpioe;          /* GPIO_WKUP + 0x00 */
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PATCH] PowerPC 440EPx Sequoia USB OHCI DTS entry
From: Valentine Barshak @ 2007-10-24 14:23 UTC (permalink / raw)
  To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071024141041.GA13586@xyzzy.farnsworth.org>

Dale Farnsworth wrote:
> On Wed, Oct 24, 2007 at 05:44:51PM +0400, Valentine Barshak wrote:
>> Dale Farnsworth wrote:
>>> On Wed, Oct 24, 2007 at 03:19:14PM +0400, Valentine Barshak wrote:
>>>> Dale Farnsworth wrote:
>>>>> Valentine wrote:
>>>>>> Actually I also don't see much reason for the 
>>>>>> USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE stuff.
>>>>>> Is this really needed?
>>>>> I think so.  The SOC host controllers are BE and the PCI
>>>>> host controllers are LE.  Or, do you have an alternative
>>>>> method of handling both types?
>>>> Yes, PCI controllers are LE, but do we really need user-selectable 
>>>> USB_OHCI_HCD_PPC_OF_LE option, since USB_OHCI_LITTLE_ENDIAN is selected
>>>> by default for USB_OHCI_HCD_PCI?
>>>> The USB_OHCI_HCD_PPC_OF_LE/BE stuff is related to PPC OF glue only.
>>>> I think it's useless. We should always enable
>>>> USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO for PPC OF
>>>> and the real LE/BE implementation should be selected by the 
>>>> corresponding properties in the device tree.
>>> I agree that they don't need to be user selectable.  It is far preferable
>>> to deduce their values from existing information, if possible.
>>>
>>> -Dale
>> This is the original thread:
>> http://ozlabs.org/pipermail/linuxppc-embedded/2006-November/025054.html
>>
>> I think the USB_OHCI_HCD_PPC_OF_LE/BE should be removed.
>> We can't avoid the slight overhead even using these options, since 
>> USB_OHCI_BIG_ENDIAN_MMIO/DESC should always be anabled for PPC OF and we 
>> we still enable USB_OHCI_LITTLE_ENDIAN for USB_OHCI_HCD_PCI even if 
>> USB_OHCI_HCD_PPC_OF_LE is not set.
> 
> I believe you are saying that we can select any valid combination
> of USB_OHCI_BIG_ENDIAN_DESC, USB_OHCI_BIG_ENDIAN_MMIO, and
> USB_OHCI_LITTLE_ENDIAN, without using USB_OHCI_HCD_PPC_OF_BE and
> USB_OHCI_HCD_PPC_OF_LE.  I agree.  It looks like we can get rid of
> these last two with zero loss in performance or functionality.
> 
> Do you have a patch?

No I don't have it yet :)
I planed to make, test and submit it a bit later.
Thanks,
Valentine.

> 
> -Dale

^ permalink raw reply

* Re: ioctl32 unknown cmds with 2.6.24-rc1
From: Arnd Bergmann @ 2007-10-24 14:27 UTC (permalink / raw)
  To: linuxppc-dev, Geert Uytterhoeven; +Cc: Johannes Berg
In-Reply-To: <1193229045.4510.35.camel@johannes.berg>

On Wednesday 24 October 2007, Johannes Berg wrote:
>   Show Details
>   I've been getting these warnings (many more of them but this is a list
> of unique ones) on my quad G5 with 32-bit userspace:
> 
> ioctl32(cdrom_id:1078): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-3-0
> ioctl32(ata_id:1095): Unknown cmd fd(3) cmd(0000030d){t:03;sz:0} arg(ff863970) on /dev/.tmp-3-0
> ioctl32(smartd:3563): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(ffeb5480) on /dev/sda
> ioctl32(hald-probe-stor:3761): Unknown cmd fd(4) cmd(00005320){t:'S';sz:0} arg(00000004) on /dev/hda
> ioctl32(gnome-terminal:4187): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0} arg(0fd8e400) on /dev/pts/0
> 
> Does anybody know whether this is expected?

It's probably my fault, since I changed the compat ioctl handling for
block devices. Geert already reported the same, but I haven't had
a chance to reproduce it on my system to look into what went wrong.
Probably a trivial bug I introduced in block/compat_ioctl.c

	Arnd <><

^ permalink raw reply

* Re: [PATCH] fix appletouch geyser 1 breakage
From: Dmitry Torokhov @ 2007-10-24 14:29 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linuxppc-dev list, Anton Ekblad
In-Reply-To: <1193233015.4510.44.camel@johannes.berg>

On 10/24/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2007-10-24 at 09:34 -0400, Dmitry Torokhov wrote:
>
> > Well, but what about fountains then? Regardless of the model, if there
> > is a way to stop "empty" meaurements, we should do it.
>
> There is no way on fountains though. We could check the measurement
> ourselves and if no finger is detected decrease the polling frequency or
> something, but there's no hw support.
>

Do yo know who has powerbooks with older geyser models (0x214, 215,
216)? It would be nice to know if they send the data continiously and
whether the geyser 3 reset hack works on them.

-- 
Dmitry

^ permalink raw reply

* Re: libfdt: Rename and publish _fdt_next_tag()
From: Jon Loeliger @ 2007-10-24 14:59 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024010609.GH10595@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> Although it's a low-level function that shouldn't normally be needed,
> there are circumstances where it's useful for users of libfdt to use
> the _fdt_next_tag() function.  Therefore, this patch renames it to
> fdt_next_tag() and publishes it in libfdt.h.
> 
> In addition, this patch adds a new testcase using fdt_next_tag(),
> dtbs_equal_ordered.  This testcase tests for structural equality of
> two dtbs, including the order of properties and subnodes, but ignoring
> NOP tags, the order of the dtb sections and the layout of strings in
> the strings block.  This will be useful for testing other dtc
> functionality in the future.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Applied.

Thanks,
jdl

^ permalink raw reply

* Re: libfdt: Add some documenting comments in libfdt.h
From: Jon Loeliger @ 2007-10-24 15:00 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071024071058.GC17853@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> This patch adds some internal documentation in libfdt.h, in the form
> of comments on the error codes and some functions.  Only a couple of
> functions are covered so far, leaving the documentation still woefully
> inadequate, but hey, it's a start.
> 
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

Applied.

I did miss the fdt_next_tag patch earlier.
These are not the droids you are looking for.
Move along.

jdl

^ permalink raw reply

* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:00 UTC (permalink / raw)
  To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F52ED.10007@freescale.com>

On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
> > Is this consensus on how the tree should look?
> >
> > There is no attempt to describe the codec connections inside the
> > device tree.
>
> I don't think I agree with that.  The device tree should indicate which codec is
> connected to which I2S/AC97 device.

What I meant was that there is no attempt to describe how the codec is
connected to the external world. Those connections are described in
the fabric driver.

I'm getting conflicting opinions on how the devices should be linked
into the tree. We should pick one and add it to the documentation.

The DTC experts need to tell us which way to make the pointers between
i2s and i2c for the codec.  Here's a another way it could be done that
looks more like the ac97 model.

i2s@2000 {           // PSC1
     compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
     cell-index = <0>;
     reg = <2000 100>;
     interrupts = <2 1 0>;
     interrupt-parent = <&mpc5200_pic>;
     codec0: i2s-codec@0 {
           compatible = "ti,tas5508";
           reg = <0>;
           i2c-handle = <&i2c@3d00>;
     };
     codec1: i2s-codec@1 {
           compatible = "ti,tas5508";
           reg = <1>;
           i2c-handle = <&i2c@3d00>;
     };
};

i2s@2200 {           // PSC2
     compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
     cell-index = <1>;
     reg = <2200 100>;
     interrupts = <2 2 0>;
     interrupt-parent = <&mpc5200_pic>;
     codec2: i2s-codec@2 {
           compatible = "wolson,wm8750";
           reg = <2>;
           i2c-handle = <&i2c@3d00>;
     };
};

i2c@3d00 {
     compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
     #address-cells = <1>;
     #size-cells = <0>;
     cell-index = <0>;
     reg = <3d00 40>;
     interrupts = <2 f 0>;
     interrupt-parent = <&mpc5200_pic>;
     fsl5200-clocking;
}

----- or would this be better? ---------------------

i2s@2000 {           // PSC1
     compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
     cell-index = <0>;
     reg = <2000 100>;
     interrupts = <2 1 0>;
     interrupt-parent = <&mpc5200_pic>;
     i2s-codec@0 {
           compatible = "ti,tas5508";
           reg = <0>;
     };
     i2s-codec@1 {
           compatible = "ti,tas5508";
           reg = <1>;
     };
};

i2s@2200 {           // PSC2
     compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
     cell-index = <1>;
     reg = <2200 100>;
     interrupts = <2 2 0>;
     interrupt-parent = <&mpc5200_pic>;
     i2s-codec@2 {
           compatible = "wolson,wm8750";
           reg = <2>;
     };
};

i2c@3d00 {
     compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
     #address-cells = <1>;
     #size-cells = <0>;
     cell-index = <0>;
     reg = <3d00 40>;
     interrupts = <2 f 0>;
     interrupt-parent = <&mpc5200_pic>;
     fsl5200-clocking;
     i2c-handle = <&i2s-codec@0 &i2s-codec@1 &i2s-codec@2>
}



>
> I see that you do that for the AC97 node, but not the I2S node.  Why?
>
> > I'm still not clear on how to trigger the load of the fabric driver.
> > Right now I have a single kernel that works on Efika and my target
> > hardware.  This gets sorted out by define_machine(xxxx). I'll write
> > some code tonight to figure out how to load drivers and match on
> > codec0, codec1, etc. But how do I probe for the fabric driver I need
> > to figure out whether to load the Efika one or my target one.
>
> I've been struggling with that one, too.  To keep it simple, I have the fabric
> driver just search for all the I2S nodes in my tree, and create ASoC objects for
> each one it finds.  There's some hackery there, but I don't think we need to
> solve all the problems at once.  The only thing that *has* to be right the first
> time is the device tree.
>
> > i2s@2200 {           // PSC2
> >       compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> >       cell-index = <1>;
> >       reg = <2200 100>;
> >       interrupts = <2 2 0>;
> >       interrupt-parent = <&mpc5200_pic>;
> > };
> >
> > i2c@3d00 {
> >       compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> >       cell-index = <0>;
> >       reg = <3d00 40>;
> >       interrupts = <2 f 0>;
> >       interrupt-parent = <&mpc5200_pic>;
> >       fsl5200-clocking;
> >
> >       codec0: i2s-codec@0 {
> >             compatible = "ti,tas5508";
> >             reg = <0>;
> >             i2s-handle = <&i2s@2000>;
> >       };
>
> I'd do this the other way around -- that is:
>
> i2s@2200 {           // PSC2
>         compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
>         ...
>         i2c-handle = <&codec0>;  /* Or something like that */
> };
>
> The reason is because I think the I2S driver will be instantiated *first* as an
> I2S driver and then it will create the I2C instantiation.
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 15:07 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710240800y24952e70g8c318e35e2e45e2e@mail.gmail.com>

Jon Smirl wrote:

> What I meant was that there is no attempt to describe how the codec is
> connected to the external world. Those connections are described in
> the fabric driver.

Hmmm, I'm not sure I'm okay with that.  We can always add properties to those 
nodes if it's necessary.  However, now you're basically defining some parts of 
the board layout in the DTS, and some parts in the fabric driver.  On PowerPC 
platforms, the fabric driver is supposed to get board layout information from 
the device tree.

> I'm getting conflicting opinions on how the devices should be linked
> into the tree. We should pick one and add it to the documentation.

It's a battle of wills!

> The DTC experts need to tell us which way to make the pointers between
> i2s and i2c for the codec.  Here's a another way it could be done that
> looks more like the ac97 model.
> 
> i2s@2000 {           // PSC1
>      compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
>      cell-index = <0>;
>      reg = <2000 100>;
>      interrupts = <2 1 0>;
>      interrupt-parent = <&mpc5200_pic>;
>      codec0: i2s-codec@0 {
>            compatible = "ti,tas5508";
>            reg = <0>;
>            i2c-handle = <&i2c@3d00>;
>      };
>      codec1: i2s-codec@1 {
>            compatible = "ti,tas5508";
>            reg = <1>;
>            i2c-handle = <&i2c@3d00>;
>      };
> };
> 
> i2s@2200 {           // PSC2
>      compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
>      cell-index = <1>;
>      reg = <2200 100>;
>      interrupts = <2 2 0>;
>      interrupt-parent = <&mpc5200_pic>;
>      codec2: i2s-codec@2 {

This should probably be codec0, since it's the first code on this I2S bus.

>            compatible = "wolson,wm8750";
>            reg = <2>;
>            i2c-handle = <&i2c@3d00>;
>      };
> };
> 
> i2c@3d00 {
>      compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
>      #address-cells = <1>;
>      #size-cells = <0>;
>      cell-index = <0>;
>      reg = <3d00 40>;
>      interrupts = <2 f 0>;
>      interrupt-parent = <&mpc5200_pic>;
>      fsl5200-clocking;
> }

My vote is for this version.  In fact, I think it *has* to be this way.  If 
you're using a CS4270 codec (as I am), the I2C interface is *optional*.  So I 
want the I2S node to point to the I2C node if it exists.

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:08 UTC (permalink / raw)
  To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F52ED.10007@freescale.com>

On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> >       codec0: i2s-codec@0 {
> >             compatible = "ti,tas5508";
> >             reg = <0>;
> >             i2s-handle = <&i2s@2000>;
> >       };
>
> I'd do this the other way around -- that is:
>
> i2s@2200 {           // PSC2
>         compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
>         ...
>         i2c-handle = <&codec0>;  /* Or something like that */

i2c-handle is a poor property name here.  It should be 'codec-handle'.
 The codec could theoretically live on just about *any* control bus;
not just i2c.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:16 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240800y24952e70g8c318e35e2e45e2e@mail.gmail.com>

On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> > Jon Smirl wrote:
> > > Is this consensus on how the tree should look?
> > >
> > > There is no attempt to describe the codec connections inside the
> > > device tree.
> >
> > I don't think I agree with that.  The device tree should indicate which codec is
> > connected to which I2S/AC97 device.
>
> What I meant was that there is no attempt to describe how the codec is
> connected to the external world. Those connections are described in
> the fabric driver.
>
> I'm getting conflicting opinions on how the devices should be linked
> into the tree. We should pick one and add it to the documentation.

Two valid methods have been proposed
1. a codec-

> The DTC experts need to tell us which way to make the pointers between
> i2s and i2c for the codec.  Here's a another way it could be done that
> looks more like the ac97 model.

I *really* don't think this is a good idea.  Put the node on the bus
that the device is addressed from.  I2S is the *data* path, not the
*control* path, but you cannot control the codec from there.

Your suggestion only looks more like the AC97 model if you're looking
at the data path.  If you're looking at the control path it looks
completely different.  The device tree convention is to orient around
the control path.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:19 UTC (permalink / raw)
  To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240808r5d634905t6ba81c802e8f123a@mail.gmail.com>

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> > >       codec0: i2s-codec@0 {
> > >             compatible = "ti,tas5508";
> > >             reg = <0>;
> > >             i2s-handle = <&i2s@2000>;
> > >       };
> >
> > I'd do this the other way around -- that is:
> >
> > i2s@2200 {           // PSC2
> >         compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> >         ...
> >         i2c-handle = <&codec0>;  /* Or something like that */
>
> i2c-handle is a poor property name here.  It should be 'codec-handle'.
>  The codec could theoretically live on just about *any* control bus;
> not just i2c.

That's one of the reasons I put the second option in the post.

In the second option the i2s driver would instantiate first. Next the
generic code would get loaded. The generic codec will know the control
but for the device and it can go look in the i2c node for the address.
i2c node still lists all of the devices on the i2c bus. But the codecs
are in the i2c-handle property so they don't trigger a second loading
of the codec.

A fundamental question is, which bus should trigger the loading of the
generic codec driver. The answer to this determines how the device
tree should look.

I'm using the model that a child node means load the driver and a
reference does not load a driver.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:20 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240816l6187b559l31fb72656ec265c@mail.gmail.com>

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> > > Jon Smirl wrote:
> > > > Is this consensus on how the tree should look?
> > > >
> > > > There is no attempt to describe the codec connections inside the
> > > > device tree.
> > >
> > > I don't think I agree with that.  The device tree should indicate which codec is
> > > connected to which I2S/AC97 device.
> >
> > What I meant was that there is no attempt to describe how the codec is
> > connected to the external world. Those connections are described in
> > the fabric driver.
> >
> > I'm getting conflicting opinions on how the devices should be linked
> > into the tree. We should pick one and add it to the documentation.
>
> Two valid methods have been proposed
> 1. a codec-

oops

1. a codec-handle property in the i2s node
2. an i2s-handle property in the codec node

Either are reasonable.  I prefer putting the handle in the i2s node;
but I'm looking at it from the way that ethernet phys are being
described currently.  The other is also perfectly valid.

I suppose it depends on what point of view you see the system from; either:
a. the codec is supported by the i2s bus, in which case use the
i2s-handle property
b. the i2s bus is supported by the codec; in which case use the
codec-handle property.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:23 UTC (permalink / raw)
  To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240816l6187b559l31fb72656ec265c@mail.gmail.com>

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > The DTC experts need to tell us which way to make the pointers between
> > i2s and i2c for the codec.  Here's a another way it could be done that
> > looks more like the ac97 model.
>
> I *really* don't think this is a good idea.  Put the node on the bus
> that the device is addressed from.  I2S is the *data* path, not the
> *control* path, but you cannot control the codec from there.
>
> Your suggestion only looks more like the AC97 model if you're looking
> at the data path.  If you're looking at the control path it looks
> completely different.  The device tree convention is to orient around
> the control path.

It doesn't make any difference to me which one we pick. I'm just
listing all of the possible combinations. I just want to pick a model
so that we can write the code.

I see your point about putting the child node onto the control bus.
ac97 is both a control and data bus. For the i2s case the child should
go onto the i2c bus.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:28 UTC (permalink / raw)
  To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240820l62d5a50ewcd7707fed8f9176f@mail.gmail.com>

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Two valid methods have been proposed
> > 1. a codec-
>
> oops
>
> 1. a codec-handle property in the i2s node
> 2. an i2s-handle property in the codec node
>
> Either are reasonable.  I prefer putting the handle in the i2s node;
> but I'm looking at it from the way that ethernet phys are being
> described currently.  The other is also perfectly valid.
>
> I suppose it depends on what point of view you see the system from; either:
> a. the codec is supported by the i2s bus, in which case use the
> i2s-handle property
> b. the i2s bus is supported by the codec; in which case use the
> codec-handle property.

Do you want to pick one and add it to the device tree documentation
with an example for i2s and ac97? I'll use which ever one is picked.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:28 UTC (permalink / raw)
  To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F5FC4.1040804@freescale.com>

On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > What I meant was that there is no attempt to describe how the codec is
> > connected to the external world. Those connections are described in
> > the fabric driver.
>
> Hmmm, I'm not sure I'm okay with that.  We can always add properties to those
> nodes if it's necessary.  However, now you're basically defining some parts of
> the board layout in the DTS, and some parts in the fabric driver.  On PowerPC
> platforms, the fabric driver is supposed to get board layout information from
> the device tree.

No, not always; if the description is too complex (like gpio's for
instance) then it is perfectly valid to build the knowledge into the
platform code.  It should be avoided; but the device tree doesn't need
to describe *everything*.

>
> > i2s@2200 {           // PSC2
> >      compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
> >      cell-index = <1>;
> >      reg = <2200 100>;
> >      interrupts = <2 2 0>;
> >      interrupt-parent = <&mpc5200_pic>;
> >      codec2: i2s-codec@2 {
>
> This should probably be codec0, since it's the first code on this I2S bus.
>
> >            compatible = "wolson,wm8750";
> >            reg = <2>;
> >            i2c-handle = <&i2c@3d00>;
> >      };
> > };
> >
> > i2c@3d00 {
> >      compatible = "fsl,mpc5200b-i2c", "fsl,mpc5200-i2c", "fsl-i2c";
> >      #address-cells = <1>;
> >      #size-cells = <0>;
> >      cell-index = <0>;
> >      reg = <3d00 40>;
> >      interrupts = <2 f 0>;
> >      interrupt-parent = <&mpc5200_pic>;
> >      fsl5200-clocking;
> > }
>
> My vote is for this version.  In fact, I think it *has* to be this way.  If
> you're using a CS4270 codec (as I am), the I2C interface is *optional*.  So I
> want the I2S node to point to the I2C node if it exists.

It doesn't have to be this way.  If the codec does not have a control
interface, then it can happily be a child of the i2s node.  But if it
*does*; don't break convention by separating it from it's control
interface.

I strongly recommend following the lead of ethernet phys and mdio busses here.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 15:40 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710240823v2022661ftb1b754a86cab88f3@mail.gmail.com>

Jon Smirl wrote:

> I see your point about putting the child node onto the control bus.
> ac97 is both a control and data bus. For the i2s case the child should
> go onto the i2c bus.

I know AC97 is *also* a control bus, but treating I2S and AC97 differently is 
bad, IMHO.  If you're going to put the child node in the AC97 node, you should 
also put it in the I2S node.

The 8610 has an SSI that can operate as either AC97 or I2S.  If I want to switch 
from AC97 to I2S, I should not have to move the child node out of the AC97 node. 
  I should instead just add an I2C node and point to it.

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:43 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <9e4733910710240828x412f598dy7fc4a75faa76358d@mail.gmail.com>

On 10/24/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Two valid methods have been proposed
> > > 1. a codec-
> >
> > oops
> >
> > 1. a codec-handle property in the i2s node
> > 2. an i2s-handle property in the codec node
> >
> > Either are reasonable.  I prefer putting the handle in the i2s node;
> > but I'm looking at it from the way that ethernet phys are being
> > described currently.  The other is also perfectly valid.
> >
> > I suppose it depends on what point of view you see the system from; either:
> > a. the codec is supported by the i2s bus, in which case use the
> > i2s-handle property
> > b. the i2s bus is supported by the codec; in which case use the
> > codec-handle property.
>
> Do you want to pick one and add it to the device tree documentation
> with an example for i2s and ac97? I'll use which ever one is picked.

Sure, I'll draft something up and post it for review.

On the device probing front; what about this method:

Rather than trying to figure things out from the board model, or the
combination of the codec and i2s bus; add another node to represent
the sound circuit.  All that node would need is a unique compatible
property and a phandle to either the i2s bus or the codec (depending
on which binding approach is used).  It could have additional
properties to represent optional features, etc.

For example:
sound@0 {
      compatible = "<mfg>,<board>,sound"   // The board might have
more than one sound i/f which could be wired differently
      codec-handle = <&codec0>;
};

This would give your fabric driver something unique to probe on; but
the i2c, i2s and codec nodes which actually describe interconnects
will still be present.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [patch v3] Cell: Wrap master run control bit
From: Geert Uytterhoeven @ 2007-10-24 15:53 UTC (permalink / raw)
  To: Jeremy Kerr
  Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Arnd Bergmann,
	Cell Broadband Engine OSS Development
In-Reply-To: <46F6D188.7090201@am.sony.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 9828 bytes --]

On Sun, 23 Sep 2007, Geoff Levand wrote:
> Subject: Cell: Wrap master run control bit
> 
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> 
> Add platform specific SPU run control routines to the spufs.  The current
> spufs implementation uses the SPU master run control bit (MFC_SR1[S]) to
> control SPE execution, but the PS3 hypervisor does not support the use of
> this feature.
> 
> This change adds the run control wrapper routies spu_enable_spu() and
> spu_disable_spu().  The bare metal routines use the master run control
> bit, and the PS3 specific routines use the priv2 run control register.
> 
> An outstanding enhancement for the PS3 would be to add a guard to check
> for incorrect access to the spu problem state when the spu context is
> disabled.  This check could be implemented with a flag added to the spu
> context that would inhibit mapping problem state pages, and a routine
> to unmap spu problem state pages.  When the spu is enabled with
> ps3_enable_spu() the flag would be set allowing pages to be mapped,
> and when the spu is disabled with ps3_disable_spu() the flag would be
> cleared and mapped problem state pages would be unmapped.
> 
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> 
> Jeremy,
> 
> Here is an updated version for 2.6.24.  Noguchi-san will

As 2.6.24-rc1 is out and Geoff is offline: what's the status of this patch?

> work on the LS unmapping feature for 2.6.25.
> 
> -Geoff
> 
> v2:
>  o Added comments about unmapping PS pages when disabled.
> v3:
>  o Changed routines to return void instead of int.
>  o Rebased to apply to Jeremy's 2.6.23-rc work-around.
> 
>  arch/powerpc/platforms/cell/spu_manage.c        |   13 +++++++++++
>  arch/powerpc/platforms/cell/spufs/backing_ops.c |    6 +++++
>  arch/powerpc/platforms/cell/spufs/hw_ops.c      |   10 ++++++++
>  arch/powerpc/platforms/cell/spufs/run.c         |    4 +--
>  arch/powerpc/platforms/cell/spufs/spufs.h       |    1 
>  arch/powerpc/platforms/ps3/spu.c                |   27 ++++++++++++++++++++++--
>  include/asm-powerpc/spu_priv1.h                 |   15 +++++++++++++
>  7 files changed, 72 insertions(+), 4 deletions(-)
> 
> --- a/arch/powerpc/platforms/cell/spu_manage.c
> +++ b/arch/powerpc/platforms/cell/spu_manage.c
> @@ -35,6 +35,7 @@
>  #include <asm/firmware.h>
>  #include <asm/prom.h>
>  
> +#include "spufs/spufs.h"
>  #include "interrupt.h"
>  
>  struct device_node *spu_devnode(struct spu *spu)
> @@ -369,6 +370,16 @@ static int of_destroy_spu(struct spu *sp
>  	return 0;
>  }
>  
> +static void enable_spu_by_master_run(struct spu_context *ctx)
> +{
> +	ctx->ops->master_start(ctx);
> +}
> +
> +static void disable_spu_by_master_run(struct spu_context *ctx)
> +{
> +	ctx->ops->master_stop(ctx);
> +}
> +
>  /* Hardcoded affinity idxs for qs20 */
>  #define QS20_SPES_PER_BE 8
>  static int qs20_reg_idxs[QS20_SPES_PER_BE] =   { 0, 2, 4, 6, 7, 5, 3, 1 };
> @@ -535,5 +546,7 @@ const struct spu_management_ops spu_mana
>  	.enumerate_spus = of_enumerate_spus,
>  	.create_spu = of_create_spu,
>  	.destroy_spu = of_destroy_spu,
> +	.enable_spu = enable_spu_by_master_run,
> +	.disable_spu = disable_spu_by_master_run,
>  	.init_affinity = init_affinity,
>  };
> --- a/arch/powerpc/platforms/cell/spufs/backing_ops.c
> +++ b/arch/powerpc/platforms/cell/spufs/backing_ops.c
> @@ -285,6 +285,11 @@ static void spu_backing_runcntl_write(st
>  	spin_unlock(&ctx->csa.register_lock);
>  }
>  
> +static void spu_backing_runcntl_stop(struct spu_context *ctx)
> +{
> +	spu_backing_runcntl_write(ctx, SPU_RUNCNTL_STOP);
> +}
> +
>  static void spu_backing_master_start(struct spu_context *ctx)
>  {
>  	struct spu_state *csa = &ctx->csa;
> @@ -381,6 +386,7 @@ struct spu_context_ops spu_backing_ops =
>  	.get_ls = spu_backing_get_ls,
>  	.runcntl_read = spu_backing_runcntl_read,
>  	.runcntl_write = spu_backing_runcntl_write,
> +	.runcntl_stop = spu_backing_runcntl_stop,
>  	.master_start = spu_backing_master_start,
>  	.master_stop = spu_backing_master_stop,
>  	.set_mfc_query = spu_backing_set_mfc_query,
> --- a/arch/powerpc/platforms/cell/spufs/hw_ops.c
> +++ b/arch/powerpc/platforms/cell/spufs/hw_ops.c
> @@ -220,6 +220,15 @@ static void spu_hw_runcntl_write(struct 
>  	spin_unlock_irq(&ctx->spu->register_lock);
>  }
>  
> +static void spu_hw_runcntl_stop(struct spu_context *ctx)
> +{
> +	spin_lock_irq(&ctx->spu->register_lock);
> +	out_be32(&ctx->spu->problem->spu_runcntl_RW, SPU_RUNCNTL_STOP);
> +	while (in_be32(&ctx->spu->problem->spu_status_R) & SPU_STATUS_RUNNING)
> +		cpu_relax();
> +	spin_unlock_irq(&ctx->spu->register_lock);
> +}
> +
>  static void spu_hw_master_start(struct spu_context *ctx)
>  {
>  	struct spu *spu = ctx->spu;
> @@ -321,6 +330,7 @@ struct spu_context_ops spu_hw_ops = {
>  	.get_ls = spu_hw_get_ls,
>  	.runcntl_read = spu_hw_runcntl_read,
>  	.runcntl_write = spu_hw_runcntl_write,
> +	.runcntl_stop = spu_hw_runcntl_stop,
>  	.master_start = spu_hw_master_start,
>  	.master_stop = spu_hw_master_stop,
>  	.set_mfc_query = spu_hw_set_mfc_query,
> --- a/arch/powerpc/platforms/cell/spufs/run.c
> +++ b/arch/powerpc/platforms/cell/spufs/run.c
> @@ -302,7 +302,7 @@ long spufs_run_spu(struct spu_context *c
>  	if (mutex_lock_interruptible(&ctx->run_mutex))
>  		return -ERESTARTSYS;
>  
> -	ctx->ops->master_start(ctx);
> +	spu_enable_spu(ctx);
>  	ctx->event_return = 0;
>  
>  	spu_acquire(ctx);
> @@ -376,7 +376,7 @@ long spufs_run_spu(struct spu_context *c
>  		ctx->stats.libassist++;
>  
>  
> -	ctx->ops->master_stop(ctx);
> +	spu_disable_spu(ctx);
>  	ret = spu_run_fini(ctx, npc, &status);
>  	spu_yield(ctx);
>  
> --- a/arch/powerpc/platforms/cell/spufs/spufs.h
> +++ b/arch/powerpc/platforms/cell/spufs/spufs.h
> @@ -170,6 +170,7 @@ struct spu_context_ops {
>  	char*(*get_ls) (struct spu_context * ctx);
>  	 u32 (*runcntl_read) (struct spu_context * ctx);
>  	void (*runcntl_write) (struct spu_context * ctx, u32 data);
> +	void (*runcntl_stop) (struct spu_context * ctx);
>  	void (*master_start) (struct spu_context * ctx);
>  	void (*master_stop) (struct spu_context * ctx);
>  	int (*set_mfc_query)(struct spu_context * ctx, u32 mask, u32 mode);
> --- a/arch/powerpc/platforms/ps3/spu.c
> +++ b/arch/powerpc/platforms/ps3/spu.c
> @@ -28,6 +28,7 @@
>  #include <asm/spu_priv1.h>
>  #include <asm/lv1call.h>
>  
> +#include "../cell/spufs/spufs.h"
>  #include "platform.h"
>  
>  /* spu_management_ops */
> @@ -419,10 +420,34 @@ static int ps3_init_affinity(void)
>  	return 0;
>  }
>  
> +/**
> + * ps3_enable_spu - Enable SPU run control.
> + *
> + * An outstanding enhancement for the PS3 would be to add a guard to check
> + * for incorrect access to the spu problem state when the spu context is
> + * disabled.  This check could be implemented with a flag added to the spu
> + * context that would inhibit mapping problem state pages, and a routine
> + * to unmap spu problem state pages.  When the spu is enabled with
> + * ps3_enable_spu() the flag would be set allowing pages to be mapped,
> + * and when the spu is disabled with ps3_disable_spu() the flag would be
> + * cleared and the mapped problem state pages would be unmapped.
> + */
> +
> +static void ps3_enable_spu(struct spu_context *ctx)
> +{
> +}
> +
> +static void ps3_disable_spu(struct spu_context *ctx)
> +{
> +	ctx->ops->runcntl_stop(ctx);
> +}
> +
>  const struct spu_management_ops spu_management_ps3_ops = {
>  	.enumerate_spus = ps3_enumerate_spus,
>  	.create_spu = ps3_create_spu,
>  	.destroy_spu = ps3_destroy_spu,
> +	.enable_spu = ps3_enable_spu,
> +	.disable_spu = ps3_disable_spu,
>  	.init_affinity = ps3_init_affinity,
>  };
>  
> @@ -505,8 +530,6 @@ static void mfc_sr1_set(struct spu *spu,
>  	static const u64 allowed = ~(MFC_STATE1_LOCAL_STORAGE_DECODE_MASK
>  		| MFC_STATE1_PROBLEM_STATE_MASK);
>  
> -	sr1 |= MFC_STATE1_MASTER_RUN_CONTROL_MASK;
> -
>  	BUG_ON((sr1 & allowed) != (spu_pdata(spu)->cache.sr1 & allowed));
>  
>  	spu_pdata(spu)->cache.sr1 = sr1;
> --- a/include/asm-powerpc/spu_priv1.h
> +++ b/include/asm-powerpc/spu_priv1.h
> @@ -24,6 +24,7 @@
>  #include <linux/types.h>
>  
>  struct spu;
> +struct spu_context;
>  
>  /* access to priv1 registers */
>  
> @@ -178,6 +179,8 @@ struct spu_management_ops {
>  	int (*enumerate_spus)(int (*fn)(void *data));
>  	int (*create_spu)(struct spu *spu, void *data);
>  	int (*destroy_spu)(struct spu *spu);
> +	void (*enable_spu)(struct spu_context *ctx);
> +	void (*disable_spu)(struct spu_context *ctx);
>  	int (*init_affinity)(void);
>  };
>  
> @@ -207,6 +210,18 @@ spu_init_affinity (void)
>  	return spu_management_ops->init_affinity();
>  }
>  
> +static inline void
> +spu_enable_spu (struct spu_context *ctx)
> +{
> +	spu_management_ops->enable_spu(ctx);
> +}
> +
> +static inline void
> +spu_disable_spu (struct spu_context *ctx)
> +{
> +	spu_management_ops->disable_spu(ctx);
> +}
> +
>  /*
>   * The declarations folowing are put here for convenience
>   * and only intended to be used by the platform setup code.
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* Re: Audio codec device tree entries
From: Grant Likely @ 2007-10-24 15:54 UTC (permalink / raw)
  To: Timur Tabi; +Cc: PowerPC dev list
In-Reply-To: <471F6761.3030405@freescale.com>

On 10/24/07, Timur Tabi <timur@freescale.com> wrote:
> Jon Smirl wrote:
>
> > I see your point about putting the child node onto the control bus.
> > ac97 is both a control and data bus. For the i2s case the child should
> > go onto the i2c bus.
>
> I know AC97 is *also* a control bus, but treating I2S and AC97 differently is
> bad, IMHO.  If you're going to put the child node in the AC97 node, you should
> also put it in the I2S node.

They *are* different.  The choice you're making is whether or not you
keep them similar in the control path or the data path; but you still
have to choose.

>
> The 8610 has an SSI that can operate as either AC97 or I2S.  If I want to switch
> from AC97 to I2S, I should not have to move the child node out of the AC97 node.
>   I should instead just add an I2C node and point to it.

But you need a different codec node regardless.  The board/system will
in the vast majority of cases designed to only use AC97 or only use
I2S.  It's not moving a node.  It's deleting an ac97 codec node and
adding an i2s codec node.

Besides; correctness is more important that how many device tree
changes need to be made to go from one board design to another.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: Audio codec device tree entries
From: Jon Smirl @ 2007-10-24 15:54 UTC (permalink / raw)
  To: Grant Likely; +Cc: PowerPC dev list, Timur Tabi
In-Reply-To: <fa686aa40710240843r5271c749m33bce043702603b7@mail.gmail.com>

On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > Do you want to pick one and add it to the device tree documentation
> > with an example for i2s and ac97? I'll use which ever one is picked.
>
> Sure, I'll draft something up and post it for review.
>
> On the device probing front; what about this method:
>
> Rather than trying to figure things out from the board model, or the
> combination of the codec and i2s bus; add another node to represent
> the sound circuit.  All that node would need is a unique compatible
> property and a phandle to either the i2s bus or the codec (depending
> on which binding approach is used).  It could have additional
> properties to represent optional features, etc.

That's the pseudo-sound node proposal that other people objected to.

It makes sense to me, there needs to be some way to trigger loading
the fabric driver.

>
> For example:
> sound@0 {
>       compatible = "<mfg>,<board>,sound"   // The board might have
> more than one sound i/f which could be wired differently
>       codec-handle = <&codec0>;
> };

Do you even need the parameters,  how about simply this?

sound-fabric {
};

That will trigger loading all of the sound-fabric drivers built into
the kernel. In their probe functions they can look in the device tree
and extract the machine name and then decide to stay loaded or fail
the probe.

> This would give your fabric driver something unique to probe on; but
> the i2c, i2s and codec nodes which actually describe interconnects
> will still be present.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: Audio codec device tree entries
From: Timur Tabi @ 2007-10-24 16:01 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710240854y6ac115b6i5e0400eb369fcf7@mail.gmail.com>

Jon Smirl wrote:

> It makes sense to me, there needs to be some way to trigger loading
> the fabric driver.

Well, you only really two have choices:

1) Probe on the AC97/SSI nodes
2) When the driver initializes, just scan all the nodes in the device tree (no 
probing).

I think option #2 makes the most sense, because option #1 says that your fabric 
driver is really an AC97 driver, which it isn't.

You can try to make the fabric driver into a bus driver, but I think that just 
complicates things.

^ permalink raw reply

* Re: linux-2.6.git: cannot build PS3 image
From: Geert Uytterhoeven @ 2007-10-24 16:26 UTC (permalink / raw)
  To: Scott Wood; +Cc: Linux/PPC Development
In-Reply-To: <47162BC4.2090907@freescale.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1929 bytes --]

On Wed, 17 Oct 2007, Scott Wood wrote:
> Geert Uytterhoeven wrote:
> >> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
> >> index 39b27e5..795f988 100755
> >> --- a/arch/powerpc/boot/wrapper
> >> +++ b/arch/powerpc/boot/wrapper
> >> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
> >>  entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
> >>  
> >>  if [ -n "$binary" ]; then
> >> -    mv "$ofile" "$ofile".elf
> >> +    cp "$ofile" "$ofile".elf
> >>      ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
> >>  fi
> > 
> > No comments?
> 
> That'd work in this case, though it'd probably be better to make the 
> $ofile be the end result that will boot on the ps3, and leave a suffix 
> on the intermediate files.

The $ofile is the end result to boot using kboot (2nd stage kernel).
otheros.bld is the end result to write to FLASH ROM (1st stage kernel).

The funny thing is that we pass `-o arch/powerpc/boot/zImage.ps3' to the
wrapper script (which indicates the _output_ file, i.e. $ofile, as per the
documentation at the top of the wrapper script), while this output file is
no longer created by the wrapper script!
Instead it creates arch/powerpc/boot/zImage.ps3.elf.

So I do think your change broke the expected and obvious behavior.

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

^ permalink raw reply

* [PATCH 0/2] USB: Rework OHCI PPC OF driver to support new bindings
From: Valentine Barshak @ 2007-10-24 16:22 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: tnt, linux-usb-devel

These patches update ohci-ppc-of and the dts files for the new bindings.
The "compatible" is set to "usb-ohci" and the "big-endian" quirkiness is 
expressed by a property, not by the "compatible" name.
Also user-selectable USB_OHCI_HCD_PPC_OF_BE/USB_OHCI_HCD_PPC_OF_LE config
options are removed, since the USB_OHCI_BIG_ENDIAN/USB_OHCI_LITTLE_ENDIAN
selection is made by default for PPC/PCI OHCI controllers.

^ permalink raw reply

* [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-10-24 16:34 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: tnt, linux-usb-devel
In-Reply-To: <20071024162223.GA17649@ru.mvista.com>

Rework ohci-ppc-of driver to use big-endian property instead of
ohci-be/ohci-le compatible strings. Also remove unnecessary
user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 drivers/usb/host/Kconfig       |   17 +++--------------
 drivers/usb/host/ohci-ppc-of.c |   38 ++++++--------------------------------
 2 files changed, 9 insertions(+), 46 deletions(-)

diff -pruN linux-2.6.orig/drivers/usb/host/Kconfig linux-2.6/drivers/usb/host/Kconfig
--- linux-2.6.orig/drivers/usb/host/Kconfig	2007-10-24 18:44:25.000000000 +0400
+++ linux-2.6/drivers/usb/host/Kconfig	2007-10-24 19:37:18.000000000 +0400
@@ -128,23 +128,12 @@ config USB_OHCI_HCD_PPC_OF
 	bool "OHCI support for PPC USB controller on OF platform bus"
 	depends on USB_OHCI_HCD && PPC_OF
 	default y
+	select USB_OHCI_BIG_ENDIAN_DESC
+	select USB_OHCI_BIG_ENDIAN_MMIO
 	---help---
 	  Enables support for the USB controller PowerPC present on the
 	  OpenFirmware platform bus.
 
-config USB_OHCI_HCD_PPC_OF_BE
-	bool "Support big endian HC"
-	depends on USB_OHCI_HCD_PPC_OF
-	default y
-	select USB_OHCI_BIG_ENDIAN_DESC
-	select USB_OHCI_BIG_ENDIAN_MMIO
-
-config USB_OHCI_HCD_PPC_OF_LE
-	bool "Support little endian HC"
-	depends on USB_OHCI_HCD_PPC_OF
-	default n
-	select USB_OHCI_LITTLE_ENDIAN
-
 config USB_OHCI_HCD_PCI
 	bool "OHCI support for PCI-bus USB controllers"
 	depends on USB_OHCI_HCD && PCI && (STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF)
@@ -180,7 +169,7 @@ config USB_OHCI_BIG_ENDIAN_MMIO
 config USB_OHCI_LITTLE_ENDIAN
 	bool
 	depends on USB_OHCI_HCD
-	default n if STB03xxx || PPC_MPC52xx
+	default n if STB03xxx || PPC_MPC52xx || USB_OHCI_HCD_PPC_OF
 	default y
 
 config USB_UHCI_HCD
diff -pruN linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c linux-2.6/drivers/usb/host/ohci-ppc-of.c
--- linux-2.6.orig/drivers/usb/host/ohci-ppc-of.c	2007-10-24 18:44:25.000000000 +0400
+++ linux-2.6/drivers/usb/host/ohci-ppc-of.c	2007-10-24 19:32:21.000000000 +0400
@@ -15,8 +15,8 @@
 
 #include <linux/signal.h>
 
-#include <asm/of_platform.h>
-#include <asm/prom.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
 
 
 static int __devinit
@@ -91,15 +91,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
 	int irq;
 
 	int rv;
-	int is_bigendian;
 
 	if (usb_disabled())
 		return -ENODEV;
 
-	is_bigendian =
-		of_device_is_compatible(dn, "ohci-bigendian") ||
-		of_device_is_compatible(dn, "ohci-be");
-
 	dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
 
 	rv = of_address_to_resource(dn, 0, &res);
@@ -134,9 +129,10 @@ ohci_hcd_ppc_of_probe(struct of_device *
 	}
 
 	ohci = hcd_to_ohci(hcd);
-	if (is_bigendian) {
+
+	if (of_get_property(dn, "big-endian", NULL)) {
 		ohci->flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
-		if (of_device_is_compatible(dn, "mpc5200-ohci"))
+		if (of_device_is_compatible(dn, "mpc5200-usb-ohci"))
 			ohci->flags |= OHCI_QUIRK_FRAME_NO;
 	}
 
@@ -187,35 +183,13 @@ static int ohci_hcd_ppc_of_shutdown(stru
 
 
 static struct of_device_id ohci_hcd_ppc_of_match[] = {
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_BE
-	{
-		.name = "usb",
-		.compatible = "ohci-bigendian",
-	},
-	{
-		.name = "usb",
-		.compatible = "ohci-be",
-	},
-#endif
-#ifdef CONFIG_USB_OHCI_HCD_PPC_OF_LE
-	{
-		.name = "usb",
-		.compatible = "ohci-littledian",
-	},
 	{
-		.name = "usb",
-		.compatible = "ohci-le",
+		.compatible = "usb-ohci",
 	},
-#endif
 	{},
 };
 MODULE_DEVICE_TABLE(of, ohci_hcd_ppc_of_match);
 
-#if	!defined(CONFIG_USB_OHCI_HCD_PPC_OF_BE) && \
-	!defined(CONFIG_USB_OHCI_HCD_PPC_OF_LE)
-#error "No endianess selected for ppc-of-ohci"
-#endif
-
 
 static struct of_platform_driver ohci_hcd_ppc_of_driver = {
 	.name		= "ppc-of-ohci",

^ permalink raw reply

* [PATCH 2/2] PowerPC: Update USB OHCI DTS entires for new bindings
From: Valentine Barshak @ 2007-10-24 16:35 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: tnt, linux-usb-devel
In-Reply-To: <20071024162223.GA17649@ru.mvista.com>

Adjust mpc52xx DTS entries to support reworked ohci-ppc-of driver.
Use compatible "usb-ohci" and an empty big-endian property for 
USB_OHCI_BIG_ENDIAN_DESC and USB_OHCI_BIG_ENDIAN_MMIO support.
This also adds OHCI DTS entry for Sequoia PowerPC 440EPx board.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/boot/dts/lite5200.dts  |    5 +++--
 arch/powerpc/boot/dts/lite5200b.dts |    5 +++--
 arch/powerpc/boot/dts/sequoia.dts   |    8 ++++++++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts linux-2.6/arch/powerpc/boot/dts/lite5200b.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200b.dts	2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200b.dts	2007-10-24 19:20:31.000000000 +0400
@@ -183,8 +183,9 @@
 		};
 
 		usb@1000 {
-			device_type = "usb-ohci-be";
-			compatible = "mpc5200b-ohci","mpc5200-ohci","ohci-be";
+			device_type = "usb-ohci";
+			compatible = "mpc5200b-usb-ohci","mpc5200-usb-ohci","usb-ohci";
+			big-endian;
 			reg = <1000 ff>;
 			interrupts = <2 6 0>;
 			interrupt-parent = <&mpc5200_pic>;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts linux-2.6/arch/powerpc/boot/dts/lite5200.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/lite5200.dts	2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/lite5200.dts	2007-10-24 19:21:57.000000000 +0400
@@ -183,8 +183,9 @@
 		};
 
 		usb@1000 {
-			device_type = "usb-ohci-be";
-			compatible = "mpc5200-ohci","ohci-be";
+			device_type = "usb-ohci";
+			compatible = "mpc5200-usb-ohci","usb-ohci";
+			big-endian;
 			reg = <1000 ff>;
 			interrupts = <2 6 0>;
 			interrupt-parent = <&mpc5200_pic>;
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts	2007-10-24 18:44:00.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts	2007-10-24 19:30:36.000000000 +0400
@@ -122,6 +122,14 @@
 			interrupt-map-mask = <ffffffff>;
 		};
 
+		USB1: usb@e0000400 {
+			compatible = "usb-ohci-440epx", "usb-ohci";
+			reg = <0 e0000400 60>;
+			big-endian;
+			interrupt-parent = <&UIC0>;
+			interrupts = <15 8>;
+		};
+
 		POB0: opb {
 		  	compatible = "ibm,opb-440epx", "ibm,opb";
 			#address-cells = <1>;

^ 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