Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Benjamin Herrenschmidt]

On Sun, 2009-05-24 at 00:47 -0600, Grant Likely wrote:
> Ilya, any comment on this?  Can a fix be made quickly, or should this
> patch be reverted until a more robust version can be crafted?
> 
> g.

Nasty...

We need to see if we can get the vmalloc allocator safe for GFP_ATOMIC
context, might be doable.

As for free, unfortunately, even the old allocator won't help with SMP,
since that needs to do IPIs for cross TLB invalidates.

Maybe we should enqueue free blocks and do the actual freeing from a
workqueue or something similar.

Cheers,
Ben.

> On Thu, May 21, 2009 at 10:50 AM, Albert Herranz
>  wrote:
> >
> > Hello list,
> >
> > Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA 
> > coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms.
> >
> > The problems seem to be that the new __dma_alloc_coherent() and 
> > __dma_free_coherent() implementations:
> >
> > - don't respect anymore the passed gfp flags (__dma_alloc_coherent() 
> > unconditionally uses GFP_KERNEL within the function irrespective of the 
> > caller flags)
> > - can't be used in interrupt context as they use 
> > get_vm_area_caller()/vfree() which end up triggering BUG_ON(in_interrupt())
> >
> > One victim happens to be the USB core subsystem which sometimes frees dma 
> > coherent memory in interrupt context for drivers flagged HCD_LOCAL_MEM.
> >
> > This has been experienced while writing a new EHCI driver for the Nintendo 
> > Wii platform.
> >
> > usb 1-1: new high speed USB device using ehci-mipc and address 2
> > [ cut here ]
> > kernel BUG at mm/vmalloc.c:1328!
> > Oops: Exception in kernel mode, sig: 5 [#1]
> > PREEMPT wii
> > Modules linked in:
> > NIP: c008ea20 LR: c0015890 CTR: c00111d4
> > REGS: d2c65b10 TRAP: 0700   Not tainted  
> > (2.6.30-rc2-isobel-wii-00092-gcba94db-dirty)
> > MSR: 00021032   CR: 42482028  XER: 
> > TASK = d2c600f0[28] 'kmmcd' THREAD: d2c64000
> > GPR00: 0001 d2c65bc0 d2c600f0 d403 d403 d403 12da1000 
> > 0001
> > GPR08:  d2c64000 0020  22482022 94fdfb98 6e1979bc 
> > c6bbdbdd
> > GPR16: 0020 00200200 00100100 d4020060 0001 d401c0ec 0001 
> > d401c0ec
> > GPR24: d2d9a6c0   d2f69de0 d2d9a600 d2f69e30 d2f69e2c 
> > d2da08e0
> > NIP [c008ea20] vfree+0xc/0x18
> > LR [c0015890] __dma_free_coherent+0x14/0x24
> > Call Trace:
> > [d2c65bc0] [c0017af8] __mipc_recv_req+0x160/0x178 (unreliable)
> > [d2c65bd0] [c00111ec] dma_direct_free_coherent+0x18/0x28
> > [d2c65be0] [c01cfca4] hcd_free_coherent+0x7c/0x12c
> > [d2c65c10] [c01d00b8] unmap_urb_for_dma+0x150/0x1cc
> > [d2c65c20] [c01d0174] usb_hcd_giveback_urb+0x40/0xe4
> > [d2c65c30] [c01df474] ehci_urb_done+0xf0/0x114
> > [d2c65c50] [c01e3870] qh_completions+0x41c/0x4dc
> > [d2c65ca0] [c01e44e0] scan_async+0x9c/0x1a0
> > [d2c65cc0] [c01e49ec] ehci_work+0x58/0xc4
> > [d2c65cd0] [c01e5424] ehci_irq+0x22c/0x230
> > [d2c65d00] [c01cfa88] usb_hcd_irq+0x50/0xa8
> > [d2c65d20] [c00597d8] handle_IRQ_event+0xdc/0x250
> > [d2c65d60] [c005ba20] handle_level_irq+0x9c/0x138
> > [d2c65d80] [c001cbc8] hollywood_pic_irq_cascade+0x7c/0xf8
> > [d2c65da0] [c00064b4] do_IRQ+0x9c/0xc4
> > [d2c65dc0] [c0011fb8] ret_from_except+0x0/0x14
> >
> > Any comments on how to address this issue (other than reverting the above 
> > mentioned commit, which fixes it) are welcome.
> >
> > Thanks,
> > Albert
> >
> >
> >
> >
> > ___
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> 
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 3/9] Rename the PSC functions to DMA

[Mark Brown]

On Sat, May 23, 2009 at 07:13:01PM -0400, Jon Smirl wrote:
> Rename the functions in the mpc5200 DMA file from i2s based names to dma ones 
> to reflect the file they are in.

I'm OK with both these refactoring patches if Grant is - Grant, if I
could get your ack I'd like to merge these as soon as possible since
they're very big changes and it'd cut down on review effort.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97

[Mark Brown]

On Sat, May 23, 2009 at 07:12:55PM -0400, Jon Smirl wrote:

[Jon, could you please fix the word wrapping in your MUA, there's none
at all which makes it more difficult than it needs to be to respond to
your e-mail.]

> Mark is not enthused about soc-of-simple.c so rather than extend it
> for AC97 I altered the drivers to not use it. Instead they use the old
> way of manually binding everything. Mark would like to see OF binding
> more closely integrated to the core. Once a proper solution for OF

I really don't feel that this reflects the issues I had with the code
well.  There are two basic issues here:

 - You had been trying to represent the AC97 CODEC drivers as platform
   devices which is not a good approach, largely since AC97 is a real
   bus and should be represented as such.

 - soc-of-simple really should be merged into the core now, there's no
   need to have to add changes to individual drivers any more since
   drivers are already regstering with the core.

These two points are basically unrelated except in that your motiviation
for doing the platform device thing was trying to fit your machine
drivers into the existing soc-of-simple framework.  It's the changes to
the cross-platform AC97 drivers that were causing real problems,
soc-of-simple is only an issue in that using it motivates these other
changes.

> binding is agreed upon it is easy to convert the existing drivers. A
> first step would be converting the existing codec drivers so that they
> can be dynamically loaded.

I'm not aware of any CODEC drivers which can't currently be built and
used as modules.  If you mean "load via the normal device model" then
yes, that'd be very good (and is in progress) but it's another issue and
as I explained last time AC97 poses particular problems there.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load

[Mark Brown]

On Sat, May 23, 2009 at 07:12:57PM -0400, Jon Smirl wrote:
> Register the wm9712 DAIs on module load

> Signed-off-by: Jon Smirl 

Why do you wish to do this - ASoC does not require or use DAI registration
for AC97 CODECs?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code

[Mark Brown]

On Sat, May 23, 2009 at 07:13:05PM -0400, Jon Smirl wrote:

This is all basically OK bearing in mind that I know nothing about the
hardware.  A couple of things, though:

> +/* -
> + * Sysfs attributes for debugging
> + */

These look like they may be better placed in debugfs?

> +EXPORT_SYMBOL_GPL(mpc5200_audio_dma_create);

> +EXPORT_SYMBOL_GPL(mpc5200_audio_dma_destroy);

> +static int __init mpc5200_soc_platform_init(void)
> +{
> + /* Tell the ASoC OF helpers about it */
> + return snd_soc_register_platform(&mpc5200_audio_dma_platform);
> +}
> +module_init(mpc5200_soc_platform_init);

> +static void __exit mpc5200_soc_platform_exit(void)
> +{
> + snd_soc_unregister_platform(&mpc5200_audio_dma_platform);
> +}
> +module_exit(mpc5200_soc_platform_exit);

This all looks a bit odd - I'd expect to see the platform registering
with the core when it is probed rather than on module load.  Looking at
the code it appears that you're automatically instantiating the DMA
driver from the node for the DAI?  If that is the case then you ought
to be calling the platform registration functions from the dma_create()
and dma_destroy() functions instead.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 6/9] Codec for STAC9766 used on the Efika

[Mark Brown]

On Sat, May 23, 2009 at 07:13:07PM -0400, Jon Smirl wrote:
> AC97 codec for STAC9766 used on the Efika.
> Datasheet: http://www.idt.com/products/getDoc.cfm?docID=13134007
> 
> Signed-off-by: Jon Smirl 

This looks mostly good, a couple of issues below.  I'll apply the patch
but please submit a followup patch for resume as discussed below.

> +static int ac97_digital_trigger(struct snd_pcm_substream *substream,
> + int cmd, struct 
> snd_soc_dai *dai)

Very strange indentation here...

> +static int stac9766_codec_resume(struct platform_device *pdev)
> +{

> + /* give the codec an AC97 warm reset to start the link */
> +reset:
> + if (reset > 5) {
> + printk(KERN_ERR "stac9766 failed to resume");
> + return -EIO;
> + }
> + codec->ac97->bus->ops->warm_reset(codec->ac97);
> + id = soc_ac97_ops.read(codec->ac97, AC97_VENDOR_ID2);
> + if (id != 0x4c13) {
> + stac9766_reset(codec, 0);
> + reset++;
> + goto reset;
> + }

As I said last time I'd this looks like it should be using the reset
function that you've provided?  

The loop is new since last time and seems very suspicious - are you sure
that this is a CODEC problem that's being worked around and not an issue
with the AC97 controller or with the specific system starting up the
master clock for the CODEC after resume?  If it's an issue with the
controler then it'd be better to fix it there so that all CODEC drivers
get the benefit.  If it's a CODEC issue a comment explaining the problem
would be helpful since it's not the sort of issue I'd expect to see in a
CODEC.  The fact that it's not needed on initial boot suggests something
controller or external clock related.

Either way, it'd be much clearer to rewrite it using a for or while loop
rather than a goto.  Please submit a followup patch fixing at least this
issue.

> +static int __init stac9766_modinit(void)
> +{
> + return snd_soc_register_dais(stac9766_dai, ARRAY_SIZE(stac9766_dai));
> +}
> +module_init(stac9766_modinit);
> +
> +static void __exit stac9766_exit(void)
> +{
> + snd_soc_unregister_dais(stac9766_dai, ARRAY_SIZE(stac9766_dai));
> +}
> +module_exit(stac9766_exit);

These are not needed for AC97 CODECs, ASoC doesn't wait for them to
probe.  I'll apply a patch removing these.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 7/9] AC97 driver for mpc5200

[Mark Brown]

On Sat, May 23, 2009 at 07:13:09PM -0400, Jon Smirl wrote:

> +#ifdef CONFIG_PM
> +static int psc_ac97_suspend(struct snd_soc_dai *dai)
> +{
> + return 0;
> +}
> +
> +static int psc_ac97_resume(struct snd_soc_dai *dai)
> +{
> + return 0;
> +}
> +
> +#else
> +#define psc_ac97_suspend NULL
> +#define psc_ac97_resume  NULL
> +#endif

These can all just be removed, they can be added later if they are
implemented.

> +static int psc_ac97_hw_analog_params(struct snd_pcm_substream *substream,
> +  struct snd_pcm_hw_params *params,
> +  struct snd_soc_dai *dai)
> +{
> + struct snd_soc_pcm_runtime *rtd = substream->private_data;
> + struct psc_dma *psc_dma = rtd->dai->cpu_dai->private_data;

Note that cpu_dai is passed in as an argument here - this didn't used to
be the case which is why most drivers fish it out of rtd but that's not
required any more.

> +static int psc_ac97_trigger(struct snd_pcm_substream *substream, int cmd,
> +  struct 
> snd_soc_dai *dai)

Again with the odd indentation.

> +static int __devinit psc_ac97_of_probe(struct of_device *op,
> +   const struct of_device_id *match)
> +{

> + rc = snd_soc_register_dais(psc_ac97_dai, ARRAY_SIZE(psc_ac97_dai));
> + if (rc != 0) {
> + pr_err("Failed to register DAI\n");
> + return 0;
> + }

I'd expect to see the error passed back to the caller here?  I'd also
expect to see this happening right at the end of this function after
you're happy everything else has worked, otherwise the core might try to
start using the half-initialised driver.

> + /* AC97 clock is generated by the codec.
> +  * Ensure that it starts ticking after codec reset.
> +  */
> + max_reset = 0;
> +reset:
> + if (max_reset++ > 5) {
> + dev_err(&op->dev, "AC97 codec failed to reset\n");
> + mpc5200_audio_dma_destroy(op);
> + return -ENODEV;
> + }
> +
> + psc_ac97_cold_reset(&ac97);
> + psc_ac97_warm_reset(&ac97);
> +
> + /* first make sure it is low */
> + timeout = 0;
> + while ((in_8(®s->ipcr_acr.ipcr) & 0x80) != 0) {
> + udelay(1);
> + if (timeout++ > 1000)
> + goto reset;
> + }

This looks awfully similar to the logic in the resume function of your
CODEC driver...  In general an ASoC AC97 DAI driver shouldn't be trying
to bring the CODEC up like this, it should normally leave that up to the
CODEC driver.  This is mostly because some system designers do strange
and wonderful things with clocking which require some system specific
code to either bring up the master clock for the codec before it'll
reset or reconfigure the clocking to something standard.

The issue with the use of goto rather than a real loop also applies
here.

> + /* then wait for the transition to high */
> + timeout = 0;
> + while ((in_8(®s->ipcr_acr.ipcr) & 0x80) == 0) {
> + udelay(1);
> + if (timeout++ > 1000)
> + psc_ac97_warm_reset(&ac97);
> + }

Shouldn't this be integrated into the warm reset operation (or to put it
another way, why wouldn't a warm reset want to do this)?  

> +
> + /* Go */
> + out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE);
> +
> + id1 = psc_ac97_read(&ac97, AC97_VENDOR_ID1);
> + id2 = psc_ac97_read(&ac97, AC97_VENDOR_ID2);
> +
> + dev_info(&op->dev, "Codec ID is %04x %04x\n", id1, id2);

You really can't rely on this working in general system designs - like I
say, some platforms will require additional work to bring the CODEC up.
I'd just remove it, it's purely for information anyway.  The out_8()
probably ought to be moved into the ASoC probe() function (called once
the card is coming up).
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 8/9] Fabric bindings for STAC9766 on the Efika

[Mark Brown]

On Sat, May 23, 2009 at 07:13:11PM -0400, Jon Smirl wrote:
> Fabric bindings for STAC9766 AC97 codec on the Efika.
> 
> Signed-off-by: Jon Smirl 

This is OK, but obviously depends on previous patches so I'll not apply
it just yet.  You might want to run it (and many of your other patches)
through checkpatch, though.  One nit:

> +static __exit void efika_fabric_exit(void)
> +{
> +}

This should either do something or be removed.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 9/9] Support for AC97 on Phytec pmc030 base board.

