Re: [linux-sunxi] [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

2016-11-24 Thread Ondřej Jirman 
Dne 25.11.2016 v 06:27 Icenowy Zheng napsal(a):
> 
> 
> 20.11.2016, 20:07, "Jean-Francois Moine" :
>> Signed-off-by: Jean-Francois Moine 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 51 
>> +
>>  1 file changed, 51 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 416b825..7c6b1d5 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -140,6 +140,16 @@
>>  #size-cells = <1>;
>>  ranges;
>>
>> + de: de-controller@0100 {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + reg = <0x0100 0x40>;
>> + clocks = < CLK_BUS_DE>, < CLK_DE>;
>> + clock-names = "bus", "clock";
>> + resets = < RST_BUS_DE>;
>> + ports = <_p>;
>> + status = "disabled";
>> + };
>> +
>>  dma: dma-controller@01c02000 {
>>  compatible = "allwinner,sun8i-h3-dma";
>>  reg = <0x01c02000 0x1000>;
>> @@ -149,6 +159,23 @@
>>  #dma-cells = <1>;
>>  };
>>
>> + lcd0: lcd-controller@01c0c000 {
>> + compatible = "allwinner,sun8i-a83t-tcon";
>> + reg = <0x01c0c000 0x400>;
>> + clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
>> + clock-names = "bus", "clock";
>> + resets = < RST_BUS_TCON0>;
>> + interrupts = ;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + lcd0_p: port {
>> + lcd0_hdmi: endpoint {
>> + remote-endpoint = <_lcd0>;
>> + };
>> + };
>> + };
>> +
>>  mmc0: mmc@01c0f000 {
>>  compatible = "allwinner,sun7i-a20-mmc";
>>  reg = <0x01c0f000 0x1000>;
>> @@ -314,6 +341,11 @@
>>  clock-names = "hosc", "losc";
>>  #clock-cells = <1>;
>>  #reset-cells = <1>;
>> +
>> + assigned-clocks = < CLK_PLL_DE>,
> 
> Cannot get the patch built on 4.9-rc, as CLK_PLL_DE is not an exported clock.
> 
> Only CLK_DE is exported.

Jean-Francois uses his own clk driver for h3. Check out this branch,
which contains his latest HDMI patches with necessary fixes for it to
work with sunxi-ng clk driver:

  https://github.com/megous/linux/commits/orange-pi-4.9

There are more issues, than just a missing CLK_DE macro. I'll probably
send the patches out soon.

regards,
  o.

>> + < CLK_DE>;
>> + assigned-clock-rates = <86400>,
>> + <43200>;
>>  };
>>
>>  pio: pinctrl@01c20800 {
>> @@ -564,6 +596,25 @@
>>  interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>>  };
>>
>> + hdmi: hdmi@01ee {
>> + compatible = "allwinner,sun8i-h3-hdmi";
>> + reg = <0x01ee 0x2>;
>> + clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
>> + < CLK_HDMI_DDC>;
>> + clock-names = "bus", "clock", "ddc-clock";
>> + resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
>> + reset-names = "hdmi0", "hdmi1";
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 { /* video */
>> + reg = <0>;
>> + hdmi_lcd0: endpoint {
>> + remote-endpoint = <_hdmi>;
>> + };
>> + };
>> + };
>> +
>>  rtc: rtc@01f0 {
>>  compatible = "allwinner,sun6i-a31-rtc";
>>  reg = <0x01f0 0x54>;
>> --
>> 2.10.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.


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] PoC tvin2jpeg_h264 with veisp scaling

2016-11-24 Thread Milos Ladni 
Hi,

>  last time maybe wasn't very clear explained what this
> >  "divide scaler" really is.
>

You are right, i did not understand what divide scaler is.
I do not really need raw pictures when i have arbitrary scaler for encoding,
this was just for test, i'll fix it.

> Another thing were you speak about muxing into video containers, if you
> > have interest to implement this. I have somewhere a very simple example
> > of using ffmpeg libavformat to do this, much more easy to understand
> > that any of ffmpeg examples or test cases.
> > Just tell, i have to go find where is, first.
>

It would be nice to implement this. 
If you have a time to find example please send me.

--
Milos Ladicorbic


-- 
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 v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

2016-11-24 Thread Jean-François Moine 
On Fri, 25 Nov 2016 13:27:20 +0800
Icenowy Zheng  wrote:

> > + assigned-clocks = < CLK_PLL_DE>,
> 
> Cannot get the patch built on 4.9-rc, as CLK_PLL_DE is not an exported clock.

Hi,

Sorry, I forgot it. The symbol goes to
include/dt-bindings/clock/sun8i-h3-ccu.h
as:

#define CLK_PLL_DE  13

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
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] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

