Re: [linux-sunxi] [PATCH v3 3/9] ASoC: sun8i-codec-analog: add support for V3s SoC
On Wed, May 24, 2017 at 6:06 PM, Icenowy Zheng wrote: > From: Icenowy Zheng > > The V3s SoC features an analog codec with headphone support but without > mic2 and linein. > > Add support for it. > > Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai Mark, please hold off on applying this patch until the comments from the previous patch have been addressed. They should be applied in order. > --- > Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt | 1 + > sound/soc/sunxi/sun8i-codec-analog.c | 9 + Also, is there a preference for splitting out device tree binding changes from driver changes? Thanks ChenYu -- 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] [PATCH v3 2/9] ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s
On Wed, May 24, 2017 at 6:06 PM, Icenowy Zheng wrote:
> Allwinner V3s has an analog codec without MIC2 and Line In, which will
> need a special set of mixer controls/widgets/routes, otherwise meaningless
> controls will be exported to userspace and confuse the user.
>
> Add the special set, and use it when the SoC has no MIC2 and Line In.
>
> Signed-off-by: Icenowy Zheng
> ---
> New patch in v3.
>
> sound/soc/sunxi/sun8i-codec-analog.c | 97
> +++-
> 1 file changed, 96 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec-analog.c
> b/sound/soc/sunxi/sun8i-codec-analog.c
> index edcc3eb7cd9a..4c34a12b3739 100644
> --- a/sound/soc/sunxi/sun8i-codec-analog.c
> +++ b/sound/soc/sunxi/sun8i-codec-analog.c
> @@ -219,6 +219,22 @@ static const struct snd_kcontrol_new
> sun8i_codec_mixer_controls[] = {
> SUN8I_ADDA_LOMIXSC_MIC2, 1, 0),
> };
>
> +/* mixer controls */
> +static const struct snd_kcontrol_new sun8i_v3s_codec_mixer_controls[] = {
> + SOC_DAPM_DOUBLE_R("DAC Playback Switch",
> + SUN8I_ADDA_LOMIXSC,
> + SUN8I_ADDA_ROMIXSC,
> + SUN8I_ADDA_LOMIXSC_DACL, 1, 0),
> + SOC_DAPM_DOUBLE_R("DAC Reversed Playback Switch",
> + SUN8I_ADDA_LOMIXSC,
> + SUN8I_ADDA_ROMIXSC,
> + SUN8I_ADDA_LOMIXSC_DACR, 1, 0),
> + SOC_DAPM_DOUBLE_R("Mic1 Playback Switch",
> + SUN8I_ADDA_LOMIXSC,
> + SUN8I_ADDA_ROMIXSC,
> + SUN8I_ADDA_LOMIXSC_MIC1, 1, 0),
> +};
> +
> /* ADC mixer controls */
> static const struct snd_kcontrol_new sun8i_codec_adc_mixer_controls[] = {
> SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
> @@ -243,6 +259,22 @@ static const struct snd_kcontrol_new
> sun8i_codec_adc_mixer_controls[] = {
> SUN8I_ADDA_LADCMIXSC_MIC2, 1, 0),
> };
>
> +/* ADC mixer controls */
> +static const struct snd_kcontrol_new sun8i_v3s_codec_adc_mixer_controls[] = {
> + SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
> + SUN8I_ADDA_LADCMIXSC,
> + SUN8I_ADDA_RADCMIXSC,
> + SUN8I_ADDA_LADCMIXSC_OMIXRL, 1, 0),
> + SOC_DAPM_DOUBLE_R("Mixer Reversed Capture Switch",
> + SUN8I_ADDA_LADCMIXSC,
> + SUN8I_ADDA_RADCMIXSC,
> + SUN8I_ADDA_LADCMIXSC_OMIXRR, 1, 0),
> + SOC_DAPM_DOUBLE_R("Mic1 Capture Switch",
> + SUN8I_ADDA_LADCMIXSC,
> + SUN8I_ADDA_RADCMIXSC,
> + SUN8I_ADDA_LADCMIXSC_MIC1, 1, 0),
> +};
> +
> /* volume / mute controls */
> static const DECLARE_TLV_DB_SCALE(sun8i_codec_out_mixer_pregain_scale,
> -450, 150, 0);
> @@ -292,8 +324,9 @@ static const struct snd_soc_dapm_widget
> sun8i_codec_common_widgets[] = {
> /* Mic input path */
> SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
> SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
> +};
>
> - /* Mixers */
> +static const struct snd_soc_dapm_widget sun8i_codec_mixer_widgets[] = {
> SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
>SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
>sun8i_codec_mixer_controls,
> @@ -312,10 +345,31 @@ static const struct snd_soc_dapm_widget
> sun8i_codec_common_widgets[] = {
>ARRAY_SIZE(sun8i_codec_adc_mixer_controls)),
> };
>
> +static const struct snd_soc_dapm_widget sun8i_v3s_codec_mixer_widgets[] = {
> + SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
> + SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
> + sun8i_v3s_codec_mixer_controls,
> + ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
> + SND_SOC_DAPM_MIXER("Right Mixer", SUN8I_ADDA_DAC_PA_SRC,
> + SUN8I_ADDA_DAC_PA_SRC_RMIXEN, 0,
> + sun8i_v3s_codec_mixer_controls,
> + ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
> + SND_SOC_DAPM_MIXER("Left ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
> + SUN8I_ADDA_ADC_AP_EN_ADCLEN, 0,
> + sun8i_v3s_codec_adc_mixer_controls,
> + ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
> + SND_SOC_DAPM_MIXER("Right ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
> + SUN8I_ADDA_ADC_AP_EN_ADCREN, 0,
> + sun8i_v3s_codec_adc_mixer_controls,
> + ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
> +};
> +
> static const struct snd_soc_dapm_route sun8i_codec_common_routes[] = {
> /* Microphone Routes */
> { "Mic1 Amplifier", NULL, "MI
[linux-sunxi] Re: [PATCH v2 4/4] sunxi: video: Add H3/H5 TV out driver
Hi, Dne torek, 23. maj 2017 ob 22:22:14 CEST je Maxime Ripard napisal(a): > Hi Jernej, > > On Mon, May 22, 2017 at 08:49:57PM +0200, Jernej Škrabec wrote: > > Dne ponedeljek, 22. maj 2017 ob 09:35:56 CEST je Maxime Ripard napisal(a): > > > On Fri, May 19, 2017 at 05:41:17PM +0200, Jernej Skrabec wrote: > > > > This commit adds support for TV (composite) output. > > > > > > > > Because there is no mechanism to select TV standard, PAL is > > > > hardcoded. > > > > > > I'd rather use a consistent mechanism with the old driver (even if we > > > only support PAL right now and reject any other option), and using > > > composite-pal as monitor. > > > > I have few arguments against that: > > > > 1. Code for parsing that env variable is in videomodes.[c|h], which is > > clearly a part of an older video framework (ctfb). I didn't want to > > include any legacy code. > > > > 2. Even if this code is used for parsing, it would bring a lot of > > confusion. For now, we can say that docs/README.video does not apply to > > H3 and newer SoCs. If we implement this only partially, we would need to > > describe in details which of each setting is honored with the new driver > > and which not. Even then, a lot of users would skip that description and > > complain anyway. > The issue with this, and we've been bitten very hard on this one with > the CHIP, is that you don't really have a clear majority on that > one. If you support only PAL, half the world will be left out, and > same thing with NTSC (for some reason, we never needed to support the > less common ones like PAL-M or NTSC-J, but that just might be because > it never really sold that well in those countries, I don't have any > numbers on that). > > The point is, if you just hardcode PAL for now, you will have half > your users complain, and then, when we will introduce NTSC support > eventually, we'll have to introduce some mechanism to switch between > the two, then we'll probably break the behaviour our users relied on > before, making the other half of our users pissed. > > I'm not sure this is something we should just discard, or at least the > second part. Having the selection mechanism in place, even if we don't > support all the settings and just report an error in the logs in such > a case address the latter issue. > > You'll also need to address how to setup the overscan, since this is > really something you want to have very quick. Ok, I'm prepared to tackle this. Do you think it is worth to delay driver merge? > > > 3. If anything is done in this direction, I think that it is better > > to extend DM video framework so other drivers would benefit from > > that work too. > > That makes sense, but again, this is a pre-requisite for me. And it's > not that hard to support the video modelines with a device model > driver, Linux does it, and you have a string identifier at the > beginning of it. It just has to be deterministic, but I don't think > this is an issue with U-Boot's DM. > Ok, so how do you think we should implement this? If only composite modes are supported in the string, someone might try to set hdmi monitor. Should we just ignore such settings and maybe print a warning? Also the question for Simon, how should I merge code for parsing video string from drivers/video/videomodes.c to DM video in a way to be useful to most drivers? I guess this is the first time to support analog video output in DM video driver and there are some things missing such as a way to select TV standard and define overscan. Or alternatively, I could make just quick edit to sunxi_tve.c driver and directly use old functions as they are. That way we could get something working very quickly, but I don't like much such approach. Best regards, Jernej -- 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] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
Hi, Dne sreda, 24. maj 2017 ob 10:25:46 CEST je Icenowy Zheng napisal(a): > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 写到: > >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote: > >> 在 2017-05-23 20:53，Maxime Ripard 写道： > >> > >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: > >> > > Hi, > >> > > > >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai > > > >napisal(a): > >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec > > > > > > > >> > > wrote: > >> > > > > Hi, > >> > > > > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng > > > >napisal(a): > >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > > > > >> > > > > electrons.com> 写到: > >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng > > > >wrote: > >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in > > > >earlier > > > >> > > > >> >SoCs, > >> > > > >> > > >> > > > >> >> but with some different points about clocks: > >> > > > >> >> - It has a mod clock and a bus clock. > >> > > > >> >> - The mod clock must be at a fixed rate to generate > > > >signal. > > > >> > > > >> >Why? > >> > > > >> > >> > > > >> It's experiment result by Jernej. > >> > > > >> > >> > > > >> The clock rates in BSP kernel is also specially designed > >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > >> > > > > > >> > > > > My experiments and search through BSP code showed that TVE > > > >seems to have > > > >> > > > > additional fixed predivider 8. So if you want to generate 27 > > > >MHz clock, > > > >> > > > > unit has to be feed with 216 MHz. > >> > > > > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a > > > >bit low for > > > >> > > > > DE2, > >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to > > > >generate 216 MHz. > > > >> > > > > This clock is then divided by 8 internaly to get final 27 > > > >MHz. > > > >> > > > > Please note that I don't have any hard evidence to support > > > >that, only > > > >> > > > > experimental data. However, only that explanation make sense > > > >to me. > > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which > > > >both use 27 MHz > > > >> > > > > base clock. Further experiments are needed to check if there > > > >is any > > > >> > > > > possibility to have other resolutions by manipulating clocks > > > >and give > > > >> > > > > other proper settings. I plan to do that, but not in very > > > >near future. > > > >> > > > You only have composite video output, and those are the only 2 > > > >standard > > > >> > > > resolutions that make any sense. > >> > > > >> > > Right, other resolutions are for VGA. > >> > > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I > > > >think > > > >> > > that H3 TVE > >> > > unit is something in between. R40 TVE has a setting to select "up > >> > > sample". > >> > > >> > That might be just another translation of oversampling :) > >> > > >> > I didn't know it could be applied to composite signals though, but > > > >I > > > >> > guess this is just another analog signal after all. > >> > > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP > >> > > driver on R40 > >> > > has this setting enabled only for PAL and NTSC and it is always > > > >216 > > > >> > > MHz. I > >> > > think that H3 may have this hardwired to 216 MHz and this would > > > >be > > > >> > > the reason > >> > > why 216 MHz is needed. > >> > > > >> > > Has anyone else any better explanation? > >> > > >> > That's already a pretty good one. > >> > > >> > Either way, wether this is upsampling, oversampling or just a > >> > pre-divider, this can and should be dealt with in the mode_set > >> > callback, and not in the probe. > >> > >> I got a better idea -- let TVE driver have the CLK_TVE as an > >> input and create a subclock output with divider 16, and feed this > >> subclock to TCON lcd-ch1. > >> > >> This is a model of the real hardware -- the clock divider is in > >> TVE, not TCON. If we are talking about HW divider, it is 8 (216 / 27 = 8). Slightly offtopic, reason why DE2 is hardcoded to 432 might be that for 4K resolution you need at least 297 MHz. So next dividable frequency is taken (432 MHz). That way you can have 4K HDMI display and composite TV connected at the same time, although this sounds a bit weird. Best regards, Jernej > > > >That's definitely not a good representation of the hardware. There's > >one clock, it goes to the TCON, period. > > No, I still think it goes to the TVE as: > > 1. it's named TVE in datasheet. > 2. Generating signal with such a low resolution but such > a high dotclock is not a good situation. > > >However, the TV encoder has a constraint on that clock rate. This can > >be easily implemented using a custom encoder state where you'd set the > >multiplier to set on that clock, and the TCON will use it. > > > >Maxime -- You received this message b
Re: [linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low
在 2017-05-24 04:41，Danny Milosavljevic 写道： Next, I'll try to disable CS manual mode in drivers/spi/spi-sun4i.c and test - still with nothing but the resistor connected. Let's see... I've done that and it changed nothing wrt SCLK. Good to know... diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c index c5cd635..3e9e7b6 100644 --- a/drivers/spi/spi-sun4i.c +++ b/drivers/spi/spi-sun4i.c @@ -174,8 +174,9 @@ static void sun4i_spi_set_cs(struct spi_device *spi, bool enable) reg |= SUN4I_CTL_CS(spi->chip_select); /* We want to control the chip select manually */ - reg |= SUN4I_CTL_CS_MANUAL; + /* reg |= SUN4I_CTL_CS_MANUAL; */ +#if 0 if (enable) reg |= SUN4I_CTL_CS_LEVEL; else @@ -196,6 +197,7 @@ static void sun4i_spi_set_cs(struct spi_device *spi, bool enable) reg &= ~SUN4I_CTL_CS_ACTIVE_LOW; else reg |= SUN4I_CTL_CS_ACTIVE_LOW; +#endif sun4i_spi_write(sspi, SUN4I_CTL_REG, reg); } Please note that this can break the capability to use any GPIO as CS. -- 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 3/3] ARM: sun8i: v3s: add backlight device node for Lichee Pi Zero LCD
The 40-pin LCD connector on Lichee Pi Zero has backlight pins, which is
controlled by the PWM0 controller of the V3s SoC, and the controlling
part is on the board.
Add the PWM and backlight device nodes in the device tree file, but
leave them disabled, as they can only be useful when the LCD is
attached. The LCD device tree overlay files can enable these controllers
and make use of them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..e0721bf725d1 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -52,6 +52,14 @@
serial0 = &uart0;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 0>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ status = "disabled";
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -86,6 +94,12 @@
status = "okay";
};
+&pwm {
+ pinctrl-0 = <&pwm0_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins_a>;
pinctrl-names = "default";
--
2.12.2
--
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 2/3] ARM: sun8i: v3s: add PWM pinmux nodes
Allwinner V3s have two PWM channels, the first channel can be only at
PB4 pin, and the second channel PB5.
Add their pinmux configurations.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index bb080c4bd22c..db3328a2c89a 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -239,6 +239,16 @@
pins = "PC0", "PC1", "PC2", "PC3";
function = "spi0";
};
+
+ pwm0_pins: pwm0 {
+ pins = "PB4";
+ function = "pwm0";
+ };
+
+ pwm1_pins: pwm1 {
+ pins = "PB5";
+ function = "pwm1";
+ };
};
timer@01c20c00 {
--
2.12.2
--
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 1/3] ARM: sun8i: v3s: add PWM device node
As we have already the support for the PWM controller on V3s SoC, add
its device node in the SoC's DTSI file.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..bb080c4bd22c 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -255,6 +255,14 @@
interrupts = ;
};
+ pwm: pwm@1c21400 {
+ compatible = "allwinner,sun7i-a20-pwm";
+ reg = <0x01c21400 0x400>;
+ clocks = <&osc24M>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
lradc: lradc@1c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x400>;
--
2.12.2
--
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 2/2] ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC
Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.
Add pinctrl node for them.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3a06dc5b3746..81e5406661b4 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,15 @@
function = "i2c0";
};
+ lcd_rgb666_pins: lcd_rgb666 {
+ pins = "PE0", "PE1", "PE2", "PE3", "PE4",
+ "PE5", "PE6", "PE7", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15", "PE16", "PE17", "PE18", "PE19",
+ "PE23", "PE24";
+ function = "lcd";
+ };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
--
2.12.2
--
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 1/2] ARM: sun8i: v3s: add device nodes for DE2 display pipeline
Allwinner V3s SoC features a "Display Engine 2.0" with only one mixer
and only one TCON connected to this mixer, which have RGB LCD output.
Add device nodes for this display pipeline.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 83
1 file changed, 83 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..3a06dc5b3746 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -61,6 +61,12 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-v3s-display-engine";
+ allwinner,pipelines = <&mixer0>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -95,6 +101,83 @@
#size-cells = <1>;
ranges;
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun8i-v3s-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_DE>,
+<&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@110 {
+ compatible = "allwinner,sun8i-v3s-de2-mixer";
+ reg = <0x0110 0x10>;
+ clocks = <&display_clocks 0>,
+<&display_clocks 6>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks 0>;
+ assigned-clocks = <&display_clocks 6>;
+ assigned-clock-rates = <15000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ tcon0: lcd-controller@1c0c000 {
+ compatible = "allwinner,sun8i-v3s-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON0>,
+<&ccu CLK_TCON0>;
+ clock-names = "ahb",
+ "tcon-ch0";
+ clock-output-names = "tcon-pixel-clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ reset-names = "lcd";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
--
2.12.2
--
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 v3 0/9] Add support for the audio codec on Allwinner V3s
Fixed Arnd email now.. On Wed, May 24, 2017 at 04:10:08PM +0530, Vinod Koul wrote: > On Wed, May 24, 2017 at 06:05:58PM +0800, Icenowy Zheng wrote: > > Allwinner V3s features a audio codec with dedicated digital and analog > > parts, > > like the ones on A23/H3, but much simpler (lack of MIC2, LINE IN and MBIAS). > > > > Add support for it. > > > > In order to make the codec usable, DMA support is also added in this series. > > > > Patch 1 split out MBIAS in analog codec driver. > > > > Patch 2 prepared a set of objects that have MIC2 and LINEIN stripped out > > for V3s. > > > > Patch 3/4 adds support for V3s in analog/digital codec. > > > > Patch 5 add the gate bit as a common quirk of sun6i-dma driver, as V3s also > > needs it. > > > > Patch 6 really adds support for V3s in DMA engine. > > > > Patch 7/8/9 adds three parts of device tree: DMA engine, codec support > > and enable the codec for Lichee Pi Zero dock. > > > > Icenowy Zheng (9): > > ASoC: sun8i-codec-analog: split out mbias > > ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for > > V3s > > ASoC: sun8i-codec-analog: add support for V3s SoC > > ASoC: sun4i-codec: Add support for V3s codec > > dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk > > dmaengine: sun6i: support V3s SoC variant > > ARM: dts: sun8i: add DMA engine in V3s DTSI > > ARM: dts: sun8i: add audio codec support into V3s DTSI > > ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board > > And why do we need the cross tree submission?? I have asked before and was > met with silence! [1] > > Can you please split it up per subsystem to make it easy for everyone and > clearly spell out dependencies. > > [1]: https://www.spinics.net/lists/dmaengine/msg12884.html -- ~Vinod -- 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 v3 0/9] Add support for the audio codec on Allwinner V3s
On Wed, May 24, 2017 at 06:05:58PM +0800, Icenowy Zheng wrote: > Allwinner V3s features a audio codec with dedicated digital and analog parts, > like the ones on A23/H3, but much simpler (lack of MIC2, LINE IN and MBIAS). > > Add support for it. > > In order to make the codec usable, DMA support is also added in this series. > > Patch 1 split out MBIAS in analog codec driver. > > Patch 2 prepared a set of objects that have MIC2 and LINEIN stripped out > for V3s. > > Patch 3/4 adds support for V3s in analog/digital codec. > > Patch 5 add the gate bit as a common quirk of sun6i-dma driver, as V3s also > needs it. > > Patch 6 really adds support for V3s in DMA engine. > > Patch 7/8/9 adds three parts of device tree: DMA engine, codec support > and enable the codec for Lichee Pi Zero dock. > > Icenowy Zheng (9): > ASoC: sun8i-codec-analog: split out mbias > ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for > V3s > ASoC: sun8i-codec-analog: add support for V3s SoC > ASoC: sun4i-codec: Add support for V3s codec > dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk > dmaengine: sun6i: support V3s SoC variant > ARM: dts: sun8i: add DMA engine in V3s DTSI > ARM: dts: sun8i: add audio codec support into V3s DTSI > ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board And why do we need the cross tree submission?? I have asked before and was met with silence! [1] Can you please split it up per subsystem to make it easy for everyone and clearly spell out dependencies. [1]: https://www.spinics.net/lists/dmaengine/msg12884.html -- ~Vinod -- 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] [PATCH v3 1/9] ASoC: sun8i-codec-analog: split out mbias
On Wed, May 24, 2017 at 6:05 PM, Icenowy Zheng wrote: > From: Icenowy Zheng > > Allwinner V3s features an analog codec without MBIAS pin. > > Split out this part, in order to prepare for the V3s analog codec. > > Signed-off-by: Icenowy Zheng Reviewed-by: Chen-Yu Tsai -- 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] [PATCH v3 5/9] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk
On Wed, May 24, 2017 at 6:06 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng
>
> Originally we enable a special gate bit when the compatible indicates
> A23/33.
>
> But according to BSP sources and user manuals, more SoCs will need this
> gate bit.
>
> So make it a common quirk configured in the config struct.
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v3:
> - Stripped out the A83T gate bit set.
>
> drivers/dma/sun6i-dma.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..69840cf6fe98 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -101,6 +101,11 @@ struct sun6i_dma_config {
> u32 nr_max_channels;
> u32 nr_max_requests;
> u32 nr_max_vchans;
> + /*
> +* The hardware has a special gate bit, which is needed to
> +* be enabled for some SoCs with a sun6i-style DMA engine.
> +*/
> + bool gate_needed;
The user manual identifies the gate bit as "DMA MCLK interface circuit
auto gating bit", which, when set to 1, disables auto gating. It also
has a footnote saying "When initializing DMA Controller, bit 2 (this
bit) should be set up."
Please include this information in the comment. Also you might want to
merge the two comment blocks and keep all the information in one place.
Curiously on the A83T I didn't need to set the bit for DMA to work.
ChenYu
> };
>
> /*
> @@ -1009,6 +1014,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
> .nr_max_channels = 8,
> .nr_max_requests = 24,
> .nr_max_vchans = 37,
> + .gate_needed = true,
> };
>
> static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> @@ -1177,10 +1183,10 @@ static int sun6i_dma_probe(struct platform_device
> *pdev)
> /*
> * sun8i variant requires us to toggle a dma gating register,
> * as seen in Allwinner's SDK. This register is not documented
> -* in the A23 user manual.
> +* in the A23 user manual, but documented at least in V3s user
> +* manual.
> */
> - if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun8i-a23-dma"))
> + if (sdc->cfg->gate_needed)
> writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
>
> return 0;
> --
> 2.12.2
>
> --
> 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.
[linux-sunxi] [PATCH v3 9/9] ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board
The Lichee Pi Zero Dock board has an audio jack and an onboard MIC.
Enable them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
index d1311098ea45..80f477738668 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
@@ -55,6 +55,15 @@
};
};
+&codec {
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Headphone", "HPCOM",
+ "MIC1", "Mic",
+ "Mic", "HBIAS";
+ status = "okay";
+};
+
&mmc1 {
broken-cd;
bus-width = <4>;
--
2.12.2
--
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 v3 8/9] ARM: dts: sun8i: add audio codec support into V3s DTSI
From: Icenowy Zheng
Allwinner V3s SoC features an internal audio codec like the one in H3,
and a analog codec like the one in H3/A23 (but much simpler).
Add them in the DTSI file.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v3:
- Added Chen-Yu's ACK.
arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index e0e99bbebdb3..01751ea0761e 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -271,6 +271,25 @@
status = "disabled";
};
+ codec: codec@01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-v3s-codec";
+ reg = <0x01c22c00 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "codec";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ allwinner,codec-analog-controls = <&codec_analog>;
+ status = "disabled";
+ };
+
+ codec_analog: codec-analog@01c23000 {
+ compatible = "allwinner,sun8i-v3s-codec-analog";
+ reg = <0x01c23000 0x4>;
+ };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.12.2
--
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 v3 5/9] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk
From: Icenowy Zheng
Originally we enable a special gate bit when the compatible indicates
A23/33.
But according to BSP sources and user manuals, more SoCs will need this
gate bit.
So make it a common quirk configured in the config struct.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Stripped out the A83T gate bit set.
drivers/dma/sun6i-dma.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index a2358780ab2c..69840cf6fe98 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -101,6 +101,11 @@ struct sun6i_dma_config {
u32 nr_max_channels;
u32 nr_max_requests;
u32 nr_max_vchans;
+ /*
+* The hardware has a special gate bit, which is needed to
+* be enabled for some SoCs with a sun6i-style DMA engine.
+*/
+ bool gate_needed;
};
/*
@@ -1009,6 +1014,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
.nr_max_channels = 8,
.nr_max_requests = 24,
.nr_max_vchans = 37,
+ .gate_needed = true,
};
static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
@@ -1177,10 +1183,10 @@ static int sun6i_dma_probe(struct platform_device *pdev)
/*
* sun8i variant requires us to toggle a dma gating register,
* as seen in Allwinner's SDK. This register is not documented
-* in the A23 user manual.
+* in the A23 user manual, but documented at least in V3s user
+* manual.
*/
- if (of_device_is_compatible(pdev->dev.of_node,
- "allwinner,sun8i-a23-dma"))
+ if (sdc->cfg->gate_needed)
writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
return 0;
--
2.12.2
--
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 v3 7/9] ARM: dts: sun8i: add DMA engine in V3s DTSI
From: Icenowy Zheng
Allwinner V3s SoC features a DMA engine.
Add it in the DTSI file.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v3:
- Added Chen-Yu's ACK.
arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..e0e99bbebdb3 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -95,6 +95,15 @@
#size-cells = <1>;
ranges;
+ dma: dma-controller@01c02000 {
+ compatible = "allwinner,sun8i-v3s-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
--
2.12.2
--
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 v3 6/9] dmaengine: sun6i: support V3s SoC variant
From: Icenowy Zheng
Allwinner V3s has a DMA engine similar to the ones from A31, but with
fewer channels and DRQs.
Add support for it.
Signed-off-by: Icenowy Zheng
Acked-by: Chen-Yu Tsai
---
Changes in v3:
- Added Chen-Yu's ACK.
Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
drivers/dma/sun6i-dma.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index 6b267045f522..98fbe1a5c6dd 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -9,6 +9,7 @@ Required properties:
"allwinner,sun8i-a23-dma"
"allwinner,sun8i-a83t-dma"
"allwinner,sun8i-h3-dma"
+ "allwinner,sun8i-v3s-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 69840cf6fe98..a57eaace8e7d 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -1034,11 +1034,24 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
.nr_max_vchans = 34,
};
+/*
+ * The V3s have only 8 physical channels, a maximum DRQ port id of 23,
+ * and a total of 24 usable source and destination endpoints.
+ */
+
+static struct sun6i_dma_config sun8i_v3s_dma_cfg = {
+ .nr_max_channels = 8,
+ .nr_max_requests = 23,
+ .nr_max_vchans = 24,
+ .gate_needed = true,
+};
+
static const struct of_device_id sun6i_dma_match[] = {
{ .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
{ .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
{ .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg
},
{ .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
+ { .compatible = "allwinner,sun8i-v3s-dma", .data = &sun8i_v3s_dma_cfg },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, sun6i_dma_match);
--
2.12.2
--
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 v3 4/9] ASoC: sun4i-codec: Add support for V3s codec
From: Icenowy Zheng
The codec in the V3s is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the V3s does not have LINEIN, LINEOUT, MBIAS and MIC2,
MIC3, and the FIFO related registers are like H3.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Change regmap max register.
- Add a note for further DAP support.
.../devicetree/bindings/sound/sun4i-codec.txt | 11 ++--
sound/soc/sunxi/sun4i-codec.c | 63 ++
2 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index 3863531d1e6d..2d4e10deb6f4 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -7,6 +7,7 @@ Required properties:
- "allwinner,sun7i-a20-codec"
- "allwinner,sun8i-a23-codec"
- "allwinner,sun8i-h3-codec"
+ - "allwinner,sun8i-v3s-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -25,6 +26,7 @@ Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun8i-a23-codec"
- "allwinner,sun8i-h3-codec"
+ - "allwinner,sun8i-v3s-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -34,15 +36,15 @@ Required properties for the following compatibles:
Audio pins on the SoC:
"HP"
"HPCOM"
- "LINEIN"
- "LINEOUT"(not on sun8i-a23)
+ "LINEIN" (not on sun8i-v3s)
+ "LINEOUT"(not on sun8i-a23 or sun8i-v3s)
"MIC1"
- "MIC2"
+ "MIC2" (not on sun8i-v3s)
"MIC3" (sun6i-a31 only)
Microphone biases from the SoC:
"HBIAS"
- "MBIAS"
+ "MBIAS" (not on sun8i-v3s)
Board connectors:
"Headphone"
@@ -55,6 +57,7 @@ Required properties for the following compatibles:
Required properties for the following compatibles:
- "allwinner,sun8i-a23-codec"
- "allwinner,sun8i-h3-codec"
+ - "allwinner,sun8i-v3s-codec"
- allwinner,codec-analog-controls: A phandle to the codec analog controls
block in the PRCM.
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index c3aab10fa085..150069987c0c 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1339,6 +1339,44 @@ static struct snd_soc_card
*sun8i_h3_codec_create_card(struct device *dev)
return card;
};
+static struct snd_soc_card *sun8i_v3s_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+
"allwinner,codec-analog-controls",
+0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "V3s Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.
[linux-sunxi] [PATCH v3 3/9] ASoC: sun8i-codec-analog: add support for V3s SoC
From: Icenowy Zheng
The V3s SoC features an analog codec with headphone support but without
mic2 and linein.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt | 1 +
sound/soc/sunxi/sun8i-codec-analog.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
index 779b735781ba..1b6e7c4e50ab 100644
--- a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: must be one of the following compatibles:
- "allwinner,sun8i-a23-codec-analog"
- "allwinner,sun8i-h3-codec-analog"
+ - "allwinner,sun8i-v3s-codec-analog"
Required properties if not a sub-node of the PRCM node:
- reg: must contain the registers location and length
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c
b/sound/soc/sunxi/sun8i-codec-analog.c
index 4c34a12b3739..465d53fa93ac 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -808,6 +808,11 @@ static int sun8i_codec_analog_add_mixer(struct
snd_soc_component *cmpnt,
return 0;
}
+static const struct sun8i_codec_analog_quirks sun8i_v3s_quirks = {
+ .has_headphone = true,
+ .has_hmic = true,
+};
+
static int sun8i_codec_analog_cmpnt_probe(struct snd_soc_component *cmpnt)
{
struct device *dev = cmpnt->dev;
@@ -882,6 +887,10 @@ static const struct of_device_id
sun8i_codec_analog_of_match[] = {
.compatible = "allwinner,sun8i-h3-codec-analog",
.data = &sun8i_h3_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-v3s-codec-analog",
+ .data = &sun8i_v3s_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun8i_codec_analog_of_match);
--
2.12.2
--
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 v3 2/9] ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s
Allwinner V3s has an analog codec without MIC2 and Line In, which will
need a special set of mixer controls/widgets/routes, otherwise meaningless
controls will be exported to userspace and confuse the user.
Add the special set, and use it when the SoC has no MIC2 and Line In.
Signed-off-by: Icenowy Zheng
---
New patch in v3.
sound/soc/sunxi/sun8i-codec-analog.c | 97 +++-
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c
b/sound/soc/sunxi/sun8i-codec-analog.c
index edcc3eb7cd9a..4c34a12b3739 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -219,6 +219,22 @@ static const struct snd_kcontrol_new
sun8i_codec_mixer_controls[] = {
SUN8I_ADDA_LOMIXSC_MIC2, 1, 0),
};
+/* mixer controls */
+static const struct snd_kcontrol_new sun8i_v3s_codec_mixer_controls[] = {
+ SOC_DAPM_DOUBLE_R("DAC Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACL, 1, 0),
+ SOC_DAPM_DOUBLE_R("DAC Reversed Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACR, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic1 Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_MIC1, 1, 0),
+};
+
/* ADC mixer controls */
static const struct snd_kcontrol_new sun8i_codec_adc_mixer_controls[] = {
SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
@@ -243,6 +259,22 @@ static const struct snd_kcontrol_new
sun8i_codec_adc_mixer_controls[] = {
SUN8I_ADDA_LADCMIXSC_MIC2, 1, 0),
};
+/* ADC mixer controls */
+static const struct snd_kcontrol_new sun8i_v3s_codec_adc_mixer_controls[] = {
+ SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRL, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mixer Reversed Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRR, 1, 0),
+ SOC_DAPM_DOUBLE_R("Mic1 Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_MIC1, 1, 0),
+};
+
/* volume / mute controls */
static const DECLARE_TLV_DB_SCALE(sun8i_codec_out_mixer_pregain_scale,
-450, 150, 0);
@@ -292,8 +324,9 @@ static const struct snd_soc_dapm_widget
sun8i_codec_common_widgets[] = {
/* Mic input path */
SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
+};
- /* Mixers */
+static const struct snd_soc_dapm_widget sun8i_codec_mixer_widgets[] = {
SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
sun8i_codec_mixer_controls,
@@ -312,10 +345,31 @@ static const struct snd_soc_dapm_widget
sun8i_codec_common_widgets[] = {
ARRAY_SIZE(sun8i_codec_adc_mixer_controls)),
};
+static const struct snd_soc_dapm_widget sun8i_v3s_codec_mixer_widgets[] = {
+ SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
+ sun8i_v3s_codec_mixer_controls,
+ ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Right Mixer", SUN8I_ADDA_DAC_PA_SRC,
+ SUN8I_ADDA_DAC_PA_SRC_RMIXEN, 0,
+ sun8i_v3s_codec_mixer_controls,
+ ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Left ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCLEN, 0,
+ sun8i_v3s_codec_adc_mixer_controls,
+ ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
+ SND_SOC_DAPM_MIXER("Right ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+ SUN8I_ADDA_ADC_AP_EN_ADCREN, 0,
+ sun8i_v3s_codec_adc_mixer_controls,
+ ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
+};
+
static const struct snd_soc_dapm_route sun8i_codec_common_routes[] = {
/* Microphone Routes */
{ "Mic1 Amplifier", NULL, "MIC1"},
+};
+static const struct snd_soc_dapm_route sun8i_codec_mixer_routes[] = {
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
@@ -714,6
[linux-sunxi] [PATCH v3 1/9] ASoC: sun8i-codec-analog: split out mbias
From: Icenowy Zheng
Allwinner V3s features an analog codec without MBIAS pin.
Split out this part, in order to prepare for the V3s analog codec.
Signed-off-by: Icenowy Zheng
---
Changes in v3:
- Fixed a missing line in v2.
sound/soc/sunxi/sun8i-codec-analog.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c
b/sound/soc/sunxi/sun8i-codec-analog.c
index 6c17c99c2c8d..edcc3eb7cd9a 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -289,11 +289,6 @@ static const struct snd_soc_dapm_widget
sun8i_codec_common_widgets[] = {
/* Microphone input */
SND_SOC_DAPM_INPUT("MIC1"),
- /* Microphone Bias */
- SND_SOC_DAPM_SUPPLY("MBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
- SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN,
- 0, NULL, 0),
-
/* Mic input path */
SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
@@ -453,6 +448,27 @@ static int sun8i_codec_add_headphone(struct
snd_soc_component *cmpnt)
return 0;
}
+/* mbias specific widget */
+static const struct snd_soc_dapm_widget sun8i_codec_mbias_widgets[] = {
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+ SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN,
+ 0, NULL, 0),
+};
+
+static int sun8i_codec_add_mbias(struct snd_soc_component *cmpnt)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(cmpnt);
+ struct device *dev = cmpnt->dev;
+ int ret;
+
+ ret = snd_soc_dapm_new_controls(dapm, sun8i_codec_mbias_widgets,
+ ARRAY_SIZE(sun8i_codec_mbias_widgets));
+ if (ret)
+ dev_err(dev, "Failed to add MBIAS DAPM widgets: %d\n", ret);
+
+ return ret;
+}
+
/* hmic specific widget */
static const struct snd_soc_dapm_widget sun8i_codec_hmic_widgets[] = {
SND_SOC_DAPM_SUPPLY("HBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
@@ -679,6 +695,7 @@ struct sun8i_codec_analog_quirks {
bool has_hmic;
bool has_linein;
bool has_lineout;
+ bool has_mbias;
bool has_mic2;
};
@@ -686,12 +703,14 @@ static const struct sun8i_codec_analog_quirks
sun8i_a23_quirks = {
.has_headphone = true,
.has_hmic = true,
.has_linein = true,
+ .has_mbias = true,
.has_mic2 = true,
};
static const struct sun8i_codec_analog_quirks sun8i_h3_quirks = {
.has_linein = true,
.has_lineout= true,
+ .has_mbias = true,
.has_mic2 = true,
};
@@ -734,6 +753,12 @@ static int sun8i_codec_analog_cmpnt_probe(struct
snd_soc_component *cmpnt)
return ret;
}
+ if (quirks->has_mbias) {
+ ret = sun8i_codec_add_mbias(cmpnt);
+ if (ret)
+ return ret;
+ }
+
if (quirks->has_mic2) {
ret = sun8i_codec_add_mic2(cmpnt);
if (ret)
--
2.12.2
--
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 v3 0/9] Add support for the audio codec on Allwinner V3s
Allwinner V3s features a audio codec with dedicated digital and analog parts, like the ones on A23/H3, but much simpler (lack of MIC2, LINE IN and MBIAS). Add support for it. In order to make the codec usable, DMA support is also added in this series. Patch 1 split out MBIAS in analog codec driver. Patch 2 prepared a set of objects that have MIC2 and LINEIN stripped out for V3s. Patch 3/4 adds support for V3s in analog/digital codec. Patch 5 add the gate bit as a common quirk of sun6i-dma driver, as V3s also needs it. Patch 6 really adds support for V3s in DMA engine. Patch 7/8/9 adds three parts of device tree: DMA engine, codec support and enable the codec for Lichee Pi Zero dock. Icenowy Zheng (9): ASoC: sun8i-codec-analog: split out mbias ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s ASoC: sun8i-codec-analog: add support for V3s SoC ASoC: sun4i-codec: Add support for V3s codec dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk dmaengine: sun6i: support V3s SoC variant ARM: dts: sun8i: add DMA engine in V3s DTSI ARM: dts: sun8i: add audio codec support into V3s DTSI ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board .../devicetree/bindings/dma/sun6i-dma.txt | 1 + .../devicetree/bindings/sound/sun4i-codec.txt | 11 +- .../bindings/sound/sun8i-codec-analog.txt | 1 + arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 9 ++ arch/arm/boot/dts/sun8i-v3s.dtsi | 28 drivers/dma/sun6i-dma.c| 25 +++- sound/soc/sunxi/sun4i-codec.c | 63 + sound/soc/sunxi/sun8i-codec-analog.c | 141 - 8 files changed, 266 insertions(+), 13 deletions(-) -- 2.12.2 -- 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 v3] sunxi: A64/Pine64: update device tree from Linux
The Linux device tree for the Allwinner A64 SoC has changed a lot since
the U-Boot version was merged.
Let's replace the current DT with a exact copy of the Linux one as of:
commit c6778ff813d2ca3e3c8733c87dc8b6831a64578b
Merge: 0ff4c01 3c0e3abd
Author: Linus Torvalds
Date: Tue May 9 10:07:33 2017 -0700
This is the DT used in Linux 4.12-rc1.
Since U-Boot has an Ethernet driver (while Linux does not yet), we
provide the required DT nodes for it in an ...-u-boot.dtsi file, to both
mark them as U-Boot specific and to allow easier upgrading once Linux gets
the driver and its own binding later.
Compared to the existing Ethernet DT nodes we just slightly tweak the clock
and reset nodes in there to match the new bindings used by Linux for those.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi| 50 ++
arch/arm/dts/sun50i-a64-pine64-plus.dts| 26 +-
arch/arm/dts/sun50i-a64-pine64.dts | 59 +-
arch/arm/dts/sun50i-a64.dtsi | 639 ++---
include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +
.../dt-bindings/reset/sun50i-a64-ccu.h | 109 ++--
6 files changed, 489 insertions(+), 528 deletions(-)
create mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
rename arch/arm/dts/sun50i-a64-pine64-common.dtsi =>
include/dt-bindings/reset/sun50i-a64-ccu.h (52%)
diff --git a/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
b/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
new file mode 100644
index 000..9c61bea
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi
@@ -0,0 +1,50 @@
+/ {
+ aliases {
+ ethernet0 = &emac;
+ };
+
+ soc {
+ emac: ethernet@01c3 {
+ compatible = "allwinner,sun50i-a64-emac";
+ reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+ reg-names = "emac", "syscon";
+ interrupts = ;
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "ahb";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "ahb";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ phy-mode = "rgmii";
+ phy = <&phy1>;
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
+ };
+};
+
+&pio {
+ rmii_pins: rmii_pins {
+ allwinner,pins = "PD10", "PD11", "PD13", "PD14",
+"PD17", "PD18", "PD19", "PD20",
+"PD22", "PD23";
+ allwinner,function = "emac";
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
+
+ rgmii_pins: rgmii_pins {
+ allwinner,pins = "PD8", "PD9", "PD10", "PD11",
+"PD12", "PD13", "PD15",
+"PD16", "PD17", "PD18", "PD19",
+"PD20", "PD21", "PD22", "PD23";
+ allwinner,function = "emac";
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
+};
diff --git a/arch/arm/dts/sun50i-a64-pine64-plus.dts
b/arch/arm/dts/sun50i-a64-pine64-plus.dts
index 389c609..790d14d 100644
--- a/arch/arm/dts/sun50i-a64-pine64-plus.dts
+++ b/arch/arm/dts/sun50i-a64-pine64-plus.dts
@@ -40,33 +40,11 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-/dts-v1/;
-
-#include "sun50i-a64-pine64-common.dtsi"
+#include "sun50i-a64-pine64.dts"
/ {
model = "Pine64+";
compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- /* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
- memory {
- reg = <0x4000 0x4000>;
- };
-};
-
-&emac {
- pinctrl-names = "default";
- pinctrl-0 = <&rgmii_pins>;
- phy-mode = "rgmii";
- phy = <&phy1>;
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
+ /* TODO: Camera, Ethernet PHY, touchscreen, etc. */
};
-
diff --git a/arch/arm/dts/sun50i-a64-pine64.dts
b/arch/arm/dts/sun50i-a64-pine64.dts
index ebe029e..c680ed3 100644
--- a/arch/arm/dts/sun50i-a64-pine64.dts
+++ b/arch/arm/dts/sun50i-a64-pine64.dts
@@ -42,17 +42,70 @@
/dts-v1/;
-#include "sun50i-a64-pine64-common.dtsi"
+#include "sun50i-a64.dtsi"
+
+#include
/ {
model = "Pine64";
compatible = "pine64,pine64", "allwinner,sun50i-a64";
+ aliases {
+ serial0 = &uart0;
+ };
+
chose
[linux-sunxi] Re: [U-Boot] [PATCH v2 0/2] sunxi: update Pine64 device tree
Hi, On 24/05/17 10:14, Chen-Yu Tsai wrote: > On Wed, May 24, 2017 at 4:30 PM, Andre Przywara > wrote: >> Hi, >> >> On 23/05/17 23:26, Andreas Färber wrote: >>> Hi Andre, >>> >>> Am 23.05.2017 um 12:09 schrieb Andre Przywara: an updated version: the first patch is unchanged (still the exact same DT as in Linux), but the second patch reformats the Ethernet nodes as a .dtsi and uses the new U-Boot specific DT addon feature to make it clear that these nodes are for a (preliminary) U-Boot specific binding. Once the Ethernet driver made it into Linux, we will either adapt the U-Boot driver to cope with the new binding or get a new (Designware based) driver anyway. In any case this -u-boot.dtsi can then just be removed. >>> >>> Could we squash the two? Or add the .dtsi first? That would keep the >>> series bisectable. >> >> Yeah, now with that separate file for the Ethernet node squashing the >> two patches into one would be the easiest. >> >> Chen-Yu, Maxime, are you OK with this? I can send a new version then. > > You're asking the wrong person. I'm not a maintainer for U-boot. :p I know, but you commented on my initial post a few weeks ago (suggesting to keep the DT update in one patch) and are a valuable and knowledgeable resource anyway ;-) Cheers, Andre. > Andreas' point is valid. Keeping it in one patch means the user retains > ethernet support across the changes. > > ChenYu > -- 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: [U-Boot] [PATCH v2 0/2] sunxi: update Pine64 device tree
On Wed, May 24, 2017 at 4:30 PM, Andre Przywara wrote: > Hi, > > On 23/05/17 23:26, Andreas Färber wrote: >> Hi Andre, >> >> Am 23.05.2017 um 12:09 schrieb Andre Przywara: >>> an updated version: the first patch is unchanged (still the exact >>> same DT as in Linux), but the second patch reformats the Ethernet nodes >>> as a .dtsi and uses the new U-Boot specific DT addon feature to make >>> it clear that these nodes are for a (preliminary) U-Boot specific binding. >>> Once the Ethernet driver made it into Linux, we will either adapt the >>> U-Boot driver to cope with the new binding or get a new (Designware based) >>> driver anyway. In any case this -u-boot.dtsi can then just be removed. >> >> Could we squash the two? Or add the .dtsi first? That would keep the >> series bisectable. > > Yeah, now with that separate file for the Ethernet node squashing the > two patches into one would be the easiest. > > Chen-Yu, Maxime, are you OK with this? I can send a new version then. You're asking the wrong person. I'm not a maintainer for U-boot. :p Andreas' point is valid. Keeping it in one patch means the user retains ethernet support across the changes. ChenYu -- 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: [U-Boot] [PATCH v2 0/2] sunxi: update Pine64 device tree
On Wed, May 24, 2017 at 09:30:05AM +0100, Andre Przywara wrote: > Hi, > > On 23/05/17 23:26, Andreas Färber wrote: > > Hi Andre, > > > > Am 23.05.2017 um 12:09 schrieb Andre Przywara: > >> an updated version: the first patch is unchanged (still the exact > >> same DT as in Linux), but the second patch reformats the Ethernet nodes > >> as a .dtsi and uses the new U-Boot specific DT addon feature to make > >> it clear that these nodes are for a (preliminary) U-Boot specific binding. > >> Once the Ethernet driver made it into Linux, we will either adapt the > >> U-Boot driver to cope with the new binding or get a new (Designware based) > >> driver anyway. In any case this -u-boot.dtsi can then just be removed. > > > > Could we squash the two? Or add the .dtsi first? That would keep the > > series bisectable. > > Yeah, now with that separate file for the Ethernet node squashing the > two patches into one would be the easiest. > > Chen-Yu, Maxime, are you OK with this? I can send a new version then. Yep, that works for me. 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: [U-Boot] [PATCH v2 0/2] sunxi: update Pine64 device tree
Hi, On 23/05/17 23:26, Andreas Färber wrote: > Hi Andre, > > Am 23.05.2017 um 12:09 schrieb Andre Przywara: >> an updated version: the first patch is unchanged (still the exact >> same DT as in Linux), but the second patch reformats the Ethernet nodes >> as a .dtsi and uses the new U-Boot specific DT addon feature to make >> it clear that these nodes are for a (preliminary) U-Boot specific binding. >> Once the Ethernet driver made it into Linux, we will either adapt the >> U-Boot driver to cope with the new binding or get a new (Designware based) >> driver anyway. In any case this -u-boot.dtsi can then just be removed. > > Could we squash the two? Or add the .dtsi first? That would keep the > series bisectable. Yeah, now with that separate file for the Ethernet node squashing the two patches into one would be the easiest. Chen-Yu, Maxime, are you OK with this? I can send a new version then. Cheers, Andre. -- 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] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard 写到: >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote: >> 在 2017-05-23 20:53，Maxime Ripard 写道： >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: >> > > Hi, >> > > >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai >napisal(a): >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec > >> > > wrote: >> > > > > Hi, >> > > > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng >napisal(a): >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard >> > > > > >> > > > > electrons.com> 写到: >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng >wrote: >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in >earlier >> > > > >> > >> > > > >> >SoCs, >> > > > >> > >> > > > >> >> but with some different points about clocks: >> > > > >> >> - It has a mod clock and a bus clock. >> > > > >> >> - The mod clock must be at a fixed rate to generate >signal. >> > > > >> > >> > > > >> >Why? >> > > > >> >> > > > >> It's experiment result by Jernej. >> > > > >> >> > > > >> The clock rates in BSP kernel is also specially designed >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. >> > > > > >> > > > > My experiments and search through BSP code showed that TVE >seems to have >> > > > > additional fixed predivider 8. So if you want to generate 27 >MHz clock, >> > > > > unit has to be feed with 216 MHz. >> > > > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a >bit low for >> > > > > DE2, >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to >generate 216 MHz. >> > > > > This clock is then divided by 8 internaly to get final 27 >MHz. >> > > > > >> > > > > Please note that I don't have any hard evidence to support >that, only >> > > > > experimental data. However, only that explanation make sense >to me. >> > > > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which >both use 27 MHz >> > > > > base clock. Further experiments are needed to check if there >is any >> > > > > possibility to have other resolutions by manipulating clocks >and give >> > > > > other proper settings. I plan to do that, but not in very >near future. >> > > > >> > > > You only have composite video output, and those are the only 2 >standard >> > > > resolutions that make any sense. >> > > >> > > Right, other resolutions are for VGA. >> > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I >think >> > > that H3 TVE >> > > unit is something in between. R40 TVE has a setting to select "up >> > > sample". >> > >> > That might be just another translation of oversampling :) >> > >> > I didn't know it could be applied to composite signals though, but >I >> > guess this is just another analog signal after all. >> > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP >> > > driver on R40 >> > > has this setting enabled only for PAL and NTSC and it is always >216 >> > > MHz. I >> > > think that H3 may have this hardwired to 216 MHz and this would >be >> > > the reason >> > > why 216 MHz is needed. >> > > >> > > Has anyone else any better explanation? >> > >> > That's already a pretty good one. >> > >> > Either way, wether this is upsampling, oversampling or just a >> > pre-divider, this can and should be dealt with in the mode_set >> > callback, and not in the probe. >> >> I got a better idea -- let TVE driver have the CLK_TVE as an >> input and create a subclock output with divider 16, and feed this >> subclock to TCON lcd-ch1. >> >> This is a model of the real hardware -- the clock divider is in >> TVE, not TCON. > >That's definitely not a good representation of the hardware. There's >one clock, it goes to the TCON, period. No, I still think it goes to the TVE as: 1. it's named TVE in datasheet. 2. Generating signal with such a low resolution but such a high dotclock is not a good situation. > >However, the TV encoder has a constraint on that clock rate. This can >be easily implemented using a custom encoder state where you'd set the >multiplier to set on that clock, and the TCON will use it. > >Maxime -- 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] Re: [RFC PATCH 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
On Sat, May 20, 2017 at 02:10:35AM +0800, Icenowy Zheng wrote:
>
>
> 于 2017年5月20日 GMT+08:00 上午2:06:16, Maxime Ripard
> 写到:
> >On Thu, May 18, 2017 at 12:43:53AM +0800, Icenowy Zheng wrote:
> >> As we have already the support for the TV encoder on Allwinner H3,
> >add
> >> the display engine pipeline device tree nodes to its DTSI file.
> >>
> >> The H5 pipeline has some differences and will be enabled later.
> >>
> >> The currently-unused mixer0 and tcon0 are also needed, for the
> >> completement of the pipeline.
> >>
> >> Signed-off-by: Icenowy Zheng
> >> ---
> >> arch/arm/boot/dts/sun8i-h3.dtsi | 189
> >
> >> 1 file changed, 189 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> >b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> index b36f9f423c39..20172ef92415 100644
> >> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> >> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> >> @@ -41,6 +41,8 @@
> >> */
> >>
> >> #include "sunxi-h3-h5.dtsi"
> >> +#include
> >> +#include
> >>
> >> / {
> >>cpus {
> >> @@ -72,6 +74,193 @@
> >>};
> >>};
> >>
> >> + de: display-engine {
> >> + compatible = "allwinner,sun8i-h3-display-engine";
> >> + allwinner,pipelines = <&mixer0>,
> >> +<&mixer1>;
> >> + status = "disabled";
> >> + };
> >> +
> >> + soc {
> >> + display_clocks: clock@100 {
> >> + compatible = "allwinner,sun8i-a83t-de2-clk";
> >> + reg = <0x0100 0x10>;
> >> + clocks = <&ccu CLK_BUS_DE>,
> >> + <&ccu CLK_DE>;
> >> + clock-names = "bus",
> >> +"mod";
> >> + resets = <&ccu RST_BUS_DE>;
> >> + #clock-cells = <1>;
> >> + #reset-cells = <1>;
> >> + assigned-clocks = <&ccu CLK_DE>;
> >> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> >> + assigned-clock-rates = <43200>;
> >
> >This shouldn't be set in the DT, but evaluated at runtime when calling
> >clk_set_rate.
>
> Nope, DE2 clock doesn't need evalution, as the clock is decoupled with
> DE2 mixers' output signal. (Although it seems that SoCs with larger
> plane size will use higher clock.)
So it's the display engine that needs that clock to operate properly?
This is the wrong DT node to set that value then. It should be in the
mixer node, or even better in the mixers' driver.
> And setting it to 432MHz is also needed for properly 216MHz clock to
> TVE.
Just like the parenthood, this can and should be evaluated at runtime.
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: [RFC PATCH 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
On Sat, May 20, 2017 at 02:00:22AM +0800, Icenowy Zheng wrote:
>
>
> 于 2017年5月20日 GMT+08:00 上午1:57:53, Maxime Ripard
> 写到:
> >On Thu, May 18, 2017 at 12:43:46AM +0800, Icenowy Zheng wrote:
> >> Some SoC's DE2 has two mixers. Defaultly the mixer0 is connected to
> >> tcon0 and mixer1 is connected to tcon1; however by setting a bit
> >> the connection can be swapped.
> >>
> >> As we now hardcode the default connection, ignore the bonus endpoint
> >for
> >> the mixer's output and the TCON's input, as they stands for the
> >swapped
> >> connection.
> >>
> >> Signed-off-by: Icenowy Zheng
> >> ---
> >> drivers/gpu/drm/sun4i/sun4i_drv.c | 27 ++
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c | 39
> >+-
> >> drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
> >> 3 files changed, 59 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> index 1dd1948025d2..29bf1325ded6 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> @@ -173,6 +173,13 @@ static bool sun4i_drv_node_is_frontend(struct
> >device_node *node)
> >>of_device_is_compatible(node,
> >"allwinner,sun8i-a33-display-frontend");
> >> }
> >>
> >> +static bool sun4i_drv_node_is_swappable_de2_mixer(struct device_node
> >*node)
> >> +{
> >> + /* The V3s has only one mixer-tcon pair, so it's not listed here.
> >*/
> >> + return of_device_is_compatible(node,
> >"allwinner,sun8i-h3-de2-mixer0") ||
> >> + of_device_is_compatible(node, "allwinner,sun8i-h3-de2-mixer1");
> >> +}
> >> +
> >> static bool sun4i_drv_node_is_tcon(struct device_node *node)
> >> {
> >>return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
> >> @@ -249,6 +256,26 @@ static int sun4i_drv_add_endpoints(struct device
> >*dev,
> >>}
> >>}
> >>
> >> + /*
> >> + * The second endpoint of the output of a swappable DE2 mixer
> >> + * is the TCON after connection swapping.
> >> + * Ignore it now, as we now hardcode mixer0->tcon0,
> >> + * mixer1->tcon1 connection.
> >> + */
> >> + if (sun4i_drv_node_is_swappable_de2_mixer(node)) {
> >> + struct of_endpoint endpoint;
> >> +
> >> + if (of_graph_parse_endpoint(ep, &endpoint)) {
> >> + DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
> >> + continue;
> >> + }
> >> +
> >> + if (endpoint.id) {
> >> + DRM_DEBUG_DRIVER("Endpoint is an unused
> >> connection for DE2
> >mixer... skipping\n");
> >> + continue;
> >> + }
> >> + }
> >> +
> >>/* Walk down our tree */
> >>count += sun4i_drv_add_endpoints(dev, match, remote);
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> index f44a37a5993d..89a215ff2370 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> @@ -425,7 +425,8 @@ static int sun4i_tcon_init_regmap(struct device
> >*dev,
> >> * requested via the get_id function of the engine.
> >> */
> >> static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv
> >*drv,
> >> - struct device_node *node)
> >> + struct device_node *node,
> >> + bool skip_bonus_ep)
> >> {
> >>struct device_node *port, *ep, *remote;
> >>struct sunxi_engine *engine;
> >> @@ -439,6 +440,20 @@ static struct sunxi_engine
> >*sun4i_tcon_find_engine(struct sun4i_drv *drv,
> >>if (!remote)
> >>continue;
> >>
> >> + if (skip_bonus_ep) {
> >> + struct of_endpoint endpoint;
> >> +
> >> + if (of_graph_parse_endpoint(ep, &endpoint)) {
> >> + DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
> >> + continue;
> >> + }
> >> +
> >> + if (endpoint.id) {
> >> + DRM_DEBUG_DRIVER("Skipping bonus mixer->TCON
> >> connection when
> >searching engine\n");
> >> + continue;
> >> + }
> >> + }
> >> +
> >
> >You don't list the mixers in the tcon's output, why do you need that
> >exactly?
>
> Mixers are TCONs' input, not output...
Then why are they even parsed? The whole parsing logic in the driver
only searches for output nodes.
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,
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote: > 在 2017-05-23 20:53，Maxime Ripard 写道： > > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote: > > > Hi, > > > > > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec > > > > > > > wrote: > > > > > Hi, > > > > > > > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > > > > > > > electrons.com> 写到: > > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > > > > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > > > > >> > > > > > >> >SoCs, > > > > >> > > > > > >> >> but with some different points about clocks: > > > > >> >> - It has a mod clock and a bus clock. > > > > >> >> - The mod clock must be at a fixed rate to generate signal. > > > > >> > > > > > >> >Why? > > > > >> > > > > >> It's experiment result by Jernej. > > > > >> > > > > >> The clock rates in BSP kernel is also specially designed > > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > > > > > > > My experiments and search through BSP code showed that TVE seems to > > > > > have > > > > > additional fixed predivider 8. So if you want to generate 27 MHz > > > > > clock, > > > > > unit has to be feed with 216 MHz. > > > > > > > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > > > > DE2, > > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 > > > > > MHz. > > > > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > > > > > > > Please note that I don't have any hard evidence to support that, only > > > > > experimental data. However, only that explanation make sense to me. > > > > > > > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 > > > > > MHz > > > > > base clock. Further experiments are needed to check if there is any > > > > > possibility to have other resolutions by manipulating clocks and give > > > > > other proper settings. I plan to do that, but not in very near future. > > > > > > > > You only have composite video output, and those are the only 2 standard > > > > resolutions that make any sense. > > > > > > Right, other resolutions are for VGA. > > > > > > Anyway, I did some more digging in A10 and R40 datasheets. I think > > > that H3 TVE > > > unit is something in between. R40 TVE has a setting to select "up > > > sample". > > > > That might be just another translation of oversampling :) > > > > I didn't know it could be applied to composite signals though, but I > > guess this is just another analog signal after all. > > > > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP > > > driver on R40 > > > has this setting enabled only for PAL and NTSC and it is always 216 > > > MHz. I > > > think that H3 may have this hardwired to 216 MHz and this would be > > > the reason > > > why 216 MHz is needed. > > > > > > Has anyone else any better explanation? > > > > That's already a pretty good one. > > > > Either way, wether this is upsampling, oversampling or just a > > pre-divider, this can and should be dealt with in the mode_set > > callback, and not in the probe. > > I got a better idea -- let TVE driver have the CLK_TVE as an > input and create a subclock output with divider 16, and feed this > subclock to TCON lcd-ch1. > > This is a model of the real hardware -- the clock divider is in > TVE, not TCON. That's definitely not a good representation of the hardware. There's one clock, it goes to the TCON, period. However, the TV encoder has a constraint on that clock rate. This can be easily implemented using a custom encoder state where you'd set the multiplier to set on that clock, and the TCON will use it. 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
