Re: mpc512x/clock: fix clk_get logic

2009-10-30 Thread Mark Brown
On Fri, Oct 30, 2009 at 10:17:14AM +0100, Wolfram Sang wrote: The matching logic returns a clock even if only the dev-part matches. This is wrong as devices may utilize more than one clock, so the wrong clock may be returned due to dev being not unique (noticed while working on the CAN

Re: [alsa-devel] [PATCH 0/6] Fixups to MPC5200 ASoC drivers

2009-11-07 Thread Mark Brown
On Sat, Nov 07, 2009 at 01:33:40AM -0700, Grant Likely wrote: However, I was able to reproduce the noise problem when using aplay if I have DEBUG #defined at the top of the mpc5200_dma.c file with debug console logs being spit out the serial port. In that situation, the STOP trigger calls

Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()

2009-11-07 Thread Mark Brown
On Sat, Nov 07, 2009 at 01:34:55AM -0700, Grant Likely wrote: ALSA playback seems to be more reliable if the .pointer() hook reports a value slightly into the period, rather than right on the period boundary. This patch adds a fudge factor of 1/4 the period size to better estimate the actual

Re: [alsa-devel] [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer()

2009-11-07 Thread Mark Brown
On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote: On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown It occurs to me that in terms of dealing with what's going on here this probably is achieving exactly the same effect as Jon's code in that it tells ALSA that things are a bit ahead

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-07 Thread Mark Brown
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote: On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl jonsm...@gmail.com wrote: current period. My understanding of ALSA is that the application is supposed to make sure there is enough silence in the buffer to handle the lag between

Re: [PATCH] ASoC/mpc5200: remove duplicate identical IRQ handler

2009-11-10 Thread Mark Brown
On Mon, Nov 09, 2009 at 09:40:09AM -0700, Grant Likely wrote: The TX and RX irq handlers are identical. Merge them Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Mark Brown
On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: There are two solutions: 1) tell me where the end of the valid data is. That allows me to program the hardware to not enqueue the invalid data. 2) For batched hardware, pad an extra period with silence after the end of the stream.

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-11 Thread Mark Brown
On 11 Nov 2009, at 19:24, Grant Likely grant.lik...@secretlab.ca wrote: On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Nov 11, 2009 at 11:38:06AM -0500, Jon Smirl wrote: Providing a final valid data point to the driver would possibly even

Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense

2009-11-12 Thread Mark Brown
On Wed, Nov 11, 2009 at 06:13:25PM -0500, Jon Smirl wrote: I don't think it is that much more work for ALSA to provide an accessible field indicating the end of valid data. It's already tracking appl_ptr. Appl_ptr just needs to be translated into a physical DMA buffer address and we've been

Re: Calling wait_event_interruptible_timeout() in I2C wait functions

2009-02-05 Thread Mark Brown
On Wed, Feb 04, 2009 at 12:00:52PM -0800, Mike Ditto wrote: Timur Tabi wrote: However, it appears that this is not common behavior for I2C driver. In fact, only these six drivers ever call wait_event_interruptible_timeout(): i2c-cpm.c I don't know about the others, but in i2c-cpm.c the

Re: [alsa-devel] [PATCH] ASoC: fsl_dma: Pass the proper device for dma mapping routines

2009-04-06 Thread Mark Brown
On Mon, Apr 06, 2009 at 04:06:22PM -0500, Timur Tabi wrote: Acked-by: Timur Tabi ti...@freescale.com Mark and Takashi: this patch is a must-fix for 2.6.30 Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org

Re: [RFC] [PATCH] watchdog_info separation and constify

2010-01-19 Thread Mark Brown
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote: Maybe a standard #define WATCHDOG_NAME foo .identity = WATCHGOD_NAME I don't really see that the indrection via the #define would buy us anything? ___ Linuxppc-dev mailing list

Re: [PATCH 33/37] sound/soc: use .dev.of_node instead of .node in struct of_device

2010-03-11 Thread Mark Brown
On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote: .node is being removed Signed-off-by: Grant Likely grant.lik...@secretlab.ca Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com but please ensure that Liam and especially Timur also check this (both CCed). For enormous

Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 04:36:08PM +1000, Benjamin Herrenschmidt wrote: Gross. Loses the linkage to device-tree etc... which is useful for audio especially. You should at least make sure the device node follows for the target driver to be able to use it :-) I'd like you to sync with Grant

Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 08:09:15PM +1000, Benjamin Herrenschmidt wrote: I think the main deal is to decide who gets to be the master node which contains the various properties doing the linkage. My gut feeling is that it could be the main transport, ie, the i2s or ac97, but people with more

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 03:04:33PM -0500, Timur Tabi wrote: [Reflowed into 80 columns] At least, that's the way ASoC likes to operate. AsoC takes a fixed string plus a unique integer. I could technically create a unique string for each DMA device, and have the integer always be 0. This

Re: [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 02:27:42PM -0600, Grant Likely wrote: On Tue, Apr 27, 2010 at 4:09 AM, Benjamin Herrenschmidt I don't have bandwidth to contribute much in this discussion right now, at least not to lead it, so I'm happy to let others do so, but I'm happy to provide feedback from my

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 03:46:04PM -0500, Timur Tabi wrote: [Reflowed into 80 columns; please fix your mail client.] (I've omitted the DMA nodes and some irrelevant details) This is enough information for a simplistic driver registration that probably makes a lot of assumptions. Such as

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 04:03:27PM -0500, Timur Tabi wrote: [Reflowing the text into 80 columns again] Mark Brown wrote: It's entirely possible that if the board designer intended the verious SSIs to be used in concert they've done something like cross wire the clocks which creates

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-27 Thread Mark Brown
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote: However, as you and Mark rightly point out, it completely fails to represent complex sound devices with weird clocking and strange routes. Something like this is probably more appropriate: [...] codec1

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-28 Thread Mark Brown
On Tue, Apr 27, 2010 at 08:31:18PM -0600, Grant Likely wrote: On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown On the other hand from a pragmatic point of view it's just much less hassle to just only provide the mechanism for instantiating a machine with custom code and use that for everything

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-28 Thread Mark Brown
On Wed, Apr 28, 2010 at 02:10:11PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote: On the other hand from a pragmatic point of view it's just much less hassle to just only provide the mechanism for instantiating a machine with custom code and use

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-28 Thread Mark Brown
On Wed, Apr 28, 2010 at 02:25:29PM +1000, Benjamin Herrenschmidt wrote: I'd stay stick to the basics and move incrementally up until it stops making sense: - First, the basics: nodes for actual physical devices. i2c codecs on their i2c busses, DMA controllers, etc... This is already

Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers

2010-04-28 Thread Mark Brown
On Wed, Apr 28, 2010 at 08:19:00AM -0500, Timur Tabi wrote: On Tue, Apr 27, 2010 at 5:29 PM, Mark Brown You also want to be representing unused pins here. If they're unused, how do I represent them? Can you give me an example? You should arrange for something to call snd_soc_dapm_nc_pin

Re: [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers

2010-05-04 Thread Mark Brown
On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote: { .compatible = simple-bus, }, - { .compatible = gianfar, }, + /* So that the DMA channel nodes can be probed individually: */ + { .compatible = fsl,eloplus-dma, }, {} The removal of gianfar looks a bit

Re: [alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers

2010-05-04 Thread Mark Brown
On Tue, May 04, 2010 at 10:11:34AM -0500, Timur Tabi wrote: Also remove the gianfar compatible from mpc8610_ids[], since there is no gianfar (or any other networking device) on the 8610. Meh, sorry. Though this is a very good example of why you shouldn't randomly mix unrelated changes into

Re: [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers

2010-05-05 Thread Mark Brown
On Tue, May 04, 2010 at 12:20:13PM -0500, Kumar Gala wrote: On May 3, 2010, at 4:54 PM, Timur Tabi wrote: A future version of the MPC8610 HPCD's ASoC DMA driver will probe on individual DMA channel nodes, so the DMA controller nodes' compatible string must be listed in mpc8610_ids[]

Re: [alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers

2010-05-05 Thread Mark Brown
On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote: On Wed, May 5, 2010 at 6:22 AM, Mark Brown Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC

Re: [PATCH] drivers: remove all i2c_set_clientdata(client, NULL)

2010-05-31 Thread Mark Brown
e4a7b9b04de15f6b63da5ccdd373ffa3057a3681 to fix the faulty drivers. As there is no need anymore to clear the clientdata-pointer, remove all current occurrences in the drivers to simplify the code and prevent confusion. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Acked-by: Mark Brown broo

Loading drivers based on board identification

2008-06-17 Thread Mark Brown
Recently there's been quite a bit of discussion surrounding how to set up machine specific hardware that can't readily be represented in the device tree. I was wondering if one way of solving these problems might be to provide a mechanism for drivers to load based on board type rather than by

Re: Loading drivers based on board identification

2008-06-17 Thread Mark Brown
On Tue, Jun 17, 2008 at 02:31:03PM -0700, Stephen Neuendorffer wrote: I'm very interested in trying to factor out board data from the device tree, but for slightly different reasons, I think. (Although I don't exactly understand what you're proposing...) Sorry, I should have gone into a

Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-04 Thread Mark Brown
On Tue, Jul 01, 2008 at 05:53:40PM -0600, Grant Likely wrote: +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 =

Re: [alsa-devel] [PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver

2008-07-07 Thread Mark Brown
On Sun, Jul 06, 2008 at 01:56:48PM -0400, Jon Smirl wrote: The driver is assuming a capture stream exists. My codec is output only. While the driver declares a capture stream the core doesn't require that both capture and playback be available - it will cope with a capture only or a playback

Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-14 Thread Mark Brown
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

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
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

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
On Mon, Jul 14, 2008 at 10:13:14AM -0400, Jon Smirl wrote: On 7/14/08, Mark Brown [EMAIL PROTECTED] 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

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
On Mon, Jul 14, 2008 at 11:14:41AM -0500, Timur Tabi wrote: Mark Brown wrote: 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. Jon's

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
On Mon, Jul 14, 2008 at 11:06:34AM -0600, Grant Likely wrote: I'm okay with that. How about fsl/mpc5200-of-machine.c for now? (only the mpc5200 i2s driver uses it at the moment). It can always be renamed if other folks want to use it for other chips. That seems reasonable so long as you're

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
On Mon, Jul 14, 2008 at 11:21:12AM -0600, Grant Likely wrote: On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown Incidentally, nobody ever really commented on my suggestion to do something DMI-like I'm feeling stupid; what does DMI stand for? Desktop Management Interface, a standard BIOS

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-14 Thread Mark Brown
On Mon, Jul 14, 2008 at 01:40:24PM -0500, Timur Tabi wrote: Mark Brown wrote: Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard

Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-15 Thread Mark Brown
On Tue, Jul 15, 2008 at 06:08:19PM +0530, dinesh wrote: thanks for your response but there is no /dev/snd directory in my file structure is there any special method to create it please tell in detail. The devices appear via the standard kernel interfaces so if you are using udev or mdev they

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-15 Thread Mark Brown
On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote: On 7/15/08, Mark Brown [EMAIL PROTECTED] wrote: 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

Re: [alsa-devel] WRITING AN SOC DRIVER WITHOUT DMA

2008-07-17 Thread Mark Brown
On Thu, Jul 17, 2008 at 11:33:31AM +0530, dinesh wrote: What i want is that i have a buffer in driver code which is also handled by some other application i want that this buffer data is to be used for capture and playback stream fills data to another buffer which i can passover to my other

Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-18 Thread Mark Brown
On Thu, Jul 17, 2008 at 05:31:53PM -0600, Grant Likely wrote: On Sat, Jul 12, 2008 at 06:36:10PM +0100, Mark Brown wrote: /sys/bus/platform/devices/soc-audio/codec_reg Yikes. The AIC26 has registers all over the place and most of them are empty. The codec_reg attribute handling means I

Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-18 Thread Mark Brown
On Fri, Jul 18, 2008 at 01:17:20AM -0600, Grant Likely wrote: Okay, I've changed my mind. :-) I'll back off a bit from this extreme and call it: sound/soc/fsl/soc-of-simple.c Does that sound okay? If non-freescale chips decide to use it then it can be moved out of the freescale

Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-18 Thread Mark Brown
On Fri, Jul 18, 2008 at 12:29:37AM -0600, Grant Likely wrote: On Mon, Jul 14, 2008 at 12:45:55PM +0100, Mark Brown wrote: On Sat, Jul 12, 2008 at 02:39:39AM -0600, Grant Likely wrote: This configuration is also exposed via a sysfs file, including some of the configurability. Exposing

Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote: Here is the latest series for adding MPC5200 I2S and TI AIC26 codec support to ALSA SoC. I believe all the comments are addressed and I hope that this series is now ready to be merged. I would really like to see these ones land

Re: [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-22 Thread Mark Brown
functions integrated into the core registration functions. Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote: Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] There's a few issues that were raised on the previous review cycle that still need to be addressed but they should be fixable in incremental

Re: [PATCH v3 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 12:54:03AM -0600, Grant Likely wrote: Signed-off-by: Grant Likely [EMAIL PROTECTED] Signed-off-by: Mark Brown [EMAIL PROTECTED] with the same comments about outstanding issues as applied to the CPU side. +static int aic26_hw_params(struct snd_pcm_substream *substream

Re: [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 12:58:09AM -0600, Grant Likely wrote: Here is the latest series for adding MPC5200 I2S and TI AIC26 codec support to ALSA SoC. I believe all the comments are addressed and I hope that this series is now ready to be merged. I would really like to see these ones land

[PATCH 3/3] ASoC: Staticise keyclick dev_attr in tlv320aic26

2008-07-22 Thread Mark Brown
Signed-off-by: Mark Brown [EMAIL PROTECTED] --- sound/soc/codecs/tlv320aic26.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c index 73b7027..bed8a9e 100644 --- a/sound/soc/codecs/tlv320aic26.c +++ b/sound

[PATCH 2/3] ASoC: Export DAI and codec for TLV320AIC26

2008-07-22 Thread Mark Brown
This fixes sparse warnings and allows non-OpenFirmware systems to attempt to bind to the device. Signed-off-by: Mark Brown [EMAIL PROTECTED] --- sound/soc/codecs/tlv320aic26.c |1 + sound/soc/codecs/tlv320aic26.h |3 +++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git

[PATCH 1/3] ASoC: Make OpenFirmware helper include file conditional

2008-07-22 Thread Mark Brown
The OpenFirmware API headers don't build on all platforms so ensure that they are not included unless they are being used. Signed-off-by: Mark Brown [EMAIL PROTECTED] --- include/sound/soc-of-simple.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/sound/soc

Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 09:38:11AM -0400, Jon Smirl wrote: These drivers are going to get hit with immediate patches. The DMA is not broken out so that AC97 support can be fixed for the Efika. Further updates shouldn't present a problem - if anything, it should be easier easier to review

Re: [alsa-devel] [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 12:38:30PM -0400, Jon Smirl wrote: On 7/22/08, Grant Likely [EMAIL PROTECTED] wrote: +int of_snd_soc_register_platform(struct snd_soc_platform *platform, +struct device_node *node, +struct

Re: [alsa-devel] [PATCH v3 0/3] ALSA SoC: MPC5200 audio driver

2008-07-22 Thread Mark Brown
On Tue, Jul 22, 2008 at 10:52:20AM -0400, Jon Smirl wrote: I'm just going to ignore 2.6.27 and wait for 2.6.28. This driver only If you want to get changes in for 2.6.28 it's probably best to be working on them now - it's not clear if this driver will be merged for 2.6.27 at all and the sooner

Re: [alsa-devel] [PATCH 1/2] Support internal I2S clock sources on MPC5200

2008-07-23 Thread Mark Brown
On Tue, Jul 22, 2008 at 07:53:49PM -0400, Jon Smirl wrote: Support internal I2S clock sources on MPC5200 Looks good from an ASoC point of view. There's quite a few checkpatch warnings that should be fixed (all fairly straightforward, though) but other than that I'm happy to apply it with

Re: [alsa-devel] [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple

2008-07-23 Thread Mark Brown
On Tue, Jul 22, 2008 at 07:53:51PM -0400, Jon Smirl wrote: Allow a custom ASOC machine driver with soc-of-simple As with the clocking configuration: this looks fine from an ASoC point of view but please fix the checkpatch warnings. However... /* Only register the device if both the

Re: [alsa-devel] [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple

2008-07-23 Thread Mark Brown
On Wed, Jul 23, 2008 at 10:09:01AM -0400, Jon Smirl wrote: On 7/23/08, Mark Brown [EMAIL PROTECTED] wrote: ...this doesn't just allow a custom machine driver, it requires that something configures at least the machine name. That's not a problem from the ASoC point of view but possibly

Re: [alsa-devel] [PATCH 2/2] Allow a custom ASOC machine driver with soc-of-simple

2008-07-23 Thread Mark Brown
On Wed, Jul 23, 2008 at 11:16:17AM -0400, Jon Smirl wrote: On 7/23/08, Mark Brown [EMAIL PROTECTED] wrote: I'd also expect something to handle the existing user. This is a modification to Grant's new driver. Grant is the only other user. Right, hence my use of the singular : ) . Since you

Re: [i2c] [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver

2008-09-23 Thread Mark Brown
On Mon, Sep 22, 2008 at 11:45:40PM +0100, Ben Dooks wrote: I've also a driver for a similar PMU fitted to a number of our boards that provides basic gpio (wakeup sources) and some minimalist power management (so isn't really fit for regulator framwork) and isn't really a gpio chip (so

Re: [PATCH 2/2] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset.

2010-06-09 Thread Mark Brown
On Tue, Jun 08, 2010 at 12:46:02PM -0400, Eric Millbrandt wrote: + switch (psc_dma-id) { + case 0: + gpio_mux = MPC52xx_GPIO_PSC1_MASK; break; + case 1: + gpio_mux = MPC52xx_GPIO_PSC2_MASK; break; Please don't place the break on the same line as

Re: [PATCH 0/2] mpc5200 ac97 gpio reset

2010-06-09 Thread Mark Brown
On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote: In message aanlktimis90kr5uqhdbq02osd94dn08soitm51ylr...@mail.gmail.com you wrote: Would making a change in uboot be a better solution? Eric, can you verify if changing uboot also fixes the problem? To me it seems better if

Re: [PATCH 0/2] mpc5200 ac97 gpio reset

2010-06-09 Thread Mark Brown
On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote: [Please fix your MUA to word wrap paragraphs to within 80 characters, I've reflowed the text below.] From the MPC5200B user manual: Some AC97 devices goes to a test mode, if the Sync line is high during the Res line is low

Re: [PATCH 0/2] mpc5200 ac97 gpio reset

2010-06-09 Thread Mark Brown
On Wed, Jun 09, 2010 at 10:41:23AM -0400, Jon Smirl wrote: On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown Please include this quote in the changelog for the patch, if this a documented workaround from the vendor that's a very different thing to something that you've found happens to work

Re: [PATCH 0/2] mpc5200 ac97 gpio reset

2010-06-10 Thread Mark Brown
On 10 Jun 2010, at 23:07, Grant Likely wrote: To me, this seems firmly in the realm of silicon bug workaround. Considering that the pins aren't relocatable (ie, the GPIO numbers never change), I've got no problem having the GPIO reset logic added to arch/powerpc/platforms/52xx and hard coding

Re: Request review of device tree documentation

2010-06-14 Thread Mark Brown
On Mon, Jun 14, 2010 at 03:40:19PM -0400, Nicolas Pitre wrote: On Mon, 14 Jun 2010, Mitch Bradley wrote: Arranging for a JTAG dongle to appear at the customer site, then getting it set up and the necessary software installed and configured on a suitable host system, typically requires

Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset

2010-06-22 Thread Mark Brown
On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote: These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97 reset functionality in the psc. This avoids a problem in which attached ac97 devices go into test mode appear

Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset

2010-06-27 Thread Mark Brown
On 26 Jun 2010, at 00:04, Grant Likely grant.lik...@secretlab.ca wrote: On Tue, Jun 22, 2010 at 5:00 PM, Mark Brown On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote: These patches reimplement the reset fuction in the ac97 to use gpio pins instead of using the mpc5200 ac97

Re: [PATCH][v2] powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support

2010-07-22 Thread Mark Brown
on 85xx chips. Signed-off-by: Timur Tabi ti...@freescale.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/6] regulator: Remove owner field from attribute initialization in regulator core driver

2010-07-29 Thread Mark Brown
On Wed, Jul 28, 2010 at 10:09:24PM -0700, Guenter Roeck wrote: Signed-off-by: Guenter Roeck guenter.ro...@ericsson.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https

Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset

2010-08-02 Thread Mark Brown
On Sat, Jul 31, 2010 at 10:42:15PM -0600, Grant Likely wrote: On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown I'm a little concerned with a collision with multi codec here. It'd be handy if you could keep it separate in case it needs merging into both trees (or we could merge via ASoC only

Re: [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes

2010-08-05 Thread Mark Brown
...@freescale.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 11/11] sound: Remove pr_level uses of KERN_level

2010-09-13 Thread Mark Brown
On Sat, Sep 11, 2010 at 10:10:59PM -0700, Joe Perches wrote: Signed-off-by: Joe Perches j...@perches.com --- sound/ppc/snd_ps3.c |2 +- sound/soc/s3c24xx/s3c-dma.c |3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) Acked-by: Mark Brown broo

Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board

2010-10-14 Thread Mark Brown
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote: Mark, can you pick up this patch for us? Because it depends on powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support, it will break the build if we apply to powerpc-next. You can grab the patch from

Re: [PATCH] mfd/wm8350: don't export static functions

2008-10-16 Thread Mark Brown
(mfd: Core support for the WM8350 AudioPlus PMIC). wm8350_create_cache is not used elsewhere, so remove the EXPORT_SYMBOL. Acked-by: Mark Brown [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo

Re: powerpc allmodconfig

2008-10-16 Thread Mark Brown
On Wed, Oct 15, 2008 at 09:33:37PM -0700, Andrew Morton wrote: sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026) sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at

Re: MPC8610HPCD sound as module

2008-12-11 Thread Mark Brown
On Thu, Dec 11, 2008 at 09:40:55AM -0600, Timur Tabi wrote: Mark Brown wrote: ASoC v1 supports loading drivers as modules (and this is fairly heavily used), though as you say the MPC8610 drivers don't support that. Well, at the time I wrote the drivers, I didn't see an easy way to support

Re: MPC8610HPCD sound as module

2008-12-11 Thread Mark Brown
On Thu, Dec 11, 2008 at 09:12:54AM -0600, Timur Tabi wrote: On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik [EMAIL PROTECTED] wrote: As far as I can see from comments in the sources, it should work also as a module. Any hints how to achieve that? The ASoC V2 version of the driver supports

Re: MPC8610HPCD sound as module

2008-12-11 Thread Mark Brown
On Thu, Dec 11, 2008 at 09:45:26AM -0600, Timur Tabi wrote: And since I fixed the code in the V2 drivers, I have no interest in fixing it in the V1 drivers, which are officially in maintenance mode -- only critical bug fixes, no new features. Well, from that point of view now would be a

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-02 Thread Mark Brown
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote: Jon Smirl wrote: Does this need to be bus-frequency? It's always called MCLK in all of the literature. I'm trying to make this node as generic as possible. The fabric driver is the one that will parse this node and pass the

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-02 Thread Mark Brown
On Wed, Jan 02, 2008 at 09:28:12AM -0700, Grant Likely wrote: On 1/2/08, Timur Tabi [EMAIL PROTECTED] wrote: However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such device. The fabric driver is an abstraction. So I need to chose

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-03 Thread Mark Brown
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote: Mark Brown wrote: To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-03 Thread Mark Brown
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote: Grant Likely wrote: Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Software is, however, lousy at correctly wading through poorly-structured

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-04 Thread Mark Brown
On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote: On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote: I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-07 Thread Mark Brown
On Fri, Jan 04, 2008 at 08:43:17PM -0600, Timur Tabi wrote: Mark Brown wrote: In other words, ... clock1 = 0, bb8000 clock2 = 1, 653230 clock23 = 0, ab2372 Yes, something like that would cover it. I'm not sure what is idiomatic for the device tree. and of course the ordering matters

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-07 Thread Mark Brown
On Sun, Jan 06, 2008 at 11:46:37AM +1100, David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? That's what ASoC v2 is doing, more or less (the core brings things on line rather than

Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

2008-01-07 Thread Mark Brown
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? Not in ASoC V1. You have to understand, ASoC V1 was designed

Re: [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared

2013-07-11 Thread Mark Brown
On Wed, Jul 10, 2013 at 06:43:54PM +0800, Nicolin Chen wrote: The code enabled SSIEN when triggered by SNDRV_PCM_TRIGGER_START, so move the disable code to SNDRV_PCM_TRIGGER_STOP for symmetric. Applied, thanks. signature.asc Description: Digital signature

Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared

2013-07-12 Thread Mark Brown
On Thu, Jul 11, 2013 at 11:00:15PM -0500, Timur Tabi wrote: Nicolin Chen wrote: If I'm not missing some part of branch updating, it looks like Mark hasn't pushed it to the branch yet. Please test it for me. Thank you. I definitely want to. Unfortunately, I'm literally in the middle of

Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared

2013-07-12 Thread Mark Brown
On Fri, Jul 12, 2013 at 07:11:35AM -0500, Timur Tabi wrote: Mark Brown wrote: Yes, that's why I just went ahead - you'd said recently that you'd be out of action for a while and not able to test anything. Yeah, I'd rather you waited until I at least made sure it compiled. Is there any way

Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them

2013-07-15 Thread Mark Brown
On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote: clocks need to get prepared before they can get enabled, fix the MPC512x PSC SPI master's initialization Signed-off-by: Gerhard Sittig g...@denx.de --- drivers/spi/spi-mpc512x-psc.c |2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them

2013-07-17 Thread Mark Brown
On Wed, Jul 17, 2013 at 04:26:28PM +0200, Gerhard Sittig wrote: On Wed, Jul 17, 2013 at 13:07 +0100, Mark Brown wrote: This is a pretty long e-mail. It'd probably have taken less time to fix the issues than to reply to the e-mail... but anyway. Not quite. Please consider that careful

Re: [PATCH v1 05/24] clk: wrap I/O access for improved portability

2013-07-18 Thread Mark Brown
On Thu, Jul 18, 2013 at 10:06:57AM +0200, Sascha Hauer wrote: I think regmap has the potential to solve a number of issues like the hardcoded readl/writel in the common clock blocks, issues with i2c clocks and your endianess issue. The biggest question probably is how to get there without

Re: [PATCH v2 01/24] spi: mpc512x: cleanup clock API use

2013-07-18 Thread Mark Brown
On Thu, Jul 18, 2013 at 07:00:32PM +0200, Gerhard Sittig wrote: + psc_num = master-bus_num; + snprintf(clk_name, sizeof(clk_name), psc%d_mclk, psc_num); + mps-clk_mclk = clk_get(dev, clk_name); + if (IS_ERR(mps-clk_mclk)) + goto free_irq; Should be using

Re: [PATCH v3 01/31] spi: mpc512x: cleanup clock API use

2013-07-22 Thread Mark Brown
On Mon, Jul 22, 2013 at 02:14:28PM +0200, Gerhard Sittig wrote: + ret = clk_prepare_enable(clk); + if (ret) { + devm_clk_put(dev, clk); + goto free_irq; The main point of the devm_ APIs is to avoid the need for explicit freeing so you should just remove these

Re: [PATCH] ASoC: fsl: Set sdma peripheral type directly

2013-07-25 Thread Mark Brown
On Thu, Jul 25, 2013 at 05:41:41PM +0800, Nicolin Chen wrote: Let CPU DAI drivers set SDMA periperal type directly to support more dma types(SPDIF, ESAI) other than only two for SSI. This will easily allow some non-SSI drivers to use the imx-pcm-dma as well. Applied, thanks. signature.asc

Re: [PATCH 1/3] ASoC: codec: spdif: Add S20_3LE and S24_LE support for dummy codec drivers

2013-07-31 Thread Mark Brown
On Wed, Jul 31, 2013 at 08:07:05PM +0800, Nicolin Chen wrote: Generally, S/PDIF supports 20bit and optional 24bit samples. Thus add these two formats for the dummy codec drivers. Applied, thanks. Please check the mailing lists you're posting to - you've got the DT list wrong here and you

[PATCH] powerpc: Ignore zImage.epapr

2013-08-06 Thread Mark Brown
From: Mark Brown broo...@linaro.org This is another file we can generate so add it to the list. Signed-off-by: Mark Brown broo...@linaro.org --- arch/powerpc/boot/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore index

  1   2   3   4   5   6   7   >