Re: dmaengine: dw-dmac: Custom cyclic API (Why?)

[Jose Abreu]

++dw-dmac Maintainers


On 30-12-2016 11:32, Jose Abreu wrote:
> Hi All,
>
>
> I am going to work with dw-dmac AHB controller and I wanted to
> use SND_DMAENGINE_PCM. In order to use this, a standard DMA
> driver with cyclic support is needed. I found out that dw-dmac is
> capable of cyclic transfers but instead of using the DMA engine
> standard cyclic API it uses a custom API. Is there any specific
> reason for this? What is the effort to change the custom API to a
> standard DMA engine cyclic API?
>
>
> Best regards,
>
> Jose Miguel Abreu
>

dmaengine: dw-dmac: Custom cyclic API (Why?)

[Jose Abreu]

Hi All,


I am going to work with dw-dmac AHB controller and I wanted to
use SND_DMAENGINE_PCM. In order to use this, a standard DMA
driver with cyclic support is needed. I found out that dw-dmac is
capable of cyclic transfers but instead of using the DMA engine
standard cyclic API it uses a custom API. Is there any specific
reason for this? What is the effort to change the custom API to a
standard DMA engine cyclic API?


Best regards,

Jose Miguel Abreu

[PATCH 2/2] ASoC: dwc: Enable 24 bit sample size in PIO mode

[Jose Abreu]

Sample size of 24 bits use in reality 32 bits for storage. We
can safelly enable this sample size and treat the data as
32 bits.

Tested in a x86_64 platform and in ARC AXS101 SDP platform.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/dwc/designware_pcm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/dwc/designware_pcm.c b/sound/soc/dwc/designware_pcm.c
index b063c86..459ec86 100644
--- a/sound/soc/dwc/designware_pcm.c
+++ b/sound/soc/dwc/designware_pcm.c
@@ -80,6 +80,7 @@
.rate_min = 32000,
.rate_max = 48000,
.formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE |
SNDRV_PCM_FMTBIT_S32_LE,
.channels_min = 2,
.channels_max = 2,
@@ -175,6 +176,7 @@ static int dw_pcm_hw_params(struct snd_pcm_substream 
*substream,
dev->tx_fn = dw_pcm_tx_16;
dev->rx_fn = dw_pcm_rx_16;
break;
+   case SNDRV_PCM_FORMAT_S24_LE:
case SNDRV_PCM_FORMAT_S32_LE:
dev->tx_fn = dw_pcm_tx_32;
dev->rx_fn = dw_pcm_rx_32;
-- 
1.9.1

[PATCH 1/2] ASoC: dwc: Add record capability in PIO mode

[Jose Abreu]

Up until now PIO mode offered only playback support. With
this patch we add support for record mode. The PCM was
refactored so that we could reuse the existing infrastructure
without many changes.

We have support for 16 and 32 bits of sample size using
only 2 channels.

Tested in a x86_64 platform and in ARC AXS101 SDP platform.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/dwc/designware_i2s.c |  9 +++-
 sound/soc/dwc/designware_pcm.c | 97 +-
 sound/soc/dwc/local.h  |  9 +++-
 3 files changed, 92 insertions(+), 23 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index bdf8398..9c46e41 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -121,9 +121,14 @@ static irqreturn_t i2s_irq_handler(int irq, void *dev_id)
irq_valid = true;
}
 
-   /* Data available. Record mode not supported in PIO mode */
-   if (isr[i] & ISR_RXDA)
+   /*
+* Data available. Retrieve samples from FIFO
+* NOTE: Only two channels supported
+*/
+   if ((isr[i] & ISR_RXDA) && (i == 0) && dev->use_pio) {
+   dw_pcm_pop_rx(dev);
irq_valid = true;
+   }
 
/* Error Handling: TX */
if (isr[i] & ISR_TXFO) {
diff --git a/sound/soc/dwc/designware_pcm.c b/sound/soc/dwc/designware_pcm.c
index 4a83a22..b063c86 100644
--- a/sound/soc/dwc/designware_pcm.c
+++ b/sound/soc/dwc/designware_pcm.c
@@ -41,10 +41,33 @@
return tx_ptr; \
 }
 
+#define dw_pcm_rx_fn(sample_bits) \
+static unsigned int dw_pcm_rx_##sample_bits(struct dw_i2s_dev *dev, \
+   struct snd_pcm_runtime *runtime, unsigned int rx_ptr, \
+   bool *period_elapsed) \
+{ \
+   u##sample_bits (*p)[2] = (void *)runtime->dma_area; \
+   unsigned int period_pos = rx_ptr % runtime->period_size; \
+   int i; \
+\
+   for (i = 0; i < dev->fifo_th; i++) { \
+   p[rx_ptr][0] = ioread32(dev->i2s_base + LRBR_LTHR(0)); \
+   p[rx_ptr][1] = ioread32(dev->i2s_base + RRBR_RTHR(0)); \
+   period_pos++; \
+   if (++rx_ptr >= runtime->buffer_size) \
+   rx_ptr = 0; \
+   } \
+   *period_elapsed = period_pos >= runtime->period_size; \
+   return rx_ptr; \
+}
+
 dw_pcm_tx_fn(16);
 dw_pcm_tx_fn(32);
+dw_pcm_rx_fn(16);
+dw_pcm_rx_fn(32);
 
 #undef dw_pcm_tx_fn
+#undef dw_pcm_rx_fn
 
 static const struct snd_pcm_hardware dw_pcm_hardware = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
@@ -68,27 +91,51 @@
.fifo_size = 16,
 };
 
-void dw_pcm_push_tx(struct dw_i2s_dev *dev)
+static void dw_pcm_transfer(struct dw_i2s_dev *dev, bool push)
 {
-   struct snd_pcm_substream *tx_substream;
-   bool tx_active, period_elapsed;
+   struct snd_pcm_substream *substream;
+   bool active, period_elapsed;
 
rcu_read_lock();
-   tx_substream = rcu_dereference(dev->tx_substream);
-   tx_active = tx_substream && snd_pcm_running(tx_substream);
-   if (tx_active) {
-   unsigned int tx_ptr = READ_ONCE(dev->tx_ptr);
-   unsigned int new_tx_ptr = dev->tx_fn(dev, tx_substream->runtime,
-   tx_ptr, &period_elapsed);
-   cmpxchg(&dev->tx_ptr, tx_ptr, new_tx_ptr);
+   if (push)
+   substream = rcu_dereference(dev->tx_substream);
+   else
+   substream = rcu_dereference(dev->rx_substream);
+   active = substream && snd_pcm_running(substream);
+   if (active) {
+   unsigned int ptr;
+   unsigned int new_ptr;
+
+   if (push) {
+   ptr = READ_ONCE(dev->tx_ptr);
+   new_ptr = dev->tx_fn(dev, substream->runtime, ptr,
+   &period_elapsed);
+   cmpxchg(&dev->tx_ptr, ptr, new_ptr);
+   } else {
+   ptr = READ_ONCE(dev->rx_ptr);
+   new_ptr = dev->rx_fn(dev, substream->runtime, ptr,
+   &period_elapsed);
+   cmpxchg(&dev->rx_ptr, ptr, new_ptr);
+   }
 
if (period_elapsed)
-   snd_pcm_period_elapsed(tx_substream);
+   snd_pcm_period_elapsed(substream);
}
rcu_read_unlock();
 }
+
+void dw_pcm_push_tx(struct dw_i2s_dev *dev)
+{
+   dw_pcm_transfer(dev, true);
+}
 EXPORT_SYMBOL_GPL(dw_pcm_push_tx);
 
+void dw_pcm_pop_rx(struct

Re: [PATCH v2 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Jose Abreu]

Hi Kedar,


On 23-12-2016 08:52, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v2:
> ---> Fixed race conditions in the driver as suggested by Jose Abreu
> ---> Fixed unnecessray if else checks in the vdma_start_transfer
>  as suggested by Laurent Pinchart.
>
>  drivers/dma/xilinx/xilinx_dma.c | 54 
> +++--
>  1 file changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index be7eb41..cf9edd8 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1052,25 +1052,38 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (chan->has_sg) {
>   dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
>   tail_segment->phys);
> + list_splice_tail_init(&chan->pending_list, &chan->active_list);
> + chan->desc_pendingcount = 0;
>   } else {
>   struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>  
>   if (chan->desc_submitcount < chan->num_frms)
>   i = chan->desc_submitcount;
>  
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> +   XILINX_VDMA_REG_START_ADDRESS_64(i++),
> +   segment->hw.buf_addr,
> +   segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> + XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
> +
> + last = segment;
> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;
> + if (list_empty(&chan->pending_list) ||
> + (i == chan->num_frms))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct xilinx_dma_tx_descriptor,
> + node);
>   }
>  
>   if (!last)
> @@ -1081,20 +1094,14 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
>   last->hw.stride);
>   vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);

What if we reach here and j < num_frms? It can happen because if
the pending list is empty the loop breaks. Then VDMA will start
with framebuffers having address 0x0. You should only program
vsize when j > num_frms or when we have already previously set
the framebuffers (i.e. when submitcount has already been
incremented num_frms at least once).

Best regards,
Jose Miguel Abreu

> - }
>  
> - chan->idle = false;
> - if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submi

Re: [PATCH 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Jose Abreu]

Hi Kedar,


On 15-12-2016 19:09, Appana Durga Kedareswara Rao wrote:
> Hi Jose Miguel Abreu,
>
>   Thanks for the review
>
>>> -   last = segment;
>>> +   for (j = 0; j < chan->num_frms; ) {
>>> +   list_for_each_entry(segment, &desc->segments, node)
>> {
>>> +   if (chan->ext_addr)
>>> +   vdma_desc_write_64(chan,
>>> +
>> XILINX_VDMA_REG_START_ADDRESS_64(i++),
>>> + segment->hw.buf_addr,
>>> + segment->hw.buf_addr_msb);
>>> +   else
>>> +   vdma_desc_write(chan,
>>> +
>> XILINX_VDMA_REG_START_ADDRESS(i++),
>>> +   segment->hw.buf_addr);
>>> +
>>> +   last = segment;
>> Hmm, is it possible to submit more than one segment? If so, then i and j 
>> will get
>> out of sync.
> If h/w is configured for more than 1 frame buffer and user submits more than 
> one frame buffer
> We can submit more than one frame/ segment to hw right??

I'm not sure. When I used VDMA driver I always submitted only one
segment and multiple descriptors. But the problem is, for example:

If you have:
descriptor1 (2 segments)
descriptor2 (2 segments)

And you have 3 frame buffers in the HW.

Then:
1st frame buffer will have: descriptor1 -> segment1
2nd frame buffer will have: descriptor1 -> segment2
3rd frame buffer will have: descriptor2 -> segment1
but, 4th frame buffer will have: descriptor2 -> segment2 <
INVALID because there is only 3 frame buffers

So, maybe a check inside the loop "list_for_each_entry(segment,
&desc->segments, node)" could be a nice to have.

>
>>> +   }
>>> +   list_del(&desc->node);
>>> +   list_add_tail(&desc->node, &chan->active_list);
>>> +   j++;
>> But if i is non zero and pending_list has more than num_frms then i will not
>> wrap-around as it should and will write to invalid framebuffer location, 
>> right?
> Yep will fix in v2...
>   
>   If (if (list_empty(&chan->pending_list)) || (i == chan->num_frms)
>   break;
>
> Above condition is sufficient right???

Looks ok.

>
>>> +   if (list_empty(&chan->pending_list))
>>> +   break;
>>> +   desc = list_first_entry(&chan->pending_list,
>>> +   struct
>> xilinx_dma_tx_descriptor,
>>> +   node);
>>> }
>>>
>>> if (!last)
>>> @@ -1114,14 +1124,13 @@ static void xilinx_vdma_start_transfer(struct
>> xilinx_dma_chan *chan)
>>> vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
>>> last->hw.stride);
>>> vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last-
>>> hw.vsize);
>> Maybe a check that all framebuffers contain valid addresses should be done
>> before programming vsize so that VDMA does not try to write to invalid
>> addresses.
> Do we really need to check for valid address??? 
> I didn't get you what to do you mean by invalid address could you please 
> explain???
> In the driver we are reading form the pending_list which will be updated by 
> pep_interleaved_dma 
> Call so we are under assumption that user sends the proper address right???

What I mean by valid address is to check that i variable has
already been incremented by num_frms at least once since a VDMA
reset. This way you know that you have programmed all the
addresses of the frame buffers with an address and they are non-zero.

Best regards,
Jose Miguel Abreu

>
>>> +
>>> +   chan->desc_submitcount += j;
>>> +   chan->desc_pendingcount -= j;
>>> }
>>>
>>> chan->idle = false;
>>> if (!chan->has_sg) {
>>> -   list_del(&desc->node);
>>> -   list_add_tail(&desc->node, &chan->active_list);
>>> -   chan->desc_submitcount++;
>>> -   chan->desc_pendingcount--;
>>> if (chan->desc_submitcount == chan->num_frms)
>>> chan->desc_submitcount = 0;
>> "desc_submitcount >= chan->num_frms would be safer here.
> Sure will fix in v2...
>
> Regards,
> Kedar.
>
>>> } else {
>> Best regards,
>> Jose Miguel Abreu
>> --
>> To unsubscribe from this list: send the line "unsubscribe dmaengine" 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/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma

[Jose Abreu]

Hi Kedar,


On 15-12-2016 15:11, Kedareswara rao Appana wrote:
> When VDMA is configured for more than one frame in the h/w
> for example h/w is configured for n number of frames and user
> Submits n number of frames and triggered the DMA using issue_pending API.
> In the current driver flow we are submitting one frame at a time
> but we should submit all the n number of frames at one time as the h/w
> Is configured for n number of frames.
>
> This patch fixes this issue.
>
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/xilinx/xilinx_dma.c | 43 
> +
>  1 file changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 736c2a3..4f3fa94 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1087,23 +1087,33 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   tail_segment->phys);
>   } else {
>   struct xilinx_vdma_tx_segment *segment, *last = NULL;
> - int i = 0;
> + int i = 0, j = 0;
>  
>   if (chan->desc_submitcount < chan->num_frms)
>   i = chan->desc_submitcount;
>  
> - list_for_each_entry(segment, &desc->segments, node) {
> - if (chan->ext_addr)
> - vdma_desc_write_64(chan,
> - XILINX_VDMA_REG_START_ADDRESS_64(i++),
> - segment->hw.buf_addr,
> - segment->hw.buf_addr_msb);
> - else
> - vdma_desc_write(chan,
> - XILINX_VDMA_REG_START_ADDRESS(i++),
> - segment->hw.buf_addr);
> -
> - last = segment;
> + for (j = 0; j < chan->num_frms; ) {
> + list_for_each_entry(segment, &desc->segments, node) {
> + if (chan->ext_addr)
> + vdma_desc_write_64(chan,
> +   XILINX_VDMA_REG_START_ADDRESS_64(i++),
> +   segment->hw.buf_addr,
> +   segment->hw.buf_addr_msb);
> + else
> + vdma_desc_write(chan,
> + XILINX_VDMA_REG_START_ADDRESS(i++),
> + segment->hw.buf_addr);
> +
> + last = segment;

Hmm, is it possible to submit more than one segment? If so, then
i and j will get out of sync.

> + }
> + list_del(&desc->node);
> + list_add_tail(&desc->node, &chan->active_list);
> + j++;

But if i is non zero and pending_list has more than num_frms then
i will not wrap-around as it should and will write to invalid
framebuffer location, right?

> + if (list_empty(&chan->pending_list))
> + break;
> + desc = list_first_entry(&chan->pending_list,
> + struct xilinx_dma_tx_descriptor,
> + node);
>   }
>  
>   if (!last)
> @@ -1114,14 +1124,13 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
>   last->hw.stride);
>   vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);

Maybe a check that all framebuffers contain valid addresses
should be done before programming vsize so that VDMA does not try
to write to invalid addresses.

> +
> + chan->desc_submitcount += j;
> + chan->desc_pendingcount -= j;
>   }
>  
>   chan->idle = false;
>   if (!chan->has_sg) {
> - list_del(&desc->node);
> - list_add_tail(&desc->node, &chan->active_list);
> - chan->desc_submitcount++;
> - chan->desc_pendingcount--;
>   if (chan->desc_submitcount == chan->num_frms)
>   chan->desc_submitcount = 0;

"desc_submitcount >= chan->num_frms would be safer here.

>   } else {

Best regards,
Jose Miguel Abreu

Re: [PATCH 1/3] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor

[Jose Abreu]

Hi Kedar,


On 15-12-2016 15:11, Kedareswara rao Appana wrote:
> Add channel idle state to ensure that dma descriptor is not
> submitted when VDMA engine is in progress.
>
> Signed-off-by: Kedareswara rao Appana 
> ---
>  drivers/dma/xilinx/xilinx_dma.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 8288fe4..736c2a3 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -321,6 +321,7 @@ struct xilinx_dma_tx_descriptor {
>   * @cyclic: Check for cyclic transfers.
>   * @genlock: Support genlock mode
>   * @err: Channel has errors
> + * @idle: Check for channel idle
>   * @tasklet: Cleanup work after irq
>   * @config: Device configuration info
>   * @flush_on_fsync: Flush on Frame sync
> @@ -351,6 +352,7 @@ struct xilinx_dma_chan {
>   bool cyclic;
>   bool genlock;
>   bool err;
> + bool idle;
>   struct tasklet_struct tasklet;
>   struct xilinx_vdma_config config;
>   bool flush_on_fsync;
> @@ -966,6 +968,7 @@ static void xilinx_dma_halt(struct xilinx_dma_chan *chan)
>   chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
>   chan->err = true;
>   }
> + chan->idle = true;
>  }
>  
>  /**
> @@ -1007,6 +1010,9 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   if (chan->err)
>   return;
>  
> + if (!chan->idle)
> + return;
> +
>   if (list_empty(&chan->pending_list))
>   return;
>  
> @@ -1110,6 +1116,7 @@ static void xilinx_vdma_start_transfer(struct 
> xilinx_dma_chan *chan)
>   vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last->hw.vsize);
>   }
>  
> + chan->idle = false;
>   if (!chan->has_sg) {
>   list_del(&desc->node);
>   list_add_tail(&desc->node, &chan->active_list);
> @@ -1447,6 +1454,7 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void 
> *data)
>   if (status & XILINX_DMA_DMASR_FRM_CNT_IRQ) {
>   spin_lock(&chan->lock);
>   xilinx_dma_complete_descriptor(chan);
> + chan->idle = true;
>   chan->start_transfer(chan);
>   spin_unlock(&chan->lock);
>   }
> @@ -2327,6 +2335,7 @@ static int xilinx_dma_chan_probe(struct 
> xilinx_dma_device *xdev,
>   chan->has_sg = xdev->has_sg;
>   chan->desc_pendingcount = 0x0;
>   chan->ext_addr = xdev->ext_addr;
> + chan->idle = true;
>  
>   spin_lock_init(&chan->lock);
>   INIT_LIST_HEAD(&chan->pending_list);

I think there is missing a set to true in idle when a channel
reset is performed.
Otherwise: Reviewed-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

Re: [PATCH] dmaengine: xilinx_dma: Add support for multiple buffers

[Jose Abreu]

Hi Kedar,


On 15-12-2016 15:19, Appana Durga Kedareswara Rao wrote:
> Hi Jose Abreu,
>
>   Thanks for the patch...
>
>> Xilinx VDMA supports multiple framebuffers. This patch adds correct handling 
>> for
>> the scenario where multiple framebuffers are available in the HW and parking
>> mode is not set.
>>
>> We corrected these situations:
>>  1) Do not start VDMA until all the framebuffers
>>  have been programmed with a valid address.
>>  2) Restart variables when VDMA halts/resets.
>>  3) Halt channel when all the framebuffers have
>>  finished and there is not anymore segments
>>  pending.
>>  4) Do not try to overlap framebuffers until they
>>  are completed.
>>
>> All these situations, without this patch, can lead to data corruption and 
>> even
>> system memory corruption. If, for example, user has a VDMA with 3
>> framebuffers, with direction DMA_DEV_TO_MEM and user only submits one
>> segment, VDMA will write first to the segment the user submitted BUT if the
>> user doesn't submit another segment in a timelly manner then VDMA will write
>> to position 0 of system mem in the following VSYNC.
>   I have posted different patch series for fixing these issues just now...
> Please take a look into it...
>
> Regards,
> Kedar.

Thanks, I will review them.

Best regards,
Jose Miguel Abreu

>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Vinod Koul 
>> Cc: Dan Williams 
>> Cc: Kedareswara rao Appana 
>> Cc: Laurent Pinchart 
>> Cc: dmaeng...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  drivers/dma/xilinx/xilinx_dma.c | 80 ++-
>> --
>>  1 file changed, 68 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/dma/xilinx/xilinx_dma.c 
>> b/drivers/dma/xilinx/xilinx_dma.c
>> index 8288fe4..30eec5a 100644
>> --- a/drivers/dma/xilinx/xilinx_dma.c
>> +++ b/drivers/dma/xilinx/xilinx_dma.c
>> @@ -351,10 +351,12 @@ struct xilinx_dma_chan {
>>  bool cyclic;
>>  bool genlock;
>>  bool err;
>> +bool running;
>>  struct tasklet_struct tasklet;
>>  struct xilinx_vdma_config config;
>>  bool flush_on_fsync;
>>  u32 desc_pendingcount;
>> +u32 seg_pendingcount;
>>  bool ext_addr;
>>  u32 desc_submitcount;
>>  u32 residue;
>> @@ -946,6 +948,17 @@ static bool xilinx_dma_is_idle(struct xilinx_dma_chan
>> *chan)  }
>>
>>  /**
>> + * xilinx_vdma_is_multi_buffer - Check if VDMA has multiple
>> +framebuffers
>> + * @chan: Driver specific DMA channel
>> + *
>> + * Return: '1' if is multi buffer, '0' if not.
>> + */
>> +static bool xilinx_vdma_is_multi_buffer(struct xilinx_dma_chan *chan) {
>> +return chan->num_frms > 1;
>> +}
>> +
>> +/**
>>   * xilinx_dma_halt - Halt DMA channel
>>   * @chan: Driver specific DMA channel
>>   */
>> @@ -966,6 +979,10 @@ static void xilinx_dma_halt(struct xilinx_dma_chan
>> *chan)
>>  chan, dma_ctrl_read(chan,
>> XILINX_DMA_REG_DMASR));
>>  chan->err = true;
>>  }
>> +
>> +chan->seg_pendingcount = 0;
>> +chan->desc_submitcount = 0;
>> +chan->running = false;
>>  }
>>
>>  /**
>> @@ -1002,14 +1019,35 @@ static void xilinx_vdma_start_transfer(struct
>> xilinx_dma_chan *chan)
>>  struct xilinx_dma_tx_descriptor *desc, *tail_desc;
>>  u32 reg;
>>  struct xilinx_vdma_tx_segment *tail_segment;
>> +bool mbf = xilinx_vdma_is_multi_buffer(chan) && !config->park;
>>
>>  /* This function was invoked with lock held */
>>  if (chan->err)
>>  return;
>>
>> -if (list_empty(&chan->pending_list))
>> +/*
>> + * Can't continue if we have already consumed all the available
>> + * framebuffers and they are not done yet.
>> + */
>> +if (mbf && (chan->seg_pendingcount >= chan->num_frms))
>>  return;
>>
>> +if (list_empty(&chan->pending_list)) {
>> +/*
>> + * Can't keep running if there are no pending segments. Halt
>> + * the channel as security measure. Notice that this will not
>> + * corrupt current transactions because this function is
>> + * called after

[PATCH] dmaengine: xilinx_dma: Add support for multiple buffers

[Jose Abreu]

Xilinx VDMA supports multiple framebuffers. This patch
adds correct handling for the scenario where multiple
framebuffers are available in the HW and parking mode is
not set.

We corrected these situations:
1) Do not start VDMA until all the framebuffers
have been programmed with a valid address.
2) Restart variables when VDMA halts/resets.
3) Halt channel when all the framebuffers have
finished and there is not anymore segments
pending.
4) Do not try to overlap framebuffers until they
are completed.

All these situations, without this patch, can lead to data
corruption and even system memory corruption. If, for example,
user has a VDMA with 3 framebuffers, with direction
DMA_DEV_TO_MEM and user only submits one segment, VDMA will
write first to the segment the user submitted BUT if the user
doesn't submit another segment in a timelly manner then VDMA
will write to position 0 of system mem in the following VSYNC.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Vinod Koul 
Cc: Dan Williams 
Cc: Kedareswara rao Appana 
Cc: Laurent Pinchart 
Cc: dmaeng...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/dma/xilinx/xilinx_dma.c | 80 ++---
 1 file changed, 68 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 8288fe4..30eec5a 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -351,10 +351,12 @@ struct xilinx_dma_chan {
bool cyclic;
bool genlock;
bool err;
+   bool running;
struct tasklet_struct tasklet;
struct xilinx_vdma_config config;
bool flush_on_fsync;
u32 desc_pendingcount;
+   u32 seg_pendingcount;
bool ext_addr;
u32 desc_submitcount;
u32 residue;
@@ -946,6 +948,17 @@ static bool xilinx_dma_is_idle(struct xilinx_dma_chan 
*chan)
 }
 
 /**
+ * xilinx_vdma_is_multi_buffer - Check if VDMA has multiple framebuffers
+ * @chan: Driver specific DMA channel
+ *
+ * Return: '1' if is multi buffer, '0' if not.
+ */
+static bool xilinx_vdma_is_multi_buffer(struct xilinx_dma_chan *chan)
+{
+   return chan->num_frms > 1;
+}
+
+/**
  * xilinx_dma_halt - Halt DMA channel
  * @chan: Driver specific DMA channel
  */
@@ -966,6 +979,10 @@ static void xilinx_dma_halt(struct xilinx_dma_chan *chan)
chan, dma_ctrl_read(chan, XILINX_DMA_REG_DMASR));
chan->err = true;
}
+
+   chan->seg_pendingcount = 0;
+   chan->desc_submitcount = 0;
+   chan->running = false;
 }
 
 /**
@@ -1002,14 +1019,35 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
struct xilinx_dma_tx_descriptor *desc, *tail_desc;
u32 reg;
struct xilinx_vdma_tx_segment *tail_segment;
+   bool mbf = xilinx_vdma_is_multi_buffer(chan) && !config->park;
 
/* This function was invoked with lock held */
if (chan->err)
return;
 
-   if (list_empty(&chan->pending_list))
+   /*
+* Can't continue if we have already consumed all the available
+* framebuffers and they are not done yet.
+*/
+   if (mbf && (chan->seg_pendingcount >= chan->num_frms))
return;
 
+   if (list_empty(&chan->pending_list)) {
+   /*
+* Can't keep running if there are no pending segments. Halt
+* the channel as security measure. Notice that this will not
+* corrupt current transactions because this function is
+* called after the pendingcount is decreased and after the
+* current transaction has finished.
+*/
+   if (mbf && chan->running && !chan->seg_pendingcount) {
+   dev_dbg(chan->dev, "pending list empty: halting\n");
+   xilinx_dma_halt(chan);
+   }
+
+   return;
+   }
+
desc = list_first_entry(&chan->pending_list,
struct xilinx_dma_tx_descriptor, node);
tail_desc = list_last_entry(&chan->pending_list,
@@ -1079,6 +1117,8 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)
if (chan->has_sg) {
dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
tail_segment->phys);
+   list_splice_tail_init(&chan->pending_list, &chan->active_list);
+   chan->desc_pendingcount = 0;
} else {
struct xilinx_vdma_tx_segment *segment, *last = NULL;
int i = 0;
@@ -1097,29 +1137,34 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_dma_chan *chan)

[PATCH] ASoC: dwc: Fix PIO mode initialization

[Jose Abreu]

We can no longer rely on the return value of
devm_snd_dmaengine_pcm_register(...) to check if the DMA
handle is declared in the DT.

Previously this check activated PIO mode but currently
dma_request_chan returns either a valid channel or -EPROBE_DEFER.

In order to activate PIO mode check instead if the interrupt
line is declared. This reflects better what is documented in
the DT bindings (see Documentation/devicetree/bindings/sound/
designware-i2s.txt).

Also, initialize use_pio variable which was never being set
causing PIO mode to never work.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/dwc/designware_i2s.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 2998954..bdf8398 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -681,22 +681,19 @@ static int dw_i2s_probe(struct platform_device *pdev)
}
 