[Mark Brown]

On Sat, May 23, 2009 at 07:13:13PM -0400, Jon Smirl wrote:
> Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
> 
> Signed-off-by: Jon Smirl 

Same comments as for the previous driver - it's OK once the AC97 DAI
driver goes in.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: PPC405EX based irq flooding with USB-OTG and usbserial device

[Chuck Meade]

Hunter Cobbs wrote:
> On Sat, May 23, 2009 at 1:14 PM, Wolfgang Denk  > wrote:
> 
> Dear Hunter,
> 
> In message
>  >
> you wrote:
> >
> > This is my first post to the PPC dev list as my company has just
> started
> > developing a new project based on Linux.  The good news is, this
> post is not
> > debug-related as much as it is an introduction and query while I
> download
> > the latest DENX kernel(only place I know that has the DWC_OTG driver).
> 
> there is a strong reason why we decided  not  to  try  to  push  this
> driver  upstream:  it  is not in a state that would have a chance for
> being accepted for mainline. The problems you  are  experiencing  are
> probably   not   the   only  one.  Please  consider  this  driver  as
> unsupported.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> w...@denx.de 
> "Ada is PL/I trying to be Smalltalk. - Codoso diBlini
> 
> 
> Which leads me to another question.  Since I should consider this
> unsupported, is there a better driver out there as my company is already
> well down the road with our design?  Or would you recommend just
> creating our own driver for the USB-OTG? 
> 
> I'm developing with the Kilauea, and I guess I should ask how unstable
> is Linux support for this Processor.
> -- 
> Hunter Cobbs

Hi Hunter,

First, thanks very much for the email, and for the patches to fix the DMA.  I 
had
assumed, both when I saw the DMA warnings and when I saw the defines in the 
Makefile,
that DMA was absolutely not ready for primetime on PPC405EX USB.  Needless to 
say I
will be testing out your DMA patches here.

If that works for me, that should mitigate some of this interrupt overhead.  So 
thanks
in advance -- I am hoping that this will make a real difference.

To answer your recent question, I have had no other difficulties with the 
PPC405EX.
I actually work with 3 different custom targets right now using the PPC405EX 
(one uses
the PPC405EXr variant), and have had no problems outside of USB.

I do not know of any other driver for the PPC405EX USB controller.

My other remaining USB issue on this controller is a bandwidth issue.  There is 
another
USB host controller called ehci commonly found on PCs, and I see that they have 
a
configurable scheduler tweak called CONFIG_USB_EHCI_TT_NEWSCHED.  The 
description in
the drivers/usb/host/Kconfig file for that config item under ehci (in the 
Kconfig file
search for USB_EHCI_TT_NEWSCHED) is *exactly* the problem I am having now on 
the PPC405EX
USB controller.  Of course that scheduler tweak is for a totally different USB 
controller,
so that doesn't help me directly, but it serves as an example.  If anybody else 
out there
has fixed this USB bandwidth issue on PPC405EX (the one described in the ehci 
solution
for this under USB_EHCI_TT_NEWSCHED), please let me/us know.

Thanks,
Chuck

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 2/9] Basic split of mpc5200 DMA code out from mpc5200_psc_i2s

[Grant Likely]

On Sat, May 23, 2009 at 5:12 PM, Jon Smirl  wrote:
> Basic split of mpc5200 DMA code out from i2s into a standalone file.
>
> Signed-off-by: Jon Smirl 

I haven't looked in detail, but I'm okay with this in principle.

Acked-by: Grant Likely 

g.

> ---
>  sound/soc/fsl/Kconfig           |    4
>  sound/soc/fsl/Makefile          |    2
>  sound/soc/fsl/mpc5200_dma.c     |  458 +
>  sound/soc/fsl/mpc5200_dma.h     |   81 +++
>  sound/soc/fsl/mpc5200_psc_i2s.c |  485 
> ---
>  5 files changed, 547 insertions(+), 483 deletions(-)
>  create mode 100644 sound/soc/fsl/mpc5200_dma.c
>  create mode 100644 sound/soc/fsl/mpc5200_dma.h
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 9fc9082..dc79bdf 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -1,5 +1,8 @@
>  config SND_SOC_OF_SIMPLE
>        tristate
> +
> +config SND_MPC52xx_DMA
> +       tristate
>
>  # ASoC platform support for the Freescale MPC8610 SOC.  This compiles drivers
>  # for the SSI and the Elo DMA controller.  You will still need to select
> @@ -23,6 +26,7 @@ config SND_SOC_MPC5200_I2S
>        tristate "Freescale MPC5200 PSC in I2S mode driver"
>        depends on PPC_MPC52xx && PPC_BESTCOMM
>        select SND_SOC_OF_SIMPLE
> +       select SND_MPC52xx_DMA
>        select PPC_BESTCOMM_GEN_BD
>        help
>          Say Y here to support the MPC5200 PSCs in I2S mode.
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index f85134c..7731ef2 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -10,5 +10,7 @@ snd-soc-fsl-ssi-objs := fsl_ssi.o
>  snd-soc-fsl-dma-objs := fsl_dma.o
>  obj-$(CONFIG_SND_SOC_MPC8610) += snd-soc-fsl-ssi.o snd-soc-fsl-dma.o
>
> +# MPC5200 Platform Support
> +obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
>  obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> new file mode 100644
> index 000..4bae8d6
> --- /dev/null
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -0,0 +1,458 @@
> +/*
> + * Freescale MPC5200 PSC DMA
> + * ALSA SoC Platform driver
> + *
> + * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "mpc5200_dma.h"
> +
> +MODULE_AUTHOR("Grant Likely ");
> +MODULE_DESCRIPTION("Freescale MPC5200 PSC in DMA mode ASoC Driver");
> +MODULE_LICENSE("GPL");
> +
> +/*
> + * Interrupt handlers
> + */
> +static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s)
> +{
> +       struct psc_i2s *psc_i2s = _psc_i2s;
> +       struct mpc52xx_psc __iomem *regs = psc_i2s->psc_regs;
> +       u16 isr;
> +
> +       isr = in_be16(®s->mpc52xx_psc_isr);
> +
> +       /* Playback underrun error */
> +       if (psc_i2s->playback.active && (isr & MPC52xx_PSC_IMR_TXEMP))
> +               psc_i2s->stats.underrun_count++;
> +
> +       /* Capture overrun error */
> +       if (psc_i2s->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
> +               psc_i2s->stats.overrun_count++;
> +
> +       out_8(®s->command, 4 << 4);  /* reset the error status */
> +
> +       return IRQ_HANDLED;
> +}
> +
> +/**
> + * psc_i2s_bcom_enqueue_next_buffer - Enqueue another audio buffer
> + * @s: pointer to stream private data structure
> + *
> + * Enqueues another audio period buffer into the bestcomm queue.
> + *
> + * Note: The routine must only be called when there is space available in
> + * the queue.  Otherwise the enqueue will fail and the audio ring buffer
> + * will get out of sync
> + */
> +static void psc_i2s_bcom_enqueue_next_buffer(struct psc_i2s_stream *s)
> +{
> +       struct bcom_bd *bd;
> +
> +       /* Prepare and enqueue the next buffer descriptor */
> +       bd = bcom_prepare_next_buffer(s->bcom_task);
> +       bd->status = s->period_bytes;
> +       bd->data[0] = s->period_next_pt;
> +       bcom_submit_next_buffer(s->bcom_task, NULL);
> +
> +       /* Update for next period */
> +       s->period_next_pt += s->period_bytes;
> +       if (s->period_next_pt >= s->period_end)
> +               s->period_next_pt = s->period_start;
> +}
> +
> +/* Bestcomm DMA irq handler */
> +static irqreturn_t psc_i2s_bcom_irq(int irq, void *_psc_i2s_stream)
> +{
> +       struct psc_i2s_stream *s = _psc_i2s_stream;
> +
> +       /* For each finished period, dequeue the completed period buffer
> +        * and enqueue a new one in it's place. */
> +       while (bcom_buffer_done(s->bcom_task)) {
> +               bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
> +               s->period_current_pt += s->period_bytes;
> +               if (s->period_current_pt >= s->period_end)
> +                       s->period_current_pt = s->period_start;
> +               psc_i2s_b

Re: [alsa-devel] [PATCH V2 3/9] Rename the PSC functions to DMA

[Grant Likely]

On Sun, May 24, 2009 at 5:15 AM, Mark Brown
 wrote:
> On Sat, May 23, 2009 at 07:13:01PM -0400, Jon Smirl wrote:
>> Rename the functions in the mpc5200 DMA file from i2s based names to dma 
>> ones to reflect the file they are in.
>
> I'm OK with both these refactoring patches if Grant is - Grant, if I
> could get your ack I'd like to merge these as soon as possible since
> they're very big changes and it'd cut down on review effort.

Acked-by: Grant Likely 

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines

[Grant Likely]

On Sat, May 23, 2009 at 5:13 PM, Jon Smirl  wrote:
> Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC 
> registers. This patch is going in via Grant's tree.
>
> Signed-off-by: Jon Smirl 

Acked-by: Grant Likely 

> ---
>  0 files changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h 
> b/arch/powerpc/include/asm/mpc52xx_psc.h
> index a218da6..fb84120 100644
> --- a/arch/powerpc/include/asm/mpc52xx_psc.h
> +++ b/arch/powerpc/include/asm/mpc52xx_psc.h
> @@ -28,6 +28,10 @@
>  #define MPC52xx_PSC_MAXNUM     6
>
>  /* Programmable Serial Controller (PSC) status register bits */
> +#define MPC52xx_PSC_SR_UNEX_RX 0x0001
> +#define MPC52xx_PSC_SR_DATA_VAL        0x0002
> +#define MPC52xx_PSC_SR_DATA_OVR        0x0004
> +#define MPC52xx_PSC_SR_CMDSEND 0x0008
>  #define MPC52xx_PSC_SR_CDE     0x0080
>  #define MPC52xx_PSC_SR_RXRDY   0x0100
>  #define MPC52xx_PSC_SR_RXFULL  0x0200
> @@ -61,6 +65,12 @@
>  #define MPC52xx_PSC_RXTX_FIFO_EMPTY    0x0001
>
>  /* PSC interrupt status/mask bits */
> +#define MPC52xx_PSC_IMR_UNEX_RX_SLOT 0x0001
> +#define MPC52xx_PSC_IMR_DATA_VALID     0x0002
> +#define MPC52xx_PSC_IMR_DATA_OVR       0x0004
> +#define MPC52xx_PSC_IMR_CMD_SEND       0x0008
> +#define MPC52xx_PSC_IMR_ERROR          0x0040
> +#define MPC52xx_PSC_IMR_DEOF           0x0080
>  #define MPC52xx_PSC_IMR_TXRDY          0x0100
>  #define MPC52xx_PSC_IMR_RXRDY          0x0200
>  #define MPC52xx_PSC_IMR_DB             0x0400
> @@ -117,6 +127,7 @@
>  #define MPC52xx_PSC_SICR_SIM_FIR               (0x6 << 24)
>  #define MPC52xx_PSC_SICR_SIM_CODEC_24          (0x7 << 24)
>  #define MPC52xx_PSC_SICR_SIM_CODEC_32          (0xf << 24)
> +#define MPC52xx_PSC_SICR_AWR                   (1 << 30)
>  #define MPC52xx_PSC_SICR_GENCLK                        (1 << 23)
>  #define MPC52xx_PSC_SICR_I2S                   (1 << 22)
>  #define MPC52xx_PSC_SICR_CLKPOL                        (1 << 21)
>
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97

[Jon Smirl]

On Sun, May 24, 2009 at 7:08 AM, Mark Brown
 wrote:
> I'm not aware of any CODEC drivers which can't currently be built and
> used as modules.  If you mean "load via the normal device model" then
> yes, that'd be very good (and is in progress) but it's another issue and
> as I explained last time AC97 poses particular problems there.
>

I mean "load via the normal device model". For example the AC97
drivers need to be loadable by the codec id. There's no entry in
scripts/mod/file2alias.c for dynamically loading the modules.  They
don't have an id_table.

My AC97 driver is detecting the codec id and printing it before trying
to access the codec driver. I can convert that to a load_module() call
when the drivers are ready.

The core needs to detect if a specific codec id can't be supported to
fall back to the generic AC97 driver.

-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load

[Jon Smirl]

On Sun, May 24, 2009 at 7:11 AM, Mark Brown
 wrote:
> On Sat, May 23, 2009 at 07:12:57PM -0400, Jon Smirl wrote:
>> Register the wm9712 DAIs on module load
>
>> Signed-off-by: Jon Smirl 
>
> Why do you wish to do this - ASoC does not require or use DAI registration
> for AC97 CODECs?
>

Then what is wrong with my binding code? If I take out the
registration my bind fails.

static struct snd_soc_dai_link pcm030_fabric_dai[] = {
{
.name = "AC97",
.stream_name = "AC97 Analog",
.codec_dai = &wm9712_dai[WM9712_DAI_AC97_HIFI],
.cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
},
{
.name = "AC97",
.stream_name = "AC97 IEC958",
.codec_dai = &wm9712_dai[WM9712_DAI_AC97_AUX],
.cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
},
};

static __init int pcm030_fabric_init(void)
{
struct platform_device *pdev;
int rc;

if (!machine_is_compatible("phytec,pcm030"))
return -ENODEV;

card.platform = &mpc5200_audio_dma_platform;
card.name = "pcm030";
card.dai_link = pcm030_fabric_dai;
card.num_links = ARRAY_SIZE(pcm030_fabric_dai);

device.card = &card;
device.codec_dev = &soc_codec_dev_wm9712;

pdev = platform_device_alloc("soc-audio", 1);
if (!pdev) {
pr_err("pcm030_fabric_init: platform_device_alloc() failed\n");
return -ENODEV;
}

platform_set_drvdata(pdev, &device);
device.dev = &pdev->dev;

rc = platform_device_add(pdev);
if (rc) {
pr_err("pcm030_fabric_init: platform_device_add() failed\n");
return -ENODEV;
}
return 0;
}


Advanced Linux Sound Architecture Driver Version 1.0.19.
No device for DAI stac9766 analog
No device for DAI stac9766 IEC958
No device for DAI tas5504
irq: irq 129 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 129
irq: irq 194 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 194
irq: irq 195 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 195
mpc5200-psc-ac97 f0002000.ac97: Codec ID is 574d 4c12
ALSA device list:
  No soundcards found.





-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load

[Jon Smirl]

Output with SOC DEBUG turned on:

Advanced Linux Sound Architecture Driver Version 1.0.19.
No device for DAI stac9766 analog
Registered DAI 'stac9766 analog'
No device for DAI stac9766 IEC958
Registered DAI 'stac9766 IEC958'
No device for DAI tas5504
Registered DAI 'tas5504'
Registered platform 'mpc5200-psc-audio'
irq: irq 129 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 129
irq: irq 194 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 194
irq: irq 195 on host /soc5...@f000/interrupt-control...@500 mapped
to virtual irq 195
Registered DAI 'AC97'
Registered DAI 'SPDIF'
mpc5200-psc-ac97 f0002000.ac97: Codec ID is 574d 4c12
soc-audio soc-audio.1: DAI AC97 HiFi not registered
soc-audio soc-audio.1: Registered card 'pcm030'
ALSA device list:
  No soundcards found.


-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines

[Mark Brown]

On Sun, May 24, 2009 at 08:13:19AM -0600, Grant Likely wrote:
> On Sat, May 23, 2009 at 5:13 PM, Jon Smirl  wrote:
> > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC 
> > registers. This patch is going in via Grant's tree.

> > Signed-off-by: Jon Smirl 

> Acked-by: Grant Likely 

Jon's commit log says this is going in via your tree - is that the case
or should I apply it to ASoC?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 4/9] Add a few more mpc5200 PSC defines

[Grant Likely]

On Sun, May 24, 2009 at 12:00 PM, Mark Brown
 wrote:
> On Sun, May 24, 2009 at 08:13:19AM -0600, Grant Likely wrote:
>> On Sat, May 23, 2009 at 5:13 PM, Jon Smirl  wrote:
>> > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 
>> > PSC registers. This patch is going in via Grant's tree.
>
>> > Signed-off-by: Jon Smirl 
>
>> Acked-by: Grant Likely 
>
> Jon's commit log says this is going in via your tree - is that the case
> or should I apply it to ASoC?

Nothing else needs it in MPC5200 land and I haven't applied it to my
tree yet.  Go ahead and add it to the ASoC tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 4/9] Add a few more mpc5200 PSC defines

[Mark Brown]

On Sun, May 24, 2009 at 12:19:37PM -0600, Grant Likely wrote:

> Nothing else needs it in MPC5200 land and I haven't applied it to my
> tree yet.  Go ahead and add it to the ASoC tree.

OK, applied this and the two refactoring patches - thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 0/9] mpc5200 audio rework for AC97

