Re: [PATCH v3] spi: fsl-spi: use devm_ioremap_resource() to map parameter ram on CPM1
On Wed, Apr 22, 2015 at 04:28:20PM +0200, Christophe Leroy wrote: > On CPM2, the SPI parameter RAM is dynamically allocated in the > dualport RAM whereas in CPM1, it is statically allocated to a default > address with capability to relocate it somewhere else via the use of > CPM micropatch. The address of the parameter RAM is given by the boot > loader and expected to be mapped via devm_ioremap_resource() Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: fsl-spi: fix devm_ioremap_resource() error case
On Thu, Apr 23, 2015 at 02:11:47PM +0200, Christophe Leroy wrote: > devm_ioremap_resource() doesn't return NULL but an ERR_PTR on error. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] ASoC: au1x: Constify platform_device_id
On Sat, May 02, 2015 at 01:00:11AM +0900, Krzysztof Kozlowski wrote: > The platform_device_id is not modified by the driver and core uses it as > const. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] ASoC: bt-sco: Constify platform_device_id
On Sat, May 02, 2015 at 01:00:12AM +0900, Krzysztof Kozlowski wrote: > The platform_device_id is not modified by the driver and core uses it as > const. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] ASoC: fsl: Constify platform_device_id
On Sat, May 02, 2015 at 01:00:13AM +0900, Krzysztof Kozlowski wrote: > The platform_device_id is not modified by the driver and core uses it as > const. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4] ASoC: samsung: Constify platform_device_id
On Sat, May 02, 2015 at 01:00:14AM +0900, Krzysztof Kozlowski wrote: > The platform_device_id is not modified by the driver and core uses it as > const. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] ASoC: fsl_sai: Add tdm slots operation for SAI master mode
On Mon, May 11, 2015 at 06:24:42PM +0800, Zidan Wang wrote:
> if (!sai->is_slave_mode) {
> + slot_width = sai->slot_width;
> ret = fsl_sai_set_bclk(cpu_dai, tx,
> - 2 * word_width * params_rate(params));
> + sai->slots * slot_width * params_rate(params));
> if (ret)
This seems to make TDM configuration mandatory which seems like a step
back - if it's been set up then of course we need to use it but if it's
not been configured we should be able to just infer something from
hw_params as we have been doing. Checking to see if the relevant values
have been set and falling back to using hw_params seems better.
Otherwise this looks good.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] ASoC: fsl_sai: add sai master mode support
On Mon, May 11, 2015 at 06:24:41PM +0800, Zidan Wang wrote: > When sai works on master mode, set its bit clock and frame clock. > > SAI has 4 MCLK source, bus clock, MCLK1, MCLK2 and MCLK3. fsl_sai_set_bclk > will select proper MCLK source, then calculate and set the bit clock divider. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] ASoC: fsl_sai: add 12kHz, 24kHz, 176.4kHz and 192kHz sample rate support
On Mon, May 11, 2015 at 06:24:43PM +0800, Zidan Wang wrote: > Normally we don't support 12kHz, 24kHz in audio driver, alsa didn't > have formal definition of 12kHz, 24kHz, but alsa supply a way to > support these sample rates. And add 176.4kHz and 192kHz support. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel][PATCH v2 1/3] ASoC: fsl_sai: add sai master mode support
On Wed, May 13, 2015 at 03:12:59PM +0800, Zidan Wang wrote: > When sai works on master mode, set its bit clock and frame clock. > > SAI has 4 MCLK source, bus clock, MCLK1, MCLK2 and MCLK3. fsl_sai_set_bclk > will select proper MCLK source, then calculate and set the bit clock divider. This looks like a patch I've already applied? If there are any changes needed please send incremental fixes. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_spdif: Don't try to round-up for clock divisor calculation
On Sun, May 24, 2015 at 01:12:41AM -0700, Nicolin Chen wrote:
> As commit 6c8ca30eec7b ("ASoC: fsl_ssi: Don't try to round-up for PM
> divisor calculation") mentioned that there's no more need to use a
> round up work around to get a better divisor since the clk-divider
> driver has been refined a lot.
Applied, thanks.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: fsl: Don't use devm_kzalloc in master->setup callback
On Sun, Aug 31, 2014 at 12:44:09PM +0800, Axel Lin wrote: > device_add() expects that any memory allocated via devm_* API is only > done in the device's probe function. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module
On Tue, Sep 09, 2014 at 05:18:07PM +0800, Shengjiu Wang wrote:
> + if (ssi_private->soc->imx)
> + clk_prepare_enable(ssi_private->clk);
> +
We're ignoring the error code here.
> - ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
> + ssi_private->clk = devm_clk_get(&pdev->dev, "ipg");
> if (IS_ERR(ssi_private->clk)) {
> ret = PTR_ERR(ssi_private->clk);
> - dev_err(&pdev->dev, "could not get clock: %d\n", ret);
> - return ret;
Why is this change being made? It wasn't mentioned in the commit log
and doesn't seem relevant to moving where the enable and disable are
done which is what the patch is supposed to be doing...
Please don't make different changes in the same patch.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module
On Tue, Sep 09, 2014 at 08:17:51AM -0500, Timur Tabi wrote: > Shengjiu Wang wrote: > >+if (ssi_private->soc->imx) > >+clk_prepare_enable(ssi_private->clk); > How about this instead? > if (ssi_private->clk) > clk_prepare_enable(ssi_private->clk); Should be a !IS_ERR() - NULL is a valid clock. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V1] ASoC: fsl_ssi: refine ipg clock usage in this module
On Tue, Sep 09, 2014 at 11:03:10AM -0700, Nicolin Chen wrote: > On Tue, Sep 09, 2014 at 12:27:50PM +0100, Mark Brown wrote: > > On Tue, Sep 09, 2014 at 05:18:07PM +0800, Shengjiu Wang wrote: > > > - ssi_private->clk = devm_clk_get(&pdev->dev, NULL); > > > + ssi_private->clk = devm_clk_get(&pdev->dev, "ipg"); > > Why is this change being made? It wasn't mentioned in the commit log > > and doesn't seem relevant to moving where the enable and disable are > > done which is what the patch is supposed to be doing... > I think Shengjiu is trying to keep the clock disabled while SSI's idle. > The current driver enables ipg clock anyway even if there's no stream > running. > Apparently, these should be put into the comment log. I got that bit. However as well as changing where the enable and disable take place this is also changing from requesting a clock with a NULL to requesting one called "ipg". signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_spdif: don't change the root clock rate of spdif in driver
On Tue, Sep 16, 2014 at 11:19:28AM -0700, Nicolin Chen wrote: > So I think, if it's a shared clock, we should not define it as a > rate-changeable one in the SoC level, as we might still have some > SoCs provide a dedicated clock to S/PDIF so as to get the maximum > range of clock support for users. > @Shawn > Sorry to involve you in this topic. I'm not so sure if we can do > this in the clock driver so that the clock rate would be fixed > even if the driver is trying to change it. If we can, I think we > may use a better solution here instead. I tend to agree here. My first thought here is that we should have support in the clock API for constraining clocks in the clock API so we can still set the clock where there's a possibility to do that. Not trivail to implement though. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4] ASoC: fsl_ssi: refine ipg clock usage in this module
On Tue, Sep 16, 2014 at 10:13:16AM +0800, Shengjiu Wang wrote: > Check if ipg clock is in clock-names property, then we can move the > ipg clock enable and disable operation to startup and shutdown, that > is only enable ipg clock when ssi is working and keep clock is disabled > when ssi is in idle. > But when the checking is failed, remain the clock control as before. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] spi: fsl-spi: Allow dynamic allocation of CPM1 parameter RAM
On Fri, Oct 03, 2014 at 02:56:09PM +0200, Christophe Leroy wrote: > +config CPM1_RELOCSPI > + bool "Dynamic SPI relocation" > + default n > + help > + On recent MPC8xx (at least MPC866 and MPC885) SPI can be relocated > + without micropatch. This activates relocation to a dynamically > + allocated area in the CPM Dual port RAM. > + When combined with SPI relocation patch (for older MPC8xx) it avoids > + the "loss" of additional Dual port RAM space just above the patch, > + which might be needed for example when using the CPM QMC. Something like this shouldn't be a compile time option. Either it should be unconditional or it should be triggered in some system specific manner (from DT, from knowing about other users or similar). signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_spdif: Remove unused includes of linux/clk-private.h
On Fri, Oct 03, 2014 at 05:54:13PM +0200, Tomeu Vizoso wrote: > Signed-off-by: Tomeu Vizoso Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl-asoc-card: Don't bypass settings if cpu-dai is Master
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote: > When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations, > set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if > the set_bias_level() has already taken care of the codec-dai side. > > So this patch just simply adds an additional condition. This was threaded with another patch series - did you intend to submit this or did it get sent by accident? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
On Fri, Oct 24, 2014 at 07:03:57PM -0700, Nicolin Chen wrote: > Kernel dump (WARN_ON) ocurred during system boot-up inside regmap_write(): > > [ cut here ] > WARNING: CPU: 0 PID: 47 at kernel/locking/lockdep.c:2744 > lockdep_trace_alloc+0xe8/0x108() Applied, thanks. Please edit down or elide backtraces - they take up a lot of space in the changelog compared to the amount of information they contain. > By looking at 2744 line, we can get that it's because regcache_rbtree_write() > would call kmalloc() with GFP flag if it couldn't find an existing block to > insert nodes while this kmalloc() call is inside a spin_lock_irq_save pair, > i.e. IRQs disabled. > Even though this may be a bug that should be fixed, I still try to send this > patch as a quick fix (work around) since it does no harm to assign default > values of every registers when using regcache. It's not a bug, it's not reasonable to default allocations to atomic and we can't really tell what context we're in. Anything used inside a heavily locked path should either have a default provided or arrange for a prior write to set up the cache. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_asrc: Add reg_defaults for regmap to fix kernel dump
On Mon, Oct 27, 2014 at 09:26:26PM -0700, Nicolin Chen wrote: > On Tue, Oct 28, 2014 at 12:19:04AM +0000, Mark Brown wrote: > > It's not a bug, it's not reasonable to default allocations to atomic and > > we can't really tell what context we're in. Anything used inside a > > heavily locked path should either have a default provided or arrange for > > a prior write to set up the cache. > I've a little trouble to understand the prior write over here. Inside my > probe() there's a register_init() call which has a set of regmap_write(). > And then the first regmap_write() results the dump. Does that mean this > regmap_write() isn't prior write? If so, how should I do if not setting Oh, bother. We fixed things so that we're now always running with the spinlock held... never mind. > default values here -- Some IPs may have default value 0 for registers. > And this would make reg_defaults tedious since there's nothing special > to assign. Write a small script then, or a little bit of code to create the defaults dynamically. > And actually I remember I haven't seen any dump when I sent the initial > patch for the whole ASRC driver but it manifested last month. I thought > it might be a partially-merging issue and it would be fixed after merge > window's done. Nothing has changed here for a while as far as I remember. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl-asoc-card: Don't bypass settings if cpu-dai is Master
On Fri, Oct 24, 2014 at 04:48:11PM -0700, Nicolin Chen wrote: > When cpu-dai is the DAI Master (CBM_CFx), it may need some configurations, > set_sysclk() call for eample, for cpu-dai side in the hw_params(), even if > the set_bias_level() has already taken care of the codec-dai side. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] ASoC: fsl: Use dynamic slot width for ESAI.
On Fri, Oct 24, 2014 at 04:48:10PM -0700, Nicolin Chen wrote: > @Shengjiu, > Will you be available to test this series on Sabre Auto for both > Master and Slave cases? I'd like to wait for your Test-by. Thanks. Any ETA on the testing? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: fsl-spi: Don't use cpm_command on CPM1
On Thu, Nov 20, 2014 at 05:24:17PM +0100, Christophe Leroy wrote: > On CPM1, when the SPI parameter RAM is relocated to somewhere else than the > default location, in accordance with freescale documentation > (refer micropatch SPI application note EB662), init RX/TX params command shall > not be used because it doesn't take into account the new location, and > overwrites data that is in original location of SPI param ram at addresses > SCC2 param base + (u32*)0x88 (u16*)0x90 (u32*)0x98 (u16*)0xA0, hence breaking > activity on SCC2 if SCC2 is used in a mode like QMC for instance. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] ASoC: fsl: Use dynamic slot width for ESAI.
On Fri, Oct 24, 2014 at 04:48:10PM -0700, Nicolin Chen wrote: > This series of patches add the support of dynamic slot width for > ESAI driver. To do this, the PATCH-1 removes the fixed width. In > order not to break those platforms that use fixed width, there > comes the PATCH-2 to apply an override of slot_width. Applied both, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On Mon, Dec 01, 2014 at 05:49:56PM +0100, Lars-Peter Clausen wrote: > On 12/01/2014 07:50 AM, Markus Pargmann wrote: > >devm_request_irq() is used by other drivers too, this should not be a > >problem. Looking at the code it seems that irq_dispose_mapping may not > >be necessary with devm_request_irq(). So I think it would be better to > >remove irq_dispose_mapping() instead. > The driver creates the mapping by calling irq_of_parse_and_map(), so it also > has to dispose the mapping. But the easy way out is to simply use > platform_get_irq() instead of irq_of_parse_map(). In this case the mapping > is not managed by the device but by the of core, so the device has not to > dispose the mapping. It also has the advantage of not being DT specific so providing some chance that future firmware interfaces can be supported without driver modification. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On Mon, Dec 01, 2014 at 08:39:51PM +0100, Lars-Peter Clausen wrote: > On 12/01/2014 07:48 PM, Timur Tabi wrote: > >A quick grep shows the following drivers that call both functions: > Most of these drivers will probably work fine without irq_of_parse_and_map(). I'd also note that quite a few of these drivers look pretty legacy - a very large proportion are for old PowerPC hardware, though by no means all. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: free irq before irq_dispose_mapping()
On Mon, Dec 01, 2014 at 09:01:43PM +0100, Arnd Bergmann wrote: > On Monday 01 December 2014 13:59:27 Timur Tabi wrote: > > On 12/01/2014 01:56 PM, Arnd Bergmann wrote: > > > All other drivers that call irq_of_parse_and_map and pass that into > > > devm_request_irq just never unmap, and their interrupts are already > > > mapped by the platform code, so I think it's not even a leak. > > Does this mean that fsl_ssi.c should not be calling > > irq_of_parse_and_map? How else should it get the IRQ? > platform_get_irq() Right, and just to emphasize what we were saying earlier the code was fine when originally written - both mapping inside platform_get_irq() and devm_ came along quite a while after the driver was originally written. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] ASoC: fsl_ssi: fix error path in probe
On Tue, Dec 02, 2014 at 02:55:06PM +0900, Jiada Wang wrote: > SSI component isn't unregistered if fsl_ssi_debugfs_create() fails > in probe phase. applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] ASoC: fsl_ssi: use platform_get_irq instead of irq_of_parse_and_map
On Tue, Dec 02, 2014 at 02:55:07PM +0900, Jiada Wang wrote: > Use platform_get_irq as no mapping needs to be done. > By using platform_get_irq, driver can avoid to free IRQ manually > when SSI driver exits. Fabio sent a version of this before yours so I applied his, I think the code is the same. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
On Mon, Dec 29, 2014 at 04:13:51PM -0800, Nicolin Chen wrote: > The xDC field should have 5 bit width according to Reference Manual. > Thus this patch fixes it. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_esai: Fix incorrect xDC field width of xCCR registers
On Mon, Dec 29, 2014 at 04:13:51PM -0800, Nicolin Chen wrote: > The xDC field should have 5 bit width according to Reference Manual. > Thus this patch fixes it. Applied, thanks - I also fixed the patch author up to be him. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
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 > moving into a new house, and so everything is packed up. I won't be > able to look at it for another week. 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. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC: fsl: Disable SSI in trigger() if RE/TE are both cleared
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 you can at least install the Freescale PowerPC SDK > and do compile tests? At least that way you won't have to wait for > me for every little thing. Several of the automated systems that cover -next do PowerPC test builds so I think it's getting covered already (Stephen Rothwell plus I think that Fengguang's system has some too). Now that I'm keeping everything in topic branches it's much easier for me to discard anything found in such testing. But yes, it's easy enough for me to install a PowerPC toolchain - in fact I was going to do that anyway as there's some SPI drivers that only build for PowerPC which I want to clean up. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
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 > --- > drivers/spi/spi-mpc512x-psc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-mpc512x-psc.c b/drivers/spi/spi-mpc512x-psc.c > index 29fce6a..76b20ea 100644 > --- a/drivers/spi/spi-mpc512x-psc.c > +++ b/drivers/spi/spi-mpc512x-psc.c > @@ -395,7 +395,7 @@ static int mpc512x_psc_spi_port_config(struct spi_master > *master, > > sprintf(name, "psc%d_mclk", master->bus_num); > spiclk = clk_get(&master->dev, name); > - clk_enable(spiclk); > + clk_prepare_enable(spiclk); > mps->mclk = clk_get_rate(spiclk); > clk_put(spiclk); This code is *clearly* buggy and should be fixed rather than papered over. Not only is there no matching put the driver is also dropping the reference to the clock rather than holding on to it while it's in use. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
On Wed, Jul 17, 2013 at 01:22:29PM +0200, Gerhard Sittig wrote: > On Mon, Jul 15, 2013 at 21:17 +0100, Mark Brown wrote: > > On Mon, Jul 15, 2013 at 08:47:30PM +0200, Gerhard Sittig wrote: > > > sprintf(name, "psc%d_mclk", master->bus_num); > > > spiclk = clk_get(&master->dev, name); > > > - clk_enable(spiclk); > > > + clk_prepare_enable(spiclk); > > > mps->mclk = clk_get_rate(spiclk); > > > clk_put(spiclk); > > This code is *clearly* buggy and should be fixed rather than papered > > over. Not only is there no matching put the driver is also dropping the > > reference to the clock rather than holding on to it while it's in use. > "This code" refers to the driver's original condition, right? I > agree that the driver has been suffering from incomplete clock > handling since it was born three years ago. And that this issue > shall get addressed. The question is just whether it needs to be > part of this series which has a different focus. 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. A big part of the issue with the state of the driver is that there's obvious clock API abuse going on that isn't corrected here - the main one is that the sprintf() for the clock name is a fairly clear warning sign, the driver should be using a fixed value there. This raises a warning flag for me about the quality of the common clock API implementation that's being sent and/or the potential for bugs to be noticed with the common clock framework. I'd not expect this code to actually work, and looking at the rest of the series I don't see how it does since I can't see what forces the name. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 01/24] spi: mpc512x: prepare clocks before enabling them
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 submission is as > expensive as thorough review is, and that a lot of work is done > before v1 gets submitted, which you may not always notice from > looking at a concentrated series that may no longer suggest how > much it took to get there (especially when prepared carefully). This is rather undermined the more time and effort gets spent pushing back against doing trival fixes, of course... besides, the issues here are all really simple to fix and test. It's not a major or risky rewrite of the driver or anything like that - most of this can be tested by just probing the driver. > As mentioned before I did not question the need to fix issues as > they get identified. I just asked whether reworking the serial OK, so send patches then. > The initial COMMON_CLK implementation in part 09/24 registers > clkdev items for compatibility during migration. The string > isn't greppable since it's constructed by the preprocessor in the > MCLK data setup, see the MCLK_SETUP_DATA_PSC() macro. Ugh, right - it didn't show up in searches due to being hidden by the macro. > Now let me see how I can improve the SPI driver with regard to > overall clock handling and beyond mere operation by coincidence > in the absence of errors. But please understand that I don't > want to stall the common clock support for a whole platform just > because some of the drivers it needs to touch to keep them > operational have other issues that weren't addressed yet, while > these issues aren't introduced with the series but preceed it. Again, you're not being asked to implement substantial new functionality here. From my point of view I can't test this at all so I'm looking at code that's obviously not good for the standard clock API and wondering if it even works or how robust it's going to be going forward as the common clock code changes which makes me relucatant to say it'll be OK. The fact that you're switching over to use generic code is itself a reason to make sure that the API usage is sane, dodgy API usage against open coded clock implementations is less risky than against the common code. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 05/24] clk: wrap I/O access for improved portability
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 putting too much of a burden on you. It's probably > not an option to convert all users to regmap, so it seems additional > functions like clk_register_gate_regmap are better to handle. That's basically what regulator does. There's versions of the ops that all the drivers can use. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/24] spi: mpc512x: cleanup clock API use
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 devm_clk_get(). signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 01/31] spi: mpc512x: cleanup clock API use
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 puts.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Set sdma peripheral type directly
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 Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] ASoC: codec: spdif: Add S20_3LE and S24_LE support for dummy codec drivers
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 shouldn't post non-binding reviews there anyway. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch] ASoC: fsl: add an error check
On Wed, Jun 10, 2015 at 06:37:23PM +0300, Dan Carpenter wrote: > My static checker complains that: > > sound/soc/fsl/imx-wm8962.c:196 imx_wm8962_probe() warn: > we tested 'ret' before and it was 'false' Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel][PATCH] ASoC: fsl: add imx-wm8960 machine driver
On Wed, Jun 10, 2015 at 04:26:27PM +0800, Zidan Wang wrote:
> + - hp-det : ADCLRC/GPIO1, LINPUT3/JD2 and RINPUT3/JD3 pins can
> + be selected as headphone jack detect inputs to
> + automatically disable the speaker output and enable
> + the headphone output.
> + hp-det = ;
> + hp-det-pin = 1: ADCLRC/GPIO1 used as detect pin
> + hp-det-pin = 2: LINPUT3/JD2 used as detect pin
> + hp-det-pin = 3: RINPUT3/JD3 used as detect pin
> + hp-det-polarity = 0: hp detect high for headphone
> + hp-det-polarity = 1: hp detect high for speaker
This looks like something that should be in the DT binding for the
CODEC, not the machine driver.
> +static int hp_set_status_check(void *data)
> +{
Why is this in the driver?
> + hp_status = gpio_get_value(priv->hp_set_gpio) ? 1 : 0;
gpio_get_value() already returns a boolean.
> + if (hp_status != priv->hp_active_low) {
> + snprintf(buf, 32, "STATE=%d", 2);
> + snd_soc_dapm_disable_pin(&priv->codec->dapm, "Ext Spk");
> + snd_soc_dapm_disable_pin(&priv->codec->dapm, "Main MIC");
> + ret = imx_hp_set_gpio.report;
The generic jack code already has support for disabling and enabling
pins, though disabling the speaker looks like a policy decision which
probably doesn't belong here.
> + /*
> + * As the hp MIC only connect the input for left channel, we
> + * need to route it for right channel.
> + */
> + snd_soc_update_bits(priv->codec, WM8960_ADDCTL1, 3<<2, 1<<2);
This looks like routing which we'd expect userspace to be doing.
> + snd_kctl_jack_report(priv->snd_card, priv->headset_kctl, 1);
Use the ASoC level helpers.
> + envp[0] = "NAME=headset";
> + envp[1] = buf;
> + envp[2] = NULL;
> + kobject_uevent_env(&pdev->dev.kobj, KOBJ_CHANGE, envp);
> + kfree(buf);
Let the core deal with notifying userspace - it looks like you want to
implement extcon integration there.
> + /* set cpu DAI configuration */
> + ret = snd_soc_dai_set_fmt(cpu_dai, fmt);
> + if (ret) {
> + dev_err(dev, "failed to set cpu dai fmt: %d\n", ret);
> + return ret;
> + }
> + /* set codec DAI configuration */
> + ret = snd_soc_dai_set_fmt(codec_dai, fmt);
> + if (ret) {
> + dev_err(dev, "failed to set codec dai fmt: %d\n", ret);
> + return ret;
> + }
Initialise these in the dai_link structure.
> + for (i = 0; i < ARRAY_SIZE(sysclk_divs); ++i) {
> + if (sysclk_divs[i] == -1)
> + continue;
> + sysclk /= sysclk_divs[i];
> + for (j = 0; j < ARRAY_SIZE(dac_divs); ++j) {
> + if (sysclk == sample_rate * dac_divs[j]) {
> + for (k = 0; k < ARRAY_SIZE(bclk_divs); ++k)
> + if (sysclk == bclk * bclk_divs[k] / 10)
> + break;
> + if (k != ARRAY_SIZE(bclk_divs))
> + break;
> + }
> + }
> + if (j != ARRAY_SIZE(dac_divs))
> + break;
> + }
> + if (i != ARRAY_SIZE(sysclk_divs)) {
> + /* Set codec sysclk */
> + snd_soc_dai_set_sysclk(codec_dai,
> +WM8960_SYSCLK_MCLK, sysclk, 0);
> + snd_soc_dai_set_clkdiv(codec_dai, WM8960_SYSCLKDIV, i << 1);
> + return 0;
> + }
Better, upgrade the CODEC driver to do this.
> + /* codec mclk should be enabled early to avoid jack detect error */
> + ret = clk_prepare_enable(data->codec_clk);
> + if (ret) {
> + dev_err(card->dev, "Failed to enable MCLK: %d\n", ret);
> + return ret;
> + }
Similarly integrating clock API support into the CODEC is better - it
makes all the DT stuff work a lot more smoothly and avoids things having
to get duplicated.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: mpc512x-psc: add support for Freescale MPC5125
On Tue, Jul 14, 2015 at 11:19:56AM +0200, Uwe Kleine-König wrote:
> static const struct of_device_id mpc512x_psc_spi_of_match[] = {
> - { .compatible = "fsl,mpc5121-psc-spi", },
> + { .compatible = "fsl,mpc5121-psc-spi", .data = (void *)TYPE_MPC5121 },
> + { .compatible = "fsl,mpc5125-psc-spi", .data = (void *)TYPE_MPC5125 },
> {},
The code seems fine but this should update the binding document to
include the new compatible string.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] spi: mpc512x-psc: add support for Freescale MPC5125
On Wed, Jul 15, 2015 at 09:40:19AM +0200, Uwe Kleine-König wrote:
> On Tue, Jul 14, 2015 at 10:54:42AM +0100, Mark Brown wrote:
> > > static const struct of_device_id mpc512x_psc_spi_of_match[] = {
> > > - { .compatible = "fsl,mpc5121-psc-spi", },
> > > + { .compatible = "fsl,mpc5121-psc-spi", .data = (void *)TYPE_MPC5121 },
> > > + { .compatible = "fsl,mpc5125-psc-spi", .data = (void *)TYPE_MPC5125 },
> > > {},
> > The code seems fine but this should update the binding document to
> > include the new compatible string.
> I don't find fsl,mpc5121-psc-spi documented either. The best I found is
> ocumentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt which
> describes fsl,mpc5121-psc-uart and fsl,mpc5121-psc.
OK, then please add a basic binding document. The point is that new
bindings should be being documented, if people have been lax on this in
the past that does involve a bit of cleanup.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v2] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Mon, Aug 03, 2015 at 12:44:11AM +0200, Maciej S. Szmigiero wrote: > Adjust set DAI format function in fsl_ssi driver > so it doesn't fail and clears RXDIR in AC'97 mode. > > Changes from v1: fix indentation to be consistent with rest > of the driver. Inter version changelogs go after the --- as covered in SubmittingPatches. > > Signed-off-by: Maciej Szmigiero Please don't bury new patches in reply to old submissions, especially not individual patches - it makes it hard to work out what's going on and make sure that the most current version of everything is being applied. In order to avoid confusion I'm not going to look at these, please resubmit as a new thread. Please also try to thread your patch series together (git send-email can do this for you) - it also helps people keep track of things. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6 v2] ASoC: fsl_ssi: adjust set DAI format in AC'97 mode
On Tue, Aug 04, 2015 at 12:42:48AM +0200, Maciej S. Szmigiero wrote: > In cases like this where only one patch of six patch series is updated > should other ones be resubmitted as well to keep the full patch series > together? Yes, any unapplied patches should be resubmitted. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Ignore zImage.epapr
From: Mark Brown This is another file we can generate so add it to the list. Signed-off-by: Mark Brown --- arch/powerpc/boot/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore index c32ae5c..554734f 100644 --- a/arch/powerpc/boot/.gitignore +++ b/arch/powerpc/boot/.gitignore @@ -22,6 +22,7 @@ zImage.initrd zImage.bin.* zImage.chrp zImage.coff +zImage.epapr zImage.holly zImage.*lds zImage.miboot -- 1.8.4.rc1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v4 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Tue, Aug 13, 2013 at 02:58:26PM -0300, Fabio Estevam wrote: > On Mon, Aug 12, 2013 at 9:01 AM, Nicolin Chen wrote: > > +Required properties: > > + - compatible : Compatible list, contains "fsl,-spdif". Using > > general > Can't we just use "fsl,fsl-spdif" instead? It's better to list the specific chips in the DT so that we can quirk if we need to later. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 11:01:43AM +0100, Mark Rutland wrote: > On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > > The phrase "user-visible" is being used in many current docs, I don't > > dare to change it unless a sage gives me a suggestion. > I can see that there is entrenched usage, but this really seems to be > embedding Linux-specific implementation details into the dt. I don't see > why the driver cannot select a sensible name, but perhaps I'm missing > something. > Mark, is there any reason we need to handle the user-visible name of the > device this way? This is intended to allow userspace to distinguish between systems that are electrically identical but physically distinct, for example when multiple systems are derived from the same reference design. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 12:31:21PM +0100, Mark Rutland wrote: > On Mon, Aug 19, 2013 at 11:52:01AM +0100, Mark Brown wrote: > > This is intended to allow userspace to distinguish between systems that > > are electrically identical but physically distinct, for example when > > multiple systems are derived from the same reference design. > I see. Surely if there's some meaning imparted to userspace by the model > name, there's a contract there that we should document (the set of valid > model names and what they correspond to)? In theory I guess. In practice I doubt many people will bother and I'd expect zero productive result from those that do. > I'm not sure I understand why userspace needs to know what the system is > if we've adequately described how it's wired and what its capabilities > are. However, I'm not at all familiar with the way we handle audio, so > please forgive my naivety there :) The physical form of the system can have a substantial impact on how people want to configure it at runtime even if there is no software visible difference. Coefficients can be chosen to work with plastics, or volumes adjusted for expected user positioning with respect to the hardware for example. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
On Mon, Aug 19, 2013 at 03:39:26PM -0600, Stephen Warren wrote: > On 08/19/2013 06:08 AM, Nicolin Chen wrote: > > This patch implements a device-tree-only machine driver for Freescale > > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > > fsl_spdif.c drivers. > > > diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > > b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt > > +Optional properties: > > + - spdif-transmitter : The phandle of the spdif-transmitter dummy codec > > + - spdif-receiver : The phandle of the spdif-receiver dummy codec > > +* Note: At least one of these two properties should be set in the DT > > binding. > Those object truly don't exist in HW and only exist due to internal > details of Linux's ASoC subsystem. They will physically exist if they're usefully present on the board (in the sense that they're there and can be pointed at) - there will be either a TOSLINK optical connector or (less commonly) an electrical connector breaking the signal out to go elsewhere though they don't have any interaction with software usually which is more what you mean here. > Or, to map the properties more directly to HW, perhaps name the property > "spdif-tx-jack-exists", or even "spdif-tx-jack" and make it a phandle to > a node that represents the actual S/PDIF connector? S/PDIF is also sometimes used as an interconnect between devices - some CODECs have S/PDIF I/O (more normally used as an external connector on the box). This is most frequently seen as a way to plumb HDMI in since some HDMI devices seem to provide this as a legacy interconnect, though it can get used just for regular CODECs as well. Using this machine driver would probably be a bit of an abuse for some applications, though with things like the HDMI one the goal of the hardware is to be dropped into a driver like this so perhaps it makes sense and is useful anyway. Equally well it'd be good to get this stuff actually merged, it seems to have been surprisingly time consuming thus far... signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
On Tue, Aug 20, 2013 at 09:48:46AM -0600, Stephen Warren wrote: > On 08/19/2013 06:18 PM, Mark Brown wrote: > > S/PDIF is also sometimes used as an interconnect between devices - > > some CODECs have S/PDIF I/O (more normally used as an external > > connector on the box). This is most frequently seen as a way to > That's not a good argument for an incorrect binding. The point is that it might turn into a more correct binding depending on what the S/PDIF device actually is. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Tue, Aug 20, 2013 at 10:16:28AM -0600, Stephen Warren wrote: > What changed between v8 and v9? There was a changelog in the cover mail for the series: | Changelog: | v8->v9: | * Use bool instead of atomic_t. | * Use clk_prepare_enable() instead. | * Dropped dumpregs(). | * Dropped unnecessary clk_round_rate(). | * Dropped unused clock source enum. | * Revised dev_err() message. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 2/2] ASoC: fsl: Add S/PDIF machine driver
On Tue, Aug 20, 2013 at 01:53:49PM -0600, Stephen Warren wrote: > On 08/20/2013 01:07 PM, Mark Brown wrote: > > The point is that it might turn into a more correct binding > > depending on what the S/PDIF device actually is. > There's *never* an object on the board called a "dummy codec". Oh, is that what you're talking about? Yes, that makes sense. I had been responding to the comments about the transceivers. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 01/31] spi: mpc512x: cleanup clock API use
On Wed, Aug 21, 2013 at 09:22:58PM +0200, Anatolij Gustschin wrote: > Mark, are you going to apply this patch? Or should I queue it > in my mpc5xxx tree (I'd like to get your Acked-by then)? Has this series settled down? I'd been ignoring it since it was getting so many and so frequent revisions. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Wed, Aug 21, 2013 at 11:13:16AM +0800, Nicolin Chen wrote: > This patch implements a device-tree-only CPU DAI driver for Freescale > S/PDIF controller that supports stereo playback and record feature. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 01/31] spi: mpc512x: cleanup clock API use
On Tue, Aug 06, 2013 at 10:43:41PM +0200, Gerhard Sittig wrote: > cleanup the MPC512x SoC's SPI master's use of the clock API > - get, prepare, and enable the MCLK during probe; disable, unprepare and > put the MCLK upon remove; hold a reference to the clock over the > period of use Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 2/2] ASoC: fsl: Add S/PDIF machine driver
On Thu, Aug 22, 2013 at 01:56:32PM -0600, Stephen Warren wrote: > On 08/22/2013 05:40 AM, Nicolin Chen wrote: > > Documentation/devicetree/bindings/sound/spdif-receiver.txt > > If I understand correctly, this doc for the dummy codec should be invalid? > Yes, I'm not convinced that binding is a good idea; it describes > something that often doesn't actually exist in HW. (Sometimes there's a > real S/PDIF receiving device on board, but sometimes there's nothing > except a jack/connector). > It'd be useful if other DT binding maintainers could weigh in on this to > confirm/deny my thoughts. I think the binding should be changed to replace the word "dummy" with "generic" and perhaps some verbiage about not requiring software configuration. I think given the unidirectional nature of S/PDIF it's reasonable to represent a jack like this - the hardware can't generally tell if there's anything at the other end of the link anyway, for all pratical purposes the transmit end just has to blindly send. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On Fri, Aug 23, 2013 at 01:08:28PM -0600, Stephen Warren wrote: > On 08/23/2013 02:04 AM, Nicolin Chen wrote: > > This patch implements a device-tree-only machine driver for Freescale > > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > > fsl_spdif.c drivers. > The binding looks reasonable to me now. Thanks. Is that a Reviewed-by? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v5 1/2] ASoC: fsl: Add S/PDIF CPU DAI driver
On Fri, Aug 23, 2013 at 02:41:44PM -0700, Mike Turquette wrote: > Seems like the regulator framework is solving this with the new > regulator_get_optional() call. This leaves the > optional-versus-not-optional logic up to the driver. That is possibly for a slightly different case but perhaps not... The problem we've got with the regulator API is that an awful lot of regulators are always on and people generally don't want to go and hook everything up, especially when drivers don't yet have regulator support. This means that we end up with lots of complaints about having to add regultors and lots of pain adding regulator support to widely used devices, or drivers that just ignore errors which is not awesome. We don't want to provide dummies since if the driver genuinely does have optional regulators they tend to break them so we're adding that call to allow the core to know if it can just provide a stub and assume the board data was lazy. My impression with clocks on most platforms is that there are fewer of this sort of always on clock, though that said I know there has been a bit of an issue with some of the IP clocks when IPs are used in SoCs from less power sensitive environments that don't bother implementing gating even in hardware. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v11] ASoC: fsl: Add S/PDIF machine driver
On Tue, Aug 27, 2013 at 10:01:08AM +0800, Nicolin Chen wrote: > On Fri, Aug 23, 2013 at 08:13:53PM +0100, Mark Brown wrote: > I think this patch hasn't been applied yet, already been acked though. > Is there any problem in it? You've allowed less than one working day for a response here - Monday was a holiday in the UK. Something like a week is normally a minimum for this sort of thing, especially in a case like this where there has been extensive discussion. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v12] ASoC: fsl: Add S/PDIF machine driver
On Wed, Aug 28, 2013 at 12:04:46PM +0800, Nicolin Chen wrote: > This patch implements a device-tree-only machine driver for Freescale > i.MX series Soc. It works with spdif_transmitter/spdif_receiver and > fsl_spdif.c drivers. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] ASoC: fsl_spdif: remove redundant dev_err call in fsl_spdif_probe()
On Thu, Aug 29, 2013 at 08:00:05AM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > There is a error message within devm_ioremap_resource > already, so remove the dev_err call to avoid redundant > error message. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ASoC: fsl: Add wrapping for dev_dbg() in fsl_spdif.c
On Fri, Aug 30, 2013 at 05:38:08PM +0800, Nicolin Chen wrote: > Add wrapping '\n' for dev_dbg() in fsl_spdif.c Applied both, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers
On Thu, Sep 19, 2013 at 10:53:02PM +0100, Russell King wrote: > This code sequence is unsafe in modules: > > static u64 mask = DMA_BIT_MASK(something); > ... > if (!dev->dma_mask) > dev->dma_mask = &mask; Acked-by: Mark Brown signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] sound/soc/fsl/fsl_ssi.c: let check zero instead of check NO_IRQ
On Mon, Sep 23, 2013 at 11:36:21AM +0800, Chen Gang wrote: > NO_IRQ may be defined as '(unsigned int) -1' in some architectures > (arm, sh ...), and either may not be defined in some architectures > which can enable SND_SOC_FSL_SSI (e.g. allmodconfig for arc). Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
On Wed, Oct 02, 2013 at 09:15:22PM -0700, Guenter Roeck wrote: > irq_of_parse_and_map() returns 0 on error, not NO_IRQ. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
On Wed, Oct 16, 2013 at 06:57:53PM -0700, Guenter Roeck wrote: > do you plan to send this patch upstream anytime soon ? It'll go next time I send stuff if it hasn't already. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Thu, Oct 17, 2013 at 03:51:54PM +0200, Lars-Peter Clausen wrote: > On 10/17/2013 03:37 PM, Timur Tabi wrote: > > I understand that, but I'm trying to figure out why of_iomap() is okay for > > hundreds of other drivers, but not this one. I've used it dozens of times > > myself, without ever worrying about overlapping regions. > The driver would work fine with just of_iomap(). But the resource range > check comes basically for free and it does help to catch errors, so I'd > recommend on using it rather than not using it. There's also the fact that it's a devm_ function which means less error handling code that we can break which is nice. There's probably a case for an improved OF helper here... signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 5/8] ASoC: sgtl5000: Revise the bugs about the sgt15000 codec.
On Thu, Oct 17, 2013 at 05:01:14PM +0800, Xiubo Li wrote:
> @@ -883,14 +883,19 @@ static int ldo_regulator_register(struct snd_soc_codec
> *codec,
> struct regulator_init_data *init_data,
> int voltage)
> {
> +#ifdef CONFIG_SND_SOC_FSL_SGTL5000
> + return 0;
> +#else
> dev_err(codec->dev, "this setup needs regulator support in the
> kernel\n");
> return -EINVAL;
> +#endif
> }
If these systems don't actually need the internal regulator then should
they not be trying to enable it? Alternatively if it's OK to ignore
this then why is this conditional in the board?
If this is something that it's safe to ignore then it should either be
ignored all the time or should be controlled by platform data not by a
compile time #define.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 8/8] Documentation: Add device tree bindings for Freescale VF610 sound.
On Thu, Oct 17, 2013 at 05:01:17PM +0800, Xiubo Li wrote: > + -- Power supplies: > + * Mic Bias > + > + -- SGTL5000 pins: > + * MIC_IN > + * LINE_IN > + * HP_OUT > + * LINE_OUT Things that are part of the CODEC should be part of the CODEC binding and this binding should reference that - this way the information doesn't have to be replicated by all boards using the CODEC and if new devices are supported by the CODEC driver then only that needs updating hopefully. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 6/8] ASoC: fsl: add SGT15000 based audio machine driver.
On Thu, Oct 17, 2013 at 05:01:15PM +0800, Xiubo Li wrote:
> + ret = snd_soc_register_card(&fsl_sgt1500_card);
> + if (ret) {
> + dev_err(&pdev->dev, "register soc sound card failed :%d\n",
> + ret);
> + return ret;
> + }
Use the newly added devm_snd_soc_register_card() (in -next).
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 8/8] Documentation: Add device tree bindings for Freescale VF610 sound.
On Mon, Oct 21, 2013 at 07:24:56AM +, Xiubo Li-B47053 wrote: > Yes, the "-- SGTL5000 pins:" should be in the CODEC binding. > But, actually the CODEC binding hasn't any reference about this. > So I added it here, but not very sure. Please add them to the CODEC binding instead. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Thu, Oct 17, 2013 at 05:01:10PM +0800, Xiubo Li wrote:
> +static struct snd_pcm_hardware snd_fsl_hardware = {
> + .info = SNDRV_PCM_INFO_INTERLEAVED |
> + SNDRV_PCM_INFO_BLOCK_TRANSFER |
> + SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_MMAP_VALID |
> + SNDRV_PCM_INFO_PAUSE |
> + SNDRV_PCM_INFO_RESUME,
> + .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .rate_min = 8000,
> + .channels_min = 2,
> + .channels_max = 2,
> + .buffer_bytes_max = FSL_SAI_DMABUF_SIZE,
> + .period_bytes_min = 4096,
> + .period_bytes_max = FSL_SAI_DMABUF_SIZE / TCD_NUMBER,
> + .periods_min = TCD_NUMBER,
> + .periods_max = TCD_NUMBER,
> + .fifo_size = 0,
> +};
There's a patch in -next that lets the generic dmaengine code figure out
some settings from the dmacontroller rather than requiring the driver to
explicitly provide configuration - it's "ASoC: dmaengine-pcm: Provide
default config". Please update your driver to use this, or let's work
out what it doesn't do any try to fix it.
> + ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
> + FSL_FMT_TRANSMITTER);
> + if (ret) {
> + dev_err(cpu_dai->dev,
> + "Cannot set sai's transmitter sysclk: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = fsl_sai_set_dai_sysclk_tr(cpu_dai, clk_id, freq,
> + FSL_FMT_RECEIVER);
As other people have commented these should be exposed as separate
clocks rather than set in sync, unless there's some hardware reason they
need to be identical. If that is the case then a comment explaining the
limitation would be good.
Similarly with several of the other functions.
> +int fsl_sai_dai_remove(struct snd_soc_dai *dai)
> +{
> + struct fsl_sai *sai = dev_get_drvdata(dai->dev);
> +
> + clk_disable_unprepare(sai->clk);
It'd be a bit nicer to only enable the clock while the driver is
actively being used rather than all the time the system is powered up
but it's not a blocker for merge.
> + ret = snd_soc_register_component(&pdev->dev, &fsl_component,
> + &fsl_sai_dai, 1);
> + if (ret)
> + return ret;
There's a devm_snd_soc_register_component() in -next, please use that.
> +
> + ret = fsl_pcm_dma_init(pdev);
> + if (ret)
> + goto out;
> +
> + platform_set_drvdata(pdev, sai);
These should go before the driver is registered with the subsystem
otherwise you've got a race where something might try to use the driver
before init is finished.
> +static int fsl_sai_remove(struct platform_device *pdev)
> +{
> + struct fsl_sai *sai = platform_get_drvdata(pdev);
> +
> + fsl_pcm_dma_exit(pdev);
> +
> + snd_soc_unregister_component(&pdev->dev);
Similarly here, unregister from the subsystem then clean up after.
> +#define SAI_CR5_FBT(x) ((x) << 8)
> +#define SAI_CR5_FBT_MASK (0x1f << 8)
> +
> +/* SAI audio dividers */
> +#define FSL_SAI_TX_DIV 0
> +#define FSL_SAI_RX_DIV 1
Make the namespacing consistent please - for preference use FSL_SAI
always.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_spdif: fix return value check in fsl_spdif_probe()
On Fri, Oct 25, 2013 at 05:29:25PM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, the function platform_get_resource() returns NULL > pointer not ERR_PTR(). The IS_ERR() test in the return value check > should be replaced with NULL test. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/4] ASoC: fsl_ssi: Add dual fifo mode support
On Thu, Oct 31, 2013 at 09:44:15PM +0800, Nicolin Chen wrote: > By enabling dual fifo mode, it would allow SSI enter a better performance > to transimit/receive data without occasional hardware underrun/overrun. > > [ Passed compile-test with mpc85xx_defconfig ] Acked-by: Mark Brown signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Fri, Nov 01, 2013 at 03:04:48PM +0800, Xiubo Li wrote:
> +static int fsl_sai_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
> + int div_id, int div)
> +{
> + struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> + u32 tcr2, rcr2;
> +
> + if (div_id == FSL_SAI_TX_DIV) {
> + tcr2 = readl(sai->base + FSL_SAI_TCR2);
> + tcr2 &= ~FSL_SAI_CR2_DIV_MASK;
> + tcr2 |= FSL_SAI_CR2_DIV(div);
> + writel(tcr2, sai->base + FSL_SAI_TCR2);
What is this divider and why does the user have to set it manually?
> + } else
> + return -EINVAL;
> +
Coding style?
> +static int fsl_sai_dai_probe(struct snd_soc_dai *dai)
> +{
> + int ret;
> + struct fsl_sai *sai = dev_get_drvdata(dai->dev);
> +
> + ret = clk_prepare_enable(sai->clk);
> + if (ret)
> + return ret;
It'd be nicer to only enable the clock while the device is in active
use.
> + ret = snd_dmaengine_pcm_register(&pdev->dev, NULL,
> + SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
> + if (ret)
> + return ret;
We should have a devm_ version of this.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
On Fri, Nov 01, 2013 at 03:04:53PM +0800, Xiubo Li wrote:
> Conflicts:
> sound/soc/fsl/Makefile
Ahem.
> + /* TODO: The SAI driver should figure this out for us */
> + switch (channels) {
> + case 2:
> + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffc, 0xfffc, 2, 0);
> + break;
> + case 1:
> + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffe, 0xfffe, 1, 0);
> + break;
> + default:
> + return -EINVAL;
> + }
Yes, it should - this code should probably just be copied straight into
the SAI driver. If we need to support other configurations we can do
that later.
> +static int fsl_sgtl5000_remove(struct platform_device *pdev)
> +{
> + snd_soc_unregister_card(&fsl_sgt1500_card);
> +
> + return 0;
> +}
You're using snd_soc_unregister_card() so you don't need to do this.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.
On Fri, Nov 01, 2013 at 03:04:52PM +0800, Xiubo Li wrote: > On VF610 series there are no regulators used, and now whether the > CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio > patch series, the board cannot be probe successfully. > And this patch will solve this issue. I don't understand what this is for at all, you're just saying there is a problem you're trying to solve but you don't explain anything about what the problem is or how your changes address it. > +#ifndef CONFIG_SND_SOC_FSL_SGTL5000_VF610 > static int ldo_regulator_register(struct snd_soc_codec *codec, This is definitely broken, it won't work with multi-platform kernels, and I don't understand what this is supposed to do - what is the reason for making this change? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Mon, Nov 04, 2013 at 07:35:12AM +, Li Xiubo wrote:
> From the ASoC subsystem comments we can see that:
> ++
> Configures the clock dividers. This is used to derive the best DAI bit and
> frame clocks from the system or master clock. It's best to set the DAI bit
> and frame clocks as low as possible to save system power.
> --
You should never use this unless you have to, there is no point in every
single machine driver using your driver having to duplicate the same
calculations.
>
> > > +static int fsl_sai_dai_probe(struct snd_soc_dai *dai) {
> > > + int ret;
> > > + struct fsl_sai *sai = dev_get_drvdata(dai->dev);
> > > +
> > > + ret = clk_prepare_enable(sai->clk);
> > > + if (ret)
> > > + return ret;
> > It'd be nicer to only enable the clock while the device is in active use.
> While if the module clock is not enabled here, the followed registers cannot
> read/write in the same function.
> And this _probe function is the _dai_probe not the driver's module _probe.
So you can enable the clock when you explicitly need to write to the
registers...
> If the clk_prepare_enable(sai->clk) is not here, where should it be will be
> nicer ?
> One of the following functions ?
> .set_sysclk = fsl_sai_set_dai_sysclk,
> .set_clkdiv = fsl_sai_set_dai_clkdiv,
> .set_fmt= fsl_sai_set_dai_fmt,
> .set_tdm_slot = fsl_sai_set_dai_tdm_slot,
> .hw_params = fsl_sai_hw_params,
> .trigger= fsl_sai_trigger,
It could be in any or all of them except trigger (where the core should
hold a runtime PM reference anyway). You can always take a reference
for the duration of the function if you're concerned it may be called
when the referent isn't otherwise held.
> > > + ret = snd_dmaengine_pcm_register(&pdev->dev, NULL,
> > > + SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
> > > + if (ret)
> > > + return ret;
> > We should have a devm_ version of this.
> Sorry, is there one patch for adding the devm_ version of
> snd_dmaengine_pcm_register() already ?
> In the -next and other topics branches I could not find it.
No, there isn't one but there should be one.
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Tue, Nov 05, 2013 at 03:21:49AM +, Li Xiubo wrote: > As your opinions, should I move the four register writing operations to > .set_sysclk/set_clkdiv/... functions too ? > Or just add a clk_disable_unprepare() after them here, and then add > clk_prepare_enable in one of .set_sysclk/set_clkdiv/...? The latter. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.
On Wed, Nov 06, 2013 at 08:59:53AM +, Li Xiubo wrote: Please fix your mailer to word wrap within paragraphs. > The SGTL5000 is based on regulators and when it is disabled, there > will be an error returns directly while the SGTL5000 codec is probing. What makes you say this? That's not how the regulator API works. Have you actually seen any problems? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.
On Thu, Nov 07, 2013 at 03:01:02AM +, Li Xiubo wrote: > > > The SGTL5000 is based on regulators and when it is disabled, there > > > will be an error returns directly while the SGTL5000 codec is probing. > > What makes you say this? > static int ldo_regulator_register(struct snd_soc_codec *codec, > struct regulator_init_data *init_data, > int voltage) If the regulator is not used in the system then why is the driver getting as far as trying to register it? Surely this is a system configuration error? This all sounds like some problem with either the system integration or the driver which is causing it to try to register the regulator needlessly - you should be fixing that problem, not adding ifdefs. I'm still unclear on exactly what the issue is so it's hard to say exactly what the best way forwards is. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 0/4] Add dual-fifo mode support of i.MX ssi
On Fri, Nov 08, 2013 at 07:29:20PM +0800, Nicolin Chen wrote: > Sorry all, I mistook the version number. It should be version 5. > Please ignore this series version. There is no need to resend for things like getting the version number wrong in the subject line, that's just noise. Please only resend things if there's a change in the actual patches. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 3/4] ASoC: fsl_ssi: Add dual fifo mode support
On Fri, Nov 08, 2013 at 07:32:53PM +0800, Nicolin Chen wrote: > By enabling dual fifo mode, it would allow SSI enter a better performance > to transimit/receive data without occasional hardware underrun/overrun. Acked-by: Mark Brown signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl: Fix build problem
On Wed, Jun 11, 2014 at 12:13:52AM -0700, Guenter Roeck wrote: > Commit 432481220 (ASoC: fsl-ssi: Use regmap) removed struct ccsr_ssi. > Unfortunately, the structure is still used. This causes > mpc85xx_smp_defconfig and mpc85xx_defconfig builds to fail with Applied, thanks,. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] spi: deal with a compile warning
On Thu, Jun 26, 2014 at 11:26:43AM +0800, Zhao Qiang wrote: > ret is unused when CONFIG_FSL_SOC defined, > so return ret instead of -ENOMEM when the > kzalloc fails to avoid it. Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: spi, spi_fsl-spi.c not working?
On Thu, Jul 17, 2014 at 11:11:45AM +0200, Heiko Schocher wrote: > Is it maybe the missing "support for the SPI subsystem's queue SPI messages"? It shouldn't be that, that's still optional (sadly). signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/6] ASoC: mxs-saif: fix mixed use of public and provider clk API
On Thu, Jul 17, 2014 at 04:13:15PM +0200, Tomeu Vizoso wrote: > In preparation to changing the clk provider API to use struct clk_core instead > of struct clk. Acked-by: Mark Brown signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ASoC: fsl_sai: Reset FIFOs after disabling TE/RE
On Wed, Jul 23, 2014 at 05:52:32PM +0800, Nicolin Chen wrote: > I found this two patches are merged into for-next branch, although I haven't > got the 'applied' email. > Is that possible for you to drop this one? If not, I'll send another patch > to fix this. Please send a patch, I'd already applied it by the time you asked me to drop it. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] ASoC: fsl_sai: Fix some issues in fsl_sai_trigger()
On Wed, Jul 23, 2014 at 07:23:37PM +0800, Nicolin Chen wrote: > The series of patches focus on issue fix inside fsl_sai_trigger(). Applied all, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 0/2] Add Freescale ASRC driver
On Tue, Jul 29, 2014 at 06:08:51PM +0800, Nicolin Chen wrote: > This series of patches add Freescale ASRC module driver support along > with the extra request in imx-sdma structure required by SDMA Device > to Device script. Applied both, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ASoC: fsl_asrc: Fix sparse warnings in FSL_ASRC_FORMATS due to typo
On Thu, Jul 31, 2014 at 12:07:40PM +0800, Nicolin Chen wrote: > reproduce: make C=1 CF=-D__CHECK_ENDIAN__ > > sparse warnings: (new ones prefixed by >>) Applied, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch -next] ASoC: fsl_asrc: fix an error code in fsl_asrc_probe()
On Thu, Jul 31, 2014 at 12:32:09PM +0300, Dan Carpenter wrote: > There is a cut and paste bug so it returns success instead of the error > code. Applied, thanks. Might be worth looking at how you're generating your CC lists here, it seems a bit random. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] ASoC: fsl: Add stream names to CPU DAI drivers for DPCM
On Wed, Jul 30, 2014 at 11:10:25AM +0800, Nicolin Chen wrote: > DPCM needs extra dapm routes in the machine driver to route audio > between Front-End and Back-End. In order to differ the stream names > in the route map from CODECs, we here add specific stream names to > all Freescale ASoC CPU DAI drivers so that we can implement ASRC via > DPCM to each of them. Applied all, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] ASoC: fsl_asrc: Fix two dereferenced variable before check
On Mon, Aug 04, 2014 at 12:19:47PM +0800, Nicolin Chen wrote: > These two patches fixes two warning of dereferenced variable reported by > Dan Carpenter Applied both, thanks. signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