if (!pdata) {
-   ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
-   if (ret == -EPROBE_DEFER) {
-   dev_err(&pdev->dev,
-   "failed to register PCM, deferring probe\n");
-   return ret;
-   } else if (ret) {
-   dev_err(&pdev->dev,
-   "Could not register DMA PCM: %d\n"
-   "falling back to PIO mode\n", ret);
+   if (irq >= 0) {
ret = dw_pcm_register(pdev);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "Could not register PIO PCM: %d\n",
+   dev->use_pio = true;
+   } else {
+   ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL,
+   0);
+   dev->use_pio = false;
+   }
+
+   if (ret) {
+   dev_err(&pdev->dev, "could not register pcm: %d\n",
ret);
-   goto err_clk_disable;
-   }
+   goto err_clk_disable;
}
}
 
-- 
1.9.1

[PATCH] clk/axs10x: Clear init field in driver probe

[Jose Abreu]

Init field must be cleared in driver probe as this structure is not dinamically 
allocated. If not, wrong flags can be passed to core.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Stephen Boyd 
Cc: Michael Turquette 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/axs10x/i2s_pll_clock.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
b/drivers/clk/axs10x/i2s_pll_clock.c
index 411310d..02d3bcd 100644
--- a/drivers/clk/axs10x/i2s_pll_clock.c
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -182,6 +182,7 @@ static int i2s_pll_clk_probe(struct platform_device *pdev)
if (IS_ERR(pll_clk->base))
return PTR_ERR(pll_clk->base);
 
+   memset(&init, 0, sizeof(init));
clk_name = node->name;
init.name = clk_name;
init.ops = &i2s_pll_ops;
-- 
1.9.1

Re: [RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

[Jose Abreu]

Hi Hans,



On 11-11-2016 14:52, Hans Verkuil wrote:
> Hi Jose,
>
> On 11/09/2016 06:43 PM, Jose Abreu wrote:
>> Hi All,
>>
>> This is a RFC patch for Synopsys Designware HDMI RX PHY e405.
>> This phy receives and decodes HDMI video that is delivered to
>> a controller. The controller bit is not yet ready for submission
>> but we are planning to submit it as soon as possible.
>>
>> Main included features in this driver are:
>>  - Equalizer algorithm that chooses phy best settings
>>  according to detected HDMI cable characteristics.
>>  - Support for scrambling
>>  - Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz)
>>
>> The driver was implemented as a V4L2 subdevice and the phy
>> interface with the controller was implemented using V4L2 ioctls.
>> I do not know if this is the best option but it is not possible
>> to use the existing API functions directly as we need specific
>> functions that will be called by the controller at specific
>> configuration stages. For example, we can only set scrambling
>> when the sink detects the corresponding bit set in SCDC.
>>
>> Please notice that we plan to submit more phy drivers as they
>> are released, maintaining the newly created interface
>> (dw-phy-pdata.h) and using only one controller driver.
>>
>> I realize that this code needs a lot of polishment, specially
>> the equalizer part so I would really apreciate some feedback.
>>
>> Looking forward to your comments!
> I looked it over and I didn't see anything alarming :-)
>
> But it is hard to review without seeing the controller driver as well.
> When I can see how it is used by the controller driver then I can see
> if using ioctls here makes sense or not.
>
> Typically ioctls in subdevs are used for very device-specific actions.
> But perhaps what is happening here is required for all HDMI phys, and in
> that case new subdev ops could be added instead.
>
> Or we start with ioctls and later convert it to ops when it is clear that
> other phys need to do the same.
>
> Anyway, I think I'll have to wait until the controller is posted before I
> can do a proper review.
>
> Regards,
>
>   Hans

Thanks for your answer! I am not sure about other controllers
phys but ours needs a special configuration when in HDMI 2.0
modes (like 4k@60Hz) and also a special bit set when in
scrambling mode so that the equalizing algorithm stabilizes
faster. Besides this it needs configuration parameters, that in
this case are passed by platform data.

I will then wait until I have the controller driver ready and
send a RFC with these two blocks.

Best regards,
Jose Miguel Abreu


>> Best regards,
>> Jose Miguel Abreu
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-me...@vger.kernel.org
>> ---
>>  drivers/media/platform/Kconfig   |   1 +
>>  drivers/media/platform/Makefile  |   2 +
>>  drivers/media/platform/dw/Kconfig|   8 +
>>  drivers/media/platform/dw/Makefile   |   3 +
>>  drivers/media/platform/dw/dw-phy-e405.c  | 732 
>> +++
>>  drivers/media/platform/dw/dw-phy-e405.h  |  48 ++
>>  drivers/media/platform/dw/dw-phy-pdata.h |  47 ++
>>  7 files changed, 841 insertions(+)
>>  create mode 100644 drivers/media/platform/dw/Kconfig
>>  create mode 100644 drivers/media/platform/dw/Makefile
>>  create mode 100644 drivers/media/platform/dw/dw-phy-e405.c
>>  create mode 100644 drivers/media/platform/dw/dw-phy-e405.h
>>  create mode 100644 drivers/media/platform/dw/dw-phy-pdata.h
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index 754edbf1..9e8e67f 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
>>  source "drivers/media/platform/xilinx/Kconfig"
>>  source "drivers/media/platform/rcar-vin/Kconfig"
>>  source "drivers/media/platform/atmel/Kconfig"
>> +source "drivers/media/platform/dw/Kconfig"
>>  
>>  config VIDEO_TI_CAL
>>  tristate "TI CAL (Camera Adaptation Layer) driver"
>> diff --git a/drivers/media/platform/Makefile 
>> b/drivers/media/platform/Makefile
>> index f842933..fb2cf01 100644
>> --- a/drivers/media/platform/Makefile
>> +++ b/drivers/media/platform/Makefile
>> @@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
>>  obj-$(CONFIG

[RFC] [media] Add Synopsys Designware HDMI RX PHY e405 driver

[Jose Abreu]

Hi All,

This is a RFC patch for Synopsys Designware HDMI RX PHY e405.
This phy receives and decodes HDMI video that is delivered to
a controller. The controller bit is not yet ready for submission
but we are planning to submit it as soon as possible.

Main included features in this driver are:
- Equalizer algorithm that chooses phy best settings
according to detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz)

The driver was implemented as a V4L2 subdevice and the phy
interface with the controller was implemented using V4L2 ioctls.
I do not know if this is the best option but it is not possible
to use the existing API functions directly as we need specific
functions that will be called by the controller at specific
configuration stages. For example, we can only set scrambling
when the sink detects the corresponding bit set in SCDC.

Please notice that we plan to submit more phy drivers as they
are released, maintaining the newly created interface
(dw-phy-pdata.h) and using only one controller driver.

I realize that this code needs a lot of polishment, specially
the equalizer part so I would really apreciate some feedback.

Looking forward to your comments!

Best regards,
Jose Miguel Abreu

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: linux-kernel@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
 drivers/media/platform/Kconfig   |   1 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/dw/Kconfig|   8 +
 drivers/media/platform/dw/Makefile   |   3 +
 drivers/media/platform/dw/dw-phy-e405.c  | 732 +++
 drivers/media/platform/dw/dw-phy-e405.h  |  48 ++
 drivers/media/platform/dw/dw-phy-pdata.h |  47 ++
 7 files changed, 841 insertions(+)
 create mode 100644 drivers/media/platform/dw/Kconfig
 create mode 100644 drivers/media/platform/dw/Makefile
 create mode 100644 drivers/media/platform/dw/dw-phy-e405.c
 create mode 100644 drivers/media/platform/dw/dw-phy-e405.h
 create mode 100644 drivers/media/platform/dw/dw-phy-pdata.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..9e8e67f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,7 @@ source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 source "drivers/media/platform/rcar-vin/Kconfig"
 source "drivers/media/platform/atmel/Kconfig"
+source "drivers/media/platform/dw/Kconfig"
 
 config VIDEO_TI_CAL
tristate "TI CAL (Camera Adaptation Layer) driver"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index f842933..fb2cf01 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -68,3 +68,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VPU)  += mtk-vpu/
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
 
 obj-$(CONFIG_VIDEO_MEDIATEK_MDP)   += mtk-mdp/
+
+obj-y += dw/
diff --git a/drivers/media/platform/dw/Kconfig 
b/drivers/media/platform/dw/Kconfig
new file mode 100644
index 000..b3d7044
--- /dev/null
+++ b/drivers/media/platform/dw/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DW_PHY_E405
+   tristate "Synopsys Designware HDMI RX PHY e405 driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+  Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+  To compile this driver as a module, choose M here. The module
+  will be called dw-phy-e405.
diff --git a/drivers/media/platform/dw/Makefile 
b/drivers/media/platform/dw/Makefile
new file mode 100644
index 000..decc494
--- /dev/null
+++ b/drivers/media/platform/dw/Makefile
@@ -0,0 +1,3 @@
+# Makefile for Synopsys Designware HDMI RX
+
+obj-$(CONFIG_VIDEO_DW_PHY_E405) += dw-phy-e405.o
diff --git a/drivers/media/platform/dw/dw-phy-e405.c 
b/drivers/media/platform/dw/dw-phy-e405.c
new file mode 100644
index 000..e9c9cdf
--- /dev/null
+++ b/drivers/media/platform/dw/dw-phy-e405.c
@@ -0,0 +1,732 @@
+/*
+ * Synopsys Designware HDMI RX PHY e405 driver
+ *
+ * Copyright (C) 2016 Synopsys, Inc.
+ * Jose Abreu 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dw-phy-e405.h"
+#include "dw-phy-pdata.h"
+
+MODULE_AUTHOR("Jose Abreu ");
+MODULE_DESCRIPTION("Designware HDMI RX PHY e405 driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:dw-phy-e405");
+
+#define PHY_EQ_WAIT_TIME_START 3
+#define PHY_EQ_SLEEP_TIME_CDR  30
+#define PHY_EQ_SLEEP_TIME_ACQ  1
+#de

Re: [PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Jose Abreu]

On 29-08-2016 10:21, Russell King - ARM Linux wrote:
> On Mon, Aug 29, 2016 at 10:17:04AM +0100, Jose Abreu wrote:
>> Colorspace and scan information values were being written in wrong
>> offsets. This patch corrects this and writes the values at the
>> offsets specified in the databook.
>>
>> Signed-off-by: Jose Abreu 
>> Acked-by: Russel King 
> That's "Russell King" please.
>

Sorry. Will send again.

Best regards,
Jose Miguel Abreu

[PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Jose Abreu]

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.

Signed-off-by: Jose Abreu 
Acked-by: Russel King 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..cdf39aa 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -940,10 +940,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 */
 
/*
-* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6,
-* active aspect present in bit 6 rather than 4.
+* AVI data byte 1 differences: Colorspace in bits 0,1 rather than 5,6,
+* scan info in bits 4,5 rather than 0,1 and active aspect present in
+* bit 6 rather than 4.
 */
-   val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3);
+   val = (frame.scan_mode & 3) << 4 | (frame.colorspace & 3);
if (frame.active_aspect & 15)
val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT;
if (frame.top_bar || frame.bottom_bar)
-- 
2.1.4

[PATCH] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

[Jose Abreu]

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: David Airlie 
Cc: Russell King 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..cdf39aa 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -940,10 +940,11 @@ static void hdmi_config_AVI(struct dw_hdmi *hdmi, struct 
drm_display_mode *mode)
 */
 
/*
-* AVI data byte 1 differences: Colorspace in bits 4,5 rather than 5,6,
-* active aspect present in bit 6 rather than 4.
+* AVI data byte 1 differences: Colorspace in bits 0,1 rather than 5,6,
+* scan info in bits 4,5 rather than 0,1 and active aspect present in
+* bit 6 rather than 4.
 */
-   val = (frame.colorspace & 3) << 4 | (frame.scan_mode & 0x3);
+   val = (frame.scan_mode & 3) << 4 | (frame.colorspace & 3);
if (frame.active_aspect & 15)
val |= HDMI_FC_AVICONF0_ACTIVE_FMT_INFO_PRESENT;
if (frame.top_bar || frame.bottom_bar)
-- 
2.1.4

Re: [PATCH] drm: edid: HDMI 2.0 HF-VSDB block parsing

[Jose Abreu]

Hi Ville,


On 12-08-2016 14:46, Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 04:29:21PM +0100, Jose Abreu wrote:
>> Adds parsing for HDMI 2.0 'HDMI Forum Vendor
>> Specific Data Block'. This block is present in
>> some HDMI 2.0 EDID's and gives information about
>> scrambling support, SCDC, 3D Views, and others.
>>
>> Parsed parameters are stored in drm_connector
>> structure.
>>
>> Signed-off-by: Jose Abreu 
>> Cc: Carlos Palminha 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linux-kernel@vger.kernel.org
> Thierry not in cc? Is this based on his SCDC work [1] or did we have
> multiple people implementing the same thing, partially at least?
>
> [1] 
> https://lists.freedesktop.org/archives/dri-devel/2015-September/090929.html

Thanks for pointing this. I am quite new to DRM and I was not
aware of the existence of that patch set. I also implemented SCDC
in a very similar way. Will cc him next time.

>
>> ---
>>  drivers/gpu/drm/drm_edid.c | 49 
>> ++
>>  include/drm/drm_crtc.h | 12 
>>  include/drm/drm_edid.h |  5 +
>>  include/linux/hdmi.h   |  1 +
>>  4 files changed, 67 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 7df26d4..bcacf11 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3160,6 +3160,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
>>  return hdmi_id == HDMI_IEEE_OUI;
>>  }
>>  
>> +static bool cea_db_is_hdmi_hf_vsdb(const u8 *db)
> IIRC I asked Thierry to spell out the hdmi forum to avoid having this
> look like alphabet soup. But now that I've read the spec, I do see it
> being referred as hdmi-hf there as well, so I suppose it's fine.
>
>> +{
>> +int hdmi_id;
>> +
>> +if (cea_db_tag(db) != VENDOR_BLOCK)
>> +return false;
>> +
>> +if (cea_db_payload_len(db) < 7)
>> +return false;
>> +
>> +hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
>> +
>> +return hdmi_id == HDMI_IEEE_OUI_HF;
>> +}
>> +
>>  #define for_each_cea_db(cea, i, start, end) \
>>  for ((i) = (start); (i) < (end) && (i) + 
>> cea_db_payload_len(&(cea)[(i)]) < (end); (i) += 
>> cea_db_payload_len(&(cea)[(i)]) + 1)
>>  
>> @@ -3287,6 +3302,37 @@ parse_hdmi_vsdb(struct drm_connector *connector, 
>> const u8 *db)
>>  }
>>  
>>  static void
>> +parse_hdmi_hf_vsdb(struct drm_connector *connector, const u8 *db)
>> +{
>> +u8 len = cea_db_payload_len(db);
>> +
>> +if (len < 7)
>> +return;
>> +
>> +if (db[4] != 1)
>> +return; /* invalid version */
>> +
>> +connector->max_tmds_char = db[5] * 5;
> We already have the max_tmds_clock. Also I was just trying move some of
> the junk out from the connector into display_info [2].
>
> [2] https://lists.freedesktop.org/archives/dri-devel/2016-August/114634.html

This is max value for rates above 340Mcsc and can be used to
limit the 4:2:0 modes. The value of this field is zero when TMDS
character rates above 340Mcsc are not supported, so the source
must check then the max_tmds_clock in this condition and
max_tmds_char otherwise. I think it is a little bit confusing though.

I agree with your patches, specially patch 1 and 2 which reset
the field values. I was planning to send a new version with this
fix because I noticed that when switching from a 2.0 sink to a
1.4 the variables are not updated causing, for example,
scrambling to still be enabled when it can't be.

>
>> +connector->scdc_present = db[6] & (1 << 7);
>> +connector->rr_capable = db[6] & (1 << 6);
>> +connector->flags_3d = db[6] & 0x7;
>> +connector->supports_scramble = connector->scdc_present &&
>> +(db[6] & (1 << 3));
> Do we have actual users for all these? I don't like adding stuff into
> core structures just for the purposes of immediately printing it out.
>
> For the stereo flags, I guess someone would have to figure put how they
> relate to the 3d flags in the other vsdb, and how to convert to drm mode
> flags.

SCDC and RR can be used by SCDC helpers (when available) to check
respectively if sink supports SCDC and if sink supports SCDC read
requests. Scramble is being used by me now in bridge dw-hdmi to
run HDMI 2.0 compliance tests. Still I haven't send the patches
for

[PATCH] drm: edid: HDMI 2.0 HF-VSDB block parsing

[Jose Abreu]

Adds parsing for HDMI 2.0 'HDMI Forum Vendor
Specific Data Block'. This block is present in
some HDMI 2.0 EDID's and gives information about
scrambling support, SCDC, 3D Views, and others.

Parsed parameters are stored in drm_connector
structure.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/drm_edid.c | 49 ++
 include/drm/drm_crtc.h | 12 
 include/drm/drm_edid.h |  5 +
 include/linux/hdmi.h   |  1 +
 4 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7df26d4..bcacf11 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3160,6 +3160,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
return hdmi_id == HDMI_IEEE_OUI;
 }
 
+static bool cea_db_is_hdmi_hf_vsdb(const u8 *db)
+{
+   int hdmi_id;
+
+   if (cea_db_tag(db) != VENDOR_BLOCK)
+   return false;
+
+   if (cea_db_payload_len(db) < 7)
+   return false;
+
+   hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
+
+   return hdmi_id == HDMI_IEEE_OUI_HF;
+}
+
 #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + 
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) 
+ 1)
 
@@ -3287,6 +3302,37 @@ parse_hdmi_vsdb(struct drm_connector *connector, const 
u8 *db)
 }
 
 static void
+parse_hdmi_hf_vsdb(struct drm_connector *connector, const u8 *db)
+{
+   u8 len = cea_db_payload_len(db);
+
+   if (len < 7)
+   return;
+
+   if (db[4] != 1)
+   return; /* invalid version */
+
+   connector->max_tmds_char = db[5] * 5;
+   connector->scdc_present = db[6] & (1 << 7);
+   connector->rr_capable = db[6] & (1 << 6);
+   connector->flags_3d = db[6] & 0x7;
+   connector->supports_scramble = connector->scdc_present &&
+   (db[6] & (1 << 3));
+
+   DRM_DEBUG_KMS("HDMI v2: max TMDS char %d, "
+   "scdc %s, "
+   "rr %s, "
+   "3D flags 0x%x, "
+   "scramble %s\n",
+   connector->max_tmds_char,
+   connector->scdc_present ? "available" : "not available",
+   connector->rr_capable ? "capable" : "not capable",
+   connector->flags_3d,
+   connector->supports_scramble ?
+   "supported" : "not supported");
+}
+
+static void
 monitor_name(struct detailed_timing *t, void *data)
 {
if (t->data.other_data.type == EDID_DETAIL_MONITOR_NAME)
@@ -3403,6 +3449,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
/* HDMI Vendor-Specific Data Block */
if (cea_db_is_hdmi_vsdb(db))
parse_hdmi_vsdb(connector, db);
+   /* HDMI Forum Vendor-Specific Data Block */
+   else if (cea_db_is_hdmi_hf_vsdb(db))
+   parse_hdmi_hf_vsdb(connector, db);
break;
default:
break;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b618b50..eca57d2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1279,6 +1279,11 @@ struct drm_encoder {
  * @audio_latency: audio latency info from ELD, if found
  * @null_edid_counter: track sinks that give us all zeros for the EDID
  * @bad_edid_counter: track sinks that give us an EDID with invalid checksum
+ * @max_tmds_char: indicates the maximum TMDS Character Rate supported
+ * @scdc_present: when set the sink supports SCDC functionality
+ * @rr_capable: when set the sink is capable of initiating an SCDC read request
+ * @supports_scramble: when set the sink supports less than 340Mcsc scrambling
+ * @flags_3d: 3D view(s) supported by the sink, see drm_edid.h (DRM_EDID_3D_*)
  * @edid_corrupt: indicates whether the last read EDID was corrupt
  * @debugfs_entry: debugfs directory for this connector
  * @state: current atomic state for this connector
@@ -1377,6 +1382,13 @@ struct drm_connector {
int null_edid_counter; /* needed to workaround some HW bugs where we 
get all 0s */
unsigned bad_edid_counter;
 
+   /* EDID bits HDMI 2.0 */
+   int max_tmds_char;  /* in Mcsc */
+   bool scdc_present;
+   bool rr_capable;
+   bool supports_scramble;
+   int flags_3d;
+
/* Fl

Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

[Jose Abreu]

Hi,


On 05-08-2016 09:13, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
>> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
>>>> Hi Russell,
>>>>
>>>> So, I didn't use framebuffer console but used X instead and it is
>>>> working as it should. I think we can drop this patch. I am now
>>>> making interoperability with DVI and I am facing the following
>>>> scenario:
>>>> - I start the driver
>>>> - An EDID is sent which tells the driver that HDMI is NOT
>>>> supported;
>>>> - The driver configures itself to a DVI mode;
>>>>
>>>> Until this point everything is working as it should. But:
>>>>
>>>> - Now I send an EDID which tells the driver that HDMI is
>>>> supported;
>>>> - As the EDID has the same preferred mode the user will not
>>>> reconfigure the mode and there will be no change to HDMI mode.
>>> The EDID should still be read, but as you say, userspace doesn't take
>>> any action because it sees that the mode parameters are still the same,
>>> as you have identified.
>>>
>>>> The missing change to HDMI mode will cause the test to fail. The
>>>> workaround that I am using is to reconfigure to another video
>>>> mode and then configure to the preferred one but I think this
>>>> could be fixed in the driver, right?
>>> This one is extremely awkward - to fix it, we would need to check to
>>> see whether we reconfigure the hardware each time we read the EDID,
>>> and I don't think that's a particularly nice thing to do.
>>>
>>> I'd like to hear what other DRM developers think about this issue.
>> I pondored whether we should have a counter on each connector for probe
>> state, which helpers would increment whenever something changes, like:
>> - connector_status (as tracked by probe helpers)
>> - anything in the edid changes (when setting it
>>   drm_mode_connector_update_edid_property)
>> - other changes (like sink state changes in dpcd or whatever)
>>
>> That way userspace would be able to reliably spot such changes and do a
>> new modeset.
> Yes, please. I have had similar wishes for state changes and overall
> modeset counters.
> -Chris
>

What about this: Assuming that the modes probed by EDID have the
picture aspect ratio field set we can check for one of this
probed modes when receiving a mode from userspace and then if the
modes match (except from the picture aspect field, which is not
set by userspace) then we can use the picture aspect value of the
probed mode. I am using something like this in my modeset callback:

/* 'mode' comes from userspace, 'pmode' comes from EDID */
if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_NONE) {
struct drm_display_mode *pmode;

list_for_each_entry(pmode, &connector.modes, head) {
if (drm_mode_equal(pmode, mode))
mode->picture_aspect_ratio =
pmode->picture_aspect_ratio;
}
}

Of course if the EDID has for example two exactly equal modes
that only differ in the picture aspect ratio then this will not
work unless user passes the picture aspect when setting the mode.

Best regards,
Jose Miguel Abreu

Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

[Jose Abreu]

Hi Russell,


On 04-08-2016 16:04, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
>> Hmm, I am not debugging it right now but I remember that
>> drm_fb_helper_probe_connector_modes() was not being called at the
>> time I set the new EDID but only after I stopped sending video (I
>> was using modetest).
> Please investigate - I'd prefer that your patch does not get applied
> until we really know what's going on here.
>
> Hmm, if you're using modetest, then userspace is setting a mode, and
> userspace is in control of the DRM device - that's probably the reason
> why you're not seeing anything happening - modetest probably doesn't
> know anything about hotplug events, and so doesn't read the modes.
>
> Have you tried with the framebuffer console and DRM fbdev emulation
> enabled, without using modetest?
>

So, I didn't use framebuffer console but used X instead and it is
working as it should. I think we can drop this patch. I am now
making interoperability with DVI and I am facing the following
scenario:
- I start the driver
- An EDID is sent which tells the driver that HDMI is NOT
supported;
- The driver configures itself to a DVI mode;

Until this point everything is working as it should. But:

- Now I send an EDID which tells the driver that HDMI is
supported;
- As the EDID has the same preferred mode the user will not
reconfigure the mode and there will be no change to HDMI mode.

The missing change to HDMI mode will cause the test to fail. The
workaround that I am using is to reconfigure to another video
mode and then configure to the preferred one but I think this
could be fixed in the driver, right?

Best regards,
Jose Miguel Abreu

Re: [PATCH 2/3 v3] drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets

[Jose Abreu]

Hi Russell,


On 04-08-2016 16:32, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
>> Currently ISCR and ACP packets are not being sent causing
>> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
> Hmm.  Reading the HDMI specifications (v1.3, being the publically
> available one), the specification does _not_ say that a source _must_
> transmit ISRC and ACP packets if Supports_AI is set.
>
> What it does say is that:
> * a sink shall set Supports_AI if it supports at least one function
>   which uses ISRC or ACP packets, and it shall accept such packets.
> * a source shall not transmit ISRC or ACP packets to a sink that
>   has Supports_AI=0.
>
> I don't see anything that mandates the transmission of ISRC and ACP
> packets when Supports_AI is set.
>
> Moreover, transmission of wrong ISRC information probably goes against
> the HDMI spec section 8.8, which requires specific ISRC status values
> in HB1 - I don't see how that _could_ be handled, as the kernel has no
> knowledge about the EAN of the audio content being played, nor when a
> track starts or finishes.
>
> Please clarify.

You are correct. I ran the test again and indeed it is not
failing but it is skipped. Sorry for the confusion. Anyway, with
this patch the test that verifies the ISRC packets succeeds so I
think it would be a nice addition.

>
>> +/* Set ISCR1, ISCR2, and ACP packets to automatic scheduling */
>> +if (hdmi->sink_supports_ai) {
>> +dev_dbg(hdmi->dev, "sink supports AI packets\n");
>> +hdmi_writeb(hdmi, 0x06, HDMI_FC_ISCR1_0);
>> +hdmi_writeb(hdmi, 0x03, HDMI_FC_DATAUTO0);
>> +hdmi_writeb(hdmi, 0x01, HDMI_FC_DATAUTO1);
>> +hdmi_writeb(hdmi, 0x11, HDMI_FC_DATAUTO2);
> So what data gets sent in these packets - I guess whatever random data
> happens to be in the HDMI_FC_ACP* and HDMI_FC_ISCR1_* registers at the
> time the sending is enabled.  I don't think that's particularly a good
> idea.

It is not random as the registers defaults to zero per databook.
It is sending an empty packet.

>> @@ -1474,8 +1490,13 @@ static int dw_hdmi_connector_get_modes(struct 
>> drm_connector *connector)
>>  /* Store the ELD */
>>  drm_edid_to_eld(connector, edid);
>>  kfree(edid);
>> +
>> +hdmi->sink_supports_ai = connector->eld[5] & (0x1 << 1);
> We have a definition for this bit - DRM_ELD_SUPPORTS_AI.
>

Thanks. Will change in next version if you agree with this
addition. If not I will drop the patch.


Best regards,
Jose Miguel Abreu

Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

[Jose Abreu]

Hi Russell,


On 04-08-2016 15:31, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>> I am not sure if this is a bug in DRM or a bad implementation of
>> dw-hdmi. I've seen at least two more drivers that do the edid
>> reading at the .detect() callback: nouveau and gma500. This is
>> noticeable if while sending video the edid changes like in a
>> compliance environment. In the environment that I tested I was
>> sending video and swapped an edid that had support for AI packets
>> to another one without support and I noticed that although the
>> hotplug is generated the edid was not being updated.
> The path should be:
>
> - HPD interrupt
> - drm_helper_hpd_irq_event()
>   - generates uevent to userspace
>   - output_poll_changed() called
> - drm_fb_helper_hotplug_event()
>   - drm_fb_helper_probe_connector_modes()
> - connector->fill_modes()
>   - drm_helper_probe_single_connector_modes()
> - connector_funcs->get_modes()
>
> Now, if we don't have fbdev emulation, then things won't get much
> fruther than output_poll_changed(), and the responsibility for
> reading the EDID falls onto userspace.  However, as soon as userspace
> or the kernel reads the new EDID, that is when any changes in it
> should become visible.
>
> Of course, that should occur in a timely fashion.
>

Hmm, I am not debugging it right now but I remember that
drm_fb_helper_probe_connector_modes() was not being called at the
time I set the new EDID but only after I stopped sending video (I
was using modetest).


Best regards,
Jose Miguel Abreu

Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

[Jose Abreu]

Hi Russell,


On 04-08-2016 11:47, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 11:44:51AM +0100, Jose Abreu wrote:
>> When running HDMI compliance tests we noticed that sometimes
>> the edid changes but the get_modes() function is not called
>> so the edid is not updated. Moving the edid reading to the
>> detect() callback ensures that the edid is correctly updated
>> after an hotplug.
> Wouldn't this be a bug in the higher levels of DRM?
>

I am not sure if this is a bug in DRM or a bad implementation of
dw-hdmi. I've seen at least two more drivers that do the edid
reading at the .detect() callback: nouveau and gma500. This is
noticeable if while sending video the edid changes like in a
compliance environment. In the environment that I tested I was
sending video and swapped an edid that had support for AI packets
to another one without support and I noticed that although the
hotplug is generated the edid was not being updated.

Best regards,
Jose Miguel Abreu

[PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

[Jose Abreu]

When running HDMI compliance tests we noticed that sometimes
the edid changes but the get_modes() function is not called
so the edid is not updated. Moving the edid reading to the
detect() callback ensures that the edid is correctly updated
after an hotplug.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Fabio Estevam 
Cc: Daniel Vetter 
Cc: Takashi Iwai 
Cc: Vladimir Zapolskiy 
Cc: Thierry Reding 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---

This patch was only introduced in v3.

 drivers/gpu/drm/bridge/dw-hdmi.c | 67 +++-
 1 file changed, 38 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9122a20..c795888 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -31,8 +31,6 @@
 #include "dw-hdmi.h"
 #include "dw-hdmi-audio.h"
 
-#define HDMI_EDID_LEN  512
-
 #define RGB0
 #define YCBCR444   1
 #define YCBCR422_16BITS2
@@ -117,7 +115,7 @@ struct dw_hdmi {
 
int vic;
 
-   u8 edid[HDMI_EDID_LEN];
+   struct edid *edid;
bool cable_plugin;
 
bool phy_enabled;
@@ -1457,6 +1455,7 @@ dw_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);
+   bool connected;
 
mutex_lock(&hdmi->mutex);
hdmi->force = DRM_FORCE_UNSPECIFIED;
@@ -1464,7 +1463,40 @@ dw_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
dw_hdmi_update_phy_mask(hdmi);
mutex_unlock(&hdmi->mutex);
 
-   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+   connected = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD;
+
+   if (connected && hdmi->ddc) {
+   if (hdmi->edid) {
+   drm_mode_connector_update_edid_property(connector,
+   NULL);
+   kfree(hdmi->edid);
+   hdmi->edid = NULL;
+   }
+
+   hdmi->edid = drm_get_edid(connector, hdmi->ddc);
+   if (hdmi->edid) {
+   dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
+   hdmi->edid->width_cm,
+   hdmi->edid->height_cm);
+   drm_mode_connector_update_edid_property(connector,
+   hdmi->edid);
+   drm_edid_to_eld(connector, hdmi->edid);
+
+   hdmi->sink_is_hdmi =
+   drm_detect_hdmi_monitor(hdmi->edid);
+   hdmi->sink_has_audio =
+   drm_detect_monitor_audio(hdmi->edid);
+   hdmi->sink_supports_ai =
+   connector->eld[5] & (0x1 << 1);
+   } else {
+   dev_dbg(hdmi->dev, "failed to get edid\n");
+   hdmi->sink_is_hdmi = false;
+   hdmi->sink_has_audio = false;
+   hdmi->sink_supports_ai = false;
+   }
+   }
+
+   return connected ?
connector_status_connected : connector_status_disconnected;
 }
 
@@ -1472,33 +1504,10 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);
-   struct edid *edid;
int ret = 0;
 
-   if (!hdmi->ddc)
-   return 0;
-
-   edid = drm_get_edid(connector, hdmi->ddc);
-   if (edid) {
-   dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
-   edid->width_cm, edid->height_cm);
-
-   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
-   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
-   drm_mode_connector_update_edid_property(connector, edid);
-   ret = drm_add_edid_modes(connector, edid);
-   /* Store the ELD */
-   drm_edid_to_eld(connector, edid);
-   kfree(edid);
-
-   hdmi->sink_supports_ai = connector->eld[5] & (0x1 << 1);
-   } else {
-   dev_dbg(hdmi->dev, "failed to get edid\n");
-   hdmi->sink_is_hdmi = false;
-   hdmi->sink_has_audio = false;
-   hdmi->sink_supports_ai = false;
-   }
-
+   if (hdmi->edid)
+   ret = drm_add_edid_modes(connector, hdmi->edid);
return ret;
 }
 
