Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block

[Padma Venkat]

Hi Vivek,

On 1/13/15, Vivek Gautam  wrote:
> Hi Padma,
>
>
> On Fri, Dec 19, 2014 at 6:53 PM, Padmavathi Venna 
> wrote:
>> Add required clk support for I2S,PCM amd SPDIF
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>
> verified from Exynos7 datasheet. The patch looks good.
> Reviewed-by: Vivek Gautam 
>

Thanks for the review.

Hi Sylwester,

I posted patches after re-basing on your tree and after incorporating
all comments from Vivek.
Below is the link
http://www.spinics.net/lists/linux-samsung-soc/msg40992.html

Can you pick the patches?

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block

[Padma Venkat]

Hi Sylwester,

On 12/22/14, Sylwester Nawrocki  wrote:
> Hi,
>
> On 19/12/14 14:23, Padmavathi Venna wrote:
>> Add required clk support for I2S,PCM amd SPDIF
>
> There is a non-trivial conflict with the MSCL CMU patch, could you
> please resend rebased onto my exynos7 branch:

Ok. I willl rebase the patch on your tree.

>
> git://linuxtv.org/snawrocki/samsung.git for-v3.20/clk/exynos7 ?
>
> Is exynos7420 documentation applicable to this ?

This is applicable only for exynos7.

> Would be nice to have someone else who has access to the SoC
> documentation replied with a Reviewed-by tag.
>
> --
> Thanks,
> Sylwester

Thanks
Padma
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] clk: samsung: exynos7: add clocks for SPI block

[Padma Venkat]

Hi ViVek,

On 1/9/15, Vivek Gautam  wrote:
> On Fri, Jan 9, 2015 at 5:18 PM, Vivek Gautam 
> wrote:
>> Hi Padma,
>>
>>
>> On Fri, Dec 19, 2014 at 6:53 PM, Padmavathi Venna 
>> wrote:
>>> Add clock support for 5 SPI channels.
>>>
>>> Signed-off-by: Padmavathi Venna 
>>> ---

[snip]

>> Same here for SCLK_SPI5, unused in the patch.

ok.

>>
>> [snip]
>>
>> The rest all looks good in this patch. I have also verified from the
>> Exynos7 UM.
>
> missed it earlier. You may also want to add update documentation for
> clock sources
> of peric1 block.

I will add the required source clks.
Thanks for the review.

Padma
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH/RFC 00/14] ASoC: samsung: Add clk provider for I2S internal clocks

[Padma Venkat]

Hi Sylwester,

> I need some more thought about interaction between the clk API calls on the
> clocks being exposed and the ASoC calls into sound/soc/samsung/i2s.c.
> I'm sending teh patches for review though to avoid any waste of time should
> it turn out the direction taken is wrong.
>
> This whole series definitely needs more testing, so far I only tested it
> on Odroid X2, with the I2S working in slave mode.

your patches looks good to me. I did basic playback and capture test
of your patches with i2s in master mode on exynos7.  I also added
secondary dai for testing and verified playback. But I think some more
testing required to check the serialization of registers. Tried aplay
with front dai in background and with secondary dai in the foreground.
But due to one issue on my system backend playback not working.

Thanks
Padma

>
> [1]
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081753.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: samsung: i2s: Add missing assignment of variant_regs

[Padma Venkat]

Hi,

On 12/9/14, Mark Brown  wrote:
> On Mon, Dec 08, 2014 at 06:45:54PM +0100, Sylwester Nawrocki wrote:
>
>> Add assignment of the variant_regs field which is missing in commit
>> a5a56871f804edac93a53b5e871c0e9818fb9033 ("ASoC: samsung: add support
>> for exynos7 I2S controller"). Without this attempting to probe the
>> secondary DAI fails with an error like:
>
> Applied, thanks.  Broader testing of changes before sending them
> upstream would be good...
>

I am really sorry for introducing so many crashes in the driver. Next
time will take care of testing all possible cases.

Thanks for the support
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback

[Padma Venkat]

Hi Lars,

[snip]
>>> +
>>> +   ret = dma_cookie_status(chan, cookie, txstate);
>>> +   if (ret == DMA_COMPLETE || !txstate)
>>> +   return ret;
>>> +
>>> +   used = txstate->used;
>>> +
>>> +   spin_lock_irqsave(&pch->lock, flags);
>>> +   sar = readl(regs + SA(thrd->id));
>>> +   dar = readl(regs + DA(thrd->id));
>>> +
>>> +   list_for_each_entry(desc, &pch->work_list, node) {
>>> +   if (desc->status == BUSY) {
>>> +   current_c = desc->txd.cookie;
>>> +   if (first) {
>>> +   first_c = desc->txd.cookie;
>>> +   first = false;
>>> +   }
>>> +
>>> +   if (first_c < current_c)
>>> +   residue += desc->px.bytes;
>>> +   else {
>>> +   if (desc->rqcfg.src_inc && 
>>> pl330_src_addr_in_desc(desc, sar)) {
>>> +   residue += desc->px.bytes;
>>> +   residue -= sar - desc->px.src_addr;
>>> +   } else if (desc->rqcfg.dst_inc && 
>>> pl330_dst_addr_in_desc(desc, dar))
>>> {
>>> +   residue += desc->px.bytes;
>>> +   residue -= dar - desc->px.dst_addr;
>>> +   }
>>> +   }
>>> +   } else if (desc->status == PREP)
>>> +   residue += desc->px.bytes;
>>> +
>>> +   if (desc->txd.cookie == used)
>>> +   break;
>>> +   }
>>> +   spin_unlock_irqrestore(&pch->lock, flags);
>>> +   dma_set_residue(txstate, residue);
>>> +   return ret;
>>>   }
[snip]
>>
>> Any comment on this patch?
>
> Well it doesn't break audio, but I don't think it has the correct haviour
> for all cases yet.

OK. Any way of testing other cases like scatter-gather and memcopy.  I
verified memcopy in dmatest but it seems not doing anything with
residue bytes.

>
> Again, the semantics are that it should return the progress of the transfer
>
> for which the allocation function returned the cookie that is passe to this

May be my understanding is wrong. For clarification..In the
snd_dmaengine_pcm_pointer it is subtracting the residue bytes from the
total buffer bytes not from period bytes. So how it expects
the progress of the transfer of the passed cookie which just holds period bytes?

>
> function. You have to consider that there might be multiple different
> descriptors submitted and in the work list, not just the one we want to know

Even though there are multiple descriptors in the work list, at a time
only two descriptors are in busy state(as per the documentation in the
driver) and all the descriptors cookie number is in incremental order.
Not sure for other cases how it will be.

>
> the status of. The big problem with the pl330 driver is that the current
> structure of the driver makes it not so easy to implement the residue
> reporting correctly.
>
> - Lars

Thanks
Padma
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dmaengine: pl330: Set residue in tx_status callback

[Padma Venkat]

Hi Vinod/Lars,

On 11/26/14, Padmavathi Venna  wrote:
> Fill txstate.residue with the amount of bytes remaining in the current
> transfer if the transfer is not complete.  This will be of particular
> use to i2s DMA transfers, providing more accurate hw_ptr values to ASoC.
>
> I had taken the code from Dylan Reid  patch from the
> below link and modified according to the current dmaengine framework.
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/23007
>
> Cc: Dylan Reid 
> Signed-off-by: Padmavathi Venna 
> ---
>
> This patch has been tested for audio playback on exynos5420 peach-pit.
>
>  drivers/dma/pl330.c |   67
> +-
>  1 files changed, 65 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index b7493d2..db880ae 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2182,11 +2182,74 @@ static void pl330_free_chan_resources(struct
> dma_chan *chan)
>   pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
>  }
>
> +static inline int
> +pl330_src_addr_in_desc(struct dma_pl330_desc *desc, unsigned int sar)
> +{
> + return ((desc->px.src_addr <= sar) &&
> + (sar <= (desc->px.src_addr + desc->px.bytes)));
> +}
> +
> +static inline int
> +pl330_dst_addr_in_desc(struct dma_pl330_desc *desc, unsigned int dar)
> +{
> + return ((desc->px.dst_addr <= dar) &&
> + (dar <= (desc->px.dst_addr + desc->px.bytes)));
> +}
> +
>  static enum dma_status
>  pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>struct dma_tx_state *txstate)
>  {
> - return dma_cookie_status(chan, cookie, txstate);
> + dma_addr_t sar, dar;
> + struct dma_pl330_chan *pch = to_pchan(chan);
> + void __iomem *regs = pch->dmac->base;
> + struct pl330_thread *thrd = pch->thread;
> + struct dma_pl330_desc *desc;
> + unsigned int residue = 0;
> + unsigned long flags;
> + bool first = true;
> + dma_cookie_t first_c, current_c;
> + dma_cookie_t used;
> + enum dma_status ret;
> +
> + ret = dma_cookie_status(chan, cookie, txstate);
> + if (ret == DMA_COMPLETE || !txstate)
> + return ret;
> +
> + used = txstate->used;
> +
> + spin_lock_irqsave(&pch->lock, flags);
> + sar = readl(regs + SA(thrd->id));
> + dar = readl(regs + DA(thrd->id));
> +
> + list_for_each_entry(desc, &pch->work_list, node) {
> + if (desc->status == BUSY) {
> + current_c = desc->txd.cookie;
> + if (first) {
> + first_c = desc->txd.cookie;
> + first = false;
> + }
> +
> + if (first_c < current_c)
> + residue += desc->px.bytes;
> + else {
> + if (desc->rqcfg.src_inc && 
> pl330_src_addr_in_desc(desc, sar)) {
> + residue += desc->px.bytes;
> + residue -= sar - desc->px.src_addr;
> + } else if (desc->rqcfg.dst_inc && 
> pl330_dst_addr_in_desc(desc, dar)) {
> + residue += desc->px.bytes;
> + residue -= dar - desc->px.dst_addr;
> + }
> + }
> + } else if (desc->status == PREP)
> + residue += desc->px.bytes;
> +
> + if (desc->txd.cookie == used)
> + break;
> + }
> + spin_unlock_irqrestore(&pch->lock, flags);
> + dma_set_residue(txstate, residue);
> + return ret;
>  }
>
>  static void pl330_issue_pending(struct dma_chan *chan)
> @@ -2631,7 +2694,7 @@ static int pl330_dma_device_slave_caps(struct dma_chan
> *dchan,
>   caps->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
>   caps->cmd_pause = false;
>   caps->cmd_terminate = true;
> - caps->residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> + caps->residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
>
>   return 0;
>  }

Any comment on this patch?

Thanks
Padma
> --
> 1.7.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

[Padma Venkat]

Hi Mark,

>>> OK. I don't have provision to test on this board. I will try to test
>>> on older boards by disabling manual mode.
>>>
>>
>> I tested on exynos5420 peach-pit by enabling auto mode. I used dd
>> command to read 1MB data from spi flash and I compared the result with
>> manual mode. Both are same.
>
> I also tested this patch with Javier Martinez Canillas patches for
> enabling spidev nodes from
> http://www.spinics.net/lists/linux-samsung-soc/msg39057.html.
>
> I read 4MB flashdata from spi by enabling auto mode and compared the
> result. They look same.

Do want some extra tests need to be done for this patch or is it okey?

>
>>
>>> Thanks
>>> padma
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

[Padma Venkat]

Hi Mark,

 CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
 in CS_CFG. When it is auto CS automatically toggles between packet to
 packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
 driver by default uses manual mode. But on exynos7 the manual mode is
 removed.
>>>
>>> OK, but what's a packet here?
>>
>> Packet is either 1 byte or 4 bytes size depends on width of the SPI
>> channel.
>>
>>>
 I tested the driver with wm5110 codec.
>>>
>>> Did you try firmware downloads or something else that generates multiple
>>> transfers in a message?  Normal register writes will use a single
>>> transfer so I'd expect them to just work.
>>>
>>
>> OK. I don't have provision to test on this board. I will try to test
>> on older boards by disabling manual mode.
>>
>
> I tested on exynos5420 peach-pit by enabling auto mode. I used dd
> command to read 1MB data from spi flash and I compared the result with
> manual mode. Both are same.

I also tested this patch with Javier Martinez Canillas patches for
enabling spidev nodes from
http://www.spinics.net/lists/linux-samsung-soc/msg39057.html.

I read 4MB flashdata from spi by enabling auto mode and compared the
result. They look same.

>
>> Thanks
>> padma
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

[Padma Venkat]

Hi Sylwester,

On 11/20/14, Sylwester Nawrocki  wrote:
> Hi,
>
> On 20/11/14 08:04, Padma Venkat wrote:
>>> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
>>> > index 947352d..8db8c66 100644
>>> > --- a/sound/soc/samsung/i2s.c
>>> > +++ b/sound/soc/samsung/i2s.c
>>> > @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
>>> >   if (dir == SND_SOC_CLOCK_IN)
>>> >   mod |= 1 << i2s_regs->cdclkcon_off;
>>> >   else
>>> > - mod &= 0 << i2s_regs->cdclkcon_off;
>>> > + mod &= ~(1 << i2s_regs->cdclkcon_off);
>>
>> Thanks for pointing this. In my local machine it was properly done but
>> while rebasing on linux-next I did some mistake. There is one more
>> place in set_sysclk which need to be corrected here
>> mod &= 0 << i2s_regs->rclksrc_off
>> can you include this change also in your patch or should I post a new
>> patch for all?
>
> OK, I'll also correct this and resend the patch.

As I found one more break statement missing. So posted a new patch
with all corrected code with your signed-off. Please do review of the
same.

Thanks for you support.
Padma

>
> --
> Regards,
> Sylwester
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND ope

[Padma Venkat]

Hi,

On 11/20/14, Padmavathi Venna  wrote:
> Cc: Sylwester Nawrocki 
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Padmavathi Venna 
> ---
>  sound/soc/samsung/i2s.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 0df6547..e1ace52 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
>   if (dir == SND_SOC_CLOCK_IN)
>   mod |= 1 << i2s_regs->cdclkcon_off;
>   else
> - mod &= 0 << i2s_regs->cdclkcon_off;
> + mod &= ~(1 << i2s_regs->cdclkcon_off);
>
>   i2s->rfs = rfs;
>   break;
> @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
>   }
>
>   if (clk_id == 0)
> - mod &= 0 << i2s_regs->rclksrc_off;
> + mod &= ~(1 << i2s_regs->rclksrc_off);
>   else
>   mod |= 1 << i2s_regs->rclksrc_off;
>
> + break;
>   default:
>   dev_err(&i2s->pdev->dev, "We don't serve that!\n");
>   return -EINVAL;
> --
> 1.7.4.4
>

Please ignore this patch as subject line is not proper.

Thanks
Padma
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

[Padma Venkat]

Hi Sylwester,

On 11/19/14, Sylwester Nawrocki  wrote:
> In the i2s_set_sysclk() callback we are currently clearing all bits
> of the IISMOD register when clk_id is SAMSUNG_I2S_CDCLK and dir
> is SND_SOC_CLOCK_OUT. It's due to an incorrect mask used for the AND
> operation and breaks the I2S interface operation when we attempt to
> use the CDCLK output clock.
>
> It fixes commit a5a56871f804edac93a53b5e871c0e9818fb9033
> ("ASoC: samsung: add support for exynos7 I2S controller") and restores
> sound support for Odroid X2/U3.
>
> Cc: Padmavathi Venna 
> Signed-off-by: Sylwester Nawrocki 
> ---
>  sound/soc/samsung/i2s.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 947352d..8db8c66 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
>   if (dir == SND_SOC_CLOCK_IN)
>   mod |= 1 << i2s_regs->cdclkcon_off;
>   else
> - mod &= 0 << i2s_regs->cdclkcon_off;
> + mod &= ~(1 << i2s_regs->cdclkcon_off);

Thanks for pointing this. In my local machine it was properly done but
while rebasing on linux-next I did some mistake. There is one more
place in set_sysclk which need to be corrected here
mod &= 0 << i2s_regs->rclksrc_off
can you include this change also in your patch or should I post a new
patch for all?

Thanks
Padma

>   i2s->rfs = rfs;
>   break;
> --
> 1.7.9.5
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

[Padma Venkat]

Hi Mark,

On 11/10/14, Padma Venkat  wrote:
> Hi Mark,
>
> On 11/7/14, Mark Brown  wrote:
>> On Fri, Nov 07, 2014 at 02:01:57PM +0530, Padma Venkat wrote:
>>
>>> CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
>>> in CS_CFG. When it is auto CS automatically toggles between packet to
>>> packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
>>> driver by default uses manual mode. But on exynos7 the manual mode is
>>> removed.
>>
>> OK, but what's a packet here?
>
> Packet is either 1 byte or 4 bytes size depends on width of the SPI
> channel.
>
>>
>>> I tested the driver with wm5110 codec.
>>
>> Did you try firmware downloads or something else that generates multiple
>> transfers in a message?  Normal register writes will use a single
>> transfer so I'd expect them to just work.
>>
>
> OK. I don't have provision to test on this board. I will try to test
> on older boards by disabling manual mode.
>

I tested on exynos5420 peach-pit by enabling auto mode. I used dd
command to read 1MB data from spi flash and I compared the result with
manual mode. Both are same.

> Thanks
> padma
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

[Padma Venkat]

Hi Mark,

On 11/7/14, Mark Brown  wrote:
> On Fri, Nov 07, 2014 at 02:01:57PM +0530, Padma Venkat wrote:
>
>> CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
>> in CS_CFG. When it is auto CS automatically toggles between packet to
>> packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
>> driver by default uses manual mode. But on exynos7 the manual mode is
>> removed.
>
> OK, but what's a packet here?

Packet is either 1 byte or 4 bytes size depends on width of the SPI channel.

>
>> I tested the driver with wm5110 codec.
>
> Did you try firmware downloads or something else that generates multiple
> transfers in a message?  Normal register writes will use a single
> transfer so I'd expect them to just work.
>

OK. I don't have provision to test on this board. I will try to test
on older boards by disabling manual mode.

Thanks
padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: s3c64xx: add support for exynos7 SPI controller

[Padma Venkat]

Hi Mark,

CCing Kukjin Kim.

On 11/6/14, Mark Brown  wrote:
> On Thu, Nov 06, 2014 at 03:21:49PM +0530, Padmavathi Venna wrote:
>> Exynos7 SPI controller supports only the auto Selection of
>> CS toggle mode and Exynos7 SoC includes six SPI controllers.
>> Add support for these changes in Exynos7 SPI controller driver.
>
> Could you give a bit more detail on what the "auto selection of CS
> toggle mode" is - in the diff it looks like it's not an existing mode.
> I'm a bit worried that it's not going to function well with devices that
> send more than one transfer per message.

There is a bit AUTO_N_MANUAL(as per manual) in the spi CS_CFG
register(as per manual, in the driver it is S3C64XX_SPI_SLAVE_SEL) to
control the CS toggle mode either manually or automatically. If CS has
to be controlled manually the AUTO_N_MANUAL should be set to 0 which
the driver is doing in the s3c64xx_spi_transfer_one function by
writing 0 in the S3C64XX_SPI_SLAVE_SEL. When it is handled manually
NSSOUT as per the manual(in the driver it is
S3C64XX_SPI_SLAVE_SIG_INACT) controls the level of CS which when set
deactivates the signal and reset activates.

CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
in CS_CFG. When it is auto CS automatically toggles between packet to
packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
driver by default uses manual mode. But on exynos7 the manual mode is
removed.

I tested the driver with wm5110 codec.

>
>> Signed-off-by: Padmavathi Venna 
>
> It's better if your signoff is using the same e-maill address as

ok.  I will take care of this.

>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Mon, Dec 9, 2013 at 11:00 PM, Mark Brown  wrote:
> On Fri, Dec 06, 2013 at 10:44:19AM +0530, Padma Venkat wrote:
>
>> I couldn't test this patch set due to some crash in recent kernel in
>> dmaengine_unmap_put. I think this unmap support is not yet implemented
>> for pl330 driver. It is mentioned in the commit "dmaengine: prepare
>> for generic 'unmap' data", [bzolnier: prepare pl330 driver for adding
>> missing unmap while at it].
>
> This is unfortunate...  I'd suggest trying mainline but I see it's
> broken in Linus' tree too and no fixes in -next. :(
>
> I'm tempted to push up with your Tested-by a note saying you did your
> testing on an earlier version but weren't able to test due to other bugs.

I managed to test your latest version of these patches(posted on
Dec6th) on earlier version of linux-samsung tree. May be you can push
up these patches with my Tested-by.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Thu, Dec 5, 2013 at 5:15 PM, Mark Brown  wrote:
> On Thu, Dec 05, 2013 at 04:20:03PM +0530, Padma Venkat wrote:
>> On Thu, Nov 28, 2013 at 5:23 PM, Mark Brown  wrote:
>
>> > OK, so we can probably just reinitialise the dmaengine data after we
>> > reset it?  Like below
>
>> Yes. That works well.
>
> Great.
>
>> As I forgot to add SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag, I was
>> getting underrun error. After adding this flag audio playback is
>> working fine for smaller files on smdk5420 with pl330 dma driver.
>
> OK, there were some patches on the thread adding residue support to the
> PL330 driver yesterday - hopefully those can get merged at some point
>
>> Except for the crash due to NULL pointer dereference in secondary
>> dai(I posted a patch for the same (ASoC: samsung: Initialize the
>> dma_data for secondary dai)) you can add my
>
>> Tested By: Padmavathi Venna 
>
> Excellent, thanks - I'd squashed in your change already.  Like I say I'm
> still concerned that we might need a fix for v3.13 since I can't
> entirely see why the code works as-is.

Here two things
1)crash due to null pointer reference during boot which got fixed by
initializing the secondary dai.
 This crash was not there in mainline because the channel request
happening at runtime and with dmaengine the channel request happening
at boot time. But if some one try to play audio with secondary device
then at run time this crash might happen.
2) overwritting of dma_size during hw_params
This is not required in mainline because pointer to the whole
s3c_dma_params were being passed as dma_data which has dma_size init.
But with dmaengine we are just passing the pointer to
snd_dmaengine_dai_dma_data which is embedded in s3c_dma_params and
dma_size is outside.


I think this is what you are concern about why it is not working as-is.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init

[Padma Venkat]

Hi Mark,

On Mon, Dec 9, 2013 at 5:30 PM, Padma Venkat  wrote:
> Hi Mark,
>
> On Fri, Dec 6, 2013 at 4:57 PM, Mark Brown  wrote:
>> On Fri, Dec 06, 2013 at 10:44:33AM +0530, Padma Venkat wrote:
>>
>>> This is done in your earlier patch " ASoC: samsung: Ensure DMA data is
>>> initialised for secondary DAI ". Was it done on purpose or by mistake
>>> in this patch?
>>
>> It's intentional - notice that the function has changed, this is why I
>> kept asking you about mainline.  Mainline doesn't have the wrapper
>> function that abstracts the difference between s3c-dma and dmaengine,
>> this is why I'm saying these two will need to be rebased on top of the
>> mainline fix.
>
> Ok. I didn't notice the function name. Then this commit is not
> required in the mainline.
> This is required only after your changes because in dmaengine we are
> requesting the dma channel statically but in mainline(with samsung
> proprietary ops) we are requesting the dma channel at run time during
> playback or capture.

sorry for the mix-up. I think we need to set the dma data for the
secondary dai even in mainline.

>
>>
>>> I think you also told to include a patch for reinitialization of the
>>> dma_data in i2s_hw_params. If you are in the process of debugging some
>>> bug as you mentioned earlier you can ignore this comment. Otherwise it
>>> is just a reminder.
>>
>> Hrm, forgot to commit that bit.
>
> Thanks
> Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init

[Padma Venkat]

Hi Mark,

On Fri, Dec 6, 2013 at 4:57 PM, Mark Brown  wrote:
> On Fri, Dec 06, 2013 at 10:44:33AM +0530, Padma Venkat wrote:
>
>> This is done in your earlier patch " ASoC: samsung: Ensure DMA data is
>> initialised for secondary DAI ". Was it done on purpose or by mistake
>> in this patch?
>
> It's intentional - notice that the function has changed, this is why I
> kept asking you about mainline.  Mainline doesn't have the wrapper
> function that abstracts the difference between s3c-dma and dmaengine,
> this is why I'm saying these two will need to be rebased on top of the
> mainline fix.