2016-11-24 Thread Maxime Ripard 
On Fri, Nov 25, 2016 at 01:28:47AM +0100, meg...@megous.com wrote:
> From: Ondrej Jirman 
> 
> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
> too high, and the system becomes unstable (oopses or hangs).
> 
> Add a notifier to avoid this situation by temporarily switching
> to a known stable 24 MHz oscillator.
> 
> Signed-off-by: Ondrej Jirman 
> Tested-by: Lutz Sammer 

Applied, 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

Re: [linux-sunxi] [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

2016-11-24 Thread Icenowy Zheng 


20.11.2016, 20:07, "Jean-Francois Moine" :
> Signed-off-by: Jean-Francois Moine 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 51 
> +
>  1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 416b825..7c6b1d5 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -140,6 +140,16 @@
>  #size-cells = <1>;
>  ranges;
>
> + de: de-controller@0100 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + reg = <0x0100 0x40>;
> + clocks = < CLK_BUS_DE>, < CLK_DE>;
> + clock-names = "bus", "clock";
> + resets = < RST_BUS_DE>;
> + ports = <_p>;
> + status = "disabled";
> + };
> +
>  dma: dma-controller@01c02000 {
>  compatible = "allwinner,sun8i-h3-dma";
>  reg = <0x01c02000 0x1000>;
> @@ -149,6 +159,23 @@
>  #dma-cells = <1>;
>  };
>
> + lcd0: lcd-controller@01c0c000 {
> + compatible = "allwinner,sun8i-a83t-tcon";
> + reg = <0x01c0c000 0x400>;
> + clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
> + clock-names = "bus", "clock";
> + resets = < RST_BUS_TCON0>;
> + interrupts = ;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_hdmi: endpoint {
> + remote-endpoint = <_lcd0>;
> + };
> + };
> + };
> +
>  mmc0: mmc@01c0f000 {
>  compatible = "allwinner,sun7i-a20-mmc";
>  reg = <0x01c0f000 0x1000>;
> @@ -314,6 +341,11 @@
>  clock-names = "hosc", "losc";
>  #clock-cells = <1>;
>  #reset-cells = <1>;
> +
> + assigned-clocks = < CLK_PLL_DE>,

Cannot get the patch built on 4.9-rc, as CLK_PLL_DE is not an exported clock.

Only CLK_DE is exported.

> + < CLK_DE>;
> + assigned-clock-rates = <86400>,
> + <43200>;
>  };
>
>  pio: pinctrl@01c20800 {
> @@ -564,6 +596,25 @@
>  interrupts =  IRQ_TYPE_LEVEL_HIGH)>;
>  };
>
> + hdmi: hdmi@01ee {
> + compatible = "allwinner,sun8i-h3-hdmi";
> + reg = <0x01ee 0x2>;
> + clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
> + < CLK_HDMI_DDC>;
> + clock-names = "bus", "clock", "ddc-clock";
> + resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
> + reset-names = "hdmi0", "hdmi1";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 { /* video */
> + reg = <0>;
> + hdmi_lcd0: endpoint {
> + remote-endpoint = <_hdmi>;
> + };
> + };
> + };
> +
>  rtc: rtc@01f0 {
>  compatible = "allwinner,sun6i-a31-rtc";
>  reg = <0x01f0 0x54>;
> --
> 2.10.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.

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

2016-11-24 Thread Chen-Yu Tsai 
On Fri, Nov 25, 2016 at 8:28 AM,   wrote:
> From: Ondrej Jirman 
>
> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
> too high, and the system becomes unstable (oopses or hangs).
>
> Add a notifier to avoid this situation by temporarily switching
> to a known stable 24 MHz oscillator.
>
> Signed-off-by: Ondrej Jirman 
> Tested-by: Lutz Sammer 

A Fixes tag would be nice. Otherwise,

Acked-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] PoC tvin2jpeg_h264 with veisp scaling

2016-11-24 Thread Manuel Braga 
Hi.
Good work.

I took a look (not tested in the hardware, sorry is the usual no time),
and what you wrote in the readme about the divide scaler bug.

>From only a quick look, is hard to understand how you are using it, but
before that, last time maybe wasn't very clear explained what this
"divide scaler" really is.
This is a feature of the veisp to make "thumbnails", basically when
encoding is also possible to get the exactly picture as raw pixels of
what was encoded.

