[linux-sunxi] Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

2016-10-27 Thread Maxime Ripard 
On Tue, Oct 25, 2016 at 04:14:41PM +0200, Jean-Francois Moine wrote:
> > > +Display controller
> > > +==
> > > +
> > > +Required properties:
> > > +
> > > +- compatible: value should be one of the following
> > > + "allwinner,sun8i-a83t-display-engine"
> > > + "allwinner,sun8i-h3-display-engine"
> > > +
> > > +- clocks: must include clock specifiers corresponding to entries in the
> > > + clock-names property.
> > > +
> > > +- clock-names: must contain
> > > + "gate": for DE activation
> > > + "clock": DE clock
> > 
> > We've been calling them bus and mod.
> 
> I can understand "bus" (which is better than "apb"), but why "mod"?

Allwinner has been calling the clocks that are supposed to generate
the external signals (depending on where you were looking) module or
mod clocks (which is also why we have mod in the clock
compatibles). The module 1 clocks being used for the audio and the
module 0 for the rest (SPI, MMC, NAND, display, etc.)

> > > +
> > > +- resets: phandle to the reset of the device
> > > +
> > > +- ports: phandle's to the LCD ports
> > 
> > Please use the OF graph.
> 
> These ports are references to the graph of nodes. See
>   http://www.kernelhub.org/?msg=911825=2

In an OF-graph, your phandle to the LCD controller would be replaced
by an output endpoint.

> 
>   [snip]
> > > +struct tcon {
> > > + u32 gctl;
> > > +#define  TCON_GCTL_TCON_En BIT(31)
> > > + u32 gint0;
> > > +#define  TCON_GINT0_TCON1_Vb_Int_En BIT(30)
> > > +#define  TCON_GINT0_TCON1_Vb_Int_Flag BIT(14)
> > > + u32 gint1;
> > > + u32 dum0[13];
> > > + u32 tcon0_ctl;  /* 0x40 */
> > > +#define  TCON0_CTL_TCON_En BIT(31)
> > > + u32 dum1[19];
> > > + u32 tcon1_ctl;  /* 0x90 */
> > > +#define  TCON1_CTL_TCON_En BIT(31)
> > > +#define  TCON1_CTL_Interlace_En BIT(20)
> > > +#define  TCON1_CTL_Start_Delay_SHIFT 4
> > > +#define  TCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
> > > + u32 basic0; /* XI/YI */
> > > + u32 basic1; /* LS_XO/LS_YO */
> > > + u32 basic2; /* XO/YO */
> > > + u32 basic3; /* HT/HBP */
> > > + u32 basic4; /* VT/VBP */
> > > + u32 basic5; /* HSPW/VSPW */
> > > + u32 dum2;
> > > + u32 ps_sync;/* 0xb0 */
> > > + u32 dum3[15];
> > > + u32 io_pol; /* 0xf0 */
> > > +#define  TCON1_IO_POL_IO0_inv BIT(24)
> > > +#define  TCON1_IO_POL_IO1_inv BIT(25)
> > > +#define  TCON1_IO_POL_IO2_inv BIT(26)
> > > + u32 io_tri;
> > > + u32 dum4[2];
> > > +
> > > + u32 ceu_ctl;/* 0x100 */
> > > +#define TCON_CEU_CTL_ceu_en BIT(31)
> > > + u32 dum5[3];
> > > + u32 ceu_rr;
> > > + u32 ceu_rg;
> > > + u32 ceu_rb;
> > > + u32 ceu_rc;
> > > + u32 ceu_gr;
> > > + u32 ceu_gg;
> > > + u32 ceu_gb;
> > > + u32 ceu_gc;
> > > + u32 ceu_br;
> > > + u32 ceu_bg;
> > > + u32 ceu_bb;
> > > + u32 ceu_bc;
> > > + u32 ceu_rv;
> > > + u32 ceu_gv;
> > > + u32 ceu_bv;
> > > + u32 dum6[45];
> > > +
> > > + u32 mux_ctl;/* 0x200 */
> > > + u32 dum7[63];
> > > +
> > > + u32 fill_ctl;   /* 0x300 */
> > > + u32 fill_start0;
> > > + u32 fill_end0;
> > > + u32 fill_data0;
> > > +};
> > 
> > Please use defines instead of the structures.
> 
> I think that structures are more readable.

That's not really the point. No one in the kernel uses it (and even
you use defines for registers offset in some places of that
patch). And then you have André arguments.

> > > +void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
> > > +{
> > > + struct priv *priv = drm->dev_private;
> > > + struct lcd *lcd = priv->lcds[crtc];
> > > +
> > > + tcon_write(lcd->mmio, gint0,
> > > +  tcon_read(lcd->mmio, gint0) &
> > > + ~TCON_GINT0_TCON1_Vb_Int_En);
> > > +}
> > > +
> > > +/* panel functions */
> > 
> > Panel functions? In the CRTC driver?
> 
> Yes, dumb panel.

What do you mean by that? Using a Parallel/RGB interface?

> 
> > > +static void de2_set_frame_timings(struct lcd *lcd)
> > > +{
> > > + struct drm_crtc *crtc = >crtc;
> > > + const struct drm_display_mode *mode = >mode;
> > > + int interlace = mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 1;
> > > + int start_delay;
> > > + u32 data;
> > > +
> > > + data = XY(mode->hdisplay - 1, mode->vdisplay / interlace - 1);
> > > + tcon_write(lcd->mmio, basic0, data);
> > > + tcon_write(lcd->mmio, basic1, data);
> > > + tcon_write(lcd->mmio, basic2, data);
> > > + tcon_write(lcd->mmio, basic3,
> > > + XY(mode->htotal - 1,
> > > + mode->htotal - mode->hsync_start - 1));
> > > + tcon_write(lcd->mmio, basic4,
> > > + XY(mode->vtotal * (3 - interlace),
> > > +

Re: [linux-sunxi] ISP scaling A20

2016-10-27 Thread Manuel Braga 
On Thu, 27 Oct 2016 03:54:49 -0700 (PDT) Milos Ladni
 wrote:
> Cool, arbitrary scaler is working now..:)
> Thank you a lot Manuel!

And thanks you too, for reporting that it works.

 
> By the way, divide-scaler is not working properly yet, maybe i do not
> need it anymore but It would be nice if i can contribute to the
> development of VE.

Is likely to be a wrong value written in a register, and talking about
this do check if MACC_ISP_OUTPIC_STRIDE has the stride of the *output*
matching the divisor used.
http://linux-sunxi.org/VE_Register_guide#MACC_ISP_PIC_STRIDE


> These days i will try to merge tvin and hw jpeg encoder in simple 
> application and i will push it on github. Maybe one day someone needs
> it..
> 
> > This looks familiar, but i can't remember what. 
> > Are you flushing the cache for the buffers? 
> 
> Yes, i am flushing the buffers. 
> I am think that hardware has some bugs or there are missing
> documentation how to do that.

If the above hit does not make it work, only by seeing the source code
is that i can try to spot the error.
Anything more is only guessing. 


-- 
Manuel Braga

-- 
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: [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

2016-10-27 Thread Maxime Ripard 
On Thu, Oct 27, 2016 at 05:13:25PM +0200, Jean-Francois Moine wrote:
> On Mon, 24 Oct 2016 14:34:49 +0200
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai  wrote:
> > > 
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > > 
> > > > If it's close to sun4i-i2s, you should probably rework that one to 
> > > > support
> > > > the newer SoCs.
> > > > 
> > > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > > >   by the CODECs)
> > > > 
> > > > I think this is wrong. I2S is only the DAI. You typically have a 
> > > > separate
> > > > platform driver for the whole card, or just use simple-card.
> > > 
> > > An other device is not needed. The layout is simple:
> > >   I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > > so, it cannot be the card device.
> > > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > > natural to use it to handle the card.
> > 
> > Still, duplicating the driver is not the solution. I agree with
> > Chen-Yu that we want to leverage the driver that is already there.
> 
> Hi Maxime and Chen-Yu,
> 
> After looking at the sun4i-i2s, I found 2 solutions for re-using its
> code in the DE2 HDMI context:
> 
> 1) either to split the sun4i-i2s driver into common I/O functions and
>slave CPU DAI,
> 
> 2) or to move the sun4i-i2s into a master CPU DAI.
> 
> (
>  some explanation about 'master' and 'slave': the master is the
>  component the device of which is also the sound card.
>  As the sound card uses the 'drvdata' of the device, this drvdata pointer
>  cannot be used by the master.
>  In the actual implementations:
>   - sun4i-i2s
>   master: card dev = codec dev, drvdata -> card
>   slave:  i2s dev (CPU DAI), drvdata -> i2s data
>   - sun8i-i2s
>   master: card dev = i2s dev (CPU DAI), drvdata -> card
>   slave:  codec dev (hdmi), drvdata -> codec data (audio/video)
> )
> 
> In the case 1, there is no functional change, just a source split.
> The sun8i-i2s will then use the common I/O functions.
> 
> In the case 2, the CODECs using the sun4i-i2s would have to move to
> slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
> In the 4.9, there is only one codec (sun4i-codec), so, the change
> is just to move the card creation and the use of drvdata in both
> codes.

I think you're mistaken. sun4i-codec has nothing to do with the I2S
driver. It's a driver for the (poorly named) Allwinner's Audio Codec
which features it's own DAI and Codec directly into the SoC.

The DAI being different from the I2S one.

However, we want to use any codec driver with the i2s driver,
including those in sound/soc/codecs, and we already have drivers for
them.

So I'm not sure either solution is a good one. Why not just make the
HDMI part a codec itself, and use the i2s driver as the CPU DAI, like
any other codec?

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 v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC

2016-10-27 Thread Mark Brown 
On Thu, Oct 27, 2016 at 07:16:34PM +0200, Jean-Francois Moine wrote:
> Chen-Yu Tsai  wrote:
> > There's already a driver for basically the same thing:

> > sound/soc/codec/hdmi-codec.c

> > You use it by registering a sub-device from your hdmi driver, with the
> > proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> > platforms already using it.

> I know that for a long time, and I will not use it on any account: it is
> a gasworks!

If there are problems with what's there then articulate them and fix
them, don't just open code something separate.  Just open coding
something else without any articulated reasoning is not helping things.

-- 
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 01/14] dma: sun6i-dma: Add burst case of 4

2016-10-27 Thread Maxime Ripard 
On Sun, Oct 23, 2016 at 06:31:07PM +0200, Jean-Francois Moine wrote:
> On Tue, 4 Oct 2016 18:55:54 +0200
> Maxime Ripard  wrote:
> 
> > On Tue, Oct 04, 2016 at 12:40:11PM +0200, Jean-Francois Moine wrote:
> > > On Tue,  4 Oct 2016 11:46:14 +0200
> > > Mylène Josserand  wrote:
> > > 
> > > > Add the case of a burst of 4 which is handled by the SoC.
> > > > 
> > > > Signed-off-by: Mylène Josserand 
> > > > ---
> > > >  drivers/dma/sun6i-dma.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > > > index 8346199..0485204 100644
> > > > --- a/drivers/dma/sun6i-dma.c
> > > > +++ b/drivers/dma/sun6i-dma.c
> > > > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > > > switch (maxburst) {
> > > > case 1:
> > > > return 0;
> > > > +   case 4:
> > > > +   return 1;
> > > > case 8:
> > > > return 2;
> > > > default:
> > > > -- 
> > > > 2.9.3
> > > 
> > > This patch has already been rejected by Maxime in the threads
> > >   http://www.spinics.net/lists/dmaengine/msg08610.html
> > > and
> > >   http://www.spinics.net/lists/dmaengine/msg08719.html
> > > 
> > > I hope you will find the way he wants for this maxburst to be added.
> > 
> > I was talking about something along these lines (not tested):
> 
> I wonder why you don't submit this yourself.

I thought you were the one who cared. You asked for what I had in
mind, here it is.

> > ---8<-
> > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> > index 83461994e418..573ac4608293 100644
> > --- a/drivers/dma/sun6i-dma.c
> > +++ b/drivers/dma/sun6i-dma.c
> > @@ -240,6 +240,8 @@ static inline s8 convert_burst(u32 maxburst)
> > switch (maxburst) {
> > case 1:
> > return 0;
> > +   case 4:
> > +   return 1;
> > case 8:
> > return 2;
> > default:
> > @@ -1110,11 +1112,19 @@ static int sun6i_dma_probe(struct platform_device 
> > *pdev)
> > sdc->slave.dst_addr_widths  = 
> > BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> >   
> > BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> >   
> > BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> > +   sdc->slave.dst_bursts   = BIT(1) | BIT(8);
> > +   sdc->slave.src_bursts   = BIT(1) | BIT(8);
> > sdc->slave.directions   = BIT(DMA_DEV_TO_MEM) |
> >   BIT(DMA_MEM_TO_DEV);
> > sdc->slave.residue_granularity  = DMA_RESIDUE_GRANULARITY_BURST;
> > sdc->slave.dev = >dev;
> >  
> > +   if (of_device_is_compatible(pdev->dev.of_node,
> > +   "allwinner,sun8i-h3-dma")) {
> > +   sdc->slave.dst_bursts |= BIT(4);
> > +   sdc->slave.src_bursts |= BIT(4);
> > +   }
> > +
> > sdc->pchans = devm_kcalloc(>dev, sdc->cfg->nr_max_channels,
> >sizeof(struct sun6i_pchan), GFP_KERNEL);
> > if (!sdc->pchans)
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index cc535a478bae..f7bbec24bb58 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -673,6 +673,8 @@ struct dma_filter {
> >   * each type of direction, the dma controller should fill (1 <<
> >   * ) and same should be checked by controller as well
> >   * @max_burst: max burst capability per-transfer
> > + * @dst_bursts: bitfield of the available burst sizes for the destination
> > + * @src_bursts: bitfield of the available burst sizes for the source
> 
> You did not define dst_bursts nor src_bursts.
> 
> >   * @residue_granularity: granularity of the transfer residue reported
> >   * by tx_status
> >   * @device_alloc_chan_resources: allocate resources and return the
> > @@ -800,6 +802,14 @@ struct dma_device {
> >  static inline int dmaengine_slave_config(struct dma_chan *chan,
> >   struct dma_slave_config *config)
> >  {
> > +   if (config->src_maxburst && config->device->src_bursts &&
> > +   !(BIT(config->src_maxburst) & config->device->src_bursts))
> 
> The maxburst may be as big as 4Kibytes, then, I am not sure that this
> code will work!
> 
> > +   return -EINVAL;
> > +
> > +   if (config->dst_maxburst && config->device->dst_bursts &&
> > +   !(BIT(config->dst_maxburst) & config->device->dst_bursts))
> > +   return -EINVAL;
> > +
> > if (chan->device->device_config)
> > return chan->device->device_config(chan, config);
> > ---8< 
> 
> Yes, I know that the burst size is always a power of 2.
> The best way to check it would be to change the {src,dts}_maxburst to a
> bitmap of the possible bursts as 0x0d for 1,4 and 8 bytes.

Re: [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC

2016-10-27 Thread Jean-Francois Moine 
On Fri, 28 Oct 2016 00:54:34 +0800
Chen-Yu Tsai  wrote:

> There's already a driver for basically the same thing:
> 
> sound/soc/codec/hdmi-codec.c
> 
> You use it by registering a sub-device from your hdmi driver, with the
> proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
> platforms already using it.

I know that for a long time, and I will not use it on any account: it is
a gasworks!

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

Re: [linux-sunxi] [PATCH v5 2/7] ASoC: sunxi: Add a simple HDMI CODEC

2016-10-27 Thread Chen-Yu Tsai 
On Fri, Oct 21, 2016 at 3:44 PM, Jean-Francois Moine  wrote:
> Allwinner's SoCs include support for both audio and video on HDMI.
> This patch defines a simple audio CODEC which may be used in sunxi
> HDMI video drivers.
>
> Signed-off-by: Jean-Francois Moine 

There's already a driver for basically the same thing:

sound/soc/codec/hdmi-codec.c

You use it by registering a sub-device from your hdmi driver, with the
proper platform_data and callbacks. Grep for HDMI_CODEC_DRV_NAME for
platforms already using it.

ChenYu

> ---
>  include/sound/sunxi_hdmi.h|  23 +
>  sound/soc/codecs/Kconfig  |   9 
>  sound/soc/codecs/Makefile |   2 +
>  sound/soc/codecs/sunxi-hdmi.c | 106 
> ++
>  4 files changed, 140 insertions(+)
>  create mode 100644 include/sound/sunxi_hdmi.h
>  create mode 100644 sound/soc/codecs/sunxi-hdmi.c
>
> diff --git a/include/sound/sunxi_hdmi.h b/include/sound/sunxi_hdmi.h
> new file mode 100644
> index 000..0986bb9
> --- /dev/null
> +++ b/include/sound/sunxi_hdmi.h
> @@ -0,0 +1,23 @@
> +#ifndef __SUNXI_HDMI_H__
> +#define __SUNXI_HDMI_H__
> +/*
> + * Copyright (C) 2016 Jean-François Moine
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +struct sunxi_hdmi_codec {
> +   u8 *eld;
> +   int (*set_audio_input)(struct device *dev,
> +   int enable,
> +   unsigned sample_rate,
> +   unsigned sample_bit);
> +};
> +
> +int sunxi_hdmi_codec_register(struct device *dev);
> +void sunxi_hdmi_codec_unregister(struct device *dev);
> +
> +#endif /* __SUNXI_HDMI_H__ */
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index c67667b..53385b1 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -131,6 +131,7 @@ config SND_SOC_ALL_CODECS
> select SND_SOC_STA529 if I2C
> select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
> select SND_SOC_STI_SAS
> +   select SND_SOC_SUNXI_HDMI
> select SND_SOC_TAS2552 if I2C
> select SND_SOC_TAS5086 if I2C
> select SND_SOC_TAS571X if I2C
> @@ -793,6 +794,14 @@ config SND_SOC_STAC9766
>  config SND_SOC_STI_SAS
> tristate "codec Audio support for STI SAS codec"
>
> +config SND_SOC_SUNXI_HDMI
> +   tristate "Allwinner sunxi HDMI Support"
> +   default m if DRM_SUNXI_DE2_HDMI=m
> +   default y if DRM_SUNXI_DE2_HDMI=y
> +   select SND_PCM_ELD
> +   help
> + Enable HDMI audio output
> +
>  config SND_SOC_TAS2552
> tristate "Texas Instruments TAS2552 Mono Audio amplifier"
> depends on I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 958cd49..35804eb 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -139,6 +139,7 @@ snd-soc-sta350-objs := sta350.o
>  snd-soc-sta529-objs := sta529.o
>  snd-soc-stac9766-objs := stac9766.o
>  snd-soc-sti-sas-objs := sti-sas.o
> +snd-soc-sunxi-hdmi-objs := sunxi-hdmi.o
>  snd-soc-tas5086-objs := tas5086.o
>  snd-soc-tas571x-objs := tas571x.o
>  snd-soc-tas5720-objs := tas5720.o
> @@ -359,6 +360,7 @@ obj-$(CONFIG_SND_SOC_STA350)   += snd-soc-sta350.o
>  obj-$(CONFIG_SND_SOC_STA529)   += snd-soc-sta529.o
>  obj-$(CONFIG_SND_SOC_STAC9766) += snd-soc-stac9766.o
>  obj-$(CONFIG_SND_SOC_STI_SAS)  += snd-soc-sti-sas.o
> +obj-$(CONFIG_SND_SOC_SUNXI_HDMI)   += snd-soc-sunxi-hdmi.o
>  obj-$(CONFIG_SND_SOC_TAS2552)  += snd-soc-tas2552.o
>  obj-$(CONFIG_SND_SOC_TAS5086)  += snd-soc-tas5086.o
>  obj-$(CONFIG_SND_SOC_TAS571X)  += snd-soc-tas571x.o
> diff --git a/sound/soc/codecs/sunxi-hdmi.c b/sound/soc/codecs/sunxi-hdmi.c
> new file mode 100644
> index 000..0d08676
> --- /dev/null
> +++ b/sound/soc/codecs/sunxi-hdmi.c
> @@ -0,0 +1,106 @@
> +/*
> + * Allwinner HDMI codec
> + *
> + * Copyright (C) 2016 Jean-Francois Moine 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sound/sunxi_hdmi.h"
> +
> +#define SUNXI_HDMI_FORMATS (SNDRV_PCM_FMTBIT_S8 | \
> + SNDRV_PCM_FMTBIT_S16_LE | \
> + SNDRV_PCM_FMTBIT_S20_3LE | \
> + SNDRV_PCM_FMTBIT_S24_LE | \
> + SNDRV_PCM_FMTBIT_S32_LE)
> +
> +static int sunxi_hdmi_codec_startup(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)

[linux-sunxi] Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias

2016-10-27 Thread Andreas Färber 
Hi André,

Am 26.10.2016 um 22:50 schrieb André Przywara:
> On 26/10/16 19:51, Jagan Teki wrote:
>> On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara  
>> wrote:
>>> The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
>>> missing an alias entry to trigger the driver instantiation by U-Boot.
>>> Add the line to point U-Boot to the Ethernet DT node.
>>> This enables TFTP boot on the Pine64.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi 
>>> b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>> index d5a7249..c0fde44 100644
>>> --- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>> +++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>> @@ -46,6 +46,7 @@
>>>
>>> aliases {
>>> serial0 = 
>>> +   ethernet0 = 
>>
>> Better to have this alias on sun50i-a64.dtsi since the node is defined there?
> 
> Mmh, I find examples for both ways (.dtsi vs. .dts) in the kernel. I
> need to learn what's the best practice here.

Last I was told by kernel maintainers (in an Amlogic context) aliases
should be in the board's .dts[i] so that only the enabled nodes get
numbered. If they're enabled at .dtsi level then I guess nothing is
wrong with having the alias there. So I'm guessing the patch is good.

Reviewed-by: Andreas Färber 

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

-- 
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: [alsa-devel] [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

2016-10-27 Thread Jean-Francois Moine 
On Mon, 24 Oct 2016 14:34:49 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Sun, Oct 23, 2016 at 09:45:03AM +0200, Jean-Francois Moine wrote:
> > On Sun, 23 Oct 2016 09:33:16 +0800
> > Chen-Yu Tsai  wrote:
> > 
> > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > - it handles the H3
> > > 
> > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > the newer SoCs.
> > > 
> > > > - it creates the sound card (with sun4i-i2s, the sound card is created
> > > >   by the CODECs)
> > > 
> > > I think this is wrong. I2S is only the DAI. You typically have a separate
> > > platform driver for the whole card, or just use simple-card.
> > 
> > An other device is not needed. The layout is simple:
> > I2S_controller (CPU DAI) <-> HDMI_CODEC (CODEC DAI)
> > The HDMI CODEC is supported by the HDMI video driver (only one device),
> > so, it cannot be the card device.
> > ASoC does not use the CPU DAI device (I2S_controller), so, it is
> > natural to use it to handle the card.
> 
> Still, duplicating the driver is not the solution. I agree with
> Chen-Yu that we want to leverage the driver that is already there.

Hi Maxime and Chen-Yu,

After looking at the sun4i-i2s, I found 2 solutions for re-using its
code in the DE2 HDMI context:

1) either to split the sun4i-i2s driver into common I/O functions and
   slave CPU DAI,

2) or to move the sun4i-i2s into a master CPU DAI.

(
 some explanation about 'master' and 'slave': the master is the
 component the device of which is also the sound card.
 As the sound card uses the 'drvdata' of the device, this drvdata pointer
 cannot be used by the master.
 In the actual implementations:
  - sun4i-i2s
master: card dev = codec dev, drvdata -> card
slave:  i2s dev (CPU DAI), drvdata -> i2s data
  - sun8i-i2s
master: card dev = i2s dev (CPU DAI), drvdata -> card
slave:  codec dev (hdmi), drvdata -> codec data (audio/video)
)

In the case 1, there is no functional change, just a source split.
The sun8i-i2s will then use the common I/O functions.

In the case 2, the CODECs using the sun4i-i2s would have to move to
slave CODEC DAI, i.e. the card is created by the sun4i-i2s code.
In the 4.9, there is only one codec (sun4i-codec), so, the change
is just to move the card creation and the use of drvdata in both
codes.

In either cases, I could not check if this changes raise some
regression on the sun4i SoCs side. Then, I'd be glad to know:
- which solution suits you?
- are you ready to do and test the needed changes at the sun4i side?

-- 
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 02/12] ASoC: dapm: Implement stereo mixer control support

2016-10-27 Thread Chen-Yu Tsai 
On Thu, Oct 27, 2016 at 1:50 AM, Mark Brown  wrote:
> On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:
>
>>   /* find dapm widget path assoc with kcontrol */
>>   dapm_kcontrol_for_each_path(path, kcontrol) {
>> + /*
>> +  * If status for the second channel was given ( >= 0 ),
>> +  * consider the second and later paths as the second
>> +  * channel.
>> +  */
>> + if (found && rconnect >= 0)
>> + soc_dapm_connect_path(path, rconnect, "mixer update");
>> + else
>> + soc_dapm_connect_path(path, connect, "mixer update");
>>   found = 1;
>> - soc_dapm_connect_path(path, connect, "mixer update");
>
> This really only works for two channels with the current inteface - the
> comment makes it sound like it'll work for more but we can only pass in
> two (and there's only support for specifying two everywhere).

I could rework it to pass a list of connected status' and the number
of elements instead, but it wouldn't work well for situations where
the number of channels on the kcontrol != the number of paths. I'm not
sure if that's even a valid setup, but it does work with the current
core code.

On the other hand, are there kcontrols that are multi-channel
(> 2 channels)?

I'm inclined to just fixup the comment to make it clear that the
implementation supports stereo, i.e. 2 channels, only.

>
>> - change = dapm_kcontrol_set_value(kcontrol, val);
>> + /* This assumes field width < (bits in unsigned int / 2) */
>> + change = dapm_kcontrol_set_value(kcontrol, val | (rval << width));
>
> That seems like a bit of an assumption in cases where we've got a single
> control for both power and volume?  They're very rare though, I'm not
> even sure any exist.  It'd be good to have a check in the code just in
> case it does come up, it'll likely be a nightmare to debug if someone
> does run into it.

Agreed. I'll put a check and warning before it.

>
> Otherwise I think this makes sense.

Thanks for the review!

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

2016-10-27 Thread Milos Ladni 
Cool, arbitrary scaler is working now..:)
Thank you a lot Manuel!

By the way, divide-scaler is not working properly yet, maybe i do not need 
it anymore but It would be nice if i can contribute to the development of 
VE.
These days i will try to merge tvin and hw jpeg encoder in simple 
application and i will push it on github. Maybe one day someone needs it..

> This looks familiar, but i can't remember what. 
> Are you flushing the cache for the buffers? 

Yes, i am flushing the buffers. 
I am think that hardware has some bugs or there are missing documentation 
how to do that.
--
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] AMBA Bus

2016-10-27 Thread deco33000 
Thanks a lot Andre!-- Mark01:34, 27 October 2016, "André Przywara" :On 26/10/16 08:39, Mark L. wrote:Hi Mark, I have a doubt I would like to clear. When you buy a Allwinner H3, one doesn't have to mess with the AMBA specification, right?  We just use the H3 interface we got (clock, secure memory) and that is it? Isn't this specification for hardware (Chip) makers only? Even a PCB maker shouldn't be too concerned by it as well (except to connect the right pins with the right traces)Yes, usually on this side of the SoC you don't have to care too muchabout AMBA, as it is an on-chip interconnect only. So there are no "AMBApins" exposed on the package, for instance.Sometime you see AMBA terms "shine through" in the documentation, forinstance AHB and APB are AMBA names, Allwinner named the respectiveclocks this way.Also you have to be aware that this is a bus system external to the*core* (but not the SoC), so the usual concerns about buses apply here:delay, arbitration, possible aborts, cache coherency and so on. Sowriting something to an MMIO device is not guaranteed to landimmediately and in every case there, for instance. But this is notreally AMBA specific, but applies to other peripheral buses like PCI aswell.But you are right that from a software point of view (and even as a PCBdesigner) you should not need the AMBA specification to get yourself going.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.



-- 
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 v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO

2016-10-27 Thread Chen-Yu Tsai 
On Thu, Oct 27, 2016 at 2:40 PM, Archit Taneja  wrote:
>
>
> On 10/25/2016 02:29 PM, Chen-Yu Tsai wrote:
>>
>> On Tue, Oct 25, 2016 at 4:09 PM, Archit Taneja 
>> wrote:
>>>
>>> Hi,
>>>
>>> On 10/20/2016 09:13 AM, Chen-Yu Tsai wrote:


 Some rgb-to-vga bridges have an enable GPIO, either directly tied to
 an enable pin on the bridge IC, or indirectly controlling a power
 switch.

 Add support for it.
>>>
>>>
>>>
>>> Does the bridge on your platform have an active/passive DAC, or is it a
>>> smarter encoder chip that is capable of doing more? If so, it might be
>>> good to have a separate DT compatible string to it, like what's done
>>> in the patch titled:
>>>
>>> drm: bridge: vga-dac: Add adi,adv7123 compatible string
>>>
>>> so that we can switch to a different driver later if needed.
>>
>>
>> The chip is GM7123. It is not configurable. It just takes the LCD RGB/SYNC
>> signals and converts them to analog. The only things you can change are
>> putting it into sleep mode and tweaking the output drive strength by
>
>
> Is sleep mode the thing that's controlled by this gpio?

Not on this particular board. The gpio controls the external LDO that
supplies 3.3V to VDD.

>
>> changing the external reference resistor. The latter would be a hardware
>> design decision. I would say this qualifies as "dumb".
>
>
> Yeah, I agree. I'd want feedback from Laurent too, since he had comments
> on the usage of the original dumb-vga-dac driver.
>
>>
>> I revisited the board schematics, and the enable GPIO actually toggles
>> an external LDO regulator. So this might be better modeled as a regulator
>> supply?
>
>
> If you model it as a regulator, how would you toggle the GPIO on your
> platform?
>
> Looking at the chip pin out, there is a 3.3V VDD supply needed for the
> chip, so it would be good to have an optional 'power' regulator supply
> anyway.

Yes, that it what I plan to do. I'll drop the enable-gpios property,
and add a power-supply property for the regulator.

Regards
ChenYu

>
> Archit
>
>
>>
>>
>> Thanks
>> ChenYu
>>
>>>
>>> Thanks,
>>> Archit
>>>
>>>

 Signed-off-by: Chen-Yu Tsai 
 ---
  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 28
 ++
  2 files changed, 30 insertions(+)

 diff --git
 a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 index 003bc246a270..d3484822bf77 100644
 --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
 @@ -16,6 +16,8 @@ graph bindings specified in
 Documentation/devicetree/bindings/graph.txt.
  - Video port 0 for RGB input
  - Video port 1 for VGA output

 +Optional properties:
 +- enable-gpios: GPIO pin to enable or disable the bridge

  Example
  ---
 diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
 b/drivers/gpu/drm/bridge/dumb-vga-dac.c
 index afec232185a7..b487e5e9b56d 100644
 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
 +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
 @@ -10,6 +10,7 @@
   * the License, or (at your option) any later version.
   */

 +#include 
  #include 
  #include 

 @@ -23,6 +24,7 @@ struct dumb_vga {
 struct drm_connectorconnector;

 struct i2c_adapter  *ddc;
 +   struct gpio_desc*enable_gpio;
  };

  static inline struct dumb_vga *
 @@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge
 *bridge)
 return 0;
  }

 +static void dumb_vga_enable(struct drm_bridge *bridge)
 +{
 +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
 +
 +   if (vga->enable_gpio)
 +   gpiod_set_value_cansleep(vga->enable_gpio, 1);
 +}
 +
 +static void dumb_vga_disable(struct drm_bridge *bridge)
 +{
 +   struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
 +
 +   if (vga->enable_gpio)
 +   gpiod_set_value_cansleep(vga->enable_gpio, 0);
 +}
 +
  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
 .attach = dumb_vga_attach,
 +   .enable = dumb_vga_enable,
 +   .disable= dumb_vga_disable,
  };

  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
 @@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device
 *pdev)
 return -ENOMEM;
 platform_set_drvdata(pdev, vga);

 +   vga->enable_gpio = devm_gpiod_get_optional(>dev, "enable",
 +  GPIOD_OUT_LOW);
 +