Ok. I didn't notice the function name. Then this commit is not
required in the mainline.
This is required only after your changes because in dmaengine we are
requesting the dma channel statically but in mainline(with samsung
proprietary ops) we are requesting the dma channel at run time during
playback or capture.

>
>> I think you also told to include a patch for reinitialization of the
>> dma_data in i2s_hw_params. If you are in the process of debugging some
>> bug as you mentioned earlier you can ignore this comment. Otherwise it
>> is just a reminder.
>
> Hrm, forgot to commit that bit.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Thu, Dec 5, 2013 at 7:55 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> Since all Exynos platforms have been converted to dmaengine and many of
> the older platforms are in the process of conversion they do not need to
> use the legacy s3c-dma APIs for DMA but can instead use the standard ASoC
> dmaengine helpers. This both allows them to benefit from improvements
> implemented in the generic code and supports multiplatform.
>
> This patch includes some fixes from Padma for Exynos SoCs.
>
> Signed-off-by: Mark Brown 
> Tested By: Padmavathi Venna 
> ---
>
> I think this should reflect all your testing but a recheck would be good.

I couldn't test this patch set due to some crash in recent kernel in
dmaengine_unmap_put. I think this unmap support is not yet implemented
for pl330 driver. It is mentioned in the commit "dmaengine: prepare
for generic 'unmap' data", [bzolnier: prepare pl330 driver for adding
missing unmap while at it].


[snip]

> +
> +int samsung_asoc_dma_platform_register(struct device *dev)
> +{
> +   return snd_dmaengine_pcm_register(dev, &samsung_dmaengine_pcm_config,
> + 
> SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME |
> + SND_DMAENGINE_PCM_NO_RESIDUE |

This flag should be SND_DMAENGINE_PCM_FLAG_NO_RESIDUE.

> + SND_DMAENGINE_PCM_FLAG_COMPAT);
> +}
> +EXPORT_SYMBOL_GPL(samsung_asoc_dma_platform_register);
> +

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init

[Padma Venkat]

Hi Mark,

On Thu, Dec 5, 2013 at 7:55 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> In preparation for using the dmaengine helpers in ASoC rather than the
> dmaengine wrappers for the Samsung API wrap the configuration of dma_data.
> The dmaengine code expects different data to that used by the legacy API.
>
> Signed-off-by: Mark Brown 
> ---
>
> This will need merging with the fix patch I sent earlier, I'l do that
> assuming this is OK.
>

[snip]

> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index a5cbdb4f1655..eab0050d4579 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -946,8 +946,11 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
> struct i2s_dai *i2s = to_info(dai);
> struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai;
>
> -   if (other && other->clk) /* If this is probe on secondary */
> +   if (other && other->clk) { /* If this is probe on secondary */
> +   samsung_asoc_init_dma_data(dai, &other->sec_dai->dma_playback,
> +  NULL);
> goto probe_exit;
> +   }

This is done in your earlier patch " ASoC: samsung: Ensure DMA data is
initialised for secondary DAI ". Was it done on purpose or by mistake
in this patch?

I think you also told to include a patch for reinitialization of the
dma_data in i2s_hw_params. If you are in the process of debugging some
bug as you mentioned earlier you can ignore this comment. Otherwise it
is just a reminder.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: samsung: Initialize the dma_data for secondary dai

[Padma Venkat]

Hi Mark,

On Thu, Nov 28, 2013 at 5:08 PM, Mark Brown  wrote:
> On Thu, Nov 28, 2013 at 03:32:12PM +0530, Padmavathi Venna wrote:
>
>> This is made based on Mark Brown for-next branch of sound.git
>> This patch is based on Mark Brown below patches for
>> generic dma engine support for samsung audio IPs.
>> ASoC: samsung: Use ASoC dmaengine code where possible
>> ASoC: samsung: Provide helper for DMA init
>
> Why don't we need this fix for mainline?  The dmaengine change is just
> moving the initialisation through a layer of indirection but there was
> initialisation anyway.  I'm concerned that there's a bug that ought to
> be fixed for v3.13 as well here.

Yes. We need this for mainline. Not dependent on your dmaengine changes.

>
>>   return snd_dmaengine_pcm_register(dev, &samsung_dmaengine_pcm_config,
>> -   SND_DMAENGINE_PCM_FLAG_COMPAT);
>> +   SND_DMAENGINE_PCM_FLAG_COMPAT |
>> + SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME);
>
> This is already done.

Should I send another patch by removing this flag from this patch?

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Thu, Nov 28, 2013 at 5:23 PM, Mark Brown  wrote:
> On Thu, Nov 28, 2013 at 03:29:31PM +0530, Padma Venkat wrote:
>> On Wed, Nov 27, 2013 at 8:35 PM, Mark Brown  wrote:
>
>> > But if it's initialised at probe time then when is it getting
>> > overwritten?  This must be something triggered by DT which unfortunately
>> > I can't test.  It's a bit of a shame that the flows are different
>> > between the DT and non-DT cases.
>
>> it's getting overwritten in i2s_hw_params which is happening after
>> dma_data got initialized in dai probe. Based on mono or stereo channel
>> this value getting initialized to 2 or 4 respectively in
>> i2s_hw_params. This value is not triggered by DT now.
>
> OK, so we can probably just reinitialise the dmaengine data after we
> reset it?  Like below

Yes. That works well.

>
>> > Are you sure that dma_size should be 2?  The i2s DAI driver seems to be
>> > hard coding it to 4.
>
>> I think for mono files the dma_size should be 2 only. Right now based
>> on mono or stereo this value getting overwritten in i2s_hw_params.
>> Initially it is hardcoded to 4. Due to this commit "ASoC: samsung:
>> Allow mono in i2s driver" which was not there earlier, I got confused.
>> Now it seems clear except that underrun message which I am still
>> debugging.

As I forgot to add SND_DMAENGINE_PCM_FLAG_NO_RESIDUE flag, I was
getting underrun error. After adding this flag audio playback is
working fine for smaller files on smdk5420 with pl330 dma driver.

Except for the crash due to NULL pointer dereference in secondary
dai(I posted a patch for the same (ASoC: samsung: Initialize the
dma_data for secondary dai)) you can add my

Tested By: Padmavathi Venna 

>
> Yeah, that's now confusing - I'll send a patch to remove the
> initialisation on probe() since it's getting overwritten later.
>
> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index 67d9fa91fdb9..ba24a954b9e4 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -702,6 +702,8 @@ static int i2s_hw_params(struct snd_pcm_substream 
> *substream,
> }
> writel(mod, i2s->addr + I2SMOD);
>
> +   samsung_asoc_init_dma_data(dai, &i2s->dma_playback, 
> &i2s->dma_capture);
> +
> i2s->frmclk = params_rate(params);
>
> return 0;

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Wed, Nov 27, 2013 at 8:35 PM, Mark Brown  wrote:
> On Wed, Nov 27, 2013 at 06:08:47PM +0530, Padma Venkat wrote:
>> On Tue, Nov 26, 2013 at 5:50 PM, Mark Brown  wrote:
>
>> > So this is 16 bit stereo or something, and did it work beforehand?  Like
>> > I say I suspect the DMA is ending up being configured with the wrong
>> > transfer size, can you check what actually happens there please - what's
>> > different about the configuration that the DMA controller gets?  I don't
>> > have any Exynos systems with mainline audio support so I can't test
>> > anything myself.
>
>> This stream was working before. dma_size in i2s_hw_params not getting
>> effected as dma_data is getting initialized only at dai probe time. So
>> by default the dma_size is always 4 which is initialized at driver
>> probe time. The fifo_size of dai is also always 0. It is not getting
>> passed from dai driver. I just hard coded the dma_size to 2 and
>
> But if it's initialised at probe time then when is it getting
> overwritten?  This must be something triggered by DT which unfortunately
> I can't test.  It's a bit of a shame that the flows are different
> between the DT and non-DT cases.

it's getting overwritten in i2s_hw_params which is happening after
dma_data got initialized in dai probe. Based on mono or stereo channel
this value getting initialized to 2 or 4 respectively in
i2s_hw_params. This value is not triggered by DT now.

>
> The FIFO size looks like a difference between the pl330 and pl080, it
> doesn't seem to matter for pl080.  We just need to set it though.

fifo_size seems doesn't have any effect even in this case.

>
>> fifo_size to 32 then I can hear the audio only on right ear phone.
>> Still underrun error message appears.
>
> Are you sure that dma_size should be 2?  The i2s DAI driver seems to be
> hard coding it to 4.

I think for mono files the dma_size should be 2 only. Right now based
on mono or stereo this value getting overwritten in i2s_hw_params.
Initially it is hardcoded to 4. Due to this commit "ASoC: samsung:
Allow mono in i2s driver" which was not there earlier, I got confused.
Now it seems clear except that underrun message which I am still
debugging.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Tue, Nov 26, 2013 at 5:50 PM, Mark Brown  wrote:
> On Tue, Nov 26, 2013 at 04:18:41PM +0530, Padma Venkat wrote:
>
>> I tried this on linux-samsung tree by applying all the patches from
>> you and Lars.
>
> Can you use -next plus the posted patches please in case there's
> something been misplaced, it'll help if we're working from the same code
> base?

Sound tree has some booting issue on smdk5420 so I tried this on
linux-samsung tree.

>
>> I initialised the dma_data for secondary dai as there is a crash with out 
>> that.
>
> Can you please send a patch for that if you find it's needed?  Like I
> said in reply to your earlier mail it looks like this doesn't work
> anyway so mainline ought to be fixed.

Okay. I will send a patch.

>
>> Then I used aplay after running the mixer settings.
>> ./aplay /mars/share/sounds/alsa/Front_Center.wav
>
> So this is 16 bit stereo or something, and did it work beforehand?  Like
> I say I suspect the DMA is ending up being configured with the wrong
> transfer size, can you check what actually happens there please - what's
> different about the configuration that the DMA controller gets?  I don't
> have any Exynos systems with mainline audio support so I can't test
> anything myself.

This stream was working before. dma_size in i2s_hw_params not getting
effected as dma_data is getting initialized only at dai probe time. So
by default the dma_size is always 4 which is initialized at driver
probe time. The fifo_size of dai is also always 0. It is not getting
passed from dai driver. I just hard coded the dma_size to 2 and
fifo_size to 32 then I can hear the audio only on right ear phone.
Still underrun error message appears.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Tue, Nov 26, 2013 at 3:53 PM, Mark Brown  wrote:
> On Tue, Nov 26, 2013 at 10:55:17AM +0530, Padma Venkat wrote:
>
>> I tested this patch set on smdk5420 i2s. During playback audio playing
>> fast and there is underrun error like below.
>> underrun!!! (at least 0.061 ms long)
>> underrun!!! (at least 0.043 ms long)
>
> This sounds like it's setting the transfer width incorrectly, though I
> can't immediately see how that's changed unless the DMA driver is not
> working correctly.  What exactly did you do to test?

I tried this on linux-samsung tree by applying all the patches from
you and Lars.
I initialised the dma_data for secondary dai as there is a crash with out that.
Then I used aplay after running the mixer settings.
./aplay /mars/share/sounds/alsa/Front_Center.wav

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible

[Padma Venkat]

Hi Mark,

On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> Since all Exynos platforms have been converted to dmaengine and many of
> the older platforms are in the process of conversion they do not need to
> use the legacy s3c-dma APIs for DMA but can instead use the standard ASoC
> dmaengine helpers. This both allows them to benefit from improvements
> implemented in the generic code and supports multiplatform.
>
> Signed-off-by: Mark Brown 
> ---
>
> This depends on Tomasz's s3c64xx dmaengine conversion since that is how
> I've tested it - if possible I'd like to get that merged into ASoC and
> SPI early after -rc1, since I maintian both trees it's possibly easiest
> if I go ahead any apply it?
>
>  sound/soc/samsung/Kconfig | 13 +--
>  sound/soc/samsung/Makefile|  6 ++--
>  sound/soc/samsung/dma.h   |  3 ++
>  sound/soc/samsung/dmaengine.c | 82 
> +++
>  4 files changed, 100 insertions(+), 4 deletions(-)
>  create mode 100644 sound/soc/samsung/dmaengine.c
>

[snip]

>  void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
> diff --git a/sound/soc/samsung/dmaengine.c b/sound/soc/samsung/dmaengine.c
> new file mode 100644
> index 000..ad0a371
> --- /dev/null
> +++ b/sound/soc/samsung/dmaengine.c
> @@ -0,0 +1,82 @@
> +/*
> + * dmaengine.c - Samsung dmaengine wrapper
> + *
> + * Author: Mark Brown 
> + * Copyright 2013 Linaro
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "dma.h"
> +
> +#ifdef CONFIG_ARCH_S3C64XX
> +#define filter_fn pl08x_filter_id
> +#else
> +#define filter_fn NULL
> +#endif
> +
> +static const struct snd_dmaengine_pcm_config samsung_dmaengine_pcm_config = {
> +   .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
> +   .compat_filter_fn = filter_fn,
> +};
> +
> +void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
> +   struct s3c_dma_params *playback,
> +   struct s3c_dma_params *capture)
> +{
> +   struct snd_dmaengine_dai_dma_data *playback_data = NULL;
> +   struct snd_dmaengine_dai_dma_data *capture_data = NULL;
> +
> +   if (playback) {
> +   playback_data = &playback->dma_data;
> +   playback_data->filter_data = (void *)playback->channel;
> +   playback_data->chan_name = playback->ch_name;
> +   playback_data->addr = playback->dma_addr;
> +   playback_data->addr_width = playback->dma_size;
> +   }
> +   if (capture) {
> +   capture_data = &capture->dma_data;
> +   capture_data->filter_data = (void *)capture->channel;
> +   capture_data->chan_name = capture->ch_name;
> +   capture_data->addr = capture->dma_addr;
> +   capture_data->addr_width = capture->dma_size;
> +   }
> +
> +   snd_soc_dai_init_dma_data(dai, playback_data, capture_data);
> +}
> +EXPORT_SYMBOL_GPL(samsung_asoc_init_dma_data);
> +
> +int samsung_asoc_dma_platform_register(struct device *dev)
> +{
> +   return snd_dmaengine_pcm_register(dev, &samsung_dmaengine_pcm_config,
> + SND_DMAENGINE_PCM_FLAG_COMPAT);

also need to pass flag SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME here?

I tested this patch set on smdk5420 i2s. During playback audio playing
fast and there is underrun error like below.
underrun!!! (at least 0.061 ms long)
underrun!!! (at least 0.043 ms long)

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init

[Padma Venkat]

Hi Mark,

On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown  wrote:
> From: Mark Brown 
>
> In preparation for using the dmaengine helpers in ASoC rather than the
> dmaengine wrappers for the Samsung API wrap the configuration of dma_data.
> The dmaengine code expects different data to that used by the legacy API.
>
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/samsung/ac97.c | 51 
> +++-
>  sound/soc/samsung/dma.c  |  8 
>  sound/soc/samsung/dma.h  |  3 +++
>  sound/soc/samsung/i2s.c  |  2 +-
>  sound/soc/samsung/pcm.c  | 18 +
>  5 files changed, 38 insertions(+), 44 deletions(-)
>

[snip]

> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
> index a5cbdb4..67d9fa9 100644
> --- a/sound/soc/samsung/i2s.c
> +++ b/sound/soc/samsung/i2s.c
> @@ -963,7 +963,7 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai)
> }
> clk_prepare_enable(i2s->clk);
>
> -   snd_soc_dai_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture);
> +   samsung_asoc_init_dma_data(dai, &i2s->dma_playback, 
> &i2s->dma_capture);

we have to initialize the dma data for i2s secondary dai also
otherwise there is a crash in dmaengine_pcm_new during probe.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] dmaengine: pl330: Set residue in tx_status callback.

[Padma Venkat]

Hi Chanho,

On Thu, Sep 12, 2013 at 5:10 PM, Chanho Park  wrote:
> Hi Padmavathi,
>
>> -Original Message-
>> From: linux-arm-kernel [mailto:linux-arm-kernel-
>> boun...@lists.infradead.org] On Behalf Of Padmavathi Venna
>> Sent: Wednesday, September 11, 2013 3:08 PM
>> To: linux-samsung-soc@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; padm...@samsung.com; padma@gmail.com
>> Cc: kgene@samsung.com; a...@arndb.de; sbki...@samsung.com;
>> vinod.k...@intel.com; broo...@kernel.org; dgr...@chromium.org;
>> ol...@chromium.org
>> Subject: [PATCH 1/3] dmaengine: pl330: Set residue in tx_status callback.
>>
>> From: Dylan Reid 
>>
>> Fill txstate.residue with the amount of bytes remaining in the current
>> transfer if the transfer is not complete.  This will be of particular use
>> to i2s DMA transfers, providing more accurate hw_ptr values to ASoC.
>>
>> Signed-off-by: Dylan Reid 
>> Reviewed-by: Olof Johansson 
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  drivers/dma/pl330.c |   55
>> ++-
>>  1 files changed, 54 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c index
>> 593827b..7ab9136 100644
>> --- a/drivers/dma/pl330.c
>> +++ b/drivers/dma/pl330.c
>> @@ -2476,11 +2476,64 @@ static void pl330_free_chan_resources(struct
>> dma_chan *chan)
>>   spin_unlock_irqrestore(&pch->lock, flags);  }
>>
>> +static inline int
>> +pl330_src_addr_in_desc(struct dma_pl330_desc *desc, unsigned int sar) {
>> + return ((desc->px.src_addr <= sar) &&
>> + (sar <= (desc->px.src_addr + desc->px.bytes))); }
>> +
>> +static inline int
>> +pl330_dst_addr_in_desc(struct dma_pl330_desc *desc, unsigned int dar) {
>> + return ((desc->px.dst_addr <= dar) &&
>> + (dar <= (desc->px.dst_addr + desc->px.bytes))); }
>> +
>> +static unsigned int pl330_tx_residue(struct dma_chan *chan) {
>> + struct dma_pl330_chan *pch = to_pchan(chan);
>> + void __iomem *regs = pch->dmac->pif.base;
>> + struct pl330_thread *thrd = pch->pl330_chid;
>> + struct dma_pl330_desc *desc;
>> + unsigned int sar, dar;
>> + unsigned int residue = 0;
>> + unsigned long flags;
>> +
>> + sar = readl(regs + SA(thrd->id));
>> + dar = readl(regs + DA(thrd->id));
>> +
>> + spin_lock_irqsave(&pch->lock, flags);
>> +
>> + /* Find the desc related to the current buffer. */
>> + list_for_each_entry(desc, &pch->work_list, node) {
>> + if (desc->rqcfg.src_inc && pl330_src_addr_in_desc(desc,
>> sar)) {
>> + residue = desc->px.bytes - (sar -
> desc->px.src_addr);
>> + goto found_unlock;
>> + }
>> + if (desc->rqcfg.dst_inc && pl330_dst_addr_in_desc(desc,
>> dar)) {
>> + residue = desc->px.bytes - (dar -
> desc->px.dst_addr);
>> + goto found_unlock;
>> + }
>> + }
>> +
>> +found_unlock:
>> + spin_unlock_irqrestore(&pch->lock, flags);
>> +
>> + return residue;
>> +}
>> +
>>  static enum dma_status
>>  pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>>struct dma_tx_state *txstate)
>>  {
>> - return dma_cookie_status(chan, cookie, txstate);
>> + enum dma_status ret;
>> +
>> + ret = dma_cookie_status(chan, cookie, txstate);
>> + if (ret != DMA_SUCCESS) /* Not complete, check amount left. */
>> + dma_set_residue(txstate, pl330_tx_residue(chan));
>> +
>> + return ret;
>
> Why didn't you use a cookie value to track the request?
> The cookie is assigned when each transfer is submitted.
> If you save the value in the desc, we can find the request easily.

Ok. I will check this and modify the code in the next version of patches.

Thanks for the suggestion.

>
> Thanks,
>
> Best  Regards,
> Chanho Park
>

Best Regards
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/4] clk: Samsung: audss: Add support for Exynos5420

[Padma Venkat]

Hi Mike,

On Mon, Aug 19, 2013 at 2:18 PM, Padma Venkat  wrote:
> Hi Mike,
>
> On Fri, Aug 16, 2013 at 1:19 PM, Padmavathi Venna  wrote:
>> This patch set adds support for audio subsystem clks on Exynos5420. 
>> Exynos5420
>> audio subsystem has a gate bit for ADMA controller and the some of the parent
>> clks for mout_i2s and sclk_pcm are different from Exynos5250. So this patch
>> adds provision for supporting both the platforms by determining the parent 
>> clk
>> names based on compatible string.
>>
>> Changes since V1:
>> - parent clocks are determined by using the compatible string and not
>>   passed via device tree as done in V1 because the probing order of
>>   the clock providers can't be guaranteed.
>>
>> Andrew Bresticker (3):
>>   clk: exynos-audss: add support for Exynos 5420
>>   clk: exynos-audss: set correct parent clocks
>
> Can you apply the above two patches into your tree?
>

If there is no review comment on the above two can you please
acknowledge them? The below patch is dependent on these two patches
and Kukjin is waiting for these patches to be merged.

[V2] ARM: dts: Add DMA controller node info on Exynos5420.
https://patchwork.kernel.org/patch/2844436/

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/4] clk: Samsung: audss: Add support for Exynos5420

[Padma Venkat]

Hi Mike,

On Fri, Aug 16, 2013 at 1:19 PM, Padmavathi Venna  wrote:
> This patch set adds support for audio subsystem clks on Exynos5420. Exynos5420
> audio subsystem has a gate bit for ADMA controller and the some of the parent
> clks for mout_i2s and sclk_pcm are different from Exynos5250. So this patch
> adds provision for supporting both the platforms by determining the parent clk
> names based on compatible string.
>
> Changes since V1:
> - parent clocks are determined by using the compatible string and not
>   passed via device tree as done in V1 because the probing order of
>   the clock providers can't be guaranteed.
>
> Andrew Bresticker (3):
>   clk: exynos-audss: add support for Exynos 5420
>   clk: exynos-audss: set correct parent clocks

Can you apply the above two patches into your tree?

>   ARM: dts: exynos5420: add audio clock controller
>
> Padmavathi Venna (1):
>   ARM: dts: Correct the /include entry on exynos5420 dtsi file
>
>  .../devicetree/bindings/clock/clk-exynos-audss.txt |7 +--
>  arch/arm/boot/dts/exynos5420.dtsi  |   11 ++-
>  drivers/clk/samsung/clk-exynos-audss.c |   20 
> +++-
>  include/dt-bindings/clk/exynos-audss-clk.h |3 ++-
>  4 files changed, 36 insertions(+), 5 deletions(-)
>
> --
> 1.7.4.4
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Broken device trees for exynos in linux-next

[Padma Venkat]

Hi,

On Fri, Aug 16, 2013 at 6:12 AM, Mark Brown  wrote:
> On Fri, Aug 16, 2013 at 01:35:57AM +0100, Mark Brown wrote:
>> On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:
>
>> > NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: 
>> > exynos5250:
>> > move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.
>
>> > Mark, pleaser revert it in your tree...
>
>> I'll do that but I don't know if that's then going to break anything
>> else.  This sort of bisection/cross tree issue does come up a lot with
>> the Samsung SoCs - it'd be good if you could remind the people working
>> on them about the need to make sure that when there are dependencies
>> they're handled when things are merged.
>
> I also had to revert "ARM: dts: Change i2s compatible string on
> exynos5250" from my tree since it depended on the above commit.  I
> suspect this may leave the driver broken and we'll need a new version
> before the merge window...

I apologize for this bisection. Soon I will post a new patch for this.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 1/4] ARM: dts: exynos5420: add i2s controllers

[Padma Venkat]

Hi Tomasz,

