Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Thu, Jun 9, 2016 at 4:31 PM, Daniel Vetter  wrote:
> On Thu, Jun 9, 2016 at 4:29 PM, Alexey Brodkin
>  wrote:
>> Hi Daniel,
>>
>> On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
>>>
>>> The fake implementation is fundamentally racy, and I don't want to write
>>> helpers which can't be used correctly. Anyway I think without this patch
>>> (or something similar) arcpgu will stall badly with the new nonblocking
>>> helpers, because arcpgu didn't bother at all to implement nonblocking. Can
>>> you pls ack this, or even better, test the entire patch series? The
>>> helpers themselves should work, but in all 5 drivers tested thus far they
>>> discovered some bugs.
>>
>> Sure I will happily test this series.
>> The only question then is what should I use as a proper base?
>
> It should apply on drm-next from Dave.

And indeed it won't work at all because arcpgu doesn't call
drm_crtc_handle_vblank anywhere. So you need to add your patch to
enable vblank interrupts somewhere. Note that as long as you leave
max_vblank_counter as 0, the only bits you need is drm_vblank_init and
drm_crtc_handle_vblanke() from the irq handler.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Thu, Jun 9, 2016 at 4:29 PM, Alexey Brodkin
 wrote:
> Hi Daniel,
>
> On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
>>
>> The fake implementation is fundamentally racy, and I don't want to write
>> helpers which can't be used correctly. Anyway I think without this patch
>> (or something similar) arcpgu will stall badly with the new nonblocking
>> helpers, because arcpgu didn't bother at all to implement nonblocking. Can
>> you pls ack this, or even better, test the entire patch series? The
>> helpers themselves should work, but in all 5 drivers tested thus far they
>> discovered some bugs.
>
> Sure I will happily test this series.
> The only question then is what should I use as a proper base?

It should apply on drm-next from Dave.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
> 
> The fake implementation is fundamentally racy, and I don't want to write
> helpers which can't be used correctly. Anyway I think without this patch
> (or something similar) arcpgu will stall badly with the new nonblocking
> helpers, because arcpgu didn't bother at all to implement nonblocking. Can
> you pls ack this, or even better, test the entire patch series? The
> helpers themselves should work, but in all 5 drivers tested thus far they
> discovered some bugs.

Sure I will happily test this series.
The only question then is what should I use as a proper base?

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Thu, Jun 09, 2016 at 01:27:55PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Thu, 2016-06-09 at 15:23 +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 12:48:31PM +, Alexey Brodkin wrote:
> > > 
> > > Hi Daniel,
> > > 
> > > On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> > > > 
> > > > On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > > > > 
> > > > > 
> > > > > Hi Daniel,
> > > > > 
> > > > > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > > > > 
> > > > > > 
> > > > > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > The drm core has a nice ready-made helper for exactly the 
> > > > > > > > simple case
> > > > > > > > where it should fire on the next vblank.
> > > > > > > > 
> > > > > > > > Note that arming the vblank event in _begin is probably too 
> > > > > > > > early, and
> > > > > > > > might easily result in the vblank firing too early, before the 
> > > > > > > > new set
> > > > > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > > > > compared to just outright hanging userspace.
> > > > > > > > 
> > > > > > > > v2: Be more robust and either arm, when the CRTC is on, or just 
> > > > > > > > send
> > > > > > > > the event out right away.
> > > > > > > > 
> > > > > > > > Cc: Carlos Palminha 
> > > > > > > > Cc: Alexey Brodkin 
> > > > > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > > > > Signed-off-by: Daniel Vetter 
> > > > > > > Wouldn't it be better to do this in atomic_flush then?
> > > > > > I'm not going to fix up other people's drivers completely, just 
> > > > > > enough to
> > > > > > hopefully not break them. If arc also blocks vblank interrupts with 
> > > > > > the go
> > > > > > bit, then doing this in _begin is correct. Either way it needs 
> > > > > > hw-specific
> > > > > > knowledge to asses whether it's correct, since doing the vblank 
> > > > > > event
> > > > > > stuff in _flush is also racy without some prevention.
> > > > > Actually in ARC PGU driver that was one of many other copy-pastes from
> > > > > other drivers. I.e. for me this is another boilerplate and if that's 
> > > > > the
> > > > > same for other drivers as well probably that's a good candidate for
> > > > > generalization into something like drm_helper_crtc_atomic_check().
> > > > I checked them all, you are special with your code here. And this can't 
> > > > be
> > > > generalized since you must send out vblank events in a race-free manner
> > > > against the actual hw update. This requires deep knowledge of the actual
> > > > hw, and it's not something the helpers can take care of you. It is very
> > > > much not boilerplate, but crucial for a correct implementation. And most
> > > > likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> > > > going to change it more than absolutely required.
> > > Well I meant as of today we don't support vblank interrupts and so
> > > arc_pgu_crtc_atomic_begin() barely makes any sense.
> > > 
> > > Still in the future we do plan to add support of interrupts.
> > 
> >
> > If you don't support vblank interrupts you're driver isn't compliant with
> > atomic. You need to at least fake them.
> 
> Indeed. So my assumption was there are (or could appear) other simple drivers
> of the same kind and that fake implementation might be generic.