-- 
2.1.4

[PATCH 2/3 v3] drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets

[Jose Abreu]

Currently ISCR and ACP packets are not being sent causing
HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.

With this pacth the mentioned packets are activated when
needed.

Verified using HDMI compliance equipment.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Fabio Estevam 
Cc: Daniel Vetter 
Cc: Takashi Iwai 
Cc: Vladimir Zapolskiy 
Cc: Thierry Reding 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---

This patch was only introduced in v3.

 drivers/gpu/drm/bridge/dw-hdmi.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b5fac27..9122a20 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -127,6 +127,7 @@ struct dw_hdmi {
void __iomem *regs;
bool sink_is_hdmi;
bool sink_has_audio;
+   bool sink_supports_ai;
 
struct mutex mutex; /* for state below and previous_mode */
enum drm_connector_force force; /* mutex-protected force state */
@@ -216,6 +217,21 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned 
int cts,
hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
 
+   /* Set ISCR1, ISCR2, and ACP packets to automatic scheduling */
+   if (hdmi->sink_supports_ai) {
+   dev_dbg(hdmi->dev, "sink supports AI packets\n");
+   hdmi_writeb(hdmi, 0x06, HDMI_FC_ISCR1_0);
+   hdmi_writeb(hdmi, 0x03, HDMI_FC_DATAUTO0);
+   hdmi_writeb(hdmi, 0x01, HDMI_FC_DATAUTO1);
+   hdmi_writeb(hdmi, 0x11, HDMI_FC_DATAUTO2);
+   } else {
+   dev_dbg(hdmi->dev, "sink does not support AI packets\n");
+   hdmi_writeb(hdmi, 0x00, HDMI_FC_ISCR1_0);
+   hdmi_writeb(hdmi, 0x00, HDMI_FC_DATAUTO0);
+   hdmi_writeb(hdmi, 0x00, HDMI_FC_DATAUTO1);
+   hdmi_writeb(hdmi, 0x00, HDMI_FC_DATAUTO2);
+   }
+
/* Set Frame Composer Audio Sample sampling frequency */
if (hdmi->dev_type == DWC_HDMI) {
u8 val = 0x0;
@@ -1474,8 +1490,13 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
/* Store the ELD */
drm_edid_to_eld(connector, edid);
kfree(edid);
+
+   hdmi->sink_supports_ai = connector->eld[5] & (0x1 << 1);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
+   hdmi->sink_is_hdmi = false;
+   hdmi->sink_has_audio = false;
+   hdmi->sink_supports_ai = false;
}
 
return ret;
-- 
2.1.4

[PATCH 0/3 v3] drm: bridge/dw-hdmi: Fixes for dw-hdmi and DWC support

[Jose Abreu]

In this patch series we add support for Synopsys DWC Phy
and improve current driver.

First patch adds the support and remaining patches correct
some minor things.

All patches were tested using HDMI compliance equipment.

Changes v2 -> v3:
- Fixed incorrect frequency values
- Added ISCR and ACP packets enable
- Moved EDID reading to .detect() callback

Changes v1 -> v2:
- Fixed Audio Infoframe

Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Fabio Estevam 
Cc: Daniel Vetter 
Cc: Takashi Iwai 
Cc: Vladimir Zapolskiy 
Cc: Thierry Reding 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org

Jose Abreu (3):
  drm: bridge/dw-hdmi: Add support for DWC Phy
  drm: bridge/dw-hdmi: Enable ISCR1, ISCR2 and ACP packets
  drm: bridge/dw-hdmi: Move edid reading to .detect() callback

 drivers/gpu/drm/bridge/dw-hdmi.c | 103 +--
 drivers/gpu/drm/bridge/dw-hdmi.h |   1 +
 include/drm/bridge/dw_hdmi.h |   1 +
 3 files changed, 80 insertions(+), 25 deletions(-)

-- 
2.1.4

[PATCH 1/3 v3] drm: bridge/dw-hdmi: Add support for DWC Phy

[Jose Abreu]

This patch adds support for the Synopsys HDMI TX Phy in
bridge dw-hdmi.

The init flow is the same as the Rockchip Phy so we only
need to add one define and one if statement.

Also, the audio infoframe was fixed (before it was always
reporting 44.1k). With this patch this is now corrected
and validated. This is specific to Synopsys Phy.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Russell King 
Cc: Fabio Estevam 
Cc: Daniel Vetter 
Cc: Takashi Iwai 
Cc: Vladimir Zapolskiy 
Cc: Thierry Reding 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---

Changes v2 -> v3:
- Fixed incorrect frequency values

Changes v1 -> v2:
- Fixed Audio Infoframe

 drivers/gpu/drm/bridge/dw-hdmi.c | 25 -
 drivers/gpu/drm/bridge/dw-hdmi.h |  1 +
 include/drm/bridge/dw_hdmi.h |  1 +
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..b5fac27 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -215,6 +215,29 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned 
int cts,
hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
+
+   /* Set Frame Composer Audio Sample sampling frequency */
+   if (hdmi->dev_type == DWC_HDMI) {
+   u8 val = 0x0;
+
+   switch (hdmi->sample_rate) {
+   case 32000:
+   val = 0x3;
+   break;
+   case 44100:
+   val = 0x0;
+   break;
+   case 48000:
+   val = 0x2;
+   break;
+   default:
+   dev_err(hdmi->dev, "unsupported sample rate (%d)\n",
+   hdmi->sample_rate);
+   return;
+   }
+
+   hdmi_writeb(hdmi, val, HDMI_FC_AUDSCHNL7);
+   }
 }
 
 static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
@@ -833,7 +856,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   if (hdmi->dev_type == RK3288_HDMI)
+   if ((hdmi->dev_type == RK3288_HDMI) || (hdmi->dev_type == DWC_HDMI))
dw_hdmi_phy_enable_spare(hdmi, 1);
 
/*Wait for PHY PLL lock */
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index fc9a560..5f137fd 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -162,6 +162,7 @@
 #define HDMI_FC_SPDDEVICEINF0x1062
 #define HDMI_FC_AUDSCONF0x1063
 #define HDMI_FC_AUDSSTAT0x1064