On Mon, Aug 12, 2013 at 10:32 PM, Tomasz Figa  wrote:
> On Monday 12 of August 2013 14:12:36 Mark Brown wrote:
>> On Mon, Aug 12, 2013 at 01:41:23PM +0200, Tomasz Figa wrote:
>> > On Monday 12 of August 2013 12:34:48 Mark Brown wrote:
>> > > I'd expect that to interact badly with the pinmuxing - unless the
>> > > device is disabled it'll try to grab its pins on probe which is not
>> > > going to be a good idea unless it is actually wired up for use in
>> > > the system.  Or is there some other mechanism for handling that?
>> >
>> > Ah, good point. Now I wonder whether pinctrl nodes shouldn't be
>> > considered board-specific and specified in board-level dts instead?
>>
>> It seems a bit cleaner to use the current mechanism in that it stops the
>> device appearing at all and hence repeated efforts to probe, plus a
>> simple enable is less error prone, the way these SoCs are designed you
>> don't have to pick which pinmux is in use for most of the IPs.  Where
>> there are multiple options it does seem like a good approach though.
>>
>> Tastes may differ though.
>
> Right, if this SoC has only one pinmux setting for this IP, then it's
> fine.

Yes. This IP has only default pin configuration.

>
> Padmavathi, this was the only issue I spotted, so have my:
>
> Reviewed-by: Tomasz Figa 

Thanks for your review.

>
> Best regards,
> Tomasz
>

Best Regards,
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] Move comon DMA nodes to exynos5.dtsi and

[Padma Venkat]

Hi Kukjin,

Any comment on this patch set?
If not can you take into your tree?

Thanks
Padma

On Wed, Jul 10, 2013 at 5:44 PM, Padmavathi Venna  wrote:
> Exynos5250 and Exynos5420 has 4 DMA controllers in common. So this patch
> set moved the common nodes to exynos.dtsi keeping the clk info seperate
> for both the platforms. Exynos5420 has a separate DMA controller for audio
> IPs. So this patch set also adds the ADMA node on Exynos5420.
>
> Padmavathi Venna (2):
>   ARM: dts: Move the common DMA controller nodes to exynos5.dtsi
>   ARM: dts: Add DMA controller node info on Exynos5420.
>
>  arch/arm/boot/dts/exynos5.dtsi|   44 
> +
>  arch/arm/boot/dts/exynos5250.dtsi |   30 -
>  arch/arm/boot/dts/exynos5420.dtsi |   33 +++
>  3 files changed, 77 insertions(+), 30 deletions(-)
>
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] clk: Samsung: audss: Add support for Exynos5420

[Padma Venkat]

Hi Kukjin,

Any comments on this patch set?

Thanks
Padma

On Wed, Jul 10, 2013 at 5:41 PM, Padmavathi Venna  wrote:
> This patch set adds support for audio subsystem clks on Exynos5420. Exynos5420
> audio subsystem has a gate bit for ADMA controller and the some of parent clks
> for mout_i2s are also different from Exynos5250. So this patch adds provision
> for supporting both the platforms by passing the parent clk names through
> device tree.
>
> Andrew Bresticker (3):
>   clk: exynos-audss: add support for Exynos 5420
>   clk: exynos-audss: allow input clocks to be specified in device tree
>   ARM: dts: exynos5420: add audio clock controller
>
> Padmavathi Venna (1):
>   ARM: dts: Correct the /include entry on exynos5420 dtsi file
>
>  .../devicetree/bindings/clock/clk-exynos-audss.txt |   38 +--
>  arch/arm/boot/dts/exynos5420.dtsi  |   13 ++-
>  drivers/clk/samsung/clk-exynos-audss.c |   36 --
>  include/dt-bindings/clk/exynos-audss-clk.h |3 +-
>  4 files changed, 80 insertions(+), 10 deletions(-)
>
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Padma Venkat]

Hi Tomasz,

On Wed, Aug 7, 2013 at 4:43 PM, Tomasz Figa  wrote:
> Ahh, one more thing inline.
>

[snip]

>>
>> +static struct samsung_i2s_dai_data i2sv3_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_NO_MUXPSR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv4_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv5_c100_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_NO_MUXPSR | QUIRK_SEC_DAI |
>> + QUIRK_NEED_RSTCLR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data i2sv5_dai_type = {
>> + .dai_type = TYPE_PRI,
>> + .quirks = QUIRK_PRI_6CHAN | QUIRK_SEC_DAI | QUIRK_NEED_RSTCLR,
>> +};
>> +
>> +static struct samsung_i2s_dai_data samsung_dai_type_sec = {
>> + .dai_type = TYPE_SEC,
>> +};
>> +
>>  static struct platform_device_id samsung_i2s_driver_ids[] = {
>>   {
>> - .name   = "samsung-i2s",
>> - .driver_data= TYPE_PRI,
>> + .name   = "samsung,s3c6410-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv3_dai_type,
>> + }, {
>> + .name   = "samsung,s3c6410-i2s-multi",
>> + .driver_data= (kernel_ulong_t)&i2sv4_dai_type,
>> + }, {
>> + .name   = "samsung,s5pc100-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv5_c100_dai_type,
>>   }, {
>> - .name   = "samsung-i2s-sec",
>> - .driver_data= TYPE_SEC,
>> + .name   = "samsung,s5pv210-i2s",
>> + .driver_data= (kernel_ulong_t)&i2sv5_dai_type,
>> + }, {
>> + .name   = "samsung-i2s-sec",
>> + .driver_data= (kernel_ulong_t)&samsung_dai_type_sec,
>
> I don't think you need to change the legacy platform IDs at all.

If legacy platforms not required to change then I need to introduce a
new samsung_i2s_dai_data structure which holds only dai_type for
non-dt platforms. If I change legacy platforms it breaks the older
platforms now. Is it okay adding a samsung_i2s_dai_data structure for
non-dt platforms which will be removed later?

>
> IMHO it would be better to keep the old way of quirk retrieval from
> platform_data (which I think this patch does anyway, because the probe path
> without DT is unchanged), as it will be dropped in some point in time
> anyway.
>
> This would also eliminate the need for patch 1.
>
> Best regards,
> Tomasz
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 2/3] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Padma Venkat]

Hi Tomasz,

On Wed, Aug 7, 2013 at 4:32 PM, Tomasz Figa  wrote:
> Hi Padmavathi,
>
> [Ccing DT maintainers with a little comment about contents of this patch
> for them:
>
> This is a rework of Samsung i2s bindings to make them more reasonable than
> they are at the moment. I know this was supposed to be stable, fixed, ABI,
> etc., but as we discussed a lot the whole topic of DT bindings, we need to
> sanitize existing bindings and this patch is a part of this work.]
>

[snip]

>>
>>  Required SoC Specific Properties:
>>
>> -- compatible : "samsung,i2s-v5"
>> +- compatible : should be one of the following.
>> +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
>> + has only 8/16bit support.
>
> The comment about previous versions seems a bit enigmatic.
>
> If there is another variant supported by this driver that supports only
> 8/16bit audio data, then it should have a separate compatible value.

For previous i2s controllers there are two other i2s drivers
available. I think I can delete this comment here.

>
>> +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel)
>> I2S. + Introduced in s3c6410. This also applicable for s5p64x0
>> platforms. +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1
>> channel) I2S + with secondary fifo and s/w reset control.
>> +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
>> + secondary fifo, s/w reset control and internal mux for root clk
>> src. +
>>  - reg: physical base address of the controller and length of memory
>> mapped region.
>>  - dmas: list of DMA controller phandle and DMA request line ordered
>> pairs. @@ -21,13 +30,6 @@ Required SoC Specific Properties:
>>
>>  Optional SoC Specific Properties:
>>
>> -- samsung,supports-6ch: If the I2S Primary sound source has 5.1 Channel
>> -  support, this flag is enabled.
>> -- samsung,supports-rstclr: This flag should be set if I2S software reset
>> bit -  control is required. When this flag is set I2S software reset bit
>> will be -  enabled or disabled based on need.
>> -- samsung,supports-secdai:If I2S block has a secondary FIFO and internal
>> DMA, -  then this flag is enabled.
>>  - samsung,idma-addr: Internal DMA register base address of the audio
>>sub system(used in secondary sound source).
>>  - pinctrl-0: Should specify pin control groups used for this controller.
>> @@ -46,9 +48,6 @@ i2s0: i2s@0383 {
>
> The example has also a compatible value set to "samsung,i2s-v5". I don't
> think this is compliant to the new bindings.

Yes. It's my mistake. Will change this to new one.

>
>>   <&clock_audss EXYNOS_I2S_BUS>,
>>   <&clock_audss EXYNOS_SCLK_I2S>;
>>   clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
>> - samsung,supports-6ch;
>> - samsung,supports-rstclr;
>> - samsung,supports-secdai;
>>   samsung,idma-addr = <0x0300>;
>>   pinctrl-names = "default";
>>   pinctrl-0 = <&i2s0_bus>;
>> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
>> index 47e08dd..8a5504c 100644
>> --- a/sound/soc/samsung/i2s.c
>> +++ b/sound/soc/samsung/i2s.c
>> @@ -40,6 +40,7 @@ enum samsung_dai_type {
>>
>>  struct samsung_i2s_dai_data {
>
> const struct samsung_i2s_dai_data

OK.

>
>>   int dai_type;
>> + u32 quirks;
>>  };
>>
>>  struct i2s_dai {
>> @@ -1032,18 +1033,18 @@ static struct i2s_dai *i2s_alloc_dai(struct
>> platform_device *pdev, bool sec)
>>
>>  static const struct of_device_id exynos_i2s_match[];
>>
>> -static inline int samsung_i2s_get_driver_data(struct platform_device
>> *pdev) +static inline struct samsung_i2s_dai_data
>> *samsung_i2s_get_driver_data( +  
>>  struct platform_device
> *pdev)
>>  {
>>  #ifdef CONFIG_OF
>> - struct samsung_i2s_dai_data *data;
>>   if (pdev->dev.of_node) {
>>   const struct of_device_id *match;
>>   match = of_match_node(exynos_i2s_match, pdev->dev.of_node);
>> - data = (struct samsung_i2s_dai_data *) match->data;
>> - return data->dai_type;
>> + return (struct samsung_i2s_dai_data *) match->data;
>
> If you make the dai_data const this cast will be no longer necessary.
>
>>   } else
>>  #endif
>> - return platform_get_device_id(pdev)->driver_data;
>> + return (struct samsung_i2s_dai_data *)
>> + platform_get_device_id(pdev)->driver_data;
>>  }
>>
>>  #ifdef CONFIG_PM_RUNTIME
>> @@ -1074,13 +1075,13 @@ static int samsung_i2s_probe(struct
>> platform_device *pdev) struct resource *res;
>>   u32 regs_base, quirks = 0, idma_addr = 0;
>>   struct device_node *np = pdev->dev.of_node;
>> - enum samsung_dai_type samsung_dai_type;
>> + struct samsung_i2s_dai_data *i2s_dai_data;
>
> const

OK.

>
>>   int ret = 0;
>>
>>   /* Call during Seconday interface registration */
>> - samsung_dai_type = samsung_i2s_get_driver_data(pdev);
>> + i2s_

Re: [PATCH V3 6/7] ASoC: Samsung: wm8994: Register the osc clock.

[Padma Venkat]

Hi Mark,

On Wed, Aug 7, 2013 at 3:40 PM, Mark Brown  wrote:
> On Wed, Aug 07, 2013 at 02:40:15PM +0530, Padmavathi Venna wrote:
>> This patch registers the 16MHz oscillator clock as fixed clk.
>
>> +/* 16.9MHz fixed oscillator clock */
>> +static void init_osc_clock(void)
>> +{
>> + struct device_node *np;
>> +
>> + np = of_find_compatible_node(NULL, NULL, "osc3_clk16mhz");
>> + of_fixed_clk_setup(np);
>> +}
>> +
>>  static int smdk_hw_params(struct snd_pcm_substream *substream,
>>   struct snd_pcm_hw_params *params)
>>  {
>> @@ -173,6 +183,8 @@ static int smdk_audio_probe(struct platform_device *pdev)
>>   smdk_dai[0].platform_of_node = smdk_dai[0].cpu_of_node;
>>   }
>>
>> + init_osc_clock();
>> +
>
> This doesn't seem great - it means that this machine driver needs to

Yes. True. But I am not sure of the correct place to keep this code.
Any suggestions?

Thanks
Padma

> know about a specifically named fixed clock which makes it hard to reuse
> on other similar boards.  For example I'm intending to reuse this on
> Arndale.  Mike?
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/7] ARM: dts: Change i2s compatible string on exynos5250

[Padma Venkat]

Hi Mark,

On Wed, Aug 7, 2013 at 3:40 PM, Mark Brown  wrote:
> On Wed, Aug 07, 2013 at 02:40:10PM +0530, Padmavathi Venna wrote:
>> This patch removes quirks from i2s node and change the i2s
>> compatible names.
>
> This needs to go along with the driver change otherwise we break
> bisection.

some of the patches at dts side are dependent on this patch. So I
separated it into another set. Should I re-post this patch along with
other driver side patches?

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 0/7] Add i2s nodes on Exynos5420 and enable sound support on sdmk5420

[Padma Venkat]

Hi,

Abandoning this series due to some mistake in the post.  Will post new
patch set.

Thanks
Padma

On Wed, Aug 7, 2013 at 2:20 PM, Padmavathi Venna  wrote:
> Changes since V2:
> - Seperated out driver side changes and dts changes in two
>   patch sets
> - Added proper names for wm8994 regulators as commented by Mark
> - Moved common i2s nodes into the exynos5.dtsi
> - Added clock info in wm8994 node as requested by Mark.
> - Registered the 16.9MHz oscillator clock as fixed clock in the
>   machine file. Right now no user of this clock but as Mark requested
>   to add mclk info in wm8994 node, I added this part.
>
> This patch set is dependent on the following i2c, dma and audio subsystem
> clk controller patches.
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20077
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20661
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20668
>
> This patch set is made based on Kukjin Kim for-next branch.
>
> Andrew Bresticker (1):
>   ARM: dts: exynos5420: add i2s controllers
>
> Padmavathi Venna (6):
>   ARM: dts: Change i2s compatible string on exynos5250
>   ARM: dts: Add i2c bus 1 and it's audio codec child node on smdk5420
>   ARM: dts: exynos5250: move common i2s properties to exynos5 dtsi
>   ARM: dts: Add osc clock node on smdk5420.
>   ASoC: Samsung: wm8994: Register the osc clock.
>   ARM: dts: Enable sound support on smdk5420
>
>  arch/arm/boot/dts/exynos5.dtsi|   21 
>  arch/arm/boot/dts/exynos5250.dtsi |   17 +--
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |   78 
> +
>  arch/arm/boot/dts/exynos5420.dtsi |   32 
>  sound/soc/samsung/smdk_wm8994.c   |   12 +
>  5 files changed, 144 insertions(+), 16 deletions(-)
>
> --
> 1.7.4.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420

[Padma Venkat]

Hi Mark,

On Tue, Jul 30, 2013 at 8:58 AM, Padma Venkat  wrote:
> Hi Mark,
>
> On Mon, Jul 29, 2013 at 7:13 PM, Mark Brown  wrote:
>> On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
>>> On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat  wrote:
>>
>>> >>> + vdd: fixed-regulator@0 {
>>> >>> + compatible = "regulator-fixed";
>>> >>> + regulator-name = "vdd-supply";
>>
>>> >> These names look wrong - they should reflect the names in the schematic
>>> >> as they're for human comprehensibility.  This may just be a case of
>>> >> dropping the -supply.
>>
>>> When I posted the same patch for smdk5250, you asked me to club all
>>> the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
>>> better name for representing both supplies?
>>
>> No, I'd have told you to combine things taht come from the same supply
>> on the board - things like the speaker supplies for example aren't going
>> to be coming from separate places.  The names should reflect whatever
>> the names on the schemaric are, like I say that's probably just removing
>> the -supply.
>>
>>> >> documentation update the other day, it's in my tree now) but it's not
>>> >> essential and I suspect it needs some work on the clock driver side
>>> >> still.
>>
>>> > OK. I will check this.
>>
>>> As per schemata, input clock to MCLK1 is an oscillator clock with
>>> 16.9MHz and MCLK2 not showing any input clock. So here I need to add a
>>> fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
>>
>>> Is it correct?
>>
>> Yes, in the DTS (or to XCLKOUT on the AP?).
>
> On smdk boards(atleast on smdk5250 and smdk5420) there is no XCLKOUT
> funda. Codec MCLK can get clock from oscillator clock in codec master
> mode or i2scdclk in codec slave mode. XCLKOUT is there in some other
> variants of 5250 and 5420 where it is using other codecs than wm8994.
> But the mux and divider of XCLKOUT is out of CMU. As Sylwester told it
> is there in PMU registers.

Sorry for giving some what wrong info here. I verified the schemata.
There is a switch on the board which can be used to select the input
clock of codec MCLK1. We can either select oscillator clock which is
16.9MHz which is on the board or XCLKOUT which is from PMU or
i2scdclk(codec slave mode). Right now we are using oscillator clock as
input clock to MCLK1.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420

[Padma Venkat]

Hi Mark,

On Mon, Jul 29, 2013 at 7:13 PM, Mark Brown  wrote:
> On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
>> On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat  wrote:
>
>> >>> + vdd: fixed-regulator@0 {
>> >>> + compatible = "regulator-fixed";
>> >>> + regulator-name = "vdd-supply";
>
>> >> These names look wrong - they should reflect the names in the schematic
>> >> as they're for human comprehensibility.  This may just be a case of
>> >> dropping the -supply.
>
>> When I posted the same patch for smdk5250, you asked me to club all
>> the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
>> better name for representing both supplies?
>
> No, I'd have told you to combine things taht come from the same supply
> on the board - things like the speaker supplies for example aren't going
> to be coming from separate places.  The names should reflect whatever
> the names on the schemaric are, like I say that's probably just removing
> the -supply.
>
>> >> documentation update the other day, it's in my tree now) but it's not
>> >> essential and I suspect it needs some work on the clock driver side
>> >> still.
>
>> > OK. I will check this.
>
>> As per schemata, input clock to MCLK1 is an oscillator clock with
>> 16.9MHz and MCLK2 not showing any input clock. So here I need to add a
>> fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
>
>> Is it correct?
>
> Yes, in the DTS (or to XCLKOUT on the AP?).

On smdk boards(atleast on smdk5250 and smdk5420) there is no XCLKOUT
funda. Codec MCLK can get clock from oscillator clock in codec master
mode or i2scdclk in codec slave mode. XCLKOUT is there in some other
variants of 5250 and 5420 where it is using other codecs than wm8994.
But the mux and divider of XCLKOUT is out of CMU. As Sylwester told it
is there in PMU registers.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420

[Padma Venkat]

Hi Mark,

On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat  wrote:
> Hi Mark,
>
> On Fri, Jul 26, 2013 at 8:49 PM, Mark Brown  wrote:
>> On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
>>> This patch adds wm8994 codec node on i2c bus1 and the required
>>> regulator supplies and properties on smdk5420 board.
>>
>> This isn't a device tree patch for WM8994, it's a patch for the
>> SMDK5420.
>
> Yes. I will correct the subject.
>
>>
>>> + vdd: fixed-regulator@0 {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "vdd-supply";
>>
>> These names look wrong - they should reflect the names in the schematic
>> as they're for human comprehensibility.  This may just be a case of
>> dropping the -supply.
>

When I posted the same patch for smdk5250, you asked me to club all
the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
better name for representing both supplies?

> OK.
>
>>
>>> + wm8994: wm8994@1a {
>>> + compatible = "wlf,wm8994";
>>> + reg = <0x1a>;
>>> +
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> +
>>> + AVDD2-supply = <&vdd>;
>>> + CPVDD-supply = <&vdd>;
>>> + DBVDD-supply = <&dbvdd>;
>>> + SPKVDD1-supply = <&spkvdd>;
>>> + SPKVDD2-supply = <&spkvdd>;
>>> + };
>>
>> It would be helpful to also add a clock binding (I posted a binding
>> documentation update the other day, it's in my tree now) but it's not
>> essential and I suspect it needs some work on the clock driver side
>> still.
>
> OK. I will check this.

As per schemata, input clock to MCLK1 is an oscillator clock with
16.9MHz and MCLK2 not showing any input clock. So here I need to add a
fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.

Is it correct?

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420

[Padma Venkat]

Hi Mark,

On Fri, Jul 26, 2013 at 8:49 PM, Mark Brown  wrote:
> On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
>> This patch adds wm8994 codec node on i2c bus1 and the required
>> regulator supplies and properties on smdk5420 board.
>
> This isn't a device tree patch for WM8994, it's a patch for the
> SMDK5420.

Yes. I will correct the subject.

>
>> + vdd: fixed-regulator@0 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vdd-supply";
>
> These names look wrong - they should reflect the names in the schematic
> as they're for human comprehensibility.  This may just be a case of
> dropping the -supply.

OK.

>
>> + wm8994: wm8994@1a {
>> + compatible = "wlf,wm8994";
>> + reg = <0x1a>;
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + AVDD2-supply = <&vdd>;
>> + CPVDD-supply = <&vdd>;
>> + DBVDD-supply = <&dbvdd>;
>> + SPKVDD1-supply = <&spkvdd>;
>> + SPKVDD2-supply = <&spkvdd>;
>> + };
>
> It would be helpful to also add a clock binding (I posted a binding
> documentation update the other day, it's in my tree now) but it's not
> essential and I suspect it needs some work on the clock driver side
> still.

OK. I will check this.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/8] platform: Increase platform name size

[Padma Venkat]

Hi Sachin,

On Fri, Jul 26, 2013 at 8:06 PM, Sachin Kamat  wrote:
> Hi Padma,
>
> On 26 July 2013 19:06, Padmavathi Venna  wrote:
>> This patch increases the platform name size from 20 to 30.
>
> Instead of describing what the patch does (which is quite obvious from
> the code), it would be useful to describe why this change is required.

OK. I will post in my next version.

>
>
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  include/linux/mod_devicetable.h |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/mod_devicetable.h 
>> b/include/linux/mod_devicetable.h
>> index b62d4af..f67b5d5 100644
>> --- a/include/linux/mod_devicetable.h
>> +++ b/include/linux/mod_devicetable.h
>> @@ -478,7 +478,7 @@ struct dmi_system_id {
>>  #define DMI_MATCH(a, b){ .slot = a, .substr = b }
>>  #define DMI_EXACT_MATCH(a, b)  { .slot = a, .substr = b, .exact_match = 1 }
>>
>> -#define PLATFORM_NAME_SIZE 20
>> +#define PLATFORM_NAME_SIZE 30
>>  #define PLATFORM_MODULE_PREFIX "platform:"
>>
>>  struct platform_device_id {
>> --
>> 1.7.4.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With warm regards,
> Sachin

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/8] Add audio support on smdk5420

[Padma Venkat]

On Fri, Jul 26, 2013 at 7:52 PM, Tomasz Figa  wrote:
> Hi Padmavathi,
>
> On Friday 26 of July 2013 19:06:44 Padmavathi Venna wrote:
>> Samsung has different versions of I2S introduced in different
>> platforms. Each version has some new support added for multichannel,
>> secondary fifo, s/w reset control, internal mux for rclk src clk and
>> tdm support. Each newly added change has a quirk. So this patch adds
>> all the required quirks as driver data and based on compatible string
>> from dtsi fetches the quirks. This also adds i2s support on exynos5420
>> and make relevent changes in the dtsi files.
>>
>> Changes since V1:
>>   - Pass quirks as driver data and fetch the quirks based on
>> compatible string from dtsi file as suggested by
>> Tomasz Figa and Mark Brown
>>   - Make the I2S driver more flexible with respect to register
>> access as suggested by Tomasz Figa and Mark Brown
>>   - Add 5420 support in the driver.
>>   - Modify the dtsi files with the corresponding compatible
>> strings and removed the i2s quirks from 5250 dtsi file.
>>   - Updated the i2s Documentation with relevent changes and
>> i2s versioning info.
>>   - Add i2s nodes on exynos5420.dtsi
>>   - Enable sound support on smdk5420
>>
>> This patch set is dependent on the following dma and audio subsystem
>> clk controller patches.
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20661
>> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/20668
>>
>> This patch set is made based on Kukjin Kim for-next branch.
>>
>> Andrew Bresticker (1):
>>   ARM: dts: exynos5420: add i2s controllers
>>
>> Padmavathi Venna (7):
>>   platform: Increase platform name size
>>   ASoC: Samsung: I2S: Add quirks as driver data in I2S
>>   ARM: dts: Change i2s compatible string on exynos5250
>>   ASoC: Samsung: I2S: Modify driver to give more flexibility
>>   ASoC: Samsung: I2S: Modify the I2S driver to support I2S on
>> Exynos5420
>>   ARM: dts: wm8994: Add wm8994 support on smdk5420
>>   ARM: dts: Enable sound support on smdk5420
>>
>>  .../devicetree/bindings/sound/samsung-i2s.txt  |   25 ++-
>>  arch/arm/boot/dts/exynos5250.dtsi  |9 +-
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |   60 ++
>>  arch/arm/boot/dts/exynos5420.dtsi  |   44 +
>>  include/linux/mod_devicetable.h|2 +-
>>  include/linux/platform_data/asoc-s3c.h |1 +
>>  sound/soc/samsung/i2s-regs.h   |   51 --
>>  sound/soc/samsung/i2s.c|  205
>> +++- 8 files changed, 312 insertions(+), 85 deletions(-)
>
> Please resend the whole series again using correct devicetree mailing list,
> which is:
>
> devicet...@vger.kernel.org
>
> The old one (devicetree-disc...@lists.ozlabs.org) is no longer functioning.
>
> Best regards,
> Tomasz
>

 OK. I will post.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 2/8] ASoC: Samsung: I2S: Add quirks as driver data in I2S

[Padma Venkat]

Hi Mark,

On Fri, Jul 26, 2013 at 8:23 PM, Mark Brown  wrote:
> On Fri, Jul 26, 2013 at 07:06:46PM +0530, Padmavathi Venna wrote:
>> Samsung has different versions of I2S introduced in different
>> platforms. Each version has some new support added for multichannel,
>> secondary fifo, s/w reset control and internal mux for rclk src clk.
>> Each newly added change has a quirk. So this patch adds all the
>> required quirks as driver data and based on compatible string from
>> dtsi fetches the quirks.
>
> As Russell indicated you should really keep the old name around, though
> marking them as deprecated is OK.  However I'm not sure anyone will have
> deployed this so I'm not sure how much it matters - every downstream
> kernel I've seen was still using board files anyway.


This is there only on exynos5250.dtsi, so changing this file alone is
enough. patch3 in
this series have the same.

>
> The actual meat of the patch changing to a quirk scheme does look good,
> though.
>
>> -- compatible : "samsung,i2s-v5"
>> +- compatible : should be one of the following.
>> +   - samsung,s3c6410-i2s: for 8/16/24bit stereo I2S. Previous versions
>> + has only 8/16bit support.
>> +   - samsung,s3c6410-i2sv4: for 8/16/24bit multichannel(5.1 channel) I2S.
>> + Introduced in s3c6410. This also applicable for s5p64x0 platforms.
>> +   - samsung,s5pc100-i2s: for 8/16/24bit multichannel(5.1 channel) I2S
>> + with secondary fifo and s/w reset control.
>> +   - samsung,s5pv210-i2s: for 8/16/24bit multichannel(5.1) I2S with
>> + secondary fifo, s/w reset control and internal mux for root clk src.
>> +
>
> I think the -vN naming scheme was fine - I see where this came from but
> the main point was about having things identified by a string not
> switching the naming scheme.  As you can see from the s3c6410 stuff the
> SoC isn't that helpful as a naming scheme as multiple IP versions appear
> on the same SoC.

Having only the version info is confusing. When I posted my previous version of
patches I was clear which version introduced in which platform and
again if I come
back today and see I again had to search each SoC datasheet. So I think this
patch now clearly explains what new support introduced in which
version of IP and which
SoC platform.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] clk: exynos-audss: allow input clocks to be specified in device tree

[Padma Venkat]

Hi Tomasz,

On Tue, Jul 23, 2013 at 1:12 AM, Tomasz Figa  wrote:
> On Monday 22 of July 2013 11:15:30 Mike Turquette wrote:
>> Quoting Tomasz Figa (2013-07-22 09:28:47)
>>
>> > Hi Padmavathi, Andrew,
>> >
>> > On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:
>> > > From: Andrew Bresticker 
>> > >
>> > > This allows the input clocks to the Exynos AudioSS block to be
>> > > specified via device-tree bindings.  Default names will be used
>> > > when an input clock is not given.  This will be useful when adding
>> > > support for the Exynos5420 where the audio bus clock is called
>> > > "sclk_maudio0" instead of "sclk_audio0".
>> > >
>> > > Signed-off-by: Andrew Bresticker 
>> > > Reviewed-on: https://gerrit.chromium.org/gerrit/57833
>> > > Reviewed-by: Simon Glass 
>> > > ---
>> > >
>> > >  .../devicetree/bindings/clock/clk-exynos-audss.txt |   31
>> > >
>> > > ++- drivers/clk/samsung/clk-exynos-audss.c
>> > >   |> >
>> > >   28 +++-- 2 files changed, 53 insertions(+), 6
>> > >   deletions(-)
>> >
>> > Well, this is basically how it should be done, but in current state of
>> > clock core I can see a problem: can we really rely on the order of
>> > clock initialization? I mean, we can't defer initialization of
>> > particular clock controller until all external clocks it needs are
>> > available, because there is no probing involved here.

your point is valid. In this case audio clk controller registration
happening only after CMU clk
controller from which audss needs clks. So this patch can't be taken in?

Thanks
Padma

>>
>> The clock core allows registering clocks even if their parents are not
>> yet registered. I test this path with some dummy clocks every so often
>> to make sure the re-parenting operation are completed successfully after
>> the parents eventually are registered.
>
> Sure it does, but this patch is about something different. It adds device
> tree based lookup (of_clk_get_by_name()) of external clocks (as opposed to
> existing lookup by name), which will fail if provider pointed by phandle
> is not registered yet.
>
>> This feature was not used in practice until recently with the advent of
>> multiple clock controllers getting registered and DT description of
>> clocks / clock controllers that may be "out of order". If you find any
>> bugs please let me know ;-)
>
> I will send you a bunch of patches sorting out issues I found in
> clk_set_rate() path, but give me some time to prepare them :).
>
> As for multiple clock controllers, this is going to be funny. I have
> discussed this a bit with Sylwester and we managed to find some design
> issues that I think must be solved:
>
> a) What about multiple controllers with identical clock names? Imagine two
> PMICs that can also generate 32 KHz clocks, both having them named
> "clk32k". Am I right saying that this won't work with current code?
>
> b) What are the rules of using clock-output-names property (and what
> should be used in non-DT case)? I can imagine using it to assign platform-
> specific names of clock outputs of extra clock controllers (this would
> help in the above case of "clk32k"), but currently it seems like it is
> optional to use it in clock drivers and the meaning is provider-specific.
>
> Best regards,
> Tomasz
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on Exynos5420