The fake implementation is fundamentally racy, and I don't want to write
helpers which can't be used correctly. Anyway I think without this patch
(or something similar) arcpgu will stall badly with the new nonblocking
helpers, because arcpgu didn't bother at all to implement nonblocking. Can
you pls ack this, or even better, test the entire patch series? The
helpers themselves should work, but in all 5 drivers tested thus far they
discovered some bugs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 15:23 +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 12:48:31PM +, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> > > 
> > > On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Daniel,
> > > > 
> > > > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > > > 
> > > > > 
> > > > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The drm core has a nice ready-made helper for exactly the simple 
> > > > > > > case
> > > > > > > where it should fire on the next vblank.
> > > > > > > 
> > > > > > > Note that arming the vblank event in _begin is probably too 
> > > > > > > early, and
> > > > > > > might easily result in the vblank firing too early, before the 
> > > > > > > new set
> > > > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > > > compared to just outright hanging userspace.
> > > > > > > 
> > > > > > > v2: Be more robust and either arm, when the CRTC is on, or just 
> > > > > > > send
> > > > > > > the event out right away.
> > > > > > > 
> > > > > > > Cc: Carlos Palminha 
> > > > > > > Cc: Alexey Brodkin 
> > > > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > > > Signed-off-by: Daniel Vetter 
> > > > > > Wouldn't it be better to do this in atomic_flush then?
> > > > > I'm not going to fix up other people's drivers completely, just 
> > > > > enough to
> > > > > hopefully not break them. If arc also blocks vblank interrupts with 
> > > > > the go
> > > > > bit, then doing this in _begin is correct. Either way it needs 
> > > > > hw-specific
> > > > > knowledge to asses whether it's correct, since doing the vblank event
> > > > > stuff in _flush is also racy without some prevention.
> > > > Actually in ARC PGU driver that was one of many other copy-pastes from
> > > > other drivers. I.e. for me this is another boilerplate and if that's the
> > > > same for other drivers as well probably that's a good candidate for
> > > > generalization into something like drm_helper_crtc_atomic_check().
> > > I checked them all, you are special with your code here. And this can't be
> > > generalized since you must send out vblank events in a race-free manner
> > > against the actual hw update. This requires deep knowledge of the actual
> > > hw, and it's not something the helpers can take care of you. It is very
> > > much not boilerplate, but crucial for a correct implementation. And most
> > > likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> > > going to change it more than absolutely required.
> > Well I meant as of today we don't support vblank interrupts and so
> > arc_pgu_crtc_atomic_begin() barely makes any sense.
> > 
> > Still in the future we do plan to add support of interrupts.
> 
>
> If you don't support vblank interrupts you're driver isn't compliant with
> atomic. You need to at least fake them.

