Re: [PATCH] ASoC: davinci: vcif must be a module if SND_DAVINCI_SOC is
On Mon, Sep 29, 2014 at 05:32:17PM +0200, Arnd Bergmann wrote: It is possible to configure a kernel with SND_DAVINCI_SOC=m and SND_DM365_VOICE_CODEC=y, which results in a link error: Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND PATCH v3] spi: davinci: add support for adding delay between word's transmissions
On Tue, Sep 16, 2014 at 02:25:05PM +0300, Grygorii Strashko wrote: From: Murali Karicheri m-kariche...@ti.com This patch adds ability to configure delay between transmission of words over SPI bus if it's required by SPI slave devices. Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] spi: davinci: remove empty function davinci_spi_cleanup
On Tue, Sep 16, 2014 at 02:14:23PM +0300, Grygorii Strashko wrote: Remove empty function davinci_spi_cleanup(). Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] spi: davinci: request cs_gpio's from probe
On Mon, Sep 15, 2014 at 04:06:42PM +0300, Grygorii Strashko wrote: The function davinci_spi_cleanup() will be reused by following patch [PATCH v3] spi: davinci: add support for adding delay between word's transmissions http://www.spinics.net/lists/devicetree/msg49141.html So, in broonie/spi.git/for-next it will not be empty. Again, I've missed description of this dependency, sorry for that. Don't do things like this, delete the function and then re-add it - it makes the review simpler and it means that if the second patch doesn't get applied (as will happen here for v3.17) then the code still looks good. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3] spi: davinci: add support for adding delay between word's transmissions
On Fri, Sep 12, 2014 at 06:48:12PM +0300, Grygorii Strashko wrote: From: Murali Karicheri m-kariche...@ti.com This patch adds ability to configure delay between transmission of words over SPI bus if it's required by SPI slave devices. This is fine but it doesn't appear to apply against current code. Can you please check and resend? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] spi: davinci: request cs_gpio's from probe
On Fri, Sep 12, 2014 at 05:54:00PM +0300, Grygorii Strashko wrote:
static void davinci_spi_cleanup(struct spi_device *spi)
{
- if (spi-cs_gpio = 0)
- gpio_free(spi-cs_gpio);
}
This function is now empty so should be removed. I've applied for now
but please send a followup fixing this.
signature.asc
Description: Digital signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] spi: davinci: add support for adding delay between word's transmission
On Tue, Sep 09, 2014 at 07:07:31PM +0300, Grygorii Strashko wrote: - ti,spi-c2t-delay: Chip-select-active-to-transmit-start delay (SPIDELAY.C2TDELAY) - ti,spi-t2c-delay: Transmit-end-to-chip-select-inactive delay (SPIDELAY.T2CDELAY) Now I look at these they look very much like the standard delay feature that the SPI subsystem has already - are they? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] spi: davinci: add support for adding delay between word's transmission
On Tue, Sep 09, 2014 at 01:09:27PM -0400, Murali Karicheri wrote: On 09/09/2014 12:55 PM, Mark Brown wrote: On Tue, Sep 09, 2014 at 07:07:31PM +0300, Grygorii Strashko wrote: - ti,spi-c2t-delay: Chip-select-active-to-transmit-start delay (SPIDELAY.C2TDELAY) - ti,spi-t2c-delay: Transmit-end-to-chip-select-inactive delay (SPIDELAY.T2CDELAY) Now I look at these they look very much like the standard delay feature that the SPI subsystem has already - are they? As Grygorii explained in previous postings (reproduced below), these delays are handled by the SPI hardware on Keystone and affect the delay between successive word tranmssion and has nothing to do with the delay you are talking about. Isn't the standard delay you mention here is between successive packets send down to the lower level driver (in this case spi-davinci.c) ? He talked about such delays between words (and there were some other delays listed which seemed to meet that description) but the above don't appear to refer to them, the above refer to delays around chip select which most definitely are covered with the standard delays. If these delays are not related to chip select then the documentation needs to be fixed to not refer to chip select. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] spi: davinci: add support for adding delay between word's transmission
On Tue, Sep 09, 2014 at 02:20:27PM -0400, Murali Karicheri wrote: On 09/09/2014 01:20 PM, Mark Brown wrote: If these delays are not related to chip select then the documentation needs to be fixed to not refer to chip select. Ok. So what I understand is the issue is not having the right description to indicate that these parameters are delays associated with tranmission of successive words on the wire. Personally I like these description match with what is described in the device spec/ user guide and what is described above match with that. However we could add additional description as below to to make it more explicit. spi-c2t-delay - delay after CS is asserted before output bits on wire spi-t2c-delay - delay after tramission of bits and before deasserting CS Do you think this will help? No, that doesn't help at all. You keep claiming that these parameters are related to the intervals between words but then providing descriptions of these parameters which relate to intervals around changes in /CS which is patently not something connected with the gaps between words. Either your description of parameters which do not relate to /CS should not need to mention /CS or the parameters are in fact related to /CS, both can't simultaneously be true. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] spi: davinci: support adding delay between transmission
On Mon, Sep 08, 2014 at 04:30:57PM +0300, Grygorii Strashko wrote: I'll split this patch and first introduce WDELAY, C2TDELAY, T2CDELAY (with updated documentation). The only question is - Should they be somehow common or specific for spi-davinci? If they don't have any impact on the device at the remote end of the link then making them device specific is fine. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] spi: davinci: support adding delay between transmission
On Fri, Sep 05, 2014 at 05:21:56PM +0300, Grygorii Strashko wrote: I think we have some misunderstanding here :( 1) All new properties a optional and should be specified for SPI Slave devices 2) Seems we are talking using different terms: - you referring to the term transfers - sequence of packets. Each packet is one transfer (array of words). - while these new properties affect on transmissions - sequence of words. Each word is one transmission. That's *very* unusual terminology which doesn't match my expectations at all. Please describe words as words, that'll be much more obvious. Also, below is additional information about properties which are used in 5-pin mode (SPI_READY) to improve error detection [OMAP-L138/da830 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf]: This is a *whole* other thing, please split these out and work on this separately. The client device is going to need to be doing the same thing here so implementing this as a local option in the controller driver isn't the best way forwards. SPIFMTn[23].PARPOL - Parity polarity: even or odd. PARPOL can be modified in privilege mode only. 0 An even parity flag is added at the end of the transmit data stream. 1 An odd parity flag is added at the end of the transmit data stream. Why would these be specified in DT and not with runtime flags enabled by the device? It looks like they affect the data stream generated by the controller so the client device needs to know about them; I'd expect that it's device driver would be controlling when they are enabled if the controller supports them. Could you clarify, pls - Do you mean that struct spi_device.mode and common SPI DT bindings should be extended to support this? Yes, if they aren't something that's purely internal to the device they need to be generic so that both devices can be configured appropriately. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] spi: davinci: support adding delay between transmission
On Fri, Aug 22, 2014 at 04:33:09PM +0300, Grygorii Strashko wrote: On 08/21/2014 09:20 PM, Mark Brown wrote: On Thu, Aug 21, 2014 at 06:25:06PM +0300, Grygorii Strashko wrote: +- ti,davinci-spi-wdelay : delay between transmissions. I don't understand why this is here - there is already standard support in the SPI core for client drivers specifying inter-transfer delays. If there is a need to provide platform configuration for this in addition to that then it should also be a standard property, there is nothing device specific about these. Sorry, may be I've missed smth, because I was not able to find such common property in SPI bindings document and code. Could you point me on, pls? It's not a property, it's what the delay_usecs in the transfer does. There is no obvious reason to apply something like this unconditionally on every transfer in DT - either it's needed only at particular points in the transfer for device reasons (in which case the device driver needs to know about it) or we need some sort of association with what the device is doing since the way the client driver splits up transfers is entirely up to it. +- ti,davinci-spi-odd-parity : odd partity enabled + OR + ti,davinci-spi-even-parity : even parity enabled What do these mean? Supported by OMAP-L138/da830: SPIFMTn[23].PARPOL - Parity polarity: even or odd. PARPOL can be modified in privilege mode only. 0 An even parity flag is added at the end of the transmit data stream. 1 An odd parity flag is added at the end of the transmit data stream. Why would these be specified in DT and not with runtime flags enabled by the device? It looks like they affect the data stream generated by the controller so the client device needs to know about them; I'd expect that it's device driver would be controlling when they are enabled if the controller supports them. +- ti,davinci-spi-io-type: io type (check platform_data/spi-davinci.h) The bindings should be independent of the kernel, the values need to be included here (and the defines moved to include/dt-bindings so they can be used when writing DTs). Allowed values here are: #define SPI_IO_TYPE_INTR 0 #define SPI_IO_TYPE_POLL 1 #define SPI_IO_TYPE_DMA 2 I'll update. Now I see these it's not at all clear why this is configurable at all - I would expect the controller driver to automatically select the most appropriate scheme for the transfers it's doing in order to obtain the best performance rather than having a global switch for this. For almost all devices the best results will be obtained by doing a mix of these modes. Typically for each level of transfer there will be some minimal size below which it doesn't make sense to use that control type, for example it's common to only DMA if there's more than a FIFO worth of data to transfer. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] spi: davinci: fix SPI_NO_CS functionality
On Thu, Aug 21, 2014 at 06:25:05PM +0300, Grygorii Strashko wrote: The driver should not touch CS lines if SPI_NO_CS flag is set. This patch fixes it as this functionality was broken accidentally by commit a88e34ea213e1b (spi: davinci: add support to configure gpio cs through dt). Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] spi: davinci: support adding delay between transmission
On Thu, Aug 21, 2014 at 06:25:06PM +0300, Grygorii Strashko wrote: +- ti,davinci-spi-wdelay : delay between transmissions. I don't understand why this is here - there is already standard support in the SPI core for client drivers specifying inter-transfer delays. If there is a need to provide platform configuration for this in addition to that then it should also be a standard property, there is nothing device specific about these. +- ti,davinci-spi-odd-parity : odd partity enabled + OR + ti,davinci-spi-even-parity : even parity enabled What do these mean? +- ti,davinci-spi-io-type: io type (check platform_data/spi-davinci.h) The bindings should be independent of the kernel, the values need to be included here (and the defines moved to include/dt-bindings so they can be used when writing DTs). +- ti,davinci-spi-disable-timer: disable CS timer (SPIFMTn) +- ti,davinci-spi-c2t-delay: c2t delay +- ti,davinci-spi-t2c-delay: t2c delay +- ti,davinci-spi-t2e-delay: t2e delay +- ti,davinci-spi-c2e-delay: c2e delay What are all these timers/delays - at least some reference to the datasheet please? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] spi: davinci: add support to configure gpio cs through dt
On Fri, Aug 01, 2014 at 07:40:32PM +0300, Grygorii Strashko wrote: From: Murali Karicheri m-kariche...@ti.com Currently driver supports only configuration of GPIO CS through platform data. This patch enhances the driver to configure GPIO CS through DT. Also update the DT binding documentation to reflect the availability of cs-gpios. Please submit an incremental patch with whatever the changes were from the version of this that I applied already. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] spi: davinci: add support to configure gpio cs through dt
On Fri, Aug 01, 2014 at 07:40:32PM +0300, Grygorii Strashko wrote:
From: Murali Karicheri m-kariche...@ti.com
Currently driver supports only configuration of GPIO CS through
platform data. This patch enhances the driver to configure GPIO
CS through DT. Also update the DT binding documentation to
reflect the availability of cs-gpios.
Ah, sorry - this is the unapplied patch from before. It would have been
much better to submit this as the second patch after your rework patch
since this...
- if (pdata-chip_sel chip_sel pdata-num_chipselect
- pdata-chip_sel[chip_sel] != SPI_INTERN_CS)
+ if (np master-cs_gpios != NULL spi-cs_gpio = 0) {
+ /* SPI core parse and update master-cs_gpio */
gpio_chipsel = true;
+ gpio = spi-cs_gpio;
+ } else if (pdata-chip_sel
+chip_sel pdata-num_chipselect
+pdata-chip_sel[chip_sel] != SPI_INTERN_CS) {
+ /* platform data defines chip_sel */
+ gpio_chipsel = true;
+ gpio = pdata-chip_sel[chip_sel];
+ }
...still looks excessively confusing - it is way more logic than I'd
expect to see on every chip select.
signature.asc
Description: Digital signature
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] spi: davinci: add support to configure gpio cs through dt
On Fri, Aug 01, 2014 at 07:40:32PM +0300, Grygorii Strashko wrote: From: Murali Karicheri m-kariche...@ti.com Currently driver supports only configuration of GPIO CS through platform data. This patch enhances the driver to configure GPIO CS through DT. Also update the DT binding documentation to reflect the availability of cs-gpios. Applied both, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/3] spi: remove obsolete spi-ti-ssp driver
On Tue, Mar 18, 2014 at 03:55:59PM +0100, Arnd Bergmann wrote: The tnetv107x platform is getting removed, so this driver will not be needed any more. Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On Fri, Mar 14, 2014 at 11:38:58AM +0200, Peter Ujfalusi wrote: The only thing I'm afraid off is that it is going to take two release cycle to get this in: first cycle edma part, next cycle for the ASoC to switch to use the edma-pcm. We can do a cross tree merge, or the EDMA code can be applied to ASoC directly if that's what people want. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x
On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote: With this series AM335x and AM447x will use the dmaengine PCM for audio. The daVinci devices will keep using the davinci-pcm for now since I do not have means to test them but the code is written in a way that they can be switched to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was working fine). Can you please not resend the ASoC portions of this series until the EDMA portion is stable (and ideally committed)? I'm not quite sure why but every EDMA patch series seems to go through lots of iterations which gets rather noisy - my initial reaction to seeing EDMA in a subject is to just delete the thread. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/5] spi: remove obsolete spi-ti-ssp driver
On Wed, Feb 26, 2014 at 01:43:32PM +0100, Arnd Bergmann wrote: The tnetv107x platform is getting removed, so this driver will not be needed any more. If you get the acks you're looking for can you please resend with them? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] regulator: tps6507x: Use IS_ENABLED for DT code.
On Thu, Feb 06, 2014 at 12:06:00AM +0530, Manish Badarkhe wrote: Instead of #ifdef CONFIG_OF use IS_ENABLED(CONFIG_OF) option for DT code to avoid if-deffery in code. Also, modify code as per coding style. Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
On Tue, Sep 24, 2013 at 11:44:57AM +0200, Laurent Pinchart wrote: On Monday 23 September 2013 15:33:10 Stephen Warren wrote: So I think you want to make the supply properties mandatory in DT (since some form of supply is mandatory in HW), yet make the driver support broken DTs which don't have those properties, by error-checking the return value from regulator_get(). You might want to put a note into DT saying that a previous version of the binding didn't require those supply properties, so they may be missing from older DTs. Are there such devices in the wild ? From v3.12 on the kernel will stub in a dummy supply if one isn't found when using DT but I wouldn't mention that in the bindings since it's very much fixing up broken DTs rather than a good idea. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
On Mon, Sep 23, 2013 at 01:50:51PM +0200, Laurent Pinchart wrote: Isn't regulator_get_optional() intended for devices that can have supplies unconnected in normal use ? The ADV7343 supplies are mandatory from a hardware point of view, so I think we should use regulator_get(). Otherwise the driver won't be able to tell the difference between a regulator that isn't present yet (for instance because the regulator device/driver hasn't been probed yet), which should result in deferred probing, and an always-on regulator that has been left out. Yes, everything you say here is correct. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/5] Remove ASoC-level I/O functions from cq93vc
On Mon, Sep 02, 2013 at 10:55:34AM +0200, Samuel Ortiz wrote: I put a topic/for-asoc branch upstream for you to pull from: Great, thanks! signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/5] Remove ASoC-level I/O functions from cq93vc
On Sun, Sep 01, 2013 at 04:48:47PM +0200, Samuel Ortiz wrote: As I'd prefer to carry the MFD ones (Including the twl6040 one) through mfd-next, I can build a branch for you to pull from. Would that be fine with you ? That's fine by me, I just want the patches in ASoC - obviously the branch couldn't be rebased though. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ASoC: cq93vc: Use table based control registration
From: Mark Brown broo...@linaro.org
Saves a little code.
Signed-off-by: Mark Brown broo...@linaro.org
---
sound/soc/codecs/cq93vc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 3ce535b..43737a27 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -142,10 +142,6 @@ static int cq93vc_probe(struct snd_soc_codec *codec)
snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP);
- /* Set controls */
- snd_soc_add_codec_controls(codec, cq93vc_snd_controls,
-ARRAY_SIZE(cq93vc_snd_controls));
-
/* Off, with power on */
cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
@@ -164,6 +160,8 @@ static struct snd_soc_codec_driver soc_codec_dev_cq93vc = {
.probe = cq93vc_probe,
.remove = cq93vc_remove,
.resume = cq93vc_resume,
+ .controls = cq93vc_snd_controls,
+ .num_controls = ARRAY_SIZE(cq93vc_snd_controls),
};
static int cq93vc_platform_probe(struct platform_device *pdev)
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/5] mfd: davinci_voicecodec: Remove unused read and write functions
From: Mark Brown broo...@linaro.org
These functions are not referenced anywhere, nor prototyped, so just
remove them.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/mfd/davinci_voicecodec.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c
index fb643985..a292d71 100644
--- a/drivers/mfd/davinci_voicecodec.c
+++ b/drivers/mfd/davinci_voicecodec.c
@@ -32,17 +32,6 @@
#include linux/mfd/davinci_voicecodec.h
-u32 davinci_vc_read(struct davinci_vc *davinci_vc, int reg)
-{
- return __raw_readl(davinci_vc-base + reg);
-}
-
-void davinci_vc_write(struct davinci_vc *davinci_vc,
- int reg, u32 val)
-{
- __raw_writel(val, davinci_vc-base + reg);
-}
-
static int __init davinci_vc_probe(struct platform_device *pdev)
{
struct davinci_vc *davinci_vc;
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/5] Remove ASoC-level I/O functions from cq93vc
This patch series removes the use of the ASoC-level read and write functions from the cq93vc driver as part of a wider push to remove them completely and just use regmap for all register I/O. Since the driver is essentially doing what regmap-mmio is doing this is done by adding a MMIO regmap to the core device and using that. This is compile tested only, I don't have any hardware to run on. Since I anticipate doing more cleanups over the CODEC drivers during the next release cycle it'd be good to merge via ASoC, though there shouldn't be any overlap with the first patch. Mark Brown (5): mfd: davinci_voicecodec: Remove unused read and write functions mfd: davinci_voicecodec: Provide a regmap for register I/O ASoC: cq93vc: Use core I/O functions ASoC: cq93vc: Don't use control data for core driver data ASoC: cq93vc: Use regmap for I/O drivers/mfd/davinci_voicecodec.c | 23 +++ include/linux/mfd/davinci_voicecodec.h | 3 +++ sound/soc/codecs/cq93vc.c | 42 +++--- 3 files changed, 29 insertions(+), 39 deletions(-) signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 4/5] ASoC: cq93vc: Don't use control data for core driver data
From: Mark Brown broo...@linaro.org
The platform data is being used to obtain the core driver data for the
device (which is a bit of an abuse but not the issue at hand) so reference
it directly in order to support refactoring to use regmap.
Signed-off-by: Mark Brown broo...@linaro.org
---
sound/soc/codecs/cq93vc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 424e9a4..2cbb584 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -81,7 +81,7 @@ static int cq93vc_set_dai_sysclk(struct snd_soc_dai
*codec_dai,
int clk_id, unsigned int freq, int dir)
{
struct snd_soc_codec *codec = codec_dai-codec;
- struct davinci_vc *davinci_vc = codec-control_data;
+ struct davinci_vc *davinci_vc = codec-dev-platform_data;
switch (freq) {
case 22579200:
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 5/5] ASoC: cq93vc: Use regmap for I/O
From: Mark Brown broo...@linaro.org
Avoid use of the ASoC-specific register I/O functions by converting to
use the MMIO regmap provided the core MFD.
Signed-off-by: Mark Brown broo...@linaro.org
---
sound/soc/codecs/cq93vc.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 2cbb584..43737a27 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -38,24 +38,6 @@
#include sound/soc.h
#include sound/initval.h
-static inline unsigned int cq93vc_read(struct snd_soc_codec *codec,
- unsigned int reg)
-{
- struct davinci_vc *davinci_vc = codec-control_data;
-
- return readl(davinci_vc-base + reg);
-}
-
-static inline int cq93vc_write(struct snd_soc_codec *codec, unsigned int reg,
- unsigned int value)
-{
- struct davinci_vc *davinci_vc = codec-control_data;
-
- writel(value, davinci_vc-base + reg);
-
- return 0;
-}
-
static const struct snd_kcontrol_new cq93vc_snd_controls[] = {
SOC_SINGLE(PGA Capture Volume, DAVINCI_VC_REG05, 0, 0x03, 0),
SOC_SINGLE(Mono DAC Playback Volume, DAVINCI_VC_REG09, 0, 0x3f, 0),
@@ -156,7 +138,9 @@ static int cq93vc_probe(struct snd_soc_codec *codec)
struct davinci_vc *davinci_vc = codec-dev-platform_data;
davinci_vc-cq93vc.codec = codec;
- codec-control_data = davinci_vc;
+ codec-control_data = davinci_vc-regmap;
+
+ snd_soc_codec_set_cache_io(codec, 32, 32, SND_SOC_REGMAP);
/* Off, with power on */
cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
@@ -172,8 +156,6 @@ static int cq93vc_remove(struct snd_soc_codec *codec)
}
static struct snd_soc_codec_driver soc_codec_dev_cq93vc = {
- .read = cq93vc_read,
- .write = cq93vc_write,
.set_bias_level = cq93vc_set_bias_level,
.probe = cq93vc_probe,
.remove = cq93vc_remove,
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/5] mfd: davinci_voicecodec: Provide a regmap for register I/O
From: Mark Brown broo...@linaro.org
This will be used to support refactoring of the ASoC CODEC driver to use
a regmap.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/mfd/davinci_voicecodec.c | 14 ++
include/linux/mfd/davinci_voicecodec.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c
index a292d71..013ba81 100644
--- a/drivers/mfd/davinci_voicecodec.c
+++ b/drivers/mfd/davinci_voicecodec.c
@@ -27,11 +27,17 @@
#include linux/delay.h
#include linux/io.h
#include linux/clk.h
+#include linux/regmap.h
#include sound/pcm.h
#include linux/mfd/davinci_voicecodec.h
+static struct regmap_config davinci_vc_regmap = {
+ .reg_bits = 32,
+ .val_bits = 32,
+};
+
static int __init davinci_vc_probe(struct platform_device *pdev)
{
struct davinci_vc *davinci_vc;
@@ -63,6 +69,14 @@ static int __init davinci_vc_probe(struct platform_device
*pdev)
goto fail;
}
+ davinci_vc-regmap = devm_regmap_init_mmio(pdev-dev,
+ davinci_vc-base,
+ davinci_vc_regmap);
+ if (IS_ERR(davinci_vc-regmap)) {
+ ret = PTR_ERR(davinci_vc-regmap);
+ goto fail;
+ }
+
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!res) {
dev_err(pdev-dev, no DMA resource\n);
diff --git a/include/linux/mfd/davinci_voicecodec.h
b/include/linux/mfd/davinci_voicecodec.h
index 13a1ee9..5166935 100644
--- a/include/linux/mfd/davinci_voicecodec.h
+++ b/include/linux/mfd/davinci_voicecodec.h
@@ -30,6 +30,8 @@
#include mach/hardware.h
+struct regmap;
+
/*
* Register values.
*/
@@ -113,6 +115,7 @@ struct davinci_vc {
/* Memory resources */
void __iomem *base;
+ struct regmap *regmap;
/* MFD cells */
struct mfd_cell cells[DAVINCI_VC_CELLS];
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/5] ASoC: cq93vc: Use core I/O functions
From: Mark Brown broo...@linaro.org
Support future refactoring by using the core I/O functions rather than
calling the driver provided I/O functions directly.
Signed-off-by: Mark Brown broo...@linaro.org
---
sound/soc/codecs/cq93vc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
index 1ba7588..424e9a4 100644
--- a/sound/soc/codecs/cq93vc.c
+++ b/sound/soc/codecs/cq93vc.c
@@ -64,13 +64,15 @@ static const struct snd_kcontrol_new cq93vc_snd_controls[]
= {
static int cq93vc_mute(struct snd_soc_dai *dai, int mute)
{
struct snd_soc_codec *codec = dai-codec;
- u8 reg = cq93vc_read(codec, DAVINCI_VC_REG09) ~DAVINCI_VC_REG09_MUTE;
+ u8 reg;
if (mute)
- cq93vc_write(codec, DAVINCI_VC_REG09,
-reg | DAVINCI_VC_REG09_MUTE);
+ reg = DAVINCI_VC_REG09_MUTE;
else
- cq93vc_write(codec, DAVINCI_VC_REG09, reg);
+ reg = 0;
+
+ snd_soc_update_bits(codec, DAVINCI_VC_REG09, DAVINCI_VC_REG09_MUTE,
+ reg);
return 0;
}
@@ -97,18 +99,18 @@ static int cq93vc_set_bias_level(struct snd_soc_codec
*codec,
{
switch (level) {
case SND_SOC_BIAS_ON:
- cq93vc_write(codec, DAVINCI_VC_REG12,
+ snd_soc_write(codec, DAVINCI_VC_REG12,
DAVINCI_VC_REG12_POWER_ALL_ON);
break;
case SND_SOC_BIAS_PREPARE:
break;
case SND_SOC_BIAS_STANDBY:
- cq93vc_write(codec, DAVINCI_VC_REG12,
+ snd_soc_write(codec, DAVINCI_VC_REG12,
DAVINCI_VC_REG12_POWER_ALL_OFF);
break;
case SND_SOC_BIAS_OFF:
/* force all power off */
- cq93vc_write(codec, DAVINCI_VC_REG12,
+ snd_soc_write(codec, DAVINCI_VC_REG12,
DAVINCI_VC_REG12_POWER_ALL_OFF);
break;
}
--
1.8.4.rc3
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 08/12] dma: edma: Add one more required slot to MAX slots
On Mon, Aug 12, 2013 at 11:26:49AM +0530, Sekhar Nori wrote: No need for a separate patch for this, just do this in the patch where you include the two linked sets. Can you guys please think about the CC lists you're using for these patch serieses? I've certainly no interest in random patches to the DaVinci DMA controllers, and I suspect the same is true for most of the people on the CC list. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. The whole purpose of NAPI is to avoid taking interrupts for completion of transfers. Anything that generates interrupts when NAPI is in polling mode is defeating the point. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 05, 2013 at 05:06:28PM +, Russell King - ARM Linux wrote: On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote: On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: For IRQ mode, use the completion callback to push each cookie to NAPI, and thus let the IRQ drive the traffic. The whole purpose of NAPI is to avoid taking interrupts for completion of transfers. Anything that generates interrupts when NAPI is in polling mode is defeating the point. Yes, but you're missing one very important point. If your DMA engine is decoupled from the network device, and the DMA engine relies upon interrupts to queue further transfers to move data into RAM, then you have two options: 1. Receive these interrupts so you can update the DMA engine for further data transfer. 2. Don't receive these interrupts, and cause the network device to error out with a FIFO overrun because its DMA requests have not been serviced. (which may raise an interrupt.) There's still the third option of just implementing a non-NAPI driver, though I guess we've now built so much infrastructure on top of NAPI that it's still useful to pretend we can disable interrupts. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/3] ASoC: tlv320aic3x: Convert mic bias to a supply widget
On Thu, Jan 31, 2013 at 06:23:04PM +0530, Hebbar Gururaja wrote: Convert MicBias widgets to supply widget. On tlv320aic3x, Mic bias power on/off shares the same register bits with output mic bias voltage. So, when power on mic bias, we need reclaim it to voltage value. Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote: On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote: Based on our experience with fitting multiple subsystems on top of this DMA-Engine driver, I must say that the DMA-Engine interface has proven to be a less than ideal fit for the network driver use case. The first problem is that the DMA-Engine interface expects to push completed traffic up into the upper layer as a part of its callback. This doesn't fit cleanly with NAPI, which expects to pull completed traffic from below in the NAPI poll. We've somehow kludged together a solution around this, but it isn't very elegant. I cannot understand the actual technical problem from the above paragraphs though. dmaengine doesn't have a concept of pushing nor polling, it basically copies streams of words from A to B, where A/B can be a device or a buffer, nothing else. The thing you're looking for sounds more like an adapter on top of dmaengine, which can surely be constructed, some drivers/dma/dmaengine-napi.c or whatever. Broadly speaking what NAPI wants is to never get any callbacks from the hardware (or DMAs). It wants to wake up periodically, take a look at what packets have been read by the hardware and process them. The goal is to have the DMAs sitting and running without disturbing the processor at all after the first packet has been handled. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 1/4] ASoC: tlv320aic3x: Convert mic bias to a supply widget
On Thu, Jan 31, 2013 at 04:53:10PM +0530, Hebbar Gururaja wrote: :100644 100644 e7b98f4... f47c3f5... M Documentation/devicetree/bindings/sound/tlv320aic3x.txt :100644 100644 ffd9bc7... 9407fd0... Minclude/sound/tlv320aic3x.h :100644 100644 4989143... 65d09d6... Msound/soc/codecs/tlv320aic3x.c :100644 100644 6db3c41... e521ac3... Msound/soc/codecs/tlv320aic3x.h As mentioned when you posted this before this patch needs to update the machine drivers using the device too. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 1/4] ASoC: tlv320aic3x: Convert mic bias to a supply widget
On Thu, Jan 31, 2013 at 11:27:07AM +, Hebbar, Gururaja wrote: On Thu, Jan 31, 2013 at 16:54:16, Mark Brown wrote: As mentioned when you posted this before this patch needs to update the machine drivers using the device too. The patch-set 2/4 does the same thing. Since I have da850-evm at my end, I have modified that machine driver and sent-it as 2/4. Two problems here. One is that the update should be done in the same patch and the other is that you need to update *all* the machine drivers using the device, not just one of them. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ASoC: tlv320aic3x: Convert mic bias to a supply widget
On Wed, Jan 30, 2013 at 06:52:35PM +0530, Hebbar Gururaja wrote: Convert MicBias widgets to supply widget. On tlv320aic3x, Mic bias power on/off shares the same register bits with output mic bias voltage. So, when power on mic bias, we need reclaim it to voltage value. This should update machine drivers that use the CODEC too. +- ai3x-micbias-vg - MicBias Voltage required. + 1 - MICBIAS output is powered to 2.0V, + 2 - MICBIAS output is powered to 2.5V, + 3 - MICBIAS output is connected to AVDD, + If this node is not mentioned or if the value is incorrect, then MicBias + is powered down. Would 2.0V not be a more sensible default (it is the lowest voltage so is unlikely to cause hardware damage if it's wrong)? Otherwise this looks good. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 4/6] davinci: regulator: tps6507x: add device tree support.
On Thu, Jan 24, 2013 at 04:25:18PM +0530, Vishwanathrao Badarkhe, Manish wrote: Add device tree based initialization support for TI's tps6507x regulators. Applied, thanks. Please always use subject lines appropriate for the subsystem you are submitting against - this is not a DaVinci change. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 5/6] ARM: regulator: add tps6507x device tree data
On Fri, Jan 25, 2013 at 06:29:49AM +, Vishwanathrao Badarkhe, Manish wrote: On Thu, Jan 24, 2013 at 17:30:51, Mark Brown wrote: I too doubt that whether it should be in architecture specific folder, My code is in reference to below patch: arm/dts: regulator: Add tps65910 device tree data(d5d08e2e1672da627d7c9d34a9dc1089c653e23a) Could you please suggest me if it can be moved somewhere else? We should have somewhere to put this sort of generic stuff, yes. Not sure where, possibly under drivers/of or some non-drivers part of the tree. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
On Thu, Jan 24, 2013 at 09:33:34AM +, Hebbar, Gururaja wrote: So, by just using the SND_SOC_DAPM_POST_PMU SND_SOC_DAPM_PRE_PMD I can mask handle one particular voltage. What makes you say that? That is just not true. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
On Thu, Jan 24, 2013 at 10:06:42AM +, Hebbar, Gururaja wrote: What I meant was that by using this macro (SND_SOC_DAPM_POST_PMU SND_SOC_DAPM_PRE_PMD) I can just save and restore existing voltage values inside the event. They will not be user configurable (available to user through some widget). Well, you *could* add separate register control for that but it's not really something that should obviously be exposed to users; usually that'd be something that is fixed by the platform via platform data. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 5/6] ARM: regulator: add tps6507x device tree data
On Thu, Jan 24, 2013 at 04:25:19PM +0530, Vishwanathrao Badarkhe, Manish wrote: --- arch/arm/boot/dts/tps6507x.dtsi | 47 +++ Why are you putting this in arch/arm? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
On Wed, Jan 23, 2013 at 12:39:35PM +, Hebbar, Gururaja wrote: On Fri, Jan 04, 2013 at 17:56:12, Mark Brown wrote: The CODEC driver biases should be changed over to be supplies, this makes the above much more natural - the routing there is a hack for older versions of ASoc. Otherwise this looks fine. ON TLV320AIC3x Codec, MIC Bias power on/off share the same register bits with Bias voltage output. So you need to use an event to write the actual enable bit. SGTL5000 -- Single register for MIC BIAS enable output impedance of MIC Bias. The driver uses SND_SOC_DAPM_POST_PMU SND_SOC_DAPM_PRE_PMD macro to handle the MIC Bias enable disable event. This is the way these things should be handled. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5 00/14] DMA Engine support for AM33XX
On Tue, Jan 22, 2013 at 09:26:34PM +0530, Sekhar Nori wrote: On 1/16/2013 2:02 AM, Matt Porter wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. Will you take this series through the OMAP tree? Only 1/14 touches mach-davinci and I am mostly okay with it except some changes I just requested Matt to make in another thread. Is this series somewhere near actually getting merged then? It seemed like there was lots of stuff going on. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
On Mon, Jan 07, 2013 at 09:20:16AM +, Hebbar, Gururaja wrote: I will be looking into this now. To speed up the things, do you have any reference link/implementation which I can refer to? Any modern CODEC driver. I looked at the OMAP implementation but they are following the same (meaning both DT non-DT use similar audio map for routing). You should use the same setup for DT and non-DT. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/2] ASoC: davinci-mcasp: Add pinctrl support
On Fri, Jan 04, 2013 at 03:24:36PM +0530, Hebbar Gururaja wrote: From: Hebbar, Gururaja gururaja.heb...@ti.com Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com Linus has a change for this in the core which currently looks like it'll get merged in v3.8 so there doesn't seem to be any pressing need for driver specific changes that just set the defaults. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
On Fri, Jan 04, 2013 at 03:24:37PM +0530, Hebbar Gururaja wrote: + MIC3L,Mic Bias 2V, + MIC3R,Mic Bias 2V, + Mic Bias 2V, Mic Jack, The CODEC driver biases should be changed over to be supplies, this makes the above much more natural - the routing there is a hack for older versions of ASoc. Otherwise this looks fine. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ASoC: davinci-mcasp: Add pinctrl support
On Mon, Nov 26, 2012 at 09:55:33PM -0800, Peter Korsgaard wrote: Mark == Mark Brown broo...@opensource.wolfsonmicro.com writes: Mark Since the driver is happy to continue without the pins why is it Mark bothering requesting them in the first place? In other words, this Mark should be a hard error. Sorry, I disagree. As was discussed recently, there's several reasons why the pinctrl call might fail, and not all are fatal (E.G. pinmux already setup by bootloader): http://article.gmane.org/gmane.linux.kernel/1399756 I'd expect the platform to provide stub mappings for cases where the pinmux code shouldn't do anything. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant
On Mon, Nov 26, 2012 at 11:32:49AM +, Hebbar, Gururaja wrote: On Sun, Nov 25, 2012 at 15:56:27, Yegor Yefremov wrote: What can be expected in 3.8? 1. ASoC McASP DT conversion is 80% complete. Davinci Machine DT conversion McASP pinctrl support is yet to be accepted. I sent a patch recently and waiting for feedback. I don't have anything in my review queue, please post patches if you want them reviewed. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ASoC: davinci-mcasp: Add pinctrl support
On Thu, Nov 22, 2012 at 09:34:58AM +0530, Hebbar, Gururaja wrote: + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, + pins are not configured from the driver\n); Since the driver is happy to continue without the pins why is it bothering requesting them in the first place? In other words, this should be a hard error. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] ASoC: Davinci: machine: Add device tree binding
On Thu, Nov 22, 2012 at 09:34:59AM +0530, Hebbar, Gururaja wrote: +- dai-data : A list of DAI data used by SOC code to register + DAI, Codecs platform. + The string index should be as shown below. +dai-data = +DAI Name,DAI Stream Name, +CODEC DAI Name, true if evm_aic3x_init is required, else false, +evm ops required (evm_ops or evm_spdif_ops); This continues to have the same issue as with previous versions, this is all Linux internals (especially the evm_aic3x_init thing) not a description of the hardware, there's not enough information to allow someone to work out what the bindings for their system should be. Do not post *ANY* further versions that have this evm_aic3x_init stuff in them, it's very annoying that you keep on ignoring this feedback. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH 0/3] ASoC: Davinci: McASP: add support new McASP IP Variant
On Mon, Nov 26, 2012 at 11:42:01AM +, Hebbar, Gururaja wrote: I already sent the patches for these on 22/11/2012 http://lkml.org/lkml/2012/11/22/857 You've resent the same bindings again without addressing the review comments from last time. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote: I also agree that ifdef is not a good solution. It is better to have this information passed as device_data and via DT it can be decided based on the compatible property for the device. That's not really the problem here - the problem is that the APIs used to get the SRAM are DaVinci only so it's not possible to build on OMAP or other platforms. The SRAM code needs to move to a standard API. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
On Thu, Sep 27, 2012 at 06:57:49AM +, Hebbar, Gururaja wrote: I have no knowledge about multi-platform builds yet. Currently this driver is shared between OMAP DaVinci and both of them doesn't exist in single image build. ...due to issues like having compile time things selecting between the platforms. In other words what these ifdefs would do is move us further away from that goal rather than towards it as we should be doing. There was a effort done for this SRAM Consolidation [1] but it didn't progress. Hence I took this approach as a time-being/workaround. This was we can get affected platforms (like AM335x) get going/working. Looks like it just needs more people pushing it... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote: +config SND_DAVINCI_HAVE_SRAM + bool + default y if ARCH_DAVINCI=y + default n if ARCH_OMAP=y + I've been sitting on this mostly since it seems like a step back from multi-platform kernels (which is where we're trying to get to) and I've been trying to decide what the best approach is. I'm thinking that we do want a generic API for allocating this stuff, it's a fairly generic feature (there's TCMs as well). Adding ifdefs like this does just doesn't seem good. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC PATCH 13/13] Documentation: add schedule for removing private EDMA API
On Thu, Sep 20, 2012 at 10:43:46AM -0400, Matt Porter wrote: Documentation/feature-removal-schedule.txt | 10 ++ 1 file changed, 10 insertions(+) We decided at kernel summit that we'd stop bothering with this, it's mostly just bitrot and rarely read. I guess the ASoC driver update isn't ready yet? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
On Wed, Sep 12, 2012 at 07:50:31AM +, Hebbar, Gururaja wrote: Gentle ping. Is there any comments/review for this patch? If not, can this be pulled in? Don't send contentless quoted pings. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V3] ASoC: Davinci: machine: Add device tree binding
On Wed, Sep 12, 2012 at 07:55:08AM +, Hebbar, Gururaja wrote: Gentle ping. Is there any comments/review for this patch? If not, can this be pulled in? To repeat, don't send contentless pings. If the patch has genuinely been lost then it'll need a resend. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] ASoC: Davinci: McASP: add support new McASP IP Variant
On Mon, Sep 03, 2012 at 01:40:40PM +0530, Hebbar, Gururaja wrote: The OMAP2+ variant of McASP is different from Davinci variant w.r.to some register offset. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant
On Mon, Sep 03, 2012 at 06:57:22AM +, Hebbar, Gururaja wrote: Ok I will update this. Since 3/3 is already accepted I don’t see any reviews for 2/3, I will only resend this patch (1/3). Is it ok? Yes. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V3] ASoC: Davinci: machine: Add device tree binding
On Fri, Aug 31, 2012 at 08:55:39AM +, Hebbar, Gururaja wrote: Gentle Ping. Any updates about this version or can it be pulled into the tree. On Thu, Aug 30, 2012 at 09:29:55, Hebbar, Gururaja wrote: Please don't do this: - Never top post. - If the patch genuinely has been forgotten you need to resend it. - You've allowed less than 24 hours for a reply, this is unreasonable. Unless there's a critical bug fix you should only be worrying after a few weeks or so. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/3] ASoC: Davinci: McASP: add support new McASP IP Variant
On Fri, Aug 31, 2012 at 06:20:57PM +0530, Hebbar, Gururaja wrote:
+ if (dev-version == MCASP_VERSION_3) {
+ mcasp_clr_bits(dev-base + MCASP_VER3_RFIFOCTL,
FIFO_ENABLE);
- mcasp_set_bits(dev-base + DAVINCI_MCASP_RFIFOCTL,
+ mcasp_set_bits(dev-base + MCASP_VER3_RFIFOCTL,
FIFO_ENABLE);
+ } else {
+ mcasp_clr_bits(dev-base +
+ DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE);
+ mcasp_set_bits(dev-base +
+ DAVINCI_MCASP_RFIFOCTL, FIFO_ENABLE);
+ }
This is all basically OK but it seems like it'd be better if all these
dev-version checks were switch statements. That way when the hardware
designers get bored and add version 4 of the register map it'll slot in
naturally, and it'll be more clear what the code currently handles.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/3] ASoC: Davinci: evm: Fix typo in cpu dai name
On Fri, Aug 31, 2012 at 06:20:59PM +0530, Hebbar, Gururaja wrote: Fix typo caused by recent commit (cf53756 - ASoC: davinci: davinci-pcm does not need to be a plaform_driver) Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 6/6] ASoC: tlv320aic3x: Add device tree bindings
On Mon, Aug 27, 2012 at 06:56:44PM +0530, Hebbar, Gururaja wrote: Device tree support for tlv320aic3x CODEC driver. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 4/6] ASoC: Davinci: McASP: add device tree support for McASP
On Mon, Aug 27, 2012 at 06:56:42PM +0530, Hebbar, Gururaja wrote: +- sram-size-playback : size of sram to be allocated during playback +- sram-size-capture : size of sram to be allocated during capture These smell like runtime/policy configuration rather than fixed properties of the device so it probably shouldn't appear in the device tree, ideally at some point in the future we'll be able to work out some wonderful way of automatically allocating the resources. That said if the rest of the series looks OK I'll apply this but it'd be nice to get these numbers from somewhere else. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 1/6] ASoC: davinci: davinci-pcm does not need to be a plaform_driver
On Mon, Aug 27, 2012 at 06:56:39PM +0530, Hebbar, Gururaja wrote: Same as the commit 518de86 (ASoC: tegra: register 'platform' from DAIs, get rid of pdev). It makes davinci-pcm not a platform_driver but helper to register platform, so that the platform_device for davinci-pcm can be saved completely. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 3/6] ASoC/ARM: Davinci: McASP: split asp header into platform and audio specific
On Mon, Aug 27, 2012 at 06:56:41PM +0530, Hebbar, Gururaja wrote: Davinci McASP header driver are shared by few OMAP platforms (like TI81xx, AM335x). Splitting asp header into Davinci platform specific header and Audio specific header helps to share them across platforms. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 2/6] ARM: Davinci: Remove references to davinci pcm
On Mon, Aug 27, 2012 at 06:56:40PM +0530, Hebbar, Gururaja wrote: Since davinci-pcm is no more a platform_driver but helper to register platform pcm driver, remove davinci-pcm device registration Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 4/6] ASoC: Davinci: McASP: add device tree support for McASP
On Mon, Aug 27, 2012 at 06:56:42PM +0530, Hebbar, Gururaja wrote: Add device tree probe for McASP driver. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2 5/6] ASoC: Davinci: machine: Add device tree binding
On Mon, Aug 27, 2012 at 06:56:43PM +0530, Hebbar, Gururaja wrote: Device tree support for tlv320aic3x CODEC driver Not really for the CODEC - this is a machine driver. +- dai-data : A list of DAI data used by SOC code to register + DAI, Codecs platform. + The string index should be as shown below. +dai-data = +DAI Name,DAI Stream Name, +CODEC DAI Name, true if evm_aic3x_init is required, else false, +evm ops required (evm_ops or evm_spdif_ops); What do these different ops do - how would the user figure it out or if they're needed at all? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/5] ASoC: Davinci: pcm: Add device tree bindings
On Wed, Aug 22, 2012 at 01:50:09PM +, Hebbar, Gururaja wrote: From your for-3.7 branch, I could only find such implementation in Tegra Platform. Most Freescale platforms implements this through a device/driver method. Exception being sound/soc/mxs/mxs-pcm.c So should I follow tegra implementation? Tegra and mxs should be good examples, yes. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/5] ASoC: Davinci: pcm: Add device tree bindings
On Tue, Aug 14, 2012 at 06:12:03PM +0530, Hebbar, Gururaja wrote: Device tree support for Davinci/OMAP2+ pcm driver. This looks like it's a device which maps a shared DMA controller in the SoC core into ASoC rather than actual hardware. Such devices are usually instantiated automatically from the DAI rather than being represented in the device tree since they are a Linux internal thing really - the Tegra and Freescale drivers provide examples of how this sort of thing can be done. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/5] ASoC/ARM: Davinci: McASP: split asp header into platform and audio specific
On Tue, Aug 14, 2012 at 06:12:01PM +0530, Hebbar, Gururaja wrote: Davinci McASP header driver are shared by few OMAP platforms (like TI81xx, AM335x). Splitting asp header into Davinci platform specific header and Audio specific header helps to share them across platforms. This doesn't apply against v3.6-rc2, I suspect there's overlapping changes in arch/arm. I was just going to apply it on a separate branch to allow cross-tree merge if there's overlap with architecture work. Can you please check and resend? signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/5] ASoC: Davinci: McASP: add device tree support for McASP
On Tue, Aug 14, 2012 at 06:12:02PM +0530, Hebbar, Gururaja wrote: +- op-mode : I2S/DIT ops mode. This would normally be part of the machine binding since it needs to be applied to both ends of the link. When adding it could you come up with a generic binding for this in terms of the current ASoC DAI paremeters please? That way we'll be able to have other machine drivers be consistent with this one. +- tdm-slots : Slots for TDM operation. This would normally also be a machine driver thing though it's less normal to need to configure this on both ends. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 4/5] ASoC: Davinci: machine: Add device tree binding
On Tue, Aug 14, 2012 at 06:12:04PM +0530, Hebbar, Gururaja wrote: +- ti,codec-clock : The Codec Clock from the board I think this is the clock rate? Please specify it more specifically. +CODEC DAI Name, true if evm_aic3x_init is required, else false, +evm ops required, evm_ops or evm_spdif_ops; Please be more specific as to what these actually do - consider the user who is reading the bindings with a view to implementing them for their board, or writing drivers for another OS. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 5/5] ASoC: tlv320aic3x: Add device tree bindings
On Tue, Aug 14, 2012 at 06:12:05PM +0530, Hebbar, Gururaja wrote: +- gpio-reset - int - gpio pin number used for codec reset This should be a standard DT GPIO reference by phandle like: gpio = gpio1 16 0; There's quite a few examples in tree. Otherwise this looks good. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ASoC: Davinci: McASP: remove unused header include
On Wed, Aug 08, 2012 at 08:40:30PM +0530, Hebbar, Gururaja wrote: Defines or parameters from mach/mux.h isn't used anywhere. Hence remove the header include. Applied all, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: How to handle parameter variation across different boards but same platform
On Thu, Jul 05, 2012 at 08:32:16AM +, Arnd Bergmann wrote: On Thursday 05 July 2012, Vaibhav Hiremath wrote: Does machine ID still gets set? May be I am missing something... No, it doesn't. This is a *really* unfortunate decision, BTW - it means that if your bootloader has a device tree available it needs to know if the kernel it's booting is DT or non-DT which is just generally unhelpful. Sadly I don't hold out much hope of being able to fix it, though. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: How to handle parameter variation across different boards but same platform
On Wed, Jul 04, 2012 at 02:17:48PM +, Hebbar, Gururaja wrote: On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote: If these are totally different boards they should have different machine IDs set so machine_is_() should identify. If that isn't there then you need to do something custom to your products to identify the boards further. They are different boards with same SoC (AM33xx). So they both are true for machine_is_am33xx(). That's not how this stuff is supposed to work - machine is the board, you should have cpu_is_() for identifying the SoC. We have a means to detect the type of board but in arch/arm/mach-omap2/ board file. However, I believe it is not recommended to call boards api inside drivers. Only for generic drivers, board specific drivers are obviously board specific. The point is that you shouldn't make something that could run on many boards depend on an API specific to a particular board. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V3 1/1] ASoC: tlv320aic3x: Fix codec pll configure bug
On Tue, Jun 26, 2012 at 07:25:11PM +0530, Hebbar, Gururaja wrote: In sound/soc/codecs/tlv320aic3x.c data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG); snd_soc_write(codec, AIC3X_PLL_PROGA_REG, data | (pll_p PLLP_SHIFT)); Applied, thanks. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH V2] ASoC: tlv320aic3x: Fix codec pll configure bug
On Tue, Jun 26, 2012 at 11:33:43AM +0530, Hebbar, Gururaja wrote: In sound/soc/codecs/tlv320aic3x.c data = snd_soc_read(codec, AIC3X_PLL_PROGA_REG); snd_soc_write(codec, AIC3X_PLL_PROGA_REG, data | (pll_p PLLP_SHIFT)); In the above code, pll-p value is OR'ed with previous value without clearing it. Bug is not seen if pll-p value doesn't change across Sampling frequency. A better fix is to change the code to use snd_soc_update_bits() rather than open code it. This is more idiomatic and will suppress writes if they don't change anything. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND PATCH] davinci: CQ93VC: remove machine specific header file inclusion from codec driver
On Wed, Feb 08, 2012 at 12:41:14PM +, Hadli, Manjunath wrote: On Wed, Jan 11, 2012 at 00:17:41, Mark Brown wrote: Fix your mailer, not only is it not word wrapping within paragraphs it's adding such problems to quoted text. Applied but please do try to use a subject line appropriate for the subsystem you're contributing to. I still can't find this patch in the mainline, any issues? It will go into mainline in the next merge window. signature.asc Description: Digital signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RESEND PATCH] davinci: CQ93VC: remove machine specific header file inclusion from codec driver
On Tue, Jan 10, 2012 at 04:57:43PM +0530, Manjunath Hadli wrote: remove unnecessary inclusion of machine specific header file mach/dm365.h from cq93vc.c voice codec driver which comes in the way of platform code consolidation. Applied but please do try to use a subject line appropriate for the subsystem you're contributing to. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v8 2/2] davinci: CQ93VC: remove machine specific header file inclusion from codec driver
On Wed, Jan 04, 2012 at 12:47:49PM +0530, Manjunath Hadli wrote: remove unnecessary inclusion of machine specific header file mach/dm365.h from cq93vc.c voice codec driver which comes in the way of platform code consolidation. *Always* CC maintainers on patches. If you send me a copy directly this looks OK. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC 2/3] ASoC: davinci-pcm: add cpu-dai health callbacks
On Mon, Oct 03, 2011 at 10:05:45PM -0400, Ben Gardiner wrote: From your other email I see now that the intended behaviour can be accomplished entirely in the application. Returning _POS_XRUN should be sufficient here in ASoC. OK, great - I was worried this might get complicated but if the drivers can just punt the decision to userspace that makes life much easier. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC 2/3] ASoC: davinci-pcm: add cpu-dai health callbacks
On Fri, Sep 30, 2011 at 05:23:02PM -0400, Ben Gardiner wrote: The CPU DAIs available to the davinci-pcm driver have the capability of detecting and reporting errors. Add callbacks to the struct davinci_pcm_dma_params passed to davinci-pcm from the CPU DAI. This looks like something we should be doing at the subsystem level, the DaVinci is far from unique in having the ability to detect errors at the DAI level. This has several shortcomings: 1) It bubbles up to the user as underruns, not a fatal error -- some may prefer the former, I realize but the latter is more attractive to me. Same problem as with the previous patch in this series. Why do you prefer a fatal error, and how do you distinguish a fatal error from a glitch? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ASoC: davinci-pcm: trivial: replace link with actual chan/link
On Fri, Sep 09, 2011 at 05:06:05PM -0400, Ben Gardiner wrote: The ambiguously named variable 'link' is used as a temporary throughout davinci-pcm -- its presence makes grepping (and groking) the code difficult. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ASoC: davinci-mcasp: add support for unsigned PCM formats
On Fri, Aug 26, 2011 at 12:02:44PM -0400, Ben Gardiner wrote:
Although the McASP supports sign-extending samples in RX or TX [1]; the
davinci-mcasp driver does not touch the {R,X}PBIT or {R,X}PAD field of the
{R,X}FMT registers meaning that the McASP will serialize the bytes it is given
regardless of their signedness. So supporting unsigned formats is as simple
as adding them to the metadata of the davinci-mcasp driver.
Applied, thanks.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] ASoC: davinci: fix codec start and stop functions
On Wed, Jul 20, 2011 at 05:36:04PM +0530, Rajashekhara, Sudhakar wrote: According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/2] ASoC: davinci: add missing break statement
On Wed, Jul 20, 2011 at 05:37:18PM +0530, Rajashekhara, Sudhakar wrote: In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/6] ASoC: davinci-pcm: some fixes and convert to BATCH
On Tue, May 24, 2011 at 02:50:14PM -0400, Ben Gardiner wrote: This patchset is a collection of changes for the davinci-pcm driver that were accumulated during previous forays into the davinci-mcasp and davinci-pcm drivers [1]. Applied all, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ASoC: davinci-pcm: comments for the conversion to BATCH mode
On Wed, May 25, 2011 at 09:27:22AM -0400, Ben Gardiner wrote: In the previous commit 'ASoC: davinci-pcm: convert to BATCH mode', the phase offset of 2 was mentioned in the commit message but not well commented in the source. Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] ASoC: davinci-mcasp: enable ping-pong SRAM buffers
On Wed, May 18, 2011 at 09:27:45AM -0400, Ben Gardiner wrote: The davinci-i2s driver copies the platform data for playback and capture sram sizes which is in turn used by davinci-pcm to allocate ping-pong buffers. Copy also the platform data in davinci-mcasp probe. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] davinci: da850evm: enable mcasp ping-pong bufs and evq's
On Wed, May 18, 2011 at 09:27:46AM -0400, Ben Gardiner wrote: The davinci-mcasp driver will copy the platform data specified sram sizes and eventq's. Set the event queues and sram sizes for da850. 8K SRAM buffers are selected because it is the minimum that resulted in the same period size when testing 48KHz S16_LE stereo. Event queues 0 and 1 are assigned to match those specified by Troy Kisky in his introduction of ping-pong buffers for dm644x. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca Davinci folks, are you OK with this? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [linux-pm] pm loss development
On Wed, May 18, 2011 at 09:43:13PM +0200, Rafael J. Wysocki wrote: On Wednesday, May 18, 2011, mark gross wrote: I need to get more details on this but I assume its a state where the meta data of the file system is committed to the emmc before lights go off such that when power is reapplied that the damage isn't too big. I don't think you can guarantee that the metadata won't be damaged without notifying the filesystem of the event (and making it react appropriately). I guess with a journalling filesystem you'd hope that you can at any point write out what's in flight and have it be safe; if it's a non journalling filesystem of course all bets are off. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 01/11] mfd: add pruss mfd driver.
On Fri, May 13, 2011 at 04:25:56PM +0530, Subhasish Ghosh wrote: Instead, maybe you can simply call platform_device_register at that stage to create the children and not use MFD at all. Samuel, can you comment on this as well? Do you still see pruss as an MFD driver when the uses are completely dynamic and determined by the firmware loaded into it? But in that case, where do I fit my driver. It's a microcontroller inside of a processor, guess that's unique for Linux. It's not that unusual in hardware terms, really. There's an awful lot of this going on in the audio area especially at the minute so there's going to be some effort around providing some framework support for this which should have some general usability but that's not there yet. Will a misc device be a better choice. In that case I can remove the MFD cell from the board_file and add an array of platform_device for the UART CAN. I think that for me so long as it can simultaneously do two unrelated functions which need to be arbitrated between there's probably a place for it in MFD, certainly at the minute. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