[Padma Venkat]

Hi Mark,

On Fri, Jul 12, 2013 at 2:19 PM, Mark Brown  wrote:
> On Fri, Jul 12, 2013 at 10:07:22AM +0530, Padma Venkat wrote:
>
>> A new version number is added when a there was some change in the IP
>> like adding a internal mux to the IP, adding multi channel support,
>> adding reset control bit. This was done in the older code with
>> platform device.
>> Same thing is followed here. So as previously done, adding a new
>> compatible name like "samsung,i2s-v6" with new quirk
>> "samsung,supports-tdm" is okey?
>
> Yes, this is good but the quirk should just be found by software based
> on the compatible string rather than in the DT.

You mean I just need to initialize the quirks in the driver based on
the compatible string?
So what about the quirks that I added previously on 5250? Should I
also follow the same thing for other quirks?

Or it need to be passed via driver data as it is done in spi driver?
Please clarify me.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Samsung: Set RFS and BFS in slave mode

[Padma Venkat]

Hi,

On Thu, Jul 11, 2013 at 4:41 PM, Mark Brown  wrote:
> On Thu, Jul 11, 2013 at 12:38:25PM +0530, Padmavathi Venna wrote:
>> As per the User Manual, the RFS and BFS should be set in slave mode
>> for correct operation.
>
> Applied, thanks.  Since this is a fix it should have been the first
> patch in the series - this allows fixes to be sent to
>
>> Reviewed-on: https://gerrit-int.chromium.org/37841
>
> Including things like this isn't terribly helpful - this is the Chromium
> internal system and nobody in the community can view the review.  A link
> to a public system might be useful but a private one should be omitted.

I thought it was link to the public gerrit review system. Will remove next time.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on Exynos5420

[Padma Venkat]

Hi,

On Thu, Jul 11, 2013 at 6:31 PM, Mark Brown  wrote:
> On Thu, Jul 11, 2013 at 01:41:40PM +0200, Tomasz Figa wrote:
>> On Thursday 11 of July 2013 12:20:23 Mark Brown wrote:
>
>> > This is a bit of a larger project sadly, there was resistance to doing
>> > the DT bindings based on compatible strings using the IP version :(
>
>> I'm not sure if this case is related to this problem in any way. I just
>> suggested introducing a new include like samsung,exynos5420-i2s, a opposed to
>> using samsung,exynos5250-i2s and adding flags, since the I2S in Exynos5420 is
>
> Well, it *should* be samsung,i2s-vN where N is the version number of the
> IP but documentation on the versioning has been patchy hence this whole
> thinng.
>

A new version number is added when a there was some change in the IP
like adding a internal mux to the IP, adding multi channel support,
adding reset control bit. This was done in the older code with
platform device.
Same thing is followed here. So as previously done, adding a new
compatible name like "samsung,i2s-v6" with new quirk
"samsung,supports-tdm" is okey?

I will mention about this versioning info in the Documentation in the
next patch.

>> the first one to have this TDM or whatever mode. (I'd still like to hear what
>> it is...)
>
> What it *should* be is the option to send more than one audio stream
> down a link using time division multiplexing.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Samsung: Modify the I2S driver to support I2S on Exynos5420

[Padma Venkat]

On Thu, Jul 11, 2013 at 4:37 PM, Tomasz Figa  wrote:
> On Thursday 11 of July 2013 11:48:04 Mark Brown wrote:
>> On Thu, Jul 11, 2013 at 12:38:24PM +0530, Padmavathi Venna wrote:
>> > -#define MOD_LR_LLOW(0 << 7)
>> > -#define MOD_LR_RLOW(1 << 7)
>> > -#define MOD_SDF_IIS(0 << 5)
>> > -#define MOD_SDF_MSB(1 << 5)
>> > -#define MOD_SDF_LSB(2 << 5)
>> > -#define MOD_SDF_MASK   (3 << 5)
>> >
>> > +#define MOD_LR_LLOW0
>> > +#define MOD_LR_RLOW1
>> > +#define MOD_SDF_SHIFT  5
>> > +#define MOD_SDF_IIS0
>> > +#define MOD_SDF_MSB1
>> > +#define MOD_SDF_LSB2
>> > +#define MOD_SDF_MASK   3
>>
>> This patch has an awful lot of coding style changes like this which
>> are just coding style changes and not implementing TDM support.  These
>> should be done separately, not as part of the same patch, in order to
>> make the code easier to review.
>>
>> > case 768:
>> > -   mod |= MOD_RCLK_768FS;
>> > +   mod |= (MOD_RCLK_768FS << rfs_shift);
>> >
>> > break;
>>
>> This stuff is another example.
>>
>> I think the change itself should be fine but I'm not 100% sure I'm
>> correctly identifying what's a stylistic change and what's a functional
>> change.
>
> Right. This could be split into two patches, first reworking the style to give
> more flexibility with operations on registers and another one adding TDM
> specific changes, like new bitfield definitions and conditional handling of
> register accesses to account for new bitfield locations.
>
> Best regards,
> Tomasz
>

Ok. I will bisect the changes into two patches as suggested.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 6/6] clk: exynos5250: Add enum entries for divider clock of i2s1 and i2s2

[Padma Venkat]

Hi Mike,

On Thu, Jun 13, 2013 at 8:32 AM, Padma Venkat  wrote:
> Hi Mike,
>
> On Wed, Jun 12, 2013 at 10:15 PM, Mike Turquette  
> wrote:
>> Quoting Padmavathi Venna (2013-06-12 01:07:43)
>>> This patch adds enum entries for div_i2s1 and div_i2s2 which are
>>> required for i2s1 and i2s2 controllers.
>>>
>>> Signed-off-by: Padmavathi Venna 
>>
>> Looks good.  Did you want me to take the clk patches or just gathering
>> Acks?
>
> Please take the patches :).
>
> Thanks
> Padma

clk related patches in this set has some dependency on arch side
patches because one of the patch replaces all '/include's with
'#include's and adds a header file in
arch/arm/boot/include/dt-bindings/. So all these patches required to
go into one tree.

Hi Kukjin,

Can you please take all these patches into samsung-tree?