[Mark Brown]

On Sun, May 24, 2009 at 11:21:15AM -0400, Jon Smirl wrote:

> My AC97 driver is detecting the codec id and printing it before trying
> to access the codec driver. I can convert that to a load_module() call
> when the drivers are ready.

No, your AC97 driver shouldn't be doing any of this at all - it should
be leaving any enumeration of the hardware up to the machine driver and
the core.  In so far as it is standardised the process for probing AC97
is something that can be implemented in terms of the operations exported
by the DAI so it should be done in the core for all AC97 DAIs.  Where
standardised probing can't work it needs to be machine specific anyway.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code

[Wolfram Sang]

> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it more 
> robust.

Why is it more robust?

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH V2 1/9] Register the wm9712 DAIs on module load

[Mark Brown]

On Sun, May 24, 2009 at 11:28:15AM -0400, Jon Smirl wrote:
> On Sun, May 24, 2009 at 7:11 AM, Mark Brown

> > Why do you wish to do this - ASoC does not require or use DAI registration
> > for AC97 CODECs?

> Then what is wrong with my binding code? If I take out the
> registration my bind fails.

It appears that the problem here is that your CPU DAI isn't marked as an
ac97 DAI by having ac97_control set so the core expects the codec to
instantiate prior to the card.  Setting ac97_control ought to fix the
problem, but obviously I can't test.

When looking at problems like this it's worth taking a step back and
looking at why the existing code is the way that it is when considering
if you've found the right fix.  In this case AC97 is fairly widely used
and there are also a number of WM9712 users but neither WM9712 or any of
the other AC97 CODEC drivers ever register their DAIs.  That should be
an indication that either things probably should work without a change
to existing code or things are completely broken and something wider
than a change in a single driver is required in order to get things
working.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code

[Jon Smirl]

On Sun, May 24, 2009 at 2:55 PM, Wolfram Sang  wrote:
>> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it 
>> more robust.
>
> Why is it more robust?

I've implemented retries for when the AC97 hardware doesn't reset on
first try. About 10% of the time both the Efika and pcm030 AC97 codecs
don't reset on first try and need to be poked multiple times.  Failure
is indicated by not having the link clock start ticking. Every once in
a while even five pokes won't get the link started and I have to power
cycle.

I don't have an oscilloscope, after I get these basic drivers in maybe
someone can put a scope on this and figure out why reset is failing.
I've read the various datasheets and I believe my reset pulses have
the correct timings.

>
> --
> Pengutronix e.K.                           | Wolfram Sang                |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoZmA0ACgkQD27XaX1/VRvugwCgsluxfp1rJH2MVFMTH6Yqo8bX
> dnIAn1z0QRIFEUJa0XpGFE937siwf8Cy
> =M0wP
> -END PGP SIGNATURE-
>
>



-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2 5/9] Main rewite of the mpc5200 audio DMA code

[Wolfram Sang]

On Sun, May 24, 2009 at 04:10:52PM -0400, Jon Smirl wrote:
> On Sun, May 24, 2009 at 2:55 PM, Wolfram Sang  wrote:
> >> Rewrite the mpc5200 audio DMA code to support both I2S and AC97. Make it 
> >> more robust.
> >
> > Why is it more robust?
> 
> I've implemented retries for when the AC97 hardware doesn't reset on
> first try. About 10% of the time both the Efika and pcm030 AC97 codecs
> don't reset on first try and need to be poked multiple times.  Failure
> is indicated by not having the link clock start ticking. Every once in
> a while even five pokes won't get the link started and I have to power
> cycle.
> 
> I don't have an oscilloscope, after I get these basic drivers in maybe
> someone can put a scope on this and figure out why reset is failing.
> I've read the various datasheets and I believe my reset pulses have
> the correct timings.

That's good to know. In fact, I think a summary of this should go into the
patch description.

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

U-boot and linux command line parameters

[Mirek23]

Dear All,

I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 ) for  some
time. All works fine when the
kernel together with initramfs is smaller than 8MB. If it is bigger than the
kernel does not boot properly.

First of all I would like to know how the address for the linux command line
parameters is "transferred" from u-boot to linux for ppc405 (virtex4 chip)?
(via some registers or is it  a fixed address in the memory ie. 8MB?)
Does somebody know what should be changed, in the kernel,  in order to move
this limitation from 8MB to let say 12MB? I would be grateful for any hint.

Thanks in advance.
M. 
-- 
View this message in context: 
http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23698384.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: U-boot and linux command line parameters

[Hunter Cobbs]

Have you considered using a kernel and initrd?

Hunter Cobbs

On May 24, 2009, at 4:38 PM, Mirek23  wrote:



Dear All,

I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 )  
for  some

time. All works fine when the
kernel together with initramfs is smaller than 8MB. If it is bigger  
than the

kernel does not boot properly.

First of all I would like to know how the address for the linux  
command line
parameters is "transferred" from u-boot to linux for ppc405 (virtex4  
chip)?

(via some registers or is it  a fixed address in the memory ie. 8MB?)
Does somebody know what should be changed, in the kernel,  in order  
to move
this limitation from 8MB to let say 12MB? I would be grateful for  
any hint.


Thanks in advance.
M.
--
View this message in context: 
http://www.nabble.com/U-boot-and-linux-command-line-parameters-tp23698384p23698384.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver

[Arnd Bergmann]

On Saturday 23 May 2009, Wolfgang Grandegger wrote:
> Arnd Bergmann wrote:
> > 
> > Minor nitpicking: dev->base_addr should be defined as an __iomem pointer
> > so you can avoid the cast here and in the ioremap/iounmap path.
> 
> Here the member "base_addr" of "struct net_device" is used and it's not
> up to me to change the type.

Right, that makes sense. However, most drivers use the field to store the
physical address, not the iomap token. Maybe there should be a new field
in struct sja1000_priv for the virtual address, but that would be a change
to the base driver, not just to the OF portion.

Thanks,

Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: U-boot and linux command line parameters

[David Gibson]

On Sun, May 24, 2009 at 02:38:52PM -0700, Mirek23 wrote:
> 
> Dear All,
> 
> I use linux kernel 2.6.23 and u-boot 1.2.0 (on ppc405 virtex-4 ) for
> some time. All works fine when the kernel together with initramfs is
> smaller than 8MB. If it is bigger than the kernel does not boot
> properly.
> 
> First of all I would like to know how the address for the linux
> command line parameters is "transferred" from u-boot to linux for
> ppc405 (virtex4 chip)?  (via some registers or is it a fixed address
> in the memory ie. 8MB?)  Does somebody know what should be changed,
> in the kernel, in order to move this limitation from 8MB to let say
> 12MB? I would be grateful for any hint.

IIRC, U-boot 1.2.0 is a version of u-boot before it became device tree
aware.  Which means if I'm reading the cuboot.c code correctly, the
command line address is passed to the kernel at entry in r6, with the
length in r7.  With later, device-tree aware u-boot versions, the
command line is instead passed as a device tree property.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Benjamin Herrenschmidt]

On Sun, 2009-05-24 at 20:21 +1000, Benjamin Herrenschmidt wrote:

> We need to see if we can get the vmalloc allocator safe for GFP_ATOMIC
> context, might be doable.
> 
> As for free, unfortunately, even the old allocator won't help with SMP,
> since that needs to do IPIs for cross TLB invalidates.
> 
> Maybe we should enqueue free blocks and do the actual freeing from a
> workqueue or something similar.

Ok, so here's my conclusion:

First, I need to apologize as I'm the one iirc who told Ilya to
implement it that way... oops.

I don't think we can easily get the mm/vmalloc.c code irq safe,
especially not since it got bloated recently for scalability.

So at this stage, we have no choice I think be re-instate the old code.

This won't fix all the issues because we still can't do TLB shootdown in
SMP at interrupt time, but I don't think there's any released platform
in 2.6.30 that does SMP and non-coherent DMA, so we can fix that later.

I'll do the revert as it's not trivial (we removed CONFIG_CONSISTENT_*
etc...) for now.

Note that I still think the right approach in the long run is to ban the
consistent allocs from atomic contexts generically in linux, though that
will be a hard nut to crack.

Cheers,
Ben.

> Cheers,
> Ben.
> 
> > On Thu, May 21, 2009 at 10:50 AM, Albert Herranz
> >  wrote:
> > >
> > > Hello list,
> > >
> > > Commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8 seems to have broken DMA 
> > > coherent allocations for CONFIG_NOT_COHERENT_CACHE platforms.
> > >
> > > The problems seem to be that the new __dma_alloc_coherent() and 
> > > __dma_free_coherent() implementations:
> > >
> > > - don't respect anymore the passed gfp flags (__dma_alloc_coherent() 
> > > unconditionally uses GFP_KERNEL within the function irrespective of the 
> > > caller flags)
> > > - can't be used in interrupt context as they use 
> > > get_vm_area_caller()/vfree() which end up triggering 
> > > BUG_ON(in_interrupt())
> > >
> > > One victim happens to be the USB core subsystem which sometimes frees dma 
> > > coherent memory in interrupt context for drivers flagged HCD_LOCAL_MEM.
> > >
> > > This has been experienced while writing a new EHCI driver for the 
> > > Nintendo Wii platform.
> > >
> > > usb 1-1: new high speed USB device using ehci-mipc and address 2
> > > [ cut here ]
> > > kernel BUG at mm/vmalloc.c:1328!
> > > Oops: Exception in kernel mode, sig: 5 [#1]
> > > PREEMPT wii
> > > Modules linked in:
> > > NIP: c008ea20 LR: c0015890 CTR: c00111d4
> > > REGS: d2c65b10 TRAP: 0700   Not tainted  
> > > (2.6.30-rc2-isobel-wii-00092-gcba94db-dirty)
> > > MSR: 00021032   CR: 42482028  XER: 
> > > TASK = d2c600f0[28] 'kmmcd' THREAD: d2c64000
> > > GPR00: 0001 d2c65bc0 d2c600f0 d403 d403 d403 12da1000 
> > > 0001
> > > GPR08:  d2c64000 0020  22482022 94fdfb98 6e1979bc 
> > > c6bbdbdd
> > > GPR16: 0020 00200200 00100100 d4020060 0001 d401c0ec 0001 
> > > d401c0ec
> > > GPR24: d2d9a6c0   d2f69de0 d2d9a600 d2f69e30 d2f69e2c 
> > > d2da08e0
> > > NIP [c008ea20] vfree+0xc/0x18
> > > LR [c0015890] __dma_free_coherent+0x14/0x24
> > > Call Trace:
> > > [d2c65bc0] [c0017af8] __mipc_recv_req+0x160/0x178 (unreliable)
> > > [d2c65bd0] [c00111ec] dma_direct_free_coherent+0x18/0x28
> > > [d2c65be0] [c01cfca4] hcd_free_coherent+0x7c/0x12c
> > > [d2c65c10] [c01d00b8] unmap_urb_for_dma+0x150/0x1cc
> > > [d2c65c20] [c01d0174] usb_hcd_giveback_urb+0x40/0xe4
> > > [d2c65c30] [c01df474] ehci_urb_done+0xf0/0x114
> > > [d2c65c50] [c01e3870] qh_completions+0x41c/0x4dc
> > > [d2c65ca0] [c01e44e0] scan_async+0x9c/0x1a0
> > > [d2c65cc0] [c01e49ec] ehci_work+0x58/0xc4
> > > [d2c65cd0] [c01e5424] ehci_irq+0x22c/0x230
> > > [d2c65d00] [c01cfa88] usb_hcd_irq+0x50/0xa8
> > > [d2c65d20] [c00597d8] handle_IRQ_event+0xdc/0x250
> > > [d2c65d60] [c005ba20] handle_level_irq+0x9c/0x138
> > > [d2c65d80] [c001cbc8] hollywood_pic_irq_cascade+0x7c/0xf8
> > > [d2c65da0] [c00064b4] do_IRQ+0x9c/0xc4
> > > [d2c65dc0] [c0011fb8] ret_from_except+0x0/0x14
> > >
> > > Any comments on how to address this issue (other than reverting the above 
> > > mentioned commit, which fixes it) are welcome.
> > >
> > > Thanks,
> > > Albert
> > >
> > >
> > >
> > >
> > > ___
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > >
> > 
> > 
> > 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 0/6] PPC64: Hardware Breakpoint interfaces - ver IV

