[linux-sunxi] Re: [RFC 0/2] A33 SPI support

2016-09-22 Thread Siarhei Siamashka 
Hello Karsten,

On Sun,  4 Sep 2016 18:53:13 +0200
Karsten Merker  wrote:

> Hello everybody,
> 
> during the mainlining discussion in the Olimex blog at
> https://olimex.wordpress.com/2016/08/30/free-electrons-add-mainline-linux-kernel-support-for-the-a13-allwinner-vpu/#comments
> the topic of A33 SPI support came up.  Chen-Yu and Siarhei have
> pointed out that the chances are good that the A33 can work with
> the already existing SPI drivers and that simply nobody has taken
> a look at those in the context of the A33 yet - so I have taken
> that as an inspiration to take a look :-).

Yes, probably nobody just had an A33 board with SPI pins on an
expansion header. The A33 SoC is primarily used in tablets.

> From the description in the docs published by Allwinner, the
> A23/A33 SPI controller is clearly derived from the one in the
> A31, but it is not completely identical.  The biggest difference
> is that the RX and TX FIFOs on the A23/A33 are only 64 Bytes deep
> while they are 128 Bytes deep on the A31. Documentation source:
> 
> Page 463 of the A33 manual:
> https://github.com/allwinner-zh/documents/raw/master/A33/A33%20user%20manual%20release%201.1.pdf
> 
> Page 889 of the A31 manual:
> https://github.com/allwinner-zh/documents/raw/master/A31/A31_User_Manual_v1.3_20150510.pdf
> 
> The current spi-sun6i driver hardcodes the FIFO depth to 128
> Bytes, so that needs to be changed depending on the SoC type.
> 
> Another difference is an additional configuration option
> influencing the signal sampling on the A23/A33.  This is handled
> by bit 13 of the SPI_INTCTL register.  The description states:
> 
>   "Master Sample Data Mode
>1-Normal Sample Mode
>0-Delay Sample Mode
>In Normal Sample Mode,SPI Master samples the data at
>the correct edge for each SPI mode.
>In Delay Sample Mode,SPI master samples data at the
>edge that is half cycle delayed by the correct edge defined
>in respective SPI mode."
> 
> The manual states that "Delay Sample Mode" is the default, which
> sounds a bit strange to me.  Can somebody with a deeper knowledge
> of SPI comment on that?
> 
> There are some additional test modes on the A23/33 compared to the A31,
> but those should be irrelevant for normal operations.
> 
> Following are two RFC patches based on Maxime Ripard's sunxi/for-next
> branch at
> 
>   
> https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next
> 
> that modify the spi-sun6i driver to handle different FIFO depths and add the
> relevant nodes (clock, pinctrl, spi0 controller) to the A23/A33 dtsi files. 

> Please note that this is largely untested as I currently don't have any
> A23/A33 hardware (an A33 board is on the way to me but will probably take
> some time to arrive).  All I can say at the moment is that the code
> compiles.  I would apprechiate very much if people could take a look at it
> and provide feedback, and if somebody has appropriate hardware, I would
> welcome very much if you could subject the code to some practical tests.

Well, basically it is really difficult to get people interested in
spending their time to look at this code at this point :-)

Please first test it on real hardware when the hardware arrives. And
then submit patches to the appropriate mailing list.

> Btw, while checking the docs I have stumbled over one thing that strikes me
> as rather strange: the A23/A33 has two SPI controllers (SPI0 and SPI1), but
> there is no documented pinmux that makes SPI1 available on any pins, so SPI1
> appears to be completely useless?
> 
> Regards,
> Karsten
> 
> 
> Karsten Merker (2):
>   spi: sunxi: Add Allwinner A23/A33 support to spi-sun6i
>   ARM: dts: sun8i: Add SPI support to the Allwinner A23/A33 dtsi.
> 
>  .../devicetree/bindings/spi/spi-sun6i.txt  |  6 ++-
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi   | 38 +++
>  arch/arm/boot/dts/sun8i-a23.dtsi   | 12 ++
>  arch/arm/boot/dts/sun8i-a33.dtsi   | 12 ++
>  drivers/spi/spi-sun6i.c| 43 
> +++---
>  5 files changed, 103 insertions(+), 8 deletions(-)
> 



-- 
Best regards,
Siarhei Siamashka

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low

2016-09-22 Thread Siarhei Siamashka 
On Thu, 22 Sep 2016 23:52:52 +0200
Danny Milosavljevic  wrote:

> Hello,
> 
> when using SPI on Allwinner A20 with CPOL=1 and CPHA=1 with Linux 4.8.0-rc6 
> Psychotic Stoned Sheep I see a weird dip in the beginning (which also 
> confuses the slave) on the SCLK line right when SSEL goes low - see 
> attachment.
> 
> The lines are, starting from the top, SCLK MOSI MISO SSEL.
> 
> I'm using spidev.
> 
> Did anyone see this problem before?

Hi,

I'm not sure, but something like this might be somehow related:
https://patchwork.kernel.org/patch/7960811/

As a random thing to check, I would also advise to verify the
pull-up/pull-down settings for the SCLK pin.

And maybe as another test, change the driver to automatically
drive the SSEL pin instead of doing this manually.

Also try to contact the author of the SPI driver via the
mainline kernel mailing list.

-- 
Best regards,
Siarhei Siamashka

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64

2016-09-22 Thread Siarhei Siamashka 
On Mon, 19 Sep 2016 09:07:39 -0700 (PDT)
TsvetanUsunov  wrote:

> Hi,
> 
> We make our final touch of A64-OLinuXino PCB and there we add option eMMC 
> Flash to work on dual voltages 1.8V and 3.3V.
> The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that when 
> A64 boots and AXP803 is not initialized it outputs default 0.8V then after 
> initialization driver takes care to drive it  1.8V or 3.3V.
> This makes impossible to boot from eMMC which is not good. We now think for 
> solution which to drive eMMC at 3.3V initially when AXP803 output is below 
> 1.8V but this adds unnecessary hardware complexity.
> For hardware point of view it will be much more simplier if dedigated A64 
> GPIO is used and initially is pulled down and after AXP803 is initialized 
> is pulled up.
> How would you suggest us to implement it? Will this additional GPIO create 
> troubles in eMMC driver philosophy?
> For the SDMMC we are still hesitating what to do as we don't know if the 
> card which will be inserted will support low voltage and higher speeds at 
> all. Also eMMC Flash and SDMMC card should be driven by separate voltages, 
> as they may work in any combinations.
> This means we need another AXP803 LDO and another GPIO for the SDMMC card.
> 
> By the way the current eMMC from Micron we use has 11MB Write speed no 
> matter what is the voltage and this is written in the datasheet, so maybe 
> we should switch and add this dual voltage to the SD MMC where someone 
> could use SD MMC card supporting higher clocks?
> 
> I would love to hear your opinion.

Hi,

I have only skimmed through the JEDEC MMC standard, but got an
impression that it is perfectly safe to run dual voltage cards at
1.8V voltage all the time. At least that's how I'm interpreting
the first and the last paragraphs of the "7.4.2 Operating voltage
range validation" section of the JESD84-A44 MMC Version 4.4 standard.

Basically, it looks like when you are running with the 1.8V
voltage, you can do everything that is possible with 3.3V and
it just additionally allows higher speed modes (HS200).
Presumably also consuming less power.

The init sequence also involves starting the card with 3.3V. Then doing
the voltage negotiation. Then powering the card off, switching to 1.8V
and basically repeating the same steps. But if the card is 1.8V
capable, then the initial negotiation step looks redundant. It can
also run at 1.8V instead of 3.3V without affecting anything.

Thus it seems to be a ridiculous idea to implement the runtime
1.8V/3.3V voltage switching for a dual voltage capable eMMC chip
that is soldered to the PCB. You can probably just connect it to
a fixed 1.8V voltage regulator and be done with that.

The voltage switching and negotiation seems to be only useful
for removable SD cards, where you don't have any idea if the
connected SD card actually supports 1.8V or not.

But I'm not an eMMC expert, so please correct me if I got
everything wrong.

-- 
Best regards,
Siarhei Siamashka

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low

2016-09-22 Thread Danny Milosavljevic 
Hello,

when using SPI on Allwinner A20 with CPOL=1 and CPHA=1 with Linux 4.8.0-rc6 
Psychotic Stoned Sheep I see a weird dip in the beginning (which also confuses 
the slave) on the SCLK line right when SSEL goes low - see attachment.

The lines are, starting from the top, SCLK MOSI MISO SSEL.

I'm using spidev.

Did anyone see this problem before?

Regards,
   Danny

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] custom bootloader/OS + registers question + IPI

2016-09-22 Thread Mark L . 
Andre,

I took some time to answer because I documented myself further. I like to be 
precise.

You are right, this is the bit I missed: the platform seeks for a sd card to 
boot before looking for the on board NAND.
So, from here, I can add my bootloader on the sdcard and let the fun start (no 
need to flash the NAND).
I have looked at the u-boot code already, and I understand pretty well how this 
SoC behaves now.

As for the IPIs, thanks, I will ditch the msgbox altogether and use the GIC 
only.

Super, Andre, thanks again.

Cheers

-- 
Mark


21.09.2016, 15:03, "Andre Przywara" :
> Hi,
>
> On 21/09/16 11:27, Mark L. wrote:
>>  Hi,
>>
>>  The plan:
>>  1) erase && replace the bootloader with a custom one on a H3 SoC (much 
>> simpler/faster/secure and fitting the need perfectly)
>>  2) create a custom small OS, replacing the AMP default behavior with a SMP 
>> one: basically matching the address spaces between cpus and just send the 
>> other cores some work to do from cpu0 ( they won't have an operating system 
>> and basically wait for CPU0 events -> hence the new bootloader as well).
>>
>>  Questions:
>>  1) H3 datasheet: are all the registers there or are there some undocumented 
>> ones? (to burn the new bootloader, that is critical)
>
> Not everything is documented, but you can take a look at U-Boot, that
> should cover everything you need.
> But I wonder why you want to replace U-Boot in the first place, if you
> disable PSCI (and UEFI) it shouldn't be in the way after you started
> your OS. And although U-Boot is usually used with Linux, it is actually
> OS agnostic, so launching "something else" from is definitely a
> supported use case. AFAIK the arisc isn't used these days with an
> upstream Linux software setup.
>
> Also have you checked ar100-info [1]? That should give you the bare
> minimum in terms of initialization to launch your custom code.
>
> Rewriting a boot loader (which would involve DRAM initialization) is
> pretty tedious and complicated, so I'd strongly recommend against it.
>
> Also what do you mean exactly with "burn a bootloader"? On most
> Allwinner boards we use upstream U-Boot exclusively (no Allwinner
> provided code), so many people "burn" a boot loader already. Also you
> can put it on an SD card, which I wouldn't exactly call "burning".
>
>>  2) CPU IPIs: we have a msgbox on this platform according to the datasheet. 
>> But how do you send a message from CPU0 to CPU3 or CPU2 to CPU1, without 
>> interrupting the unconcerned cpus (respectively {CPU1,CPU2} and {CPU0,CPU3} 
>> )?
>>  Because the datasheet talks about user0 and user1 but no cpuIDs are 
>> involved and it is not clear to me.
>
> So since you mentioned the msgbox and AMP above, I take it you want to
> have the OpenRISC and the ARM cores working together?
> Using the msgbox you can only send messages from the ARM cores to the
> OpenRISC and vice versa. Sending a message from ARM CPU0 to CPU1, for
> instance, doesn't work this way (I tried this on the A64), at least you
> won't see the IRQ.
> But if you want to notify one ARM core from another, just use the GIC
> and SGIs, you can target single cores or group of cores with this one.
> If you target the OpenRISC, you can use the msgbox.
> Targeting a specific ARM core from the OpenRISC is not easily possible,
> AFAICT, since there is only one msgbox IRQ. You can set the affinity of
> this IRQ to an ARM core, but this must be done from the ARM cores
> beforehand and cannot be influenced from the OpenRISC (as the GIC isn't
> accessible from the OpenRISC).
>
> Cheers,
> Andre.
>
> [1] https://github.com/ssvb/ar100-info
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Fwd: nasty recruiter bs.

