* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Benjamin Herrenschmidt @ 2008-07-15 10:37 UTC (permalink / raw)
To: Srinivasa DS; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <487C7C48.8090308@in.ibm.com>
On Tue, 2008-07-15 at 16:00 +0530, Srinivasa DS wrote:
> Sorry, I got it wrong, But I dont find my patch in your latest
> powerpc
> git tree(git.kernel.org/?p=linux/kernel/git/benh/powerpc.git).
Hrm... I thought I merged it. I'll check that tomorrow.
Cheers,
Ben.
^ permalink raw reply
* Re: 2.6.26 does not boot on Pegasos
From: Gabriel Paubert @ 2008-07-15 10:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, David Woodhouse
In-Reply-To: <1216116349.7740.101.camel@pasglop>
On Tue, Jul 15, 2008 at 08:05:49PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote:
> > Hi,
> >
> > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> > The last message I have is:
> > gunzip (0xffffffff <----- some more hex digits)
> >
> > The configuration has been created from a working 2.6.25 one with
> > make oldconfig and answering N to new config options.
> >
> > Anybody has seen this or do I have to start digging deeper?
>
> Unfortunately, I don't have a pegasos anymore. David, did you get a
> chance to test anything recent on yours ? Matt ?
I seem to remember that 2.6.26-rc5 booted fine. Compiling it right now
before I start a bisection.
Regards,
Gabriel
^ permalink raw reply
* Re: [PATCH] of: i2c: improve last resort compatible entry selection
From: Jochen Friedrich @ 2008-07-15 10:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Jean Delvare
In-Reply-To: <20080714175437.GA5230@polina.dev.rtsoft.ru>
Hi Anton,
> Since no sane driver will ever match specific devices, what we want is
> to select most generic option (last). Then driver may call
> of_device_is_compatible() if it is really interested in details.
My original intention was to have alias entries for specific devices in the
i2c device drivers. Later, Jean decided to only have the most generic names
in there (like in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21)
So your patch is correct.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Jochen Friedrich <jochen@scram.de>
Thanks,
Jochen
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-15 10:33 UTC (permalink / raw)
To: dinesh; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <1216108672.9701.5.camel@dinesh.dua>
On Tue, Jul 15, 2008 at 01:27:52PM +0530, dinesh wrote:
> I have one query about this soc driver.
> I want to know when u will merge it with kernel then
> where and by which name this device will be available
> in /dev directory of your file system.
> As i am following the same structure for my driver so please help me. I
> am ot able to recognise the device in the file system.
It will appear via the standard ALSA interfaces (and OSS interfaces if
you enable OSS compatibility). The standard location for ALSA device
files is under /dev/snd where you'll see several files per device.
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Srinivasa DS @ 2008-07-15 10:30 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1216113357.7740.95.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-15 at 14:36 +0530, Srinivasa D S wrote:
>> On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote:
>>
>>>> Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
>>> Can you send a cleanup patch against powerpc.git instead ?
>>>
>> Resending the patch against powerpc.git tree.
>
> Nah, your initial patch is there already :-) I'm just asking for a
> cleanup one that removes the useless cast.
>
Sorry, I got it wrong, But I dont find my patch in your latest powerpc
git tree(git.kernel.org/?p=linux/kernel/git/benh/powerpc.git).
Thanks
Srinivasa DS
^ 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-15 10:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi, liam.girdwood
In-Reply-To: <9e4733910807141645l404881b0m1d17d88c26792c78@mail.gmail.com>
On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote:
> On 7/14/08, Timur Tabi <timur@freescale.com> wrote:
> > Mark Brown wrote:
> > > chassis - on Linux drivers can be automatically loaded based on these
> > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver
> > > that does this.
> Allowing multiple binds at the root causes the problem of something
> like compatible="lite5200b,mpc5200-simple". Both platforms would bind
> and that's not what you want.
Binding isn't the issue here - it's loading the driver in the first
place. Once the drivers are loaded they can (hopefully) figure out if
they are running on appropriate hardware.
> Another scheme would be to add kernel code to always create virtual OF
> devices like "lite5200b-fabric" that are derived off from the machine
> name that achieved a bind.
This is what I'm suggesting, modulo the fact that I'm suggesting *not*
creating virtual devices but rather providing a mechanism for drivers to
load without binding to anything. It strikes me that you're going to
run into similar situations with other hardware at some point - either
for undocumented extras that you happen to know exist on the system
(like much of the DMI usage on x86) or for other things where you've got
on-board hardware structured like sound hardware tends to be.
^ permalink raw reply
* Re: 2.6.26 does not boot on Pegasos
From: Benjamin Herrenschmidt @ 2008-07-15 10:05 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev list, David Woodhouse
In-Reply-To: <20080715100033.GA5147@iram.es>
On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote:
> Hi,
>
> I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
> The last message I have is:
> gunzip (0xffffffff <----- some more hex digits)
>
> The configuration has been created from a working 2.6.25 one with
> make oldconfig and answering N to new config options.
>
> Anybody has seen this or do I have to start digging deeper?
Unfortunately, I don't have a pegasos anymore. David, did you get a
chance to test anything recent on yours ? Matt ?
Cheers,
Ben.
^ permalink raw reply
* 2.6.26 does not boot on Pegasos
From: Gabriel Paubert @ 2008-07-15 10:00 UTC (permalink / raw)
To: linuxppc-dev list
Hi,
I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot.
The last message I have is:
gunzip (0xffffffff <----- some more hex digits)
The configuration has been created from a working 2.6.25 one with
make oldconfig and answering N to new config options.
Anybody has seen this or do I have to start digging deeper?
Regards,
Gabriel
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Srinivasa D S @ 2008-07-15 9:21 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Paul Mackerras, Timur Tabi
In-Reply-To: <jemykkpdu8.fsf@sykes.suse.de>
On Monday 14 July 2008 11:06:47 pm Andreas Schwab wrote:
> Timur Tabi <timur@freescale.com> writes:
> > Srinivasa D S wrote:
> >> +#define task_pt_regs(tsk) (tsk)->thread.regs
> >
> > Shouldn't this be:
> >
> > #define task_pt_regs(tsk) ((tsk)->thread.regs)
> >
> > just to be safe?
>
> Both -> and . have already highest precedence as postfix operators.
>
Thanks for the comments, For safer side I have used "()" and sent the updated
patch.
Thanks
Srinivasa DS
^ permalink raw reply
* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Benjamin Herrenschmidt @ 2008-07-15 9:15 UTC (permalink / raw)
To: Srinivasa D S; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200807151436.55912.srinivasa@in.ibm.com>
On Tue, 2008-07-15 at 14:36 +0530, Srinivasa D S wrote:
> On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote:
>
> > > Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
> >
> > Can you send a cleanup patch against powerpc.git instead ?
> >
>
> Resending the patch against powerpc.git tree.
Nah, your initial patch is there already :-) I'm just asking for a
cleanup one that removes the useless cast.
Cheers,
Ben.
>
> Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
>
>
> ---
> include/asm-powerpc/processor.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: powerpc.git/include/asm-powerpc/processor.h
> ===================================================================
> --- powerpc.git.orig/include/asm-powerpc/processor.h
> +++ powerpc.git/include/asm-powerpc/processor.h
> @@ -234,6 +234,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: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Srinivasa D S @ 2008-07-15 9:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1216026417.7549.270.camel@pasglop>
On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote:
> > Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
>
> Can you send a cleanup patch against powerpc.git instead ?
>
Resending the patch against powerpc.git tree.
Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
---
include/asm-powerpc/processor.h | 2 ++
1 file changed, 2 insertions(+)
Index: powerpc.git/include/asm-powerpc/processor.h
===================================================================
--- powerpc.git.orig/include/asm-powerpc/processor.h
+++ powerpc.git/include/asm-powerpc/processor.h
@@ -234,6 +234,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: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-15 8:36 UTC (permalink / raw)
To: David Hubbard
Cc: Ortiz, Samuel, linux-kernel, Milton Miller, lm-sensors,
linuxppc-dev, Hans de Goede
In-Reply-To: <4dfa50520807141055l532caaaai700255936600e5ae@mail.gmail.com>
On Mon, 14 Jul 2008 11:55:01 -0600, David Hubbard wrote:
> Hi Hans,
>
> On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede <j.w.r.degoede@hhs.nl> wrote:
> > Milton Miller wrote:
> >> I haven't done the research, but it might be keep superio as
> >> a platform driver, and keep the clients as platform drivers. Only
> >> have the superio driver probe and discover the subcomponent
> >> addresses and then create the platform devices as children
> >> instead of having each driver create its own platform device.
> >> (This all assumes they are all platform devices in sysfs, I have
> >> not looked).
> >>
> >> This is all because in the platform bus the bus driver does not
> >> discover the addresses but relies on drivers or platform setup code.
> >
> > This sounds like a good plan, rather then add a new bus type add a superio
> > platform driver which does superio probing and registering of platform devices
> > for discovered logical devices.
> >
> > This superio platform driver then needs to also export some functions of those
> > few logical devices which need access to the superio registers for more then
> > just finding out their own base address.
> >
> > I guess that it then would be best to load this superio driver by default on
> > most systems.
> >
> > How does this all mix and match with isapnp, it feels to me we're doing
> > somewhat the same as isapnp here.
>
> Is there any way to use lspci and start at the LPC bridge, then find
> the SuperIO chip's IO address? What about ACPI tables? Perhaps probing
> logic could look for an LPC bridge before probing certain IO addresses
> even if the addresses are not in the LPC bridge config.
I always assumed that there was no way to know in advance if a
Super-I/O (LPC) chip was present or not, let alone the exact model of
the chip. The I/O addresses are decoded by the Super-I/O chip itself,
and in general it has no relation to PCI. And I've never seen ports
0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports.
But of course if there is a way to know, we should use it. Avoiding
random access to I/O ports, even if they are relatively standard in
this case, is always good.
> A superio platform driver is a good way to go -- it fits with the way
> the platform bus does things. Also, Jim's patches are almost there
> already.
Good.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-15 8:28 UTC (permalink / raw)
To: Milton Miller
Cc: Samuel Ortiz, linux-kernel, lm-sensors, linuxppc-dev,
Hans de Goede, David Hubbard
In-Reply-To: <88f5162604470179b3c6ebfe729a46f5@bga.com>
Hi Milton,
On Mon, 14 Jul 2008 12:09:03 -0500, Milton Miller wrote:
> On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote:
> > 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.
>
> I haven't done the research, but it might be keep superio as
> a platform driver, and keep the clients as platform drivers. Only
> have the superio driver probe and discover the subcomponent
> addresses and then create the platform devices as children
> instead of having each driver create its own platform device.
> (This all assumes they are all platform devices in sysfs, I have
> not looked).
>
> This is all because in the platform bus the bus driver does not
> discover the addresses but relies on drivers or platform setup code.
That's more or less what I had in mind, yes.
> > (...) Milton, will you write a patch?
>
> Well, that is the second time you asked me, so I guess I should respond.
>
> While I it is possible for me to write this patch, my schedule and
> priority list predict it would not be before the merge window closes.
> In fact, I'm not sure when it would come out. It might be argued it
> could go in early -rc, but I would fear somebody's chip will not be detected
> with the additional check. For example, the port may reserved as mother
> board resources or something.
I really don't see this as something for kernel 2.6.27, it's too late
already. It doesn't fix any actual problem anyway (none that can be
fixed by not loading drivers you don't need, at least.) That would be
for 2.6.28, so we have plenty of time to test the changes and ensure
they do not break anything. As you are the one who reported the issue
as something that was bothering you personally, I expected you to also
spend some time trying to address it.
> (...) Also, I have no hardware to test any
> proposed patch, so it would be compile check only.
If you write the patches and post them to the lm-sensors list, I am
certain that you will find several volunteers for testing. Me, I can
offer testing of the it87, f71805f and w83627ehf drivers.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: dinesh @ 2008-07-15 7:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080712083939.15025.31192.stgit@trillian.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 23131 bytes --]
Hi
I have one query about this soc driver.
I want to know when u will merge it with kernel then
where and by which name this device will be available
in /dev directory of your file system.
As i am following the same structure for my driver so please help me. I
am ot able to recognise the device in the file system.
-----Original Message-----
From: Grant Likely <grant.likely@secretlab.ca>
To: linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
liam.girdwood@wolfsonmicro.com, jonsmirl@gmail.com
Subject: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments
TLV320AIC26 codec driver
Date: Sat, 12 Jul 2008 02:39:39 -0600
From: Grant Likely <grant.likely@secretlab.ca>
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.
---
sound/soc/codecs/Kconfig | 4
sound/soc/codecs/Makefile | 2
sound/soc/codecs/tlv320aic26.c | 546 ++++++++++++++++++++++++++++++++++++++++
sound/soc/codecs/tlv320aic26.h | 103 ++++++++
4 files changed, 655 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 3903ab7..96c7bfe 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -41,6 +41,10 @@ config SND_SOC_CS4270_VD33_ERRATA
bool
depends on SND_SOC_CS4270
+config SND_SOC_TLV320AIC26
+ tristate "TI TLB320AIC26 Codec support"
+ depends on SND_SOC && SPI
+
config SND_SOC_TLV320AIC3X
tristate
depends on SND_SOC && I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 4e1314c..ec0cd93 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -5,6 +5,7 @@ snd-soc-wm8753-objs := wm8753.o
snd-soc-wm9712-objs := wm9712.o
snd-soc-wm9713-objs := wm9713.o
snd-soc-cs4270-objs := cs4270.o
+snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
@@ -14,4 +15,5 @@ obj-$(CONFIG_SND_SOC_WM8753) += snd-soc-wm8753.o
obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
+obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
new file mode 100644
index 0000000..3ebfa23
--- /dev/null
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -0,0 +1,546 @@
+/*
+ * Texas Instruments TLV320AIC26 low power audio CODEC
+ * ALSA SoC CODEC driver
+ *
+ * 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/device.h>
+#include <linux/sysfs.h>
+#include <linux/spi/spi.h>
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+#include <sound/soc-dapm.h>
+#include <sound/soc-of.h>
+#include <sound/initval.h>
+
+#include "tlv320aic26.h"
+
+MODULE_DESCRIPTION("ASoC TLV320AIC26 codec driver");
+MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
+MODULE_LICENSE("GPL");
+
+/* AIC26 driver private data */
+struct aic26 {
+ struct spi_device *spi;
+ struct snd_soc_codec codec;
+ u16 reg_cache[AIC26_REG_CACHE_SIZE]; /* shadow registers */
+ int master;
+ int datfm;
+ int mclk;
+
+ /* Keyclick parameters */
+ int keyclick_amplitude;
+ int keyclick_freq;
+ int keyclick_len;
+};
+
+/* ---------------------------------------------------------------------
+ * Register access routines
+ */
+static unsigned int aic26_reg_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ struct aic26 *aic26 = codec->private_data;
+ u16 *cache = codec->reg_cache;
+ u16 cmd, value;
+ u8 buffer[2];
+ int rc;
+
+ if (reg >= AIC26_NUM_REGS) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ /* Do SPI transfer; first 16bits are command; remaining is
+ * register contents */
+ cmd = AIC26_READ_COMMAND_WORD(reg);
+ buffer[0] = (cmd >> 8) & 0xff;
+ buffer[1] = cmd & 0xff;
+ rc = spi_write_then_read(aic26->spi, buffer, 2, buffer, 2);
+ if (rc) {
+ dev_err(&aic26->spi->dev, "AIC26 reg read error\n");
+ return -EIO;
+ }
+ value = (buffer[0] << 8) | buffer[1];
+
+ /* Update the cache before returning with the value */
+ if (AIC26_REG_IS_CACHED(reg))
+ cache[AIC26_REG_CACHE_ADDR(reg)] = value;
+ return value;
+}
+
+static unsigned int aic26_reg_read_cache(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ u16 *cache = codec->reg_cache;
+
+ if ((reg < 0) || (reg >= AIC26_NUM_REGS)) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ if (AIC26_REG_IS_CACHED(reg))
+ return cache[AIC26_REG_CACHE_ADDR(reg)];
+
+ return aic26_reg_read(codec, reg);
+}
+
+static int aic26_reg_write(struct snd_soc_codec *codec, unsigned int reg,
+ unsigned int value)
+{
+ struct aic26 *aic26 = codec->private_data;
+ u16 *cache = codec->reg_cache;
+ u16 cmd;
+ u8 buffer[4];
+ int rc;
+
+ if ((reg < 0) || (reg >= AIC26_NUM_REGS)) {
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
+
+ /* Do SPI transfer; first 16bits are command; remaining is data
+ * to write into register */
+ cmd = AIC26_WRITE_COMMAND_WORD(reg);
+ buffer[0] = (cmd >> 8) & 0xff;
+ buffer[1] = cmd & 0xff;
+ buffer[2] = value >> 8;
+ buffer[3] = value;
+ rc = spi_write(aic26->spi, buffer, 4);
+ if (rc) {
+ dev_err(&aic26->spi->dev, "AIC26 reg read error\n");
+ return -EIO;
+ }
+
+ /* update cache before returning */
+ if (AIC26_REG_IS_CACHED(reg))
+ cache[AIC26_REG_CACHE_ADDR(reg)] = value;
+ return 0;
+}
+
+/* ---------------------------------------------------------------------
+ * Digital Audio Interface Operations
+ */
+static int aic26_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_device *socdev = rtd->socdev;
+ struct snd_soc_codec *codec = socdev->codec;
+ struct aic26 *aic26 = codec->private_data;
+ int fsref, divisor, wlen, pval, jval, dval, qval;
+ u16 reg;
+
+ dev_dbg(&aic26->spi->dev, "aic26_hw_params(substream=%p, params=%p)\n",
+ substream, params);
+ dev_dbg(&aic26->spi->dev, "rate=%i format=%i\n", params_rate(params),
+ params_format(params));
+
+ switch (params_rate(params)) {
+ case 8000: fsref = 48000; divisor = AIC26_DIV_6; break;
+ case 11025: fsref = 44100; divisor = AIC26_DIV_4; break;
+ case 12000: fsref = 48000; divisor = AIC26_DIV_4; break;
+ case 16000: fsref = 48000; divisor = AIC26_DIV_3; break;
+ case 22050: fsref = 44100; divisor = AIC26_DIV_2; break;
+ case 24000: fsref = 48000; divisor = AIC26_DIV_2; break;
+ case 32000: fsref = 48000; divisor = AIC26_DIV_1_5; break;
+ case 44100: fsref = 44100; divisor = AIC26_DIV_1; break;
+ case 48000: fsref = 48000; divisor = AIC26_DIV_1; break;
+ default: dev_dbg(&aic26->spi->dev, "bad rate\n"); return -EINVAL;
+ }
+
+ /* select data word length */
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S8: wlen = AIC26_WLEN_16; break;
+ case SNDRV_PCM_FORMAT_S16_BE: wlen = AIC26_WLEN_16; break;
+ case SNDRV_PCM_FORMAT_S24_BE: wlen = AIC26_WLEN_24; break;
+ case SNDRV_PCM_FORMAT_S32_BE: wlen = AIC26_WLEN_32; break;
+ default: dev_dbg(&aic26->spi->dev, "bad format\n"); return -EINVAL;
+ }
+
+ /* 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);
+
+ /* Power up CODEC */
+ aic26_reg_write(codec, AIC26_REG_POWER_CTRL, 0);
+
+ /* Audio Control 3 (master mode, fsref rate) */
+ reg = aic26_reg_read_cache(codec, AIC26_REG_AUDIO_CTRL3);
+ reg &= ~0xf800;
+ if (aic26->master)
+ reg |= 0x0800;
+ if (fsref == 48000)
+ reg |= 0x2000;
+ aic26_reg_write(codec, AIC26_REG_AUDIO_CTRL3, reg);
+
+ /* Audio Control 1 (FSref divisor) */
+ reg = aic26_reg_read_cache(codec, AIC26_REG_AUDIO_CTRL1);
+ reg &= ~0x0fff;
+ reg |= wlen | aic26->datfm | (divisor << 3) | divisor;
+ aic26_reg_write(codec, AIC26_REG_AUDIO_CTRL1, reg);
+
+ return 0;
+}
+
+/**
+ * aic26_mute - Mute control to reduce noise when changing audio format
+ */
+static int aic26_mute(struct snd_soc_codec_dai *dai, int mute)
+{
+ struct snd_soc_codec *codec = dai->codec;
+ struct aic26 *aic26 = codec->private_data;
+ u16 reg = aic26_reg_read_cache(codec, AIC26_REG_DAC_GAIN);
+
+ dev_dbg(&aic26->spi->dev, "aic26_mute(dai=%p, mute=%i)\n",
+ dai, mute);
+
+ if (mute)
+ reg |= 0x8080;
+ else
+ reg &= ~0x8080;
+ aic26_reg_write(codec, AIC26_REG_DAC_GAIN, reg);
+
+ return 0;
+}
+
+static int aic26_set_sysclk(struct snd_soc_codec_dai *codec_dai,
+ int clk_id, unsigned int freq, int dir)
+{
+ struct snd_soc_codec *codec = codec_dai->codec;
+ struct aic26 *aic26 = codec->private_data;
+
+ dev_dbg(&aic26->spi->dev, "aic26_set_sysclk(dai=%p, clk_id==%i,"
+ " freq=%i, dir=%i)\n",
+ codec_dai, clk_id, freq, dir);
+
+ /* MCLK needs to fall between 2MHz and 50 MHz */
+ if ((freq < 2000000) || (freq > 50000000))
+ return -EINVAL;
+
+ aic26->mclk = freq;
+ return 0;
+}
+
+static int aic26_set_fmt(struct snd_soc_codec_dai *codec_dai, unsigned int fmt)
+{
+ struct snd_soc_codec *codec = codec_dai->codec;
+ struct aic26 *aic26 = codec->private_data;
+
+ dev_dbg(&aic26->spi->dev, "aic26_set_fmt(dai=%p, fmt==%i)\n",
+ codec_dai, fmt);
+
+ /* set master/slave audio interface */
+ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFM: aic26->master = 1; break;
+ case SND_SOC_DAIFMT_CBS_CFS: aic26->master = 0; break;
+ default: dev_dbg(&aic26->spi->dev, "bad master\n"); return -EINVAL;
+ }
+
+ /* 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;
+ }
+
+ return 0;
+}
+
+/* ---------------------------------------------------------------------
+ * Digital Audio Interface Definition
+ */
+struct snd_soc_codec_dai aic26_dai = {
+ .name = "tlv320aic26",
+ .playback = {
+ .stream_name = "Playback",
+ .channels_min = 2,
+ .channels_max = 2,
+ .rates = AIC26_RATES,
+ .formats = AIC26_FORMATS,
+ },
+ .capture = {
+ .stream_name = "Capture",
+ .channels_min = 2,
+ .channels_max = 2,
+ .rates = AIC26_RATES,
+ .formats = AIC26_FORMATS,
+ },
+ .ops = {
+ .hw_params = aic26_hw_params,
+ },
+ .dai_ops = {
+ .digital_mute = aic26_mute,
+ .set_sysclk = aic26_set_sysclk,
+ .set_fmt = aic26_set_fmt,
+ },
+};
+EXPORT_SYMBOL_GPL(aic26_dai);
+
+/* ---------------------------------------------------------------------
+ * ALSA controls
+ */
+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);
+
+static const struct snd_kcontrol_new aic26_snd_controls[] = {
+ /* Output */
+ SOC_DOUBLE("PCM Playback Volume", AIC26_REG_DAC_GAIN, 8, 0, 0x7f, 1),
+ SOC_DOUBLE("PCM Playback Switch", AIC26_REG_DAC_GAIN, 15, 7, 1, 1),
+ SOC_SINGLE("PCM Capture Volume", AIC26_REG_ADC_GAIN, 8, 0x7f, 0),
+ SOC_SINGLE("PCM Capture Mute", AIC26_REG_ADC_GAIN, 15, 1, 1),
+ 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),
+ SOC_ENUM("Capture Source", aic26_capture_src_enum),
+};
+
+/* ---------------------------------------------------------------------
+ * SoC CODEC portion of driver: probe and release routines
+ */
+static int aic26_probe(struct platform_device *pdev)
+{
+ struct snd_soc_device *socdev = platform_get_drvdata(pdev);
+ struct snd_soc_codec *codec;
+ struct snd_kcontrol *kcontrol;
+ struct aic26 *aic26;
+ int i, ret, err;
+
+ dev_info(&pdev->dev, "Probing AIC26 SoC CODEC driver\n");
+ dev_dbg(&pdev->dev, "socdev=%p\n", socdev);
+ dev_dbg(&pdev->dev, "codec_data=%p\n", socdev->codec_data);
+
+ /* Fetch the relevant aic26 private data here (it's already been
+ * stored in the .codec pointer) */
+ aic26 = socdev->codec_data;
+ if (aic26 == NULL) {
+ dev_err(&pdev->dev, "aic26: missing codec pointer\n");
+ return -ENODEV;
+ }
+ codec = &aic26->codec;
+ socdev->codec = codec;
+
+ dev_dbg(&pdev->dev, "Registering PCMs, dev=%p, socdev->dev=%p\n",
+ &pdev->dev, socdev->dev);
+ /* register pcms */
+ ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "aic26: failed to create pcms\n");
+ return -ENODEV;
+ }
+
+ /* register controls */
+ dev_dbg(&pdev->dev, "Registering controls\n");
+ for (i = 0; i < ARRAY_SIZE(aic26_snd_controls); i++) {
+ kcontrol = snd_soc_cnew(&aic26_snd_controls[i], codec, NULL);
+ err = snd_ctl_add(codec->card, kcontrol);
+ WARN_ON(err < 0);
+ }
+
+ /* CODEC is setup, we can register the card now */
+ dev_dbg(&pdev->dev, "Registering card\n");
+ ret = snd_soc_register_card(socdev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "aic26: failed to register card\n");
+ goto card_err;
+ }
+ return 0;
+
+ card_err:
+ snd_soc_free_pcms(socdev);
+ return ret;
+}
+
+static int aic26_remove(struct platform_device *pdev)
+{
+ struct snd_soc_device *socdev = platform_get_drvdata(pdev);
+ snd_soc_free_pcms(socdev);
+ return 0;
+}
+
+struct snd_soc_codec_device aic26_soc_codec_dev = {
+ .probe = aic26_probe,
+ .remove = aic26_remove,
+};
+
+/* ---------------------------------------------------------------------
+ * SPI device portion of driver: sysfs files for debugging
+ */
+
+static ssize_t aic26_regs_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aic26 *aic26 = dev_get_drvdata(dev);
+ char *idx = buf;
+ int cache_flag, addr, page, i, reg;
+
+ cache_flag = (strcmp(attr->attr.name, "regs_cache") == 0);
+
+ for (page = 0; page < 3; page++) {
+ for (i = 0; i < 0x20; i++) {
+ addr = AIC26_PAGE_ADDR(page, i);
+ if (i % 8 == 0)
+ idx += sprintf(idx, "%i:%.2i:", page,i);
+ if (cache_flag)
+ reg = aic26_reg_read_cache(&aic26->codec, addr);
+ else
+ reg = aic26_reg_read(&aic26->codec, addr);
+ idx += sprintf(idx, " %.4x", reg);
+ if (i % 8 == 7)
+ idx += sprintf(idx, "\n");
+ }
+ }
+ return idx - buf;
+}
+
+static ssize_t aic26_keyclick_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct aic26 *aic26 = dev_get_drvdata(dev);
+ int val, amp, freq, len;
+
+ val = aic26_reg_read_cache(&aic26->codec, AIC26_REG_AUDIO_CTRL2);
+ amp = (val >> 12) & 0x7;
+ freq = (125 << ((val >> 8) & 0x7)) >> 1;
+ len = 2 * (1 +((val >> 4) & 0xf));
+
+ return sprintf(buf, "amp=%x freq=%iHz len=%iclks\n", amp, freq, len);
+}
+
+/* Any write to the keyclick attribute will trigger the keyclick */
+static ssize_t aic26_keyclick_set(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct aic26 *aic26 = dev_get_drvdata(dev);
+ int val;
+
+ val = aic26_reg_read_cache(&aic26->codec, AIC26_REG_AUDIO_CTRL2);
+ val |= 0x8000;
+ aic26_reg_write(&aic26->codec, AIC26_REG_AUDIO_CTRL2, val);
+
+ return count;
+}
+
+DEVICE_ATTR(regs, 0644, aic26_regs_show, NULL);
+DEVICE_ATTR(regs_cache, 0644, aic26_regs_show, NULL);
+DEVICE_ATTR(keyclick, 0644, aic26_keyclick_show, aic26_keyclick_set);
+
+/* ---------------------------------------------------------------------
+ * SPI device portion of driver: probe and release routines and SPI
+ * driver registration.
+ */
+static int aic26_spi_probe(struct spi_device *spi)
+{
+ struct aic26 *aic26;
+ int rc, i, reg;
+
+ dev_dbg(&spi->dev, "probing tlv320aic26 spi device\n");
+
+ /* Allocate driver data */
+ aic26 = kzalloc(sizeof *aic26, GFP_KERNEL);
+ if (!aic26)
+ return -ENOMEM;
+
+ /* Initialize the driver data */
+ aic26->spi = spi;
+ dev_set_drvdata(&spi->dev, aic26);
+
+ /* Setup what we can in the codec structure so that the register
+ * access functions will work as expected. More will be filled
+ * out when it is probed by the SoC CODEC part of this driver */
+ aic26->codec.private_data = aic26;
+ aic26->codec.name = "aic26";
+ aic26->codec.owner = THIS_MODULE;
+ aic26->codec.dai = &aic26_dai;
+ aic26->codec.num_dai = 1;
+ aic26->codec.read = aic26_reg_read;
+ aic26->codec.write = aic26_reg_write;
+ aic26->master = 1;
+ mutex_init(&aic26->codec.mutex);
+ INIT_LIST_HEAD(&aic26->codec.dapm_widgets);
+ INIT_LIST_HEAD(&aic26->codec.dapm_paths);
+ aic26->codec.reg_cache_size = sizeof(aic26->reg_cache);
+ aic26->codec.reg_cache = aic26->reg_cache;
+
+ /* Reset the codec to power on defaults */
+ aic26_reg_write(&aic26->codec, AIC26_REG_RESET, 0xBB00);
+
+ /* Power up CODEC */
+ aic26_reg_write(&aic26->codec, AIC26_REG_POWER_CTRL, 0);
+
+ /* Audio Control 3 (master mode, fsref rate) */
+ reg = aic26_reg_read(&aic26->codec, AIC26_REG_AUDIO_CTRL3);
+ reg &= ~0xf800;
+ reg |= 0x0800; /* set master mode */
+ aic26_reg_write(&aic26->codec, AIC26_REG_AUDIO_CTRL3, reg);
+
+ /* Fill page 2 register cache */
+ for (i = 0; i < ARRAY_SIZE(aic26->reg_cache); i++)
+ aic26_reg_read(&aic26->codec, AIC26_PAGE_ADDR(2, i));
+
+ /* Register the sysfs files for debugging */
+ /* Create SysFS files */
+ rc = device_create_file(&spi->dev, &dev_attr_regs);
+ rc |= device_create_file(&spi->dev, &dev_attr_regs_cache);
+ rc |= device_create_file(&spi->dev, &dev_attr_keyclick);
+ if (rc)
+ dev_info(&spi->dev, "error creating sysfs files\n");
+
+#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
+
+ dev_dbg(&spi->dev, "SPI device initialized\n");
+ return 0;
+}
+
+static int aic26_spi_remove(struct spi_device *spi)
+{
+ struct aic26 *aic26 = dev_get_drvdata(&spi->dev);
+
+ kfree(aic26);
+
+ return 0;
+}
+
+static struct spi_driver aic26_spi = {
+ .driver = {
+ .name = "tlv320aic26",
+ .owner = THIS_MODULE,
+ },
+ .probe = aic26_spi_probe,
+ .remove = aic26_spi_remove,
+};
+
+static int __init aic26_init(void)
+{
+ return spi_register_driver(&aic26_spi);
+}
+module_init(aic26_init);
+
+static void __exit aic26_exit(void)
+{
+ spi_unregister_driver(&aic26_spi);
+}
+module_exit(aic26_exit);
diff --git a/sound/soc/codecs/tlv320aic26.h b/sound/soc/codecs/tlv320aic26.h
new file mode 100644
index 0000000..9edb8e9
--- /dev/null
+++ b/sound/soc/codecs/tlv320aic26.h
@@ -0,0 +1,103 @@
+/*
+ * Texas Instruments TLV320AIC26 low power audio CODEC
+ * register definitions
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#ifndef _TLV320AIC16_H_
+#define _TLV320AIC16_H_
+
+/* AIC26 Registers */
+#define AIC26_READ_COMMAND_WORD(addr) ((1 << 15) | (addr << 5))
+#define AIC26_WRITE_COMMAND_WORD(addr) ((0 << 15) | (addr << 5))
+#define AIC26_PAGE_ADDR(page, offset) ((page << 6) | offset)
+#define AIC26_NUM_REGS AIC26_PAGE_ADDR(3, 0)
+#define AIC26_REG_CACHE_SIZE (0x20) /* only page 2 cached */
+#define AIC26_REG_IS_CACHED(addr) ((addr & ~0x1f) == (2 << 6))
+#define AIC26_REG_CACHE_ADDR(addr) (addr & 0x1f)
+
+/* Page 0: Auxillary data registers */
+#define AIC26_REG_BAT1 AIC26_PAGE_ADDR(0, 0x05)
+#define AIC26_REG_BAT2 AIC26_PAGE_ADDR(0, 0x06)
+#define AIC26_REG_AUX AIC26_PAGE_ADDR(0, 0x07)
+#define AIC26_REG_TEMP1 AIC26_PAGE_ADDR(0, 0x09)
+#define AIC26_REG_TEMP2 AIC26_PAGE_ADDR(0, 0x0A)
+
+/* Page 1: Auxillary control registers */
+#define AIC26_REG_AUX_ADC AIC26_PAGE_ADDR(1, 0x00)
+#define AIC26_REG_STATUS AIC26_PAGE_ADDR(1, 0x01)
+#define AIC26_REG_REFERENCE AIC26_PAGE_ADDR(1, 0x03)
+#define AIC26_REG_RESET AIC26_PAGE_ADDR(1, 0x04)
+
+/* Page 2: Audio control registers */
+#define AIC26_REG_AUDIO_CTRL1 AIC26_PAGE_ADDR(2, 0x00)
+#define AIC26_REG_ADC_GAIN AIC26_PAGE_ADDR(2, 0x01)
+#define AIC26_REG_DAC_GAIN AIC26_PAGE_ADDR(2, 0x02)
+#define AIC26_REG_SIDETONE AIC26_PAGE_ADDR(2, 0x03)
+#define AIC26_REG_AUDIO_CTRL2 AIC26_PAGE_ADDR(2, 0x04)
+#define AIC26_REG_POWER_CTRL AIC26_PAGE_ADDR(2, 0x05)
+#define AIC26_REG_AUDIO_CTRL3 AIC26_PAGE_ADDR(2, 0x06)
+
+#define AIC26_REG_FILTER_COEFF_L_N0 AIC26_PAGE_ADDR(2, 0x07)
+#define AIC26_REG_FILTER_COEFF_L_N1 AIC26_PAGE_ADDR(2, 0x08)
+#define AIC26_REG_FILTER_COEFF_L_N2 AIC26_PAGE_ADDR(2, 0x09)
+#define AIC26_REG_FILTER_COEFF_L_N3 AIC26_PAGE_ADDR(2, 0x0A)
+#define AIC26_REG_FILTER_COEFF_L_N4 AIC26_PAGE_ADDR(2, 0x0B)
+#define AIC26_REG_FILTER_COEFF_L_N5 AIC26_PAGE_ADDR(2, 0x0C)
+#define AIC26_REG_FILTER_COEFF_L_D1 AIC26_PAGE_ADDR(2, 0x0D)
+#define AIC26_REG_FILTER_COEFF_L_D2 AIC26_PAGE_ADDR(2, 0x0E)
+#define AIC26_REG_FILTER_COEFF_L_D4 AIC26_PAGE_ADDR(2, 0x0F)
+#define AIC26_REG_FILTER_COEFF_L_D5 AIC26_PAGE_ADDR(2, 0x10)
+#define AIC26_REG_FILTER_COEFF_R_N0 AIC26_PAGE_ADDR(2, 0x11)
+#define AIC26_REG_FILTER_COEFF_R_N1 AIC26_PAGE_ADDR(2, 0x12)
+#define AIC26_REG_FILTER_COEFF_R_N2 AIC26_PAGE_ADDR(2, 0x13)
+#define AIC26_REG_FILTER_COEFF_R_N3 AIC26_PAGE_ADDR(2, 0x14)
+#define AIC26_REG_FILTER_COEFF_R_N4 AIC26_PAGE_ADDR(2, 0x15)
+#define AIC26_REG_FILTER_COEFF_R_N5 AIC26_PAGE_ADDR(2, 0x16)
+#define AIC26_REG_FILTER_COEFF_R_D1 AIC26_PAGE_ADDR(2, 0x17)
+#define AIC26_REG_FILTER_COEFF_R_D2 AIC26_PAGE_ADDR(2, 0x18)
+#define AIC26_REG_FILTER_COEFF_R_D4 AIC26_PAGE_ADDR(2, 0x19)
+#define AIC26_REG_FILTER_COEFF_R_D5 AIC26_PAGE_ADDR(2, 0x1A)
+
+#define AIC26_REG_PLL_PROG1 AIC26_PAGE_ADDR(2, 0x1B)
+#define AIC26_REG_PLL_PROG2 AIC26_PAGE_ADDR(2, 0x1C)
+#define AIC26_REG_AUDIO_CTRL4 AIC26_PAGE_ADDR(2, 0x1D)
+#define AIC26_REG_AUDIO_CTRL5 AIC26_PAGE_ADDR(2, 0x1E)
+
+#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)
+
+/* fsref dividers; used in register 'Audio Control 1' */
+enum aic26_divisors {
+ AIC26_DIV_1 = 0,
+ AIC26_DIV_1_5 = 1,
+ AIC26_DIV_2 = 2,
+ AIC26_DIV_3 = 3,
+ AIC26_DIV_4 = 4,
+ AIC26_DIV_5 = 5,
+ AIC26_DIV_5_5 = 6,
+ AIC26_DIV_6 = 7,
+};
+
+/* Digital data format */
+enum aic26_datfm {
+ AIC26_DATFM_I2S = 0 << 8,
+ AIC26_DATFM_DSP = 1 << 8,
+ AIC26_DATFM_RIGHTJ = 2 << 8, /* right justified */
+ AIC26_DATFM_LEFTJ = 3 << 8, /* left justified */
+};
+
+/* Sample word length in bits; used in register 'Audio Control 1' */
+enum aic26_wlen {
+ AIC26_WLEN_16 = 0 << 10,
+ AIC26_WLEN_20 = 1 << 10,
+ AIC26_WLEN_24 = 2 << 10,
+ AIC26_WLEN_32 = 3 << 10,
+};
+
+#endif /* _TLV320AIC16_H_ */
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[-- Attachment #2: Type: text/html, Size: 25433 bytes --]
^ permalink raw reply related
* Re: powerpc.git merge status
From: Benjamin Herrenschmidt @ 2008-07-15 8:01 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list
In-Reply-To: <fa686aa40807142316j7ffdab74u1441179dbf4529f8@mail.gmail.com>
On Tue, 2008-07-15 at 00:16 -0600, Grant Likely wrote:
> On Tue, Jul 15, 2008 at 12:02 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > If you believe I've missed something, now is time to be vocal about
> > it :-)
>
> I've also got some SPI stuff, but it depends on a commit in another
> tree so I'll wait until it's in Linus' tree before I ask you to pull.
Ok.
Cheers,
Ben
^ permalink raw reply
* Re: NAND Flash, Localbus and UPM
From: Marco Stornelli @ 2008-07-15 6:38 UTC (permalink / raw)
To: Alemao; +Cc: linuxppc-embedded
In-Reply-To: <d970ff420807140747s10d8276bt3a378a7cd5a4333d@mail.gmail.com>
Alemao ha scritto:
> 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;
> };
> };
>
Maybe it'd be better:
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>;
>
>
> 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,
They are the physical addresses. You have to write the addresses
according to your memory map.
> 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.
>
Ok the last value is the size.
>
>
> 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.
>
Ok, right. The second value is simply an offset.
>
>
> In other post by Anton, i saw something like these:
>
> upm@1,0 {
> flash {
> ...
> };
> };
>
>
> Should i use it?
No I think it's not needed, however, follow the instruction of
booting-without-of.txt. In this guide you can find all the nodes you can
use.
>
> 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
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: Neeraj Garg @ 2008-07-15 6:26 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-embedded
In-Reply-To: <20080709160659.EE3F6E28065@mail118-va3.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
Hi,
--Ron,Permissions are -rwxrwxr-x for all and owner is neeraj itself. And
shared libraries are present in lib/ . Now I have placed helloworld.elf
(using printf to print helloworld, and linked with -static option) in
bin/ and changed init=/bin/helloworld , again it says cannot execute
/bin/helloworld.
--John, we are using our custom hardware board, not exactly ML405 but
its more or less similar to ML405, so I cannot use bit file provided for
ML405. Till now we were using xilkernel, but now onward we are planning
to use Linux. For serial console I have no option other than uartlite.
This is how I compiled kernel :
1) make ARCH=ppc ml405_defconfig
2) patched kernel src with EDK(10.1) , so as to change xparameter.h, and
later made some changed in arch/ppc/boot/simple/embed_config.c and
xparameters.h file.
3) make ARCH=ppc menuconfig , and selected uartlite to be console and
ramdisk as file system.
4) Created ramdisk (as per Building embedded linux, Karim Yaghmour,
however major and minor number for device nodes is similar to ramdisk
provided at git.xilinx.com)
5) I have placed this ramdisk in arch/ppc/boot/images
6) And then issued $make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu-
zImge.initrd
--I have downloaded ELDK4.1 and installed it. And when I compile
simple helloworld.c using cross compiler, it says unresolved symbol
'printf' . Is there anything else to install with ELDK ?
-------------------------------------------------------------------
Neeraj Garg
In addition to what John wrote, I would also investigate your ramdisk.
I would be sure to check that you have the permissions/owner set correctly
on bin/busybox. Also, I would double check that, if you compiled busybox
with shared libraries, the shared libraries are in the right place
on your ramdisk.
Ron
>
> Hi,
>
> Yes I am using ARCH=ppc (actual line is $make ARCH=ppc
> CROSS_COMPILE=powerpc-405-linux-gnu- zImage.initrd ) for this I have
> placed ramdisk.image.gz in arch/ppc/boot/images. In case of ARCH=powerpc
> I cannot find processor type 405 , in make menuconfig. Thats why i am
> using ARCH=ppc.
>
[-- Attachment #2: Type: text/html, Size: 2695 bytes --]
^ permalink raw reply
* Re: powerpc.git merge status
From: Grant Likely @ 2008-07-15 6:16 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216101729.7740.84.camel@pasglop>
On Tue, Jul 15, 2008 at 12:02 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> If you believe I've missed something, now is time to be vocal about
> it :-)
I've also got some SPI stuff, but it depends on a commit in another
tree so I'll wait until it's in Linus' tree before I ask you to pull.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* powerpc.git merge status
From: Benjamin Herrenschmidt @ 2008-07-15 6:02 UTC (permalink / raw)
To: linuxppc-dev list
I've pulled from Kumar, Josh and Grant, along with applying some
patches hand picked from patchworks and build fixes. I've merged in
Linus as of today (minus David Woodhouse firmware patches that have a
build breakage) in order to fix a (fairly trivial) merge conflict.
I've now pushed that to my powerpc.git "master" branch for overnight
build-testing with kisskb at which point
If all goes well, I'll put all of that in "merge" and "next" and ask
Linus to pull it tomorrow.
Now, regarding the remaining bits, still on my todo for the next batch,
probably later this week, in this merge window:
- The CMO stuff, I need to have a closer look but it should
probably go in
- Milton's serie. Mostly fixes, haven't had time to look too
closely yet.
- Kumar PTE bits... that's a bit "hot" for this merge window
but I suppose it can still make it.
- Some Cell stuff for which I'm waiting a new serie from Arnd
If you believe I've missed something, now is time to be vocal about
it :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Fix pte_update for CONFIG_PTE_64BIT and !PTE_ATOMIC_UPDATES
From: Benjamin Herrenschmidt @ 2008-07-15 5:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0807140808090.9284@blarg.am.freescale.net>
On Mon, 2008-07-14 at 08:08 -0500, Kumar Gala wrote:
> 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>
Putting that one into my tree. I'll let you put the 2 others in yours.
Cheers,
Ben.
> ---
> 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
^ permalink raw reply
* Re: [PATCH] kill useless SMT code in prom_hold_cpus
From: Benjamin Herrenschmidt @ 2008-07-15 4:53 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080715022440.GU9594@localdomain>
On Mon, 2008-07-14 at 21:24 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Tue, 2008-07-08 at 17:36 -0500, Nathan Lynch wrote:
> > > I think this code that counts SMT threads and compares against NR_CPUS
> > > is an artifact of pre-powerpc-merge ppc64. We care about starting
> > > only primary threads in the OF client code.
> > >
> > > Signed-off-by: Nathan Lynch <ntl@pobox.com>
> >
> > That looks good. I'm not merging it right now because I want to dbl
> > check that it's allright on all SMT machines. IE. We compare reg[0]
> > against _prom->cpu now instead of interrupt_server[0] and I thus
> > want to ensure it's the same everywhere.
>
> Thanks. Looks like prom_find_boot_cpu is setting _prom->cpu to reg
> (or 0), so I think it should be fine... a system where reg differed
> from interrupt_server[0] would have been broken before this patch
> anyway, I think?
I tend to agree, just didn't have time to look closely / test before
I get to prepare my batch of patches for Linus, I'll stick it in the
next one.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] kill useless SMT code in prom_hold_cpus
From: Tony Breeds @ 2008-07-15 4:59 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20080715045551.GV9594@localdomain>
On Mon, Jul 14, 2008 at 11:55:51PM -0500, Nathan Lynch wrote:
> sysfs. (e.g. /sys/devices/system/cpu/cpu0/physical_id)
Hmm okay, sysfs is fine if you're gettign all the way up. I guess if we
have problems in that are we can readd the printf().
> The proper place for such a message is in the kernel's smp bringup
> code later on, and/or the code that initializes the various cpu maps.
> The prom_init code should not really be concerned with the kernel's
> NR_CPUS configuration or mapping of logical to physical ids.
Right, care to make this a series and add that ;P
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] kill useless SMT code in prom_hold_cpus
From: Nathan Lynch @ 2008-07-15 4:55 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080715022202.GD20457@bakeyournoodle.com>
Tony Breeds wrote:
> On Tue, Jul 08, 2008 at 05:36:31PM -0500, Nathan Lynch wrote:
>
> > - prom_printf("%x : starting cpu hw idx %x... ", cpuid, reg);
> > + prom_printf("starting cpu hw idx %x... ", reg);
>
> If we remove this, where else can we see the mapping of hardware IDs
> to logical cpu IDs? This is useful on POWER4 (at least where they can be
> different).
sysfs. (e.g. /sys/devices/system/cpu/cpu0/physical_id)
> > - if (cpuid > NR_CPUS)
> > - prom_printf("WARNING: maximum CPUs (" __stringify(NR_CPUS)
> > - ") exceeded: ignoring extras\n");
> > -
>
> I think this printf() is valuable, if your boot a 128 thread machine on
> a kernel with NR_CPUS=64, this is the only messaage you get to indicate
> that you're wasting 64 threads, and how to resolve it.
The proper place for such a message is in the kernel's smp bringup
code later on, and/or the code that initializes the various cpu maps.
The prom_init code should not really be concerned with the kernel's
NR_CPUS configuration or mapping of logical to physical ids.
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Stephen Rothwell @ 2008-07-15 3:10 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080714164114.GA18784@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
Hi Anton,
On Mon, 14 Jul 2008 20:41:14 +0400 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + int ret;
> + struct of_gpio_led *led;
> + struct device_node *np = ofdev->node;
> +
> + led = kzalloc(sizeof(*led), GFP_KERNEL);
> + if (!led)
> + return -ENOMEM;
> +
> + led->np = np;
You need to take a reference if you are keeping a pointer to a
device_node, so:
led->np = of_node_get(np);
> + led->cdev.name = of_get_property(np, "label", NULL);
> + if (!led->cdev.name)
> + led->cdev.name = ofdev->dev.bus_id;
Please use dev_name() in new code:
led->cdev.name = dev_name(&ofdev->dev);
> + led->cdev.brightness_set = gpio_led_set;
> +
> + ret = gpio_request(led->gpio, ofdev->dev.bus_id);
dev_name() again.
> +err_get_gpio:
of_node_put(led->np);
> + kfree(led);
> + return ret;
> +}
> +
> +static int __devexit of_gpio_leds_remove(struct of_device *ofdev)
> +{
> + struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
> +
> + led_classdev_unregister(&led->cdev);
> + cancel_work_sync(&led->work);
> + gpio_free(led->gpio);
> + of_node_put(led->np);
This was going to be unbalanced, but is now correct.
--
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: [PATCH] kill useless SMT code in prom_hold_cpus
From: Nathan Lynch @ 2008-07-15 2:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1216087555.7740.42.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2008-07-08 at 17:36 -0500, Nathan Lynch wrote:
> > I think this code that counts SMT threads and compares against NR_CPUS
> > is an artifact of pre-powerpc-merge ppc64. We care about starting
> > only primary threads in the OF client code.
> >
> > Signed-off-by: Nathan Lynch <ntl@pobox.com>
>
> That looks good. I'm not merging it right now because I want to dbl
> check that it's allright on all SMT machines. IE. We compare reg[0]
> against _prom->cpu now instead of interrupt_server[0] and I thus
> want to ensure it's the same everywhere.
Thanks. Looks like prom_find_boot_cpu is setting _prom->cpu to reg
(or 0), so I think it should be fine... a system where reg differed
from interrupt_server[0] would have been broken before this patch
anyway, I think?
^ 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