[K.Prasad]

Hi All,
Please find a new patchset that implements Hardware Breakpoint 
interfaces
for PPC64 architecture, the previous version of which was posted here:
http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072387.html and the changes 
over
it are mentioned in the changelog below.

Changelog - ver IV
--
(Ver I: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/071942.html)
(Ver II: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072106.html)
(Ver III: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072387.html

- While DABR register requires double-word (8 bytes) aligned addresses, i.e.
the breakpoint is active over a range of 8 bytes, PPC64 allows byte-level
addressability. This may lead to stray exceptions which have to be ignored in
hw_breakpoint_handler(), when DAR != (Breakpoint request address). However DABR
will be populated with the requested breakpoint address aligned to the previous
double-word address. The code is now modified to store user-requested address
in 'bp->info.address' but update the DABR with a double-word aligned address.

- Please note that the Data Breakpoint facility in Xmon is broken as of 2.6.29
and the same has not been integrated into this facility as described in Ver I.

Kindly review the patches and let me know if they're in a form that is ready for
upstream inclusion.

Thanks,
K.Prasad

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure

[K.Prasad]

Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
relevant constant definitions and function declarations.

Signed-off-by: K.Prasad 
---
 arch/powerpc/include/asm/hw_breakpoint.h |   57 +++
 arch/powerpc/include/asm/processor.h |1 
 arch/powerpc/include/asm/reg.h   |3 +
 3 files changed, 61 insertions(+)

Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,57 @@
+#ifndef_PPC64_HW_BREAKPOINT_H
+#define_PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC64
+
+struct arch_hw_breakpoint {
+   char*name; /* Contains name of the symbol to set bkpt */
+   unsigned long   address;
+   u8  type;
+};
+
+#include 
+#include 
+#include 
+
+#define HW_BREAKPOINT_READ DABR_DATA_READ
+#define HW_BREAKPOINT_WRITE DABR_DATA_WRITE
+#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)
+
+#define HW_BREAKPOINT_ALIGN 0x7
+#define HW_BREAKPOINT_LEN INSTRUCTION_LEN
+
+extern struct hw_breakpoint *hbp_kernel[HBP_NUM];
+DECLARE_PER_CPU(struct hw_breakpoint*, this_hbp_kernel[HBP_NUM]);
+extern unsigned int hbp_user_refcount[HBP_NUM];
+
+extern void arch_install_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_uninstall_thread_hw_breakpoint(void);
+extern int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+   struct task_struct *tsk);
+extern void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk);
+extern void arch_flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_update_kernel_hw_breakpoint(void *);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+unsigned long val, void *data);
+
+extern void flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern int copy_thread_hw_breakpoint(struct task_struct *tsk,
+   struct task_struct *child, unsigned long clone_flags);
+extern void load_debug_registers(void );
+
+static inline void hw_breakpoint_disable(void)
+{
+   set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+   /* Function is defined only on PPC64 for now */
+}
+#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
+#endif /* _PPC64_HW_BREAKPOINT_H */
+
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
@@ -177,6 +177,7 @@ struct thread_struct {
 #ifdef CONFIG_PPC64
unsigned long   start_tb;   /* Start purr when proc switched in */
unsigned long   accum_tb;   /* Total accumilated purr for process */
+   struct hw_breakpoint *hbp[HBP_NUM];
 #endif
unsigned long   dabr;   /* Data address breakpoint register */
 #ifdef CONFIG_ALTIVEC
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/reg.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
@@ -26,6 +26,8 @@
 #include 
 #endif /* CONFIG_8xx */
 
+#define INSTRUCTION_LEN4   /* Length of any instruction */
+
 #define MSR_SF_LG  63  /* Enable 64 bit mode */
 #define MSR_ISF_LG 61  /* Interrupt 64b mode valid on 630 */
 #define MSR_HV_LG  60  /* Hypervisor state */
@@ -184,6 +186,7 @@
 #define   CTRL_TE  0x00c0  /* thread enable */
 #define   CTRL_RUNLATCH0x1
 #define SPRN_DABR  0x3F5   /* Data Address Breakpoint Register */
+#define   HBP_NUM  1   /* Number of physical HW breakpoint registers */
 #define   DABR_TRANSLATION (1UL << 2)
 #define   DABR_DATA_WRITE  (1UL << 1)
 #define   DABR_DATA_READ   (1UL << 0)

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces

[K.Prasad]

Introduce PPC64 implementation for the generic hardware breakpoint interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
Makefile.

Signed-off-by: K.Prasad 
---
 arch/powerpc/Kconfig|1 
 arch/powerpc/kernel/Makefile|2 
 arch/powerpc/kernel/hw_breakpoint.c |  279 
 3 files changed, 281 insertions(+), 1 deletion(-)

Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig
+++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
@@ -125,6 +125,7 @@ config PPC
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
+   select HAVE_HW_BREAKPOINT if PPC64
 
 config EARLY_PRINTK
bool
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile
@@ -33,7 +33,7 @@ obj-$(CONFIG_PPC64)   += setup_64.o sys_p
   signal_64.o ptrace32.o \
   paca.o cpu_setup_ppc970.o \
   cpu_setup_pa6t.o \
-  firmware.o nvram_64.o
+  firmware.o nvram_64.o hw_breakpoint.o
 obj64-$(CONFIG_RELOCATABLE)+= reloc_64.o
 obj-$(CONFIG_PPC64)+= vdso64/
 obj-$(CONFIG_ALTIVEC)  += vecemu.o vector.o
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,279 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright © 2009 IBM Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Store the kernel-space breakpoint address value */
+static unsigned long kdabr;
+
+/*
+ * Temporarily stores address for DABR before it is written by the
+ * single-step handler routine
+ */
+static DEFINE_PER_CPU(unsigned long, dabr_data);
+
+void arch_update_kernel_hw_breakpoint(void *unused)
+{
+   struct hw_breakpoint *bp;
+
+   /* Check if there is nothing to update */
+   if (hbp_kernel_pos == HBP_NUM)
+   return;
+
+   per_cpu(this_hbp_kernel[hbp_kernel_pos], get_cpu()) = bp =
+   hbp_kernel[hbp_kernel_pos];
+   if (bp == NULL)
+   kdabr = 0;
+   else
+   kdabr = (bp->info.address & ~HW_BREAKPOINT_ALIGN) |
+   bp->info.type | DABR_TRANSLATION;
+   set_dabr(kdabr);
+   put_cpu_no_resched();
+}
+
+/*
+ * Install the thread breakpoints in their debug registers.
+ */
+void arch_install_thread_hw_breakpoint(struct task_struct *tsk)
+{
+   set_dabr(tsk->thread.dabr);
+}
+
+/*
+ * Install the debug register values for just the kernel, no thread.
+ */
+void arch_uninstall_thread_hw_breakpoint()
+{
+   set_dabr(0);
+}
+
+/*
+ * Store a breakpoint's encoded address, length, and type.
+ */
+int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
+{
+   /*
+* User-space requests will always have the address field populated
+   * Symbol names from user-space are rejected
+   */
+   if (tsk && bp->info.name)
+   return -EINVAL;
+   /*
+* User-space requests will always have the address field populated
+* For kernel-addresses, either the address or symbol name can be
+* specified.
+*/
+   if (bp->info.name)
+   bp->info.address = (unsigned long)
+   kallsyms_lookup_name(bp->info.name);
+   if (bp->info.address)
+   return 0;
+   return -EINVAL;
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+

[Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces

[K.Prasad]

Modify the ptrace code to use the hardware breakpoint interfaces for user-space.

Signed-off-by: K.Prasad 
---
 arch/powerpc/kernel/ptrace.c |   44 +++
 1 file changed, 44 insertions(+)

Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * does not yet catch signals sent when the child dies.
@@ -735,9 +736,22 @@ void user_disable_single_step(struct tas
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
 }
 
+static void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs)
+{
+   /*
+* The SIGTRAP signal is generated automatically for us in do_dabr().
+* We don't have to do anything here
+*/
+}
+
 int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
   unsigned long data)
 {
+#ifdef CONFIG_PPC64
+   struct thread_struct *thread = &(task->thread);
+   struct hw_breakpoint *bp;
+   int ret;
+#endif
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
 *  For embedded processors we support one DAC and no IAC's at the
 *  moment.
@@ -767,6 +781,36 @@ int ptrace_set_debugreg(struct task_stru
if (data && !(data & DABR_TRANSLATION))
return -EIO;
 
+#ifdef CONFIG_PPC64
+   bp = thread->hbp[0];
+   if (data == 0) {
+   if (bp) {
+   unregister_user_hw_breakpoint(task, bp);
+   kfree(bp);
+   thread->hbp[0] = NULL;
+   }
+   return 0;
+   }
+
+   if (bp) {
+   bp->info.type = data & HW_BREAKPOINT_RW;
+   task->thread.dabr = bp->info.address = data;
+   return modify_user_hw_breakpoint(task, bp);
+   }
+   bp = kzalloc(sizeof(struct hw_breakpoint), GFP_KERNEL);
+   if (!bp)
+   return -ENOMEM;
+
+   /* Store the type of breakpoint */
+   bp->info.type = data & HW_BREAKPOINT_RW;
+   bp->triggered = ptrace_triggered;
+   task->thread.dabr = bp->info.address = data;
+
+   ret = register_user_hw_breakpoint(task, bp);
+   if (ret)
+   return ret;
+#endif /* CONFIG_PPC64 */
+
/* Move contents to the DABR register */
task->thread.dabr = data;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 4/6] Modify process and processor handling code to recognise hardware debug registers

[K.Prasad]

Modify process handling code to recognise hardware debug registers during copy
and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
process's use of debug register. Load the debug register values into a
new CPU during initialisation.

Signed-off-by: K.Prasad 
---
 arch/powerpc/include/asm/thread_info.h |2 ++
 arch/powerpc/kernel/process.c  |   18 ++
 arch/powerpc/kernel/smp.c  |2 ++
 3 files changed, 22 insertions(+)

Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/thread_info.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
@@ -114,6 +114,7 @@ static inline struct thread_info *curren
 #define TIF_FREEZE 14  /* Freezing for suspend */
 #define TIF_RUNLATCH   15  /* Is the runlatch enabled? */
 #define TIF_ABI_PENDING16  /* 32/64 bit switch needed */
+#define TIF_DEBUG  17  /* uses debug registers */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1<
 #ifdef CONFIG_PPC64
 #include 
+#include 
 #endif
 #include 
 #include 
@@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig
11, SIGSEGV) == NOTIFY_STOP)
return;
 
+#ifndef CONFIG_PPC64
if (debugger_dabr_match(regs))
return;
+#endif
 
/* Clear the DAC and struct entries.  One shot trigger */
 #if defined(CONFIG_BOOKE)
@@ -372,8 +375,13 @@ struct task_struct *__switch_to(struct t
 
 #endif /* CONFIG_SMP */
 
+#ifdef CONFIG_PPC64
+   if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
+   arch_install_thread_hw_breakpoint(new);
+#else
if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
+#endif /* CONFIG_PPC64 */
 
 #if defined(CONFIG_BOOKE)
/* If new thread DAC (HW breakpoint) is the same then leave it */
@@ -550,6 +558,10 @@ void show_regs(struct pt_regs * regs)
 void exit_thread(void)
 {
discard_lazy_cpu_state();
+#ifdef CONFIG_PPC64
+   if (unlikely(test_tsk_thread_flag(current, TIF_DEBUG)))
+   flush_thread_hw_breakpoint(current);
+#endif /* CONFIG_PPC64 */
 }
 
 void flush_thread(void)
@@ -605,6 +617,9 @@ int copy_thread(unsigned long clone_flag
struct pt_regs *childregs, *kregs;
extern void ret_from_fork(void);
unsigned long sp = (unsigned long)task_stack_page(p) + THREAD_SIZE;
+#ifdef CONFIG_PPC64
+   struct task_struct *tsk = current;
+#endif
 
CHECK_FULL_REGS(regs);
/* Copy registers */
@@ -672,6 +687,9 @@ int copy_thread(unsigned long clone_flag
 * function.
 */
kregs->nip = *((unsigned long *)ret_from_fork);
+
+   if (unlikely(test_tsk_thread_flag(tsk, TIF_DEBUG)))
+   copy_thread_hw_breakpoint(tsk, p, clone_flags);
 #else
kregs->nip = (unsigned long)ret_from_fork;
 #endif
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
@@ -48,6 +48,7 @@
 #include 
 #ifdef CONFIG_PPC64
 #include 
+#include 
 #endif
 
 #ifdef DEBUG
@@ -536,6 +537,7 @@ int __devinit start_secondary(void *unus
 
local_irq_enable();
 
+   load_debug_registers();
cpu_idle();
return 0;
 }

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 5/6] Modify Data storage exception code to recognise DABR match first

[K.Prasad]

Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.

Signed-off-by: K.Prasad 
---
 arch/powerpc/mm/fault.c |   14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

Index: linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/mm/fault.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
@@ -137,6 +137,12 @@ int __kprobes do_page_fault(struct pt_re
error_code &= 0x4820;
else
is_write = error_code & DSISR_ISSTORE;
+
+   if (error_code & DSISR_DABRMATCH) {
+   /* DABR match */
+   do_dabr(regs, address, error_code);
+   return 0;
+   }
 #else
is_write = error_code & ESR_DST;
 #endif /* CONFIG_4xx || CONFIG_BOOKE */
@@ -151,14 +157,6 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) && (address >= TASK_SIZE))
return SIGSEGV;
 
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
-   if (error_code & DSISR_DABRMATCH) {
-   /* DABR match */
-   do_dabr(regs, address, error_code);
-   return 0;
-   }
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
-
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
return SIGSEGV;

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage

[K.Prasad]

Modify kexec code to disable DABR registers before a reboot. Adapt the samples
code to populate PPC64-arch specific fields.

Signed-off-by: K.Prasad 
---
 arch/powerpc/kernel/machine_kexec_64.c  |3 +++
 samples/hw_breakpoint/data_breakpoint.c |4 
 2 files changed, 7 insertions(+)

Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
@@ -24,6 +24,7 @@
 #include   /* _end */
 #include 
 #include 
+#include 
 
 int default_machine_kexec_prepare(struct kimage *image)
 {
@@ -214,6 +215,7 @@ static void kexec_prepare_cpus(void)
put_cpu();
 
local_irq_disable();
+   hw_breakpoint_disable();
 }
 
 #else /* ! SMP */
@@ -233,6 +235,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+   hw_breakpoint_disable();
 }
 
 #endif /* SMP */
Index: linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
===
--- linux-2.6-tip.hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c
+++ linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
@@ -54,6 +54,10 @@ static int __init hw_break_module_init(v
sample_hbp.info.type = HW_BREAKPOINT_WRITE;
sample_hbp.info.len = HW_BREAKPOINT_LEN_4;
 #endif /* CONFIG_X86 */
+#ifdef CONFIG_PPC64
+   sample_hbp.info.name = ksym_name;
+   sample_hbp.info.type = HW_BREAKPOINT_WRITE;
+#endif /* CONFIG_PPC64 */
 
sample_hbp.triggered = (void *)sample_hbp_handler;
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH V3 0/4] mpc5200 audio rework for AC97

[Jon Smirl]

The following series implements audio support for the mpc5200. It adds an AC97 
driver and STAC9766 codec driver. 
Board support for the Efika and Phytec pcm030 are also included.

I've tried to implement the feedback received on the previous two versions.

based on commit 0bc53a67ac831ec84f730a657dbcadd80a589ef5 on broonie/for-2.6.31 
at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git

---

Jon Smirl (4):
  Fabric bindings for STAC9766 on the Efika
  Support for AC97 on Phytec pmc030 base board.
  AC97 driver for mpc5200
  Main rewite of the mpc5200 audio DMA code


 sound/soc/fsl/Kconfig   |   27 ++
 sound/soc/fsl/Makefile  |5 
 sound/soc/fsl/efika-audio-fabric.c  |   95 +++
 sound/soc/fsl/mpc5200_dma.c |  504 +++
 sound/soc/fsl/mpc5200_dma.h |   33 +-
 sound/soc/fsl/mpc5200_psc_ac97.c|  392 +++
 sound/soc/fsl/mpc5200_psc_ac97.h|   15 +
 sound/soc/fsl/mpc5200_psc_i2s.c |  247 +++--
 sound/soc/fsl/mpc5200_psc_i2s.h |   12 +
 sound/soc/fsl/pcm030-audio-fabric.c |   95 +++
 10 files changed, 1036 insertions(+), 389 deletions(-)
 create mode 100644 sound/soc/fsl/efika-audio-fabric.c
 create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
 create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h
 create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
 create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c

-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code

[Jon Smirl]

Rewrite the mpc5200 audio DMA code to support both I2S and AC97.

Signed-off-by: Jon Smirl 
---
 sound/soc/fsl/Kconfig   |1 
 sound/soc/fsl/mpc5200_dma.c |  504 ++-
 sound/soc/fsl/mpc5200_dma.h |   33 +--
 sound/soc/fsl/mpc5200_psc_i2s.c |  247 +++
 sound/soc/fsl/mpc5200_psc_i2s.h |   12 +
 5 files changed, 408 insertions(+), 389 deletions(-)
 create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index dc79bdf..1918c78 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -25,7 +25,6 @@ config SND_SOC_MPC8610_HPCD
 config SND_SOC_MPC5200_I2S
tristate "Freescale MPC5200 PSC in I2S mode driver"
depends on PPC_MPC52xx && PPC_BESTCOMM
-   select SND_SOC_OF_SIMPLE
select SND_MPC52xx_DMA
select PPC_BESTCOMM_GEN_BD
help
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 6850392..4e1f1f8 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -3,23 +3,13 @@
  * ALSA SoC Platform driver
  *
  * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
  */
 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
 
 #include 
 #include 
@@ -27,10 +17,6 @@
 
 #include "mpc5200_dma.h"
 
-MODULE_AUTHOR("Grant Likely ");
-MODULE_DESCRIPTION("Freescale MPC5200 PSC in DMA mode ASoC Driver");
-MODULE_LICENSE("GPL");
-
 /*
  * Interrupt handlers
  */
@@ -50,7 +36,7 @@ static irqreturn_t psc_dma_status_irq(int irq, void *_psc_dma)
if (psc_dma->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
psc_dma->stats.overrun_count++;
 
-   out_8(®s->command, 4 << 4);  /* reset the error status */
+   out_8(®s->command, MPC52xx_PSC_RST_ERR_STAT);
 
return IRQ_HANDLED;
 }
@@ -81,8 +67,21 @@ static void psc_dma_bcom_enqueue_next_buffer(struct 
psc_dma_stream *s)
s->period_next_pt = s->period_start;
 }
 
+static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream *s)
+{
+   while (s->appl_ptr < s->runtime->control->appl_ptr) {
+
+   if (bcom_queue_full(s->bcom_task))
+   return;
+
+   s->appl_ptr += s->period_size;
+
+   psc_dma_bcom_enqueue_next_buffer(s);
+   }
+}
+
 /* Bestcomm DMA irq handler */
-static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
+static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
 {
struct psc_dma_stream *s = _psc_dma_stream;
 
@@ -90,12 +89,12 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void 
*_psc_dma_stream)
 * and enqueue a new one in it's place. */
while (bcom_buffer_done(s->bcom_task)) {
bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
+
s->period_current_pt += s->period_bytes;
if (s->period_current_pt >= s->period_end)
s->period_current_pt = s->period_start;
-   psc_dma_bcom_enqueue_next_buffer(s);
-   bcom_enable(s->bcom_task);
}
+   psc_dma_bcom_enqueue_tx(s);
 
/* If the stream is active, then also inform the PCM middle layer
 * of the period finished event. */
@@ -105,49 +104,31 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void 
*_psc_dma_stream)
return IRQ_HANDLED;
 }
 
-/**
- * psc_dma_startup: create a new substream
- *
- * This is the first function called when a stream is opened.
- *
- * If this is the first stream open, then grab the IRQ and program most of
- * the PSC registers.
- */
-int psc_dma_startup(struct snd_pcm_substream *substream,
-  struct snd_soc_dai *dai)
+static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
 {
-   struct snd_soc_pcm_runtime *rtd = substream->private_data;
-   struct psc_dma *psc_dma = rtd->dai->cpu_dai->private_data;
-   int rc;
+   struct psc_dma_stream *s = _psc_dma_stream;
 
-   dev_dbg(psc_dma->dev, "psc_dma_startup(substream=%p)\n", substream);
+   /* For each finished period, dequeue the completed period buffer
+* and enqueue a new one in it's place. */
+   while (bcom_buffer_done(s->bcom_task)) {
+   bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
 
-   if (!psc_dma->playback.active &&
-   !psc_dma->capture.active) {
-   /* Setup the IRQs */
-   rc = request_irq(psc_dma->irq, &psc_dma_status_irq, IRQF_SHARED,
-"psc-dma-status", psc_dma);
-   rc |= request_irq(psc_dma->capture.irq,
- &psc_dma_bcom_irq, IRQF_SHARED,
- "psc-dma-capture", &psc_dma->capture);
-   rc |= request_irq(psc_dma->playback.irq,
- &psc_dma_bcom_i

[PATCH V3 2/4] AC97 driver for mpc5200

[Jon Smirl]

AC97 driver for mpc5200

I've implemented retries for when the AC97 hardware doesn't reset on
first try. About 10% of the time both the Efika and pcm030 AC97 codecs
don't reset on first try and need to be poked multiple times.  Failure
is indicated by not having the link clock start ticking. Every once in
a while even five pokes won't get the link started and I have to power
cycle.

Signed-off-by: Jon Smirl 
---
 sound/soc/fsl/Kconfig|   11 +
 sound/soc/fsl/Makefile   |1 
 sound/soc/fsl/mpc5200_psc_ac97.c |  392 ++
 sound/soc/fsl/mpc5200_psc_ac97.h |   15 +
 4 files changed, 419 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
 create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 1918c78..3bce952 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -29,3 +29,14 @@ config SND_SOC_MPC5200_I2S
select PPC_BESTCOMM_GEN_BD
help
  Say Y here to support the MPC5200 PSCs in I2S mode.
+
+config SND_SOC_MPC5200_AC97
+   tristate "Freescale MPC5200 PSC in AC97 mode driver"
+   depends on PPC_MPC52xx && PPC_BESTCOMM
+   select AC97_BUS
+   select SND_MPC52xx_DMA
+   select PPC_BESTCOMM_GEN_BD
+   help
+ Say Y here to support the MPC5200 PSCs in AC97 mode.
+
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 7731ef2..14631a1 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_SND_SOC_MPC8610) += snd-soc-fsl-ssi.o 
snd-soc-fsl-dma.o
 # MPC5200 Platform Support
 obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
 obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
+obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
 
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
new file mode 100644
index 000..480b677
--- /dev/null
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -0,0 +1,392 @@
+/*
+ * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip.
+ *
+ * Copyright (C) 2009 Jon Smirl, Digispeaker
+ * Author: Jon Smirl 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "mpc5200_dma.h"
+#include "mpc5200_psc_ac97.h"
+
+#define DRV_NAME "mpc5200-psc-ac97"
+
+/* ALSA only supports a single AC97 device so static is recommend here */
+static struct psc_dma *psc_dma;
+
+static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg)
+{
+   int timeout;
+   unsigned int val;
+
+   spin_lock(&psc_dma->lock);
+
+   /* Wait for it to be ready */
+   timeout = 1000;
+   while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr.status) &
+   MPC52xx_PSC_SR_CMDSEND))
+   udelay(10);
+
+   if (!timeout) {
+   pr_err("timeout on ac97 bus (rdy)\n");
+   return 0x;
+   }
+
+   /* Do the read */
+   out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 24));
+
+   /* Wait for the answer */
+   timeout = 1000;
+   while ((--timeout) && !(in_be16(&psc_dma->psc_regs->sr_csr.status) &
+   MPC52xx_PSC_SR_DATA_VAL))
+   udelay(10);
+
+   if (!timeout) {
+   pr_err("timeout on ac97 read (val) %x\n",
+   in_be16(&psc_dma->psc_regs->sr_csr.status));
+   return 0x;
+   }
+
+   /* Get the data */
+   val = in_be32(&psc_dma->psc_regs->ac97_data);
+   if (((val>>24) & 0x7f) != reg) {
+   pr_err("reg echo error on ac97 read\n");
+   return 0x;
+   }
+   val = (val >> 8) & 0x;
+
+   spin_unlock(&psc_dma->lock);
+   return (unsigned short) val;
+}
+
+static void psc_ac97_write(struct snd_ac97 *ac97,
+   unsigned short reg, unsigned short val)
+{
+   int timeout;
+
+   spin_lock(&psc_dma->lock);
+
+   /* Wait for it to be ready */
+   timeout = 1000;
+   while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr.status) &
+   MPC52xx_PSC_SR_CMDSEND))
+   udelay(10);
+
+   if (!timeout) {
+   pr_err("timeout on ac97 write\n");
+   return;
+   }
+
+   /* Write data */
+   out_be32(&psc_dma->psc_regs->ac97_cmd,
+   ((reg & 0x7f) << 24) | (val << 8));
+
+   spin_unlock(&psc_dma->lock);
+}
+
+static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
+{
+   struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
+
+   out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
+   udela

[PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.

[Jon Smirl]

Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.

Signed-off-by: Jon Smirl 
---
 sound/soc/fsl/Kconfig   |7 +++
 sound/soc/fsl/Makefile  |3 +
 sound/soc/fsl/pcm030-audio-fabric.c |   95 +++
 3 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 3bce952..79579ae 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -39,4 +39,11 @@ config SND_SOC_MPC5200_AC97
help
  Say Y here to support the MPC5200 PSCs in AC97 mode.
 
+config SND_MPC52xx_SOC_PCM030
+   tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
+   depends on PPC_MPC5200_SIMPLE
+   select SND_SOC_MPC5200_AC97
+   select SND_SOC_WM9712
+   help
+ Say Y if you want to add support for sound on the Phytec pcm030 
baseboard.
 
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 14631a1..66d88c8 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
 obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
 obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
 
+# MPC5200 Machine Support
+obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c 
b/sound/soc/fsl/pcm030-audio-fabric.c
new file mode 100644
index 000..2c426d5
--- /dev/null
+++ b/sound/soc/fsl/pcm030-audio-fabric.c
@@ -0,0 +1,95 @@
+/*
+ * Phytec pcm030 driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mpc5200_dma.h"
+#include "mpc5200_psc_ac97.h"
+#include "../codecs/wm9712.h"
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+static struct snd_soc_dai_link pcm030_fabric_dai[] = {
+{
+   .name = "AC97",
+   .stream_name = "AC97 Analog",
+   .codec_dai = &wm9712_dai[WM9712_DAI_AC97_HIFI],
+   .cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
+},
+{
+   .name = "AC97",
+   .stream_name = "AC97 IEC958",
+   .codec_dai = &wm9712_dai[WM9712_DAI_AC97_AUX],
+   .cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
+},
+};
+
+static __init int pcm030_fabric_init(void)
+{
+   struct platform_device *pdev;
+   int rc;
+
+   if (!machine_is_compatible("phytec,pcm030"))
+   return -ENODEV;
+
+   card.platform = &mpc5200_audio_dma_platform;
+   card.name = "pcm030";
+   card.dai_link = pcm030_fabric_dai;
+   card.num_links = ARRAY_SIZE(pcm030_fabric_dai);
+
+   device.card = &card;
+   device.codec_dev = &soc_codec_dev_wm9712;
+
+   pdev = platform_device_alloc("soc-audio", 1);
+   if (!pdev) {
+   pr_err("pcm030_fabric_init: platform_device_alloc() failed\n");
+   return -ENODEV;
+   }
+
+   platform_set_drvdata(pdev, &device);
+   device.dev = &pdev->dev;
+
+   rc = platform_device_add(pdev);
+   if (rc) {
+   pr_err("pcm030_fabric_init: platform_device_add() failed\n");
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static __exit void pcm030_fabric_exit(void)
+{
+}
+
+module_init(pcm030_fabric_init);
+module_exit(pcm030_fabric_exit);
+
+
+MODULE_AUTHOR("Jon Smirl ");
+MODULE_DESCRIPTION(DRV_NAME ": mpc5200 pcm030 fabric driver");
+MODULE_LICENSE("GPL");
+

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH V3 4/4] Fabric bindings for STAC9766 on the Efika

[Jon Smirl]

Fabric bindings for STAC9766 AC97 codec on the Efika.

Signed-off-by: Jon Smirl 
---
 sound/soc/fsl/Kconfig  |8 +++
 sound/soc/fsl/Makefile |1 
 sound/soc/fsl/efika-audio-fabric.c |   95 
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/fsl/efika-audio-fabric.c

diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 79579ae..f571c6e 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -47,3 +47,11 @@ config SND_MPC52xx_SOC_PCM030
help
  Say Y if you want to add support for sound on the Phytec pcm030 
baseboard.
 
+config SND_MPC52xx_SOC_EFIKA
+   tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
+   depends on PPC_EFIKA
+   select SND_SOC_MPC5200_AC97
+   select SND_SOC_STAC9766
+   help
+ Say Y if you want to add support for sound on the Efika.
+
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 66d88c8..a83a739 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
 
 # MPC5200 Machine Support
 obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
+obj-$(CONFIG_SND_MPC52xx_SOC_EFIKA) += efika-audio-fabric.o
 
diff --git a/sound/soc/fsl/efika-audio-fabric.c 
b/sound/soc/fsl/efika-audio-fabric.c
new file mode 100644
index 000..4b7ed2b
--- /dev/null
+++ b/sound/soc/fsl/efika-audio-fabric.c
@@ -0,0 +1,95 @@
+/*
+ * Efika driver for the PSC of the Freescale MPC52xx
+ * configured as AC97 interface
+ *
+ * Copyright 2008 Jon Smirl, Digispeaker
+ * Author: Jon Smirl 
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mpc5200_dma.h"
+#include "mpc5200_psc_ac97.h"
+#include "../codecs/stac9766.h"
+
+static struct snd_soc_device device;
+static struct snd_soc_card card;
+
+static struct snd_soc_dai_link efika_fabric_dai[] = {
+{
+   .name = "AC97",
+   .stream_name = "AC97 Analog",
+   .codec_dai = &stac9766_dai[STAC9766_DAI_AC97_ANALOG],
+   .cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
+},
+{
+   .name = "AC97",
+   .stream_name = "AC97 IEC958",
+   .codec_dai = &stac9766_dai[STAC9766_DAI_AC97_DIGITAL],
+   .cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
+},
+};
+
+static __init int efika_fabric_init(void)
+{
+   struct platform_device *pdev;
+   int rc;
+
+   if (!machine_is_compatible("bplan,efika"))
+   return -ENODEV;
+
+   card.platform = &mpc5200_audio_dma_platform;
+   card.name = "Efika";
+   card.dai_link = efika_fabric_dai;
+   card.num_links = ARRAY_SIZE(efika_fabric_dai);
+
+   device.card = &card;
+   device.codec_dev = &soc_codec_dev_stac9766;
+
+   pdev = platform_device_alloc("soc-audio", 1);
+   if (!pdev) {
+   pr_err("efika_fabric_init: platform_device_alloc() failed\n");
+   return -ENODEV;
+   }
+
+   platform_set_drvdata(pdev, &device);
+   device.dev = &pdev->dev;
+
+   rc = platform_device_add(pdev);
+   if (rc) {
+   pr_err("efika_fabric_init: platform_device_add() failed\n");
+   return -ENODEV;
+   }
+   return 0;
+}
+
+static __exit void efika_fabric_exit(void)
+{
+}
+
+module_init(efika_fabric_init);
+module_exit(efika_fabric_exit);
+
+
+MODULE_AUTHOR("Jon Smirl ");
+MODULE_DESCRIPTION(DRV_NAME ": mpc5200 Efika fabric driver");
+MODULE_LICENSE("GPL");
+

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Arnd Bergmann]

On Monday 25 May 2009, Benjamin Herrenschmidt wrote:
> Note that I still think the right approach in the long run is to ban the
> consistent allocs from atomic contexts generically in linux, though that
> will be a hard nut to crack.

I might be missing too much context here, but can't we make drivers that
need this allocate an uncached memory range at setup time and call
dma_declare_coherent_memory() on that to make a later dma_alloc_coherent()
succeed without GFP_KERNEL?

If that is not enough, dma_alloc_coherent could be changed to
try dma_alloc_from_coherent() on the bridge device (PCI HB,
PLB4, ...), if we reserve a reasonably sized amount of uncached
memory for each bridge that has noncoherent devices.

Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

can't flush tlb on e500

[Hideo Saito]

Hi all,

This report came from LKML, although I should post it here first,
the report said that there is a regression in linux-2.6.29 as to flushing a TLB 
entry that was going to be re-used when a context overflowed from the TLB.

On Fri, May 22, 2009 at 6:27 PM, Benjamin Herrenschmidt wrote:
> Have you verified that this change fixes your problem ?

I tested using "hackbench 100" and it was done successfully on my platform with 
e500(MPC8548).

>
> Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along with
> proper changeset comment and signed-off-by: line ?

I am sorry I don't know as to the proper changeset comment.

Signed-off-by: Hideo Saito 
---
--- arch/powerpc/mm/mmu_context_nohash.c.orig   2009-03-24 08:12:14.0 
+0900
+++ arch/powerpc/mm/mmu_context_nohash.c2009-05-20 18:33:53.0 
+0900
@@ -122,22 +122,22 @@ static unsigned int steal_context_up(uns
struct mm_struct *mm;
int cpu = smp_processor_id();
 
/* Pick up the victim mm */
mm = context_mm[id];
 
pr_debug("[%d] steal context %d from mm @%p\n", cpu, id, mm);
 
-   /* Mark this mm has having no context anymore */
-   mm->context.id = MMU_NO_CONTEXT;
-
/* Flush the TLB for that context */
local_flush_tlb_mm(mm);
 
+   /* Mark this mm has having no context anymore */
+   mm->context.id = MMU_NO_CONTEXT;
+
/* XXX This clear should ultimately be part of local_flush_tlb_mm */
__clear_bit(id, stale_map[cpu]);
 
return id;
 }
 
 #ifdef DEBUG_MAP_CONSISTENCY
 static void context_check_map(void)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: can't flush tlb on e500

[Benjamin Herrenschmidt]

On Mon, 2009-05-25 at 10:33 +0900, Hideo Saito wrote:
> 
> This report came from LKML, although I should post it here first,
> the report said that there is a regression in linux-2.6.29 as to
> flushing a TLB entry that was going to be re-used when a context
> overflowed from the TLB.
> 
> On Fri, May 22, 2009 at 6:27 PM, Benjamin Herrenschmidt wrote:
> > Have you verified that this change fixes your problem ?
> 
> I tested using "hackbench 100" and it was done successfully on my
> platform with e500(MPC8548).
> 
> >
> > Can you re-submit to linuxppc-dev@ozlabs.org mailing list, along
> with
> > proper changeset comment and signed-off-by: line ?
> 
> I am sorry I don't know as to the proper changeset comment.
> 
Well, that simply means a proper description of the bug and
the fix :-)

