* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-14 7:59 UTC (permalink / raw)
To: David Hubbard
Cc: Samuel Ortiz, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <4dfa50520807131426t4013142cp1fcd49e078a79c1f@mail.gmail.com>
On Sun, 13 Jul 2008 15:26:56 -0600, David Hubbard wrote:
> Hi Hans,
>
> >> I propose writing a subsystem driver. (Is that properly called "The
> >> SuperIO Bus Driver"?) If no one thinks it's a really bad idea I will
> >> put together some code and submit it for review, and maintain it.
> >>
> >> Some hwmon chips have odd / unique probe sequences. IMHO this is where
> >> the design needs to be inspected. One of those is the w83627ehf, which
> >> Jean and Hans are familiar enough with to check my work.
> >>
> >> Thoughts?
> >
> > I'm afraid that making this a "bus" will be a bit overkill. Jim's patches
> > are quite simple and seem todo the job.
> >
> > Also keep in mind that most users will be platform devices which just want
> > to use the superio registers to find out the baseaddress of their logical
> > device, a whole bus seems overkill for this, would the hwmon driver then
> > need to be a superio_driver (as well as an platform_driver) or can the bus
> > be queried / used
> > without having to be a bustype-driver?
>
> I think that's a valid point. I am willing to keep it small, but I
> would prefer to follow the pattern set in other subsystems. It may be
> my lack of experience in designing a subsystem showing here! What are
> some alternative ways to implement it?
>
> In other words, Jim's patches are a good start, but maybe I am
> misunderstanding them. I see it as the superio-locks module, a driver
> that other drivers would depend on / auto-load. Is that something
> other subsystems also do?
Well, there are two approaches to the problem. The first approach
(which I think Jim took in his patches? I don't really remember) is to
simply solve the problem of concurrent I/O access to the Super-I/O
configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a
simple driver requesting the ports in question and exporting an API for
other drivers to access them in a safe way.
The second approach is to make it a whole subsystem, as David is
suggesting. The Super-I/O driver would then not only request the I/O
ports, it would also identify which Super-I/O is there, and it would
create devices (in the Linux device driver model sense of the term) for
every logical device we are interested in (amongst which the hwmon
ones.) The hwmon drivers would have to be converted from platform
drivers to superio drivers.
Each approach has its advantages. The first one is rather simple and
also very generic in nature. It could be reused for other purposes. The
second one offers automatic loading of hwmon drivers, which would be
nice to have.
There's probably a middle way which would keep the simplicity of the
first approach while still allowing for driver auto-loading, without
changing the bus type of all drivers. It would probably take some
research though.
Me, I don't really care which path we choose, given that I am not the
one who will take care of it. All I have to say is that this has been
discussed several times over the past 2 years and nothing came out of
it (as far as the mainline kernel is concerned, at least) so whatever
is done now, what really matters is that it makes it into the kernel
quickly. We have some drivers missing features because of this (for
example real-time reading of VID pin values.)
This should also not prevent us from fixing the drivers now so that
they temporarily request the Super-I/O ports they are using, as Milton
suggested. Not only we don't know when we will have something better to
offer, but it might also help us find conflicts between drivers, so
that we know which drivers should make use of the future superio
driver. This could also reveal conflicts with PNP BIOS reservations,
etc. Milton, will you write a patch?
--
Jean Delvare
^ permalink raw reply
* powerpc/master: build failure
From: Stephen Rothwell @ 2008-07-14 8:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
Hi Kumar,
A build of today's powerpc/master tree for mpc85xx_defconfig fails like this:
DTC: dts->dtb on file "arch/powerpc/boot/dts/ksi8560.dts"
ERROR (phandle_references): Reference to non-existent node or label "mpic"
ERROR (phandle_references): Reference to non-existent node or label "mpic"
ERROR (phandle_references): Reference to non-existent node or label "mpic"
ERROR (phandle_references): Reference to non-existent node or label "mpic"
ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [arch/powerpc/boot/ksi8560.dtb] Error 2
Probably commit dee805532a30183c4462305b4614e58bd83a7bc1 ("powerpc: Add
dma nodes to 83xx, 85xx and 86xx boards").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Srinivasa D S @ 2008-07-14 8:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18554.33417.542066.185326@cargo.ozlabs.ibm.com>
On Monday 14 July 2008 04:02:41 am Paul Mackerras wrote:
> > Below attached patch defines this macro for powerpc arch. Please let
> > me know your comments on this.
> >
> > +#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.regs)
>
> The cast is unnecessary since tsk->thread.regs is already a struct
> pt_regs *.
True.
> Also note that tsk->thread.regs will be NULL for a kernel
> thread.
Yes, users of task_pt_regs will verify for NULL. Updated patch attached
below.
Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
---
include/asm-powerpc/processor.h | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.26-rc9/include/asm-powerpc/processor.h
===================================================================
--- linux-2.6.26-rc9.orig/include/asm-powerpc/processor.h
+++ linux-2.6.26-rc9/include/asm-powerpc/processor.h
@@ -214,6 +214,8 @@ struct thread_struct {
#define thread_saved_pc(tsk) \
((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
+#define task_pt_regs(tsk) (tsk)->thread.regs
+
unsigned long get_wchan(struct task_struct *p);
#define KSTK_EIP(tsk) ((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
^ permalink raw reply
* Re: Updates to powerpc.git
From: Benjamin Herrenschmidt @ 2008-07-14 8:37 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev list, Andrew Morton
In-Reply-To: <20080714154918.d5064b3c.sfr@canb.auug.org.au>
On Mon, 2008-07-14 at 15:49 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> On Mon, 14 Jul 2008 15:32:36 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > -next and -merge are now both to the same level, which is the same
>
> I think you meant -master (not -merge).
Yup, typo, sorry.
-merge will be updated to that level if -next is happy.
Cheers,
Ben.
^ permalink raw reply
* Re: build error in powerpc tree
From: Benjamin Herrenschmidt @ 2008-07-14 8:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Dave Kleikamp
In-Reply-To: <20080714170301.93f940fd.sfr@canb.auug.org.au>
On Mon, 2008-07-14 at 17:03 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> Commit ef3d3246a0d06be622867d21af25f997aeeb105f ("powerpc/mm: Add Strong
> Access Ordering support") in the powerpc/{next,master} tree caused the
> following in a powerpc allmodconfig build:
>
> usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported headers
>
> Also, that header file is now using CONFIG_PPC64 which we should not do
> in the unprotected (by #ifdef __KERNEL__) part an exported header file,
> we should use __powerpc64__ instead.
>
> I suspect all the CONFIG_PPC64 part of the file could be surrounded by
> #ifdef __KERNEL__ and the include of <linux/mm.h> could be moved to this
> section. The file should then be changed to unifdef-y from header-y in
> the Kbuild file. (Might have been easier to send a patch :-))
I'll dbl check tomorrow. PROT_SAO must be exported always but everything
else should pretty much be under __KERNEL__. Interesting that this
hasn't shown up in Paulus test build scripts that I used.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: mman.h export fixups
From: Stephen Rothwell @ 2008-07-14 9:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev, linux-next, Dave Kleikamp
In-Reply-To: <20080714170301.93f940fd.sfr@canb.auug.org.au>
Commit ef3d3246a0d06be622867d21af25f997aeeb105f ("powerpc/mm: Add Strong
Access Ordering support") in the powerpc/{next,master} tree caused the
following in a powerpc allmodconfig build:
usr/include/asm/mman.h requires linux/mm.h, which does not exist in exported headers
We should not use CONFIG_PPC64 in an unprotected (by __KERNEL__)
section of an exported include file and linux/mm.h is not exported. So
protect the whole section that is CONFIG_PPC64 with __KERNEL__ and put
the two introduced includes in there as well.
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/Kbuild | 2 +-
include/asm-powerpc/mman.h | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
I have included this patch in today's linux-next tree.
diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 34a0a8d..329ecfd 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-powerpc/Kbuild
@@ -2,7 +2,6 @@ include include/asm-generic/Kbuild.asm
header-y += auxvec.h
header-y += ioctls.h
-header-y += mman.h
header-y += sembuf.h
header-y += siginfo.h
header-y += stat.h
@@ -28,6 +27,7 @@ unifdef-y += byteorder.h
unifdef-y += cputable.h
unifdef-y += elf.h
unifdef-y += nvram.h
+unifdef-y += mman.h
unifdef-y += param.h
unifdef-y += posix_types.h
unifdef-y += ptrace.h
diff --git a/include/asm-powerpc/mman.h b/include/asm-powerpc/mman.h
index f8a32e2..9209f75 100644
--- a/include/asm-powerpc/mman.h
+++ b/include/asm-powerpc/mman.h
@@ -1,9 +1,7 @@
#ifndef _ASM_POWERPC_MMAN_H
#define _ASM_POWERPC_MMAN_H
-#include <asm/cputable.h>
#include <asm-generic/mman.h>
-#include <linux/mm.h>
/*
* This program is free software; you can redistribute it and/or
@@ -28,7 +26,12 @@
#define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
#define MAP_NONBLOCK 0x10000 /* do not block on IO */
+#ifdef __KERNEL__
#ifdef CONFIG_PPC64
+
+#include <asm/cputable.h>
+#include <linux/mm.h>
+
/*
* This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
* here. How important is the optimization?
@@ -56,4 +59,5 @@ static inline int arch_validate_prot(unsigned long prot)
#define arch_validate_prot(prot) arch_validate_prot(prot)
#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MMAN_H */
--
1.5.6.2
^ permalink raw reply related
* linux-next: powerpc/generic-ipi tree build failure
From: Stephen Rothwell @ 2008-07-14 9:55 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: Ingo Molnar, linux-next
Hi all,
Today's linux-next build (powerpc allmodconfig) failed like this:
ERROR: ".save_stack_trace" [tests/backtracetest.ko] undefined!
But save_stack_trace is exported in arch/powerpc/kernel/stacktrace.c
I couldn't figure it out until I noticed these earlier warnings:
arch/powerpc/kernel/stacktrace.c:47: warning: data definition has no type or storage class
arch/powerpc/kernel/stacktrace.c:47: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
arch/powerpc/kernel/stacktrace.c:47: warning: parameter names (without types) in function declaration
I applied the patch below.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
>From 91ec767c487ff260455e416fee161015a8bdb0c5 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 14 Jul 2008 19:45:59 +1000
Subject: [PATCH] powerpc/stacktrace: EXPORT SYMBOL_GPL needs module.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/stacktrace.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
index 9861f17..3cf0d94 100644
--- a/arch/powerpc/kernel/stacktrace.c
+++ b/arch/powerpc/kernel/stacktrace.c
@@ -12,6 +12,7 @@
#include <linux/sched.h>
#include <linux/stacktrace.h>
+#include <linux/module.h>
#include <asm/ptrace.h>
/*
--
1.5.6.2
^ permalink raw reply related
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Benjamin Herrenschmidt @ 2008-07-14 9:06 UTC (permalink / raw)
To: Srinivasa D S; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200807141401.26917.srinivasa@in.ibm.com>
On Mon, 2008-07-14 at 14:01 +0530, Srinivasa D S wrote:
> On Monday 14 July 2008 04:02:41 am Paul Mackerras wrote:
> > > Below attached patch defines this macro for powerpc arch. Please let
> > > me know your comments on this.
> > >
> > > +#define task_pt_regs(tsk) ((struct pt_regs *)(tsk)->thread.regs)
> >
> > The cast is unnecessary since tsk->thread.regs is already a struct
> > pt_regs *.
>
> True.
>
> > Also note that tsk->thread.regs will be NULL for a kernel
> > thread.
>
> Yes, users of task_pt_regs will verify for NULL. Updated patch attached
> below.
>
> Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
Can you send a cleanup patch against powerpc.git instead ?
Thanks !
Ben
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-14 11:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083939.15025.31192.stgit@trillian.secretlab.ca>
On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote:
> ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
> v1 API, so I don't expect it to get merged as-is, but I want to get it
> out there for review.
This looks basically good - most of the issues below are nitpicky.
> + /* Configure PLL */
> + pval = 1;
> + jval = (fsref == 44100) ? 7 : 8;
> + dval = (fsref == 44100) ? 5264 : 1920;
> + qval = 0;
> + reg = 0x8000 | qval << 11 | pval << 8 | jval << 2;
> + aic26_reg_write(codec, AIC26_REG_PLL_PROG1, reg);
> + reg = dval << 2;
> + aic26_reg_write(codec, AIC26_REG_PLL_PROG2, reg);
Does the PLL configuration not depend on the input clock frequency? You
have a set_sysclk() method to configure the MCLK supplied but the driver
never appears to reference the value anywhere.
> + /* Power up CODEC */
> + aic26_reg_write(codec, AIC26_REG_POWER_CTRL, 0);
As discussed this should probably just be removed from hw_params().
> +static int aic26_set_fmt(struct snd_soc_codec_dai *codec_dai, unsigned int fmt)
> +{
> + /* interface format */
> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> + case SND_SOC_DAIFMT_I2S: aic26->datfm = AIC26_DATFM_I2S; break;
> + case SND_SOC_DAIFMT_DSP_A: aic26->datfm = AIC26_DATFM_DSP; break;
> + case SND_SOC_DAIFMT_RIGHT_J: aic26->datfm = AIC26_DATFM_RIGHTJ; break;
> + case SND_SOC_DAIFMT_LEFT_J: aic26->datfm = AIC26_DATFM_LEFTJ; break;
> + default: dev_dbg(&aic26->spi->dev, "bad format\n"); return -EINVAL;
> + }
I'm having a hard time liking this indentation style. It's not an
obstacle to merging but it doesn't really help legibility - there's not
enough white space and once you have a non-standard line like the
default: one.
> +static const char *aic26_capture_src_text[] = {"Mic", "Aux"};
> +static const struct soc_enum aic26_capture_src_enum =
> + SOC_ENUM_SINGLE(AIC26_REG_AUDIO_CTRL1, 12,2, aic26_capture_src_text);
checkpatch complains about the 12,2 here and a bunch of other stuff -
ALSA is generally very strict about that.
> + SOC_SINGLE("Keyclick activate", AIC26_REG_AUDIO_CTRL2, 15, 0x1, 0),
> + SOC_SINGLE("Keyclick amplitude", AIC26_REG_AUDIO_CTRL2, 12, 0x7, 0),
> + SOC_SINGLE("Keyclick frequency", AIC26_REG_AUDIO_CTRL2, 8, 0x7, 0),
> + SOC_SINGLE("Keyclick period", AIC26_REG_AUDIO_CTRL2, 4, 0xf, 0),
This configuration is also exposed via a sysfs file, including some of
the configurability. Exposing the information via sysfs isn't a
particular problem but allowing it to be written to without going
through ALSA seems wrong.
> +static ssize_t aic26_regs_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
As discussed this is replicating the existing codec register display
sysfs file.
> +#if defined(CONFIG_SND_SOC_OF)
> + /* Tell the of_soc helper about this codec */
> + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> + spi->dev.archdata.of_node);
> +#endif
CONFIG_SND_SOC_OF could be a module - this needs to also check for it
being a module.
> +#define AIC26_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
> + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\
> + SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |\
> + SNDRV_PCM_RATE_48000)
> +#define AIC26_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE |\
> + SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE)
These are usually kept in the driver code.
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Mark Brown @ 2008-07-14 12:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083934.15025.86862.stgit@trillian.secretlab.ca>
On Sat, Jul 12, 2008 at 02:39:34AM -0600, Grant Likely wrote:
> This is an I2S bus driver for the MPC5200 PSC device. It is probably
> will not be merged as-is because it uses v1 of the ASoC API, but I want
> to get it out there for comments.
Looks basically good. A few things below, plus you probably want to run
checkpatch over it.
> +/* 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;
> +
> + //spin_lock(&s->psc_i2s->lock);
Either the lock is needed or it isn't :) .
> + * If this is the first stream open, then grab the IRQ and program most of
> + * the PSC registers.
> +static int psc_i2s_startup(struct snd_pcm_substream *substream)
> +{
The comment here doesn't seem to reflect what the function does - it
looks to just unconditionally reinitialise the controller with things
like this:
> + /* Disable all interrupts and reset the PSC */
> + out_be16(®s->mpc52xx_psc_imr, 0);
> + out_8(®s->command, 3 << 4); /* reset transmitter */
> + out_8(®s->command, 2 << 4); /* reset receiver */
> + out_8(®s->command, 1 << 4); /* reset mode */
> + out_8(®s->command, 4 << 4); /* reset error */
which I'd imagine might upset running streams?
> +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd)
> +{
> + case SNDRV_PCM_TRIGGER_STOP:
> + case SNDRV_PCM_TRIGGER_STOP:
> + default:
> + dev_dbg(psc_i2s->dev, "invalid command\n");
> + return -EINVAL;
> + }
This doesn't handle the pause, suspend, resume or pause_release
triggers. If there's really nothing to do for those it should ignore
them, especially given the default: behaviour.
^ permalink raw reply
* MPC8313 ERDB has proper interrupt mapping for TSEC?
From: selvamuthukumar v @ 2008-07-14 12:14 UTC (permalink / raw)
To: linuxppc-embedded
From, arch/powerpc/boot/dts/mpc8313erdb.dts,
212 enet0: ethernet@24000 {
.
.
219 interrupts = <37 0x8 36 0x8 35 0x8>;
.
.
222 };
223
224 enet1: ethernet@25000 {
.
.
231 interrupts = <34 0x8 33 0x8 32 0x8>;
.
234 };
235
But as per 8313 Reference manual interrups 32, 33, 34 are for
TSEC1@24000 and 35, 36, 37 are for TSEC2@25000. Any idea why interrupt
numbers are swapped for enet0 and enet1?
--
Selva
^ permalink raw reply
* [PATCH 1/3] powerpc: Fix pte_update for CONFIG_PTE_64BIT and !PTE_ATOMIC_UPDATES
From: Kumar Gala @ 2008-07-14 13:08 UTC (permalink / raw)
To: linuxppc-dev
Because the pte is now 64-bits the compiler was optimizing the update
to always clear the upper 32-bits of the pte. We need to ensure the
clr mask is treated as an unsigned long long to get the proper behavior.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
include/asm-powerpc/pgtable-ppc32.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h
index 11eede4..73015f0 100644
--- a/include/asm-powerpc/pgtable-ppc32.h
+++ b/include/asm-powerpc/pgtable-ppc32.h
@@ -624,7 +624,7 @@ static inline unsigned long long pte_update(pte_t *p,
: "cc" );
#else /* PTE_ATOMIC_UPDATES */
unsigned long long old = pte_val(*p);
- *p = __pte((old & ~clr) | set);
+ *p = __pte((old & ~(unsigned long long)clr) | set);
#endif /* !PTE_ATOMIC_UPDATES */
#ifdef CONFIG_44x
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/3] powerpc: rework FSL Book-E PTE access and TLB miss
From: Kumar Gala @ 2008-07-14 13:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807140808090.9284@blarg.am.freescale.net>
This converts the FSL Book-E PTE access and TLB miss handling to match
with the recent changes to 44x that introduce support for non-atomic PTE
operations in pgtable-ppc32.h and removes write back to the PTE from
the TLB miss handlers. In addition, the DSI interrupt code no longer
tries to fixup write permission, this is left to generic code, and
_PAGE_HWWRITE is gone.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
This will go via my powerpc-next tree.
arch/powerpc/kernel/head_fsl_booke.S | 168 +++++++++-------------------------
include/asm-powerpc/pgtable-ppc32.h | 15 +--
2 files changed, 48 insertions(+), 135 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index c426850..7d55496 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -483,90 +483,16 @@ interrupt_base:
/* Data Storage Interrupt */
START_EXCEPTION(DataStorage)
- mtspr SPRN_SPRG0, r10 /* Save some working registers */
- mtspr SPRN_SPRG1, r11
- mtspr SPRN_SPRG4W, r12
- mtspr SPRN_SPRG5W, r13
- mfcr r11
- mtspr SPRN_SPRG7W, r11
-
- /*
- * Check if it was a store fault, if not then bail
- * because a user tried to access a kernel or
- * read-protected page. Otherwise, get the
- * offending address and handle it.
- */
- mfspr r10, SPRN_ESR
- andis. r10, r10, ESR_ST@h
- beq 2f
-
- mfspr r10, SPRN_DEAR /* Get faulting address */
-
- /* If we are faulting a kernel address, we have to use the
- * kernel page tables.
- */
- lis r11, PAGE_OFFSET@h
- cmplw 0, r10, r11
- bge 2f
-
- /* Get the PGD for the current thread */
-3:
- mfspr r11,SPRN_SPRG3
- lwz r11,PGDIR(r11)
-4:
- FIND_PTE
-
- /* Are _PAGE_USER & _PAGE_RW set & _PAGE_HWWRITE not? */
- andi. r13, r11, _PAGE_RW|_PAGE_USER|_PAGE_HWWRITE
- cmpwi 0, r13, _PAGE_RW|_PAGE_USER
- bne 2f /* Bail if not */
-
- /* Update 'changed'. */
- ori r11, r11, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
- stw r11, PTE_FLAGS_OFFSET(r12) /* Update Linux page table */
-
- /* MAS2 not updated as the entry does exist in the tlb, this
- fault taken to detect state transition (eg: COW -> DIRTY)
- */
- andi. r11, r11, _PAGE_HWEXEC
- rlwimi r11, r11, 31, 27, 27 /* SX <- _PAGE_HWEXEC */
- ori r11, r11, (MAS3_UW|MAS3_SW|MAS3_UR|MAS3_SR)@l /* set static perms */
-
- /* update search PID in MAS6, AS = 0 */
- mfspr r12, SPRN_PID0
- slwi r12, r12, 16
- mtspr SPRN_MAS6, r12
-
- /* find the TLB index that caused the fault. It has to be here. */
- tlbsx 0, r10
-
- /* only update the perm bits, assume the RPN is fine */
- mfspr r12, SPRN_MAS3
- rlwimi r12, r11, 0, 20, 31
- mtspr SPRN_MAS3,r12
- tlbwe
-
- /* Done...restore registers and get out of here. */
- mfspr r11, SPRN_SPRG7R
- mtcr r11
- mfspr r13, SPRN_SPRG5R
- mfspr r12, SPRN_SPRG4R
- mfspr r11, SPRN_SPRG1
- mfspr r10, SPRN_SPRG0
- rfi /* Force context change */
-
-2:
- /*
- * The bailout. Restore registers to pre-exception conditions
- * and call the heavyweights to help us out.
- */
- mfspr r11, SPRN_SPRG7R
- mtcr r11
- mfspr r13, SPRN_SPRG5R
- mfspr r12, SPRN_SPRG4R
- mfspr r11, SPRN_SPRG1
- mfspr r10, SPRN_SPRG0
- b data_access
+ NORMAL_EXCEPTION_PROLOG
+ mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */
+ stw r5,_ESR(r11)
+ mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass arg2 */
+ andis. r10,r5,(ESR_ILK|ESR_DLK)@h
+ bne 1f
+ EXC_XFER_EE_LITE(0x0300, handle_page_fault)
+1:
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ EXC_XFER_EE_LITE(0x0300, CacheLockingException)
/* Instruction Storage Interrupt */
INSTRUCTION_STORAGE_EXCEPTION
@@ -645,15 +571,30 @@ interrupt_base:
lwz r11,PGDIR(r11)
4:
+ /* Mask of required permission bits. Note that while we
+ * do copy ESR:ST to _PAGE_RW position as trying to write
+ * to an RO page is pretty common, we don't do it with
+ * _PAGE_DIRTY. We could do it, but it's a fairly rare
+ * event so I'd rather take the overhead when it happens
+ * rather than adding an instruction here. We should measure
+ * whether the whole thing is worth it in the first place
+ * as we could avoid loading SPRN_ESR completely in the first
+ * place...
+ *
+ * TODO: Is it worth doing that mfspr & rlwimi in the first
+ * place or can we save a couple of instructions here ?
+ */
+ mfspr r12,SPRN_ESR
+ li r13,_PAGE_PRESENT|_PAGE_ACCESSED
+ rlwimi r13,r12,11,29,29
+
FIND_PTE
- andi. r13, r11, _PAGE_PRESENT /* Is the page present? */
- beq 2f /* Bail if not present */
+ andc. r13,r13,r11 /* Check permission */
+ bne 2f /* Bail if permission mismach */
#ifdef CONFIG_PTE_64BIT
lwz r13, 0(r12)
#endif
- ori r11, r11, _PAGE_ACCESSED
- stw r11, PTE_FLAGS_OFFSET(r12)
/* Jump to common tlb load */
b finish_tlb_load
@@ -667,7 +608,7 @@ interrupt_base:
mfspr r12, SPRN_SPRG4R
mfspr r11, SPRN_SPRG1
mfspr r10, SPRN_SPRG0
- b data_access
+ b DataStorage
/* Instruction TLB Error Interrupt */
/*
@@ -705,15 +646,16 @@ interrupt_base:
lwz r11,PGDIR(r11)
4:
+ /* Make up the required permissions */
+ li r13,_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_HWEXEC
+
FIND_PTE
- andi. r13, r11, _PAGE_PRESENT /* Is the page present? */
- beq 2f /* Bail if not present */
+ andc. r13,r13,r11 /* Check permission */
+ bne 2f /* Bail if permission mismach */
#ifdef CONFIG_PTE_64BIT
lwz r13, 0(r12)
#endif
- ori r11, r11, _PAGE_ACCESSED
- stw r11, PTE_FLAGS_OFFSET(r12)
/* Jump to common TLB load point */
b finish_tlb_load
@@ -768,29 +710,13 @@ interrupt_base:
* Local functions
*/
- /*
- * Data TLB exceptions will bail out to this point
- * if they can't resolve the lightweight TLB fault.
- */
-data_access:
- NORMAL_EXCEPTION_PROLOG
- mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass arg3 */
- stw r5,_ESR(r11)
- mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass arg2 */
- andis. r10,r5,(ESR_ILK|ESR_DLK)@h
- bne 1f
- EXC_XFER_EE_LITE(0x0300, handle_page_fault)
-1:
- addi r3,r1,STACK_FRAME_OVERHEAD
- EXC_XFER_EE_LITE(0x0300, CacheLockingException)
-
/*
-
* Both the instruction and data TLB miss get to this
* point to load the TLB.
* r10 - EA of fault
* r11 - TLB (info from Linux PTE)
- * r12, r13 - available to use
+ * r12 - available to use
+ * r13 - upper bits of PTE (if PTE_64BIT) or available to use
* CR5 - results of addr >= PAGE_OFFSET
* MAS0, MAS1 - loaded with proper value when we get here
* MAS2, MAS3 - will need additional info from Linux PTE
@@ -812,20 +738,14 @@ finish_tlb_load:
#endif
mtspr SPRN_MAS2, r12
- bge 5, 1f
-
- /* is user addr */
- andi. r12, r11, (_PAGE_USER | _PAGE_HWWRITE | _PAGE_HWEXEC)
+ li r10, (_PAGE_HWEXEC | _PAGE_PRESENT)
+ rlwimi r10, r11, 31, 29, 29 /* extract _PAGE_DIRTY into SW */
+ and r12, r11, r10
andi. r10, r11, _PAGE_USER /* Test for _PAGE_USER */
- srwi r10, r12, 1
- or r12, r12, r10 /* Copy user perms into supervisor */
- iseleq r12, 0, r12
- b 2f
-
- /* is kernel addr */
-1: rlwinm r12, r11, 31, 29, 29 /* Extract _PAGE_HWWRITE into SW */
- ori r12, r12, (MAS3_SX | MAS3_SR)
-
+ slwi r10, r12, 1
+ or r10, r10, r12
+ iseleq r12, r12, r10
+
#ifdef CONFIG_PTE_64BIT
2: rlwimi r12, r13, 24, 0, 7 /* grab RPN[32:39] */
rlwimi r12, r11, 24, 8, 19 /* grab RPN[40:51] */
diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h
index 73015f0..3a96d00 100644
--- a/include/asm-powerpc/pgtable-ppc32.h
+++ b/include/asm-powerpc/pgtable-ppc32.h
@@ -295,10 +295,10 @@ extern int icache_44x_need_flush;
#define _PAGE_PRESENT 0x00001 /* S: PTE contains a translation */
#define _PAGE_USER 0x00002 /* S: User page (maps to UR) */
#define _PAGE_FILE 0x00002 /* S: when !present: nonlinear file mapping */
-#define _PAGE_ACCESSED 0x00004 /* S: Page referenced */
-#define _PAGE_HWWRITE 0x00008 /* H: Dirty & RW, set in exception */
-#define _PAGE_RW 0x00010 /* S: Write permission */
-#define _PAGE_HWEXEC 0x00020 /* H: UX permission */
+#define _PAGE_RW 0x00004 /* S: Write permission (SW) */
+#define _PAGE_DIRTY 0x00008 /* S: Page dirty */
+#define _PAGE_HWEXEC 0x00010 /* H: SX permission */
+#define _PAGE_ACCESSED 0x00020 /* S: Page referenced */
#define _PAGE_ENDIAN 0x00040 /* H: E bit */
#define _PAGE_GUARDED 0x00080 /* H: G bit */
@@ -307,21 +307,14 @@ extern int icache_44x_need_flush;
#define _PAGE_WRITETHRU 0x00400 /* H: W bit */
#ifdef CONFIG_PTE_64BIT
-#define _PAGE_DIRTY 0x08000 /* S: Page dirty */
-
/* ERPN in a PTE never gets cleared, ignore it */
#define _PTE_NONE_MASK 0xffffffffffff0000ULL
-#else
-#define _PAGE_DIRTY 0x00800 /* S: Page dirty */
#endif
#define _PMD_PRESENT 0
#define _PMD_PRESENT_MASK (PAGE_MASK)
#define _PMD_BAD (~PAGE_MASK)
-/* Until my rework is finished, FSL BookE still needs atomic PTE updates */
-#define PTE_ATOMIC_UPDATES 1
-
#elif defined(CONFIG_8xx)
/* Definitions for 8xx embedded chips. */
#define _PAGE_PRESENT 0x0001 /* Page is valid */
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/3] powerpc/fsl: Minor TLBSYNC cleanup for FSL Book-E
From: Kumar Gala @ 2008-07-14 13:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807140809260.9284@blarg.am.freescale.net>
Use the TLBSYNC macro defined in ppc_asm.h rather than our own ifdefs.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
this will go via my powerpc-next tree.
- k
arch/powerpc/kernel/head_fsl_booke.S | 19 ++++---------------
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 7d55496..3cb52fa 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -151,16 +151,11 @@ skpinv: addi r6,r6,1 /* Increment */
/* Invalidate TLB0 */
li r6,0x04
tlbivax 0,r6
-#ifdef CONFIG_SMP
- tlbsync
-#endif
+ TLBSYNC
/* Invalidate TLB1 */
li r6,0x0c
tlbivax 0,r6
-#ifdef CONFIG_SMP
- tlbsync
-#endif
- msync
+ TLBSYNC
/* 3. Setup a temp mapping and jump to it */
andi. r5, r3, 0x1 /* Find an entry not used and is non-zero */
@@ -238,10 +233,7 @@ skpinv: addi r6,r6,1 /* Increment */
/* Invalidate TLB1 */
li r9,0x0c
tlbivax 0,r9
-#ifdef CONFIG_SMP
- tlbsync
-#endif
- msync
+ TLBSYNC
/* 6. Setup KERNELBASE mapping in TLB1[0] */
lis r6,0x1000 /* Set MAS0(TLBSEL) = TLB1(1), ESEL = 0 */
@@ -283,10 +275,7 @@ skpinv: addi r6,r6,1 /* Increment */
/* Invalidate TLB1 */
li r9,0x0c
tlbivax 0,r9
-#ifdef CONFIG_SMP
- tlbsync
-#endif
- msync
+ TLBSYNC
/* Establish the interrupt vector offsets */
SET_IVOR(0, CriticalInput);
--
1.5.5.1
^ permalink raw reply related
* Re: powerpc/master: build failure
From: Kumar Gala @ 2008-07-14 13:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20080714182118.f5a20643.sfr@canb.auug.org.au>
On Jul 14, 2008, at 3:21 AM, Stephen Rothwell wrote:
> Hi Kumar,
>
> A build of today's powerpc/master tree for mpc85xx_defconfig fails
> like this:
>
> DTC: dts->dtb on file "arch/powerpc/boot/dts/ksi8560.dts"
> ERROR (phandle_references): Reference to non-existent node or label
> "mpic"
> ERROR (phandle_references): Reference to non-existent node or label
> "mpic"
> ERROR (phandle_references): Reference to non-existent node or label
> "mpic"
> ERROR (phandle_references): Reference to non-existent node or label
> "mpic"
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[2]: *** [arch/powerpc/boot/ksi8560.dtb] Error 2
>
> Probably commit dee805532a30183c4462305b4614e58bd83a7bc1 ("powerpc:
> Add
> dma nodes to 83xx, 85xx and 86xx boards").
I have fixes, just need benh to pull them.
- k
^ permalink raw reply
* Re: [PATCH v3 5/5] powerpc/mpc5200: Add mpc5200-spi (non-PSC) device driver
From: Jon Smirl @ 2008-07-14 13:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, dbrownell, spi-devel-general
In-Reply-To: <20080712083458.14782.59382.stgit@trillian.secretlab.ca>
On 7/12/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Adds support for the dedicated SPI device on the Freescale MPC5200(b)
> SoC.
Can you adjust the existing PSC based SPI driver to use this device
tree code? It will be confusing if there are two different ways to do
SPI on the mpc5200.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] Fix copper/fiber auto-selection for 88e1111
From: Kumar Gala @ 2008-07-14 13:21 UTC (permalink / raw)
To: Wang Jian; +Cc: linuxppc-dev
In-Reply-To: <48757086.2080704@linux.net.cn>
On Jul 9, 2008, at 9:14 PM, Wang Jian wrote:
> The 27.15 bit (MII_M1111_HWCFG_FIBER_COPPER_AUTO) is disable bit. When
> set to 1, copper/fiber auto selection is disabled. The current code
> to enable but actually disable auto selection.
>
> Signed-off-by: Wang Jian <lark@linux.net.cn>
> ---
> drivers/net/phy/marvell.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
These should really get cc'd to the netdev list.
- k
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-14 13:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083929.15025.47682.stgit@trillian.secretlab.ca>
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
> Simple utility layer for creating ASoC machine instances based on data
> in the OpenFirmware device tree. OF aware platform drivers and codec
> drivers register themselves with this framework and the framework
> automatically instantiates a machine driver.
Ideally someone from the PowerPC community would sign off on this -
given the nature and volume of discussion people obviously have very
strong opinions about how machine drivers should be done so I'd really
like to see some community buy in for something like this. From an ASoC
point of view if this works it's fine.
> This is most likely temporary glue code to work around limitations in
> the ASoC v1 framework. I expect ASoC v2 won't need this.
It will need some way of providing a machine driver, generic (like this
one) or otherwise.
> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> +{
> + struct platform_device *pdev;
> + int rc;
> +
> + /* Only register the device if both the codec and platform have
> + * been registered */
> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> + return;
> +
> + pr_info("platform<-->codec match achieved; registering machine\n");
So what this does is add an extremely simple machine driver which
matches up the first DAI on a single codec and platform with no facility
for setting up any configurable clocking or anything? This is fine in
so far as it goes but it's going to work for very few systems as it is -
most codecs will need some additional configuration. This could be
added later, though.
Given this it might be worth renaming it to something less generic and
perhaps pushing it down into an of directory below the main ASoC
directory to parallel existing machine drivers. I'm happy with the code
from an ASoC point of view.
^ permalink raw reply
* Re: [PATCH] powerpc: mman.h export fixups
From: Arnd Bergmann @ 2008-07-14 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, linux-next, Dave Kleikamp
In-Reply-To: <20080714192557.331a50f5.sfr@canb.auug.org.au>
On Monday 14 July 2008, Stephen Rothwell wrote:
> index 34a0a8d..329ecfd 100644
> --- a/include/asm-powerpc/Kbuild
> +++ b/include/asm-powerpc/Kbuild
> @@ -2,7 +2,6 @@ include include/asm-generic/Kbuild.asm
> =A0
> =A0header-y +=3D auxvec.h
> =A0header-y +=3D ioctls.h
> -header-y +=3D mman.h
> =A0header-y +=3D sembuf.h
> =A0header-y +=3D siginfo.h
> =A0header-y +=3D stat.h
> @@ -28,6 +27,7 @@ unifdef-y +=3D byteorder.h
> =A0unifdef-y +=3D cputable.h
> =A0unifdef-y +=3D elf.h
> =A0unifdef-y +=3D nvram.h
> +unifdef-y +=3D mman.h
> =A0unifdef-y +=3D param.h
> =A0unifdef-y +=3D posix_types.h
> =A0unifdef-y +=3D ptrace.h
mman.h is already listed as unifdef-y in include/asm-generic/Kbuild.asm,
so you can probably just drop it here.
Arnd <><
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Jon Smirl @ 2008-07-14 14:13 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood, jonsmirl
In-Reply-To: <20080714134930.GC25448@sirena.org.uk>
On 7/14/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
>
> > Simple utility layer for creating ASoC machine instances based on data
> > in the OpenFirmware device tree. OF aware platform drivers and codec
> > drivers register themselves with this framework and the framework
> > automatically instantiates a machine driver.
>
>
> Ideally someone from the PowerPC community would sign off on this -
> given the nature and volume of discussion people obviously have very
> strong opinions about how machine drivers should be done so I'd really
> like to see some community buy in for something like this. From an ASoC
> point of view if this works it's fine.
Grant is one of the core PowerPC developers. There's no big
disagreement on the driver model, there just isn't a clean solution
for building a PowerPC ASoC driver under ASoC v1. The ASoC v1 driver
model is simply not compatible with the PowerPC device tree model.
That's why all of this glue code is needed.
Hopefully we can get the driver model sorted out in v2. If the ASoC
driver model is fixed all of this glue code disappears.
The PowerPC side isn't without fault too. PowerPC still doesn't have a
good way to load the fabric/machine driver.
Which are we going to call it, fabric or machine? I had been working
on the Apple code in sound/aoa. It is called fabric in that code. The
equivalent driver is called machine in ASoC v1.
>
>
> > This is most likely temporary glue code to work around limitations in
> > the ASoC v1 framework. I expect ASoC v2 won't need this.
>
>
> It will need some way of providing a machine driver, generic (like this
> one) or otherwise.
>
>
> > +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> > +{
> > + struct platform_device *pdev;
> > + int rc;
> > +
> > + /* Only register the device if both the codec and platform have
> > + * been registered */
> > + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> > + return;
> > +
> > + pr_info("platform<-->codec match achieved; registering machine\n");
>
>
> So what this does is add an extremely simple machine driver which
> matches up the first DAI on a single codec and platform with no facility
> for setting up any configurable clocking or anything? This is fine in
> so far as it goes but it's going to work for very few systems as it is -
> most codecs will need some additional configuration. This could be
> added later, though.
>
> Given this it might be worth renaming it to something less generic and
> perhaps pushing it down into an of directory below the main ASoC
> directory to parallel existing machine drivers. I'm happy with the code
> from an ASoC point of view.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Anton Vorontsov @ 2008-07-14 14:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083929.15025.47682.stgit@trillian.secretlab.ca>
On Sat, Jul 12, 2008 at 02:39:29AM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Simple utility layer for creating ASoC machine instances based on data
> in the OpenFirmware device tree. OF aware platform drivers and codec
> drivers register themselves with this framework and the framework
> automatically instantiates a machine driver.
>
> This is most likely temporary glue code to work around limitations in
> the ASoC v1 framework. I expect ASoC v2 won't need this.
> ---
[...]
> --- /dev/null
> +++ b/sound/soc/soc-of.c
It's quite inconvenient to spread the firmware-specific bits over the
whole kernel source tree. So, can we place this in driver/of/, just as
we did for i2c, spi and gpio?
> @@ -0,0 +1,171 @@
> +/*
> + * OF helpers for ALSA SoC Layer
> + *
> + * Copyright (C) 2008, Secret Lab Technologies Ltd.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/init.h>
> +#include <linux/delay.h>
> +#include <linux/pm.h>
> +#include <linux/bitops.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <sound/core.h>
> +#include <sound/pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +#include <sound/soc-of.h>
> +#include <sound/initval.h>
> +
> +MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ALSA SoC OpenFirmware bindings");
> +
> +static DEFINE_MUTEX(of_snd_soc_mutex);
> +static LIST_HEAD(of_snd_soc_device_list);
> +static int of_snd_soc_next_index;
> +
> +struct of_snd_soc_device {
> + int id;
> + struct list_head list;
> + struct snd_soc_device device;
> + struct snd_soc_machine machine;
> + struct snd_soc_dai_link dai_link;
> + struct platform_device *pdev;
> + struct device_node *platform_node;
> + struct device_node *codec_node;
> +};
> +
> +static struct snd_soc_ops of_snd_soc_ops = {
> +};
> +
> +static struct of_snd_soc_device *
> +of_snd_soc_get_device(struct device_node *codec_node)
> +{
> + struct of_snd_soc_device *of_soc;
> +
> + list_for_each_entry(of_soc, &of_snd_soc_device_list, list) {
> + if (of_soc->codec_node == codec_node)
> + return of_soc;
> + }
> +
> + of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL);
> + if (!of_soc)
> + return NULL;
> +
> + /* Initialize the structure and add it to the global list */
> + of_soc->codec_node = codec_node;
> + of_soc->id = of_snd_soc_next_index++;
> + of_soc->machine.dai_link = &of_soc->dai_link;
> + of_soc->machine.num_links = 1;
> + of_soc->device.machine = &of_soc->machine;
> + of_soc->dai_link.ops = &of_snd_soc_ops;
> + list_add(&of_soc->list, &of_snd_soc_device_list);
> +
> + return of_soc;
> +}
> +
> +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc)
> +{
> + struct platform_device *pdev;
> + int rc;
> +
> + /* Only register the device if both the codec and platform have
> + * been registered */
> + if ((!of_soc->device.codec_data) || (!of_soc->platform_node))
> + return;
> +
> + pr_info("platform<-->codec match achieved; registering machine\n");
> +
> + pdev = platform_device_alloc("soc-audio", of_soc->id);
> + if (!pdev) {
> + pr_err("of_soc: platform_device_alloc() failed\n");
> + return;
> + }
> +
> + pdev->dev.platform_data = of_soc;
> + platform_set_drvdata(pdev, &of_soc->device);
> + of_soc->device.dev = &pdev->dev;
> +
> + /* The ASoC device is complete; register it */
> + rc = platform_device_add(pdev);
> + if (rc) {
> + pr_err("of_soc: platform_device_add() failed\n");
> + return;
> + }
> +
> +}
> +
> +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev,
> + void *codec_data, struct snd_soc_codec_dai *dai,
> + struct device_node *node)
> +{
> + struct of_snd_soc_device *of_soc;
> + int rc = 0;
> +
> + pr_info("registering ASoC codec driver: %s\n", node->full_name);
> +
> + mutex_lock(&of_snd_soc_mutex);
> + of_soc = of_snd_soc_get_device(node);
> + if (!of_soc) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + /* Store the codec data */
> + of_soc->device.codec_data = codec_data;
> + of_soc->device.codec_dev = codec_dev;
> + of_soc->dai_link.name = node->name;
> + of_soc->dai_link.stream_name = node->name;
> + of_soc->dai_link.codec_dai = dai;
> +
> + /* Now try to register the SoC device */
> + of_snd_soc_register_device(of_soc);
> +
> + out:
> + mutex_unlock(&of_snd_soc_mutex);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(of_snd_soc_register_codec);
> +
> +int of_snd_soc_register_platform(struct snd_soc_platform *platform,
> + struct device_node *node,
> + struct snd_soc_cpu_dai *cpu_dai)
> +{
> + struct of_snd_soc_device *of_soc;
> + struct device_node *codec_node;
> + const phandle *handle;
> + int len, rc = 0;
> +
> + pr_info("registering ASoC platform driver: %s\n", node->full_name);
> +
> + handle = of_get_property(node, "codec-handle", &len);
> + if (!handle || len < sizeof(handle))
> + return -ENODEV;
> + codec_node = of_find_node_by_phandle(*handle);
> + if (!codec_node)
> + return -ENODEV;
> + pr_info("looking for codec: %s\n", codec_node->full_name);
> +
> + mutex_lock(&of_snd_soc_mutex);
> + of_soc = of_snd_soc_get_device(codec_node);
> + if (!of_soc) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
> + of_soc->platform_node = node;
> + of_soc->dai_link.cpu_dai = cpu_dai;
> + of_soc->device.platform = platform;
> + of_soc->machine.name = of_soc->dai_link.cpu_dai->name;
> +
> + /* Now try to register the SoC device */
> + of_snd_soc_register_device(of_soc);
> +
> + out:
> + mutex_unlock(&of_snd_soc_mutex);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(of_snd_soc_register_platform);
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* NAND Flash, Localbus and UPM
From: Alemao @ 2008-07-14 14:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Im trying to use a NAND flash (NAND512W3A, from ST) in MPC8360
localbus, with UPM.
My board is based on the mpc8360erdk. I also have a NOR flash
connected in the localbus.
But I have some doubts in how to put this information at the DTS file.
Im doing this way:
soc8360@e0000000 {
.
.
.
};
localbus@e0005000 {
compatible = "fsl,mpc8360-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <e0005000 d8>;
ranges = <0 0 ff800000 1000000 // nor flash, 16 MB
1 0 60000000 4000000>; // nand
flash, 64 MB (512 Mb)
nor-flash@0,0 {
compatible = "amd,s29glxxx", "cfi-flash";
reg = <0 0 40000>;
bank-width = <2>;
device-width = <1>;
};
nand-flash@1,0 {
compatible = "stmicro,NAND512W3A", "fsl,upm-nand";
reg = <1 0 4000000>; //reg = <1 0 1>;
width = <1>;
upm = "A";
upm-addr-offset = <16>;
upm-cmd-offset = <8>;
gpios = <4 18>;
gpio-parent = <&qe_pio>;
wait-pattern;
wait-write;
};
};
In range information:
ranges = <0 0 ff800000 1000000 // nor flash, 16 MB
1 0 60000000 4000000>; // nand flash, 64 MB (512 Mb)
i dont know what ff800000 and 60000000 means,
i got those values from some posts in the mail-list. I also searched
the datasheet and didnt find anything about those values.
The size values, 1000000 and 4000000, im using the memory density.
Is this correct? Cause i read some posts that the nand size was very
small, like 32K, seems that its something like the block size of
nand.
In reg information:
reg = <0 0 1000000>; // nor-flash
reg = <1 0 4000000>; // nand-flash
Dont know if its correct. The third argument i used the size,
but the second i dont know what value use.
In other post by Anton, i saw something like these:
upm@1,0 {
flash {
...
};
};
Should i use it?
I must confess, im really confuse about all this stuffs.
I read linux/Documentation/powerpc/booting-without-of.txt but didnt
clarify so much.
Cheers,
--
Alemao
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Mark Brown @ 2008-07-14 15:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <9e4733910807140713r5739efedw81e65632006d101d@mail.gmail.com>
On Mon, Jul 14, 2008 at 10:13:14AM -0400, Jon Smirl wrote:
> On 7/14/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > Ideally someone from the PowerPC community would sign off on this -
> > given the nature and volume of discussion people obviously have very
> Grant is one of the core PowerPC developers. There's no big
OK, fair enough...
> Hopefully we can get the driver model sorted out in v2. If the ASoC
> driver model is fixed all of this glue code disappears.
> The PowerPC side isn't without fault too. PowerPC still doesn't have a
> good way to load the fabric/machine driver.
I'm finding it difficult to square these two statements - from an ASoC
point of view the main thing this patch is doing is adding a machine
driver and that's not something that's going to go away. With version 2
you will get the wait for all components to come on-line logic that's
implemented here from the ASoC core but that doesn't remove the need for
a machine driver to tell the core what to wait for and arrange any
machine specific things like clocking. It's this debate about machine
drivers that makes me nervous here.
Like I say, from an ASoC point of view it's not an issue and the current
approach is fine.
> Which are we going to call it, fabric or machine? I had been working
> on the Apple code in sound/aoa. It is called fabric in that code. The
> equivalent driver is called machine in ASoC v1.
ASoC has always called it a machine driver.
> > > This is most likely temporary glue code to work around limitations in
> > > the ASoC v1 framework. I expect ASoC v2 won't need this.
> >
> >
> > It will need some way of providing a machine driver, generic (like this
> > one) or otherwise.
[BTW, it'd be helpful if you could delete unreferenced quotes when you
reply - it makes things much easier to read, especially when reviewing
lengthy patches. Unfortunately the GMail UI encourages doing this :(]
^ permalink raw reply
* Is there anybody created the ML403 firmware in which XEMAC configured in "Scattered DMA" Mode
From: Naresh Bhat @ 2008-07-14 15:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
Hi All,
Is there anybody created the ML403 firmware in which XEMAC configured in
"Scattered DMA" Mode. Please provide me the .dts file and .bit file I am
not able to create it. Where can I get the "device tree" and "Reference
Design" (I think Xilinx) for the ML403 board?
--
Naresh Bhat
[-- Attachment #2: Type: text/html, Size: 350 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Timur Tabi @ 2008-07-14 15:51 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <9e4733910807140713r5739efedw81e65632006d101d@mail.gmail.com>
Jon Smirl wrote:
> Which are we going to call it, fabric or machine?
Fabric.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox