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

2016-05-25 Thread Mark Brown
On Wed, May 25, 2016 at 11:49:12AM +0100, Jose Abreu wrote:

> 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?

We are in the merge window.  No new non-bugfix patches will be merged
until the merge window ends, most likely sometime this weekend.


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

[PATCH] arc: Get rid of root core-frequency property

2016-05-25 Thread Alexey Brodkin
Now when we switched to usage of real clk devices for CPU core
frequency those root properties make no sense any longer.
Se we're just getting rid of them here to not confuse readers of
our .dts files.

Signed-off-by: Alexey Brodkin 
Cc: Christian Ruppert 
Cc: Noam Camus 
---
 arch/arc/boot/dts/abilis_tb100.dtsi| 2 --
 arch/arc/boot/dts/abilis_tb101.dtsi| 2 --
 arch/arc/boot/dts/axc001.dtsi  | 1 -
 arch/arc/boot/dts/axc003.dtsi  | 1 -
 arch/arc/boot/dts/axc003_idu.dtsi  | 1 -
 arch/arc/boot/dts/eznps.dts| 1 -
 arch/arc/boot/dts/nsim_700.dts | 1 -
 arch/arc/boot/dts/nsimosci.dts | 1 -
 arch/arc/boot/dts/nsimosci_hs.dts  | 1 -
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 1 -
 arch/arc/boot/dts/skeleton.dtsi| 1 -
 arch/arc/boot/dts/skeleton_hs.dtsi | 1 -
 arch/arc/boot/dts/skeleton_hs_idu.dtsi | 1 -
 arch/arc/boot/dts/vdk_axc003.dtsi  | 1 -
 arch/arc/boot/dts/vdk_axc003_idu.dtsi  | 1 -
 15 files changed, 17 deletions(-)

diff --git a/arch/arc/boot/dts/abilis_tb100.dtsi 
b/arch/arc/boot/dts/abilis_tb100.dtsi
index 3942634..02410b2 100644
--- a/arch/arc/boot/dts/abilis_tb100.dtsi
+++ b/arch/arc/boot/dts/abilis_tb100.dtsi
@@ -23,8 +23,6 @@
 
 
 / {
-   clock-frequency = <5>;  /* 500 MHZ */
-
soc100 {
bus-frequency   = <1>;
 
diff --git a/arch/arc/boot/dts/abilis_tb101.dtsi 
b/arch/arc/boot/dts/abilis_tb101.dtsi
index b046722..f9e7686 100644
--- a/arch/arc/boot/dts/abilis_tb101.dtsi
+++ b/arch/arc/boot/dts/abilis_tb101.dtsi
@@ -23,8 +23,6 @@
 
 
 / {
-   clock-frequency = <5>;  /* 500 MHZ */
-
soc100 {
bus-frequency   = <1>;
 
diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 3e02f15..6ae2c47 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -15,7 +15,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <75000>;  /* 750 MHZ */
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index 378e455..14df46f 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -14,7 +14,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <9000>;
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 64c94b2..3d6cfa3 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -14,7 +14,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <9000>;
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/eznps.dts b/arch/arc/boot/dts/eznps.dts
index b89f6c3..1e0d225 100644
--- a/arch/arc/boot/dts/eznps.dts
+++ b/arch/arc/boot/dts/eznps.dts
@@ -18,7 +18,6 @@
 
 / {
compatible = "ezchip,arc-nps";
-   clock-frequency = <8333>;   /* 83.33 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <>;
diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
index 5d5e373..6397051 100644
--- a/arch/arc/boot/dts/nsim_700.dts
+++ b/arch/arc/boot/dts/nsim_700.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsim";
-   clock-frequency = <8000>;   /* 80 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index b5b060a..763d66c 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci";
-   clock-frequency = <2000>;   /* 20 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 325e730..4eb97c5 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci_hs";
-   clock-frequency = <2000>;   /* 20 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci_hs_idu.dts 
b/arch/arc/boot/dts/nsimosci_hs_idu.dts
index ee03d71..853f897 100644
--- a/arch/arc/boot/dts/nsimosci_hs_idu.dts
+++ b/arch/arc/boot/dts/nsimosci_hs_idu.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci_hs";
-   clock-frequency = <500>;/* 5 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/skeleton.dtsi b/arch/arc/boot/dts/skeleton.dtsi
index 3a10cc6..65808fe 100644
--- a/arch/arc/boot/dts/skeleton.dtsi
+++ b/arch/arc/boot/dts/skeleton.dtsi
@@ 

ARC stable backport request

2016-05-25 Thread Vineet Gupta
Hi,

Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler mnemonic".
Newer binutils don't like ASL instruction and fail to build kernels prior to 
v4.4
which added this fix.

Thx,
-Vineet

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


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

2016-05-25 Thread 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

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


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

2016-05-25 Thread 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

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