Thanks
Padma
>
>>
>> Regards,
>> Mike
>>
>>> ---
>>>  drivers/clk/samsung/clk-exynos5250.c |5 +++--
>>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
>>> b/drivers/clk/samsung/clk-exynos5250.c
>>> index 5c97e75..7c68850 100644
>>> --- a/drivers/clk/samsung/clk-exynos5250.c
>>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>>> @@ -87,6 +87,7 @@ enum exynos5250_clks {
>>> sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
>>> sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
>>> sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, 
>>> sclk_spi2,
>>> +   div_i2s1, div_i2s2,
>>>
>>> /* gate clocks */
>>> gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
>>> @@ -291,8 +292,8 @@ struct samsung_div_clock exynos5250_div_clks[] 
>>> __initdata = {
>>> DIV(none, "div_pcm1", "sclk_audio1", DIV_PERIC4, 4, 8),
>>> DIV(none, "div_audio2", "mout_audio2", DIV_PERIC4, 16, 4),
>>> DIV(none, "div_pcm2", "sclk_audio2", DIV_PERIC4, 20, 8),
>>> -   DIV(none, "div_i2s1", "sclk_audio1", DIV_PERIC5, 0, 6),
>>> -   DIV(none, "div_i2s2", "sclk_audio2", DIV_PERIC5, 8, 6),
>>> +   DIV(div_i2s1, "div_i2s1", "sclk_audio1", DIV_PERIC5, 0, 6),
>>> +   DIV(div_i2s2, "div_i2s2", "sclk_audio2", DIV_PERIC5, 8, 6),
>>> DIV(sclk_pixel, "div_hdmi_pixel", "sclk_vpll", DIV_DISP1_0, 28, 4),
>>> DIV_A(none, "armclk", "div_arm", DIV_CPU0, 28, 3, "armclk"),
>>> DIV_F(none, "div_mipi1_pre", "div_mipi1",
>>> --
>>> 1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 6/6] clk: exynos5250: Add enum entries for divider clock of i2s1 and i2s2

[Padma Venkat]

Hi Mike,

On Wed, Jun 12, 2013 at 10:15 PM, Mike Turquette  wrote:
> Quoting Padmavathi Venna (2013-06-12 01:07:43)
>> This patch adds enum entries for div_i2s1 and div_i2s2 which are
>> required for i2s1 and i2s2 controllers.
>>
>> Signed-off-by: Padmavathi Venna 
>
> Looks good.  Did you want me to take the clk patches or just gathering
> Acks?

Please take the patches :).

Thanks
Padma

>
> Regards,
> Mike
>
>> ---
>>  drivers/clk/samsung/clk-exynos5250.c |5 +++--
>>  1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
>> b/drivers/clk/samsung/clk-exynos5250.c
>> index 5c97e75..7c68850 100644
>> --- a/drivers/clk/samsung/clk-exynos5250.c
>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>> @@ -87,6 +87,7 @@ enum exynos5250_clks {
>> sclk_mmc0, sclk_mmc1, sclk_mmc2, sclk_mmc3, sclk_sata, sclk_usb3,
>> sclk_jpeg, sclk_uart0, sclk_uart1, sclk_uart2, sclk_uart3, sclk_pwm,
>> sclk_audio1, sclk_audio2, sclk_spdif, sclk_spi0, sclk_spi1, 
>> sclk_spi2,
>> +   div_i2s1, div_i2s2,
>>
>> /* gate clocks */
>> gscl0 = 256, gscl1, gscl2, gscl3, gscl_wa, gscl_wb, smmu_gscl0,
>> @@ -291,8 +292,8 @@ struct samsung_div_clock exynos5250_div_clks[] 
>> __initdata = {
>> DIV(none, "div_pcm1", "sclk_audio1", DIV_PERIC4, 4, 8),
>> DIV(none, "div_audio2", "mout_audio2", DIV_PERIC4, 16, 4),
>> DIV(none, "div_pcm2", "sclk_audio2", DIV_PERIC4, 20, 8),
>> -   DIV(none, "div_i2s1", "sclk_audio1", DIV_PERIC5, 0, 6),
>> -   DIV(none, "div_i2s2", "sclk_audio2", DIV_PERIC5, 8, 6),
>> +   DIV(div_i2s1, "div_i2s1", "sclk_audio1", DIV_PERIC5, 0, 6),
>> +   DIV(div_i2s2, "div_i2s2", "sclk_audio2", DIV_PERIC5, 8, 6),
>> DIV(sclk_pixel, "div_hdmi_pixel", "sclk_vpll", DIV_DISP1_0, 28, 4),
>> DIV_A(none, "armclk", "div_arm", DIV_CPU0, 28, 3, "armclk"),
>> DIV_F(none, "div_mipi1_pre", "div_mipi1",
>> --
>> 1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/5] clk: samsung: register audio subsystem clocks using common clock framework

[Padma Venkat]

Hi Mike,

On Wed, Jun 12, 2013 at 3:43 AM, Mike Turquette  wrote:
> Quoting Padmavathi Venna (2013-06-04 05:28:07)
>> Audio subsystem is introduced in s5pv210 and exynos platforms.
>> This has seperate clock controller which can control i2s0 and
>> pcm0 clocks. This patch registers the audio subsystem clocks
>> with the common clock framework on Exynos family.
>>
>> Signed-off-by: Padmavathi Venna 
>> Reviewed-by: Sylwester Nawrocki 
>
> This looks good to me.  You have my Ack, or I can take this patch
> through clk-next.  Let me know what works for you.

I have to rework for one small change in one of the patch in the set.
So I will do that and put your ack and will repost the patches. After
that you can take the patches through clk-next.

Thanks
Padma

>
> Regards,
> Mike
>
>> ---
>>  .../devicetree/bindings/clock/clk-exynos-audss.txt |   64 ++
>>  drivers/clk/samsung/Makefile   |1 +
>>  drivers/clk/samsung/clk-exynos-audss.c |  133 
>> 
>>  include/dt-bindings/clk/exynos-audss-clk.h |   25 
>>  4 files changed, 223 insertions(+), 0 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>>  create mode 100644 include/dt-bindings/clk/exynos-audss-clk.h
>>
>> diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt 
>> b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
>> new file mode 100644
>> index 000..a120180
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
>> @@ -0,0 +1,64 @@
>> +* Samsung Audio Subsystem Clock Controller
>> +
>> +The Samsung Audio Subsystem clock controller generates and supplies clocks
>> +to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
>> +binding described here is applicable to all SoC's in Exynos family.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following:
>> +  - "samsung,exynos4210-audss-clock" - controller compatible with all 
>> Exynos4 SoCs.
>> +  - "samsung,exynos5250-audss-clock" - controller compatible with all 
>> Exynos5 SoCs.
>> +
>> +- reg: physical base address and length of the controller's register set.
>> +
>> +- #clock-cells: should be 1.
>> +
>> +The following is the list of clocks generated by the controller. Each clock 
>> is
>> +assigned an identifier and client nodes use this identifier to specify the
>> +clock which they consume. Some of the clocks are available only on a 
>> particular
>> +Exynos4 SoC and this is specified where applicable.
>> +
>> +Provided clocks:
>> +
>> +Clock   ID  SoC (if specific)
>> +---
>> +
>> +mout_audss  0
>> +mout_i2s1
>> +dout_srp2
>> +dout_aud_bus3
>> +dout_i2s4
>> +srp_clk 5
>> +i2s_bus 6
>> +sclk_i2s7
>> +pcm_bus 8
>> +sclk_pcm9
>> +
>> +Example 1: An example of a clock controller node is listed below.
>> +
>> +clock_audss: audss-clock-controller@381 {
>> +   compatible = "samsung,exynos5250-audss-clock";
>> +   reg = <0x0381 0x0C>;
>> +   #clock-cells = <1>;
>> +};
>> +
>> +Example 2: I2S controller node that consumes the clock generated by the 
>> clock
>> +   controller. Refer to the standard clock bindings for information
>> +   about 'clocks' and 'clock-names' property.
>> +
>> +i2s0: i2s@0383 {
>> +   compatible = "samsung,i2s-v5";
>> +   reg = <0x0383 0x100>;
>> +   dmas = <&pdma0 10
>> +   &pdma0 9
>> +   &pdma0 8>;
>> +   dma-names = "tx", "rx", "tx-sec";
>> +   clocks = <&clock_audss EXYNOS_I2S_BUS>,
>> +   <&clock_audss EXYNOS_I2S_BUS>,
>> +   <&clock_audss EXYNOS_SCLK_I2S>,
>> +   <&clock_audss EXYNOS_MOUT_AUDSS>,
>> +   <&clock_audss EXYNOS_MOUT_I2S>;
>> +   clock-names = "iis", "i2s_opclk0", "i2s_opclk1",
>> +   "mout_audss", "mout_i2s";
>> +};
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index b7c232e..1876810 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o
>>  obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
>>  obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
>>  obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
>> +obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
>> diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
>> b/drivers/clk/samsung/clk-exynos-audss.c
>> new file mode 100644
>> index 000..9b1bbd5
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-exynos-audss.c
>> @@ -0,0 +1,133 @@
>> +/*
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Padmavathi Venna 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under

Re: [PATCH V5 4/5] ARM: dts: add clock provider information for i2s controllers in Exynos5250

[Padma Venkat]

Hi Doug,

On Tue, Jun 4, 2013 at 10:49 PM, Doug Anderson  wrote:
> Padmavathi,
>
> On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna  wrote:
>> @@ -471,6 +477,8 @@
>> dmas = <&pdma1 12
>> &pdma1 11>;
>> dma-names = "tx", "rx";
>> +   clocks = <&clock 307>;
>> +   clock-names = "iis";
>
> ...actually, glancing at the driver I'm a little surprised that you
> don't need to list "i2s_opclk0".  Did you test i2s1?

I didn't test i2s1 but i2s_opclk0 is also required. I will resubmit the patch.

>
>> pinctrl-names = "default";
>> pinctrl-0 = <&i2s1_bus>;
>> };
>> @@ -481,6 +489,8 @@
>> dmas = <&pdma0 12
>> &pdma0 11>;
>> dma-names = "tx", "rx";
>> +   clocks = <&clock 308>;
>> +   clock-names = "iis";
>
> ...and here.
>
>
> -Doug

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 4/4] ARM: dts: add clock provider information for i2s controllers in Exynos5250

[Padma Venkat]

Hi Doug,

On Tue, Jun 4, 2013 at 1:48 AM, Doug Anderson  wrote:
> Padmavathi,
>
> On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna  wrote:
>> +   clocks = <&clock_audss EXYNOS_I2S_BUS>,
>> +   <&clock_audss EXYNOS_I2S_BUS>,
>> +   <&clock_audss EXYNOS_SCLK_I2S>,
>> +   <&clock_audss EXYNOS_MOUT_AUDSS>,
>> +   <&clock_audss EXYNOS_MOUT_I2S>;
>> +   clock-names = "iis", "i2s_opclk0", "i2s_opclk1",
>> +   "mout_audss", "mout_i2s";
>
> Are there bindings for these clocks? Would be nice to see a
> description for what they are supposed to be.

Yes. They have bindings. I will add the description.

>
> I looked up i2s_opclk0 / i2s_opclk1 and they look reasonable at a
> quick glance. ...and it does seem right that iis and i2s_opclk0 are
> the same. ...but I don't see any place that uses the last two. Is
> there an in-flight patch?

I don't have any patch for these right now. These are used internally.
But as these are i2s0 base clocks I added here.

>
> -Doug

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 3/4] ARM: dts: add Exynos audio subsystem clock controller node

[Padma Venkat]

Hi Doug,

On Tue, Jun 4, 2013 at 1:43 AM, Doug Anderson  wrote:
> Padmavathi,
>
> On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna  wrote:
>> Audio subsystem introduced in s5pv210 and exynos platforms
>> which has a internal clock controller. This patch adds a node
>> for the same on exynos5250.
>>
>> Signed-off-by: Padmavathi Venna 
>> Reviewed-by: Sylwester Nawrocki 
>> ---
>>  arch/arm/boot/dts/exynos5250.dtsi |6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index bccda67..388983e 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -72,6 +72,12 @@
>> #clock-cells = <1>;
>> };
>>
>> +   clock_audss: audss-clock-controller@381 {

I removed this leading 0 as Tomasz Figa suggested.

>
> Nit: other places in the same file have the leading 0, like
>   i2s0: i2s@0383 {

This was the patch which got merged earlier. So I didn't modify this.
Is it okey if I remove  leading 0 for both of the nodes now?

>
> So you could follow suit and do:
>
>   clock_audss: audss-clock-controller@0381 {
>
> -Doug

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 0/4] clk: Samsung: audss: Register audio subsytem clocks using common clk framework

[Padma Venkat]

Hi Sylwester,

On Sat, Jun 1, 2013 at 1:59 PM, Sylwester Nawrocki
 wrote:
> Padmavathi,
>
>
> On 05/28/2013 12:02 PM, Padmavathi Venna wrote:
>>
>> Samsung S5PV210 and Exynos SoC has a separate subsystem for audio. This
>> subsystem
>> has a internal clock controller which controls i2s0 and pcm0 clocks. This
>> patch
>> series adds the Samsung audio subsytem clock to the common clock framework
>> and
>> provides the I2S controllers clock information in the dtsi file.
>>
>> This patch series is made based on Kukjin Kim for-next branch
>>
>> Changes since V2:
>> - Removed s5pv210 compatible name from driver as it is
>>   not yet supported which is different from Exynos series
>>   audio subsystem clock conroller.
>> - Removed clkdev lookup support and added alias names in
>>   the i2s0 controller node.
>> Changes since V1:
>>  - Reworked on all review comments by Sylwester Nawrocki
>>  - Added a header file for all clock indexes as requested by
>> Sylwester
>>  - Added different compatible names for s5pv210, exynos4 and
>> exynos5
>>  - Registered the pcm clocks with common clock framework
>
>
> Overall it looks good to me. I'm only a bit uncomfortable with using
> SAMSUNG_
> prefix for the clock index definitions. Ideally it should be something more
> specific to the SoC family. But I can't think of anything better at the
> moment.
> This covers the Exynos and S5P SoCs, hence EXYNOS_ would not be appropriate.

Actuvally I added samsung prefix when I added s5pv210 compatible name.
 But I also feel
Exynos would be better now. I will resend the patch with Exynos prefix
and with your reviewed-by.

Thanks
Padma
>
> The patch series:
> Reviewed-by: Sylwester Nawrocki 
>
> Thanks,
> Sylwester
>
>
>> Padmavathi Venna (4):
>>ARM: samsung: use #include for all device trees
>>clk: samsung: register audio subsystem clocks using common clock
>>  framework
>>ARM: dts: add Exynos audio subsystem clock controller node
>>ARM: dts: add clock provider information for i2s controllers in
>>  Exynos5250
>>
>>   .../bindings/clock/clk-samsung-audss.txt   |   64 ++
>>   arch/arm/boot/dts/exynos4.dtsi |2 +-
>>   arch/arm/boot/dts/exynos4210-origen.dts|2 +-
>>   arch/arm/boot/dts/exynos4210-smdkv310.dts  |2 +-
>>   arch/arm/boot/dts/exynos4210-trats.dts |2 +-
>>   arch/arm/boot/dts/exynos4210-universal_c210.dts|2 +-
>>   arch/arm/boot/dts/exynos4210.dtsi  |4 +-
>>   arch/arm/boot/dts/exynos4212.dtsi  |2 +-
>>   arch/arm/boot/dts/exynos4412-odroidx.dts   |2 +-
>>   arch/arm/boot/dts/exynos4412-origen.dts|2 +-
>>   arch/arm/boot/dts/exynos4412-smdk4412.dts  |2 +-
>>   arch/arm/boot/dts/exynos4412.dtsi  |2 +-
>>   arch/arm/boot/dts/exynos4x12.dtsi  |4 +-
>>   arch/arm/boot/dts/exynos5250-arndale.dts   |2 +-
>>   arch/arm/boot/dts/exynos5250-smdk5250.dts  |2 +-
>>   arch/arm/boot/dts/exynos5250-snow.dts  |4 +-
>>   arch/arm/boot/dts/exynos5250.dtsi  |   23 +++-
>>   arch/arm/boot/dts/exynos5440-sd5v1.dts |2 +-
>>   arch/arm/boot/dts/exynos5440-ssdk5440.dts  |2 +-
>>   arch/arm/boot/dts/exynos5440.dtsi  |2 +-
>>   arch/arm/boot/dts/s3c2416-smdk2416.dts |2 +-
>>   arch/arm/boot/dts/s3c2416.dtsi |4 +-
>>   arch/arm/boot/dts/s3c24xx.dtsi |2 +-
>>   drivers/clk/samsung/Makefile   |1 +
>>   drivers/clk/samsung/clk-samsung-audss.c|  133
>> 
>>   include/dt-bindings/clk/samsung-audss-clk.h|   25 
>>   26 files changed, 269 insertions(+), 27 deletions(-)
>>   create mode 100644
>> Documentation/devicetree/bindings/clock/clk-samsung-audss.txt
>>   create mode 100644 drivers/clk/samsung/clk-samsung-audss.c
>>   create mode 100644 include/dt-bindings/clk/samsung-audss-clk.h
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/3] clk: samsung: register audio subsystem clocks using common clock framework

[Padma Venkat]

Hi Tomasz,

On Fri, May 10, 2013 at 5:51 AM, Tomasz Figa  wrote:
> Hi Padmavathi,
>
> I managed to review the patch a bit more thoroughly and I had few more
> comments. You can find them inline.

Thanks for the review.

>
> On Tuesday 07 of May 2013 12:13:34 Padmavathi Venna wrote:
>> Audio subsystem is introduced in s5pv210 and exynos platforms.
>> This has seperate clock controller which can control i2s0 and
>> pcm0 clocks. This patch registers the audio subsystem clocks
>> with the common clock framework.
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  .../bindings/clock/clk-samsung-audss.txt   |   64 +
>>  drivers/clk/samsung/Makefile   |1 +
>>  drivers/clk/samsung/clk-samsung-audss.c|  137
>>  include/dt-bindings/clk/samsung-audss-clk.h
>> |   25  4 files changed, 227 insertions(+), 0 deletions(-)
>>  create mode 100644
>> Documentation/devicetree/bindings/clock/clk-samsung-audss.txt create
>> mode 100644 drivers/clk/samsung/clk-samsung-audss.c
>>  create mode 100644 include/dt-bindings/clk/samsung-audss-clk.h
>>
>> diff --git
>> a/Documentation/devicetree/bindings/clock/clk-samsung-audss.txt
>> b/Documentation/devicetree/bindings/clock/clk-samsung-audss.txt new
>> file mode 100644
>> index 000..ec2cd0b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/clk-samsung-audss.txt
>> @@ -0,0 +1,64 @@
>> +* Samsung Audio Subsystem Clock Controller
>> +
>> +The Samsung Audio Subsystem clock controller generates and supplies
>> clocks +to Audio Subsystem block available in the S5PV210 and Exynos
>> SoCs. The clock +binding described here is applicable to all SoC's in
>> the S5PV210 and Exynos +family.
>> +
>> +Required Properties:
>> +
>> +- compatible: should be one of the following:
>> +  - "samsung,s5pv210-audss-clock" - controller compatible with all
>> S5PV210 SoCs. +  - "samsung,exynos4210-audss-clock" - controller
>> compatible with all Exynos4 SoCs. +  - "samsung,exynos5250-audss-clock"
>> - controller compatible with all Exynos5 SoCs. +
>> +- reg: physical base address and length of the controller's register
>> set. +
>> +- #clock-cells: should be 1.
>> +
>> +The following is the list of clocks generated by the controller. Each
>> clock is +assigned an identifier and client nodes use this identifier
>> to specify the +clock which they consume. Some of the clocks are
>> available only on a particular +Exynos4 SoC and this is specified where
>> applicable.
>> +
>> +Provided clocks:
>> +
>> +Clock   ID  SoC (if specific)
>> +---
>> +
>> +mout_audss  0
>> +mout_i2s1
>> +dout_srp2
>> +dout_bus3
>> +dout_i2s4
>> +srp_clk 5
>> +i2s_bus 6
>> +sclk_i2s7
>> +pcm_bus 8
>> +sclk_pcm9
>> +
>> +Example 1: An example of a clock controller node is listed below.
>> +
>> +clock_audss: audss-clock-controller@0381 {
>> + compatible = "samsung,exynos5250-audss-clock";
>> + reg = <0x0381 0x0C>;
>> + #clock-cells = <1>;
>> +};
>> +
>> +Example 2: I2S controller node that consumes the clock generated by the
>> clock +   controller. Refer to the standard clock bindings for
>> information +   about 'clocks' and 'clock-names' property.
>> +
>> + i2s0: i2s@0383 {
>> + compatible = "samsung,i2s-v5";
>> + reg = <0x0383 0x100>;
>> + dmas = <&pdma0 10
>> + &pdma0 9
>> + &pdma0 8>;
>> + dma-names = "tx", "rx", "tx-sec";
>> + clocks = <&clock_audss SAMSUNG_I2S_BUS>,
>> + <&clock_audss SAMSUNG_I2S_BUS>,
>> + <&clock_audss SAMSUNG_SCLK_I2S>;
>> + clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
>> +};
>> +
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index b7c232e..5425fa8 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)  += clk.o clk-pll.o
>>  obj-$(CONFIG_ARCH_EXYNOS4)   += clk-exynos4.o
>>  obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>>  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>> +obj-$(CONFIG_PLAT_SAMSUNG)   += clk-samsung-audss.o
>> diff --git a/drivers/clk/samsung/clk-samsung-audss.c
>> b/drivers/clk/samsung/clk-samsung-audss.c new file mode 100644
>> index 000..97526b7
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-samsung-audss.c
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Padmavathi Venna 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as +
>> * published by the Free Software Foundation.
>> + *
>> + * Common Clock Framework support for Audio Subsystem Clock Controller.
>> +*/
>> +
>> +#include 
>> +#include 
>> +#inclu

Re: [PATCH V2 2/3] ARM: dts: add Exynos audio subsystem clock controller node

[Padma Venkat]

Hi Tomasz,

On Tue, May 7, 2013 at 3:24 PM, Tomasz Figa  wrote:
> Hi Padmavathi,
>
> On Tuesday 07 of May 2013 12:13:35 Padmavathi Venna wrote:
>> Audio subsystem introduced in s5pv210 and exynos platforms
>> which has a internal clock controller. This patch adds a node
>> for the same on exynos5250.
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  arch/arm/boot/dts/exynos5250.dtsi |6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi index 36c9d8d..7026de0 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -72,6 +72,12 @@
>>   #clock-cells = <1>;
>>   };
>>
>> + clock_audss: audss-clock-controller@0x0381 {
>
> Just a nitpick: this should be @381, without the 0x and leading zeroes.

Okey. I will change this.

>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Kernel and System Framework
>
>> + compatible = "samsung,exynos5250-audss-clock";
>> + reg = <0x0381 0x0C>;
>> + #clock-cells = <1>;
>> + };
>> +
>>   gic:interrupt-controller@10481000 {
>>   compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>>   #interrupt-cells = <3>;
>
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: Samsung: i2s: Fix crash in i2s driver

[Padma Venkat]

Hi Tomasz,

On Tue, May 7, 2013 at 3:20 PM, Tomasz Figa  wrote:
> Hi Padmavathi,
>
> On Tuesday 07 of May 2013 09:09:01 Padmavathi Venna wrote:
>> This patch fixes a null pointer deference in i2s driver in DT
>> case
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>
>> This patch is dependent on below patch posted by Thomas Abraham.
>> https://patchwork.kernel.org/patch/2224801/
>>
>>  sound/soc/samsung/i2s.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
>> index 7ce7c50..eaf6439 100644
>> --- a/sound/soc/samsung/i2s.c
>> +++ b/sound/soc/samsung/i2s.c
>> @@ -1182,7 +1182,7 @@ static int samsung_i2s_probe(struct platform_device
>> *pdev) pri_dai->sec_dai = sec_dai;
>>   }
>>
>> - if (i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
>> + if (i2s_pdata && i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
>
> This is a problem that needs to be fixed indeed. However the same problem
> exists in samsung_i2s_remove() as well (at least in latest linux-next).

This will go off once Thomas "ASoC: samsung: let device core setup the
default pin configuration"
patch get merged.

>
> This makes me wonder what happens with i2s_pdata in DT case. Most of drivers
> allocate a pdata struct anyway and fill it with data parsed from device tree.
> This allows rest of the code to remain unmodified and consider DT and non-DT
> cases equal.

This driver doesn't allocate the i2s_pdata in DT case. It directly
parse the information form DT file
and assign that information to i2s_dai.

Thanks
Padma

>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Kernel and System Framework
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Correct the base address of pinctrl_3

[Padma Venkat]

Hi,

On Tue, May 7, 2013 at 10:28 AM, Sascha Hauer  wrote:
> Hi,
>
> On Tue, May 07, 2013 at 09:07:33AM +0530, Padmavathi Venna wrote:
>> This patch corrects the base address of pinctrl_3 on Exynos5250
>> platform.
>
> Exynos5250 should be part of the subject so that other people can know
> whether this patch is interesting for them or not.

Okey. I will resend the patch.

Thanks
Padma
>
> Sascha
>
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] clk: Exynos: Register audio subsytem clocks using common clk framework

[Padma Venkat]

Hi Sylwester,

On Fri, Apr 5, 2013 at 6:24 PM, Sylwester Nawrocki
 wrote:
> Hi Padmavathi,
>
> On 04/05/2013 08:40 AM, Padmavathi Venna wrote:
>> Samsung Exynos SoC has a separate subsystem for audio. This subsystem
>> has a internal clock controller which controls i2s0 and pcm0 clocks.
>> This patch series adds the Samsung Exynos SoC audio subsytem clock code
>> to the common clock framework and provides the I2S0 clock information in
>> the dtsi file.
>>
>> Padmavathi Venna (3):
>>   clk: exynos: register audio subsystem clocks using common clock
>> framework
>>   ARM: dts: add Exynos audio subsystem clock controller node
>>   ARM: dts: add clock provider information for i2s0 controller in
>> Exynos5250
>>
>>  arch/arm/boot/dts/exynos5250.dtsi  |8 ++
>>  drivers/clk/samsung/Makefile   |1 +
>>  drivers/clk/samsung/clk-exynos-audss.c |  139 
>> 
>>  3 files changed, 148 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>
> It looks good, it's very similar what we have written recently for Exynos4.
> It seems the binding documentation is missing in this patch set. I've included
> below content of our .../bindings/clock/exynos4-audss-clock.txt file. Feel 
> free
> to reuse any parts of it.

Thanks for your review and help. I forgot to include documentation
file. I will reuse your's.

>
> From a brief look Exynos4 and Exynos5 Audio Subsystem CLKCON very similar.
> I've just found bit 2 of 0x0381_0008 register is not used on Exynos5250.

I added bit 2 as i2s_bus gate clock or you are pointing to something else?

>
> Additionally the Audio Subsystem Clock controller is present on S5PV210
> SoCs and IMO compatible property you used is too generic. I would propose
> to use at least:
>
> "samsung,s5pv210-audss-clock"- for S5PV210
> "samsung,exynos4210-audss-clock" - for Exynos4
> "samsung,exynos5250-audss-clock" - for Exynos5

Different compatible names means different driver files for exynos4 and 5??
I haven't seen any difference between Exynos4 and Exynos5 audio subsystem.
Can't we maintain one for both? If any extra clock instance is added
on newer SoCs
anyway it gets added at the end of the list of clocks. Please correct
me if I am wrong.

>
>
> 8<---
> * Samsung Exynos4 Audio Subsystem Clock Controller
>
> The Exynos4 Audio Subsystem clock controller generates and supplies clocks
> to Audio Subsystem block available in the Exynos4 SoCs. The clock binding
> described here is applicable to all SoC's in the Exynos4 family.
>
> Required Properties:
>
> - compatible: should be one of the following:
>   - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 
> SoCs.
>
> - reg: physical base address and length of the controller's register set.
>
> - #clock-cells: should be 1.
>
> The following is the list of clocks generated by the controller. Each clock is
> assigned an identifier and client nodes use this identifier to specify the
> clock which they consume. Some of the clocks are available only on a 
> particular
> Exynos4 SoC and this is specified where applicable.
>
> Provided clocks:
>
> Clock   ID  SoC (if specific)
> ---
>
> mout_audss  0
> dout_rp 1
> dout_aud_bus2
> mout_i2s3
> dout_i2sclk04
> clk_i2s05
> clk_pcm06
>
>
> Example 1: An example of a clock controller node is listed below.
>
> clock_audss: clock-controller@0381 {
> compatible = "samsung,exynos4-audss-clock";
> reg = <0x0381 0x0C>;
> #clock-cells = <1>;
> };
>
> Example 2: I2S controller node that consumes the clock generated by the clock
>controller. Refer to the standard clock bindings for information
>about 'clocks' and 'clock-names' property.
>
> i2s0: i2s@0383 {
> compatible = "samsung,i2s-v5";
> reg = <0x0383 0x100>;
> clocks = <&clock_audss 0>, <&clock_audss 3>, <&clock_audss 1>,
> <&clock_audss 2>, <&clock_audss 4>, <&clock_audss 2>;
> clock-names = "mout_audss", "mout_i2s", "dout_srp",
> "dout_bus", "dout_i2s", "i2s_opclk0";
> };
>
> 8<---
>
> Thanks,
> Sylwester

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] clk: exynos: register audio subsystem clocks using common clock framework

[Padma Venkat]

Hi Sylwester,

On Fri, Apr 5, 2013 at 7:23 PM, Sylwester Nawrocki
 wrote:
> On 04/05/2013 08:23 AM, Padmavathi Venna wrote:
>> Audio subsystem is introduced in exynos platforms. This has seperate
>> clock controller which can control i2s0 and pcm0 clocks. This patch
>> registers the audio subsystem clocks with the common clock framework.
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  drivers/clk/samsung/Makefile   |1 +
>>  drivers/clk/samsung/clk-exynos-audss.c |  139 
>> 
>>  2 files changed, 140 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/clk/samsung/clk-exynos-audss.c
>>
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index b7c232e..1876810 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_COMMON_CLK)  += clk.o clk-pll.o
>>  obj-$(CONFIG_ARCH_EXYNOS4)   += clk-exynos4.o
>>  obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>>  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>> +obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
>> diff --git a/drivers/clk/samsung/clk-exynos-audss.c 
>> b/drivers/clk/samsung/clk-exynos-audss.c
>> new file mode 100644
>> index 000..d7f9aa8
>> --- /dev/null
>> +++ b/drivers/clk/samsung/clk-exynos-audss.c
>> @@ -0,0 +1,139 @@
>> +/*
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Padmavathi Venna 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * Common Clock Framework support for Audio clks.
>
> s/clks/Subsystem Clock Controller ?

Ok. I will change this.

>
>> +*/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static DEFINE_SPINLOCK(lock);
>> +static struct clk **clk_table;
>> +static void __iomem *reg_base;
>> +#ifdef CONFIG_OF
>
> Is this really required ? This driver is for ARCH_EXYNOS which is
> going to be DT only anyway - presumably it would depend on OF.

I missed out to delete this. It's not required.

>
>> +static struct clk_onecell_data clk_data;
>> +#endif
>> +
>> +#define ASS_CLK_SRC 0x0
>> +#define ASS_CLK_DIV 0x4
>> +#define ASS_CLK_GATE 0x8
>> +
>> +static unsigned long reg_save[][2] = {
>> + {ASS_CLK_SRC,  0x0},
>
> nit: '0x' could be probably omitted.

Ok.

>
>> + {ASS_CLK_DIV,  0x0},
>> + {ASS_CLK_GATE, 0x0},
>> +};
>> +
>> +/*
>> + * Let each supported clock get a unique id. This id is used to lookup the 
>> clock
>> + * for device tree based platforms.
>> + *
>> + * When adding a new clock to this list, it is advised to add it to the end.
>> + * That is because the device tree source file is referring to these ids and
>> + * any change in the sequence number of existing clocks will require
>> + * corresponding change in the device tree files. This limitation would go 
>> away
>> + * when pre-processor support for dtc would be available.
>
> It's already available. Also please see [1]. IMO the best would be to
> create a header file including #defines for all the clocks indexes as
> per enum exynos_audss_clks. This header would be put in a common location
> so it can be included by the driver and the dts files.

Ok. I will include it.

>
>> + */
>> +enum exynos_audss_clks {
>> + /* audss clocks */
>> + mout_audss, mout_i2s,
>> + dout_srp, dout_bus, dout_i2s,
>> + srp_clk, i2s_bus, sclk_i2s0,
>> +
>> + nr_clks,
>> +};
>> +
>> +/* list of all parent clock list */
>> +static const char *mout_audss_p[] = { "fin_pll", "fout_epll" };
>> +static const char *mout_i2s_p[] = { "mout_audss", "cdclk0", "sclk_audio0" };
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int exynos_audss_clk_suspend(void)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < 3; i++)
>> + reg_save[i][1] = __raw_readl(reg_base + reg_save[i][0]);
>
> Why using the __raw_* accessors ? I think it should be readl().

Ok. I will change this.

