On Tue, Jan 28, 2020 at 02:12:56AM -0500, Qian Cai wrote:
> > On Jan 28, 2020, at 1:13 AM, Christophe Leroy
> > wrote:
> > ppc32 an indecent / legacy platform ? Are you kidying ?
> > Powerquicc II PRO for instance is fully supported by the
> > manufacturer and widely used in many small networki
.
Fixes: 812ad463e089 ("ASoC: fsl_sai: Add support for runtime pm")
Signed-off-by: Oleksandr Suvorov
Link:
https://lore.kernel.org/r/20200205160436.3813642-1-oleksandr.suvo...@toradex.com
Signed-off-by: Mark Brown
---
sound/soc/fsl/fsl_sai.c | 22 +-
1 file chan
On Wed, Sep 07, 2011 at 04:10:57PM +0800, Yong Zhang wrote:
> This flag is a NOOP and can be removed now.
>
> Signed-off-by: Yong Zhang
Acked-by: Mark Brown
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
On Tue, Jan 31, 2012 at 10:39:05AM -0600, Bill Gatliff wrote:
> I'm just saying that, sadly, in many ways gpiolib is still a
> work-in-progress. The userspace component has been somewhat
> controversial in general over the years, and definitely lacks several
> key features in addition to the one
On Wed, Feb 01, 2012 at 09:56:45AM -0600, Bill Gatliff wrote:
> On Wed, Feb 1, 2012 at 6:32 AM, Mark Brown wrote:
> > Just to expand on this a bit: lots of people would prefer not to have a
> > userspace component at all due to the same hardware safety concerns that
> > you
On Sun, Feb 05, 2012 at 04:13:48PM +, Russell King - ARM Linux wrote:
> It's not quite correct, because OMAP4 has issues in this area as well
> (which does select IRQ_DOMAIN but can be without OF.) The result is
> an oops from irq_domain_add() because domain->ops is NULL.
> The right solutio
On Fri, Jul 27, 2012 at 05:25:42PM +0200, Francois Romieu wrote:
> 2. It would probably make sense to Cc: netdev and serial. There may be
>some kernel client network integration from the start.
Plus audio, quite a few of the buses mentioned as examples of use cases
for the hardware are audio
On Wed, Aug 01, 2012 at 05:37:38AM -0700, Greg KH wrote:
> On Wed, Aug 01, 2012 at 12:13:19PM +, Singh Sandeep-B37400 wrote:
> > But running a complete voice stack itself is beyond the scope of Freescale.
> > So vendors integrate their solutions with FSL solution.
> And sorry, I was thinking
current architectures that HAVE_CLK but don't use the common clock
framework have selects of HAVE_CUSTOM_CLK added.
This allows drivers to use the generic API on platforms which have no need
for the clock API at platform level.
Signed-off-by: Mark Brown
---
This depends on having one o
On Wed, Aug 29, 2012 at 02:49:34PM -0700, Stephen Warren wrote:
> On 08/28/12 13:35, Mark Brown wrote:
> >@@ -674,6 +676,7 @@ config ARCH_TEGRA
> > select GENERIC_CLOCKEVENTS
> > select GENERIC_GPIO
> > select HAVE_CLK
> >+select HAVE_CUSTOM_CLK
On Tue, Sep 11, 2012 at 10:14:45PM -0400, Eric Millbrandt wrote:
> Add platform DAI information that is needed to successfully register the
> mpc5200 platform.
I'm really not clear what this patch is supposed to be doing. What are
the problems you are trying to fix and how does your patch fix the
On Tue, Sep 11, 2012 at 10:14:47PM -0400, Eric Millbrandt wrote:
> Add a generic mpc5200 driver that allows asoc cards to be defined in the
> device tree.
ASoC - you've misspelt this throughout.
This changelog should discuss the subset of devices supported by your
binding, it's only possible to d
On Tue, Sep 11, 2012 at 10:14:48PM -0400, Eric Millbrandt wrote:
> + analog@0 {
> + stream-name = "AC97 Analog";
> + codec-name = "wm9712-codec.0";
This name is fairly clearly an internal implementation detail of how
Linux does audio drivers, we
On Tue, Sep 11, 2012 at 10:14:49PM -0400, Eric Millbrandt wrote:
> MPC5200 ASoC setup can now be done in the device tree.
I only noticed DT bindings being added for pcm030, not for efika?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https:
On Tue, Sep 11, 2012 at 10:14:46PM -0400, Eric Millbrandt wrote:
> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared platform data
> with mpc5200_dma.
This looks good but depends on patch 1 so I can't apply it - if you can
rebase things so this is patch 1 I'll apply it.
_
On Wed, Sep 12, 2012 at 10:05:33AM -0400, Eric Millbrandt wrote:
Please fix your mailer to word wrap within paragraphs.
> On 2012-09-11 Mark Brown wrote:
> > I only noticed DT bindings being added for pcm030, not for efika?
> When I looked I didn't see the Efika (PPC 5200B
On Thu, Sep 13, 2012 at 05:43:14PM -0400, Eric Millbrandt wrote:
> +static int __devexit pcm030_fabric_remove(struct platform_device *op)
> +{
> + struct platform_device *pdev = platform_get_drvdata(op);
> +
> + platform_device_unregister(pdev);
> +
> + return 0;
> +}
This seems reall
On Thu, Sep 13, 2012 at 05:43:11PM -0400, Eric Millbrandt wrote:
> The mpc5200_psc_ac97 and mpc5200_psc_i2s modules rely on shared platform data
> with mpc5200_dma.
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://list
On Thu, Sep 13, 2012 at 05:43:12PM -0400, Eric Millbrandt wrote:
> Add missing dai_driver information to avoid these runtime errors
applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-de
On Thu, Sep 13, 2012 at 05:43:13PM -0400, Eric Millbrandt wrote:
> Remove unreferenced header files.
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Sep 19, 2012 at 10:35:45AM -0400, Eric Millbrandt wrote:
> That was an artifact of me splitting the changes to pcm030-audio-fabric.c
> into multiple patches. I changed the driver to a platform device in this
> patch and converted to snd_soc_register_card() in the next patch. I can
> merg
On Wed, Sep 19, 2012 at 10:51:25AM -0400, wrote:
> From: Eric Millbrandt
>
> mpc52xx socs need to define SND_POWERPC_SOC to build ASoC drivers.
>
> Signed-off-by: Eric Millbrandt
> ---
> Changes since v1:
> Patch was "powerpc/52xx: define FSL_SOC"
> Changed from defining FSL_SOC for PPC_MPC52x
On Wed, Sep 19, 2012 at 05:07:34PM -0400, Eric Millbrandt wrote:
> On 2012-09-19 Mark Brown wrote:
> > Patches 2 to 7 appear to have gone AWOL?
> No changes to 2 through 7, so I didn't repost the full series.
Then this isn't patch 1/7, it's just a patch. The fact th
On Thu, Sep 20, 2012 at 10:36:43AM -0400, Eric Millbrandt wrote:
> mpc52xx socs do not define FSL_SOC but need SND_POWERPC_SOC defined to build
> ASoC drivers.
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozl
On Thu, Sep 20, 2012 at 10:36:44AM -0400, Eric Millbrandt wrote:
> Convert pcm030-audio-fabric to use the new snd_soc_register_card api
> instead of the older method of registering a separate platform device.
> Create the dai_link to the mpc5200_psc_ac97 platform using the device tree.
> Convert th
On Thu, Sep 20, 2012 at 10:36:45AM -0400, Eric Millbrandt wrote:
> The mpc5200-psc-ac97 driver does not enumerate attached ac97 devices, so
> register the device here.
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://l
On Tue, Nov 20, 2012 at 07:21:36AM +0100, Takashi Iwai wrote:
> Yet another one for ASoC.
> Date: Mon, 19 Nov 2012 13:21:35 -0500
> From: Bill Pemberton
> To: gre...@linuxfoundation.org
> Cc: Jaroslav Kysela , Takashi Iwai , M R
> Swami Reddy , Vishwas A Deshpande
> , Peter Ujfalusi ,
> Jarkko
ter could be different. It turns out that they're not actually
> different, and so the check is not necessary. In addition, neither
> macro is defined for 64-bit e5500 kernels, so that causes a build
> break.
Acked-by: Mark Brown
signature.asc
Desc
On Mon, Apr 16, 2012 at 09:21:58AM +0200, Linus Walleij wrote:
> This looks good but I think we need to page the alpha, ia64, m68k, microblaze,
> openrisc etc subarch maintainers on this patch so they have their say.
That's why I CCed linux-arch, to get all the architecture maintainers
included.
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 http://patchwor
On Mon, Nov 22, 2010 at 10:54:03PM +0100, Jesper Juhl wrote:
>
> Eliminate duplicate #include from
> sound/soc/fsl/mpc5200_dma.c
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-
On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown
> wrote:
> > + bool
> > + default y if !IA64_HP_SIM
> Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the
> server configs), so thi
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
> On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown
> wrote:
> > Do you mean that these systems require CONFIG_PM be turned off, or just
> > that people tend not to turn it on? If the latter would you expect any
&g
On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:
> At least some of the powerpc defconfigs were added with CONFIG_PM
> disabled. I assume that was on purpose (though it may not have been).
I'd not be so sure - since it's a bool without an explicit default set
Kconfig will defaul
On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:
> On Mon, 7 Feb 2011, Mark Brown wrote:
> > I'd not be so sure - since it's a bool without an explicit default set
> > Kconfig will default to disabling it and if anything enabling it is the
> > opti
On Mon, Feb 07, 2011 at 05:17:59PM -0800, Ray Lee wrote:
> On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown
> > I'm rather hoping that they'll notice the mailing list thread or that
> > someone else who knows what's going on with them does
> Surely you're jokin
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
> dri
On Fri, Oct 30, 2009 at 12:36:44PM +0100, Wolfram Sang wrote:
> On Fri, Oct 30, 2009 at 10:54:14AM +0000, Mark Brown wrote:
> > > - require the id field (as _this_ is the unique identifier)
> > NULL id fields are supposed to be supported in the cannonical clkdev
> > AP
On Sat, Nov 07, 2009 at 01:34:31AM -0700, Grant Likely wrote:
> +/* Utility for retrieving psc_dma_stream structure from a substream */
> +inline struct psc_dma_stream *
> +to_psc_dma_stream(struct snd_pcm_substream *substream, struct psc_dma
> *psc_dma)
> +{
> + if (substream->pstr->stream =
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
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 actu
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
> > t
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl 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 notification that the l
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
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
On 11 Nov 2009, at 19:24, Grant Likely
wrote:
On Wed, Nov 11, 2009 at 11:37 AM, Mark Brown
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
make things worse since if it were used then you'd hav
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 bee
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
On Mon, Apr 06, 2009 at 04:06:22PM -0500, Timur Tabi wrote:
> Acked-by: Timur Tabi
> Mark and Takashi: this patch is a must-fix for 2.6.30
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxp
On Tue, Jan 19, 2010 at 01:42:31PM -0800, Joe Perches wrote:
> Maybe a standard #define WATCHDOG_NAME
> .identity = WATCHGOD_NAME
I don't really see that the indrection via the #define would buy us
anything?
___
Linuxppc-dev mailing list
Linuxppc-dev@
On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote:
> .node is being removed
>
> Signed-off-by: Grant Likely
Acked-by: Mark Brown
but please ensure that Liam and especially Timur also check this (both
CCed).
For enormous patch serieses like this it's really nice if
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
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 m
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 s
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 f
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. Suc
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
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
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 cu
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
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 sup
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
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
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
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 mpc8
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 s
On Thu, Jun 09, 2011 at 10:33:07PM +0200, Arnd Bergmann wrote:
> On Thursday 09 June 2011 22:18:28 Timur Tabi wrote:
> > Ok, I was really hoping to avoid doing this. Like I said, binary
> > compatibility
> > is important, and changing the type will break my existing apps. Are you
> > insisting
On Mon, Aug 01, 2011 at 04:48:54PM -0500, Timur Tabi wrote:
> The Data Collection Manager (DCM) is a feature of the FPGA on some Freescale
> PowerPC reference boards that can read temperature, current, and voltage
> settings from the sensors on those boards. This driver exposes the DCM via a
> sys
On Mon, Aug 01, 2011 at 11:58:00PM +, Tabi Timur-B04825 wrote:
> Mark Brown wrote:
> > On Mon, Aug 01, 2011 at 04:48:54PM -0500, Timur Tabi wrote:
> >> PowerPC reference boards that can read temperature, current, and voltage
> >> settings from the sensors on those b
On Tue, Aug 02, 2011 at 01:57:45AM +, Tabi Timur-B04825 wrote:
> Mark Brown wrote:
> > I'd expect that things like the _lowest, _highest and _average
> > attributes which a number of drivers have are what you're looking for.
> Yes, but then all I'm doing
On Tue, Aug 16, 2011 at 06:47:45PM -0400, Timur Tabi wrote:
> The PowerPC Freescale SSI driver is claiming the IRQ when the IRQ when
> the device is opened, which means that the /proc/interrupts entry for
> the SSI exists only during playback or capture. This also meant that
> the user won't know
On Mon, Aug 22, 2011 at 09:22:41AM -0500, Timur Tabi wrote:
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> Since we don't actually use np, we can decrement the reference count
> immediately.
Applied, thanks.
___
On Mon, Aug 22, 2011 at 09:22:41AM -0500, Timur Tabi wrote:
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> Since we don't actually use np, we can decrement the reference count
> immediately.
Applied, thanks.
___
On Sat, Aug 20, 2011 at 09:02:01AM +0200, Julia Lawall wrote:
> From: Julia Lawall
>
> The first change is to add an of_node_put, since codec_np has previously
> been allocated. The rest of the patch reorganizes the error handling code
> so the only code executed is that which is needed.
Applie
to the core with commit
> 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.
>
> Signe
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 li
On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
> In message 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 the driver itself does what needs to be done
> instead
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 (r
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 th
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 cod
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 requi
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
> unresp
On 26 Jun 2010, at 00:04, Grant Likely 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 mpc52
to cover the "GUTS"
> register set on 85xx chips.
>
> Signed-off-by: Timur Tabi
Acked-by: Mark Brown
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Jul 28, 2010 at 10:09:24PM -0700, Guenter Roeck wrote:
> Signed-off-by: Guenter Roeck
Acked-by: Mark Brown
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 tr
ff-by: Timur Tabi
Acked-by: Mark Brown
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sat, Sep 11, 2010 at 10:10:59PM -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches
> ---
> sound/ppc/snd_ps3.c |2 +-
> sound/soc/s3c24xx/s3c-dma.c |3 +--
> 2 files changed, 2 insertions(+), 3 deletions(-)
Acked
ata() should be used. These functions
> have been around since the beginning, so are backwards compatible with
> all older kernel versions.
> Cc: Takashi Iwai
Acked-by: Mark Brown
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozl
On Sat, May 23, 2009 at 07:13:01PM -0400, Jon Smirl wrote:
> Rename the functions in the mpc5200 DMA file from i2s based names to dma ones
> to reflect the file they are in.
I'm OK with both these refactoring patches if Grant is - Grant, if I
could get your ack I'd like to merge these as soon as
On Sat, May 23, 2009 at 07:12:55PM -0400, Jon Smirl wrote:
[Jon, could you please fix the word wrapping in your MUA, there's none
at all which makes it more difficult than it needs to be to respond to
your e-mail.]
> Mark is not enthused about soc-of-simple.c so rather than extend it
> for AC97 I
On Sat, May 23, 2009 at 07:12:57PM -0400, Jon Smirl wrote:
> Register the wm9712 DAIs on module load
> Signed-off-by: Jon Smirl
Why do you wish to do this - ASoC does not require or use DAI registration
for AC97 CODECs?
___
Linuxppc-dev mailing list
Li
On Sat, May 23, 2009 at 07:13:05PM -0400, Jon Smirl wrote:
This is all basically OK bearing in mind that I know nothing about the
hardware. A couple of things, though:
> +/* -
> + * Sysfs attributes for debugging
> + */
These l
On Sat, May 23, 2009 at 07:13:07PM -0400, Jon Smirl wrote:
> AC97 codec for STAC9766 used on the Efika.
> Datasheet: http://www.idt.com/products/getDoc.cfm?docID=13134007
>
> Signed-off-by: Jon Smirl
This looks mostly good, a couple of issues below. I'll apply the patch
but please submit a foll
On Sat, May 23, 2009 at 07:13:09PM -0400, Jon Smirl wrote:
> +#ifdef CONFIG_PM
> +static int psc_ac97_suspend(struct snd_soc_dai *dai)
> +{
> + return 0;
> +}
> +
> +static int psc_ac97_resume(struct snd_soc_dai *dai)
> +{
> + return 0;
> +}
> +
> +#else
> +#define psc_ac97_suspend NUL
On Sat, May 23, 2009 at 07:13:11PM -0400, Jon Smirl wrote:
> Fabric bindings for STAC9766 AC97 codec on the Efika.
>
> Signed-off-by: Jon Smirl
This is OK, but obviously depends on previous patches so I'll not apply
it just yet. You might want to run it (and many of your other patches)
through
On Sat, May 23, 2009 at 07:13:13PM -0400, Jon Smirl wrote:
> Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
>
> Signed-off-by: Jon Smirl
Same comments as for the previous driver - it's OK once the AC97 DAI
driver goes in.
__
On Sun, May 24, 2009 at 08:13:19AM -0600, Grant Likely wrote:
> On Sat, May 23, 2009 at 5:13 PM, Jon Smirl wrote:
> > Add a few more mpc5200 PSC defines. More bit fields defines for mpc5200 PSC
> > registers. This patch is going in via Grant's tree.
> > Signed-off-by: Jon Smirl
> Acked-by: Gra
On Sun, May 24, 2009 at 12:19:37PM -0600, Grant Likely wrote:
> Nothing else needs it in MPC5200 land and I haven't applied it to my
> tree yet. Go ahead and add it to the ASoC tree.
OK, applied this and the two refactoring patches - thanks!
___
Linuxp
On Sun, May 24, 2009 at 11:21:15AM -0400, Jon Smirl wrote:
> My AC97 driver is detecting the codec id and printing it before trying
> to access the codec driver. I can convert that to a load_module() call
> when the drivers are ready.
No, your AC97 driver shouldn't be doing any of this at all - i
301 - 400 of 1030 matches
Mail list logo