Meaning that this "divider scaler" can not affect the picture size that
will be encoded.

If there aren't any need for smaller raw pictures, then just only use
the arbitrary scaler.


Another thing were you speak about muxing into video containers, if you
have interest to implement this. I have somewhere a very simple example
of using ffmpeg libavformat to do this, much more easy to understand
that any of ffmpeg examples or test cases.
Just tell, i have to go find where is, first.



On Thu, 24 Nov 2016 04:20:38 -0800 (PST) Milos Ladni
 wrote:
> Hello,
> 
> This is yet another Proof of Concept analogue TV decoder (TV-IN) and 
> hardware accelerated H264-JPEG encoder with VEISP scaling for sunxi.
> This example capture frames from tvin (CVBS) scale it to VGA or QVGA
> and simultaneous encode frame to jpeg image and h264 stream.
> sunxi-tvin2jpeg_h264
> 
> 
> --
> Milos Ladicorbic
> 

-- 
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: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Maxime Ripard 
On Thu, Nov 24, 2016 at 11:15:42AM +, Andre Przywara wrote:
> On 24/11/16 10:55, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara  
> >> wrote:
> >>> Hi,
> >>>
> >>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
>  Hi,
> 
>  On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
>  wrote:
> > The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> > have arm64 capable cores. Add the generic sunxi config symbol to allow
> > the driver to be selected by arm64 Kconfigs, which don't feature
> > SoC specific MACH_ configs.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/dma/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index af63a6b..003c284 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -157,7 +157,7 @@ config DMA_SUN4I
> >
> >  config DMA_SUN6I
> > tristate "Allwinner A31 SoCs DMA support"
> > -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> > +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || 
> > ARCH_SUNXI
> 
>  AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
>  (And I don't have to add MACH_SUN9I later :) )
> >>>
> >>> Sure, admittedly it was just a quick hack to get things going.
> >>> Actually I don't know why we had a *depend* on those MACH_s before. I
> >>> think technically it does not depend on a certain SoC (having the
> >>> COMPILE_TEST in there hints on that). So what about:
> >>
> >> It was really because this DMA engine only comes with the later
> >> SoCs. We have dma-sun4i for the older one.
> > 
> > Indeed.
> > 
> >> But yes, there's no reason why you can't build it for the earlier
> >> SoC. It just doesn't get used.
> > 
> > I'm still in favor of keeping the depends on. There's no point of
> > compiling something we know have zero chance of running.
> > 
> > (But that would be (ARCH_SUNXI && ARM64))
> 
> I am OK with that, just wondering if there is a definition of what
> "depends" really means. My impression what that it's a about code
> dependencies (requires a certain subsystem, for instance), not really if
> it's useful in a particular configuration.

My understanding is that it's a hard dependency that prevents
configuration that make no sense, ie being able to compile a driver
that has no chance of being useful in the system, or a driver missing
its framework of choice.

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] ARM: dts: sun6i: hummingbird: Enable USB OTG

2016-11-24 Thread Maxime Ripard 
On Thu, Nov 24, 2016 at 07:29:08PM +0800, Chen-Yu Tsai wrote:
> The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
> SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
> VBUS detection and control.
> 
> Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
> USB OTG, as that is the hardware default.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, 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 0/2] ARM: dts: sun6i: Disable display pipeline by default

2016-11-24 Thread Maxime Ripard 
On Thu, Nov 24, 2016 at 02:43:37PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> While we now support the internal display pipeline found on sun6i, it
> is possible that we are unable to enable the display for some boards,
> due to a lack of drivers for the panels or bridges found on them. If
> the display pipeline is enabled, the driver will try to enable, and
> possibly screw up the simple framebuffer U-boot had configured.
> 
> This series disables the display pipeline by default, and re-enables
> it for the A31 Hummingbird, which already had its display pipeline
> enabled.
> 
> The series can go in after 4.10-rc1, as a fix, but should not be delayed
> till the next release.

Applied both, 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: [RFC PATCH 2/2] arm64: dts: enable the MUSB controller of Pine64 in host-only mode

2016-11-24 Thread Maxime Ripard 
On Wed, Nov 23, 2016 at 12:59:02AM +0800, Icenowy Zheng wrote:
> A64 has a MUSB controller wired to the USB PHY 0, which is connected
> to the upper USB Type-A port of Pine64.
> 
> As the port is a Type-A female port, enable it in host-only mode in the
> device tree, which makes devices with USB Type-A male port can work on
> this port (which is originally designed by Pine64 team).
> 
> Signed-off-by: Icenowy Zheng 

Applied both, 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

Re: [linux-sunxi] Re: [RFC PATCH 0/5] arm64: Allwinner H5 support

2016-11-24 Thread Ian Campbell 
On Thu, 2016-11-24 at 11:05 +, Andre Przywara wrote:
> 
> > I don't have any major comments but I guess it all depends on the DT
> > maintainers view on the symbolic link to share the DTSI.
> 
> I am curious too ;-)
> But I saw symlinks for the RaspberryPi 3 (check
> arch/arm64/boot/dts/broadcom) and VExpress, so I picked that low hanging
> fruit ;-)

See http://git.kernel.org/torvalds/linux/c/8ee57b8182c4 and the ML
discussion around the posting of that for some background on why the
symlinks are being used in preference to #include or /include/.

IIRC there was some further discussion on some lists when http://git.ke
rnel.org/torvalds/linux/c/76aa75916880 was posted too.

Ian.

-- 
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: PoC tvin2jpeg_h264 with veisp scaling

2016-11-24 Thread Milos Ladni 
Sorry i do not have H3, only A10, A10s, A13, A20

On Thursday, November 24, 2016 at 2:36:53 PM UTC+1, @lex wrote:
>
> Have you tried to port it (JPEG encoder) to H3?
>
> On Thursday, November 24, 2016 at 10:20:38 AM UTC-2, Milos Ladni wrote:
>>
>> Hello,
>>
>> This is yet another Proof of Concept analogue TV decoder (TV-IN) and 
>> hardware accelerated H264-JPEG encoder with VEISP scaling for sunxi.
>> This example capture frames from tvin (CVBS) scale it to VGA or QVGA and 
>> simultaneous encode frame to jpeg image and h264 stream.
>> sunxi-tvin2jpeg_h264 
>>
>> --
>> Milos Ladicorbic
>>
>

-- 
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: PoC tvin2jpeg_h264 with veisp scaling

2016-11-24 Thread @lex 
Have you tried to port it (JPEG encoder) to H3?

On Thursday, November 24, 2016 at 10:20:38 AM UTC-2, Milos Ladni wrote:
>
> Hello,
>
> This is yet another Proof of Concept analogue TV decoder (TV-IN) and 
> hardware accelerated H264-JPEG encoder with VEISP scaling for sunxi.
> This example capture frames from tvin (CVBS) scale it to VGA or QVGA and 
> simultaneous encode frame to jpeg image and h264 stream.
> sunxi-tvin2jpeg_h264 
>
> --
> Milos Ladicorbic
>

-- 
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] ISP scaling A20

2016-11-24 Thread Milos Ladni 

If anybody else is interesting there is my project:
https://groups.google.com/forum/#!topic/linux-sunxi/pI0orsfdh_U

--
Milos Ladicorbic

-- 
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] PoC tvin2jpeg_h264 with veisp scaling

2016-11-24 Thread Milos Ladni 
Hello,

This is yet another Proof of Concept analogue TV decoder (TV-IN) and 
hardware accelerated H264-JPEG encoder with VEISP scaling for sunxi.
This example capture frames from tvin (CVBS) scale it to VGA or QVGA and 
simultaneous encode frame to jpeg image and h264 stream.
sunxi-tvin2jpeg_h264 

--
Milos Ladicorbic

-- 
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 resend v3] ASoC: sun4i-codec: Add "Right Mixer" to "Line Out Mono Diff." route

2016-11-24 Thread Mark Brown 
On Thu, Nov 24, 2016 at 07:46:49PM +0800, Chen-Yu Tsai wrote:

> This patch seems to have fallen through the cracks.

No, nobody has reviewed it and normally there's some review for sunxi
patches.

-- 
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 resend v3] ASoC: sun4i-codec: Add "Right Mixer" to "Line Out Mono Diff." route

2016-11-24 Thread Chen-Yu Tsai 
The mono differential output for "Line Out" downmixes the stereo audio
from the mixer, instead of just taking the left channel.

Add a route from the "Right Mixer" to "Line Out Source Playback Route"
through the "Mono Differential" path, so DAPM doesn't shut down
everything if the left channel is muted.

Fixes: 0f909f98d7cb ("ASoC: sun4i-codec: Add support for A31 Line Out
  playback")
Signed-off-by: Chen-Yu Tsai 
---

This patch seems to have fallen through the cracks.

---
 sound/soc/sunxi/sun4i-codec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 092fdcf6de95..b11b0ad4dfbe 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1047,6 +1047,7 @@ static const struct snd_soc_dapm_route 
sun6i_codec_codec_dapm_routes[] = {
{ "Line Out Source Playback Route", "Stereo", "Left Mixer" },
{ "Line Out Source Playback Route", "Stereo", "Right Mixer" },
{ "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+   { "Line Out Source Playback Route", "Mono Differential", "Right Mixer" 
},
{ "LINEOUT", NULL, "Line Out Source Playback Route" },
 
/* ADC Routes */
-- 
2.10.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] ARM: dts: sun6i: hummingbird: Enable USB OTG

2016-11-24 Thread Chen-Yu Tsai 
The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
VBUS detection and control.

Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
USB OTG, as that is the hardware default.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 83643bbd51dc..f094eeb6c499 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -248,6 +248,7 @@
reg = <0x68>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   x-powers,drive-vbus-en;
};
 };
 
@@ -306,6 +307,11 @@
regulator-name = "vcc-dram";
 };
 
+_drivevbus {
+   regulator-name = "usb0-vbus";
+   status = "okay";
+};
+
 _usb1_vbus {
gpio = < 7 24 GPIO_ACTIVE_HIGH>; /* PH24 */
status = "okay";
@@ -330,12 +336,25 @@
status = "okay";
 };
 
+_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
+_power_supply {
+   status = "okay";
+};
+
 _vbus_pin_a {
/* different pin from sunxi-common-regulators */
pins = "PH24";
 };
 
  {
+   usb0_id_det-gpio = < 0 15 GPIO_ACTIVE_HIGH>; /* PA15 */
+   usb0_vbus_det-gpio = < 0 16 GPIO_ACTIVE_HIGH>; /* PA16 */
+   usb0_vbus_power-supply = <_power_supply>;
+   usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
 };
-- 
2.10.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 RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

2016-11-24 Thread Chen-Yu Tsai 
The panels shipped with Allwinner devices are very "generic", i.e.
they do not have model numbers or reliable sources of information
for the timings (that we know of) other than the fex files shipped
on them. The dot clock frequency provided in the fex files have all
been rounded to the nearest MHz, as that is the unit used in them.

We were using the simple panel "urt,umsh-8596md-t" as a substitute
for the A13 Q8 tablets in the absence of a specific model for what
may be many different but otherwise timing compatible panels. This
was usable without any visual artifacts or side effects, until the
dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
rgb: Validate the clock rate").

The reason this check fails is because the dotclock frequency for
this model is 33.26 MHz, which is not achievable with our dot clock
hardware, and the rate returned by clk_round_rate deviates slightly,
causing the driver to reject the display mode.

The LCD panels have some tolerance on the dot clock frequency, even
if it's not specified in their datasheets.

This patch adds a 5% tolerence to the dot clock check.

Signed-off-by: Chen-Yu Tsai 
---

The few LCD panel datasheets I found did not list minimums or maximums
for the dot clock rate. The 5% tolerance is just something I made up.
The point is to be able to use our dot clock, which doesn't have the
resolution needed to generate the exact clock rate requested. AFAIK
the sun4i driver is one of the strictest ones with regards to the dot
clock frequency. Some drivers don't even check it.

The clock rate given in vendor fex files are already rounded down to
MHz resolution. I doubt not using the exact rate as specified in simple
panels would cause any issues. But my experience is limited here.
Feedback on this is requested.

---
 drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index d198ad7e5323..66ad86afa561 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -93,11 +93,12 @@ static int sun4i_rgb_mode_valid(struct drm_connector 
*connector,
 
DRM_DEBUG_DRIVER("Vertical parameters OK\n");
 
+   /* Check against a 5% tolerance for the dot clock */
rounded_rate = clk_round_rate(tcon->dclk, rate);
-   if (rounded_rate < rate)
+   if (rounded_rate < rate * 19 / 20)
return MODE_CLOCK_LOW;
 
-   if (rounded_rate > rate)
+   if (rounded_rate > rate * 21 / 20)
return MODE_CLOCK_HIGH;
 
DRM_DEBUG_DRIVER("Clock rate OK\n");
-- 
2.10.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: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Andre Przywara 
On 24/11/16 10:55, Maxime Ripard wrote:
> On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara  
>> wrote:
>>> Hi,
>>>
>>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
 Hi,

 On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
 wrote:
> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> have arm64 capable cores. Add the generic sunxi config symbol to allow
> the driver to be selected by arm64 Kconfigs, which don't feature
> SoC specific MACH_ configs.
>
> Signed-off-by: Andre Przywara 
> ---
>  drivers/dma/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index af63a6b..003c284 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -157,7 +157,7 @@ config DMA_SUN4I
>
>  config DMA_SUN6I
> tristate "Allwinner A31 SoCs DMA support"
> -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI

 AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
 (And I don't have to add MACH_SUN9I later :) )
>>>
>>> Sure, admittedly it was just a quick hack to get things going.
>>> Actually I don't know why we had a *depend* on those MACH_s before. I
>>> think technically it does not depend on a certain SoC (having the
>>> COMPILE_TEST in there hints on that). So what about:
>>
>> It was really because this DMA engine only comes with the later
>> SoCs. We have dma-sun4i for the older one.
> 
> Indeed.
> 
>> But yes, there's no reason why you can't build it for the earlier
>> SoC. It just doesn't get used.
> 
> I'm still in favor of keeping the depends on. There's no point of
> compiling something we know have zero chance of running.
> 
> (But that would be (ARCH_SUNXI && ARM64))

I am OK with that, just wondering if there is a definition of what
"depends" really means. My impression what that it's a about code
dependencies (requires a certain subsystem, for instance), not really if
it's useful in a particular configuration.

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.

[linux-sunxi] Re: [RFC PATCH 3/5] arm64: defconfig: sunxi: include options for Allwinner H5 SoC

2016-11-24 Thread Andre Przywara 
Hi,

On 24/11/16 11:01, Chen-Yu Tsai wrote:
> On Thu, Nov 24, 2016 at 6:57 PM, Maxime Ripard
>  wrote:
>> On Thu, Nov 24, 2016 at 01:17:13AM +, Andre Przywara wrote:
>>> The Allwinner H5 SoC is closely related to the H3 SoC, so select the
>>> basic pinctrl driver and the DMA driver to let a defconfig kernel boot
>>> on those boards.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  arch/arm64/Kconfig.platforms | 6 +-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>>> index cfbdf02..8300677 100644
>>> --- a/arch/arm64/Kconfig.platforms
>>> +++ b/arch/arm64/Kconfig.platforms
>>> @@ -5,8 +5,12 @@ config ARCH_SUNXI
>>>   select GENERIC_IRQ_CHIP
>>>   select PINCTRL
>>>   select PINCTRL_SUN50I_A64
>>> + select PINCTRL_SUN8I_H3
>>> + select PINCTRL_SUN8I_H3_R
>>> + select DMA_SUN6I
>>
>> I'm not sure I want to get an ever growing select which will be an
>> union of all the drivers that all the arm64 Allwinner SoCs will
>> require.
>>
>> Select leaves no option to disable that option, and we have defconfig
>> to deal with that nicely.
> I have to agree. We should only select things that aren't selectable
> by the user. In our case, that's only the pinctrl drivers.

Right, I missed that.

> We should use default y (ARCH_SUNXI && ARM64) for every driver that
> has a prompt entry in Kconfig.

Sounds like a plan. I will look into this.

Thanks,
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.

[linux-sunxi] Re: [RFC PATCH 0/5] arm64: Allwinner H5 support

2016-11-24 Thread Andre Przywara 
Hi Maxime,

thanks for looking at this.

On 24/11/16 10:59, Maxime Ripard wrote:
> On Thu, Nov 24, 2016 at 01:17:10AM +, Andre Przywara wrote:
>> This series adds support for the recently released Allwinner H5 SoC [1] and
>> the Orange Pi PC 2 board [2].
>> This exercise is rather easy this time, since the new SoC is very similar
>> to the existing H3 SoC and can thus share a lot of support.
>> To express this, the first patch splits the H3 .dtsi to allow reusing
>> it later. The last two patches add the H5 .dtsi and the .dts for the
>> first available board featuring this chip, based on that shared base DT.
>>
>> This is some early version, it's based on a merge of various -for-4.10
>> branches from Maxime's repository.
>> I can boot this on the OPi board and MMC and USB seem to work fine.
>> I haven't tested any other peripherals yet.
>> Some open issues:
>> - The naming: Following the Allwinner scheme this should be "sun50i-h5"
>> (which I use in this series), but it shares so much with the H3 that
>> "sun8i-h5" wouldn't be wrong either. It gets a bit weird with that shared
>> .dtsi, which I call sun8i-h3-h5.dtsi for now.
>> - The clocks and pinctrl look _almost_ similar. I may sound like a broken
>> record, but our habit of requiring kernel support for those almost identical
>> SoCs really bites us now. As the MMC got updated, I fear there is _one_
>> additional pin that we need for the HS400 transfer mode. Also I am afraid
>> the MMC clock may be slightly different due to the advanced MMC support.
>> At the moment this is not an issue, as the driver only support DDR50 at
>> most anyway, so we get away with it now.
>> I wonder if it's feasible to add those things to the existing H3 clocks
>> and pinctrl to avoid another set of drivers.
>> - I just see that I missed those patches that add just the names to the
>> binding docs. I will send them once we agreed on the naming.
> 
> I don't have any major comments but I guess it all depends on the DT
> maintainers view on the symbolic link to share the DTSI.

I am curious too ;-)
But I saw symlinks for the RaspberryPi 3 (check
arch/arm64/boot/dts/broadcom) and VExpress, so I picked that low hanging
fruit ;-)

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.

[linux-sunxi] Re: [RFC PATCH 3/5] arm64: defconfig: sunxi: include options for Allwinner H5 SoC

2016-11-24 Thread Chen-Yu Tsai 
On Thu, Nov 24, 2016 at 6:57 PM, Maxime Ripard
 wrote:
> On Thu, Nov 24, 2016 at 01:17:13AM +, Andre Przywara wrote:
>> The Allwinner H5 SoC is closely related to the H3 SoC, so select the
>> basic pinctrl driver and the DMA driver to let a defconfig kernel boot
>> on those boards.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm64/Kconfig.platforms | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index cfbdf02..8300677 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -5,8 +5,12 @@ config ARCH_SUNXI
>>   select GENERIC_IRQ_CHIP
>>   select PINCTRL
>>   select PINCTRL_SUN50I_A64
>> + select PINCTRL_SUN8I_H3
>> + select PINCTRL_SUN8I_H3_R
>> + select DMA_SUN6I
>
> I'm not sure I want to get an ever growing select which will be an
> union of all the drivers that all the arm64 Allwinner SoCs will
> require.
>
> Select leaves no option to disable that option, and we have defconfig
> to deal with that nicely.

I have to agree. We should only select things that aren't selectable
by the user. In our case, that's only the pinctrl drivers.

We should use default y (ARCH_SUNXI && ARM64) for every driver that
has a prompt entry in Kconfig.

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: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Maxime Ripard 
On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara  
> wrote:
> > Hi,
> >
> > On 24/11/16 04:16, Chen-Yu Tsai wrote:
> >> Hi,
> >>
> >> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
> >> wrote:
> >>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> >>> have arm64 capable cores. Add the generic sunxi config symbol to allow
> >>> the driver to be selected by arm64 Kconfigs, which don't feature
> >>> SoC specific MACH_ configs.
> >>>
> >>> Signed-off-by: Andre Przywara 
> >>> ---
> >>>  drivers/dma/Kconfig | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >>> index af63a6b..003c284 100644
> >>> --- a/drivers/dma/Kconfig
> >>> +++ b/drivers/dma/Kconfig
> >>> @@ -157,7 +157,7 @@ config DMA_SUN4I
> >>>
> >>>  config DMA_SUN6I
> >>> tristate "Allwinner A31 SoCs DMA support"
> >>> -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> >>> +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> >>
> >> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> >> (And I don't have to add MACH_SUN9I later :) )
> >
> > Sure, admittedly it was just a quick hack to get things going.
> > Actually I don't know why we had a *depend* on those MACH_s before. I
> > think technically it does not depend on a certain SoC (having the
> > COMPILE_TEST in there hints on that). So what about:
> 
> It was really because this DMA engine only comes with the later
> SoCs. We have dma-sun4i for the older one.

Indeed.

> But yes, there's no reason why you can't build it for the earlier
> SoC. It just doesn't get used.

I'm still in favor of keeping the depends on. There's no point of
compiling something we know have zero chance of running.

(But that would be (ARCH_SUNXI && ARM64))

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 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Andre Przywara 
Hi,

On 24/11/16 09:30, Chen-Yu Tsai wrote:
> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara  
> wrote:
>> Hi,
>>
>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
>>> wrote:
 The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
 have arm64 capable cores. Add the generic sunxi config symbol to allow
 the driver to be selected by arm64 Kconfigs, which don't feature
 SoC specific MACH_ configs.

 Signed-off-by: Andre Przywara 
 ---
  drivers/dma/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index af63a6b..003c284 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -157,7 +157,7 @@ config DMA_SUN4I

  config DMA_SUN6I
 tristate "Allwinner A31 SoCs DMA support"
 -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
 +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
>>>
>>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
>>> (And I don't have to add MACH_SUN9I later :) )
>>
>> Sure, admittedly it was just a quick hack to get things going.
>> Actually I don't know why we had a *depend* on those MACH_s before. I
>> think technically it does not depend on a certain SoC (having the
>> COMPILE_TEST in there hints on that). So what about:
> 
> It was really because this DMA engine only comes with the later
> SoCs. We have dma-sun4i for the older one. But yes, there's no
> reason why you can't build it for the earlier SoC. It just doesn't
> get used.
> 
>>
>> depends on ARCH_SUNXI || COMPILE_TEST
>>
>> and maybe:
>>
>> default y if MACH_SUN6I || MACH_SUN8I
>>
>> Though I see that both multi_v7_defconfig and sunxi_defconfig explicitly
>> set this, so this wouldn't be needed?
> 
> I guess it's just nice to get stuff out of defconfig?
> Why not go all the way and just have
> 
> default y if ARCH_SUNXI

Well, I am all for it, but I had the impression that there is a lot of
opposition against this approach. Apparently people still want to save
some bytes by building a kernel tailored to one particular SoC.
So I didn't dare to come up with this one.
But it should work to use "# DMA_SUN6I is not selected" in a particular
.config or defconfig to deselect it, right?

Waiting for Maxime's opinion here.

(And also need to check whether the DMA really works on ARM64.
Surprisingly the code compiled cleanly, but I am wondering whether it
properly deals with 32-bit limitation of this controller. I just needed
it because the H3 DT references DMA for SPI and UART).

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.

[linux-sunxi] Re: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Chen-Yu Tsai 
On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara  wrote:
> Hi,
>
> On 24/11/16 04:16, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
>> wrote:
>>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
>>> have arm64 capable cores. Add the generic sunxi config symbol to allow
>>> the driver to be selected by arm64 Kconfigs, which don't feature
>>> SoC specific MACH_ configs.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  drivers/dma/Kconfig | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index af63a6b..003c284 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -157,7 +157,7 @@ config DMA_SUN4I
>>>
>>>  config DMA_SUN6I
>>> tristate "Allwinner A31 SoCs DMA support"
>>> -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
>>> +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
>>
>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
>> (And I don't have to add MACH_SUN9I later :) )
>
> Sure, admittedly it was just a quick hack to get things going.
> Actually I don't know why we had a *depend* on those MACH_s before. I
> think technically it does not depend on a certain SoC (having the
> COMPILE_TEST in there hints on that). So what about:

It was really because this DMA engine only comes with the later
SoCs. We have dma-sun4i for the older one. But yes, there's no
reason why you can't build it for the earlier SoC. It just doesn't
get used.

>
> depends on ARCH_SUNXI || COMPILE_TEST
>
> and maybe:
>
> default y if MACH_SUN6I || MACH_SUN8I
>
> Though I see that both multi_v7_defconfig and sunxi_defconfig explicitly
> set this, so this wouldn't be needed?

I guess it's just nice to get stuff out of defconfig?
Why not go all the way and just have

default y if ARCH_SUNXI

ChenYu

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

[linux-sunxi] Re: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs

2016-11-24 Thread Andre Przywara 
Hi,

On 24/11/16 04:16, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara  
> wrote:
>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
>> have arm64 capable cores. Add the generic sunxi config symbol to allow
>> the driver to be selected by arm64 Kconfigs, which don't feature
>> SoC specific MACH_ configs.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  drivers/dma/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index af63a6b..003c284 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -157,7 +157,7 @@ config DMA_SUN4I
>>
>>  config DMA_SUN6I
>> tristate "Allwinner A31 SoCs DMA support"
>> -   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
>> +   depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> 
> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> (And I don't have to add MACH_SUN9I later :) )

Sure, admittedly it was just a quick hack to get things going.
Actually I don't know why we had a *depend* on those MACH_s before. I
think technically it does not depend on a certain SoC (having the
COMPILE_TEST in there hints on that). So what about:

depends on ARCH_SUNXI || COMPILE_TEST

and maybe:

default y if MACH_SUN6I || MACH_SUN8I

Though I see that both multi_v7_defconfig and sunxi_defconfig explicitly
set this, so this wouldn't be needed?

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.