2016-09-22 Thread Luc Verhaegen 
On Wed, Sep 21, 2016 at 05:20:40PM -0400, rani rautela wrote:
> Hi
> 
> Hope you are doing fine. . !!!
> 

And there goes your posting rights.

Luc Verhaegen.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v5 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i

2016-09-22 Thread Maxime Ripard 
Hi,

On Thu, Sep 22, 2016 at 09:13:10AM +0200, Danny Milosavljevic wrote:
> ASoC: sun4i-codec: Introduce mechanism to detect sun7i and provide a
> different regmap different compared to sun4i Allwinner A10.
>  
> The controls will be extended in a forthcoming patch - it is necessary
> to distinguish between sun4i and sun7i controls because they have different
> registers.
>  
> Renamed SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and renamed
> SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
> are actually not present on Allwinner A10.
> 
> Handle quirks by regmap config and codec and select the correct quirks
> automatically.  

Usually, you would set the history of changes from one version to the
other here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v5 3/3] ASoC: sun4i-codec: Add custom regmap configs

2016-09-22 Thread Maxime Ripard 
On Thu, Sep 22, 2016 at 09:13:13AM +0200, Danny Milosavljevic wrote:
> The A20 has a few extra registers that the A10 doesn't have.
> Therefore, use different regmaps for A10 as compared to A20.
> 
> Signed-off-by: Danny Milosavljevic 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v5 2/3] ASoC: sun4i-codec: Rename some sun7i-only registers

2016-09-22 Thread Maxime Ripard 
On Thu, Sep 22, 2016 at 09:13:12AM +0200, Danny Milosavljevic wrote:
> Some of the registers defined in the driver are only usable on the
> A20. Rename these registers.
> 
> Signed-off-by: Danny Milosavljevic 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] [PATCH v5 2/3] ASoC: sun4i-codec: Rename some sun7i-only registers

2016-09-22 Thread Danny Milosavljevic 
Some of the registers defined in the driver are only usable on the
A20. Rename these registers.

Signed-off-by: Danny Milosavljevic 
---
 sound/soc/sunxi/sun4i-codec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index c2c0583..3b53b78 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,8 @@
 /* Other various ADC registers */
 #define SUN4I_CODEC_DAC_TXCNT  (0x30)
 #define SUN4I_CODEC_ADC_RXCNT  (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI(0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
 
 struct sun4i_codec {
struct device   *dev;
@@ -682,7 +682,7 @@ static const struct regmap_config sun4i_codec_regmap_config 
= {
.reg_bits   = 32,
.reg_stride = 4,
.val_bits   = 32,
-   .max_register   = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+   .max_register   = SUN7I_CODEC_AC_MIC_PHONE_CAL,
 };
 
 static const struct of_device_id sun4i_codec_of_match[] = {

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i

2016-09-22 Thread Danny Milosavljevic 
ASoC: sun4i-codec: Introduce mechanism to detect sun7i and provide a
different regmap different compared to sun4i Allwinner A10.
 
The controls will be extended in a forthcoming patch - it is necessary
to distinguish between sun4i and sun7i controls because they have different
registers.
 
Renamed SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and renamed
SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
are actually not present on Allwinner A10.

Handle quirks by regmap config and codec and select the correct quirks
automatically.  

Danny Milosavljevic (3):
  ASoC: sun4i-codec: rename "sun4i_codec_widgets" to
"sun4i_codec_controls" for consistency with the struct field name.
  ASoC: rename "SUN4I_CODEC_SYS_VERI" to "SUN7I_CODEC_AC_DAC_CAL";
rename "SUN4I_CODEC_AC_MIC_PHONE_CAL" to
"SUN7I_CODEC_AC_MIC_PHONE_CAL".
  ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20
variants.

 sound/soc/sunxi/sun4i-codec.c | 50 +++
 1 file changed, 41 insertions(+), 9 deletions(-)

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 3/3] ASoC: sun4i-codec: Add custom regmap configs

2016-09-22 Thread Danny Milosavljevic 
The A20 has a few extra registers that the A10 doesn't have.
Therefore, use different regmaps for A10 as compared to A20.

Signed-off-by: Danny Milosavljevic 
---
 sound/soc/sunxi/sun4i-codec.c | 38 +++---
 1 file changed, 35 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 3b53b78..e047ec0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -682,12 +682,37 @@ static const struct regmap_config 
sun4i_codec_regmap_config = {
.reg_bits   = 32,
.reg_stride = 4,
.val_bits   = 32,
+   .max_register   = SUN4I_CODEC_ADC_RXCNT,
+};
+
+static const struct regmap_config sun7i_codec_regmap_config = {
+   .reg_bits   = 32,
+   .reg_stride = 4,
+   .val_bits   = 32,
.max_register   = SUN7I_CODEC_AC_MIC_PHONE_CAL,
 };
 
+struct sun4i_codec_quirks {
+   const struct regmap_config *regmap_config;
+};
+
+static const struct sun4i_codec_quirks sun4i_codec_quirks = {
+   .regmap_config = _codec_regmap_config,
+};
+
+static const struct sun4i_codec_quirks sun7i_codec_quirks = {
+   .regmap_config = _codec_regmap_config,
+};
+
 static const struct of_device_id sun4i_codec_of_match[] = {
-   { .compatible = "allwinner,sun4i-a10-codec" },
-   { .compatible = "allwinner,sun7i-a20-codec" },
+   {
+   .compatible = "allwinner,sun4i-a10-codec",
+   .data = _codec_quirks,
+   },
+   {
+   .compatible = "allwinner,sun7i-a20-codec",
+   .data = _codec_quirks,
+   },
{}
 };
 MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
@@ -760,6 +785,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
 {
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+   const struct sun4i_codec_quirks *quirks;
struct resource *res;
void __iomem *base;
int ret;
@@ -777,8 +803,14 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
 
+   quirks = of_device_get_match_data(>dev);
+   if (quirks == NULL) {
+   dev_err(>dev, "Failed to determine the quirks to use\n");
+   return -ENODEV;
+   }
+
scodec->regmap = devm_regmap_init_mmio(>dev, base,
-_codec_regmap_config);
+  quirks->regmap_config);
if (IS_ERR(scodec->regmap)) {
dev_err(>dev, "Failed to create our regmap\n");
return PTR_ERR(scodec->regmap);

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v5 1/3] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency

2016-09-22 Thread Danny Milosavljevic 
ASoC: sun4i-codec: Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.

Signed-off-by: Danny Milosavljevic 
---
 sound/soc/sunxi/sun4i-codec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 0e19c50..c2c0583 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
 
 static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
 
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
   SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
   sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route 
sun4i_codec_codec_dapm_routes[] = {
 
 static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
-   .controls   = sun4i_codec_widgets,
-   .num_controls   = ARRAY_SIZE(sun4i_codec_widgets),
+   .controls   = sun4i_codec_controls,
+   .num_controls   = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets   = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets   = 
ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes= sun4i_codec_codec_dapm_routes,

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.