>
>> +
>> + return 0;
>> +}
>> +
>> +static void exynos_audss_clk_resume(void)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < 3; i++)
>> + __raw_writel(reg_save[i][1], reg_base + reg_save[i][0]);
>
> Same here, writel().
>
>> +}
>> +
>> +static struct syscore_ops exynos_audss_clk_syscore_ops = {
>> + .suspend= exynos_audss_clk_suspend,
>> + .resume = exynos_audss_clk_resume,
>> +};
>> +#endif /* CONFIG_PM_SLEEP */
>> +
>> +/* register exynos_audss clocks */
>> +void __init exynos_audss_clk_init(struct device_node *np)
>> +{
>
> Isn't it better to just do
>
> if (np == NULL)
> return;
>
> i.e. just skip the initialization altogether ? panic() seems
> unreasonable here.

Ok. I will change this.

>
>> + if (np) {
>> + reg_base = of_iomap(np, 0);
>> + if (!reg_base)
>> + panic("%s: failed to map registers\n", __func__

Re: [PATCH V2] DMA: PL330: Add check if device tree compatible

[Padma Venkat]

Hi Vinod,

I apologies for the delayed reply. Last week I was out of station and
no access to mails. I will send another patch addressing your
comments.

Thanks
Padma
On Mon, Apr 1, 2013 at 11:51 PM, Vinod Koul  wrote:
>
> On Mon, Apr 01, 2013 at 08:13:31AM -0500, Rob Herring wrote:
> > On Thu, Mar 21, 2013 at 4:39 AM, Vinod Koul  wrote:
> > > On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
> > >> This patch register the dma controller with generic dma helpers only
> > >> in DT case. This also adds some extra error handling in the driver.
> > >>
> > >> Signed-off-by: Padmavathi Venna 
> > >> Reported-by: Sachin Kamat 
> >
> > What's the status on this? It is needed for 3.9 to fix pl330 on highbank.
> Well the status is that submitter has been rude. I had few questions and
> comments on this patch and they are yet to be addressed.
>
> --
> ~Vinod
> >
> > Rob
> >
> > >> ---
> > >>
> > >> Based on Vinod Koul next branch.
> > >>
> > >> Changes since V1:
> > >>   - return silently when of_dma_controller_register fails, as
> > >> suggested by Arnd.
> > >>
> > >>  drivers/dma/pl330.c |   38 +++---
> > >>  1 files changed, 27 insertions(+), 11 deletions(-)
> > >>
> > >> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > >> index 7181531..5dbc594 100644
> > >> --- a/drivers/dma/pl330.c
> > >> +++ b/drivers/dma/pl330.c
> > >> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct 
> > >> amba_id *id)
> > >>  {
> > >>   struct dma_pl330_platdata *pdat;
> > >>   struct dma_pl330_dmac *pdmac;
> > >> - struct dma_pl330_chan *pch;
> > >> + struct dma_pl330_chan *pch, *_p;
> > >>   struct pl330_info *pi;
> > >>   struct dma_device *pd;
> > >>   struct resource *res;
> > >> @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const 
> > >> struct amba_id *id)
> > >>   ret = dma_async_device_register(pd);
> > >>   if (ret) {
> > >>   dev_err(&adev->dev, "unable to register DMAC\n");
> > >> - goto probe_err2;
> > >> + goto probe_err3;
> > >> + }
> > >> +
> > >> + if (adev->dev.of_node) {
> > >> + ret = of_dma_controller_register(adev->dev.of_node,
> > >> +  of_dma_pl330_xlate, pdmac);
> > >> + if (ret) {
> > >> + dev_err(&adev->dev,
> > >> + "unable to register DMA to the generic DT DMA 
> > >> helpers\n");
> > > Indent?

Okey.
>
> > >> + }
> > >>   }
> > >>
> > >>   dev_info(&adev->dev,
> > >> @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const 
> > >> struct amba_id *id)
> > >>   pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
> > >>   pi->pcfg.num_peri, pi->pcfg.num_events);
> > >>
> > >> - ret = of_dma_controller_register(adev->dev.of_node,
> > >> -  of_dma_pl330_xlate, pdmac);
> > >> - if (ret) {
> > >> - dev_err(&adev->dev,
> > >> - "unable to register DMA to the generic DT DMA helpers\n");
> > >> - goto probe_err2;
> > >> - }
> > >> -
> > >>   return 0;
> > >> +probe_err3:
> > >> + amba_set_drvdata(adev, NULL);
> > >>
> > >> + /* Idle the DMAC */
> > >> + list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
> > >> + chan.device_node) {
> > >> +
> > >> + /* Remove the channel */
> > >> + list_del(&pch->chan.device_node);
> > >> +
> > >> + /* Flush the channel */
> > >> + pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
> > >> + pl330_free_chan_resources(&pch->chan);
> > > free_chan for error handling in probe?


Will remove this.

> > >
>
> > >> + }
> > >>  probe_err2:
> > >>   pl330_del(pi);
> > >>  probe_err1:
> > >> @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
> > >>   if (!pdmac)
> > >>   return 0;
> > >>
> > >> - of_dma_controller_free(adev->dev.of_node);
> > >> + if (adev->dev.of_node)
> > >> + of_dma_controller_free(adev->dev.of_node);
> > >>
> > >> + dma_async_device_unregister(&pdmac->ddma);
> > >>   amba_set_drvdata(adev, NULL);
> > >>
> > >>   /* Idle the DMAC */
> > >> --
> > >> 1.7.4.4
> > >>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: exynos4210 not booting

[Padma Venkat]

Hi,

On Fri, Mar 15, 2013 at 10:01 PM, Daniel Lezcano
 wrote:
>
> Using the exynos4_defconfig and compiling the kernel from the samsung
> git tree at 3.9-rc1, I am stuck.
>
> Does anyone have any idea ?
>
> Thanks !
>
>   -- Daniel
>
> 
>
> U-Boot 2013.01.-rc1 (Dec 08 2012 - 12:15:17) for ORIGEN
>
> CPU:Exynos4210@1000MHz
>
> Board: ORIGEN
> DRAM:  1 GiB
> WARNING: Caches not enabled
> MMC:   SAMSUNG SDHCI: 0
> In:serial
> Out:   serial
> Err:   serial
> Hit any key to stop autoboot:  0
> reading uImage
> 1385264 bytes read
> reading uInitrd
> 3780878 bytes read
> reading board.dtb
> 16717 bytes read
> ## Booting kernel from Legacy Image at 40007000 ...
>Image Name:   Linux-3.9.0-rc1
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:1385200 Bytes = 1.3 MiB
>Load Address: 40008000
>Entry Point:  40008000
>Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 4200 ...
>Image Name:   initramfs
>Image Type:   ARM Linux RAMDisk Image (uncompressed)
>Data Size:3780814 Bytes = 3.6 MiB
>Load Address: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 41f0
>Booting using the fdt blob at 0x41f0
>Loading Kernel Image ... OK
> OK
>Using Device Tree in place at 41f0, end 41f0714c
>
> Starting kernel ...

Can you please try with below patches?

This is required for non-DT case and it is not yet merged.
https://patchwork.kernel.org/patch/2218321/

For DT case below patch is required and this got merged in kgene tree.
https://patchwork.kernel.org/patch/2210621/

Thanks
Padma
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] DMA: PL330: Add check if device tree compatible

[Padma Venkat]

Hi,

On Tue, Mar 5, 2013 at 2:55 PM, Padmavathi Venna  wrote:
> This patch register the dma controller with generic dma helpers only
> in DT case. This also adds some extra error handling in the driver.
>
> Signed-off-by: Padmavathi Venna 
> Reported-by: Sachin Kamat 
> ---
>
> Based on Vinod Koul next branch.
>
> Changes since V1:
> - return silently when of_dma_controller_register fails, as
>   suggested by Arnd.
>
>  drivers/dma/pl330.c |   38 +++---
>  1 files changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 7181531..5dbc594 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct 
> amba_id *id)
>  {
> struct dma_pl330_platdata *pdat;
> struct dma_pl330_dmac *pdmac;
> -   struct dma_pl330_chan *pch;
> +   struct dma_pl330_chan *pch, *_p;
> struct pl330_info *pi;
> struct dma_device *pd;
> struct resource *res;
> @@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct 
> amba_id *id)
> ret = dma_async_device_register(pd);
> if (ret) {
> dev_err(&adev->dev, "unable to register DMAC\n");
> -   goto probe_err2;
> +   goto probe_err3;
> +   }
> +
> +   if (adev->dev.of_node) {
> +   ret = of_dma_controller_register(adev->dev.of_node,
> +of_dma_pl330_xlate, pdmac);
> +   if (ret) {
> +   dev_err(&adev->dev,
> +   "unable to register DMA to the generic DT DMA 
> helpers\n");
> +   }
> }
>
> dev_info(&adev->dev,
> @@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct 
> amba_id *id)
> pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
> pi->pcfg.num_peri, pi->pcfg.num_events);
>
> -   ret = of_dma_controller_register(adev->dev.of_node,
> -of_dma_pl330_xlate, pdmac);
> -   if (ret) {
> -   dev_err(&adev->dev,
> -   "unable to register DMA to the generic DT DMA helpers\n");
> -   goto probe_err2;
> -   }
> -
> return 0;
> +probe_err3:
> +   amba_set_drvdata(adev, NULL);
>
> +   /* Idle the DMAC */
> +   list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels,
> +   chan.device_node) {
> +
> +   /* Remove the channel */
> +   list_del(&pch->chan.device_node);
> +
> +   /* Flush the channel */
> +   pl330_control(&pch->chan, DMA_TERMINATE_ALL, 0);
> +   pl330_free_chan_resources(&pch->chan);
> +   }
>  probe_err2:
> pl330_del(pi);
>  probe_err1:
> @@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
> if (!pdmac)
> return 0;
>
> -   of_dma_controller_free(adev->dev.of_node);
> +   if (adev->dev.of_node)
> +   of_dma_controller_free(adev->dev.of_node);
>
> +   dma_async_device_unregister(&pdmac->ddma);

Any comment on this patch?

Vinod,

Can you please take this patch into your tree?

> amba_set_drvdata(adev, NULL);
>
> /* Idle the DMAC */
> --
> 1.7.4.4
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] ARM: dts: Modify SPI nodes according generic DMA DT bindings

[Padma Venkat]

Hi Kukjin,

On Tue, Mar 5, 2013 at 4:16 PM, Padmavathi Venna  wrote:
> This patch removes custom way of adding spi dma channels and
> adds according to new generic DMA DT bindings on samsung exynos4
> and exynos5440 platforms.
>
> Signed-off-by: Padmavathi Venna 
> ---
>
> Changes since V1:
> - Corrected the pdma phandle in spi1 node.
>
>  arch/arm/boot/dts/exynos4.dtsi|   15 +--
>  arch/arm/boot/dts/exynos5440.dtsi |5 +++--
>  2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 1a62bcf..4521a72 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -235,8 +235,9 @@
> compatible = "samsung,exynos4210-spi";
> reg = <0x1392 0x100>;
> interrupts = <0 66 0>;
> -   tx-dma-channel = <&pdma0 7>; /* preliminary */
> -   rx-dma-channel = <&pdma0 6>; /* preliminary */
> +   dmas = <&pdma0 7
> +   &pdma0 6>;
> +   dma-names = "tx", "rx";
> #address-cells = <1>;
> #size-cells = <0>;
> status = "disabled";
> @@ -246,8 +247,9 @@
> compatible = "samsung,exynos4210-spi";
> reg = <0x1393 0x100>;
> interrupts = <0 67 0>;
> -   tx-dma-channel = <&pdma1 7>; /* preliminary */
> -   rx-dma-channel = <&pdma1 6>; /* preliminary */
> +   dmas = <&pdma1 7
> +   &pdma1 6>;
> +   dma-names = "tx", "rx";
> #address-cells = <1>;
> #size-cells = <0>;
> status = "disabled";
> @@ -257,8 +259,9 @@
> compatible = "samsung,exynos4210-spi";
> reg = <0x1394 0x100>;
> interrupts = <0 68 0>;
> -   tx-dma-channel = <&pdma0 9>; /* preliminary */
> -   rx-dma-channel = <&pdma0 8>; /* preliminary */
> +   dmas = <&pdma0 9
> +   &pdma0 8>;
> +   dma-names = "tx", "rx";
> #address-cells = <1>;
> #size-cells = <0>;
> status = "disabled";
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
> b/arch/arm/boot/dts/exynos5440.dtsi
> index 9a99755..31a3626 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -79,8 +79,9 @@
> compatible = "samsung,exynos4210-spi";
> reg = <0xD 0x1000>;
> interrupts = <0 4 0>;
> -   tx-dma-channel = <&pdma0 5>; /* preliminary */
> -   rx-dma-channel = <&pdma0 4>; /* preliminary */
> +   dmas = <&pdma0 5
> +   &pdma0 4>;
> +   dma-names = "tx", "rx";
> #address-cells = <1>;
> #size-cells = <0>;
> };

Any comment on this patch? If not can you please take this into your tree?

Thanks
Padma
> --
> 1.7.4.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 15/23] spi: s3c64xx: move to generic dmaengine API

[Padma Venkat]

Hi Arnd,

On Tue, Mar 5, 2013 at 11:12 PM, Arnd Bergmann  wrote:
> The spi-s3c64xx uses a Samsung proprietary interface for
> talking to the DMA engine, which does not work with
> multiplatform kernels. Since the driver can also operate
> in PIO mode without any DMA, older platforms that do
> not support the DMA engine API will still work, although
> slower.
>
> The conversion was rather mechanical, since the samsung
> interface is just a shallow wrapper around the dmaengine
> interface.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/arm/plat-samsung/devs.c  |  10 +++
>  drivers/spi/spi-s3c64xx.c | 107 
> ++
>  include/linux/platform_data/spi-s3c64xx.h |   3 +
>  3 files changed, 62 insertions(+), 58 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 76209c9..58fb02a 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -10,6 +10,7 @@
>   * published by the Free Software Foundation.
>  */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1551,6 +1552,9 @@ void __init s3c64xx_spi0_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> +   pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
>  }
> @@ -1589,6 +1593,9 @@ void __init s3c64xx_spi1_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> +   pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
>  }
> @@ -1627,6 +1634,9 @@ void __init s3c64xx_spi2_set_platdata(int 
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> +   pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
>  }
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index e862ab8..9be07a6 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -22,8 +22,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,7 +33,6 @@
>  #include 
>  #include 
>
> -#include 
>  #include 
>
>  #define MAX_SPI_PORTS  3
> @@ -131,9 +132,9 @@
>  #define TXBUSY(1<<3)
>
>  struct s3c64xx_spi_dma_data {
> -   unsignedch;
> +   struct dma_chan *ch;
> enum dma_transfer_direction direction;
> -   enum dma_ch dmach;
> +   unsigned int request;
>  };
>
>  /**
> @@ -195,16 +196,11 @@ struct s3c64xx_spi_driver_data {
> unsignedcur_speed;
> struct s3c64xx_spi_dma_data rx_dma;
> struct s3c64xx_spi_dma_data tx_dma;
> -   struct samsung_dma_ops  *ops;
> struct s3c64xx_spi_port_config  *port_conf;
> unsigned intport_id;
> unsigned long   gpios[4];
>  };
>
> -static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
> -   .name = "samsung-spi-dma",
> -};
> -
>  static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
>  {
> void __iomem *regs = sdd->regs;
> @@ -285,50 +281,42 @@ static void prepare_dma(struct s3c64xx_spi_dma_data 
> *dma,
> unsigned len, dma_addr_t buf)
>  {
> struct s3c64xx_spi_driver_data *sdd;
> -   struct samsung_dma_prep info;
> -   struct samsung_dma_config config;
> +   struct dma_slave_config config;
> +   struct scatterlist sg;
> +   struct dma_async_tx_descriptor *desc;
>
> if (dma->direction == DMA_DEV_TO_MEM) {
> sdd = container_of((void *)dma,
> struct s3c64xx_spi_driver_data, rx_dma);
> -   config.direction = sdd->rx_dma.direction;
> -   config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
> -   config.width = sdd->cur_bpw / 8;
> -   sdd->ops->config(sdd->rx_dma.ch, &config);
> +   config.direction = dma->direction;
> +   config.src_addr = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
> +   config.src_addr_width = sdd->cur_bpw / 8;
> +   config.src_maxburst = 1;
> +   dmaengine_slave_config(dma->ch, &config);
> } else {
> sdd = container_of((void *)dma,
> struct s3c64xx_spi_driver_data, tx_dma);
> -   config.direction =  sdd->tx_dma.direction;
> -   config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_D

Re: [PATCH 18/23] ASoC: samsung: convert to dmaengine API

[Padma Venkat]

Hi Arnd,

On Tue, Mar 5, 2013 at 11:12 PM, Arnd Bergmann  wrote:
> In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
> we must convert all users of the Samsung private DMA interface to
> the generic dmaengine API. This converts the sound/soc drivers,
> breaking the older s3c platforms in the process, since they do not
> support the dmaengine interface yet.
>
> This patch must not get mainlined until mach-s3c* is also converted,
> but can be used for testing in the meantime.
>
> Signed-off-by: Arnd Bergmann 
> ---
>  sound/soc/samsung/ac97.c|  15 --
>  sound/soc/samsung/dma.c | 104 
> +---
>  sound/soc/samsung/dma.h |   4 +-
>  sound/soc/samsung/i2s.c |   9 +---
>  sound/soc/samsung/pcm.c |  13 -
>  sound/soc/samsung/s3c2412-i2s.c |  10 
>  sound/soc/samsung/s3c24xx-i2s.c |  10 
>  sound/soc/samsung/spdif.c   |   6 ---
>  8 files changed, 57 insertions(+), 114 deletions(-)
>
> diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c
> index c76abdf..214f454 100644
> --- a/sound/soc/samsung/ac97.c
> +++ b/sound/soc/samsung/ac97.c
> @@ -39,30 +39,15 @@ struct s3c_ac97_info {
>  };
>  static struct s3c_ac97_info s3c_ac97;
>
> -static struct s3c2410_dma_client s3c_dma_client_out = {
> -   .name = "AC97 PCMOut"
> -};
> -
> -static struct s3c2410_dma_client s3c_dma_client_in = {
> -   .name = "AC97 PCMIn"
> -};
> -
> -static struct s3c2410_dma_client s3c_dma_client_micin = {
> -   .name = "AC97 MicIn"
> -};
> -
>  static struct s3c_dma_params s3c_ac97_pcm_out = {
> -   .client = &s3c_dma_client_out,
> .dma_size   = 4,
>  };
>
>  static struct s3c_dma_params s3c_ac97_pcm_in = {
> -   .client = &s3c_dma_client_in,
> .dma_size   = 4,
>  };
>
>  static struct s3c_dma_params s3c_ac97_mic_in = {
> -   .client = &s3c_dma_client_micin,
> .dma_size   = 4,
>  };
>
> diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
> index 21b7926..67b8dcc 100644
> --- a/sound/soc/samsung/dma.c
> +++ b/sound/soc/samsung/dma.c
> @@ -16,14 +16,14 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>
>  #include 
>  #include 
>
>  #include 
> -#include 
> -#include 
>
>  #include "dma.h"
>
> @@ -67,12 +67,16 @@ static void audio_buffdone(void *data);
>   * place a dma buffer onto the queue for the dma system
>   * to handle.
>   */
> +
>  static void dma_enqueue(struct snd_pcm_substream *substream)
>  {
> struct runtime_data *prtd = substream->runtime->private_data;
> dma_addr_t pos = prtd->dma_pos;
> +   unsigned long period = prtd->dma_period;
> unsigned int limit;
> -   struct samsung_dma_prep dma_info;
> +   enum dma_transfer_direction direction;
> +   struct dma_chan *chan = prtd->params->ch;
> +   struct dma_async_tx_descriptor *desc;
>
> pr_debug("Entered %s\n", __func__);
>
> @@ -81,29 +85,30 @@ static void dma_enqueue(struct snd_pcm_substream 
> *substream)
> pr_debug("%s: loaded %d, limit %d\n",
> __func__, prtd->dma_loaded, limit);
>
> -   dma_info.cap = (samsung_dma_has_circular() ? DMA_CYCLIC : DMA_SLAVE);
> -   dma_info.direction =
> -   (substream->stream == SNDRV_PCM_STREAM_PLAYBACK
> -   ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
> -   dma_info.fp = audio_buffdone;
> -   dma_info.fp_param = substream;
> -   dma_info.period = prtd->dma_period;
> -   dma_info.len = prtd->dma_period*limit;
> +   direction = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK
> +? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
>
> while (prtd->dma_loaded < limit) {
> pr_debug("dma_loaded: %d\n", prtd->dma_loaded);
>
> -   if ((pos + dma_info.period) > prtd->dma_end) {
> -   dma_info.period  = prtd->dma_end - pos;
> +   if ((pos + period) > prtd->dma_end) {
> +   period  = prtd->dma_end - pos;
> pr_debug("%s: corrected dma len %ld\n",
> -   __func__, dma_info.period);
> +   __func__, period);
> }
>
> -   dma_info.buf = pos;
> -   prtd->params->ops->prepare(prtd->params->ch, &dma_info);
> +   desc = dmaengine_prep_dma_cyclic(chan, pos,
> +prtd->dma_period*limit, period, direction,
> +   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> +
> +   if (desc) {
> +   desc->callback = audio_buffdone;
> +   desc->callback_param = substream;
> +   dmaengine_submit(desc);
> +   }
>
> prtd->dma_loaded++;
> -   pos += prtd->dma_period;
> +   pos += period;
> if (pos >= prtd->dma_end)
> 

Re: [PATCH 1/2] ARM: exynos: pl330: Add #dma-cells for generic dma binding support

[Padma Venkat]

On Wed, Mar 6, 2013 at 4:07 AM, Arnd Bergmann  wrote:
> On Monday 04 March 2013, Padmavathi Venna wrote:
>>
>> This patch adds #dma-cells property to PL330 DMA controller
>> nodes for supporting generic dma dt bindings on samsung exynos
>> platforms. #dma-channels and #dma-requests are not required now
>> but added in advance.
>>
>> Signed-off-by: Padmavathi Venna 
>
> Acked-by: Arnd Bergmann 
>
> Should we apply these directly to the arm-soc fixes branch, or wait
> until they come back from the Samsung subarchitecture tree?

Hmm, If Kukjin can take in 3.9 rc2 it's better to go via Samsung tree.

Kukjin,

Can you please take this patch in 3.9 rc2 ?

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Modify SPI nodes according generic DMA DT bindings

[Padma Venkat]

On Tue, Mar 5, 2013 at 3:36 PM, Sachin Kamat  wrote:
> On 5 March 2013 15:34, Padmavathi Venna  wrote:
>> This patch removes custom way of adding spi dma channels and
>> adds according to new generic DMA DT bindings on samsung exynos4
>> and exynos5440 platforms.
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  arch/arm/boot/dts/exynos4.dtsi|   15 +--
>>  arch/arm/boot/dts/exynos5440.dtsi |5 +++--
>>  2 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index 1a62bcf..2449651 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -235,8 +235,9 @@
>> compatible = "samsung,exynos4210-spi";
>> reg = <0x1392 0x100>;
>> interrupts = <0 66 0>;
>> -   tx-dma-channel = <&pdma0 7>; /* preliminary */
>> -   rx-dma-channel = <&pdma0 6>; /* preliminary */
>> +   dmas = <&pdma0 7
>> +   &pdma0 6>;
>> +   dma-names = "tx", "rx";
>> #address-cells = <1>;
>> #size-cells = <0>;
>> status = "disabled";
>> @@ -246,8 +247,9 @@
>> compatible = "samsung,exynos4210-spi";
>> reg = <0x1393 0x100>;
>> interrupts = <0 67 0>;
>> -   tx-dma-channel = <&pdma1 7>; /* preliminary */
>> -   rx-dma-channel = <&pdma1 6>; /* preliminary */
>> +   dmas = <&pdma0 7
>> +   &pdma0 6>;
>
> Shouldn't these be pdma1 as was earlier?

Oops, It's my mistake. Will repost this.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dma: of-dma: return error when 'dma-cells' not found

[Padma Venkat]

On Tue, Mar 5, 2013 at 3:13 PM, Rob Herring  wrote:
> On 03/05/2013 03:25 AM, Padmavathi Venna wrote:
>> This patch returns error when 'dma-cells' property not found
>> in the corresponding device node. With out this change there
>> is a crash in the generic dma incompatible platforms.
>>
>> Signed-off-by: Padmavathi Venna 
>
> NAK.
>
> #dma-cells should be optional. It is not needed for platforms supporting
> memory to memory transfers only and should therefore be optional. You
> cannot assume the dtb can be updated and kernel changes need to work
> with old dtbs. I've submitted patches to address this and fix the crash:
>
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-February/028769.html
>

Okay.

Thanks
Padma

> Rob
>> ---
>>
>> Based on Vinod Koul next branch.
>>
>>  drivers/dma/of-dma.c |8 +++-
>>  1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
>> index 69d04d2..46aca0d 100644
>> --- a/drivers/dma/of-dma.c
>> +++ b/drivers/dma/of-dma.c
>> @@ -92,6 +92,7 @@ int of_dma_controller_register(struct device_node *np,
>>   void *data)
>>  {
>>   struct of_dma   *ofdma;
>> + const__be32 *ip;
>>   int nbcells;
>>
>>   if (!np || !of_dma_xlate) {
>> @@ -103,7 +104,12 @@ int of_dma_controller_register(struct device_node *np,
>>   if (!ofdma)
>>   return -ENOMEM;
>>
>> - nbcells = be32_to_cpup(of_get_property(np, "#dma-cells", NULL));
>> + ip = of_get_property(np, "#dma-cells", NULL);
>> + if (!ip)
>> + return -ENXIO;
>> +
>> + nbcells = be32_to_cpup(ip);
>> +
>>   if (!nbcells) {
>>   pr_err("%s: #dma-cells property is missing or invalid\n",
>>  __func__);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] DMA: PL330: Add check if device tree compatible

[Padma Venkat]

Hi Arnd,

On Mon, Mar 4, 2013 at 6:28 PM, Arnd Bergmann  wrote:
> On Monday 04 March 2013, Padmavathi Venna wrote:
>> +
>> +   if (adev->dev.of_node) {
>> +   ret = of_dma_controller_register(adev->dev.of_node,
>> +of_dma_pl330_xlate, pdmac);
>> +   if (ret) {
>> +   dev_err(&adev->dev,
>> +   "unable to register DMA to the generic DT DMA 
>> helpers\n");
>> +   goto probe_err4;
>> +   }
>> }
>
> Hmm, when I did the same thing in dw_dma, Andy commented that this should
> not be a failure at all, since the device is still usable. Could we
> instead make of_dma_controller_register return silently when it
> gets a NULL of_node?

Ok. I will do that.

Thanks
Padma
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Boot failure on Origen board using latest kernel

[Padma Venkat]

Hi,

On Sat, Mar 2, 2013 at 10:26 AM, Sachin Kamat  wrote:
> Hi Alim,
>
> On 2 March 2013 10:18, Alim Akhtar  wrote:
>> Hi Sachin,
>>
>> Looks like exynos4 is not yet moved to the generic dma binding recently
>> merged.
>>
>> Could you try out below:
>
> I forgot to mention in the previous mail that the problem was in non-dt case.
> With the below entries added in exynos4 dtsi file, it boots fine in DT case.

For non-dt case I tested on 6410 board where it is using different DMA
controller. I will a send patch to fix this.

Thanks
Padma
>
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 02/10] ASoC: SAMSUNG: Add DT support for i2s

[Padma Venkat]

Hi,

On Fri, Feb 15, 2013 at 5:31 PM, Mark Brown
 wrote:
> On Thu, Feb 14, 2013 at 09:33:00PM +0100, Sylwester Nawrocki wrote:
>
>> My apologies for the late review. It's already sixth version of this patch
>> series... But I noticed it just now when applying it for Exynos4. The GPIO
>> part of the bindings is now incompatible with Exynos4 and the bindings will
>> need to be changed. Leaving the compatibility code in the I2S driver, when
>> we could have it done well right from the beginning. If I'm not mistaken
>> a file similar to arch/arm/boot/dts/exynos4x12-pinctrl.dtsi with at least
>> entries for the I2S devices is needed and an addition of related pinctrl
>> nodes in exynos5250.dtsi. But I guess this is not something that could be
>> fixed in the -rc period ?
>
> Yes, and incremental fix would be fine.

I will send a patch for required pinctrl support soon.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 0/5] Add generic DMA DT binding support

[Padma Venkat]

Hi Vinod,

On Thu, Feb 14, 2013 at 10:17 AM, Vinod Koul  wrote:
> On Wed, Feb 13, 2013 at 09:52:30AM +0530, Padma Venkat wrote:
>> Hi Vinod,
>>
>> On Tue, Feb 12, 2013 at 8:19 PM, Vinod Koul  wrote:
>> > On Mon, Feb 11, 2013 at 02:08:20PM +0530, Padmavathi Venna wrote:
>> >
>> > This looks fine, I have only question. The code seems to assume that pl330 
>> > dma
>> > controller always uses DT. But I dont see that as dependency for pl330.
> Have you checked this?

Sorry I didn't see this comment previously. I verified on SMDK6410
board which doesn't have DT support.
I didn't see any build error and it detected the sound card.

>
>> > Something tells me withot OF the driver may not build, have you checked it?
>> >
>> >> This patch set adds support for generic dma device tree bindings for
>> >> Samsung platforms and is dependent on the following patches from
>> >> Vinod Koul next branch
>> >> 1)of: Add generic device tree DMA helpers
>> >> 2)dmaengine: add helper function to request a slave DMA channel
>> >>
>> >> This patch set is made based Mark Brown next branch
>> > Is this targetted for ASoC tree, if so why? It would fail to build if 
>> > applied
>> > there
>>
>> I have done this for my testing purpose (I expected all will directly
>> apply in your branch). But 3rd patch is not applied directly. I will
>> resend the patches after re-basing on your tree. 5th patch has to go
>> in ASoC tree because it has dependency on "ARM: SAMSUNG: Make dma
>> request compatible to generic dma bindings" which is there in ASoC
>> tree.
>>
>> Hi Mark,
>>
>> Can you please take the 5th patch in your tree(if there is no issue)
>> or should I resend it as a separate patch?
>>
>> >
>> > --
>> > ~Vinod
>> >>
>> >> Padmavathi Venna (5):
>> >>   DMA: PL330: Add new pl330 filter for DT case.
>> >>   DMA: PL330: Add xlate function
>> >>   DMA: PL330: Register the DMA controller with the generic DMA helpers
>> >>   ARM: dts: pl330: Add #dma-cells for generic dma binding support
>> >>   ARM: SAMSUNG: dma: Remove unnecessary code
>> >>
>> >>  .../devicetree/bindings/dma/arm-pl330.txt  |   21 +--
>> >>  arch/arm/boot/dts/exynos5250.dtsi  |   12 
>> >>  arch/arm/mach-s3c24xx/include/mach/dma.h   |1 -
>> >>  arch/arm/mach-s3c64xx/include/mach/dma.h   |1 -
>> >>  arch/arm/plat-samsung/dma-ops.c|   10 +---
>> >>  arch/arm/plat-samsung/include/plat/dma-ops.h   |1 -
>> >>  arch/arm/plat-samsung/include/plat/dma-pl330.h |1 -
>> >>  drivers/dma/pl330.c|   64 
>> >> +++
>> >>  8 files changed, 79 insertions(+), 32 deletions(-)
>> >>
>> >> --
>> >> 1.7.4.4
>> >>
>> Thanks
>> Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 0/5] Add generic DMA DT binding support

[Padma Venkat]

Hi Vinod,

On Tue, Feb 12, 2013 at 8:19 PM, Vinod Koul  wrote:
> On Mon, Feb 11, 2013 at 02:08:20PM +0530, Padmavathi Venna wrote:
>
> This looks fine, I have only question. The code seems to assume that pl330 dma
> controller always uses DT. But I dont see that as dependency for pl330.
>
> Something tells me withot OF the driver may not build, have you checked it?
>
>> This patch set adds support for generic dma device tree bindings for
>> Samsung platforms and is dependent on the following patches from
>> Vinod Koul next branch
>> 1)of: Add generic device tree DMA helpers
>> 2)dmaengine: add helper function to request a slave DMA channel
>>
>> This patch set is made based Mark Brown next branch
> Is this targetted for ASoC tree, if so why? It would fail to build if applied
> there

I have done this for my testing purpose (I expected all will directly
apply in your branch). But 3rd patch is not applied directly. I will
resend the patches after re-basing on your tree. 5th patch has to go
in ASoC tree because it has dependency on "ARM: SAMSUNG: Make dma
request compatible to generic dma bindings" which is there in ASoC
tree.

Hi Mark,

Can you please take the 5th patch in your tree(if there is no issue)
or should I resend it as a separate patch?

>
> --
> ~Vinod
>>
>> Padmavathi Venna (5):
>>   DMA: PL330: Add new pl330 filter for DT case.
>>   DMA: PL330: Add xlate function
>>   DMA: PL330: Register the DMA controller with the generic DMA helpers
>>   ARM: dts: pl330: Add #dma-cells for generic dma binding support
>>   ARM: SAMSUNG: dma: Remove unnecessary code
>>
>>  .../devicetree/bindings/dma/arm-pl330.txt  |   21 +--
>>  arch/arm/boot/dts/exynos5250.dtsi  |   12 
>>  arch/arm/mach-s3c24xx/include/mach/dma.h   |1 -
>>  arch/arm/mach-s3c64xx/include/mach/dma.h   |1 -
>>  arch/arm/plat-samsung/dma-ops.c|   10 +---
>>  arch/arm/plat-samsung/include/plat/dma-ops.h   |1 -
>>  arch/arm/plat-samsung/include/plat/dma-pl330.h |1 -
>>  drivers/dma/pl330.c|   64 
>> +++
>>  8 files changed, 79 insertions(+), 32 deletions(-)
>>
>> --
>> 1.7.4.4
>>
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND][PATCH] ARM: EXYNOS: Add clocks for EXYNOS I2S and PCM I/F