Indeed. So my assumption was there are (or could appear) other simple drivers
of the same kind and that fake implementation might be generic.

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Thu, Jun 09, 2016 at 12:48:31PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> > On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > > 
> > > Hi Daniel,
> > > 
> > > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > > 
> > > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > > 
> > > > > 
> > > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > > 
> > > > > > 
> > > > > > The drm core has a nice ready-made helper for exactly the simple 
> > > > > > case
> > > > > > where it should fire on the next vblank.
> > > > > > 
> > > > > > Note that arming the vblank event in _begin is probably too early, 
> > > > > > and
> > > > > > might easily result in the vblank firing too early, before the new 
> > > > > > set
> > > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > > compared to just outright hanging userspace.
> > > > > > 
> > > > > > v2: Be more robust and either arm, when the CRTC is on, or just send
> > > > > > the event out right away.
> > > > > > 
> > > > > > Cc: Carlos Palminha 
> > > > > > Cc: Alexey Brodkin 
> > > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > > Signed-off-by: Daniel Vetter 
> > > > > Wouldn't it be better to do this in atomic_flush then?
> > > > I'm not going to fix up other people's drivers completely, just enough 
> > > > to
> > > > hopefully not break them. If arc also blocks vblank interrupts with the 
> > > > go
> > > > bit, then doing this in _begin is correct. Either way it needs 
> > > > hw-specific
> > > > knowledge to asses whether it's correct, since doing the vblank event
> > > > stuff in _flush is also racy without some prevention.
> > > Actually in ARC PGU driver that was one of many other copy-pastes from
> > > other drivers. I.e. for me this is another boilerplate and if that's the
> > > same for other drivers as well probably that's a good candidate for
> > > generalization into something like drm_helper_crtc_atomic_check().
> >
> > I checked them all, you are special with your code here. And this can't be
> > generalized since you must send out vblank events in a race-free manner
> > against the actual hw update. This requires deep knowledge of the actual
> > hw, and it's not something the helpers can take care of you. It is very
> > much not boilerplate, but crucial for a correct implementation. And most
> > likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> > going to change it more than absolutely required.
> 
> Well I meant as of today we don't support vblank interrupts and so
> arc_pgu_crtc_atomic_begin() barely makes any sense.
> 
> Still in the future we do plan to add support of interrupts.

If you don't support vblank interrupts you're driver isn't compliant with
atomic. You need to at least fake them.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > 
> > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > 
> > > > 
> > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > 
> > > > > 
> > > > > The drm core has a nice ready-made helper for exactly the simple case
> > > > > where it should fire on the next vblank.
> > > > > 
> > > > > Note that arming the vblank event in _begin is probably too early, and
> > > > > might easily result in the vblank firing too early, before the new set
> > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > compared to just outright hanging userspace.
> > > > > 
> > > > > v2: Be more robust and either arm, when the CRTC is on, or just send
> > > > > the event out right away.
> > > > > 
> > > > > Cc: Carlos Palminha 
> > > > > Cc: Alexey Brodkin 
> > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > Signed-off-by: Daniel Vetter 
> > > > Wouldn't it be better to do this in atomic_flush then?
> > > I'm not going to fix up other people's drivers completely, just enough to
> > > hopefully not break them. If arc also blocks vblank interrupts with the go
> > > bit, then doing this in _begin is correct. Either way it needs hw-specific
> > > knowledge to asses whether it's correct, since doing the vblank event
> > > stuff in _flush is also racy without some prevention.
> > Actually in ARC PGU driver that was one of many other copy-pastes from
> > other drivers. I.e. for me this is another boilerplate and if that's the
> > same for other drivers as well probably that's a good candidate for
> > generalization into something like drm_helper_crtc_atomic_check().
>
> I checked them all, you are special with your code here. And this can't be
> generalized since you must send out vblank events in a race-free manner
> against the actual hw update. This requires deep knowledge of the actual
> hw, and it's not something the helpers can take care of you. It is very
> much not boilerplate, but crucial for a correct implementation. And most
> likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> going to change it more than absolutely required.

Well I meant as of today we don't support vblank interrupts and so
arc_pgu_crtc_atomic_begin() barely makes any sense.

Still in the future we do plan to add support of interrupts.

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Daniel Vetter]