+#define HDMI_FC_AUDSCHNL7  0x106E
 #define HDMI_FC_DATACH0FILL 0x1070
 #define HDMI_FC_DATACH1FILL 0x1071
 #define HDMI_FC_DATACH2FILL 0x1072
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3..6e4fb2e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -25,6 +25,7 @@ enum dw_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
RK3288_HDMI,
+   DWC_HDMI,
 };
 
 struct dw_hdmi_mpll_config {
-- 
2.1.4

Re: [PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

[Jose Abreu]

Hi,

On 01-08-2016 05:57, Kuninori Morimoto wrote:
> Hi Jose
> Cc: Mark, Thierry, Daniel
>
>>> From: Kuninori Morimoto 
>>>
>>> Current dw-hdmi is supporting sound via AHB bus, but it has
>>> I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
>>> This HDMI I2S is supported by using ALSA SoC common HDMI encoder
>>> driver.
>>>
>>> Signed-off-by: Kuninori Morimoto 
>>> ---
>>>
>> I just tested this patch and everything seems ok. Should I give
>> my tested-by?
> Thank you for your test. I'm happy if it could have it.
>
> Mark, Thierry, Daniel
> I wonder who can be maintainer for this patch ??
>
> Best regards
> ---
> Kuninori Morimoto

Tested-by: Jose Abreu 

Best regards,
Jose Miguel Abreu

Re: [PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

[Jose Abreu]

Hi,


On 24-06-2016 03:40, Kuninori Morimoto wrote:
> From: Kuninori Morimoto 
>
> Current dw-hdmi is supporting sound via AHB bus, but it has
> I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
> This HDMI I2S is supported by using ALSA SoC common HDMI encoder
> driver.
>
> Signed-off-by: Kuninori Morimoto 
> ---
>

I just tested this patch and everything seems ok. Should I give
my tested-by?

Best regards,
Jose Miguel Abreu

[PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

[Jose Abreu]

This patch adds support for the Synopsys HDMI TX Phy in
bridge dw-hdmi.

The init flow is the same as the Rockchip Phy so we
only need to add one define and one if statement.

Also, the audio infoframe was fixed to sampling frequency
of 44.1k. With this patch this is now corrected. As
I don't know if this is specific to Synopsys Phy we only
set this if Phy type is DWC_HDMI.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: David Airlie 
Cc: Russell King 
Cc: Fabio Estevam 
Cc: Daniel Vetter 
Cc: Takashi Iwai 
Cc: Vladimir Zapolskiy 
Cc: Thierry Reding 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---

Changes v1 -> v2:
- Fixed Audio Infoframe

 drivers/gpu/drm/bridge/dw-hdmi.c | 25 -
 drivers/gpu/drm/bridge/dw-hdmi.h |  1 +
 include/drm/bridge/dw_hdmi.h |  1 +
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index c9d9412..2cab188 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -215,6 +215,29 @@ static void hdmi_set_cts_n(struct dw_hdmi *hdmi, unsigned 
int cts,
hdmi_writeb(hdmi, (n >> 16) & 0x0f, HDMI_AUD_N3);
hdmi_writeb(hdmi, (n >> 8) & 0xff, HDMI_AUD_N2);
hdmi_writeb(hdmi, n & 0xff, HDMI_AUD_N1);
+
+   /* Set Frame Composer Audio Sample sampling frequency */
+   if (hdmi->dev_type == DWC_HDMI) {
+   u8 val = 0x0;
+
+   switch (hdmi->sample_rate) {
+   case 32:
+   val = 0x3;
+   break;
+   case 441000:
+   val = 0x0;
+   break;
+   case 48:
+   val = 0x2;
+   break;
+   default:
+   dev_err(hdmi->dev, "unsupported sample rate (%d)\n",
+   hdmi->sample_rate);
+   return;
+   }
+
+   hdmi_writeb(hdmi, val, HDMI_FC_AUDSCHNL7);
+   }
 }
 
 static unsigned int hdmi_compute_n(unsigned int freq, unsigned long pixel_clk)
@@ -833,7 +856,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   if (hdmi->dev_type == RK3288_HDMI)
+   if ((hdmi->dev_type == RK3288_HDMI) || (hdmi->dev_type == DWC_HDMI))
dw_hdmi_phy_enable_spare(hdmi, 1);
 
/*Wait for PHY PLL lock */
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index fc9a560..5f137fd 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -162,6 +162,7 @@
 #define HDMI_FC_SPDDEVICEINF0x1062
 #define HDMI_FC_AUDSCONF0x1063
 #define HDMI_FC_AUDSSTAT0x1064
+#define HDMI_FC_AUDSCHNL7  0x106E
 #define HDMI_FC_DATACH0FILL 0x1070
 #define HDMI_FC_DATACH1FILL 0x1071
 #define HDMI_FC_DATACH2FILL 0x1072
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3..6e4fb2e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -25,6 +25,7 @@ enum dw_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
RK3288_HDMI,
+   DWC_HDMI,
 };
 
 struct dw_hdmi_mpll_config {
-- 
2.1.4

Re: DRM DMA Engine

[Jose Abreu]

Hi Ilia,

Thanks for your answer.

On 16-06-2016 13:39, Ilia Mirkin wrote:
> On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu  wrote:
>> Hi Daniel,
>>
>> Sorry to bother you again. I promise this is the last time :)
>>
>> On 15-06-2016 11:15, Daniel Vetter wrote:
>>> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu  
>>> wrote:
>>>> On 15-06-2016 09:52, Daniel Vetter wrote:
>>>>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu  
>>>>> wrote:
>>>>>>> I assume that xilinx VDMA is the only way to feed pixel data into your
>>>>>>> display pipeline. Under that assumption:
>>>>>>>
>>>>>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>>>>>>> would represent the dma channel. With atomic you can subclass
>>>>>>> drm_plane/crtc_state structures to store all the runtime configuration 
>>>>>>> in
>>>>>>> there.
>>>>>>>
>>>>>>> The actual buffer itsel would be represented by a drm_framebuffer, which
>>>>>>> either wraps a shmem gem or a cma gem object.
>>>>>>>
>>>>>>> If you want to know about the callbacks used by the atomic helpers to 
>>>>>>> push
>>>>>>> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
>>>>>>> (and the related functions, see kerneldoc) calls.
>>>>>>>
>>>>>>> I hope this helps a bit more.
>>>>>>> -Daniel
>>>>>> Thanks a lot! With your help I was able to implement all the
>>>>>> needed logic. Sorry to bother you but I have one more question.
>>>>>> Right now I can initialize and configure the vdma correctly but I
>>>>>> can only send one frame. I guess when the dma completes
>>>>>> transmission I need to ask drm for a new frame, right? Because
>>>>>> the commit function starts the vdma correctly but then the dma
>>>>>> halts waiting for a new descriptor.
>>>>> DRM has a continuous scanout model, i.e. when userspace doesn't give
>>>>> you a new frame you're supposed to keep scanning out the current one.
>>>>> So you need to rearm your upload code with the same drm_framebuffer if
>>>>> userspace hasn't supplied a new one since the last time before the
>>>>> vblank period starts.
>>>>>
>>>>> This is different to v4l, where userspace has to supply each frame
>>>>> (and the kernel gets angry when there's not enough frames and signals
>>>>> an underrun of the queue). This is because drm is geared at desktops,
>>>>> and there it's perfectly normal to show the exact same frame for a
>>>>> long time.
>>>>> -Daniel
>>>> Thanks, I was thinking this was similar to v4l. I am now able to
>>>> send multiple frames so it is finally working! I have one little
>>>> implementation detail: The controller that I am using supports
>>>> deep color mode but I am using FB CMA helpers to create the
>>>> framebuffer and I've seen that the supported bpp in these helpers
>>>> only goes up to 32, right? Does this means that with these
>>>> helpers I can't use deep color? Can I implement this deep color
>>>> mode (48bpp) using a custom fb or do I also need custom gem
>>>> allocation functions (Right now I am using GEM CMA helpers)?
>>> Suprising the cma doesn't take pixel_format into account. If this
>>> really doesn't work, pls fix up the cma helpers, not roll your own
>>> copypasta ;-)
>>>
>>> Note that the fbdev emulation itself (maybe that's what threw you off)
>>> only supports legacy rgb formats up to 32bits. But native kms can
>>> support anything, we just might need to add the DRM_FOURCC codes for
>>> that.
>>> -Daniel
>> So, I ended up using 32bits and everything is working fine! I
>> tested using [1] and [2] but now I have kind of a dumb question:
>> I want to use the new driver that I created as a secondary output
>> of my desktop so that I can play videos using mplayer but I am
>> not being able to do this. If I check in my linux settings only
>> one display is being detected, although in /dev/dri the two video
>> cards are present (the native one and the one I added). Does the
>> driver needs something addi

Re: DRM DMA Engine

[Jose Abreu]

Hi Daniel,

Sorry to bother you again. I promise this is the last time :)

On 15-06-2016 11:15, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu  wrote:
>> On 15-06-2016 09:52, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu  wrote:
>>>>> I assume that xilinx VDMA is the only way to feed pixel data into your
>>>>> display pipeline. Under that assumption:
>>>>>
>>>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>>>>> would represent the dma channel. With atomic you can subclass
>>>>> drm_plane/crtc_state structures to store all the runtime configuration in
>>>>> there.
>>>>>
>>>>> The actual buffer itsel would be represented by a drm_framebuffer, which
>>>>> either wraps a shmem gem or a cma gem object.
>>>>>
>>>>> If you want to know about the callbacks used by the atomic helpers to push
>>>>> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
>>>>> (and the related functions, see kerneldoc) calls.
>>>>>
>>>>> I hope this helps a bit more.
>>>>> -Daniel
>>>> Thanks a lot! With your help I was able to implement all the
>>>> needed logic. Sorry to bother you but I have one more question.
>>>> Right now I can initialize and configure the vdma correctly but I
>>>> can only send one frame. I guess when the dma completes
>>>> transmission I need to ask drm for a new frame, right? Because
>>>> the commit function starts the vdma correctly but then the dma
>>>> halts waiting for a new descriptor.
>>> DRM has a continuous scanout model, i.e. when userspace doesn't give
>>> you a new frame you're supposed to keep scanning out the current one.
>>> So you need to rearm your upload code with the same drm_framebuffer if
>>> userspace hasn't supplied a new one since the last time before the
>>> vblank period starts.
>>>
>>> This is different to v4l, where userspace has to supply each frame
>>> (and the kernel gets angry when there's not enough frames and signals
>>> an underrun of the queue). This is because drm is geared at desktops,
>>> and there it's perfectly normal to show the exact same frame for a
>>> long time.
>>> -Daniel
>> Thanks, I was thinking this was similar to v4l. I am now able to
>> send multiple frames so it is finally working! I have one little
>> implementation detail: The controller that I am using supports
>> deep color mode but I am using FB CMA helpers to create the
>> framebuffer and I've seen that the supported bpp in these helpers
>> only goes up to 32, right? Does this means that with these
>> helpers I can't use deep color? Can I implement this deep color
>> mode (48bpp) using a custom fb or do I also need custom gem
>> allocation functions (Right now I am using GEM CMA helpers)?
> Suprising the cma doesn't take pixel_format into account. If this
> really doesn't work, pls fix up the cma helpers, not roll your own
> copypasta ;-)
>
> Note that the fbdev emulation itself (maybe that's what threw you off)
> only supports legacy rgb formats up to 32bits. But native kms can
> support anything, we just might need to add the DRM_FOURCC codes for
> that.
> -Daniel

So, I ended up using 32bits and everything is working fine! I
tested using [1] and [2] but now I have kind of a dumb question:
I want to use the new driver that I created as a secondary output
of my desktop so that I can play videos using mplayer but I am
not being able to do this. If I check in my linux settings only
one display is being detected, although in /dev/dri the two video
cards are present (the native one and the one I added). Does the
driver needs something additional to do this or is it only in my
X configuration? I tried editing this configuration but still
doesn't work. I believe that because my driver is not being
probed at runtime the display is not being created by X. Is this
correct?

[1] https://dri.freedesktop.org/libdrm/
[2] https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c

Thanks!

Best regards,
Jose Miguel Abreu

Re: DRM DMA Engine

[Jose Abreu]

Hi Daniel,


On 15-06-2016 09:52, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu  wrote:
>>> I assume that xilinx VDMA is the only way to feed pixel data into your
>>> display pipeline. Under that assumption:
>>>
>>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>>> would represent the dma channel. With atomic you can subclass
>>> drm_plane/crtc_state structures to store all the runtime configuration in
>>> there.
>>>
>>> The actual buffer itsel would be represented by a drm_framebuffer, which
>>> either wraps a shmem gem or a cma gem object.
>>>
>>> If you want to know about the callbacks used by the atomic helpers to push
>>> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
>>> (and the related functions, see kerneldoc) calls.
>>>
>>> I hope this helps a bit more.
>>> -Daniel
>> Thanks a lot! With your help I was able to implement all the
>> needed logic. Sorry to bother you but I have one more question.
>> Right now I can initialize and configure the vdma correctly but I
>> can only send one frame. I guess when the dma completes
>> transmission I need to ask drm for a new frame, right? Because
>> the commit function starts the vdma correctly but then the dma
>> halts waiting for a new descriptor.
> DRM has a continuous scanout model, i.e. when userspace doesn't give
> you a new frame you're supposed to keep scanning out the current one.
> So you need to rearm your upload code with the same drm_framebuffer if
> userspace hasn't supplied a new one since the last time before the
> vblank period starts.
>
> This is different to v4l, where userspace has to supply each frame
> (and the kernel gets angry when there's not enough frames and signals
> an underrun of the queue). This is because drm is geared at desktops,
> and there it's perfectly normal to show the exact same frame for a
> long time.
> -Daniel

Thanks, I was thinking this was similar to v4l. I am now able to
send multiple frames so it is finally working! I have one little
implementation detail: The controller that I am using supports
deep color mode but I am using FB CMA helpers to create the
framebuffer and I've seen that the supported bpp in these helpers
only goes up to 32, right? Does this means that with these
helpers I can't use deep color? Can I implement this deep color
mode (48bpp) using a custom fb or do I also need custom gem
allocation functions (Right now I am using GEM CMA helpers)?

Best regards,
Jose Miguel Abreu

Re: DRM DMA Engine

[Jose Abreu]

Hi Daniel,


On 30-05-2016 10:36, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 10:00:56AM +0100, Jose Abreu wrote:
>> ++ Daniel
>>
>>
>> On 30-05-2016 09:44, Jose Abreu wrote:
>>> Hi Daniel,
>>>
>>> Thanks for your answer.
>>>
>>> On 26-05-2016 09:06, Daniel Vetter wrote:
>>>> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote:
>>>>> Hi all,
>>>>>
>>>>> Currently I am trying to develop a DRM driver that will use
>>>>> Xilinx VDMA to transfer video data to a HDMI TX Phy and I am
>>>>> facing a difficulty regarding the understanding of the DRM DMA
>>>>> Engine. I looked at several sources and at the DRM core source
>>>>> but the flow of creating and interfacing with the DMA controller
>>>>> is still not clear to me.
>>>>>
>>>>> At DRI web page the X server is mentioned. Does it mean that the
>>>>> channel creation and handling is done by the X server? If so,
>>>>> what is the DRM driver responsible to do then and what exactly
>>>>> does the DRM core do? As I am using Xilinx VDMA do you foresee
>>>>> any special implementation details?
>>>>>
>>>>> Just for reference here is the description of the Xilinx VDMA:
>>>>> "The Advanced eXtensible Interface Video Direct Memory Access
>>>>> (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core
>>>>> providing high-bandwidth direct memory access between memory and
>>>>> AXI4-Stream video type target peripherals including  peripherals
>>>>> which support AXI4-Stream Video Protocol." The driver is
>>>>> available at "drivers/dma/xilinx/xilinx_vdma.c".
>>>>>
>>>>> Another important point: I am using PCI Express connected to a
>>>>> FPGA which has all the necessary components (Xilinx VDMA, I2S,
>>>>> ...) and the HDMI TX Phy.
>>>>>
>>>>> Looking forward to you help.
>>>> If your dma engine is just for HDMI display, forget all the stuff you find
>>>> about DRI and X server on the various wikis. That's for opengl rendering.
>>>>
>>>> The only thing you need is a kernel-modesetting driver, and nowadays those
>>>> are written using the atomic modeset framework. There's plenty of
>>>> introductory talks and stuff all over the web (I suggest the latest
>>>> version of Laurent Pinchart's talk as a good starting point).
>>>> -Daniel
>>> I watched the talk of Laurent and I already have a simple KMS
>>> driver with an encoder (which is bridge dw-hdmi), a connector and
>>> a crtc. My doubt now is how do I setup the video path so that
>>> video samples are sent using the Xilinx VDMA to our hdmi phy.
>>>
>>> Sorry if I am making some mistake (I am quite new to DRM and DMA)
>>> but here is my thoughts:
>>> - A DMA channel or some kind of mapping must be done so that
>>> the DRM driver knows where to send samples;
>>> - The Xilinx VDMA driver must be instantiated (which I am
>>> already doing);
>>> - Some kind of association between the DRM DMA engine and
>>> Xilinx VDMA must be done;
>>> - A callback should exist that is called on each frame and
>>> updates the data that is sent to Xilinx VDMA.
>>>
>>> Does this looks okay to you or am I missing something? I still
>>> haven't figured out how should I associate the VDMA to the DRM
>>> DMA engine and how should I map the DMA to the DRM driver.
>>>
>>> Can you give me some help or refer me to someone who can? Also,
>>> is there a DRM driver that uses a similar architecture?
> I assume that xilinx VDMA is the only way to feed pixel data into your
> display pipeline. Under that assumption:
>
> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
> would represent the dma channel. With atomic you can subclass
> drm_plane/crtc_state structures to store all the runtime configuration in
> there.
>
> The actual buffer itsel would be represented by a drm_framebuffer, which
> either wraps a shmem gem or a cma gem object.
>
> If you want to know about the callbacks used by the atomic helpers to push
> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
> (and the related functions, see kerneldoc) calls.
>
> I hope this helps a bit more.
> -Daniel

Thanks a lot! With your help I was able to implement all the
needed logic. Sorry to bother you but I have one more question.
Right now I can initialize and configure the vdma correctly but I
can only send one frame. I guess when the dma completes
transmission I need to ask drm for a new frame, right? Because
the commit function starts the vdma correctly but then the dma
halts waiting for a new descriptor.

Best regards,
Jose Miguel Abreu

[PATCH] drm: bridge/dw-hdmi: Add support for DWC Phy

[Jose Abreu]

This patch adds support for the Synopsys HDMI TX Phy in
bridge dw-hdmi.

The init flow is the same as the Rockchip Phy so we
only need to add one define and one if statement.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
 include/drm/bridge/dw_hdmi.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index c9d9412..13e33ea 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -833,7 +833,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, 
unsigned char prep,
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);
 
-   if (hdmi->dev_type == RK3288_HDMI)
+   if ((hdmi->dev_type == RK3288_HDMI) || (hdmi->dev_type == DWC_HDMI))
dw_hdmi_phy_enable_spare(hdmi, 1);
 
/*Wait for PHY PLL lock */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index bae79f3..6e4fb2e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -25,6 +25,7 @@ enum dw_hdmi_devtype {
IMX6Q_HDMI,
IMX6DL_HDMI,
RK3288_HDMI,
+   DWC_HDMI,
 };
 
 struct dw_hdmi_mpll_config {
-- 
2.1.4

[PATCH 1/2 v9] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

A PCM extension was added to I2S driver so that audio
samples are transferred using PIO mode.

The PCM supports two channels @ 16 or 32 bits with rates
32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine the
I2S controller can be built without DMA support, therefore
this is the reason why this extension was added.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

Changes v8 -> v9:
* Use defines in IRQ handling

Changes v7 -> v8:
* Build PIO PCM as module
* Always unmask interrupts even when in DMA mode
* Fallback to PIO mode only if ALSA DMA engine probe fails

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware_i2s.c | 161 +
 sound/soc/dwc/designware_pcm.c | 225 +
 sound/soc/dwc/local.h  | 128 +++
 5 files changed, 436 insertions(+), 88 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..c297efe 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   tristate "PCM PIO extension for I2S driver"
+   depends on SND_DESIGNWARE_I2S
+   help
+Say Y, M or N if you want to add a custom ALSA extension that registers
+a PCM and uses PIO to transfer data.
+
+This functionality is specially suited for I2S devices that don't have
+DMA support.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
 obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
 
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 4c4f0dc..591854e 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,90 +24,7 @@
 #include 
 #include 
 #include 
-
-/* common register for all channel */
-#define IER0x000
-#define IRER   0x004
-#define ITER   0x008
-#define CER0x00C
-#define CCR0x010
-#define RXFFR  0x014
-#define TXFFR  0x018
-
-/* I2STxRxRegisters for all channels */
-#define LRBR_LTHR(x)   (0x40 * x + 0x020)
-#define RRBR_RTHR(x)   (0x40 * x + 0x024)
-#define RER(x) (0x40 * x + 0x028)
-#define TER(x) (0x40 * x + 0x02C)
-#define RCR(x) (0x40 * x + 0x030)
-#define TCR(x) (0x40 * x + 0x034)
-#define ISR(x) (0x40 * x + 0x038)
-#define IMR(x) (0x40 * x + 0x03C)
-#define ROR(x) (0x40 * x + 0x040)
-#define TOR(x) (0x40 * x + 0x044)
-#define RFCR(x)(0x40 * x + 0x048)
-#define TFCR(x)(0x40 * x + 0x04C)
-#define RFF(x) (0x40 * x + 0x050)
-#define TFF(x) (0x40 * x + 0x054)
-
-/* I2SCOMPRegisters */
-#define I2S_COMP_PARAM_2   0x01F0
-#define I2S_COMP_PARAM_1   0x01F4
-#define I2S_COMP_VERSION   0x01F8
-#define I2S_COMP_TYPE  0x01FC
-
-/*
- * Component parameter register fields - define the I2S block's
- * configuration.
- */
-#defineCOMP1_TX_WORDSIZE_3(r)  (((r) & GENMASK(27, 25)) >> 25)
-#defineCOMP1_TX_WORDSIZE_2(r)  (((r) & GENMASK(24, 22)) >> 22)
-#defineCOMP1_TX_WORDSIZE_1(r)  (((r) & GENMASK(21, 19)) >> 19)
-#defineCOMP1_TX_WORDSIZE_0(r)  (((r) & GENMASK(18, 16)) >> 16)
-#defineCOMP1_TX_CHANNELS(r)(((r) & GENMASK(10, 9)) >> 9)
-#defineCOMP1_RX_CHANNELS(r)(((r) & GENMASK(8, 7)) >> 7)
-#defineCOMP1_RX_ENABLED(r) (((r) &

[PATCH 0/2 v9] Add I2S audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds I2S audio for the AXS10x platform.

NOTE:
Although the mainline I2S driver uses ALSA DMA engine, this controller
can be built without DMA support so it was necessary to add this
custom platform driver so that HDMI audio works in AXS boards.

Changes v8 -> v9:
* Use defines in IRQ handling

Changes v7 -> v8:
* Build PIO PCM as module
* Always unmask interrupts even when in DMA mode
* Fallback to PIO mode only if ALSA DMA engine probe fails

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Dropped adv7511 audio patches
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org

Jose Abreu (2):
  ASoC: dwc: Add PIO PCM extension
  ASoC: dwc: Add irq parameter to DOCUMENTATION

 .../devicetree/bindings/sound/designware-i2s.txt   |   4 +
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware_i2s.c | 161 +++
 sound/soc/dwc/designware_pcm.c | 225 +
 sound/soc/dwc/local.h  | 128 
 6 files changed, 440 insertions(+), 88 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

-- 
1.9.1

[PATCH 2/2 v9] ASoC: dwc: Add irq parameter to DOCUMENTATION

[Jose Abreu]

A parameter description for the interruptions of the
I2S controller was added.

Signed-off-by: Jose Abreu 
Acked-by: Rob Herring 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

No changes v7 -> v9.

Changes v6 -> v7:
* interrupts is now optional property

No changes v5 -> v6.

Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..6a536d5 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -12,6 +12,10 @@ Required properties:
one for receive.
  - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
 
+Optional properties:
+ - interrupts: The interrupt line number for the I2S controller. Add this
+   parameter if the I2S controller that you are using does not support DMA.
+
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
* resource-names.txt
-- 
1.9.1

[PATCH 1/2 v8] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

A PCM extension was added to I2S driver so that audio
samples are transferred using PIO mode.

The PCM supports two channels @ 16 or 32 bits with rates
32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine the
I2S controller can be built without DMA support, therefore
this is the reason why this extension was added.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

Changes v7 -> v8:
* Build PIO PCM as module
* Always unmask interrupts even when in DMA mode
* Fallback to PIO mode only if ALSA DMA engine probe fails

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware_i2s.c | 152 
 sound/soc/dwc/designware_pcm.c | 222 +
 sound/soc/dwc/local.h  | 122 ++
 5 files changed, 418 insertions(+), 88 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..c297efe 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   tristate "PCM PIO extension for I2S driver"
+   depends on SND_DESIGNWARE_I2S
+   help
+Say Y, M or N if you want to add a custom ALSA extension that registers
+a PCM and uses PIO to transfer data.
+
+This functionality is specially suited for I2S devices that don't have
+DMA support.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
 obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
 
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 4c4f0dc..a238fa0 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,90 +24,7 @@
 #include 
 #include 
 #include 
-
-/* common register for all channel */
-#define IER0x000
-#define IRER   0x004
-#define ITER   0x008
-#define CER0x00C
-#define CCR0x010
-#define RXFFR  0x014
-#define TXFFR  0x018
-
-/* I2STxRxRegisters for all channels */
-#define LRBR_LTHR(x)   (0x40 * x + 0x020)
-#define RRBR_RTHR(x)   (0x40 * x + 0x024)
-#define RER(x) (0x40 * x + 0x028)
-#define TER(x) (0x40 * x + 0x02C)
-#define RCR(x) (0x40 * x + 0x030)
-#define TCR(x) (0x40 * x + 0x034)
-#define ISR(x) (0x40 * x + 0x038)
-#define IMR(x) (0x40 * x + 0x03C)
-#define ROR(x) (0x40 * x + 0x040)
-#define TOR(x) (0x40 * x + 0x044)
-#define RFCR(x)(0x40 * x + 0x048)
-#define TFCR(x)(0x40 * x + 0x04C)
-#define RFF(x) (0x40 * x + 0x050)
-#define TFF(x) (0x40 * x + 0x054)
-
-/* I2SCOMPRegisters */
-#define I2S_COMP_PARAM_2   0x01F0
-#define I2S_COMP_PARAM_1   0x01F4
-#define I2S_COMP_VERSION   0x01F8
-#define I2S_COMP_TYPE  0x01FC
-
-/*
- * Component parameter register fields - define the I2S block's
- * configuration.
- */
-#defineCOMP1_TX_WORDSIZE_3(r)  (((r) & GENMASK(27, 25)) >> 25)
-#defineCOMP1_TX_WORDSIZE_2(r)  (((r) & GENMASK(24, 22)) >> 22)
-#defineCOMP1_TX_WORDSIZE_1(r)  (((r) & GENMASK(21, 19)) >> 19)
-#defineCOMP1_TX_WORDSIZE_0(r)  (((r) & GENMASK(18, 16)) >> 16)
-#defineCOMP1_TX_CHANNELS(r)(((r) & GENMASK(10, 9)) >> 9)
-#defineCOMP1_RX_CHANNELS(r)(((r) & GENMASK(8, 7)) >> 7)
-#defineCOMP1_RX_ENABLED(r) (((r) & BIT(6)) >> 6)
-#defineCOMP1

[PATCH 0/2 v8] Add I2S audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds I2S audio for the AXS10x platform.

NOTE:
Although the mainline I2S driver uses ALSA DMA engine, this controller
can be built without DMA support so it was necessary to add this
custom platform driver so that HDMI audio works in AXS boards.

Changes v7 -> v8:
* Build PIO PCM as module
* Always unmask interrupts even when in DMA mode
* Fallback to PIO mode only if ALSA DMA engine probe fails

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Dropped adv7511 audio patches
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org

Jose Abreu (2):
  ASoC: dwc: Add PIO PCM extension
  ASoC: dwc: Add irq parameter to DOCUMENTATION

 .../devicetree/bindings/sound/designware-i2s.txt   |   4 +
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware_i2s.c | 152 ++
 sound/soc/dwc/designware_pcm.c | 222 +
 sound/soc/dwc/local.h  | 122 +++
 6 files changed, 422 insertions(+), 88 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

-- 
1.9.1

[PATCH 2/2 v8] ASoC: dwc: Add irq parameter to DOCUMENTATION

[Jose Abreu]

A parameter description for the interruptions of the
I2S controller was added.

Signed-off-by: Jose Abreu 
Acked-by: Rob Herring 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

No changes v7 -> v8.

Changes v6 -> v7:
* interrupts is now optional property

No changes v5 -> v6.

Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..6a536d5 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -12,6 +12,10 @@ Required properties:
one for receive.
  - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
 
+Optional properties:
+ - interrupts: The interrupt line number for the I2S controller. Add this
+   parameter if the I2S controller that you are using does not support DMA.
+
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
* resource-names.txt
-- 
1.9.1

Re: DRM DMA Engine

[Jose Abreu]

++ Daniel


On 30-05-2016 09:44, Jose Abreu wrote:
> Hi Daniel,
>
> Thanks for your answer.
>
> On 26-05-2016 09:06, Daniel Vetter wrote:
>> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote:
>>> Hi all,
>>>
>>> Currently I am trying to develop a DRM driver that will use
>>> Xilinx VDMA to transfer video data to a HDMI TX Phy and I am
>>> facing a difficulty regarding the understanding of the DRM DMA
>>> Engine. I looked at several sources and at the DRM core source
>>> but the flow of creating and interfacing with the DMA controller
>>> is still not clear to me.
>>>
>>> At DRI web page the X server is mentioned. Does it mean that the
>>> channel creation and handling is done by the X server? If so,
>>> what is the DRM driver responsible to do then and what exactly
>>> does the DRM core do? As I am using Xilinx VDMA do you foresee
>>> any special implementation details?
>>>
>>> Just for reference here is the description of the Xilinx VDMA:
>>> "The Advanced eXtensible Interface Video Direct Memory Access
>>> (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core
>>> providing high-bandwidth direct memory access between memory and
>>> AXI4-Stream video type target peripherals including  peripherals
>>> which support AXI4-Stream Video Protocol." The driver is
>>> available at "drivers/dma/xilinx/xilinx_vdma.c".
>>>
>>> Another important point: I am using PCI Express connected to a
>>> FPGA which has all the necessary components (Xilinx VDMA, I2S,
>>> ...) and the HDMI TX Phy.
>>>
>>> Looking forward to you help.
>> If your dma engine is just for HDMI display, forget all the stuff you find
>> about DRI and X server on the various wikis. That's for opengl rendering.
>>
>> The only thing you need is a kernel-modesetting driver, and nowadays those
>> are written using the atomic modeset framework. There's plenty of
>> introductory talks and stuff all over the web (I suggest the latest
>> version of Laurent Pinchart's talk as a good starting point).
>> -Daniel
> I watched the talk of Laurent and I already have a simple KMS
> driver with an encoder (which is bridge dw-hdmi), a connector and
> a crtc. My doubt now is how do I setup the video path so that
> video samples are sent using the Xilinx VDMA to our hdmi phy.
>
> Sorry if I am making some mistake (I am quite new to DRM and DMA)
> but here is my thoughts:
> - A DMA channel or some kind of mapping must be done so that
> the DRM driver knows where to send samples;
> - The Xilinx VDMA driver must be instantiated (which I am
> already doing);
> - Some kind of association between the DRM DMA engine and
> Xilinx VDMA must be done;
> - A callback should exist that is called on each frame and
> updates the data that is sent to Xilinx VDMA.
>
> Does this looks okay to you or am I missing something? I still
> haven't figured out how should I associate the VDMA to the DRM
> DMA engine and how should I map the DMA to the DRM driver.
>
> Can you give me some help or refer me to someone who can? Also,
> is there a DRM driver that uses a similar architecture?
>
>
>>> Best regards,
>>> Jose Miguel Abreu
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Best regards,
> Jose Miguel Abreu

Re: DRM DMA Engine

[Jose Abreu]

Hi Daniel,

Thanks for your answer.

On 26-05-2016 09:06, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote:
>> Hi all,
>>
>> Currently I am trying to develop a DRM driver that will use
>> Xilinx VDMA to transfer video data to a HDMI TX Phy and I am
>> facing a difficulty regarding the understanding of the DRM DMA
>> Engine. I looked at several sources and at the DRM core source
>> but the flow of creating and interfacing with the DMA controller
>> is still not clear to me.
>>
>> At DRI web page the X server is mentioned. Does it mean that the
>> channel creation and handling is done by the X server? If so,
>> what is the DRM driver responsible to do then and what exactly
>> does the DRM core do? As I am using Xilinx VDMA do you foresee
>> any special implementation details?
>>
>> Just for reference here is the description of the Xilinx VDMA:
>> "The Advanced eXtensible Interface Video Direct Memory Access
>> (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core
>> providing high-bandwidth direct memory access between memory and
>> AXI4-Stream video type target peripherals including  peripherals
>> which support AXI4-Stream Video Protocol." The driver is
>> available at "drivers/dma/xilinx/xilinx_vdma.c".
>>
>> Another important point: I am using PCI Express connected to a
>> FPGA which has all the necessary components (Xilinx VDMA, I2S,
>> ...) and the HDMI TX Phy.
>>
>> Looking forward to you help.
> If your dma engine is just for HDMI display, forget all the stuff you find
> about DRI and X server on the various wikis. That's for opengl rendering.
>
> The only thing you need is a kernel-modesetting driver, and nowadays those
> are written using the atomic modeset framework. There's plenty of
> introductory talks and stuff all over the web (I suggest the latest
> version of Laurent Pinchart's talk as a good starting point).
> -Daniel

I watched the talk of Laurent and I already have a simple KMS
driver with an encoder (which is bridge dw-hdmi), a connector and
a crtc. My doubt now is how do I setup the video path so that
video samples are sent using the Xilinx VDMA to our hdmi phy.

Sorry if I am making some mistake (I am quite new to DRM and DMA)
but here is my thoughts:
- A DMA channel or some kind of mapping must be done so that
the DRM driver knows where to send samples;
- The Xilinx VDMA driver must be instantiated (which I am
already doing);
- Some kind of association between the DRM DMA engine and
Xilinx VDMA must be done;
- A callback should exist that is called on each frame and
updates the data that is sent to Xilinx VDMA.

Does this looks okay to you or am I missing something? I still
haven't figured out how should I associate the VDMA to the DRM
DMA engine and how should I map the DMA to the DRM driver.

Can you give me some help or refer me to someone who can? Also,
is there a DRM driver that uses a similar architecture?


>> Best regards,
>> Jose Miguel Abreu
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best regards,
Jose Miguel Abreu

DRM DMA Engine

[Jose Abreu]

Hi all,

Currently I am trying to develop a DRM driver that will use
Xilinx VDMA to transfer video data to a HDMI TX Phy and I am
facing a difficulty regarding the understanding of the DRM DMA
Engine. I looked at several sources and at the DRM core source
but the flow of creating and interfacing with the DMA controller
is still not clear to me.

At DRI web page the X server is mentioned. Does it mean that the
channel creation and handling is done by the X server? If so,
what is the DRM driver responsible to do then and what exactly
does the DRM core do? As I am using Xilinx VDMA do you foresee
any special implementation details?

Just for reference here is the description of the Xilinx VDMA:
"The Advanced eXtensible Interface Video Direct Memory Access
(AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core
providing high-bandwidth direct memory access between memory and
AXI4-Stream video type target peripherals including  peripherals
which support AXI4-Stream Video Protocol." The driver is
available at "drivers/dma/xilinx/xilinx_vdma.c".

Another important point: I am using PCI Express connected to a
FPGA which has all the necessary components (Xilinx VDMA, I2S,
...) and the HDMI TX Phy.

Looking forward to you help.

Best regards,
Jose Miguel Abreu

Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

Hi Mark,


On 25-05-2016 11:18, Mark Brown wrote:
> On Wed, May 25, 2016 at 11:11:47AM +0100, Jose Abreu wrote:
>
>> I think I will take the second option. Something like this:
>> "
>> ret = snd_dmaengine_pcm_register(...)
>> if (ret == -EPROBE_DEFER)
>> return ret;
>> else
>> pio_register(...);
>> "?
> Sure.  You should print a diagnostic if you fail to get the DMA, for any
> real system it's going to be a bug.

Ok, will do that. I noticed the last I2S patch that you merged
("ASoC: dwc: Add helper functions to disable/enable irqs") is not
in for-next yet. Should I base my work on 'topic/dwc' branch?

Best regards,
Jose Miguel Abreu

Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

Hi Mark,


On 24-05-2016 18:51, Mark Brown wrote:
> On Tue, May 24, 2016 at 06:07:14PM +0100, Jose Abreu wrote:
>> On 24-05-2016 17:41, Mark Brown wrote:
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.
>
>>>>if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>>>>i2s_write_reg(dev->i2s_base, ITER, 1);
>>> That seems wrong, or at least something that should be separate?
>>> Previously we needed interrupts for DMA operation but now we enable
>>> interrupts only if we don't use DMA.  It feels like we want to make the
>>> change for DMA separately if only to make it clear for bisection, are we
>>> 100% sure that masking the interrupt won't also mask the DMA request
>>> signals?
>> Indeed I thought about this and the interrupts must also be enabled when in 
>> DMA
>> mode. Although there is no interrupt handler in the original driver (without
>> this patches) in some setups the interrupt line may be connected to the DMA
>> controller. I will drop this change and always enable interrupts. Please note
>> that I don't have a setup with DMA support so I can only test using the PIO 
>> mode.
> Presumably you can talk to your hardware colleagues and get them to make
> you a FPGA with a DMA IP available?

Its already in the todo list.

>
>>> This also seems wrong.  We're forcing PIO if an interrupt is provided
>>> rather than based on DMA being configured which means that if the
>>> interrupt is wired up and happens to be described in DT we'll get worse
>> How should I then determine which mode to use?
>> - Check if DMA parameters are declared in DT, or
>> - Check if snd_dmaengine_pcm_register() fails, or
>> - Assume PIO mode will be used when compiling with PIO PCM, or
>> - Something else ?
> You could either unconditionally register the PIO driver and only
> actually start using it if the driver is instantiated or you could check
> to see if the registration function works (handling deferred probe - if
> the DMA driver just didn't load yet you should wait for it).

I think I will take the second option. Something like this:
"
ret = snd_dmaengine_pcm_register(...)
if (ret == -EPROBE_DEFER)
return ret;
else
pio_register(...);
"?


Best regards,
Jose Miguel Abreu

Re: [PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

Hi Mark,

Thanks for your comments.

On 24-05-2016 17:41, Mark Brown wrote:
> On Mon, May 23, 2016 at 11:02:24AM +0100, Jose Abreu wrote:
>
>> +config SND_DESIGNWARE_PCM
>> +bool "PCM PIO extension for I2S driver"
> Why can't this be built as a module?

I can change but my intention was to make this PCM a kind of extension to the
driver instead of adding a new module to the system.

>
>> +
>> +return irq_valid ? IRQ_HANDLED : IRQ_NONE;
> Please write a normal if statement, the ternery operator doesn't help
> legibility.

Ok.

>
>>  static void i2s_start(struct dw_i2s_dev *dev,
>>struct snd_pcm_substream *substream)
>>  {
>>  struct i2s_clk_config_data *config = &dev->config;
>>  
>>  i2s_write_reg(dev->i2s_base, IER, 1);
>> -i2s_enable_irqs(dev, substream->stream, config->chan_nr);
>> +
>> +if (dev->use_pio)
>> +i2s_enable_irqs(dev, substream->stream, config->chan_nr);
>>  
>>  if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>>  i2s_write_reg(dev->i2s_base, ITER, 1);
> That seems wrong, or at least something that should be separate?
> Previously we needed interrupts for DMA operation but now we enable
> interrupts only if we don't use DMA.  It feels like we want to make the
> change for DMA separately if only to make it clear for bisection, are we
> 100% sure that masking the interrupt won't also mask the DMA request
> signals?

Indeed I thought about this and the interrupts must also be enabled when in DMA
mode. Although there is no interrupt handler in the original driver (without
this patches) in some setups the interrupt line may be connected to the DMA
controller. I will drop this change and always enable interrupts. Please note
that I don't have a setup with DMA support so I can only test using the PIO 
mode.

>> +irq = platform_get_irq(pdev, 0);
>> +if (irq >= 0) {
>> +dev_dbg(&pdev->dev, "using PIO mode\n");
>> +dev->use_pio = true;
>> +
>> +ret = devm_request_irq(&pdev->dev, irq, i2s_irq_handler, 0,
>> +pdev->name, dev);
>> +if (ret < 0) {
>> +dev_err(&pdev->dev, "failed to request irq\n");
>> +return ret;
>> +}
>> +}
> This also seems wrong.  We're forcing PIO if an interrupt is provided
> rather than based on DMA being configured which means that if the
> interrupt is wired up and happens to be described in DT we'll get worse
> performance.  People should be able to just describe the system without
> worrying about this, and we might find some other use for the interrupts
> in future.  Indeed right now it would probably be reasonable to use the
> error interrupts all the time if they're available.

How should I then determine which mode to use?
- Check if DMA parameters are declared in DT, or
- Check if snd_dmaengine_pcm_register() fails, or
- Assume PIO mode will be used when compiling with PIO PCM, or
- Something else ?

Best regards,
Jose Miguel Abreu

[PATCH 2/4 v7] ASoC: dwc: Do not use devm_clk_get() if using platform data

[Jose Abreu]

When using platform data the devm_clk_get() function is
called causing a probe failure if the clock is not
declared. As we can pass the clock handler by platform
data call only devm_clk_get() when platform data is not
used.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---

This patch was only introduced in v7.

 sound/soc/dwc/designware_i2s.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 4c4f0dc..a97be8e 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -690,15 +690,16 @@ static int dw_i2s_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no clock configure 
method\n");
return -ENODEV;
}
-   }
-   dev->clk = devm_clk_get(&pdev->dev, clk_id);
+   } else {
+   dev->clk = devm_clk_get(&pdev->dev, clk_id);
 
-   if (IS_ERR(dev->clk))
-   return PTR_ERR(dev->clk);
+   if (IS_ERR(dev->clk))
+   return PTR_ERR(dev->clk);
 
-   ret = clk_prepare_enable(dev->clk);
-   if (ret < 0)
-   return ret;
+   ret = clk_prepare_enable(dev->clk);
+   if (ret < 0)
+   return ret;
+   }
}
 
dev_set_drvdata(&pdev->dev, dev);
-- 
1.9.1

[PATCH 1/4 v7] ASoC: dwc: Add helper functions to disable/enable irqs

[Jose Abreu]

Helper functions to disable and enable the I2S interrupts were
added. Only the interrupts of the used channels are enabled.

Also, there is no need to enable irqs at dw_i2s_config(), they
are already enabled at startup.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---

This patch was only introduced in v7.

 sound/soc/dwc/designware_i2s.c | 68 +-
 1 file changed, 41 insertions(+), 27 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..4c4f0dc 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -145,26 +145,54 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev, 
u32 stream)
}
 }
 
-static void i2s_start(struct dw_i2s_dev *dev,
- struct snd_pcm_substream *substream)
+static inline void i2s_disable_irqs(struct dw_i2s_dev *dev, u32 stream,
+   int chan_nr)
 {
-   struct i2s_clk_config_data *config = &dev->config;
u32 i, irq;
-   i2s_write_reg(dev->i2s_base, IER, 1);
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   for (i = 0; i < (config->chan_nr / 2); i++) {
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   for (i = 0; i < (chan_nr / 2); i++) {
+   irq = i2s_read_reg(dev->i2s_base, IMR(i));
+   i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x30);
+   }
+   } else {
+   for (i = 0; i < (chan_nr / 2); i++) {
+   irq = i2s_read_reg(dev->i2s_base, IMR(i));
+   i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x03);
+   }
+   }
+}
+
+static inline void i2s_enable_irqs(struct dw_i2s_dev *dev, u32 stream,
+  int chan_nr)
+{
+   u32 i, irq;
+
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   for (i = 0; i < (chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x30);
}
-   i2s_write_reg(dev->i2s_base, ITER, 1);
} else {
-   for (i = 0; i < (config->chan_nr / 2); i++) {
+   for (i = 0; i < (chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x03);
}
-   i2s_write_reg(dev->i2s_base, IRER, 1);
}
+}
+
+static void i2s_start(struct dw_i2s_dev *dev,
+ struct snd_pcm_substream *substream)
+{
+   struct i2s_clk_config_data *config = &dev->config;
+
+   i2s_write_reg(dev->i2s_base, IER, 1);
+   i2s_enable_irqs(dev, substream->stream, config->chan_nr);
+
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   i2s_write_reg(dev->i2s_base, ITER, 1);
+   else
+   i2s_write_reg(dev->i2s_base, IRER, 1);
 
i2s_write_reg(dev->i2s_base, CER, 1);
 }
@@ -172,24 +200,14 @@ static void i2s_start(struct dw_i2s_dev *dev,
 static void i2s_stop(struct dw_i2s_dev *dev,
struct snd_pcm_substream *substream)
 {
-   u32 i = 0, irq;
 
i2s_clear_irqs(dev, substream->stream);
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
i2s_write_reg(dev->i2s_base, ITER, 0);
-
-   for (i = 0; i < 4; i++) {
-   irq = i2s_read_reg(dev->i2s_base, IMR(i));
-   i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x30);
-   }
-   } else {
+   else
i2s_write_reg(dev->i2s_base, IRER, 0);
 
-   for (i = 0; i < 4; i++) {
-   irq = i2s_read_reg(dev->i2s_base, IMR(i));
-   i2s_write_reg(dev->i2s_base, IMR(i), irq | 0x03);
-   }
-   }
+   i2s_disable_irqs(dev, substream->stream, 8);
 
if (!dev->active) {
i2s_write_reg(dev->i2s_base, CER, 0);
@@ -223,7 +241,7 @@ static int dw_i2s_startup(struct snd_pcm_substream 
*substream,
 
 static void dw_i2s_config(struct dw_i2s_dev *dev, int stream)
 {
-   u32 ch_reg, irq;
+   u32 ch_reg;
struct i2s_clk_config_data *config = &dev->config;
 
 
@@ -235,16 +253,12 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int 
stream)
  dev->xfer_resolution);
i2s_write_reg

[PATCH 3/4 v7] ASoC: dwc: Add PIO PCM extension

[Jose Abreu]

A PCM extension was added to I2S driver so that audio
samples are transferred using PIO mode.

The PCM supports two channels @ 16 or 32 bits with rates
32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine the
I2S controller can be built without DMA support, therefore
this is the reason why this extension was added.

The selection between the use of DMA engine or PIO mode
is detected by declaring or not the interrupt parameters
in the DT and using Kconfig.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   5 +-
 sound/soc/dwc/designware_i2s.c | 148 ---
 sound/soc/dwc/designware_pcm.c | 220 +
 sound/soc/dwc/local.h  | 122 +++
 5 files changed, 415 insertions(+), 89 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..c6fd95f 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   bool "PCM PIO extension for I2S driver"
+   depends on SND_DESIGNWARE_I2S
+   help
+Say Y or N if you want to add a custom ALSA extension that registers
+a PCM and uses PIO to transfer data.
+
+This functionality is specially suited for I2S devices that don't have
+DMA support.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..11ea966 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
-obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
-
+obj-$(CONFIG_SND_DESIGNWARE_I2S) += dwc_i2s.o
+dwc_i2s-y := designware_i2s.o
+dwc_i2s-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index a97be8e..d4c3811 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,90 +24,7 @@
 #include 
 #include 
 #include 
-
-/* common register for all channel */
-#define IER0x000
-#define IRER   0x004
-#define ITER   0x008
-#define CER0x00C
-#define CCR0x010
-#define RXFFR  0x014
-#define TXFFR  0x018
-
-/* I2STxRxRegisters for all channels */
-#define LRBR_LTHR(x)   (0x40 * x + 0x020)
-#define RRBR_RTHR(x)   (0x40 * x + 0x024)
-#define RER(x) (0x40 * x + 0x028)
-#define TER(x) (0x40 * x + 0x02C)
-#define RCR(x) (0x40 * x + 0x030)
-#define TCR(x) (0x40 * x + 0x034)
-#define ISR(x) (0x40 * x + 0x038)
-#define IMR(x) (0x40 * x + 0x03C)
-#define ROR(x) (0x40 * x + 0x040)
-#define TOR(x) (0x40 * x + 0x044)
-#define RFCR(x)(0x40 * x + 0x048)
-#define TFCR(x)(0x40 * x + 0x04C)
-#define RFF(x) (0x40 * x + 0x050)
-#define TFF(x) (0x40 * x + 0x054)
-
-/* I2SCOMPRegisters */
-#define I2S_COMP_PARAM_2   0x01F0
-#define I2S_COMP_PARAM_1   0x01F4
-#define I2S_COMP_VERSION   0x01F8
-#define I2S_COMP_TYPE  0x01FC
-
-/*
- * Component parameter register fields - define the I2S block's
- * configuration.
- */
-#defineCOMP1_TX_WORDSIZE_3(r)  (((r) & GENMASK(27, 25)) >> 25)
-#defineCOMP1_TX_WORDSIZE_2(r)  (((r) & GENMASK(24, 22)) >> 22)
-#defineCOMP1_TX_WORDSIZE_1(r)  (((r) & GENMASK(21, 19)) >> 19)
-#defineCOMP1_TX_WORDSIZE_0(r)  (((r) & GENMASK(18, 16)) >> 16)
-#defineCOMP1_TX_CHANNELS(r)(((r) & GENMASK(10, 9)) >> 9)
-#defineCOMP1_RX_CHANNELS(r)(((r) & GENMASK(8, 7)) >> 7)
-#defineC

[PATCH 0/4 v7] Add I2S audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds I2S audio for the AXS10x platform.

NOTE:
Although the mainline I2S driver uses ALSA DMA engine, this controller
can be built without DMA support so it was necessary to add this
custom platform driver so that HDMI audio works in AXS boards.

Changes v6 -> v7:
* Discard the use of memcpy
* Report IRQ_HANDLED only when there is an IRQ
* Use interrupts to check if PIO mode is in use
* Unmask interrupts only when in PIO mode
* Remove empty functions

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Dropped adv7511 audio patches
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Jose Abreu (4):
  ASoC: dwc: Add helper functions to disable/enable irqs
  ASoC: dwc: Do not use devm_clk_get() if using platform data
  ASoC: dwc: Add PIO PCM extension
  ASoC: dwc: Add irq parameter to DOCUMENTATION

 .../devicetree/bindings/sound/designware-i2s.txt   |   4 +
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   5 +-
 sound/soc/dwc/designware_i2s.c | 229 ++---
 sound/soc/dwc/designware_pcm.c | 220 
 sound/soc/dwc/local.h  | 122 +++
 6 files changed, 467 insertions(+), 122 deletions(-)
 create mode 100644 sound/soc/dwc/designware_pcm.c
 create mode 100644 sound/soc/dwc/local.h

-- 
1.9.1

[PATCH 4/4 v7] ASoC: dwc: Add irq parameter to DOCUMENTATION

[Jose Abreu]

A parameter description for the interruptions of the
I2S controller was added. This interrupt parameter
should only be set when I2S does not have DMA support.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---

Changes v6 -> v7:
* interrupts is now optional property

No changes v5 -> v6.

Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..6a536d5 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -12,6 +12,10 @@ Required properties:
one for receive.
  - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
 
+Optional properties:
+ - interrupts: The interrupt line number for the I2S controller. Add this
+   parameter if the I2S controller that you are using does not support DMA.
+
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
* resource-names.txt
-- 
1.9.1

Re: [RESEND PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock

[Jose Abreu]

Hi Vineet,


On 02-05-2016 10:39, Jose Abreu wrote:
> Add device tree bindings for AXS10X I2S PLL Clock driver.
>
> Signed-off-by: Jose Abreu 
> Acked-by: Alexey Brodkin 
> Acked-by: Vineet Gupta 
> ---
>
> Changes v5 -> v6:
> * Added 'clocks' field
>
> This patch was only introduced in v5.
>
> Cc: Carlos Palminha 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Michael Turquette 
> Cc: Stephen Boyd 
> Cc: Alexey Brodkin 
> Cc: Vineet Gupta 
> Cc: linux-snps-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
>
>  arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi 
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index ab5d570..5c6489e 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -16,7 +16,20 @@
>   ranges = <0x 0xe000 0x1000>;
>   interrupt-parent = <&mb_intc>;
>  
> + i2sclk: i2sclk@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&i2spll_clk>;
> + #clock-cells = <0>;
> + };
> +
>   clocks {
> + i2spll_clk: i2spll_clk {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
>   i2cclk: i2cclk {
>   compatible = "fixed-clock";
>   clock-frequency = <5000>;

Can you apply this to arc-next? Main driver was already merged into clk-next. We
still have to check how to deal with the parent clock frequency that will change
in the next firmware release.

Best regards,
Jose Miguel Abreu

[RESEND PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch has the goal of adding a clock driver
that programs this PLL.

At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.

Signed-off-by: Jose Abreu 
---

Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)

Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

Cc: Carlos Palminha 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 228 +
 4 files changed, 255 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..5ffc8df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,25 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- reg : address and length of the I2S PLL register set.
+- clocks: shall be the input parent clock phandle for the PLL.
+- #clock-cells: from common clock binding; Should always be set to 0.
+
+Example:
+   pll_clock: pll_clock {
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+   #clock-cells = <0>;
+   };
+
+   i2s_clock@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   clocks = <&pll_clock>;
+   #clock-cells = <0>;
+   };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
 obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X)  += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..411310d
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,228 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG   0x0
+#define PLL_FBDIV_REG  0x4
+#define PLL_ODIV0_REG  0x8
+#define PLL_ODIV1_REG  0xC
+
+struct i2s_pll_cfg {
+   unsigned int rate;
+   unsigned int idiv;
+   unsigned int fbdiv;
+   unsigned int odiv0;
+   unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+   /* 27 Mhz */
+   { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+   { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+   { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+   { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+   { 2822400, 0x82, 0x596, 0x10D35, 

[RESEND PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock

[Jose Abreu]

Add device tree bindings for AXS10X I2S PLL Clock driver.

Signed-off-by: Jose Abreu 
Acked-by: Alexey Brodkin 
Acked-by: Vineet Gupta 
---

Changes v5 -> v6:
* Added 'clocks' field

This patch was only introduced in v5.

Cc: Carlos Palminha 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org

 arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..5c6489e 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,7 +16,20 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
 
+   i2sclk: i2sclk@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   clocks = <&i2spll_clk>;
+   #clock-cells = <0>;
+   };
+
clocks {
+   i2spll_clk: i2spll_clk {
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+   #clock-cells = <0>;
+   };
+
i2cclk: i2cclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
-- 
1.9.1

[RESEND PATCH 0/2 v6] Add AXS10X I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch series has the goal of adding a clock driver
that programs this PLL.



Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
* Device tree update (added 'clocks' field)

Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)
* Added DT bindings

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

Cc: Carlos Palminha 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Michael Turquette 
Cc: Stephen Boyd 
Cc: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org

Jose Abreu (2):
  clk/axs10x: Add I2S PLL clock driver
  arc: axs10x: Add DT bindings for I2S PLL Clock

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
 arch/arc/boot/dts/axs10x_mb.dtsi   |  13 ++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 228 +
 5 files changed, 268 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

-- 
1.9.1

Re: [PATCH 1/2 v6] ASoC: dwc: Add custom PCM driver

[Jose Abreu]

Hi Mark,

Can you give me some comments regarding this patch? Am I following the right
track? This is the first time that I am using ALSA SoC so pardon me if I am
making some mistake. I would appreciate some kind of input. I tested this only
on a ARC SDP and it is working.

On 27-04-2016 11:05, Jose Abreu wrote:
> HDMI audio support was added to the AXS board using an
> I2S cpu driver and a custom platform driver.
>
> The platform driver supports two channels @ 16 bits with
> rates 32k, 44.1k and 48k.
>
> Although the mainline I2S driver uses ALSA DMA engine,
> this controller can be built without DMA support so it
> was necessary to add this custom platform driver so that
> HDMI audio works in AXS boards.
>
> The selection between the use of DMA engine or PIO mode
> is detected by declaring or not the DMA parameters in
> the device tree.
>
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Mark Brown 
> Cc: Liam Girdwood 
> Cc: Jaroslav Kysela 
> Cc: Takashi Iwai 
> Cc: Alexey Brodkin 
> Cc: linux-snps-...@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Changes v5 -> v6:
> * Use SNDRV_DMA_TYPE_CONTINUOUS
>
> Changes v4 -> v5:
> * Resolve undefined references when compiling as module
> * Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
> suggested by Lars-Peter Clausen)
>
> Changes v3 -> v4:
> * Reintroduced custom PCM driver
> * Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
>
> Changes v2 -> v3:
> * Removed pll_config functions (as suggested by Alexey Brodkin)
> * Dropped custom platform driver, using now ALSA DMA engine
> * Dropped IRQ handler for I2S
>
> No changes v1 -> v2.
>
>  sound/soc/dwc/Kconfig  |   9 ++
>  sound/soc/dwc/Makefile |   1 +
>  sound/soc/dwc/designware.h |  71 +
>  sound/soc/dwc/designware_i2s.c |  94 -
>  sound/soc/dwc/designware_pcm.c | 228 
> +
>  5 files changed, 376 insertions(+), 27 deletions(-)
>  create mode 100644 sound/soc/dwc/designware.h
>  create mode 100644 sound/soc/dwc/designware_pcm.c
>
> diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
> index d50e085..2a21120 100644
> --- a/sound/soc/dwc/Kconfig
> +++ b/sound/soc/dwc/Kconfig
> @@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
>Synopsys desigwnware I2S device. The device supports upto
>maximum of 8 channels each for play and record.
>  
> +config SND_DESIGNWARE_PCM
> + tristate "Synopsys I2S PCM Driver"
> + help
> +  Say Y or M if you want to add support for ALSA ASoC platform driver
> +  using I2S.
> +
> +  Select this option if you want to be able to create a sound interface
> +  using the I2S device driver as CPU driver. Instead of using ALSA
> +  DMA engine by selecting this driver a custom PCM driver will be used.
>  
> diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
> index 319371f..1b48bccc 100644
> --- a/sound/soc/dwc/Makefile
> +++ b/sound/soc/dwc/Makefile
> @@ -1,3 +1,4 @@
>  # SYNOPSYS Platform Support
>  obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
> +obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
>  
> diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
> new file mode 100644
> index 000..09fafee
> --- /dev/null
> +++ b/sound/soc/dwc/designware.h
> @@ -0,0 +1,71 @@
> +/*
> + * ALSA SoC Synopsys Audio Layer
> + *
> + * sound/soc/dwc/designware.h
> + *
> + * Copyright (C) 2016 Synopsys
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __DESIGNWARE_H
> +#define __DESIGNWARE_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct dw_pcm_binfo {
> + struct snd_pcm_substream *stream;
> + unsigned char *dma_base;
> + unsigned char *dma_pointer;
> + unsigned int period_size_frames;
> + unsigned int size;
> + snd_pcm_uframes_t period_pointer;
> + unsigned int total_periods;
> + unsigned int current_period;
> +};
> +
> +union dw_i2s_snd_dma_data {
> + struct i2s_dma_data pd;
> + struct snd_dmaengine_dai_dma_data dt;
> +};
> +
> +struct dw_i2s_dev {
> + void __iomem *i2s_base;
> + struct clk *clk;
> + int active;
> + unsigned int capability;
> + unsigned int quirks;
> + unsigned int i2s_reg_comp1;
> + unsigned int i2s_reg_comp2;
> +

Re: [PATCH 2/2 v6] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

Hi Mark,

Sorry. Follows bellow.

On 27-04-2016 11:05, Jose Abreu wrote:
> This patch updates documentation for the Designware I2S
> driver.
>
> Signed-off-by: Jose Abreu 
> Acked-by: Rob Herring 
> Cc: Rob Herring 
> Cc: Carlos Palminha 
> Cc: Alexey Brodkin 
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> No changes v5 -> v6.
>
> Changes v4 -> v5:
> * interrupts is now required property
> * Drop 'snps-use-dmaengine' property
>
> This patch was only introduced in v4.
>
>  Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
> b/Documentation/devicetree/bindings/sound/designware-i2s.txt
> index 7bb5424..27a728f 100644
> --- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
> @@ -3,14 +3,18 @@ DesignWare I2S controller
>  Required properties:
>   - compatible : Must be "snps,designware-i2s"
>   - reg : Must contain the I2S core's registers location and length
> + - interrupts:  where IRQ is the interrupt number.
>   - clocks : Pairs of phandle and specifier referencing the controller's
> clocks. The controller expects one clock: the clock used as the sampling
> rate reference clock sample.
>   - clock-names : "i2sclk" for the sample rate reference clock.
> +
> +Optional properties:
>   - dmas: Pairs of phandle and specifier for the DMA channels that are used by
> the core. The core expects one or two dma channels: one for transmit and
> -   one for receive.
> - - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
> +   one for receive. Set this parameter if the I2S DMA block is enabled.
> + - dma-names : "tx" for the transmit channel, "rx" for the receive channel. 
> Set
> +   this parameter if the I2S DMA block is enabled.
>  
>  For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
>  properties please check:
> @@ -23,6 +27,7 @@ Example:
>   soc_i2s: i2s@7ff9 {
>   compatible = "snps,designware-i2s";
>   reg = <0x0 0x7ff9 0x0 0x1000>;
> + interrupts = <15>;
>   clocks = <&scpi_i2sclk 0>;
>   clock-names = "i2sclk";
>   #sound-dai-cells = <0>;

[PATCH 2/2 v6] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

This patch updates documentation for the Designware I2S
driver.

Signed-off-by: Jose Abreu 
Acked-by: Rob Herring 
Cc: Rob Herring 
Cc: Carlos Palminha 
Cc: Alexey Brodkin 
Cc: devicet...@vger.kernel.org
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

No changes v5 -> v6.

Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..27a728f 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -3,14 +3,18 @@ DesignWare I2S controller
 Required properties:
  - compatible : Must be "snps,designware-i2s"
  - reg : Must contain the I2S core's registers location and length
+ - interrupts:  where IRQ is the interrupt number.
  - clocks : Pairs of phandle and specifier referencing the controller's
clocks. The controller expects one clock: the clock used as the sampling
rate reference clock sample.
  - clock-names : "i2sclk" for the sample rate reference clock.
+
+Optional properties:
  - dmas: Pairs of phandle and specifier for the DMA channels that are used by
the core. The core expects one or two dma channels: one for transmit and
-   one for receive.
- - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
+   one for receive. Set this parameter if the I2S DMA block is enabled.
+ - dma-names : "tx" for the transmit channel, "rx" for the receive channel. Set
+   this parameter if the I2S DMA block is enabled.
 
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
@@ -23,6 +27,7 @@ Example:
soc_i2s: i2s@7ff9 {
compatible = "snps,designware-i2s";
reg = <0x0 0x7ff9 0x0 0x1000>;
+   interrupts = <15>;
clocks = <&scpi_i2sclk 0>;
clock-names = "i2sclk";
#sound-dai-cells = <0>;
-- 
1.9.1

[PATCH 1/2 v6] ASoC: dwc: Add custom PCM driver

[Jose Abreu]

HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.

The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

The selection between the use of DMA engine or PIO mode
is detected by declaring or not the DMA parameters in
the device tree.

Signed-off-by: Jose Abreu 
Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---

Changes v5 -> v6:
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  71 +
 sound/soc/dwc/designware_i2s.c |  94 -
 sound/soc/dwc/designware_pcm.c | 228 +
 5 files changed, 376 insertions(+), 27 deletions(-)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..2a21120 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   tristate "Synopsys I2S PCM Driver"
+   help
+Say Y or M if you want to add support for ALSA ASoC platform driver
+using I2S.
+
+Select this option if you want to be able to create a sound interface
+using the I2S device driver as CPU driver. Instead of using ALSA
+DMA engine by selecting this driver a custom PCM driver will be used.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
 obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
 
diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
new file mode 100644
index 000..09fafee
--- /dev/null
+++ b/sound/soc/dwc/designware.h
@@ -0,0 +1,71 @@
+/*
+ * ALSA SoC Synopsys Audio Layer
+ *
+ * sound/soc/dwc/designware.h
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DESIGNWARE_H
+#define __DESIGNWARE_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dw_pcm_binfo {
+   struct snd_pcm_substream *stream;
+   unsigned char *dma_base;
+   unsigned char *dma_pointer;
+   unsigned int period_size_frames;
+   unsigned int size;
+   snd_pcm_uframes_t period_pointer;
+   unsigned int total_periods;
+   unsigned int current_period;
+};
+
+union dw_i2s_snd_dma_data {
+   struct i2s_dma_data pd;
+   struct snd_dmaengine_dai_dma_data dt;
+};
+
+struct dw_i2s_dev {
+   void __iomem *i2s_base;
+   struct clk *clk;
+   int active;
+   unsigned int capability;
+   unsigned int quirks;
+   unsigned int i2s_reg_comp1;
+   unsigned int i2s_reg_comp2;
+   struct device *dev;
+   u32 ccr;
+   u32 xfer_resolution;
+   u32 fifo_th;
+
+   /* data related to DMA transfers b/w i2s and DMAC */
+   bool use_dmaengine;
+   union dw_i2s_snd_dma_data play_dma_data;
+   union dw_i2s_snd_dma_data capture_dma_data;
+   struct i2s_clk_config_data config;
+   int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+   struct dw_pcm_binfo binfo;
+};
+
+#if IS_ENABLED(CONFIG_SND_DESIGNWARE_PCM)
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi);
+#else
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi)
+{
+   return 0;
+}
+#endif
+
+#endif
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..5ee0faf 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designwar

[PATCH 0/2 v6] Add I2S audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds I2S audio for the AXS10x platform.

Changes v5 -> v6
* Use SNDRV_DMA_TYPE_CONTINUOUS

Changes v4 -> v5
* Resolve undefined references when compiling as module
* Dropped adv7511 audio patches
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


NOTE:
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

Cc: Carlos Palminha 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Rob Herring 
Cc: Alexey Brodkin 
Cc: linux-snps-...@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Jose Abreu (2):
  ASoC: dwc: Add custom PCM driver
  ASoC: dwc: Update DOCUMENTATION for I2S Driver

 .../devicetree/bindings/sound/designware-i2s.txt   |   9 +-
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  71 +++
 sound/soc/dwc/designware_i2s.c |  94 ++---
 sound/soc/dwc/designware_pcm.c | 228 +
 6 files changed, 383 insertions(+), 29 deletions(-)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

-- 
1.9.1

Re: [PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi,

@Stephen: Is this version ok? The DT bindings were already acked by Vineet and
Alexey.

@Rob: Is this version ok? You already acked the previous version[1], see the
version log for differences. Please see also if [2] is ok.

[1] https://marc.info/?l=devicetree&m=146056894500509&w=2

[2] https://marc.info/?l=devicetree&m=146126139521541&w=2

On 21-04-2016 18:55, Jose Abreu wrote:
> Adding device tree mailing list and Rob Herring.
>
> On 21-04-2016 18:19, Jose Abreu wrote:
>> The ARC SDP I2S clock can be programmed using a
>> specific PLL.
>>
>> This patch has the goal of adding a clock driver
>> that programs this PLL.
>>
>> At this moment the rate values are hardcoded in
>> a table but in the future it would be ideal to
>> use a function which determines the PLL values
>> given the desired rate.
>>
>> Signed-off-by: Jose Abreu 
>> ---
>>
>> Changes v5 -> v6:
>> * Use parent clock to determine PLL input rate instead of using hardcoded 
>> values
>> * Documentation update (added 'clocks' field)
>>
>> Changes v4 -> v5:
>> * Documentation update (as suggested by Alexey Brodkin)
>> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
>> Alexey Brodkin)
>>
>> Changes v3 -> v4:
>> * Added binding document (as suggested by Stephen Boyd)
>> * Minor code style fixes (as suggested by Stephen Boyd)
>> * Use ioremap (as suggested by Stephen Boyd)
>> * Implement round_rate (as suggested by Stephen Boyd)
>> * Change to platform driver (as suggested by Stephen Boyd)
>> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
>>
>> Changes v2 -> v3:
>> * Implemented recalc_rate
>>
>> Changes v1 -> v2:
>> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
>> * Added more supported rates
>>
>>  .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
>>  drivers/clk/Makefile   |   1 +
>>  drivers/clk/axs10x/Makefile|   1 +
>>  drivers/clk/axs10x/i2s_pll_clock.c | 228 
>> +
>>  4 files changed, 255 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>>  create mode 100644 drivers/clk/axs10x/Makefile
>>  create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt 
>> b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>> new file mode 100644
>> index 000..5ffc8df
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>> @@ -0,0 +1,25 @@
>> +Binding for the AXS10X I2S PLL clock
>> +
>> +This binding uses the common clock binding[1].
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +
>> +Required properties:
>> +- compatible: shall be "snps,axs10x-i2s-pll-clock"
>> +- reg : address and length of the I2S PLL register set.
>> +- clocks: shall be the input parent clock phandle for the PLL.
>> +- #clock-cells: from common clock binding; Should always be set to 0.
>> +
>> +Example:
>> +pll_clock: pll_clock {
>> +compatible = "fixed-clock";
>> +clock-frequency = <2700>;
>> +#clock-cells = <0>;
>> +};
>> +
>> +i2s_clock@100a0 {
>> +compatible = "snps,axs10x-i2s-pll-clock";
>> +reg = <0x100a0 0x10>;
>> +clocks = <&pll_clock>;
>> +#clock-cells = <0>;
>> +};
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 46869d6..2ca62dc6 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -84,3 +84,4 @@ obj-$(CONFIG_X86)  += x86/
>>  obj-$(CONFIG_ARCH_ZX)   += zte/
>>  obj-$(CONFIG_ARCH_ZYNQ) += zynq/
>>  obj-$(CONFIG_H8300) += h8300/
>> +obj-$(CONFIG_ARC_PLAT_AXS10X)   += axs10x/
>> diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
>> new file mode 100644
>> index 000..01996b8
>> --- /dev/null
>> +++ b/drivers/clk/axs10x/Makefile
>> @@ -0,0 +1 @@
>> +obj-y += i2s_pll_clock.o
>> diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
>> b/drivers/clk/axs10x/i2s_pll_clock.c
>> new file mode 100644
>> index 000..411310d
>> --- /dev/null
&

Re: [PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock

[Jose Abreu]

Adding device tree mailing list and Rob Herring.

On 21-04-2016 18:19, Jose Abreu wrote:
> Add device tree bindings for AXS10X I2S PLL Clock driver.
>
> Signed-off-by: Jose Abreu 
> ---
>
> Changes v5 -> v6:
> * Added 'clocks' field
>
> This patch was only introduced in v5.
>
>  arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi 
> b/arch/arc/boot/dts/axs10x_mb.dtsi
> index ab5d570..5c6489e 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -16,7 +16,20 @@
>   ranges = <0x 0xe000 0x1000>;
>   interrupt-parent = <&mb_intc>;
>  
> + i2sclk: i2sclk@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&i2spll_clk>;
> + #clock-cells = <0>;
> + };
> +
>   clocks {
> + i2spll_clk: i2spll_clk {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
>   i2cclk: i2cclk {
>   compatible = "fixed-clock";
>   clock-frequency = <5000>;

Re: [PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Adding device tree mailing list and Rob Herring.

On 21-04-2016 18:19, Jose Abreu wrote:
> The ARC SDP I2S clock can be programmed using a
> specific PLL.
>
> This patch has the goal of adding a clock driver
> that programs this PLL.
>
> At this moment the rate values are hardcoded in
> a table but in the future it would be ideal to
> use a function which determines the PLL values
> given the desired rate.
>
> Signed-off-by: Jose Abreu 
> ---
>
> Changes v5 -> v6:
> * Use parent clock to determine PLL input rate instead of using hardcoded 
> values
> * Documentation update (added 'clocks' field)
>
> Changes v4 -> v5:
> * Documentation update (as suggested by Alexey Brodkin)
> * Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
> Alexey Brodkin)
>
> Changes v3 -> v4:
> * Added binding document (as suggested by Stephen Boyd)
> * Minor code style fixes (as suggested by Stephen Boyd)
> * Use ioremap (as suggested by Stephen Boyd)
> * Implement round_rate (as suggested by Stephen Boyd)
> * Change to platform driver (as suggested by Stephen Boyd)
> * Use {readl/writel}_relaxed (as suggested by Vineet Gupta)
>
> Changes v2 -> v3:
> * Implemented recalc_rate
>
> Changes v1 -> v2:
> * Renamed folder to axs10x (as suggested by Alexey Brodkin)
> * Added more supported rates
>
>  .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/axs10x/Makefile|   1 +
>  drivers/clk/axs10x/i2s_pll_clock.c | 228 
> +
>  4 files changed, 255 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
>  create mode 100644 drivers/clk/axs10x/Makefile
>  create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c
>
> diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt 
> b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> new file mode 100644
> index 000..5ffc8df
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
> @@ -0,0 +1,25 @@
> +Binding for the AXS10X I2S PLL clock
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible: shall be "snps,axs10x-i2s-pll-clock"
> +- reg : address and length of the I2S PLL register set.
> +- clocks: shall be the input parent clock phandle for the PLL.
> +- #clock-cells: from common clock binding; Should always be set to 0.
> +
> +Example:
> + pll_clock: pll_clock {
> + compatible = "fixed-clock";
> + clock-frequency = <2700>;
> + #clock-cells = <0>;
> + };
> +
> + i2s_clock@100a0 {
> + compatible = "snps,axs10x-i2s-pll-clock";
> + reg = <0x100a0 0x10>;
> + clocks = <&pll_clock>;
> + #clock-cells = <0>;
> + };
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 46869d6..2ca62dc6 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -84,3 +84,4 @@ obj-$(CONFIG_X86)   += x86/
>  obj-$(CONFIG_ARCH_ZX)+= zte/
>  obj-$(CONFIG_ARCH_ZYNQ)  += zynq/
>  obj-$(CONFIG_H8300)  += h8300/
> +obj-$(CONFIG_ARC_PLAT_AXS10X)+= axs10x/
> diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
> new file mode 100644
> index 000..01996b8
> --- /dev/null
> +++ b/drivers/clk/axs10x/Makefile
> @@ -0,0 +1 @@
> +obj-y += i2s_pll_clock.o
> diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
> b/drivers/clk/axs10x/i2s_pll_clock.c
> new file mode 100644
> index 000..411310d
> --- /dev/null
> +++ b/drivers/clk/axs10x/i2s_pll_clock.c
> @@ -0,0 +1,228 @@
> +/*
> + * Synopsys AXS10X SDP I2S PLL clock driver
> + *
> + * Copyright (C) 2016 Synopsys
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* PLL registers addresses */
> +#define PLL_IDIV_REG 0x0
> +#define PLL_FBDIV_REG0x4
> +#define PLL_ODIV0_REG0x8
> +#define PLL_ODIV1_REG0xC
> +
> +struct i2s_pll_cfg {
> + unsigned int rate;
> + unsigned i

[PATCH 2/2 v6] arc: axs10x: Add DT bindings for I2S PLL Clock

[Jose Abreu]

Add device tree bindings for AXS10X I2S PLL Clock driver.

Signed-off-by: Jose Abreu 
---

Changes v5 -> v6:
* Added 'clocks' field

This patch was only introduced in v5.

 arch/arc/boot/dts/axs10x_mb.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..5c6489e 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,7 +16,20 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
 
+   i2sclk: i2sclk@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   clocks = <&i2spll_clk>;
+   #clock-cells = <0>;
+   };
+
clocks {
+   i2spll_clk: i2spll_clk {
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+   #clock-cells = <0>;
+   };
+
i2cclk: i2cclk {
compatible = "fixed-clock";
clock-frequency = <5000>;
-- 
1.9.1

[PATCH 1/2 v6] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch has the goal of adding a clock driver
that programs this PLL.

At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.

Signed-off-by: Jose Abreu 
---

Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)

Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 228 +
 4 files changed, 255 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..5ffc8df
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,25 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- reg : address and length of the I2S PLL register set.
+- clocks: shall be the input parent clock phandle for the PLL.
+- #clock-cells: from common clock binding; Should always be set to 0.
+
+Example:
+   pll_clock: pll_clock {
+   compatible = "fixed-clock";
+   clock-frequency = <2700>;
+   #clock-cells = <0>;
+   };
+
+   i2s_clock@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   clocks = <&pll_clock>;
+   #clock-cells = <0>;
+   };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
 obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X)  += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..411310d
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,228 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG   0x0
+#define PLL_FBDIV_REG  0x4
+#define PLL_ODIV0_REG  0x8
+#define PLL_ODIV1_REG  0xC
+
+struct i2s_pll_cfg {
+   unsigned int rate;
+   unsigned int idiv;
+   unsigned int fbdiv;
+   unsigned int odiv0;
+   unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+   /* 27 Mhz */
+   { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+   { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+   { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+   { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+   { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+   { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+   { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+   { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+   { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+   /* 28.224 Mhz */
+   { 1024000, 0x82, 0x105, 0x107DF,

[PATCH 0/2 v6] Add AXS10X I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch series has the goal of adding a clock driver
that programs this PLL.



Changes v5 -> v6:
* Use parent clock to determine PLL input rate instead of using hardcoded values
* Documentation update (added 'clocks' field)
* Device tree update (added 'clocks' field)

Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)
* Added DT bindings

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

Jose Abreu (2):
  clk/axs10x: Add I2S PLL clock driver
  arc: axs10x: Add DT bindings for I2S PLL Clock

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  25 +++
 arch/arc/boot/dts/axs10x_mb.dtsi   |  13 ++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 228 +
 5 files changed, 268 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

-- 
1.9.1

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi Alexey,


On 21-04-2016 13:18, Alexey Brodkin wrote:
> Hi Jose,
>
> On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote:
>> Hi Alexey,
>
>>>>> Otherwise, I still prefer two DTS files for the two different FPGA
>>>>> versions. At the least, please use ioremap for any pointers that
>>>>> you readl/writel here.
>>>>>
>>>>> Beyond that, we should have a fixed rate source clk somewhere in
>>>>> the software view of the clk tree, because that reflects reality.
>>>>> Hardcoding the parent rate in the structure works, but doesn't
>>>>> properly express the clk tree.
>>>>>
>>>> Can I use a property in the DT to pass this reference clock? something 
>>>> like this:
>>>> snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
>>>> , fpga-version = 0 is default */
>>>>
>>>> Or use a parent clock? like:
>>>> clk {
>>>> compatible = "fixed-clock";
>>>> clock-frequency = <2700>;
>>>> #clock-cells = <0>;
>>>> snps,fpga-version = <0xFBED9>;
>>>> }
>>>>
>>>> It is important to distinguish between the different versions 
>>>> automatically, is
>>>> any of these solutions ok?
>>> I do like that solution with a master clock but with some fine-tuning
>>> for simplification.
>>>
>>> We'll add master clock node for I2S as a fixed clock like that:
>>> --->8--
>>> i2s_master_clock: clk {
>>> #clock-cells = <0>;
>>> compatible = "fixed-clock";
>>> clock-frequency = <2700>;
>>> };
>>> --->8--
>>>
>>> Note there's no mention of MB version, just a value of the frequency.
>>> And in the driver itself value of that master clock will be used for
>>> population of "pll_clk->ref_clk" directly.
>>>
>>> These are benefits we'll get with that approach:
>>>  [1] We escape any IOs not related to our clock device (I mean
>>>  "snps,i2s-pll-clock") itself.
>>>  [2] We'll use whatever reference clock value is given.
>>>  I.e. we'll be able to do a fix-up of that reference clock
>>>  value early in platform code depending on HW we're running on.
>>>  That's what people do here and there.
>>>  [3] Remember another clock driver for AXS10x board is right around
>>>  the corner. I mean the one for ARC PGU which uses exactly the same
>>>  master clock. So one fixup as mentioned above will work
>>>  at once for 2 clock drivers.
>>>
>>> Let me know if above makes sense.
>> That approach can't be used because the reference clock value will change in 
>> the
>> next firmware release.  The new release will have a reference clock of 
>> 28224000
>> Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
>> between them. Because of that we can't have only one master clock unless you
>> state to users that they have to change the reference clock value when using 
>> the
>> new firmware release. Stephen suggested to use two DT files (one for each
>> firmware release), but as Vineet said this would be annoying to the user so 
>> I am
>> trying to use another solution so that only one DT file is required.
> Ok reference clock will change.
> But I may guess we'll still be able to determine at least that new
> firmware version in run-time, right? If so we'll update a fix-up in
> early axs10x platform code so that reference clock will be set as 28224000 Hz.

Yes, there is a register where the FPGA version date is encoded, we can use that
to check which firmware is used (if date <= old_firmware_date then
clock=2700; else clock=28224000). If that fix is acceptable it could be a
good solution without having to use custom parameters in the DT (no need to
encode the different clocks and we would only use one master clock) but I am not
sure where and how this can be encoded and I don't know how to change the DT on
runtime. Can you give me some guidelines?

>
> And indeed 2 DT files is a no go - we want to run the same one binary
> (with built-in .dtb) on all flavors of AXS boards. And fix-up I'm talking 
> about
> will actually do transformation of .dtb early on kernel boot process so that 
> will
> be a complete equivalent of different DT files.

And doing modifications on the DT can cause some misdirections to users.
Besides, we would have clock specific functions in init procedures which is
precisely what we are trying to avoid by submitting this driver.

>
> -Alexey

Best regards,
Jose Miguel Abreu

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi Alexey,


On 20-04-2016 17:12, Alexey Brodkin wrote:
> Hi Jose, Stephen,
>
> On Wed, 2016-04-20 at 10:47 +0100, Jose Abreu wrote:
>> Hi Stephen,
>>
>>
>> On 20-04-2016 02:54, Stephen Boyd wrote:
>>> On 04/19, Jose Abreu wrote:
>>>> @Stephen: can you give some input so that I can submit a v6?
>>>>
>>> I don't prefer putting the second register in the same DT node,
>>> but that's really up to the DT reviewers to approve such a
>>> design. The current binding has been acked by Rob right?
>> Yes.
>>
>>> Assuming the new binding is acked/reviewed then that solution is
>>> fine.
>> Ok, will then use the DT to pass the FPGA version register.
> We won't need to know FPGA version at all I think.
> Read my comment below.
>
>>> Otherwise, I still prefer two DTS files for the two different FPGA
>>> versions. At the least, please use ioremap for any pointers that
>>> you readl/writel here.
>>>
>>> Beyond that, we should have a fixed rate source clk somewhere in
>>> the software view of the clk tree, because that reflects reality.
>>> Hardcoding the parent rate in the structure works, but doesn't
>>> properly express the clk tree.
>>>
>> Can I use a property in the DT to pass this reference clock? something like 
>> this:
>> snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
>> , fpga-version = 0 is default */
>>
>> Or use a parent clock? like:
>> clk {
>> compatible = "fixed-clock";
>> clock-frequency = <2700>;
>> #clock-cells = <0>;
>> snps,fpga-version = <0xFBED9>;
>> }
>>
>> It is important to distinguish between the different versions automatically, 
>> is
>> any of these solutions ok?
> I do like that solution with a master clock but with some fine-tuning
> for simplification.
>
> We'll add master clock node for I2S as a fixed clock like that:
> --->8--
>   i2s_master_clock: clk {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
>   clock-frequency = <2700>;
>   };
> --->8--
>
> Note there's no mention of MB version, just a value of the frequency.
> And in the driver itself value of that master clock will be used for
> population of "pll_clk->ref_clk" directly.
>
> These are benefits we'll get with that approach:
>  [1] We escape any IOs not related to our clock device (I mean
>  "snps,i2s-pll-clock") itself.
>  [2] We'll use whatever reference clock value is given.
>  I.e. we'll be able to do a fix-up of that reference clock
>  value early in platform code depending on HW we're running on.
>  That's what people do here and there.
>  [3] Remember another clock driver for AXS10x board is right around
>  the corner. I mean the one for ARC PGU which uses exactly the same
>  master clock. So one fixup as mentioned above will work
>  at once for 2 clock drivers.
>
> Let me know if above makes sense.

That approach can't be used because the reference clock value will change in the
next firmware release.  The new release will have a reference clock of 28224000
Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
between them. Because of that we can't have only one master clock unless you
state to users that they have to change the reference clock value when using the
new firmware release. Stephen suggested to use two DT files (one for each
firmware release), but as Vineet said this would be annoying to the user so I am
trying to use another solution so that only one DT file is required.

>
> -Alexey

Best regards,
Jose Miguel Abreu

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi Stephen,


On 20-04-2016 02:54, Stephen Boyd wrote:
> On 04/19, Jose Abreu wrote:
>> @Stephen: can you give some input so that I can submit a v6?
>>
> I don't prefer putting the second register in the same DT node,
> but that's really up to the DT reviewers to approve such a
> design. The current binding has been acked by Rob right?

Yes.

> Assuming the new binding is acked/reviewed then that solution is
> fine.

Ok, will then use the DT to pass the FPGA version register.

> Otherwise, I still prefer two DTS files for the two different FPGA
> versions. At the least, please use ioremap for any pointers that
> you readl/writel here.
>
> Beyond that, we should have a fixed rate source clk somewhere in
> the software view of the clk tree, because that reflects reality.
> Hardcoding the parent rate in the structure works, but doesn't
> properly express the clk tree.
>

Can I use a property in the DT to pass this reference clock? something like 
this:
snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
, fpga-version = 0 is default */

Or use a parent clock? like:
clk {
compatible = "fixed-clock";
clock-frequency = <2700>;
#clock-cells = <0>;
snps,fpga-version = <0xFBED9>;
}

It is important to distinguish between the different versions automatically, is
any of these solutions ok?

Best regards,
Jose Miguel Abreu

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi Vineet,


On 18-04-2016 12:49, Vineet Gupta wrote:
> On Monday 18 April 2016 04:00 PM, Jose Abreu wrote:
>>>> +  if (readl((void *)FPGA_VER_INFO) <= FPGA_VER_27M) {
>>>> Please don't readl directly from addresses. I think I mentioned
>>>> that before and didn't get back to you when you replied asking
>>>> for other solutions. I still think a proper DT is in order
>>>> instead of doing this check for ref_clk.
>> I think that the DT approach would be better but I also think that using two 
>> DT
>> files with only one change between them is not viable. I can see some 
>> alternatives:
>> 1) Pass the region of FPGA version in reg field of DT so that writel is 
>> not
>> directly used;
>> 2) Create a dummy parent clock driver that reads from FPGA version 
>> register
>> and returns the rate;
>> 3) Last resort: Use two DT files for each FPGA version.
>>
>> @Vineet, @Alexey: Can you give some suggestions?
>>
>> Some background:
>> We are expecting a new firmware release for the AXS board that will change 
>> the
>> reference clock value of the I2S PLL from 27MHz to 28.224MHz. Due to this 
>> change
>> the dividers of this PLL will change. Right now I am directly reading from 
>> the
>> FPGA version register but Stephen suggested to use a DT approach so that this
>> rate is declared as parent clock. This would be a good solution but would
>> require the usage of two different DT files (one for the current firmware and
>> another for the new firmware), which I think is not ideal. What is your 
>> opinion?
>> Some other solutions are listed above.
> Consider this my ignorance of clk drivers, what exactly is the problem with 
> that
> readl() for FPGA ver. Having 2 versions of DT is annoyance for sure, but the
> bigger headache is that it still won't help cases of users mixing and matching
> boards and DT. IMO this runtime check is pretty nice and will support both 
> types
> of boards with exact same code/DT !
>
> FWIW, both solutions #1 and #3 seem to imply a different DT - no ?

Solution 1 only requires that the FPGA version register is declared in the DT,
something like this:
i2s_clock@100a0 {
compatible = "snps,axs10x-i2s-pll-clock";
reg = <0x100a0 0x10 0x11230 0x04>;
#clock-cells = <0>;
};

And then the region is io-remapped. This solution would discard the direct readl
from the address and would still be compatible with the different firmwares
using the same DT.

Solution 3 is the alternative that Stephen suggested which requires two
different DT's.

>
> And I really don't see how #2 makes things more elegant/abstracted w.r.t clk
> framework ?

Yes, solution 2 is more of a workaround and is not the best by far.

>
> So I prefer what you had before.
> -Vineet

@Stephen: can you give some input so that I can submit a v6?

Best regards,
Jose Miguel Abreu

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

Hi Stephen,


On 16-04-2016 00:46, Stephen Boyd wrote:
> On 04/11, Jose Abreu wrote:
>> new file mode 100644
>> index 000..3ba4e2f
>> --- /dev/null
>> +++ b/drivers/clk/axs10x/i2s_pll_clock.c
>> @@ -0,0 +1,217 @@
>> +
>> +static int i2s_pll_clk_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct device_node *node = dev->of_node;
>> +const char *clk_name;
>> +struct clk *clk;
>> +struct i2s_pll_clk *pll_clk;
>> +struct clk_init_data init;
>> +struct resource *mem;
>> +
>> +if (!node)
>> +return -ENODEV;
> Does this ever happen? Looks like dead code.

Will remove.

>> +
>> +pll_clk = devm_kzalloc(dev, sizeof(*pll_clk), GFP_KERNEL);
>> +if (!pll_clk)
>> +return -ENOMEM;
>> +
>> +mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +pll_clk->base = devm_ioremap_resource(dev, mem);
>> +if (IS_ERR(pll_clk->base))
>> +return PTR_ERR(pll_clk->base);
>> +
>> +clk_name = node->name;
>> +init.name = clk_name;
>> +init.ops = &i2s_pll_ops;
>> +init.num_parents = 0;
>> +pll_clk->hw.init = &init;
>> +
>> +clk = clk_register(NULL, &pll_clk->hw);
> Pass dev as first argument. Also use devm_clk_register() instead.

Ok.

>> +if (IS_ERR(clk)) {
>> +dev_err(dev, "failed to register %s div clock (%ld)\n",
>> +clk_name, PTR_ERR(clk));
>> +return PTR_ERR(clk);
>> +}
>> +
>> +if (readl((void *)FPGA_VER_INFO) <= FPGA_VER_27M) {
> Please don't readl directly from addresses. I think I mentioned
> that before and didn't get back to you when you replied asking
> for other solutions. I still think a proper DT is in order
> instead of doing this check for ref_clk.

I think that the DT approach would be better but I also think that using two DT
files with only one change between them is not viable. I can see some 
alternatives:
1) Pass the region of FPGA version in reg field of DT so that writel is not
directly used;
2) Create a dummy parent clock driver that reads from FPGA version register
and returns the rate;
3) Last resort: Use two DT files for each FPGA version.

@Vineet, @Alexey: Can you give some suggestions?

Some background:
We are expecting a new firmware release for the AXS board that will change the
reference clock value of the I2S PLL from 27MHz to 28.224MHz. Due to this change
the dividers of this PLL will change. Right now I am directly reading from the
FPGA version register but Stephen suggested to use a DT approach so that this
rate is declared as parent clock. This would be a good solution but would
require the usage of two different DT files (one for the current firmware and
another for the new firmware), which I think is not ideal. What is your opinion?
Some other solutions are listed above.

>> +pll_clk->ref_clk = 2700;
>> +pll_clk->pll_cfg = i2s_pll_cfg_27m;
>> +} else {
>> +pll_clk->ref_clk = 28224000;
>> +pll_clk->pll_cfg = i2s_pll_cfg_28m;
>> +}
> We should do this before registering the clk with the framework.

Ok.

>> +
>> +return of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +}
>> +
>> +static int i2s_pll_clk_remove(struct platform_device *pdev)
>> +{
>> +of_clk_del_provider(pdev->dev.of_node);
>> +return 0;
>> +}
>> +
>> +static const struct of_device_id i2s_pll_clk_id[] = {
>> +{ .compatible = "snps,i2s-pll-clock", },
>> +{ },
>> +};
>> +MODULE_DEVICE_TABLE(of, i2s_pll_clk_id);
>> +
>> +static struct platform_driver i2s_pll_clk_driver = {
>> +.driver = {
>> +.name = "i2s-pll-clock",
>> +.of_match_table = of_match_ptr(i2s_pll_clk_id),
> You can drop of_match_ptr(), it doesn't have much use besides
> introducing compilation warnings.

Ok.

>> +},
>> +.probe = i2s_pll_clk_probe,
>> +.remove = i2s_pll_clk_remove,
>> +};
>> +module_platform_driver(i2s_pll_clk_driver);
>>

Best regards,
Jose Miguel Abreu

[PATCH 1/2 v5] ASoC: dwc: Add custom PCM driver

[Jose Abreu]

HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.

The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

The selection between the use of DMA engine or PIO mode
is detected by declaring or not the DMA parameters in
the device tree.

Signed-off-by: Jose Abreu 
---

Changes v4 -> v5:
* Resolve undefined references when compiling as module
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  71 +
 sound/soc/dwc/designware_i2s.c |  94 -
 sound/soc/dwc/designware_pcm.c | 230 +
 5 files changed, 378 insertions(+), 27 deletions(-)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..2a21120 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   tristate "Synopsys I2S PCM Driver"
+   help
+Say Y or M if you want to add support for ALSA ASoC platform driver
+using I2S.
+
+Select this option if you want to be able to create a sound interface
+using the I2S device driver as CPU driver. Instead of using ALSA
+DMA engine by selecting this driver a custom PCM driver will be used.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
 obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
 
diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
new file mode 100644
index 000..f702ed1
--- /dev/null
+++ b/sound/soc/dwc/designware.h
@@ -0,0 +1,71 @@
+/*
+ * ALSA SoC Synopsys Audio Layer
+ *
+ * sound/soc/dwc/designware.h
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DESIGNWARE_H
+#define __DESIGNWARE_H
+
+#include 
+#include 
+#include 
+#include 
+
+struct dw_pcm_binfo {
+   struct snd_pcm_substream *stream;
+   unsigned char *dma_base;
+   unsigned char *dma_pointer;
+   unsigned int period_size_frames;
+   unsigned int size;
+   snd_pcm_uframes_t period_pointer;
+   unsigned int total_periods;
+   unsigned int current_period;
+};
+
+union dw_i2s_snd_dma_data {
+   struct i2s_dma_data pd;
+   struct snd_dmaengine_dai_dma_data dt;
+};
+
+struct dw_i2s_dev {
+   void __iomem *i2s_base;
+   struct clk *clk;
+   int active;
+   unsigned int capability;
+   unsigned int quirks;
+   unsigned int i2s_reg_comp1;
+   unsigned int i2s_reg_comp2;
+   struct device *dev;
+   u32 ccr;
+   u32 xfer_resolution;
+   u32 fifo_th;
+
+   /* data related to DMA transfers b/w i2s and DMAC */
+   bool use_dmaengine;
+   union dw_i2s_snd_dma_data play_dma_data;
+   union dw_i2s_snd_dma_data capture_dma_data;
+   struct i2s_clk_config_data config;
+   int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+   struct dw_pcm_binfo binfo;
+};
+
+#if defined(CONFIG_SND_DESIGNWARE_PCM) || \
+   defined(CONFIG_SND_DESIGNWARE_PCM_MODULE)
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi);
+#else
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi)
+{
+   return 0;
+}
+#endif
+
+#endif
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..3040a14 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include "designware.h"
 
 /* common register for all channel */
 #define IER0x000
@@ -84,31 +85,6 @@
 #define MAX_CHANNEL_NUM8
 #define

[PATCH 2/2 v5] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

This patch updates documentation for the Designware I2S
driver.

Signed-off-by: Jose Abreu 
---

Changes v4 -> v5:
* interrupts is now required property
* Drop 'snps-use-dmaengine' property

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..9c1fecd 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -3,14 +3,18 @@ DesignWare I2S controller
 Required properties:
  - compatible : Must be "snps,designware-i2s"
  - reg : Must contain the I2S core's registers location and length
+ - interrupts:  where IRQ is the interrupt number.
  - clocks : Pairs of phandle and specifier referencing the controller's
clocks. The controller expects one clock: the clock used as the sampling
rate reference clock sample.
  - clock-names : "i2sclk" for the sample rate reference clock.
+
+Optional properties:
  - dmas: Pairs of phandle and specifier for the DMA channels that are used by
the core. The core expects one or two dma channels: one for transmit and
-   one for receive.
- - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
+   one for receive. Set this parameter if the I2S DMA block is enabled.
+ - dma-names : "tx" for the transmit channel, "rx" for the receive channel. Set
+   this parameter if the I2S DMA block is enabled.
 
 For more details on the 'dma', 'dma-names', 'clock' and 'clock-names'
 properties please check:
@@ -23,6 +27,7 @@ Example:
soc_i2s: i2s@7ff9 {
compatible = "snps,designware-i2s";
reg = <0x0 0x7ff9 0x0 0x1000>;
+   interrupts = <15>;
clocks = <&scpi_i2sclk 0>;
clock-names = "i2sclk";
#sound-dai-cells = <0>;
-- 
1.9.1

[PATCH 0/2 v5] Add I2S/ADV7511 audio support for ARC AXS10x boards

[Jose Abreu]

Hi all,

This is v5 of these patches. In this version I dropped the ADV7511 audio patch
because, quoting Lars-Peter Clausen:
"The reason why this driver is still out of tree, is because there has been no
conclusion yet on how to go forward with the whole HDMI integration. So this
is not going to get merged until that issue has been addressed."

So, until that issue is addressed I will not send any ADV7511 audio related
patches but if for some reason anyone wants to merge it I can send the
pathes again. V4, which includes the ADV7511 audio patches is available at:

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-April/106650.html

Looking forward to your comments!

Best regards,
Jose Miguel Abreu

-

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds I2S audio for the AXS10x platform.

Changes v4 -> v5
* Resolve undefined references when compiling as module
* Dropped adv7511 audio patches
* Use DMA properties in I2S to check which mode to use: PIO or DMA (as 
suggested by Lars-Peter Clausen)

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


NOTE:
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

Jose Abreu (2):
  ASoC: dwc: Add custom PCM driver
  ASoC: dwc: Update DOCUMENTATION for I2S Driver

 .../devicetree/bindings/sound/designware-i2s.txt   |   9 +-
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  71 +++
 sound/soc/dwc/designware_i2s.c |  94 ++---
 sound/soc/dwc/designware_pcm.c | 230 +
 6 files changed, 385 insertions(+), 29 deletions(-)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

-- 
1.9.1

[PATCH 1/2 v5] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch has the goal of adding a clock driver
that programs this PLL.

At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.

Signed-off-by: Jose Abreu 
---

Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  17 ++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 217 +
 4 files changed, 236 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

diff --git a/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
new file mode 100644
index 000..6879e81
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
@@ -0,0 +1,17 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,axs10x-i2s-pll-clock"
+- #clock-cells: from common clock binding; Should always be set to 0.
+- reg : Address and length of the I2S PLL register set.
+
+Example:
+   i2s_clock@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   #clock-cells = <0>;
+   };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
 obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X)  += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..1267b5b
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,217 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* FPGA Version Info */
+#define FPGA_VER_INFO  0xE0011230
+#define FPGA_VER_27M   0x000FBED9
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG   0x0
+#define PLL_FBDIV_REG  0x4
+#define PLL_ODIV0_REG  0x8
+#define PLL_ODIV1_REG  0xC
+
+struct i2s_pll_cfg {
+   unsigned int rate;
+   unsigned int idiv;
+   unsigned int fbdiv;
+   unsigned int odiv0;
+   unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+   /* 27 Mhz */
+   { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+   { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+   { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+   { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+   { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+   { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+   { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+   { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+   { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+   /* 28.224 Mhz */
+   { 1024000, 0x82, 0x105, 0x107DF, 0x2000 },
+   { 1411200, 0x28A, 0x1, 0x10001, 0x2000 },
+   { 1536000, 0xA28, 0x187, 0x10042, 0x2000 },
+   { 2048000, 0x41, 0x105, 0x107DF, 0x2000 },
+   { 2822400, 0x145, 0x1, 0x10001, 0x2000 },
+   { 3072000, 0x514, 0x187, 0x10042, 0x2000 },
+   { 2116800, 0x514, 0x42, 0x10001, 0x2000 },
+   { 2304000, 0x619, 0x82, 0x10001, 0x2000 },
+  

[PATCH 0/2 v5] Add AXS10X I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch series has the goal of adding a clock driver
that programs this PLL.



Changes v4 -> v5:
* Documentation update (as suggested by Alexey Brodkin)
* Changed compatible string to "snps,axs10x-i2s-pll-clock" (as suggested by 
Alexey Brodkin)
* Added DT bindings

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

Jose Abreu (2):
  clk/axs10x: Add I2S PLL clock driver
  arc: axs10x: Add DT bindings for I2S PLL Clock

 .../bindings/clock/axs10x-i2s-pll-clock.txt|  17 ++
 arch/arc/boot/dts/axs10x_mb.dtsi   |   6 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 217 +
 5 files changed, 242 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

-- 
1.9.1

[PATCH 2/2 v5] arc: axs10x: Add DT bindings for I2S PLL Clock

[Jose Abreu]

Add device tree bindings for AXS10X I2S PLL Clock driver.

Signed-off-by: Jose Abreu 
---

This patch was only introduced in v5.

 arch/arc/boot/dts/axs10x_mb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index ab5d570..227b215 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -16,6 +16,12 @@
ranges = <0x 0xe000 0x1000>;
interrupt-parent = <&mb_intc>;
 
+   i2sclk: i2sclk@100a0 {
+   compatible = "snps,axs10x-i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   #clock-cells = <0>;
+   };
+
clocks {
i2cclk: i2cclk {
compatible = "fixed-clock";
-- 
1.9.1

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Lars,


On 11-04-2016 13:23, Lars-Peter Clausen wrote:
> On 04/11/2016 01:32 PM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 11-04-2016 10:33, Lars-Peter Clausen wrote:
>>> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>>>> Hi Lars,
>>>>
>>>>
>>>> On 09-04-2016 16:02, Lars-Peter Clausen wrote:
>>>>> On 04/08/2016 06:12 PM, Jose Abreu wrote:
>>>>> [...]
>>>>>>> [...]
>>>>>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec 
>>>>>>>> interface
>>>>>>>> +  into ALSA SoC.
>>>>>>> This is not a description of the hardware.
>>>>>> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
>>>>>> transmitter routes audio signals" ?
>>>>> I don't think we need this property. There is no problem with registering
>>>>> the audio part unconditionally. As long as there is no connection we wont
>>>>> create a sound card that is exposed to userspace.
>>>>>
>>>> This change was suggested by Laurent Pinchart and was introduced in v3. 
>>>> Quoting
>>>> Laurent:
>>>> "The idea is that enabling support for ADV7511 audio in the kernel isn't 
>>>> coupled
>>>> with whether the system includes audio support. It would be confusing, and 
>>>> would
>>>> also waste resources, to create a Linux sound device when no sound channel 
>>>> is
>>>> routed on the board."
>>> I wouldn't care too much about this at this point, the extra amount of
>>> resources required for registering the CODEC (but not the sound card) is
>>> just a few bytes (sizeof(struct snd_soc_codec)).
>>>
>>> Nevertheless what we should do is describe the hardware and from this
>>> information infer whether there is a audio connection or not and if there is
>>> none we might skip registering the CODEC. In my opinion this hardware
>>> description should be modeled using of-graph, having a connection between
>>> the SoC side and the adv7511 SPDIF or I2S port.
>>>
>> You mean something like this:
>>
>> sound_playback: sound_playback {
>> compatible = "simple-audio-card";
>> [...]
>> simple-audio-card,format = "i2s";
>> [...]
>> }
>>
>> adv7511@xx {
>> compatible = "adi,adv7511";
>> [...]
>>
>> ports {
>> [...]
>> /* Audio Output */
>> port@x {
>> reg = ;
>> endpoint {
>> remote-endpoint = <&sound_playback>;
>> }
>> }
>> }
>> }
> Yes, something like that. Not exactly like that, but similar. One of the
> core concepts of of-graph is that there is always a description of the
> connection from both sides, this way each side can independently figure out
> where it is connected.
>
> Currently there is also zero support of of-graph in ASoC, so a bit of work
> is required to get this integrated properly.
>

I also believe this would be the better option but in the meantime can't I
integrate the audio like it is being done in the dw-hdmi driver[1]? In this
driver the audio is registered as a sound card and is conditionally built using
Kconfig, just like I was doing in the previous versions. I know you said the
HDMI audio is still an open issue but it seems that for this case it was 
accepted.

[1] 
http://lxr.free-electrons.com/source/drivers/gpu/drm/bridge/dw-hdmi-ahb-audio.c

Best regards,
Jose Miguel Abreu

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Lars,


On 11-04-2016 10:33, Lars-Peter Clausen wrote:
> On 04/11/2016 11:27 AM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 09-04-2016 16:02, Lars-Peter Clausen wrote:
>>> On 04/08/2016 06:12 PM, Jose Abreu wrote:
>>> [...]
>>>>> [...]
>>>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec 
>>>>>> interface
>>>>>> +  into ALSA SoC.
>>>>> This is not a description of the hardware.
>>>> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
>>>> transmitter routes audio signals" ?
>>> I don't think we need this property. There is no problem with registering
>>> the audio part unconditionally. As long as there is no connection we wont
>>> create a sound card that is exposed to userspace.
>>>
>> This change was suggested by Laurent Pinchart and was introduced in v3. 
>> Quoting
>> Laurent:
>> "The idea is that enabling support for ADV7511 audio in the kernel isn't 
>> coupled
>> with whether the system includes audio support. It would be confusing, and 
>> would
>> also waste resources, to create a Linux sound device when no sound channel is
>> routed on the board."
> I wouldn't care too much about this at this point, the extra amount of
> resources required for registering the CODEC (but not the sound card) is
> just a few bytes (sizeof(struct snd_soc_codec)).
>
> Nevertheless what we should do is describe the hardware and from this
> information infer whether there is a audio connection or not and if there is
> none we might skip registering the CODEC. In my opinion this hardware
> description should be modeled using of-graph, having a connection between
> the SoC side and the adv7511 SPDIF or I2S port.
>

You mean something like this:

sound_playback: sound_playback {
compatible = "simple-audio-card";
[...]
simple-audio-card,format = "i2s";
[...]
}

adv7511@xx {
compatible = "adi,adv7511";
[...]

ports {
[...]
/* Audio Output */
port@x {
reg = ;
endpoint {
remote-endpoint = <&sound_playback>;
}
}
}
}

?

Best regards,
Jose Miguel Abreu

[RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Jose Abreu]

The ARC SDP I2S clock can be programmed using a
specific PLL.

This patch has the goal of adding a clock driver
that programs this PLL.

At this moment the rate values are hardcoded in
a table but in the future it would be ideal to
use a function which determines the PLL values
given the desired rate.

Signed-off-by: Jose Abreu 
---

Changes v3 -> v4:
* Added binding document (as suggested by Stephen Boyd)
* Minor code style fixes (as suggested by Stephen Boyd)
* Use ioremap (as suggested by Stephen Boyd)
* Implement round_rate (as suggested by Stephen Boyd)
* Change to platform driver (as suggested by Stephen Boyd)
* Use {readl/writel}_relaxed (as suggested by Vineet Gupta)

Changes v2 -> v3:
* Implemented recalc_rate

Changes v1 -> v2:
* Renamed folder to axs10x (as suggested by Alexey Brodkin)
* Added more supported rates

 .../devicetree/bindings/clock/i2s-pll-clock.txt|  17 ++
 drivers/clk/Makefile   |   1 +
 drivers/clk/axs10x/Makefile|   1 +
 drivers/clk/axs10x/i2s_pll_clock.c | 217 +
 4 files changed, 236 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
 create mode 100644 drivers/clk/axs10x/Makefile
 create mode 100644 drivers/clk/axs10x/i2s_pll_clock.c

diff --git a/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt 
b/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
new file mode 100644
index 000..ff86a41
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/i2s-pll-clock.txt
@@ -0,0 +1,17 @@
+Binding for the AXS10X I2S PLL clock
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be "snps,i2s-pll-clock"
+- #clock-cells: from common clock binding; Should always be set to 0.
+- reg : Address and length of the I2S PLL register set.
+
+Example:
+   clock@0x100a0 {
+   compatible = "snps,i2s-pll-clock";
+   reg = <0x100a0 0x10>;
+   #clock-cells = <0>;
+   };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 46869d6..2ca62dc6 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,3 +84,4 @@ obj-$(CONFIG_X86) += x86/
 obj-$(CONFIG_ARCH_ZX)  += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
 obj-$(CONFIG_H8300)+= h8300/
+obj-$(CONFIG_ARC_PLAT_AXS10X)  += axs10x/
diff --git a/drivers/clk/axs10x/Makefile b/drivers/clk/axs10x/Makefile
new file mode 100644
index 000..01996b8
--- /dev/null
+++ b/drivers/clk/axs10x/Makefile
@@ -0,0 +1 @@
+obj-y += i2s_pll_clock.o
diff --git a/drivers/clk/axs10x/i2s_pll_clock.c 
b/drivers/clk/axs10x/i2s_pll_clock.c
new file mode 100644
index 000..3ba4e2f
--- /dev/null
+++ b/drivers/clk/axs10x/i2s_pll_clock.c
@@ -0,0 +1,217 @@
+/*
+ * Synopsys AXS10X SDP I2S PLL clock driver
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* FPGA Version Info */
+#define FPGA_VER_INFO  0xE0011230
+#define FPGA_VER_27M   0x000FBED9
+
+/* PLL registers addresses */
+#define PLL_IDIV_REG   0x0
+#define PLL_FBDIV_REG  0x4
+#define PLL_ODIV0_REG  0x8
+#define PLL_ODIV1_REG  0xC
+
+struct i2s_pll_cfg {
+   unsigned int rate;
+   unsigned int idiv;
+   unsigned int fbdiv;
+   unsigned int odiv0;
+   unsigned int odiv1;
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_27m[] = {
+   /* 27 Mhz */
+   { 1024000, 0x104, 0x451, 0x10E38, 0x2000 },
+   { 1411200, 0x104, 0x596, 0x10D35, 0x2000 },
+   { 1536000, 0x208, 0xA28, 0x10B2C, 0x2000 },
+   { 2048000, 0x82, 0x451, 0x10E38, 0x2000 },
+   { 2822400, 0x82, 0x596, 0x10D35, 0x2000 },
+   { 3072000, 0x104, 0xA28, 0x10B2C, 0x2000 },
+   { 2116800, 0x82, 0x3CF, 0x10C30, 0x2000 },
+   { 2304000, 0x104, 0x79E, 0x10B2C, 0x2000 },
+   { 0, 0, 0, 0, 0 },
+};
+
+static const struct i2s_pll_cfg i2s_pll_cfg_28m[] = {
+   /* 28.224 Mhz */
+   { 1024000, 0x82, 0x105, 0x107DF, 0x2000 },
+   { 1411200, 0x28A, 0x1, 0x10001, 0x2000 },
+   { 1536000, 0xA28, 0x187, 0x10042, 0x2000 },
+   { 2048000, 0x41, 0x105, 0x107DF, 0x2000 },
+   { 2822400, 0x145, 0x1, 0x10001, 0x2000 },
+   { 3072000, 0x514, 0x187, 0x10042, 0x2000 },
+   { 2116800, 0x514, 0x42, 0x10001, 0x2000 },
+   { 2304000, 0x619, 0x82, 0x10001, 0x2000 },
+   { 0, 0, 0, 0, 0 },
+};
+
+struct i2s_pll_clk {
+   void __iomem *base;
+   struct clk_hw hw;
+   unsigned int ref_clk;
+   const struct i2s_pll_cfg *pll_cfg;
+};
+
+static inline void i2s_

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Lars,


On 09-04-2016 16:02, Lars-Peter Clausen wrote:
> On 04/08/2016 06:12 PM, Jose Abreu wrote:
> [...]
>>> [...]
>>>> +- adi,enable-audio: If set the ADV7511 driver will register a codec 
>>>> interface
>>>> +  into ALSA SoC.
>>> This is not a description of the hardware.
>> Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
>> transmitter routes audio signals" ?
> I don't think we need this property. There is no problem with registering
> the audio part unconditionally. As long as there is no connection we wont
> create a sound card that is exposed to userspace.
>

This change was suggested by Laurent Pinchart and was introduced in v3. Quoting
Laurent:
"The idea is that enabling support for ADV7511 audio in the kernel isn't coupled
with whether the system includes audio support. It would be confusing, and would
also waste resources, to create a Linux sound device when no sound channel is
routed on the board."

Should I revert this?

Best regards,
Jose Miguel Abreu

Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

Hi Lars,


On 09-04-2016 15:55, Lars-Peter Clausen wrote:
> On 04/08/2016 06:08 PM, Jose Abreu wrote:
>> Hi Lars,
>>
>>
>> On 08-04-2016 16:52, Lars-Peter Clausen wrote:
>>> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>>>> Hi Mark,
>>>>
>>>>
>>>> On 07-04-2016 18:53, Mark Brown wrote:
>>>>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>>>>>
>>>>>> + Optional properties:
>>>>>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If 
>>>>>> set
>>>>>> +   it is required to use the properties 'dmas' and 'dma-names'.
>>>>> This is not a good interface, it's describing Linux internal APIs.  If
>>>>> the device needs to operate in PIO mode it should just do that.
>>>> I added this interface because there is no direct way to check if DMA is
>>>> available on the I2S controller so it is not possible to automatically 
>>>> change
>>>> between DMA and PIO mode. As the I2S controller can be built with or 
>>>> without DMA
>>>> support it is necessary to somehow check if DMA is enabled or not and 
>>>> according
>>>> to that use either ALSA DMA engine or the custom platform driver sent in 
>>>> these
>>>> patches. I did not want to remove drivers functionality so I added this 
>>>> property
>>>> to the DT. This way a user can select between DMA and PIO mode.
>>> That's OK, but you need to describe the hardware, not the indented behavior
>>> of the software driver.
>>>
>> Is this okay: "snps,use-dmaengine: Set this boolean paramater if I2S 
>> controller
>> has DMA support. If set the properties 'dmas' and 'dma-names' must be also 
>> set" ?
> The description is better. But the name of the property is still imperative
> rather then descriptive. It tells the software what should be done rather
> then describing what the hardware looks like.
>
> Since there is already the dmas property which is present if a DMA is
> connected and is absent when no DMA is present it should be enough to just
> check that property rather than requiring an additional one.

Ok, will then use the DMA property to decide which mode to use: PIO or DMA.

>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Best regards,
Jose Miguel Abreu

Re: [alsa-devel] [PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Lars,


On 08-04-2016 16:46, Lars-Peter Clausen wrote:
> On 04/07/2016 06:53 PM, Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
>> commit 1770c4a1e32b ("Merge remote-tracking branch
>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>  - https://github.com/analogdevicesinc/linux/
> The reason why this driver is still out of tree, is because there has been
> no conclusion yet on how to go forward with the whole HDMI integration. So
> this is not going to get merged until that issue has been addressed.

Ok, will then drop the patches related with adv7511 but will update with your
comments so that when this HDMI issue is addressed I can send again the patches.
Is this okay?

>
> [...]
>> +- adi,enable-audio: If set the ADV7511 driver will register a codec 
>> interface
>> +  into ALSA SoC.
> This is not a description of the hardware.

Is this okay: "adi,enable-audio: Set this boolean parameter if ADV7511
transmitter routes audio signals" ?

>
> [...]
>> diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
>> index 964b7de..539c091 100644
>> --- a/include/sound/soc-dai.h
>> +++ b/include/sound/soc-dai.h
>> @@ -33,6 +33,7 @@ struct snd_compr_stream;
>>  #define SND_SOC_DAIFMT_DSP_B5 /* L data MSB during FRM LRC 
>> */
>>  #define SND_SOC_DAIFMT_AC97 6 /* AC97 */
>>  #define SND_SOC_DAIFMT_PDM  7 /* Pulse density modulation */
>> +#define SND_SOC_DAIFMT_SPDIF8 /* SPDIF */
> This needs to be a separate patch.

Ok.

>
>
> ___
> linux-snps-arc mailing list
> linux-snps-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Best regards,
Jose Miguel Abreu

Re: [alsa-devel] [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

Hi Lars,


On 08-04-2016 16:52, Lars-Peter Clausen wrote:
> On 04/08/2016 12:06 PM, Jose Abreu wrote:
>> Hi Mark,
>>
>>
>> On 07-04-2016 18:53, Mark Brown wrote:
>>> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>>>
>>>> + Optional properties:
>>>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
>>>> +   it is required to use the properties 'dmas' and 'dma-names'.
>>> This is not a good interface, it's describing Linux internal APIs.  If
>>> the device needs to operate in PIO mode it should just do that.
>> I added this interface because there is no direct way to check if DMA is
>> available on the I2S controller so it is not possible to automatically change
>> between DMA and PIO mode. As the I2S controller can be built with or without 
>> DMA
>> support it is necessary to somehow check if DMA is enabled or not and 
>> according
>> to that use either ALSA DMA engine or the custom platform driver sent in 
>> these
>> patches. I did not want to remove drivers functionality so I added this 
>> property
>> to the DT. This way a user can select between DMA and PIO mode.
> That's OK, but you need to describe the hardware, not the indented behavior
> of the software driver.
>

Is this okay: "snps,use-dmaengine: Set this boolean paramater if I2S controller
has DMA support. If set the properties 'dmas' and 'dma-names' must be also set" 
?

Best regards,
Jose Miguel Abreu

Re: [PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

Hi Mark,


On 07-04-2016 18:53, Mark Brown wrote:
> On Thu, Apr 07, 2016 at 05:53:59PM +0100, Jose Abreu wrote:
>
>> + Optional properties:
>> + - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
>> +   it is required to use the properties 'dmas' and 'dma-names'.
> This is not a good interface, it's describing Linux internal APIs.  If
> the device needs to operate in PIO mode it should just do that.

I added this interface because there is no direct way to check if DMA is
available on the I2S controller so it is not possible to automatically change
between DMA and PIO mode. As the I2S controller can be built with or without DMA
support it is necessary to somehow check if DMA is enabled or not and according
to that use either ALSA DMA engine or the custom platform driver sent in these
patches. I did not want to remove drivers functionality so I added this property
to the DT. This way a user can select between DMA and PIO mode.

Is there a better option to do this without removing the possibility of using
ALSA DMA engine in the driver?

Best regards,
Jose Miguel Abreu

[PATCH 2/5 v4] drm/i2c/adv7511: Add audio support

[Jose Abreu]

This patch adds audio support for the ADV7511 HDMI transmitter
using ALSA SoC.

The code was ported from Analog Devices linux tree from
commit 1770c4a1e32b ("Merge remote-tracking branch
'xilinx/master' into xcomm_zynq"), which is available at:
- https://github.com/analogdevicesinc/linux/

The audio can be disabled using menu-config and/or device tree
so it is possible to use only video mode. The audio
(when enabled) registers as a codec into ALSA.

SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.

Signed-off-by: Jose Abreu 
---

No changes v3 -> v4.

Changes v2 -> v3:
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)

No changes v1 -> v2.

 .../bindings/display/bridge/adi,adv7511.txt|   3 +
 drivers/gpu/drm/i2c/adv7511/Kconfig|  12 +
 drivers/gpu/drm/i2c/adv7511/Makefile   |   1 +
 drivers/gpu/drm/i2c/adv7511/adv7511.h  |  22 ++
 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
 drivers/gpu/drm/i2c/adv7511/adv7511_core.c |  11 +
 include/sound/soc-dai.h|   1 +
 7 files changed, 360 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 96c25ee..920e542 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -43,6 +43,9 @@ Optional properties:
   data stream (similar to BT.656). Defaults to separate H/V synchronization
   signals.
 
+- adi,enable-audio: If set the ADV7511 driver will register a codec interface
+  into ALSA SoC.
+
 Required nodes:
 
 The ADV7511 has two video ports. Their connections are modelled using the OF
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig 
b/drivers/gpu/drm/i2c/adv7511/Kconfig
index 302c8e34..900f3e9 100644
--- a/drivers/gpu/drm/i2c/adv7511/Kconfig
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -4,3 +4,15 @@ config DRM_I2C_ADV7511
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
 
+config DRM_I2C_ADV7511_AUDIO
+   bool "ADV7511 audio"
+   depends on DRM_I2C_ADV7511
+   depends on SND_SOC=y || (SND_SOC && DRM_I2C_ADV7511=m)
+   default y
+   help
+ This adds support for audio on the ADV7511(W) and ADV7513 HDMI
+ encoders.
+
+ By selecting this option the ADV7511 will register a codec interface
+ into ALSA.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile 
b/drivers/gpu/drm/i2c/adv7511/Makefile
index c13f5a1..d68773a 100644
--- a/drivers/gpu/drm/i2c/adv7511/Makefile
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -1,2 +1,3 @@
 adv7511-y := adv7511_core.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511.h 
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
index fcae1ee..35828f0 100644
--- a/drivers/gpu/drm/i2c/adv7511/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -10,6 +10,7 @@
 #define __DRM_I2C_ADV7511_H__
 
 #include 
+#include 
 
 #define ADV7511_REG_CHIP_REVISION  0x00
 #define ADV7511_REG_N0 0x01
@@ -241,6 +242,7 @@ enum adv7511_sync_polarity {
  * @sync_pulse:Select the sync pulse
  * @vsync_polarity:vsync input signal configuration
  * @hsync_polarity:hsync input signal configuration
+ * @enable_audio   True if audio is enabled
  */
 struct adv7511_link_config {
unsigned int input_color_depth;
@@ -255,6 +257,8 @@ struct adv7511_link_config {
enum adv7511_input_sync_pulse sync_pulse;
enum adv7511_sync_polarity vsync_polarity;
enum adv7511_sync_polarity hsync_polarity;
+
+   bool enable_audio;
 };
 
 /**
@@ -296,6 +300,10 @@ struct adv7511 {
bool powered;
 
unsigned int f_tmds;
+   unsigned int f_audio;
+
+   unsigned int audio_source;
+   bool enable_audio;
 
unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -317,4 +325,18 @@ struct adv7511 {
 int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
 int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
 
+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev);
+void adv7511_audio_exit(struct device *dev);
+#else
+int adv7511_audio_init(st

[PATCH 5/5 v4] ASoC: dwc: Update DOCUMENTATION for I2S Driver

[Jose Abreu]

This patch updates documentation for the Designware I2S
driver.

Signed-off-by: Jose Abreu 
---

This patch was only introduced in v4.

 Documentation/devicetree/bindings/sound/designware-i2s.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/designware-i2s.txt 
b/Documentation/devicetree/bindings/sound/designware-i2s.txt
index 7bb5424..f3b5c17 100644
--- a/Documentation/devicetree/bindings/sound/designware-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/designware-i2s.txt
@@ -7,6 +7,10 @@ Required properties:
clocks. The controller expects one clock: the clock used as the sampling
rate reference clock sample.
  - clock-names : "i2sclk" for the sample rate reference clock.
+
+ Optional properties:
+ - snps,use-dmaengine: If set the driver will use ALSA DMA engine. If set
+   it is required to use the properties 'dmas' and 'dma-names'.
  - dmas: Pairs of phandle and specifier for the DMA channels that are used by
the core. The core expects one or two dma channels: one for transmit and
one for receive.
@@ -26,6 +30,7 @@ Example:
clocks = <&scpi_i2sclk 0>;
clock-names = "i2sclk";
#sound-dai-cells = <0>;
+   snps,use-dmaengine;
dmas = <&dma0 5>;
dma-names = "tx";
};
-- 
1.9.1

[PATCH 1/5 v4] drm/i2c/adv7511: Rename and move to separate folder

[Jose Abreu]

Main file of adv7511 driver was renamed from adv7511.c
to adv7511_core.c and moved to separate folder in order
to prepare the adding of audio support.

Struct adv7511 was moved to adv7511.h and functions
adv7511_packet_enable() and adv7511_packet_disable()
were made public also to prepare the adding of audio
support.

Signed-off-by: Jose Abreu 
---

No changes v3 -> v4.

This patch was only introduced in v3.

 drivers/gpu/drm/i2c/Kconfig|  6 +---
 drivers/gpu/drm/i2c/Makefile   |  2 +-
 drivers/gpu/drm/i2c/adv7511/Kconfig|  6 
 drivers/gpu/drm/i2c/adv7511/Makefile   |  2 ++
 drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 31 +
 .../drm/i2c/{adv7511.c => adv7511/adv7511_core.c}  | 32 ++
 6 files changed, 43 insertions(+), 36 deletions(-)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
 rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (93%)
 rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..9258daf 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,11 +1,7 @@
 menu "I2C encoder or helper chips"
  depends on DRM && DRM_KMS_HELPER && I2C
 
-config DRM_I2C_ADV7511
-   tristate "AV7511 encoder"
-   select REGMAP_I2C
-   help
- Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+source "drivers/gpu/drm/i2c/adv7511/Kconfig"
 
 config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb5..f144830 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,6 +1,6 @@
 ccflags-y := -Iinclude/drm
 
-obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+obj-y += adv7511/
 
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig 
b/drivers/gpu/drm/i2c/adv7511/Kconfig
new file mode 100644
index 000..302c8e34
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -0,0 +1,6 @@
+config DRM_I2C_ADV7511
+   tristate "AV7511 encoder"
+   select REGMAP_I2C
+   help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile 
b/drivers/gpu/drm/i2c/adv7511/Makefile
new file mode 100644
index 000..c13f5a1
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -0,0 +1,2 @@
+adv7511-y := adv7511_core.o
+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511.h 
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
similarity index 93%
rename from drivers/gpu/drm/i2c/adv7511.h
rename to drivers/gpu/drm/i2c/adv7511/adv7511.h
index 38515b3..fcae1ee 100644
--- a/drivers/gpu/drm/i2c/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -286,4 +286,35 @@ struct adv7511_video_config {
struct hdmi_avi_infoframe avi_infoframe;
 };
 
+struct adv7511 {
+   struct i2c_client *i2c_main;
+   struct i2c_client *i2c_edid;
+
+   struct regmap *regmap;
+   struct regmap *packet_memory_regmap;
+   enum drm_connector_status status;
+   bool powered;
+
+   unsigned int f_tmds;
+
+   unsigned int current_edid_segment;
+   uint8_t edid_buf[256];
+   bool edid_read;
+
+   wait_queue_head_t wq;
+   struct drm_encoder *encoder;
+
+   bool embedded_sync;
+   enum adv7511_sync_polarity vsync_polarity;
+   enum adv7511_sync_polarity hsync_polarity;
+   bool rgb;
+
+   struct edid *edid;
+
+   struct gpio_desc *gpio_pd;
+};
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511.c 
b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
similarity index 97%
rename from drivers/gpu/drm/i2c/adv7511.c
rename to drivers/gpu/drm/i2c/adv7511/adv7511_core.c
index a02112b..2b00581 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
@@ -20,34 +20,6 @@
 
 #include "adv7511.h"
 
-struct adv7511 {
-   struct i2c_client *i2c_main;
-   struct i2c_client *i2c_edid;
-
-   struct regmap *regmap;
-   struct regmap *packet_memory_regmap;
-   enum drm_connector_status status;
-   bool powered;
-
-   unsigned int f_tmds;
-
-   unsigned int current_edid_segment;
-   uint8_t edid_buf[256];
-   bool edid_read;
-
-   wait_queue_head_t wq;
-   struct drm_encoder *encoder;
-
-   bool embedded_sync;
-   enum adv7511_sync_polarity vsync_polarity;
-   enum adv7511_sync_polarity hsync_polarity;
-   bool 

[PATCH 0/5 v4] Add I2S/ADV7511 audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds audio for the ADV7511 transmitter and I2S audio for
the AXS10x platform.

Changes v3 -> v4:
* Reintroduced custom PCM driver (see note below)
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM
* Use fifo depth to program I2S FCR
* Update I2S documentation

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)


NOTE:
Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

Jose Abreu (5):
  drm/i2c/adv7511: Rename and move to separate folder
  drm/i2c/adv7511: Add audio support
  ASoC: dwc: Use fifo depth to program FCR
  ASoC: dwc: Add custom PCM driver
  ASoC: dwc: Update DOCUMENTATION for I2S Driver

 .../bindings/display/bridge/adi,adv7511.txt|   3 +
 .../devicetree/bindings/sound/designware-i2s.txt   |   5 +
 drivers/gpu/drm/i2c/Kconfig|   6 +-
 drivers/gpu/drm/i2c/Makefile   |   2 +-
 drivers/gpu/drm/i2c/adv7511/Kconfig|  18 ++
 drivers/gpu/drm/i2c/adv7511/Makefile   |   3 +
 drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h|  53 
 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
 .../drm/i2c/{adv7511.c => adv7511/adv7511_core.c}  |  43 +--
 include/sound/soc-dai.h|   1 +
 sound/soc/dwc/Kconfig  |   9 +
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  70 +
 sound/soc/dwc/designware_i2s.c | 106 +--
 sound/soc/dwc/designware_pcm.c | 230 +++
 15 files changed, 796 insertions(+), 64 deletions(-)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
 rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (90%)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
 rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

-- 
1.9.1

[PATCH 3/5 v4] ASoC: dwc: Use fifo depth to program FCR

[Jose Abreu]

This patch makes Designware I2S driver use the fifo
depth value to program the fifo configuration register
instead of using hardcoded values.

Signed-off-by: Jose Abreu 
---

This patch was only introduced in v4.

 sound/soc/dwc/designware_i2s.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3effcd1..0db69b7 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -100,6 +100,7 @@ struct dw_i2s_dev {
struct device *dev;
u32 ccr;
u32 xfer_resolution;
+   u32 fifo_th;
 
/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -232,14 +233,16 @@ static void dw_i2s_config(struct dw_i2s_dev *dev, int 
stream)
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
i2s_write_reg(dev->i2s_base, TCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
+   i2s_write_reg(dev->i2s_base, TFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
} else {
i2s_write_reg(dev->i2s_base, RCR(ch_reg),
  dev->xfer_resolution);
-   i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
+   i2s_write_reg(dev->i2s_base, RFCR(ch_reg),
+ dev->fifo_th - 1);
irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
@@ -499,6 +502,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
 */
u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
u32 comp2 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp2);
+   u32 fifo_depth = 1 << (1 + COMP1_FIFO_DEPTH_GLOBAL(comp1));
u32 idx;
 
if (dev->capability & DWC_I2S_RECORD &&
@@ -537,6 +541,7 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
dev->capability |= DW_I2S_SLAVE;
}
 
+   dev->fifo_th = fifo_depth / 2;
return 0;
 }
 
-- 
1.9.1

[PATCH 4/5 v4] ASoC: dwc: Add custom PCM driver

[Jose Abreu]

HDMI audio support was added to the AXS board using an
I2S cpu driver and a custom platform driver.

The platform driver supports two channels @ 16 bits with
rates 32k, 44.1k and 48k.

Although the mainline I2S driver uses ALSA DMA engine,
this controller can be built without DMA support so it
was necessary to add this custom platform driver so that
HDMI audio works in AXS boards.

The selection between the use of DMA engine or custom
PCM can be made using a device tree boolean parameter
which was introduced in this patch ('snps,use-dmaengine').

Signed-off-by: Jose Abreu 
---

Changes v3 -> v4:
* Reintroduced custom PCM driver
* Use DT boolean to switch between ALSA DMA engine PCM or custom PCM

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

No changes v1 -> v2.

 sound/soc/dwc/Kconfig  |   9 ++
 sound/soc/dwc/Makefile |   1 +
 sound/soc/dwc/designware.h |  70 +
 sound/soc/dwc/designware_i2s.c |  99 +-
 sound/soc/dwc/designware_pcm.c | 230 +
 5 files changed, 382 insertions(+), 27 deletions(-)
 create mode 100644 sound/soc/dwc/designware.h
 create mode 100644 sound/soc/dwc/designware_pcm.c

diff --git a/sound/soc/dwc/Kconfig b/sound/soc/dwc/Kconfig
index d50e085..2a21120 100644
--- a/sound/soc/dwc/Kconfig
+++ b/sound/soc/dwc/Kconfig
@@ -7,4 +7,13 @@ config SND_DESIGNWARE_I2S
 Synopsys desigwnware I2S device. The device supports upto
 maximum of 8 channels each for play and record.
 
+config SND_DESIGNWARE_PCM
+   tristate "Synopsys I2S PCM Driver"
+   help
+Say Y or M if you want to add support for ALSA ASoC platform driver
+using I2S.
+
+Select this option if you want to be able to create a sound interface
+using the I2S device driver as CPU driver. Instead of using ALSA
+DMA engine by selecting this driver a custom PCM driver will be used.
 
diff --git a/sound/soc/dwc/Makefile b/sound/soc/dwc/Makefile
index 319371f..1b48bccc 100644
--- a/sound/soc/dwc/Makefile
+++ b/sound/soc/dwc/Makefile
@@ -1,3 +1,4 @@
 # SYNOPSYS Platform Support
 obj-$(CONFIG_SND_DESIGNWARE_I2S) += designware_i2s.o
+obj-$(CONFIG_SND_DESIGNWARE_PCM) += designware_pcm.o
 
diff --git a/sound/soc/dwc/designware.h b/sound/soc/dwc/designware.h
new file mode 100644
index 000..196296c
--- /dev/null
+++ b/sound/soc/dwc/designware.h
@@ -0,0 +1,70 @@
+/*
+ * ALSA SoC Synopsys Audio Layer
+ *
+ * sound/soc/dwc/designware.h
+ *
+ * Copyright (C) 2016 Synopsys
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __DESIGNWARE_H
+#define __DESIGNWARE_H
+
+#include 
+#include 
+#include 
+#include 
+
+struct dw_pcm_binfo {
+   struct snd_pcm_substream *stream;
+   unsigned char *dma_base;
+   unsigned char *dma_pointer;
+   unsigned int period_size_frames;
+   unsigned int size;
+   snd_pcm_uframes_t period_pointer;
+   unsigned int total_periods;
+   unsigned int current_period;
+};
+
+union dw_i2s_snd_dma_data {
+   struct i2s_dma_data pd;
+   struct snd_dmaengine_dai_dma_data dt;
+};
+
+struct dw_i2s_dev {
+   void __iomem *i2s_base;
+   struct clk *clk;
+   int active;
+   unsigned int capability;
+   unsigned int quirks;
+   unsigned int i2s_reg_comp1;
+   unsigned int i2s_reg_comp2;
+   struct device *dev;
+   u32 ccr;
+   u32 xfer_resolution;
+   u32 fifo_th;
+
+   /* data related to DMA transfers b/w i2s and DMAC */
+   bool use_dmaengine;
+   union dw_i2s_snd_dma_data play_dma_data;
+   union dw_i2s_snd_dma_data capture_dma_data;
+   struct i2s_clk_config_data config;
+   int (*i2s_clk_cfg)(struct i2s_clk_config_data *config);
+   struct dw_pcm_binfo binfo;
+};
+
+#ifdef CONFIG_SND_DESIGNWARE_PCM
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi);
+#else
+int dw_pcm_transfer(u32 *lsample, u32 *rsample, int bytes, int buf_size,
+   struct dw_pcm_binfo *bi)
+{
+   return 0;
+}
+#endif
+
+#endif
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 0db69b7..16056c1 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include "designware.h"
 
 /* common register for all channel */
 #define IER0x000
@@ -84,31 +85,6 @@
 #define MAX_CHANNEL_NUM8
 #define MIN_CHANNEL_NUM2
 
-union dw_i2s_snd_dma_data {
-   struct i2s_dma_data pd;
-   struct snd_dmaengine_dai_dma_data dt;
-};
-
-struct dw_i2s_dev {
-   void __iome

[PATCH 1/3 v3] drm/i2c/adv7511: Rename and move to separate folder

[Jose Abreu]

Main file of adv7511 driver was renamed from adv7511.c
to adv7511_core.c and moved to separate folder in order
to prepare the adding of audio support.

Struct adv7511 was moved to adv7511.h and functions
adv7511_packet_enable() and adv7511_packet_disable()
were made public also to prepare the adding of audio
support.

Signed-off-by: Jose Abreu 
---

This patch was only introduced in v3.

 drivers/gpu/drm/i2c/Kconfig|  6 +---
 drivers/gpu/drm/i2c/Makefile   |  2 +-
 drivers/gpu/drm/i2c/adv7511/Kconfig|  6 
 drivers/gpu/drm/i2c/adv7511/Makefile   |  2 ++
 drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h| 31 +
 .../drm/i2c/{adv7511.c => adv7511/adv7511_core.c}  | 32 ++
 6 files changed, 43 insertions(+), 36 deletions(-)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
 rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (93%)
 rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..9258daf 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,11 +1,7 @@
 menu "I2C encoder or helper chips"
  depends on DRM && DRM_KMS_HELPER && I2C
 
-config DRM_I2C_ADV7511
-   tristate "AV7511 encoder"
-   select REGMAP_I2C
-   help
- Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+source "drivers/gpu/drm/i2c/adv7511/Kconfig"
 
 config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 2c72eb5..f144830 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,6 +1,6 @@
 ccflags-y := -Iinclude/drm
 
-obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+obj-y += adv7511/
 
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig 
b/drivers/gpu/drm/i2c/adv7511/Kconfig
new file mode 100644
index 000..302c8e34
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -0,0 +1,6 @@
+config DRM_I2C_ADV7511
+   tristate "AV7511 encoder"
+   select REGMAP_I2C
+   help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile 
b/drivers/gpu/drm/i2c/adv7511/Makefile
new file mode 100644
index 000..c13f5a1
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -0,0 +1,2 @@
+adv7511-y := adv7511_core.o
+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511.h 
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
similarity index 93%
rename from drivers/gpu/drm/i2c/adv7511.h
rename to drivers/gpu/drm/i2c/adv7511/adv7511.h
index 38515b3..fcae1ee 100644
--- a/drivers/gpu/drm/i2c/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -286,4 +286,35 @@ struct adv7511_video_config {
struct hdmi_avi_infoframe avi_infoframe;
 };
 
+struct adv7511 {
+   struct i2c_client *i2c_main;
+   struct i2c_client *i2c_edid;
+
+   struct regmap *regmap;
+   struct regmap *packet_memory_regmap;
+   enum drm_connector_status status;
+   bool powered;
+
+   unsigned int f_tmds;
+
+   unsigned int current_edid_segment;
+   uint8_t edid_buf[256];
+   bool edid_read;
+
+   wait_queue_head_t wq;
+   struct drm_encoder *encoder;
+
+   bool embedded_sync;
+   enum adv7511_sync_polarity vsync_polarity;
+   enum adv7511_sync_polarity hsync_polarity;
+   bool rgb;
+
+   struct edid *edid;
+
+   struct gpio_desc *gpio_pd;
+};
+
+int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
+int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511.c 
b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
similarity index 97%
rename from drivers/gpu/drm/i2c/adv7511.c
rename to drivers/gpu/drm/i2c/adv7511/adv7511_core.c
index a02112b..2b00581 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_core.c
@@ -20,34 +20,6 @@
 
 #include "adv7511.h"
 
-struct adv7511 {
-   struct i2c_client *i2c_main;
-   struct i2c_client *i2c_edid;
-
-   struct regmap *regmap;
-   struct regmap *packet_memory_regmap;
-   enum drm_connector_status status;
-   bool powered;
-
-   unsigned int f_tmds;
-
-   unsigned int current_edid_segment;
-   uint8_t edid_buf[256];
-   bool edid_read;
-
-   wait_queue_head_t wq;
-   struct drm_encoder *encoder;
-
-   bool embedded_sync;
-   enum adv7511_sync_polarity vsync_polarity;
-   enum adv7511_sync_polarity hsync_polarity;
-   bool rgb;
-
-   struct edid *edi

[PATCH 0/3 v3] Add I2S/ADV7511 audio support for ARC AXS10x boards

[Jose Abreu]

ARC AXS10x platforms consist of a mainboard with several peripherals.
One of those peripherals is an HDMI output port controlled by the ADV7511
transmitter.

This patch set adds audio for the ADV7511 transmitter and I2S audio for
the AXS10x platform.

Changes v2 -> v3:
* Removed pll_config functions (as suggested by Alexey Brodkin)
* Removed HDMI start at adv7511_core (as suggested by Archit Taneja)
* Use NOP functions for adv7511_audio (as suggested by Archit Taneja)
* Added adv7511_audio_exit() function (as suggested by Archit Taneja)
* Moved adv7511 to its own folder (as suggested by Archit Taneja)
* Separated file rename of adv7511_core (as suggested by Emil Velikov)
* Compile adv7511 as module if ALSA SoC is compiled as module
* Load adv7511 audio only if declared in device tree (as suggested by Laurent 
Pinchart)
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S

Changes v1 -> v2:
* DT bindings moved to separate patch (as suggested by Alexey Brodkin)
* Removed defconfigs entries (as suggested by Alexey Brodkin)

Jose Abreu (3):
  drm/i2c/adv7511: Rename and move to separate folder
  drm/i2c/adv7511: Add audio support
  ASoC: dwc: Unmask I2S interrupts only for enabled channels

 .../bindings/display/bridge/adi,adv7511.txt|   3 +
 drivers/gpu/drm/i2c/Kconfig|   6 +-
 drivers/gpu/drm/i2c/Makefile   |   2 +-
 drivers/gpu/drm/i2c/adv7511/Kconfig|  18 ++
 drivers/gpu/drm/i2c/adv7511/Makefile   |   3 +
 drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h|  53 
 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
 .../drm/i2c/{adv7511.c => adv7511/adv7511_core.c}  |  43 +--
 include/sound/soc-dai.h|   1 +
 sound/soc/dwc/designware_i2s.c |   5 +-
 10 files changed, 406 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Kconfig
 create mode 100644 drivers/gpu/drm/i2c/adv7511/Makefile
 rename drivers/gpu/drm/i2c/{ => adv7511}/adv7511.h (90%)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
 rename drivers/gpu/drm/i2c/{adv7511.c => adv7511/adv7511_core.c} (97%)

-- 
1.9.1

[PATCH 3/3 v3] ASoC: dwc: Unmask I2S interrupts only for enabled channels

[Jose Abreu]

There is no need to unmask all interrupts at I2S start. This
can cause performance issues in slower platforms.

Unmask only the interrupts for the used channels.

Signed-off-by: Jose Abreu 
---

Changes v2 -> v3:
* Dropped custom platform driver, using now ALSA DMA engine
* Dropped IRQ handler for I2S
* Removed pll_config functions (as suggested by Alexey Brodkin)

No changes v1 -> v2.

 sound/soc/dwc/designware_i2s.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index bff258d..3effcd1 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -147,17 +147,18 @@ static inline void i2s_clear_irqs(struct dw_i2s_dev *dev, 
u32 stream)
 static void i2s_start(struct dw_i2s_dev *dev,
  struct snd_pcm_substream *substream)
 {
+   struct i2s_clk_config_data *config = &dev->config;
u32 i, irq;
i2s_write_reg(dev->i2s_base, IER, 1);
 
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   for (i = 0; i < 4; i++) {
+   for (i = 0; i < (config->chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x30);
}
i2s_write_reg(dev->i2s_base, ITER, 1);
} else {
-   for (i = 0; i < 4; i++) {
+   for (i = 0; i < (config->chan_nr / 2); i++) {
irq = i2s_read_reg(dev->i2s_base, IMR(i));
i2s_write_reg(dev->i2s_base, IMR(i), irq & ~0x03);
}
-- 
1.9.1

[PATCH 2/3 v3] drm/i2c/adv7511: Add audio support

[Jose Abreu]

This patch adds audio support for the ADV7511 HDMI transmitter
using ALSA SoC.

The code was ported from Analog Devices linux tree from
commit 1770c4a1e32b ("Merge remote-tracking branch
'xilinx/master' into xcomm_zynq"), which is available at:
- https://github.com/analogdevicesinc/linux/

The audio can be disabled using menu-config so it is possible
to use only video mode. The audio (when enabled) registers as
a codec into ALSA.

SPDIF DAI format was also added to ASoC as it is required
by adv7511 audio.

Signed-off-by: Jose Abreu 
---
 .../bindings/display/bridge/adi,adv7511.txt|   3 +
 drivers/gpu/drm/i2c/adv7511/Kconfig|  12 +
 drivers/gpu/drm/i2c/adv7511/Makefile   |   1 +
 drivers/gpu/drm/i2c/adv7511/adv7511.h  |  22 ++
 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c| 310 +
 drivers/gpu/drm/i2c/adv7511/adv7511_core.c |  11 +
 include/sound/soc-dai.h|   1 +
 7 files changed, 360 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/adv7511/adv7511_audio.c

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 96c25ee..920e542 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -43,6 +43,9 @@ Optional properties:
   data stream (similar to BT.656). Defaults to separate H/V synchronization
   signals.
 
+- adi,enable-audio: If set the ADV7511 driver will register a codec interface
+  into ALSA SoC.
+
 Required nodes:
 
 The ADV7511 has two video ports. Their connections are modelled using the OF
diff --git a/drivers/gpu/drm/i2c/adv7511/Kconfig 
b/drivers/gpu/drm/i2c/adv7511/Kconfig
index 302c8e34..900f3e9 100644
--- a/drivers/gpu/drm/i2c/adv7511/Kconfig
+++ b/drivers/gpu/drm/i2c/adv7511/Kconfig
@@ -4,3 +4,15 @@ config DRM_I2C_ADV7511
help
  Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
 
+config DRM_I2C_ADV7511_AUDIO
+   bool "ADV7511 audio"
+   depends on DRM_I2C_ADV7511
+   depends on SND_SOC=y || (SND_SOC && DRM_I2C_ADV7511=m)
+   default y
+   help
+ This adds support for audio on the ADV7511(W) and ADV7513 HDMI
+ encoders.
+
+ By selecting this option the ADV7511 will register a codec interface
+ into ALSA.
+
diff --git a/drivers/gpu/drm/i2c/adv7511/Makefile 
b/drivers/gpu/drm/i2c/adv7511/Makefile
index c13f5a1..d68773a 100644
--- a/drivers/gpu/drm/i2c/adv7511/Makefile
+++ b/drivers/gpu/drm/i2c/adv7511/Makefile
@@ -1,2 +1,3 @@
 adv7511-y := adv7511_core.o
+adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511.h 
b/drivers/gpu/drm/i2c/adv7511/adv7511.h
index fcae1ee..35828f0 100644
--- a/drivers/gpu/drm/i2c/adv7511/adv7511.h
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511.h
@@ -10,6 +10,7 @@
 #define __DRM_I2C_ADV7511_H__
 
 #include 
+#include 
 
 #define ADV7511_REG_CHIP_REVISION  0x00
 #define ADV7511_REG_N0 0x01
@@ -241,6 +242,7 @@ enum adv7511_sync_polarity {
  * @sync_pulse:Select the sync pulse
  * @vsync_polarity:vsync input signal configuration
  * @hsync_polarity:hsync input signal configuration
+ * @enable_audio   True if audio is enabled
  */
 struct adv7511_link_config {
unsigned int input_color_depth;
@@ -255,6 +257,8 @@ struct adv7511_link_config {
enum adv7511_input_sync_pulse sync_pulse;
enum adv7511_sync_polarity vsync_polarity;
enum adv7511_sync_polarity hsync_polarity;
+
+   bool enable_audio;
 };
 
 /**
@@ -296,6 +300,10 @@ struct adv7511 {
bool powered;
 
unsigned int f_tmds;
+   unsigned int f_audio;
+
+   unsigned int audio_source;
+   bool enable_audio;
 
unsigned int current_edid_segment;
uint8_t edid_buf[256];
@@ -317,4 +325,18 @@ struct adv7511 {
 int adv7511_packet_enable(struct adv7511 *adv7511, unsigned int packet);
 int adv7511_packet_disable(struct adv7511 *adv7511, unsigned int packet);
 
+#ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
+int adv7511_audio_init(struct device *dev);
+void adv7511_audio_exit(struct device *dev);
+#else
+int adv7511_audio_init(struct device *dev)
+{
+   return 0;
+}
+void adv7511_audio_exit(struct device *dev)
+{
+
+}
+#endif
+
 #endif /* __DRM_I2C_ADV7511_H__ */
diff --git a/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c 
b/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
new file mode 100644
index 000..5562ed5
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511/adv7511_audio.c
@@ -0,0 +1,310 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#in

Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Laurent,


On 04-04-2016 22:41, Laurent Pinchart wrote:
> Hi Jose,
>
> On Monday 04 Apr 2016 10:05:39 Jose Abreu wrote:
>> On 01-04-2016 18:10, Laurent Pinchart wrote:
>>> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>>>> This patch adds audio support for the ADV7511 HDMI transmitter
>>>> using ALSA SoC.
>>>>
>>>> The code was ported from Analog Devices linux tree from
>>>> commit 1770c4a1e32b ("Merge remote-tracking branch
>>>>
>>>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>>>- https://github.com/analogdevicesinc/linux/
>>>>
>>>> The main core file was renamed from adv7511.c to adv7511_core.c
>>>> so that audio and video compile into a single adv7511.ko module
>>>> and to keep up with Analog Devices kernel tree.
>>>>
>>>> The audio can be disabled using menu-config so it is possible
>>>> to use only video mode.
>>>>
>>>> The HDMI mode is automatically started at boot and the audio
>>>> (when enabled) registers as a codec into ALSA.
>>>>
>>>> SPDIF DAI format was also added to ASoC as it is required
>>>> by adv7511 audio.
>>>>
>>>> Signed-off-by: Jose Abreu 
>>>> ---
>>>>
>>>> No changes v1 -> v2.
>>>>
>>>>  drivers/gpu/drm/i2c/Kconfig |   11 +
>>>>  drivers/gpu/drm/i2c/Makefile|2 +
>>>>  drivers/gpu/drm/i2c/adv7511.c   | 1024 
>>>>  drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>>>>  drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>>>>  drivers/gpu/drm/i2c/adv7511_core.c  | 1005 
>>> Please use git-format-patch -M to detect renames if you send a new version
>>> of this series, it will help with review.
>> Ok, will do that in next version.
>>
>>>>  include/sound/soc-dai.h |1 +
>>>>  7 files changed, 1370 insertions(+), 1024 deletions(-)
>>>>  delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>>>  create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>>>  create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>>> [snip]
>>>
>>>> diff --git a/drivers/gpu/drm/i2c/adv7511_core.c
>>>> b/drivers/gpu/drm/i2c/adv7511_core.c new file mode 100644
>>>> index 000..d54256a
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/i2c/adv7511_core.c
>>> [snip]
>>>
>>>> +static int adv7511_probe(struct i2c_client *i2c, const struct
>>>> i2c_device_id *id) +{
>>>> +  struct adv7511_link_config link_config;
>>>> +  struct adv7511 *adv7511;
>>>> +  struct device *dev = &i2c->dev;
>>>> +  unsigned int val;
>>>> +  int ret;
>>>> +
>>>> +  if (!dev->of_node)
>>>> +  return -EINVAL;
>>>> +
>>>> +  adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>>>> +  if (!adv7511)
>>>> +  return -ENOMEM;
>>>> +
>>>> +  adv7511->powered = false;
>>>> +  adv7511->status = connector_status_disconnected;
>>>> +
>>>> +  ret = adv7511_parse_dt(dev->of_node, &link_config);
>>>> +  if (ret)
>>>> +  return ret;
>>>> +
>>>> +  /*
>>>> +   * The power down GPIO is optional. If present, toggle it from active
>>>> to
>>>> +   * inactive to wake up the encoder.
>>>> +   */
>>>> +  adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", 
> GPIOD_OUT_HIGH);
>>>> +  if (IS_ERR(adv7511->gpio_pd))
>>>> +  return PTR_ERR(adv7511->gpio_pd);
>>>> +
>>>> +  if (adv7511->gpio_pd) {
>>>> +  mdelay(5);
>>>> +  gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>>>> +  }
>>>> +
>>>> +  adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
>>>> +  if (IS_ERR(adv7511->regmap))
>>>> +  return PTR_ERR(adv7511->regmap);
>>>> +
>>>> +  ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
>>>> +  if (ret)
>>>> +  return ret;
>>>> +  dev_dbg(dev, "Rev. %d\n", val);
>>>> +
>>>

Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Laurent,


On 01-04-2016 18:10, Laurent Pinchart wrote:
> Hi Jose,
>
> Thank you for the patch.
>
> On Monday 28 Mar 2016 15:36:09 Jose Abreu wrote:
>> This patch adds audio support for the ADV7511 HDMI transmitter
>> using ALSA SoC.
>>
>> The code was ported from Analog Devices linux tree from
>> commit 1770c4a1e32b ("Merge remote-tracking branch
>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>  - https://github.com/analogdevicesinc/linux/
>>
>> The main core file was renamed from adv7511.c to adv7511_core.c
>> so that audio and video compile into a single adv7511.ko module
>> and to keep up with Analog Devices kernel tree.
>>
>> The audio can be disabled using menu-config so it is possible
>> to use only video mode.
>>
>> The HDMI mode is automatically started at boot and the audio
>> (when enabled) registers as a codec into ALSA.
>>
>> SPDIF DAI format was also added to ASoC as it is required
>> by adv7511 audio.
>>
>> Signed-off-by: Jose Abreu 
>> ---
>>
>> No changes v1 -> v2.
>>
>>  drivers/gpu/drm/i2c/Kconfig |   11 +
>>  drivers/gpu/drm/i2c/Makefile|2 +
>>  drivers/gpu/drm/i2c/adv7511.c   | 1024 ---
>>  drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>>  drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>>  drivers/gpu/drm/i2c/adv7511_core.c  | 1005 ++
> Please use git-format-patch -M to detect renames if you send a new version of 
> this series, it will help with review.

Ok, will do that in next version.

>>  include/sound/soc-dai.h |1 +
>>  7 files changed, 1370 insertions(+), 1024 deletions(-)
>>  delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>  create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>  create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
> [snip]
>
>> diff --git a/drivers/gpu/drm/i2c/adv7511_core.c
>> b/drivers/gpu/drm/i2c/adv7511_core.c new file mode 100644
>> index 000..d54256a
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i2c/adv7511_core.c
> [snip]
>
>> +static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id
>> *id) +{
>> +struct adv7511_link_config link_config;
>> +struct adv7511 *adv7511;
>> +struct device *dev = &i2c->dev;
>> +unsigned int val;
>> +int ret;
>> +
>> +if (!dev->of_node)
>> +return -EINVAL;
>> +
>> +adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>> +if (!adv7511)
>> +return -ENOMEM;
>> +
>> +adv7511->powered = false;
>> +adv7511->status = connector_status_disconnected;
>> +
>> +ret = adv7511_parse_dt(dev->of_node, &link_config);
>> +if (ret)
>> +return ret;
>> +
>> +/*
>> + * The power down GPIO is optional. If present, toggle it from active to
>> + * inactive to wake up the encoder.
>> + */
>> +adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
>> +if (IS_ERR(adv7511->gpio_pd))
>> +return PTR_ERR(adv7511->gpio_pd);
>> +
>> +if (adv7511->gpio_pd) {
>> +mdelay(5);
>> +gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>> +}
>> +
>> +adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
>> +if (IS_ERR(adv7511->regmap))
>> +return PTR_ERR(adv7511->regmap);
>> +
>> +ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
>> +if (ret)
>> +return ret;
>> +dev_dbg(dev, "Rev. %d\n", val);
>> +
>> +ret = regmap_register_patch(adv7511->regmap, adv7511_fixed_registers,
>> +ARRAY_SIZE(adv7511_fixed_registers));
>> +if (ret)
>> +return ret;
>> +
>> +regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
>> +regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> + packet_i2c_addr);
>> +regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
>> +adv7511_packet_disable(adv7511, 0x);
>> +
>> +adv7511->i2c_main = i2c;
>> +adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
>> +if (!adv7511->i2c_edid)
>> +return -ENOMEM;
>> +
>> +if (i2c->i

Re: [PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Archit,


On 29-03-2016 18:03, Archit Taneja wrote:
>
>
> On 3/29/2016 4:22 PM, Jose Abreu wrote:
>> Hi Archit,
>>
>> On 29-03-2016 09:05, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/28/2016 08:06 PM, Jose Abreu wrote:
>>>> This patch adds audio support for the ADV7511 HDMI transmitter
>>>> using ALSA SoC.
>>>>
>>>> The code was ported from Analog Devices linux tree from
>>>> commit 1770c4a1e32b ("Merge remote-tracking branch
>>>> 'xilinx/master' into xcomm_zynq"), which is available at:
>>>>  - https://github.com/analogdevicesinc/linux/
>>>>
>>>> The main core file was renamed from adv7511.c to adv7511_core.c
>>>> so that audio and video compile into a single adv7511.ko module
>>>> and to keep up with Analog Devices kernel tree.
>>>>
>>>> The audio can be disabled using menu-config so it is possible
>>>> to use only video mode.
>>>>
>>>> The HDMI mode is automatically started at boot and the audio
>>>> (when enabled) registers as a codec into ALSA.
>>>
>>> Is there a reason why we set the mode to HDMI at probe itself?
>>> Shouldn't it be okay to set the mode later once we read the
>>> EDID off the panel?
>>>
>>> Some more comments below.
>>>
>>
>> Well, when I was using this in kernel 3.18 (with an older version of the 
>> driver)
>> I noticed that DVI mode was being used even when HDMI was connected so I 
>> forced
>> the driver to start in HDMI mode. There were some changes in the driver so 
>> it is
>> possible that this is no longer needed. Should I drop it?
>
> Mode selection works fine with ADV7533 on a 4.5 kernel. I'm assuming it
> should work out of the box for ADV7511 too. We should drop this.
>
>

Ok, will drop.

>>
>>>>
>>>> SPDIF DAI format was also added to ASoC as it is required
>>>> by adv7511 audio.
>>>>
>>>> Signed-off-by: Jose Abreu 
>>>> ---
>>>>
>>>> No changes v1 -> v2.
>>>>
>>>>drivers/gpu/drm/i2c/Kconfig |   11 +
>>>>drivers/gpu/drm/i2c/Makefile|2 +
>>>>drivers/gpu/drm/i2c/adv7511.c   | 1024
>>>> ---
>>>>drivers/gpu/drm/i2c/adv7511.h   |   41 ++
>>>>drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
>>>>drivers/gpu/drm/i2c/adv7511_core.c  | 1005
>>>> ++
>>>>include/sound/soc-dai.h |1 +
>>>>7 files changed, 1370 insertions(+), 1024 deletions(-)
>>>>delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
>>>>create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
>>>>create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>>>
>>> 
>>>
>>>> +
>>>> +static int adv7511_probe(struct i2c_client *i2c, const struct 
>>>> i2c_device_id
>>>> *id)
>>>> +{
>>>> +struct adv7511_link_config link_config;
>>>> +struct adv7511 *adv7511;
>>>> +struct device *dev = &i2c->dev;
>>>> +unsigned int val;
>>>> +int ret;
>>>> +
>>>> +if (!dev->of_node)
>>>> +return -EINVAL;
>>>> +
>>>> +adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
>>>> +if (!adv7511)
>>>> +return -ENOMEM;
>>>> +
>>>> +adv7511->powered = false;
>>>> +adv7511->status = connector_status_disconnected;
>>>> +
>>>> +ret = adv7511_parse_dt(dev->of_node, &link_config);
>>>> +if (ret)
>>>> +return ret;
>>>> +
>>>> +/*
>>>> + * The power down GPIO is optional. If present, toggle it from active 
>>>> to
>>>> + * inactive to wake up the encoder.
>>>> + */
>>>> +adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
>>>> +if (IS_ERR(adv7511->gpio_pd))
>>>> +return PTR_ERR(adv7511->gpio_pd);
>>>> +
>>>> +if (adv7511->gpio_pd) {
>>>> +mdelay(5);
>>>> +gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
>>>> +}
>>>> +
>>>> +adv751