[Padma Venkat]

On Wed, Feb 6, 2013 at 10:51 AM, Sangsu Park  wrote:
> Audio Subsystem has own clocks for I2S0 and PCM0 in all EXYNOS series.
> This patch add clocks for I2S0 and PCM0 I/F.
>
> Signed-off-by: Sangsu Park 
> ---
>  arch/arm/mach-exynos/Makefile  |1 +
>  arch/arm/mach-exynos/clock-audss.c |   64 
> 
>  2 files changed, 65 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-exynos/clock-audss.c
>
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 7e53a3a..5b6c7c0 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -13,6 +13,7 @@ obj-  :=
>  # Core
>
>  obj-$(CONFIG_ARCH_EXYNOS)  += common.o
> +obj-$(CONFIG_ARCH_EXYNOS)  += clock-audss.o
>  obj-$(CONFIG_ARCH_EXYNOS4) += clock-exynos4.o
>  obj-$(CONFIG_CPU_EXYNOS4210)   += clock-exynos4210.o
>  obj-$(CONFIG_SOC_EXYNOS4212)   += clock-exynos4212.o
> diff --git a/arch/arm/mach-exynos/clock-audss.c
> b/arch/arm/mach-exynos/clock-audss.c
> new file mode 100644
> index 000..8260185
> --- /dev/null
> +++ b/arch/arm/mach-exynos/clock-audss.c
> @@ -0,0 +1,64 @@
> +/*
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Clock support for EXYNOS Audio Subsystem
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define EXYNOS_PA_AUDSS(0x0381)
> +
> +/* IP Clock Gate 0 Registers */
> +#define EXYNOS_AUDSS_CLKGATE_I2SBUS(1<<2)
> +#define EXYNOS_AUDSS_CLKGATE_I2SSPECIAL(1<<3)
> +#define EXYNOS_AUDSS_CLKGATE_PCMBUS(1<<4)
> +#define EXYNOS_AUDSS_CLKGATE_PCMSPECIAL(1<<5)
> +#define EXYNOS_AUDSS_CLKGATE_GPIO  (1<<6)
> +
> +static void __iomem *clk_audss_base = 0;
> +
> +static int exynos_clk_audss_ctrl(struct clk *clk, int enable)
> +{
> +   if (!clk_audss_base)
> +   return ENOMEM;
> +
> +   return s5p_gatectrl(clk_audss_base, clk, enable);
> +}
> +
> +static struct clk exynos_init_audss_clocks[] = {
> +   {
> +   .name   = "iis",
> +   .devname= "samsung-i2s.0",
> +   .enable = exynos_clk_audss_ctrl,
> +   .ctrlbit= EXYNOS_AUDSS_CLKGATE_I2SSPECIAL |
> EXYNOS_AUDSS_CLKGATE_I2SBUS
> +   | EXYNOS_AUDSS_CLKGATE_GPIO,
> +   }, {
> +   .name   = "pcm",
> +   .devname= "samsung-pcm.0",
> +   .enable = exynos_clk_audss_ctrl,
> +   .ctrlbit= EXYNOS_AUDSS_CLKGATE_PCMSPECIAL |
> EXYNOS_AUDSS_CLKGATE_PCMBUS
> +   | EXYNOS_AUDSS_CLKGATE_GPIO,
> +   },
> +};
> +
> +void __init exynos_register_audss_clocks(void)
> +{
> +   clk_audss_base = ioremap(EXYNOS_PA_AUDSS, SZ_4K);
> +   if (clk_audss_base == NULL) {

Please run checkpatch. There should be space after if.

> +   pr_err("unable to ioremap for gpio_base1\n");

Please fix the err message.

> +   return;
> +   }
> +
> +   s3c_register_clocks(exynos_init_audss_clocks,
> ARRAY_SIZE(exynos_init_audss_clocks));
> +   s3c_disable_clocks(exynos_init_audss_clocks,
> ARRAY_SIZE(exynos_init_audss_clocks));
> +}
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 4/5] ARM: dts: Add #dma-cells for generic dma binding support

[Padma Venkat]

Hi Rob,

On Wed, Feb 6, 2013 at 8:54 PM, Rob Herring  wrote:
> On 02/06/2013 12:18 AM, Padmavathi Venna wrote:
>> This patch adds #dma-cells property to PL330 DMA controller
>> nodes for supporting generic dma dt bindings on samsung
>> exynos5250 platform.
>
> The subject doesn't reflect this is for pl330.
OK. I will fix this.
>
>>
>> Signed-off-by: Padmavathi Venna 
>> Acked-by: Arnd Bergmann 
>> ---
>>  .../devicetree/bindings/dma/arm-pl330.txt  |   15 +++
>>  arch/arm/boot/dts/exynos5250.dtsi  |4 
>>  2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt 
>> b/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> index 36e27d5..1fdbff6 100644
>> --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> @@ -8,6 +8,8 @@ Required properties:
>>- reg: physical base address of the controller and length of memory mapped
>>  region.
>>- interrupts: interrupt number to the cpu.
>> +  - #dma-cells: must be <1>. used to represent the number of integer
>> +cells in the dmas property of client device.
>
> This should be optional in the case of platforms supporting only memory
> to memory xfers.

In Exynos we have support for both peripheral to peripheral and memory
to memory.
So I made it as required property. Should I make this as optional?

>
> Rob
>
>>
>>  Optional properties:
>>  - dma-coherent  : Present if dma operations are coherent
>> @@ -18,16 +20,21 @@ Example:
>>   compatible = "arm,pl330", "arm,primecell";
>>   reg = <0x1268 0x1000>;
>>   interrupts = <99>;
>> + #dma-cells = <1>;
>>   };
>>
>>  Client drivers (device nodes requiring dma transfers from dev-to-mem or
>> -mem-to-dev) should specify the DMA channel numbers using a two-value pair
>> +mem-to-dev) should specify the DMA channel numbers and dma channel names
>>  as shown below.
>>
>>[property name]  = <[phandle of the dma controller] [dma request id]>;
>> +  [property name]  = <[dma channel name]>
>>
>>where 'dma request id' is the dma request number which is connected
>> -  to the client controller. The 'property name' is recommended to be
>> -  of the form -dma-channel.
>> +  to the client controller. The 'property name' 'dmas' and 'dma-names'
>> +  as required by the generic dma device tree binding helpers. The dma
>> +  names correspond 1:1 with the dma request ids in the dmas property.
>>
>> -  Example:  tx-dma-channel = <&pdma0 12>;
>> +  Example:  dmas = <&pdma0 12
>> + &pdma1 11>;
>> + dma-names = "tx", "rx";
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index f50b4e8..724f5bd 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -312,24 +312,28 @@
>>   compatible = "arm,pl330", "arm,primecell";
>>   reg = <0x121A 0x1000>;
>>   interrupts = <0 34 0>;
>> + #dma-cells = <1>;
>>   };
>>
>>   pdma1: pdma@121B {
>>   compatible = "arm,pl330", "arm,primecell";
>>   reg = <0x121B 0x1000>;
>>   interrupts = <0 35 0>;
>> + #dma-cells = <1>;
>>   };
>>
>>   mdma0: mdma@1080 {
>>   compatible = "arm,pl330", "arm,primecell";
>>   reg = <0x1080 0x1000>;
>>   interrupts = <0 33 0>;
>> + #dma-cells = <1>;
>>   };
>>
>>   mdma1: mdma@11C1 {
>>   compatible = "arm,pl330", "arm,primecell";
>>   reg = <0x11C1 0x1000>;
>>   interrupts = <0 124 0>;
>> + #dma-cells = <1>;
>>   };
>>   };
>>
>>
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: SAMSUNG: dma: Remove unnecessary code

[Padma Venkat]

Hi Arnd,

On Tue, Feb 5, 2013 at 4:43 PM, Arnd Bergmann  wrote:
> On Tuesday 05 February 2013, Padma Venkat wrote:
>> On Mon, Feb 4, 2013 at 11:13 PM, Arnd Bergmann  wrote:
>> > On Monday 04 February 2013, Padmavathi Venna wrote:
>> >> diff --git a/arch/arm/plat-samsung/dma-ops.c 
>> >> b/arch/arm/plat-samsung/dma-ops.c
>> >> index 71d58dd..ec0d731 100644
>> >> --- a/arch/arm/plat-samsung/dma-ops.c
>> >> +++ b/arch/arm/plat-samsung/dma-ops.c
>> >> @@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch 
>> >> dma_ch,
>> >>   struct device *dev, char *ch_name)
>> >>  {
>> >>   dma_cap_mask_t mask;
>> >> - void *filter_param;
>> >>
>> >>   dma_cap_zero(mask);
>> >>   dma_cap_set(param->cap, mask);
>> >>
>> >> - /*
>> >> -  * If a dma channel property of a device node from device tree is
>> >> -  * specified, use that as the fliter parameter.
>> >> -  */
>> >> - filter_param = (dma_ch == DMACH_DT_PROP) ?
>> >> - (void *)param->dt_dmach_prop : (void *)dma_ch;
>> >> -
>> >>   if (dev->of_node)
>> >>   return (unsigned)dma_request_slave_channel(dev, ch_name);
>> >>   else
>> >>   return (unsigned)dma_request_channel(mask, pl330_filter,
>> >> - filter_param);
>> >> + (void *)dma_ch);
>> >>  }
>> >
>> > This still looks wrong to me, because the pl330_filter function now tkes
>> > a struct dma_pl330_filter_args pointer argument, not dma_ch name.
>>
>> Below is my understanding about generic dma and our discussion on
>> previous versions of my patches.
>>
>> I can’t pass single dma channel number(may be not dma_ch name in your
>> comment above) as void* argument to pl330_filter.  Because I also need
>> to compare against the dma controller device node, as my requested
>> channel can belong to any of the available dma controller on SoC.  So
>> I either need to pass pointer to dma_spec as void* argument which
>> holds the dma controller node and required channel number or I can
>> pass pointer to dma_pl330_filter_args as per your dw_dmac patches.
>
> Right.
>
>> If I pass pointer to dma_spec I can have a check like below in my
>> filter function
>> return ((chan->private == dma_spec->np) && (chan->chan_id == 
>> dma_spec->args[0]))
>>
>> Or if I pass dma_pl330_filter_args I can have a check like below.
>> return ((chan->device == &fargs->pdmac->ddma) && (chan->chan_id ==
>> fargs->chan_id));
>>
>> I modified  the pl330_filter function based on your dw_dmac patches.
>> Indeed I don’t need to pass pointer to pdmac object as 3rd arg in
>> of_dma_controller_register .  Even I pass NULL here works for me.
>> Can I pass NULL here as the third argument in of_dma_controller_register?
>
> These are all not the issues I am referring to in my comment above.
> I think it works either way, even if you pass NULL to
> of_dma_controller_register, although using it for the pdmac object
> seems cleaner to me.
>
>> Please clarify me which is best way of doing this and correct me if my
>> understanding is wrong.
>
> My point was that in the samsung_dmadev_request quoted above, you
> refer to the same pl330_filter filter function, but the argument there
> is a pointer to 'enum dma_ch', which is not compatible with any of
> the methods you list, neither the dma_pl330_filter_args nor the
> raw property.
>
> Also, if you change the calling conventions for the pl330_filter
> function, you should change both the caller and the function in the
> same patch.

In none of my patches I have changed the pl330_filter args.  This
function always takes the same argument void*. In non-DT case 'enum
dma_ch' was typecasted to void* and in DT case I am passing a pointer
to dma_pl330_filter_args and in pl330_filter function they are
converted back. In both cases it finally comes down to
dma_request_channel which takes them as void* which in turn calls the
pl330_filter.

I think this is what you are pointing to. Please let me know if I am
still wrong :( .

>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: SAMSUNG: dma: Remove unnecessary code

[Padma Venkat]

Hi Arnd,

On Mon, Feb 4, 2013 at 11:13 PM, Arnd Bergmann  wrote:
> On Monday 04 February 2013, Padmavathi Venna wrote:
>> diff --git a/arch/arm/plat-samsung/dma-ops.c 
>> b/arch/arm/plat-samsung/dma-ops.c
>> index 71d58dd..ec0d731 100644
>> --- a/arch/arm/plat-samsung/dma-ops.c
>> +++ b/arch/arm/plat-samsung/dma-ops.c
>> @@ -23,23 +23,15 @@ static unsigned samsung_dmadev_request(enum dma_ch 
>> dma_ch,
>>   struct device *dev, char *ch_name)
>>  {
>>   dma_cap_mask_t mask;
>> - void *filter_param;
>>
>>   dma_cap_zero(mask);
>>   dma_cap_set(param->cap, mask);
>>
>> - /*
>> -  * If a dma channel property of a device node from device tree is
>> -  * specified, use that as the fliter parameter.
>> -  */
>> - filter_param = (dma_ch == DMACH_DT_PROP) ?
>> - (void *)param->dt_dmach_prop : (void *)dma_ch;
>> -
>>   if (dev->of_node)
>>   return (unsigned)dma_request_slave_channel(dev, ch_name);
>>   else
>>   return (unsigned)dma_request_channel(mask, pl330_filter,
>> - filter_param);
>> + (void *)dma_ch);
>>  }
>
> This still looks wrong to me, because the pl330_filter function now tkes
> a struct dma_pl330_filter_args pointer argument, not dma_ch name.

Below is my understanding about generic dma and our discussion on
previous versions of my patches.

I can’t pass single dma channel number(may be not dma_ch name in your
comment above) as void* argument to pl330_filter.  Because I also need
to compare against the dma controller device node, as my requested
channel can belong to any of the available dma controller on SoC.  So
I either need to pass pointer to dma_spec as void* argument which
holds the dma controller node and required channel number or I can
pass pointer to dma_pl330_filter_args as per your dw_dmac patches.

If I pass pointer to dma_spec I can have a check like below in my
filter function
return ((chan->private == dma_spec->np) && (chan->chan_id == dma_spec->args[0]))

Or if I pass dma_pl330_filter_args I can have a check like below.
return ((chan->device == &fargs->pdmac->ddma) && (chan->chan_id ==
fargs->chan_id));

I modified  the pl330_filter function based on your dw_dmac patches.
Indeed I don’t need to pass pointer to pdmac object as 3rd arg in
of_dma_controller_register .  Even I pass NULL here works for me.
Can I pass NULL here as the third argument in of_dma_controller_register?
Please clarify me which is best way of doing this and correct me if my
understanding is wrong.

>
> Arnd
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.

[Padma Venkat]

On Sat, Feb 2, 2013 at 8:39 PM, Arnd Bergmann  wrote:
> On Saturday 02 February 2013 08:00:54 Padma Venkat wrote:
>
>> > The result of this looks good, but I fear that changing the filter function
>> > like this wil break all drivers that currently use the 
>> > plat-samsung/dma-ops.c
>> > code. For migration purposes, I think the best way is to change
>> > samsung_dmadev_request() to match the new filter_param format.
>> >
>> > After that is done, you can migrate all the drivers using 
>> > samsung_dma_get_ops
>> > over to the new dma_request_slave_channel interface without breaking
>> > anything when only part of the series is applied.
>> >
>> > Arnd
>>
>> Please check the below link where I made the dma request compatible to
>> both DT and non-DT
>>
>> http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
>> http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=b5be04d35dbb2e00ab27a97bfd26e17019e857ef
>>
>> Please let me know if any changes required.
>>
>
> Those two changes by themselves still look ok, I think but you
> still break the non-DT case in this 4/4 patch by changing the
> pl330_filter function in an incompatible way. You will still
> have to either change the filter_param argument in the
> samsung_dmadev_request() function, or provide separate filter
> functions, one to be used by samsung_dmadev_request and
> one for the pl330_xlate function.

I missed out to delete this part. Thanks for your point. I will send
another patch.

>
> In the long run, I think it would be better to move the slave
> drivers away from the samsung_dma wrappers and use
> dma_request_slave_channel directly, but that is an independent
> discussion.
>
> Arnd

Regards
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 4/4] DMA: PL330: Modify pl330 filter based on new generic dma dt bindings.

[Padma Venkat]

Hi Arnd,

On Fri, Feb 1, 2013 at 8:53 PM, Arnd Bergmann  wrote:
> On Friday 01 February 2013, Padmavathi Venna wrote:
>> This patch modify the filter function to filter the required channel
>> based on new filter params.
>>
>> Signed-off-by: Padmavathi Venna 
>
> The result of this looks good, but I fear that changing the filter function
> like this wil break all drivers that currently use the plat-samsung/dma-ops.c
> code. For migration purposes, I think the best way is to change
> samsung_dmadev_request() to match the new filter_param format.
>
> After that is done, you can migrate all the drivers using samsung_dma_get_ops
> over to the new dma_request_slave_channel interface without breaking
> anything when only part of the series is applied.
>
> Arnd

Please check the below link where I made the dma request compatible to
both DT and non-DT

http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=b5be04d35dbb2e00ab27a97bfd26e17019e857ef

Please let me know if any changes required.

Thanks for the suggestions.
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 07/10] ASoC: SMDK: WM8994: Add device tree support for machine file

[Padma Venkat]

On Tue, Jan 29, 2013 at 12:42 PM, Mark Brown
 wrote:
> On Fri, Jan 18, 2013 at 05:17:06PM +0530, Padmavathi Venna wrote:
>
>> +Samsung SMDK audio complex
>
> This is just for SMDKs with WM8994.  I'll apply but please send a
> followup patch to clarify this - it'll be a different binding for others
> like the older boards using WM8580 and WM9713.

OK. I will send.

>
>> + samsung,i2s-controller = <&i2s0>;
>> + samsung,audio-codec = <&wm8994>;
>
> I was thinking this should really point at the DAI but since it's
> specific to the SMDKs I don't think it particularly matters - they all
> use AIF1 anyway.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 04/10] spi: s3c64xx: Modify SPI driver to use generic DMA DT support

[Padma Venkat]

On Tue, Jan 29, 2013 at 10:49 AM, Mark Brown
 wrote:
> On Fri, Jan 18, 2013 at 05:17:03PM +0530, Padmavathi Venna wrote:
>> This patch modifies the SPI driver to use generic dma dt bindings
>> support. This passes all the required arguments to dma dev request
>> functon which in turn calls the dma_request_slave_channel or dma__
>> request_channel based on DT or non-DT respectively.
>
> This loooks OK and I'm actually applying SPI patches so I could apply it
> but I'm not sure I see the relevance of this patch to the rest of the
> series (which is about ASoC).  Is there some reason why it's included in
> this patch series or can it be applied to the SPI tree?  The SMDKs use
> I2C for their CODEC control rather than SPI.
>
> Also is there a binding document update or device tree file update to go
> with this?
>
>> + if (!sdd->pdev->dev.of_node) {
>> + res = platform_get_resource(pdev, IORESOURCE_DMA,  0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "Unable to get SPI tx dma "
>> + "resource\n");
>
> I appreciate that this is cut'n'paste from the code you're refactoring
> but please don't split error messages over lines, it makes it hard to
> grep for them in the kernel source.

OK.

Thanks for reviewing.
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 03/10] ARM: SAMSUNG: Make dma request compatible to generic dma bindings.

[Padma Venkat]

On Tue, Jan 29, 2013 at 11:50 AM, Mark Brown
 wrote:
> On Fri, Jan 18, 2013 at 05:17:02PM +0530, Padmavathi Venna wrote:
>> This patch make the dma dev request operation compatible for both
>> DT and non-DT cases. It takes the all the arguments required for
>> dma_request_slave_channel and dma_request_channel. If the driver
>> is initiated via DT or non-DT the corresponding call will be made.
>
> OK, so this is where the SPI change came from - the API has been changed
> incompatibly and SPI needs updating.  For bisection this API update
> ought to be done in a single commit, otherwise there will be steps in
> the bisection where nothing will work.
>
> Anyway, I'll go ahead and apply this, the SPI and the ASoC ones but this
> is something to bear in mind for the future.

OK. Thanks for applying the patch.

Regards
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] DMA: PL330: Add xlate function

[Padma Venkat]

Hi,

On Mon, Jan 28, 2013 at 8:28 PM, Arnd Bergmann  wrote:
> On Friday 18 January 2013, Padmavathi Venna wrote:
>> +struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
>> +   struct of_dma *ofdma)
>> +{
>> +   int count = dma_spec->args_count;
>> +   struct of_dma_filter_info *info = ofdma->of_dma_data;
>> +
>> +   if (!info || !info->filter_fn)
>> +   return NULL;
>> +
>> +   if (count != 1)
>> +   return NULL;
>> +
>> +   return dma_request_channel(info->dma_cap, info->filter_fn, dma_spec);
>> +}
>> +EXPORT_SYMBOL_GPL(of_dma_pl330_xlate);
>
> It seems a little sad that we still have to use dma_request_channel()
> to implement this, when that function will go off searching all channels
> and pass them tino the filter, which then has to look for the device node
> and match it with each channel. We already know the controller and should
> just be able to get a channel for it, although I don't exactly know how
> that is done.
>
> Further, your function is almost identical to the of_dma_simple_xlate
> function. Can't you use that one instead?

of_dma_simple_xlate is just passing the dma channel number to the
filter function. But I also need
to compare against device node as my requested channel can belong to
any of the available dma controller
on SoC. So I implemented a xlate which passes the whole dma_spec.

Thanks for reviewing the patches.

Regards
Padma

>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] ARM: dts: Add #dma-cells for generic dma binding support

[Padma Venkat]

Hi,

On Mon, Jan 28, 2013 at 8:17 PM, Arnd Bergmann  wrote:
> On Friday 18 January 2013, Padmavathi Venna wrote:
>> diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt 
>> b/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> index 36e27d5..457a233 100644
>> --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
>> @@ -8,6 +8,8 @@ Required properties:
>>- reg: physical base address of the controller and length of memory mapped
>>  region.
>>- interrupts: interrupt number to the cpu.
>> +  - #dma-cells: must be at least 1. used to represent the number of integer
>> +cells in the dmas property of client device.
>
> The wording 'at least' seems wrong here: that is what we use in the
> generic DMA binding, but in the part that is specific to one
> driver, I would expect to see
>
> - #dma-cells: must be <1>
>
> Since that is what this particular driver requires.

Okey. I will change this.

>
>>  Client drivers (device nodes requiring dma transfers from dev-to-mem or
>> @@ -27,7 +30,7 @@ as shown below.
>>[property name]  = <[phandle of the dma controller] [dma request id]>;
>>
>>where 'dma request id' is the dma request number which is connected
>> -  to the client controller. The 'property name' is recommended to be
>> -  of the form -dma-channel.
>> +  to the client controller. The 'property name' is 'dmas' as recommended
>> +  by the generic dma device tree binding helpers.
>
> s/recommended/required/
>
> Also, the "dma-names" property is required as well.

OK. I will add.

Thanks
Padma

>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 10/10] dmaengine: Fix compilation error in non-DT case

[Padma Venkat]

Hi,

On Mon, Jan 28, 2013 at 7:17 PM, Vinod Koul  wrote:
> On Fri, Jan 18, 2013 at 05:17:09PM +0530, Padmavathi Venna wrote:
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  include/linux/dmaengine.h |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> index 8cd0e25..c88f302 100644
>> --- a/include/linux/dmaengine.h
>> +++ b/include/linux/dmaengine.h
>> @@ -992,7 +992,7 @@ static inline struct dma_chan 
>> *__dma_request_channel(dma_cap_mask_t *mask,
>>  static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
>>char *name)
>>  {
>> - return NULL
>> + return NULL;
> what tree was this generated against? this was fixed by 678bd8

I generated against Kukjin for-next branch. I just noticed that it's
fixed in your next branch. I will drop this patch.

Thanks
Padma
>
> --
> ~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/2] ASoC: SAMSUNG: Add DT support for i2s

[Padma Venkat]

Hi,

On Mon, Dec 24, 2012 at 9:33 AM, Padma Venkat  wrote:
> Hi,
>
> On Sat, Dec 22, 2012 at 12:32 AM, Kukjin Kim  wrote:
>> Padma Venkat wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 19, 2012 at 10:39 PM, Mark Brown
>>>  wrote:
>>> > On Wed, Dec 19, 2012 at 01:24:14PM +, Grant Likely wrote:
>>> >> On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna
>>>  wrote:
>>> >
>>> >> > +- compatible : "samsung,samsung-i2s"
>>> >
>>> >> Isn't that kind of redundant?  :-)
>>> >
>>> >> The format of the compatible strings should be ",>> number>-i2s".
>>> >> Please be specific about the part number that you're doing the binding
>>> >> for. For example; use "samsung,exynos4210-i2s" instead of
>>> "samsung,exynos-i2s".
>>> >
>>> > There are actually versioned IPs here (where the versions are used
>>> > publically in a few places) but it's not clearly documented which is
>>> > which.  It would be reasonable to use the IP versions here I think.
>>>
>>> Samsung has three i2s drivers one for s3c24xx, one for s3c2412 and one
>>> for rest of the platforms. The above mentioned other platforms has
>>> Version 3/4/5 of i2s controllers. This dt binding is for for the i2s
>>
>> Where is the version defined such as 3, 4, 5? So, what is the
>> "sound/soc/Samsung/s3c-i2s-v2.[ch]"?
>
> Versions 3, 4, 5 are defined in dev-audio.c file of corresponding platforms.
> s3c-i2s-v2 is used in s3c2412 platform.
>
>>
>>> driver that has support for Version 3/4/5 of i2s controller. So
>>> "samsung,i2s-v5" is okay as compatible name? Please suggest me.
>>>
>> I agree with using version here but we need some consensus about that.

Any suggestions on i2s compatible name or "samsung,i2s-v5" is okay?

>>
>> - Kukjin
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Thanks
> Padma

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/2] ASoC: SAMSUNG: Add DT support for i2s

[Padma Venkat]

Hi,

On Sat, Dec 22, 2012 at 12:32 AM, Kukjin Kim  wrote:
> Padma Venkat wrote:
>>
>> Hi,
>>
>> On Wed, Dec 19, 2012 at 10:39 PM, Mark Brown
>>  wrote:
>> > On Wed, Dec 19, 2012 at 01:24:14PM +, Grant Likely wrote:
>> >> On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna
>>  wrote:
>> >
>> >> > +- compatible : "samsung,samsung-i2s"
>> >
>> >> Isn't that kind of redundant?  :-)
>> >
>> >> The format of the compatible strings should be ",> number>-i2s".
>> >> Please be specific about the part number that you're doing the binding
>> >> for. For example; use "samsung,exynos4210-i2s" instead of
>> "samsung,exynos-i2s".
>> >
>> > There are actually versioned IPs here (where the versions are used
>> > publically in a few places) but it's not clearly documented which is
>> > which.  It would be reasonable to use the IP versions here I think.
>>
>> Samsung has three i2s drivers one for s3c24xx, one for s3c2412 and one
>> for rest of the platforms. The above mentioned other platforms has
>> Version 3/4/5 of i2s controllers. This dt binding is for for the i2s
>
> Where is the version defined such as 3, 4, 5? So, what is the
> "sound/soc/Samsung/s3c-i2s-v2.[ch]"?

Versions 3, 4, 5 are defined in dev-audio.c file of corresponding platforms.
s3c-i2s-v2 is used in s3c2412 platform.

>
>> driver that has support for Version 3/4/5 of i2s controller. So
>> "samsung,i2s-v5" is okay as compatible name? Please suggest me.
>>
> I agree with using version here but we need some consensus about that.
>
> - Kukjin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/2] ASoC: SAMSUNG: Add DT support for i2s

[Padma Venkat]

Hi,

On Wed, Dec 19, 2012 at 10:39 PM, Mark Brown
 wrote:
> On Wed, Dec 19, 2012 at 01:24:14PM +, Grant Likely wrote:
>> On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna  
>> wrote:
>
>> > +- compatible : "samsung,samsung-i2s"
>
>> Isn't that kind of redundant?  :-)
>
>> The format of the compatible strings should be ",-i2s".
>> Please be specific about the part number that you're doing the binding
>> for. For example; use "samsung,exynos4210-i2s" instead of 
>> "samsung,exynos-i2s".
>
> There are actually versioned IPs here (where the versions are used
> publically in a few places) but it's not clearly documented which is
> which.  It would be reasonable to use the IP versions here I think.

Samsung has three i2s drivers one for s3c24xx, one for s3c2412 and one
for rest of the platforms. The above mentioned other platforms has
Version 3/4/5 of i2s controllers. This dt binding is for for the i2s
driver that has support for Version 3/4/5 of i2s controller. So
"samsung,i2s-v5" is okay as compatible name? Please suggest me.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: EXYNOS: Fix compile error in dev-audio.c

[Padma Venkat]

Hi,

On Mon, Dec 17, 2012 at 6:12 AM, Olof Johansson  wrote:
> On Fri, Dec 14, 2012 at 12:15 AM, Jonghwan Choi  
> wrote:
>> arch/arm/mach-exynos/dev-audio.c:58:4: error: unknown field 'src_clk'
>> specified in initializer
>> arch/arm/mach-exynos/dev-audio.c:58:4: warning: initialization makes integer
>> from pointer without a cast [enabled by default]
>> arch/arm/mach-exynos/dev-audio.c:58:4: warning: (near initialization for
>> 'i2sv5_pdata.type.i2s.idma_addr') [enabled by default]
>> arch/arm/mach-exynos/dev-audio.c:91:4: error: unknown field 'src_clk'
>> specified in initializer
>> arch/arm/mach-exynos/dev-audio.c:91:4: warning: initialization makes integer
>> from pointer without a cast [enabled by default]
>> arch/arm/mach-exynos/dev-audio.c:91:4: warning: (near initialization for
>> 'i2sv3_pdata.type.i2s.idma_addr') [enabled by default]
>>
>> Signed-off-by: Jonghwan Choi 
>
> This only fixes one of many build errors caused by the i2s change:
>
>   1 arch/arm/mach-s3c64xx/dev-audio.c:113:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s3c64xx/dev-audio.c:113:4: warning: (near
> initialization for 'i2sv4_pdata.type.i2s.idma_addr') [enabled by
> default]
>   1 arch/arm/mach-s3c64xx/dev-audio.c:69:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s3c64xx/dev-audio.c:69:4: warning: (near
> initialization for 'i2sv3_pdata.type.i2s.quirks') [enabled by default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:115:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:115:4: warning: (near
> initialization for 's5p6450_i2s_pdata.type.i2s.quirks') [enabled by
> default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:48:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:48:4: warning: (near
> initialization for 's5p6440_i2s_pdata.type.i2s.idma_addr') [enabled by
> default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:96:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5p64x0/dev-audio.c:96:4: warning: (near
> initialization for 's5p6450_i2s0_pdata.type.i2s.idma_addr') [enabled
> by default]
>   1 arch/arm/mach-s5pc100/dev-audio.c:53:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5pc100/dev-audio.c:53:4: warning: (near
> initialization for 'i2sv5_pdata.type.i2s.idma_addr') [enabled by
> default]
>   1 arch/arm/mach-s5pc100/dev-audio.c:84:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5pc100/dev-audio.c:84:4: warning: (near
> initialization for 'i2sv3_pdata.type.i2s.quirks') [enabled by default]
>   1 arch/arm/mach-s5pv210/dev-audio.c:55:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5pv210/dev-audio.c:55:4: warning: (near
> initialization for 'i2sv5_pdata.type.i2s.idma_addr') [enabled by
> default]
>   1 arch/arm/mach-s5pv210/dev-audio.c:87:4: warning:
> initialization makes integer from pointer without a cast [enabled by
> default]
>   1 arch/arm/mach-s5pv210/dev-audio.c:87:4: warning: (near
> initialization for 'i2sv3_pdata.type.i2s.quirks') [enabled by default]
>
>
> Looks like the breakage was caused by the following commit:
>
> commit 1974a042dd15f1f007a3a1a2dd7a23ca0e42c01d
> Author: Padmavathi Venna 
> AuthorDate: Wed Nov 28 16:17:48 2012 +0530
> Commit: Mark Brown 
> CommitDate: Wed Nov 28 19:18:00 2012 +
>
> ASoC: Samsung: Get I2S src_clk from clock alias id.
>
> Padmavathi, you can't send out code that breaks all Samsung platforms
> like this, even if there are patches out there that fixes it. Changes
> have to be bisectable, which means that you can't break and unbreak
> the build, least of all if you merge through different maintainers.
> And you need to tell the other maintainer that there are dependent
> patches, you just sent the above patch to Mark without any such
> information.

In V3, as I posted all the patches together I didn't mention about the
dependency. But I could have mentioned about it in V4. I apologize for
the build break.

>
> Kukjin, I see that Padmavathi has posted a V3 series of patches to
> remove all this from the dev-audio files on November 23. Are you ok
> with us picking them up and sending ASAP?

Kukjin, Could you please give your conformation for the above patches?

>
>
> -Olof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks
Padma
--
To unsubscribe from this list: send the line "unsub

Re: [PATCH V4 0/2] Add DT support for i2s

[Padma Venkat]

Hi Mark,

On Sun, Dec 9, 2012 at 12:56 PM, Mark Brown
 wrote:
> On Sat, Dec 08, 2012 at 10:07:54AM +0530, Padma Venkat wrote:
>
>> Samsung i2s driver registers the platform device twice one for the
>> samsung-i2s.0,1 or 2 and two for samsung-i2s.4(which actually doesn't
>> represent any H/W peripheral). The max number of I2S blocks on any
>> Samsung SoC are 3, the secondary device registration starts with
>> device number 4.The second time registration is for the secondary fifo
>> interface of a CPU dai if any exists.
>
>> With DT support the device number in the driver is always -1, I used
>> alias id for the above purpose.
>
> So, the thing here is that while the numbers were totally OK for
> platform device use they really don't fit into DT at all well.  I think
> the thing here is to either have a node for the second CPU side DAI or
> to have a single DT link automatically expanded into two DAI links.  I
> think the second option is much better - there's only one link on the
> board, it just happens to get expanded into two the way things are
> currently implemented in ASoC.

Could you please explain me in more detail about "single DT link
automatically expanded into two DAI links".
How this can be done?

>
> This stuff probably also ought to be moved over to soc-pcm as well by
> the way.
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 0/2] Add DT support for i2s

[Padma Venkat]

Hi,

On Fri, Dec 7, 2012 at 7:21 PM, Grant Likely  wrote:
> On Thu, 6 Dec 2012 13:11:42 +0900, Mark Brown 
>  wrote:
>> On Thu, Dec 06, 2012 at 09:31:40AM +0530, Padma Venkat wrote:
>> > On Wed, Nov 28, 2012 at 4:17 PM, Padmavathi Venna  
>> > wrote:
>>
>> > > Padmavathi Venna (2):
>> > >   ASoC: Samsung: Get I2S src_clk from clock alias id.
>> > >   ASoC: SAMSUNG: Add DT support for i2s
>>
>> > Any comments on DT support for i2s patch?  If not when this patch can be 
>> > pulled?
>>
>> Don't send contentless pings.
>>
>> I still don't really like what's going on with aliases here, I need to
>> understand why things are structured the way they are to say something
>> about that.
>
> Right. On a brief look, it appears that the binding is using aliases as
> a way to encode implementation specific details of the driver.

Samsung i2s driver registers the platform device twice one for the
samsung-i2s.0,1 or 2 and two for samsung-i2s.4(which actually doesn't
represent any H/W peripheral). The max number of I2S blocks on any
Samsung SoC are 3, the secondary device registration starts with
device number 4.The second time registration is for the secondary fifo
interface of a CPU dai if any exists.

With DT support the device number in the driver is always -1, I used
alias id for the above purpose.

>
> g.
>
Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] ASoC: Samsung: Do not register samsung audio dma device as pdev

[Padma Venkat]

Hi Mark,

On Fri, Dec 7, 2012 at 12:16 PM, Mark Brown
 wrote:
> On Thu, Dec 06, 2012 at 09:20:36AM +0530, Padmavathi Venna wrote:
>> Previously, the ASoC 'platform' (PCM/DMA) object was instantiated via a
>> platform_device. This didn't represent the hardware well, since there
>> was no separate hardware associated with this platform_device; it was a
>> virtual device with sole purpose to call snd_soc_register_platform().
>
> Looks good however this doesn't apply against my topic/samsung branch -
> can you please check if I need anything from Kukjin's tree?  Though I
> guess the easiest thing is just to wait until the merge window is over,
> we're near to the next release.

I will resend the patches re-based on your topic/samsung branch.

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 0/2] Add DT support for i2s

[Padma Venkat]

Hi Mark,

On Wed, Nov 28, 2012 at 4:17 PM, Padmavathi Venna  wrote:
> V4 patches are based on Mark Brown's for-next branch of
> "git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git"
>
> Changes since V3:
> - Added syntex of gpio specifier as suggested by Mark Brown in
>   DT document file
> - Added the requirement for having I2S alias ids
> - Explained about gpio lines
> - Made a seperate patch to get the I2S rclk src clk from alias ID
>
> Changes since V2:
> - Rebased on 3.7-rc3
> - Custom DT bindings are prefixed with samsung
> - As generic device tree DMA helpers not yet mainlined
>   I am still using custom dma bindings. So added a
>   priliminary statement regarding the same. I will rework
>   on my patch once generic DMA helpers are mainlined.
>
> Chnages since V1:
> - Rebased on 3.6-rc6
>
> Padmavathi Venna (2):
>   ASoC: Samsung: Get I2S src_clk from clock alias id.
>   ASoC: SAMSUNG: Add DT support for i2s

Any comments on DT support for i2s patch?  If not when this patch can be pulled?

>
>  .../devicetree/bindings/sound/samsung-i2s.txt  |   78 +++
>  include/linux/platform_data/asoc-s3c.h |6 -
>  sound/soc/samsung/dma.c|1 +
>  sound/soc/samsung/dma.h|1 +
>  sound/soc/samsung/i2s.c|  238 +++
>  5 files changed, 268 insertions(+), 56 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/sound/samsung-i2s.txt
>
> --
> 1.7.4.4
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ASoC: Samsung: Updates for v3.8

[Padma Venkat]

Hi Mark,

On Wed, Nov 28, 2012 at 10:55 AM, Sangbeom Kim  wrote:
>> > There's some problems with this binding.  The main one is the gpios
>> > property the format of which isn't specified at all.
>
>> All of above gpio property is i2s.
>> That is,
>> + gpios = <&gpz 0 2 0 0>, -> SCLK
>> + <&gpz 1 2 0 0>,   ->  CDCLK
>> + <&gpz 2 2 0 0>,   -> LRCK
>> + <&gpz 3 2 0 0>,   -> SDI
>> + <&gpz 4 2 0 0>,   -> SDO[0]
>> + <&gpz 5 2 0 0>,   -> SDO[1]
>> + <&gpz 6 2 0 0>;   -> SDO[2]
>
>> Do you want like a below one?
>> +sclk-gpios = <&gpz 0 2 0 0>,
>> +cdclk-gpios = <&gpz 1 2 0 0>, ...
>
> That would be nice but what I was really looking for was some indiciation in 
> the binding document as
> to what all this stuff means - it should really say what gpz is (though I can 
> figure that out) and
> it definitely needs to say what the four numbers are.
>
>> > The requirement for an alias is also very odd, where does that come from?
>
>> I don't know that Which one is odd. Please let me know.
>
> Having them at all is odd - it's not something other DT bindings have needed 
> and there was nothing
> saying what it was for.

What is the exact requirement here? Should I remove the alias ids or
I2S1 and I2S2 nodes as they are in disabled state? This is done same
way as SPI and I2C. Please explain me.

>
>> > Some of the code also looks very peculiar, like the fact that it's
>> > generating a clock name i2s_opclk%d rather than hard coding the
>> > clock, the physical clock would normally be resolved based on the
>> > struct device.
>
>> This is to handle all of Samsung SOCs i2c clock mux.
>> Please look at below clk_lookup table
>
>> In case of 6410, clk_lookup
>> + CLKDEV_INIT("samsung-i2s.0", "i2s_opclk0", &clk_i2s0),
>> + CLKDEV_INIT("samsung-i2s.0", "i2s_opclk1", &clk_audio_bus0.clk),
>> + CLKDEV_INIT("samsung-i2s.1", "i2s_opclk0", &clk_i2s1),
>> + CLKDEV_INIT("samsung-i2s.1", "i2s_opclk1", &clk_audio_bus1.clk),
>> +#ifdef CONFIG_CPU_S3C6410
>> + CLKDEV_INIT("samsung-i2s.2", "i2s_opclk0", &clk_i2s2),
>> + CLKDEV_INIT("samsung-i2s.2", "i2s_opclk1", &clk_audio_bus2.clk),
>
>> In case of exynos5, clk_lookup
>> + CLKDEV_INIT("samsung-i2s.0", "i2s_opclk0", &exynos5_clk_sclk_i2s.clk),
>> + CLKDEV_INIT("samsung-i2s.0", "i2s_opclk1",
>> +&exynos5_clk_i2s_bus.clk),
>
>> We try to handle clock source of i2s by only i2s_opclk0 and i2s_opclk1.
>> Each SOCs have different clock source.
>> Is this wrong approach?
>
> That makes sense but why is the driver not just requesting by name rather 
> than having code to
> generate the names, and why is this mixed in with the patch adding DT support?
>

Thanks
Padma
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html