On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > 
> > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > 
> > > > The drm core has a nice ready-made helper for exactly the simple case
> > > > where it should fire on the next vblank.
> > > > 
> > > > Note that arming the vblank event in _begin is probably too early, and
> > > > might easily result in the vblank firing too early, before the new set
> > > > of planes are actually disabled. But that's kinda a minor issue
> > > > compared to just outright hanging userspace.
> > > > 
> > > > v2: Be more robust and either arm, when the CRTC is on, or just send
> > > > the event out right away.
> > > > 
> > > > Cc: Carlos Palminha 
> > > > Cc: Alexey Brodkin 
> > > > Cc: linux-snps-arc@lists.infradead.org
> > > > Signed-off-by: Daniel Vetter 
> > > Wouldn't it be better to do this in atomic_flush then?
> > I'm not going to fix up other people's drivers completely, just enough to
> > hopefully not break them. If arc also blocks vblank interrupts with the go
> > bit, then doing this in _begin is correct. Either way it needs hw-specific
> > knowledge to asses whether it's correct, since doing the vblank event
> > stuff in _flush is also racy without some prevention.
> 
> Actually in ARC PGU driver that was one of many other copy-pastes from
> other drivers. I.e. for me this is another boilerplate and if that's the
> same for other drivers as well probably that's a good candidate for
> generalization into something like drm_helper_crtc_atomic_check().

I checked them all, you are special with your code here. And this can't be
generalized since you must send out vblank events in a race-free manner
against the actual hw update. This requires deep knowledge of the actual
hw, and it's not something the helpers can take care of you. It is very
much not boilerplate, but crucial for a correct implementation. And most
likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
going to change it more than absolutely required.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

[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-arc@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@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



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

[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-arc@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@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)

[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-arc@lists.infradead.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@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



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

Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31

[Michael Ellerman]

On Thu, 2016-06-09 at 08:44 +, Alexey Brodkin wrote:
> Hi Michael,
> 
> On Thu, 2016-06-09 at 14:02 +0530, Vineet Gupta wrote:
> > Hi Michael,
> > 
> > On Thursday 09 June 2016 01:02 PM, nore...@ellerman.id.au wrote:
> > > 
> > > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31
> > > 
> > > http://kisskb.ellerman.id.au/kisskb/buildresult/12713783/
> > > 
> > > Commit:   Add linux-next specific files for 20160609
> > >   8f6027f7e808ed7c1fd8c8d37fc7a5076c683c4f
> > > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
> > > 
> > > Possible errors
> > > ---
> > > 
> > > {standard input}:18606: Error: Instruction with long immediate data in 
> > > delay slot
> > > make[2]: *** [block/cfq-iosched.o] Error 1
> > > make[1]: *** [block] Error 2
> > > make: *** [sub-make] Error 2
> > This problem has been fixed in tools since - can you switch to a newer 
> > toolchain -
> > such as one released last month. @Alexey can you point Michael to right 
> > buildroot
> > version ?
> 
> Unfortunately our most recent tools were released a little bit too late to 
> get in
> the most recent Buildroot version and so you'll need to build your toolchain
> from Buildroot's master branch. Basically everything after the following 
> commit will
> should work: 
> https://git.busybox.net/buildroot/commit/?id=caf515e25e699eb306d0b24986734790de80af28

OK thanks.

I'll try and get it build next week. Ping me if I forget.

cheers


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

Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31

[Alexey Brodkin]

Hi Michael,

On Thu, 2016-06-09 at 14:02 +0530, Vineet Gupta wrote:
> Hi Michael,
> 
> On Thursday 09 June 2016 01:02 PM, nore...@ellerman.id.au wrote:
> > 
> > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31
> > 
> > http://kisskb.ellerman.id.au/kisskb/buildresult/12713783/
> > 
> > Commit:   Add linux-next specific files for 20160609
> >   8f6027f7e808ed7c1fd8c8d37fc7a5076c683c4f
> > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
> > 
> > Possible errors
> > ---
> > 
> > {standard input}:18606: Error: Instruction with long immediate data in 
> > delay slot
> > make[2]: *** [block/cfq-iosched.o] Error 1
> > make[1]: *** [block] Error 2
> > make: *** [sub-make] Error 2
> This problem has been fixed in tools since - can you switch to a newer 
> toolchain -
> such as one released last month. @Alexey can you point Michael to right 
> buildroot
> version ?

Unfortunately our most recent tools were released a little bit too late to get 
in
the most recent Buildroot version and so you'll need to build your toolchain
from Buildroot's master branch. Basically everything after the following commit 
will
should work: 
https://git.busybox.net/buildroot/commit/?id=caf515e25e699eb306d0b24986734790de80af28

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