I'll cook up one.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Benjamin Herrenschmidt]

On Mon, 2009-05-25 at 02:43 +0100, Arnd Bergmann wrote:
> I might be missing too much context here, but can't we make drivers
> that
> need this allocate an uncached memory range at setup time and call
> dma_declare_coherent_memory() on that to make a later
> dma_alloc_coherent()
> succeed without GFP_KERNEL?

That isn't that much different, and still needs a dedicated allocator
which is pretty much what I'm trying to get rid of.

It would make everybody's life easier if we just banned those
allocations from atomic contexts :-)

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Benjamin Herrenschmidt]

(Please, Kumar, have a good look, especially my change to FIXMAP_TOP,
was there any reason it wasn't a constant in the first place ?)

This is going to .30 if nobody hollers. I've done some testing here
and it seems to be fine, but more eyes at this stage are much welcome.

From: Benjamin Herrenschmidt 
Date: Mon, 25 May 2009 14:24:43 +1000
Subject: [PATCH] Revert "powerpc: Rework dma-noncoherent to use generic vmalloc 
layer"

This reverts commit 33f00dcedb0e22cdb156a23632814fc580fcfcf8

 ... sort-of, the revived dma-noncoherent is modified from the
 previous variant in a handful of ways, mostly because the
 way we lay out our address space changed and I don't want
 to revive a broken config option and try to find "safe"
 values for all platforms (hint: there's none).

The result is a lot more invasive than I would have liked at this
stage, but I felt we had little choice here.

 - We can no longer set the virtual address of the coherent mapping
   (this was a big no-no) it's now fit between vmalloc/ioremap and
   PKMAP (or 0xfe00 for !CONFIG_HIGHMEM, this arbitrary limit
   must die but that's work for a different patch)

 - Due to the above, I had to do some small changes to various files
   to make FIXADDR_TOP a compile time constant (why wasn't it so ?)
   and cleaner definitions of where bits of the kernel address space
   are located in pgtable_ppc32.h

 - To ease debugging, we now print out the layout of the kernel
   virtual address space at boot time on ppc32

 - The code in dma-noncoherent.c was mostly lifted from ARM, though
   the later had a few updates related to checking the DMA mask we
   never brought over. This is now done.

 - To avoid wasting a whole lot more address space than needed, rather
   than keeping the old assumption that all PTEs for consistent memory
   fit in a single PTE page and do PTE pointer manipulations, I instead
   use our existing map_page() helper to create the mappings which is
   also simpler. Thus, the consistent memory area has no limitations on
   size and alignment now. This is a little bit slower but that shouldn't
   matter as dma_alloc_coherent() shouldn't be a fast path. Similar fixes
   went into the freeing path

 - Finally, because it made more sense and because i wanted to include
   headers local from that directory, I moved dma-noncoherent.c from
   arch/powerpc/lib to arch/powerpc/mm

The reason for the revert is that while it was a good idea to try to
use the mm/vmalloc.c allocator instead of our own (in fact, ours is
itself a dup on an old variant of the vmalloc one), unfortunately,
the approach is terminally busted since dma_alloc_coherent() can be
called at interrupt time or in atomic contexts and there's little
chances we'll make the code in mm/vmalloc.c cope with that :-(

Until we can get the generic code to forbid that idiocy and fix all
drivers abusing it, we pretty much have no choice but revert to
our custom virtual space allocator.

There's also a problem with SMP safety since freeing such mapping
would require an IPI which cannot be done at interrupt time.

However, right now, I don't think we support any platform that is
both SMP and has non-coherent DMA (don't laugh, I know such things
do exist !) so we can sort that out later.

Signed-off-by: Benjamin Herrenschmidt 
---
 arch/powerpc/Kconfig |   12 +
 arch/powerpc/include/asm/dma-mapping.h   |6 +-
 arch/powerpc/include/asm/fixmap.h|4 +-
 arch/powerpc/include/asm/pgtable-ppc32.h |   25 ++-
 arch/powerpc/kernel/dma.c|2 +-
 arch/powerpc/lib/Makefile|1 -
 arch/powerpc/lib/dma-noncoherent.c   |  237 --
 arch/powerpc/mm/Makefile |1 +
 arch/powerpc/mm/dma-noncoherent.c|  400 ++
 arch/powerpc/mm/init_32.c|8 +-
 arch/powerpc/mm/mem.c|   19 ++
 arch/powerpc/mm/pgtable_32.c |2 -
 12 files changed, 464 insertions(+), 253 deletions(-)
 delete mode 100644 arch/powerpc/lib/dma-noncoherent.c
 create mode 100644 arch/powerpc/mm/dma-noncoherent.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index a0d1146..cdc9a6f 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -868,6 +868,18 @@ config TASK_SIZE
default "0x8000" if PPC_PREP || PPC_8xx
default "0xc000"
 
+config CONSISTENT_SIZE_BOOL
+   bool "Set custom consistent memory pool size"
+   depends on ADVANCED_OPTIONS && NOT_COHERENT_CACHE
+   help
+ This option allows you to set the size of the
+ consistent memory pool.  This pool of virtual memory
+ is used to make consistent memory allocations.
+
+config CONSISTENT_SIZE
+   hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
+   default "0x0020" if NOT_COHERENT_CACHE
+
 config PIN_TLB
bool "Pinned Kernel TLBs (860 ONLY)"
depends on ADVANCED_OPTIONS && 8xx

Wrong looking statement in cpm_common.c

[Benjamin Herrenschmidt]

Hi Scott !

There's this pearl in cpm_common.c :

void __init udbg_init_cpm(void)
{
if (cpm_udbg_txdesc) {
#ifdef CONFIG_CPM2
setbat(1, 0xf000, 0xf000, 1024*1024, PAGE_KERNEL_NCG);
#endif
udbg_putc = udbg_putc_cpm;
}
}

Now, last I looked, 0xf000 (virtual) lands about right in the middle
of the vmalloc space... so unless there's code somewhere that I missed
that reserves that region of virtual space for use by that crap above,
I think somebody is in trouble :-)

Additionally, that's the last user of setbat that I can find outside
of the linear mapping setup proper, so scott, once you've fixed that
I'll happily make setbat static once for all. We -can- still provide
a facility for using BATs for early ioremap's but that should be done
properly, not by whacking setbat with random hard wired virtual
addresses.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Grant Likely]

On Sun, May 24, 2009 at 10:33 PM, Benjamin Herrenschmidt
 wrote:
> This is going to .30 if nobody hollers. I've done some testing here
> and it seems to be fine, but more eyes at this stage are much welcome.

Looks okay to me; but I'm not an expert in this area.  Boots fine on
Xilinx Virtex 440 and MPC5200.  One minor nit below.

Acked-by: Grant Likely 

> +#ifdef CONFIG_PPC32
> +       printk(KERN_INFO "Kernel virtual memory layout:\n");
> +       printk(KERN_INFO "  * 0x%08lx..0x%08lx  : fixmap\n",
> +              FIXADDR_START, FIXADDR_TOP);
> +#ifdef CONFIG_HIGHMEM
> +       printk(KERN_INFO "  * 0x%08lx..0x%08lx  : highmem PTEs\n",
> +              PKMAP_BASE, PKMAP_ADDR(LAST_PKMAP));
> +#endif /* CONFIG_HIGHMEM */
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> +       printk(KERN_INFO "  * 0x%08lx..0x%08lx  : consistent mem\n",
> +              IOREMAP_TOP, IOREMAP_TOP + CONFIG_CONSISTENT_SIZE);
> +#endif /* CONFIG_NOT_COHERENT_CACHE */
> +       printk(KERN_INFO "  * 0x%08lx..0x%08lx  : early ioremap\n",
> +              ioremap_bot, IOREMAP_TOP);
> +       printk(KERN_INFO "  * 0x%08lx..0x%08lx  : vmalloc & ioremap\n",
> +              VMALLOC_START, VMALLOC_END);
> +#endif /* CONFIG_PPC32 */

NIT: pr_info().  Same goes for other printk's in this patch.

It would also be nice for comprehension if the file move and the
modification were separate commits.  As it is I had to generate the
diff manually, but I'm not concerned.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: AMCC 405ex memory size issue

[konamo]

any ideas?



konamo wrote:
> 
> Hi all,
>   we are using AMCC 405ex kilauea eval board as a demo, not use any
> pci/nand function, 
> the board configuration is below:
> u-boot 2009.01, 
> linux-2.6.25-rc2, 
> 1GB DDR2 memory(2Gbit * 4, 1 rank), 
> AMCC powerpc 405ex, 
> both 1G and 512MB memory works fine under u-boot, but linux boot fails in
> 1G memory, if we limit mem=512M, linux could boot over nfs. Could anyone
> pls help us how to find the root cause? thanks
> 

-- 
View this message in context: 
http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23701685.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V3 2/4] AC97 driver for mpc5200

[Grant Likely]

On Sun, May 24, 2009 at 7:38 PM, Jon Smirl  wrote:
> AC97 driver for mpc5200
>
> I've implemented retries for when the AC97 hardware doesn't reset on
> first try. About 10% of the time both the Efika and pcm030 AC97 codecs
> don't reset on first try and need to be poked multiple times.  Failure
> is indicated by not having the link clock start ticking. Every once in
> a while even five pokes won't get the link started and I have to power
> cycle.
>
> Signed-off-by: Jon Smirl 
> ---
>  sound/soc/fsl/Kconfig            |   11 +
>  sound/soc/fsl/Makefile           |    1
>  sound/soc/fsl/mpc5200_psc_ac97.c |  392 
> ++
>  sound/soc/fsl/mpc5200_psc_ac97.h |   15 +
>  4 files changed, 419 insertions(+), 0 deletions(-)
>  create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c
>  create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 1918c78..3bce952 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -29,3 +29,14 @@ config SND_SOC_MPC5200_I2S
>        select PPC_BESTCOMM_GEN_BD
>        help
>          Say Y here to support the MPC5200 PSCs in I2S mode.
> +
> +config SND_SOC_MPC5200_AC97
> +       tristate "Freescale MPC5200 PSC in AC97 mode driver"
> +       depends on PPC_MPC52xx && PPC_BESTCOMM
> +       select AC97_BUS
> +       select SND_MPC52xx_DMA
> +       select PPC_BESTCOMM_GEN_BD
> +       help
> +         Say Y here to support the MPC5200 PSCs in AC97 mode.
> +
> +
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index 7731ef2..14631a1 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -13,4 +13,5 @@ obj-$(CONFIG_SND_SOC_MPC8610) += snd-soc-fsl-ssi.o 
> snd-soc-fsl-dma.o
>  # MPC5200 Platform Support
>  obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
>  obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
> +obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
>
> diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c 
> b/sound/soc/fsl/mpc5200_psc_ac97.c
> new file mode 100644
> index 000..480b677
> --- /dev/null
> +++ b/sound/soc/fsl/mpc5200_psc_ac97.c
> @@ -0,0 +1,392 @@
> +/*
> + * linux/sound/mpc5200-ac97.c -- AC97 support for the Freescale MPC52xx chip.
> + *
> + * Copyright (C) 2009 Jon Smirl, Digispeaker
> + * Author: Jon Smirl 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "mpc5200_dma.h"
> +#include "mpc5200_psc_ac97.h"
> +
> +#define DRV_NAME "mpc5200-psc-ac97"
> +
> +/* ALSA only supports a single AC97 device so static is recommend here */
> +static struct psc_dma *psc_dma;
> +
> +static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short 
> reg)
> +{
> +       int timeout;
> +       unsigned int val;
> +
> +       spin_lock(&psc_dma->lock);
> +
> +       /* Wait for it to be ready */
> +       timeout = 1000;
> +       while ((--timeout) && (in_be16(&psc_dma->psc_regs->sr_csr.status) &
> +                                               MPC52xx_PSC_SR_CMDSEND))
> +               udelay(10);

Holy unbounded latency Batman!  This code waits up to 10ms for a register read!

I hate spinning, but if it must be done; I'd like to see it small.
What is the worst case latency? 125us for 8000Hz bus speed?  If you
must spin; can a cpu_relax() be used instead of the udelay() while
watch the timebase?  Timur recently posted a patch which makes this
easier.

http://patchwork.ozlabs.org/patch/27414/

They *should* be appearing in Ben's -next branch soon.

> +
> +       if (!timeout) {
> +               pr_err("timeout on ac97 bus (rdy)\n");
> +               return 0x;
> +       }
> +
> +       /* Do the read */
> +       out_be32(&psc_dma->psc_regs->ac97_cmd, (1<<31) | ((reg & 0x7f) << 
> 24));
> +
> +       /* Wait for the answer */
> +       timeout = 1000;
> +       while ((--timeout) && !(in_be16(&psc_dma->psc_regs->sr_csr.status) &
> +                                               MPC52xx_PSC_SR_DATA_VAL))
> +               udelay(10);

ditto.

> +static int psc_ac97_cold_reset_check(struct snd_ac97 *ac97)
> +{
> +       int max_reset, timeout;
> +       struct mpc52xx_psc __iomem *regs = psc_dma->psc_regs;
> +
> +       /* AC97 clock is generated by the codec.
> +        * Ensure that it starts ticking after codec reset.
> +        */
> +       for (max_reset = 0; max_reset < 5; max_reset++) {
> +
> +               /* Do a cold reset */
> +               out_8(®s->op1, MPC52xx_PSC_OP_RES);
> +               udelay(10);
> +               out_8(®s->op0, MPC52xx_PSC_OP_RES);
> +               udelay(50);

:-/  Don't like, but don't know if there is an alternative.

> +
> +               /* PSC recover from cold reset
> +                * (cfr user

Re: [PATCH V3 1/4] Main rewite of the mpc5200 audio DMA code

[Grant Likely]

On Sun, May 24, 2009 at 7:38 PM, Jon Smirl  wrote:
> Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
>
> Signed-off-by: Jon Smirl 
> ---
>  sound/soc/fsl/Kconfig           |    1
>  sound/soc/fsl/mpc5200_dma.c     |  504 
> ++-
>  sound/soc/fsl/mpc5200_dma.h     |   33 +--
>  sound/soc/fsl/mpc5200_psc_i2s.c |  247 +++
>  sound/soc/fsl/mpc5200_psc_i2s.h |   12 +
>  5 files changed, 408 insertions(+), 389 deletions(-)
>  create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index dc79bdf..1918c78 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -25,7 +25,6 @@ config SND_SOC_MPC8610_HPCD
>  config SND_SOC_MPC5200_I2S
>        tristate "Freescale MPC5200 PSC in I2S mode driver"
>        depends on PPC_MPC52xx && PPC_BESTCOMM
> -       select SND_SOC_OF_SIMPLE
>        select SND_MPC52xx_DMA
>        select PPC_BESTCOMM_GEN_BD
>        help
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index 6850392..4e1f1f8 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -3,23 +3,13 @@
>  * ALSA SoC Platform driver
>  *
>  * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + * Copyright (C) 2009 Jon Smirl, Digispeaker
>  */
>
> -#include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
>
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
>
>  #include 
>  #include 
> @@ -27,10 +17,6 @@
>
>  #include "mpc5200_dma.h"
>
> -MODULE_AUTHOR("Grant Likely ");
> -MODULE_DESCRIPTION("Freescale MPC5200 PSC in DMA mode ASoC Driver");
> -MODULE_LICENSE("GPL");
> -
>  /*
>  * Interrupt handlers
>  */
> @@ -50,7 +36,7 @@ static irqreturn_t psc_dma_status_irq(int irq, void 
> *_psc_dma)
>        if (psc_dma->capture.active && (isr & MPC52xx_PSC_IMR_ORERR))
>                psc_dma->stats.overrun_count++;
>
> -       out_8(®s->command, 4 << 4);  /* reset the error status */
> +       out_8(®s->command, MPC52xx_PSC_RST_ERR_STAT);
>
>        return IRQ_HANDLED;
>  }
> @@ -81,8 +67,21 @@ static void psc_dma_bcom_enqueue_next_buffer(struct 
> psc_dma_stream *s)
>                s->period_next_pt = s->period_start;
>  }
>
> +static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream *s)
> +{
> +       while (s->appl_ptr < s->runtime->control->appl_ptr) {
> +
> +               if (bcom_queue_full(s->bcom_task))
> +                       return;
> +
> +               s->appl_ptr += s->period_size;
> +
> +               psc_dma_bcom_enqueue_next_buffer(s);
> +       }
> +}
> +
>  /* Bestcomm DMA irq handler */
> -static irqreturn_t psc_dma_bcom_irq(int irq, void *_psc_dma_stream)
> +static irqreturn_t psc_dma_bcom_irq_tx(int irq, void *_psc_dma_stream)
>  {
>        struct psc_dma_stream *s = _psc_dma_stream;
>
> @@ -90,12 +89,12 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void 
> *_psc_dma_stream)
>         * and enqueue a new one in it's place. */
>        while (bcom_buffer_done(s->bcom_task)) {
>                bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
> +
>                s->period_current_pt += s->period_bytes;
>                if (s->period_current_pt >= s->period_end)
>                        s->period_current_pt = s->period_start;
> -               psc_dma_bcom_enqueue_next_buffer(s);
> -               bcom_enable(s->bcom_task);
>        }
> +       psc_dma_bcom_enqueue_tx(s);
>
>        /* If the stream is active, then also inform the PCM middle layer
>         * of the period finished event. */
> @@ -105,49 +104,31 @@ static irqreturn_t psc_dma_bcom_irq(int irq, void 
> *_psc_dma_stream)
>        return IRQ_HANDLED;
>  }
>
> -/**
> - * psc_dma_startup: create a new substream
> - *
> - * This is the first function called when a stream is opened.
> - *
> - * If this is the first stream open, then grab the IRQ and program most of
> - * the PSC registers.
> - */
> -int psc_dma_startup(struct snd_pcm_substream *substream,
> -                          struct snd_soc_dai *dai)
> +static irqreturn_t psc_dma_bcom_irq_rx(int irq, void *_psc_dma_stream)
>  {
> -       struct snd_soc_pcm_runtime *rtd = substream->private_data;
> -       struct psc_dma *psc_dma = rtd->dai->cpu_dai->private_data;
> -       int rc;
> +       struct psc_dma_stream *s = _psc_dma_stream;
>
> -       dev_dbg(psc_dma->dev, "psc_dma_startup(substream=%p)\n", substream);
> +       /* For each finished period, dequeue the completed period buffer
> +        * and enqueue a new one in it's place. */
> +       while (bcom_buffer_done(s->bcom_task)) {
> +               bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
>
> -       if (!psc_dma->playback.active &&
> -           !psc_dma->capture.active) {
> -               /* Setup the IRQs */
> -               rc = request_irq(psc_dma->irq, &psc_dma_status_irq, 
> IRQF_SHARED,
> -                                "psc-dma-status", psc_dma);
> - 

[PATCH] powerpc/pmac: Update PowerMac 32-bit defconfig

[Benjamin Herrenschmidt]

This mostly adds back AppleTouch support and adds CONFIG_HIGHMEM
by default.

Signed-off-by: Benjamin Herrenschmidt 
---

 arch/powerpc/configs/pmac32_defconfig |  278 +++---
 1 file changed, 195 insertions(+), 83 deletions(-)

--- linux-work.orig/arch/powerpc/configs/pmac32_defconfig   2009-05-25 
14:54:05.0 +1000
+++ linux-work/arch/powerpc/configs/pmac32_defconfig2009-05-25 
14:54:08.0 +1000
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.28-rc3
-# Tue Nov 11 19:36:51 2008
+# Linux kernel version: 2.6.30-rc7
+# Mon May 25 14:53:25 2009
 #
 # CONFIG_PPC64 is not set
 
@@ -14,6 +14,7 @@ CONFIG_6xx=y
 # CONFIG_40x is not set
 # CONFIG_44x is not set
 # CONFIG_E200 is not set
+CONFIG_PPC_BOOK3S=y
 CONFIG_PPC_FPU=y
 CONFIG_ALTIVEC=y
 CONFIG_PPC_STD_MMU=y
@@ -43,7 +44,7 @@ CONFIG_GENERIC_FIND_NEXT_BIT=y
 CONFIG_PPC=y
 CONFIG_EARLY_PRINTK=y
 CONFIG_GENERIC_NVRAM=y
-CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_SCHED_OMIT_FRAME_POINTER=y
 CONFIG_ARCH_MAY_HAVE_PC_FDC=y
 CONFIG_PPC_OF=y
 CONFIG_OF=y
@@ -52,12 +53,14 @@ CONFIG_OF=y
 CONFIG_AUDIT_ARCH=y
 CONFIG_GENERIC_BUG=y
 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
+CONFIG_DTC=y
 # CONFIG_DEFAULT_UIMAGE is not set
 CONFIG_HIBERNATE_32=y
 CONFIG_ARCH_HIBERNATION_POSSIBLE=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 # CONFIG_PPC_DCR_NATIVE is not set
 # CONFIG_PPC_DCR_MMIO is not set
+CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
 #
@@ -72,14 +75,24 @@ CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_SYSVIPC_SYSCTL=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_POSIX_MQUEUE_SYSCTL=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
 # CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=14
-# CONFIG_CGROUPS is not set
 # CONFIG_GROUP_SCHED is not set
+# CONFIG_CGROUPS is not set
 CONFIG_SYSFS_DEPRECATED=y
 CONFIG_SYSFS_DEPRECATED_V2=y
 # CONFIG_RELAY is not set
@@ -88,23 +101,27 @@ CONFIG_NAMESPACES=y
 # CONFIG_IPC_NS is not set
 # CONFIG_USER_NS is not set
 # CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE=""
+CONFIG_RD_GZIP=y
+CONFIG_RD_BZIP2=y
+CONFIG_RD_LZMA=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
 CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
 # CONFIG_EMBEDDED is not set
 CONFIG_SYSCTL_SYSCALL=y
 CONFIG_KALLSYMS=y
 CONFIG_KALLSYMS_ALL=y
 # CONFIG_KALLSYMS_EXTRA_PASS is not set
+# CONFIG_STRIP_ASM_SYMS is not set
 CONFIG_HOTPLUG=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_ELF_CORE=y
-# CONFIG_COMPAT_BRK is not set
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
-CONFIG_ANON_INODES=y
 CONFIG_EPOLL=y
 CONFIG_SIGNALFD=y
 CONFIG_TIMERFD=y
@@ -114,10 +131,12 @@ CONFIG_AIO=y
 CONFIG_VM_EVENT_COUNTERS=y
 CONFIG_PCI_QUIRKS=y
 CONFIG_SLUB_DEBUG=y
+# CONFIG_COMPAT_BRK is not set
 # CONFIG_SLAB is not set
 CONFIG_SLUB=y
 # CONFIG_SLOB is not set
 CONFIG_PROFILING=y
+CONFIG_TRACEPOINTS=y
 # CONFIG_MARKERS is not set
 CONFIG_OPROFILE=y
 CONFIG_HAVE_OPROFILE=y
@@ -127,10 +146,10 @@ CONFIG_HAVE_IOREMAP_PROT=y
 CONFIG_HAVE_KPROBES=y
 CONFIG_HAVE_KRETPROBES=y
 CONFIG_HAVE_ARCH_TRACEHOOK=y
+# CONFIG_SLOW_WORK is not set
 # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
 CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
-# CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
 CONFIG_MODULES=y
 # CONFIG_MODULE_FORCE_LOAD is not set
@@ -138,11 +157,8 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 # CONFIG_MODVERSIONS is not set
 # CONFIG_MODULE_SRCVERSION_ALL is not set
-CONFIG_KMOD=y
 CONFIG_BLOCK=y
 CONFIG_LBD=y
-# CONFIG_BLK_DEV_IO_TRACE is not set
-CONFIG_LSF=y
 CONFIG_BLK_DEV_BSG=y
 # CONFIG_BLK_DEV_INTEGRITY is not set
 
@@ -158,14 +174,11 @@ CONFIG_DEFAULT_AS=y
 # CONFIG_DEFAULT_CFQ is not set
 # CONFIG_DEFAULT_NOOP is not set
 CONFIG_DEFAULT_IOSCHED="anticipatory"
-CONFIG_CLASSIC_RCU=y
 CONFIG_FREEZER=y
 
 #
 # Platform support
 #
-CONFIG_PPC_MULTIPLATFORM=y
-CONFIG_CLASSIC32=y
 # CONFIG_PPC_CHRP is not set
 # CONFIG_MPC5121_ADS is not set
 # CONFIG_MPC5121_GENERIC is not set
@@ -178,7 +191,9 @@ CONFIG_PPC_PMAC=y
 # CONFIG_PPC_83xx is not set
 # CONFIG_PPC_86xx is not set
 # CONFIG_EMBEDDED6xx is not set
+# CONFIG_AMIGAONE is not set
 CONFIG_PPC_NATIVE=y
+CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
 # CONFIG_IPIC is not set
 CONFIG_MPIC=y
 # CONFIG_MPIC_WEIRD is not set
@@ -212,11 +227,12 @@ CONFIG_CPU_FREQ_PMAC=y
 CONFIG_PPC601_SYNC_FIX=y
 # CONFIG_TAU is not set
 # CONFIG_FSL_ULI1575 is not set
+# CONFIG_SIMPLE_GPIO is not set
 
 #
 # Kernel options
 #
-# CONFIG_HIGHMEM is not set
+CONFIG_HIGHMEM=y
 CONFIG_TICK_ONESHOT=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
@@ -239,6 +255,7 @@ CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
 CONFIG_ARCH_HAS_WALK_MEMORY=y
 CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
 # CONFIG_KEX

Re: [PATCH V3 3/4] Support for AC97 on Phytec pmc030 base board.

[Grant Likely]

On Sun, May 24, 2009 at 7:38 PM, Jon Smirl  wrote:
> Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
>
> Signed-off-by: Jon Smirl 
> ---
>  sound/soc/fsl/Kconfig               |    7 +++
>  sound/soc/fsl/Makefile              |    3 +
>  sound/soc/fsl/pcm030-audio-fabric.c |   95 
> +++
>  3 files changed, 105 insertions(+), 0 deletions(-)
>  create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 3bce952..79579ae 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -39,4 +39,11 @@ config SND_SOC_MPC5200_AC97
>        help
>          Say Y here to support the MPC5200 PSCs in AC97 mode.
>
> +config SND_MPC52xx_SOC_PCM030
> +       tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
> +       depends on PPC_MPC5200_SIMPLE
> +       select SND_SOC_MPC5200_AC97
> +       select SND_SOC_WM9712
> +       help
> +         Say Y if you want to add support for sound on the Phytec pcm030 
> baseboard.
>
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index 14631a1..66d88c8 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -15,3 +15,6 @@ obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o
>  obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
>  obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
>
> +# MPC5200 Machine Support
> +obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
> +
> diff --git a/sound/soc/fsl/pcm030-audio-fabric.c 
> b/sound/soc/fsl/pcm030-audio-fabric.c
> new file mode 100644
> index 000..2c426d5
> --- /dev/null
> +++ b/sound/soc/fsl/pcm030-audio-fabric.c
> @@ -0,0 +1,95 @@
> +/*
> + * Phytec pcm030 driver for the PSC of the Freescale MPC52xx
> + * configured as AC97 interface
> + *
> + * Copyright 2008 Jon Smirl, Digispeaker
> + * Author: Jon Smirl 
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "mpc5200_dma.h"
> +#include "mpc5200_psc_ac97.h"
> +#include "../codecs/wm9712.h"
> +
> +static struct snd_soc_device device;
> +static struct snd_soc_card card;
> +
> +static struct snd_soc_dai_link pcm030_fabric_dai[] = {
> +{
> +       .name = "AC97",
> +       .stream_name = "AC97 Analog",
> +       .codec_dai = &wm9712_dai[WM9712_DAI_AC97_HIFI],
> +       .cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
> +},
> +{
> +       .name = "AC97",
> +       .stream_name = "AC97 IEC958",
> +       .codec_dai = &wm9712_dai[WM9712_DAI_AC97_AUX],
> +       .cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
> +},
> +};
> +
> +static __init int pcm030_fabric_init(void)
> +{
> +       struct platform_device *pdev;
> +       int rc;
> +
> +       if (!machine_is_compatible("phytec,pcm030"))
> +               return -ENODEV;
> +
> +       card.platform = &mpc5200_audio_dma_platform;
> +       card.name = "pcm030";
> +       card.dai_link = pcm030_fabric_dai;
> +       card.num_links = ARRAY_SIZE(pcm030_fabric_dai);
> +
> +       device.card = &card;
> +       device.codec_dev = &soc_codec_dev_wm9712;
> +
> +       pdev = platform_device_alloc("soc-audio", 1);
> +       if (!pdev) {
> +               pr_err("pcm030_fabric_init: platform_device_alloc() 
> failed\n");
> +               return -ENODEV;
> +       }
> +
> +       platform_set_drvdata(pdev, &device);
> +       device.dev = &pdev->dev;
> +
> +       rc = platform_device_add(pdev);
> +       if (rc) {
> +               pr_err("pcm030_fabric_init: platform_device_add() failed\n");
> +               return -ENODEV;
> +       }
> +       return 0;
> +}

This is ugly.  I'd really rather have a generic mechanism for creating
a fabric driver based on the OF data.  But failing that, it seems to
me that this platform device registration should be done in the
platform code (arch/powerpc/platforms/52xx).  Doing it in a module
init looks wrong.

I was trying to do a sort of generic matching mechanism with the of
simple stuff; but admittedly it was hacky and half-assed.  However, I
do still think it is viable to have OF hooks that kick in when codec
and machine drivers are registered.  If linkage data is encoded in the
device tree, then generic code should be able to hook them up; pulling
additional data out of the device tree as needed to configure the
coded.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Initialize DBCR0 for PPC440 targets

[Grant Likely]

On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar
 wrote:
> Hello Grant,
>
> Is there any conclusion of the below discussion:
>
> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
>
> Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without
> the DBCR0 initialization.
>
> Can you please comment on this ?

IIRC, John Linn was hacking on a patch.  Search the mailing list
archives for DBCR0.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc: DMA coherent allocations broken for CONFIG_NOT_COHERENT_CACHE

[Benjamin Herrenschmidt]

On Sun, 2009-05-24 at 23:50 -0600, Grant Likely wrote:
> It would also be nice for comprehension if the file move and the
> modification were separate commits.  As it is I had to generate the
> diff manually, but I'm not concerned.

Right, I though about that... too late :-) might break it up tomorrow
morning, I don't have time to fix that up right now. Hopefully Kumar
and Ilya will manage to do the same you did to diff it :-)

Cheers,
Ben.
 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Initialize DBCR0 for PPC440 targets

[srikanth krishnakar]

Hi John,

I am not finding any conclusion of the plan to add DBCR0
initialization code to head_44x.S after this discussion :

http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html#a23049044

Can you please comment ?

Thanks,
-Srikanth Krishnakar

On Mon, May 25, 2009 at 12:09 PM, Grant Likely
 wrote:
> On Mon, May 25, 2009 at 12:30 AM, srikanth krishnakar
>  wrote:
>> Hello Grant,
>>
>> Is there any conclusion of the below discussion:
>>
>> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
>>
>> Xilinx target (virtex5) hangs (while running GDBServer & KGDB) without
>> the DBCR0 initialization.
>>
>> Can you please comment on this ?
>
> IIRC, John Linn was hacking on a patch.  Search the mailing list
> archives for DBCR0.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>



-- 
"The Good You Do, The Best You GET"

Regards
Srikanth Krishnakar
**
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver

[Grant Likely]

On Sat, May 23, 2009 at 10:44 AM, Wolfgang Grandegger  
wrote:
> Wolfgang Grandegger wrote:
>> Grant Likely wrote:
 +- clock-frequency : CAN system clock frequency in Hz, which is normally
 +       half of the oscillator clock frequency. If not specified, a
 +       default value of 800 (8 MHz) is used.
>>> A clock-frequency property typically refers to the bus clock
>>> frequency.  Something like can-frequency would be better.
>>
>> Ah, right, but I'm also not happy with "can-frequency". The manual
>> speaks about the "internal clock", which is half of the external
>> oscillator frequency. Maybe "internal-clock-frequency" might be better.

Would it be better to specify the external clock frequency, and the
driver know that internal freq is half that?  I ask because external
clock freq is a value the HW designer actually has control over.

 +- cdr-reg : value of the SJA1000 clock divider register according to
 +       the SJA1000 data sheet. If not specified, a default value of
 +       0x48 is used.
>>> Ewh.  The driver should be clueful enough to derive the clock divider
>>> value given both the bus and can frequencies.  I don't like this
>>> property.
>>
>> The clock divider register controls the CLKOUT frequency for the
>> microcontroller another CAN controller and allows to deactivate the
>> CLKOUT pin. It's not used to configure the CAN bus frequency.
>>
 +- ocr-reg : value of the SJA1000 output control register according to
 +       the SJA1000 data sheet. If not specified, a default value of
 +       0x0a is used.
>>> Ditto here; the binding should describe the usage mode; not the
>>> register settings to get the usage mode.  What sort of settings will
>>> the .dts author be writing here?
>>
>> Unfortunately, there are many:
>>
>> clkout-frequency
>> bypass-comperator
>> tx1-output-on-rx-irq
>>
>> #define OCR_MODE_BIPHASE  0x00
>> #define OCR_MODE_TEST     0x01
>> #define OCR_MODE_NORMAL   0x02
>> #define OCR_MODE_CLOCK    0x03
>>
>> #define OCR_TX0_INVERT    0x04
>> #define OCR_TX0_PULLDOWN  0x08
>> #define OCR_TX0_PULLUP    0x10
>> #define OCR_TX0_PUSHPULL  0x18
>> #define OCR_TX1_INVERT    0x20
>> #define OCR_TX1_PULLDOWN  0x40
>> #define OCR_TX1_PULLUP    0x80
>> #define OCR_TX1_PUSHPULL  0xc0
>>
>> I think implementing properties for each option is overkill.

Ugh, I see what you mean.

> Would the following more descriptive properties be OK?
>
>  clock-out-frequency = <0>, // CLKOUT pin clock off
>                      = <400>; // frequency on CLKOUT pin

Or how about CLKOUT pin off if the property isn't present?  Otherwise,
this looks okay.  BTW, I'd consider prefixing this with 'nxp,' or
'sja1000,' to protect the namespace.  clock-out-frequency sounds like
one of those names which could be commonly used in the future.  I'd so
the same for the other chip-specific properties too.

Segher, what's your opinion on this?

>  bypass-input-comparator; // allows to bypass the CAN input comparator.
>
>  tx1-output-on-rx-irq;    // allows the TX1 output to be used as a
>                           // dedicated RX interrupt output.
>
>  output-control-mode = <0x0> // bi-phase output mode
>                        <0x1> // test output mode
>                        <0x2> // normal output mode (default)
>                        <0x3> // clock output mode
>
>  output-pin-config = <0x01> // TX0 invert
>                      <0x02> // TX0 pull-down
>                      <0x04> // TX0 pull-up
>                      <0x06> // TX0 push-pull
>                      <0x08> // TX1 invert
>                      <0x10> // TX1 pull-down
>                      <0x20> // TX1 pull-up
>                      <0x30> // TX1 push-pull

hmmm; It is very chip specific and it is a lot of mucking around.  If
you prefix the property with the manufacturer name, then perhaps the
explicit register setting is okay.

Are TX0 & TX1 protocol pins or GPIOs?  If gpio, then maybe it is worth
the mucking about to then use the gpios binding to specify the pin
mode.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver

[Wolfgang Grandegger]

Arnd Bergmann wrote:
> On Saturday 23 May 2009, Wolfgang Grandegger wrote:
>> Arnd Bergmann wrote:
>>> Minor nitpicking: dev->base_addr should be defined as an __iomem pointer
>>> so you can avoid the cast here and in the ioremap/iounmap path.
>> Here the member "base_addr" of "struct net_device" is used and it's not
>> up to me to change the type.
> 
> Right, that makes sense. However, most drivers use the field to store the
> physical address, not the iomap token. Maybe there should be a new field
> in struct sja1000_priv for the virtual address, but that would be a change
> to the base driver, not just to the OF portion.

Is that common practice? If yes, I will add a member to store the
virtual address to struct sja1000_priv.

Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev