[linux-sunxi] Re: [U-Boot] [PATCH 2/2] sunxi: A64: enable USB support

2016-10-24 Thread Amit Tomer
Hello!

>
> Since the driver is dm-driven this config not need.

I tried not to use this config but then driver don't get compiled.

You're talking about   CONFIG_USB_EHCI and CONFIG_USB_EHCI_SUNXI, right ?

Thanks
Amit.

-- 
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 1/2] drivers: USB: OHCI: allow compilation for 64-bit targets

2016-10-24 Thread André Przywara
On 24/10/16 09:20, Jagan Teki wrote:
> On Sun, Oct 23, 2016 at 3:22 AM, André Przywara  
> wrote:
>> On 22/10/16 18:10, Jagan Teki wrote:
>>
>> Hi,
>>
>>> On Fri, Oct 21, 2016 at 6:54 AM, Andre Przywara  
>>> wrote:
 OHCI has a known limitation of allowing only 32-bit DMA buffer
 addresses, so we have a lot of u32 variables around, which are assigned
 to pointers and vice versa. This obviously creates issues with 64-bit
 systems, so the compiler complains here and there.
 To allow compilation for 64-bit boards which use only memory below 4GB
 anyway (and to avoid more invasive fixes), adjust some casts and types
 and assume that the EDs and TDs are all located in the lower 4GB.
 This fixes compilation of the OHCI driver for the Pine64.

 Signed-off-by: Andre Przywara 
 ---
  drivers/usb/host/ohci-hcd.c   | 21 +++--
  drivers/usb/host/ohci-sunxi.c |  2 +-
  drivers/usb/host/ohci.h   | 11 +++
  3 files changed, 19 insertions(+), 15 deletions(-)

 diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
 index ccbfc02..0f6d03e 100644
 --- a/drivers/usb/host/ohci-hcd.c
 +++ b/drivers/usb/host/ohci-hcd.c
 @@ -682,7 +682,7 @@ static int ep_link(ohci_t *ohci, ed_t *edi)
 ed->hwNextED = 0;
 flush_dcache_ed(ed);
 if (ohci->ed_controltail == NULL)
 -   ohci_writel(ed, >regs->ed_controlhead);
 +   ohci_writel((uintptr_t)ed, 
 >regs->ed_controlhead);
 else
 ohci->ed_controltail->hwNextED =
m32_swap((unsigned 
 long)ed);
 @@ -700,7 +700,7 @@ static int ep_link(ohci_t *ohci, ed_t *edi)
 ed->hwNextED = 0;
 flush_dcache_ed(ed);
 if (ohci->ed_bulktail == NULL)
 -   ohci_writel(ed, >regs->ed_bulkhead);
 +   ohci_writel((uintptr_t)ed, 
 >regs->ed_bulkhead);
 else
 ohci->ed_bulktail->hwNextED =
m32_swap((unsigned 
 long)ed);
 @@ -753,7 +753,7 @@ static void periodic_unlink(struct ohci *ohci, 
 volatile struct ed *ed,

 /* ED might have been unlinked through another path */
 while (*ed_p != 0) {
 -   if (((struct ed *)
 +   if (((struct ed *)(uintptr_t)
 m32_swap((unsigned long)ed_p)) == 
 ed) {
 *ed_p = ed->hwNextED;
 aligned_ed_p = (unsigned long)ed_p;
 @@ -762,7 +762,7 @@ static void periodic_unlink(struct ohci *ohci, 
 volatile struct ed *ed,
 aligned_ed_p + ARCH_DMA_MINALIGN);
 break;
 }
 -   ed_p = &(((struct ed *)
 +   ed_p = &(((struct ed *)(uintptr_t)
  m32_swap((unsigned 
 long)ed_p))->hwNextED);
 }
 }
 @@ -798,7 +798,7 @@ static int ep_unlink(ohci_t *ohci, ed_t *edi)
 if (ohci->ed_controltail == ed) {
 ohci->ed_controltail = ed->ed_prev;
 } else {
 -   ((ed_t *)m32_swap(
 +   ((ed_t *)(uintptr_t)m32_swap(
 *((__u32 *)>hwNextED)))->ed_prev = 
 ed->ed_prev;
 }
 break;
 @@ -819,7 +819,7 @@ static int ep_unlink(ohci_t *ohci, ed_t *edi)
 if (ohci->ed_bulktail == ed) {
 ohci->ed_bulktail = ed->ed_prev;
 } else {
 -   ((ed_t *)m32_swap(
 +   ((ed_t *)(uintptr_t)m32_swap(
  *((__u32 *)>hwNextED)))->ed_prev = 
 ed->ed_prev;
 }
 break;
 @@ -914,12 +914,13 @@ static void td_fill(ohci_t *ohci, unsigned int info,

 /* fill the old dummy TD */
 td = urb_priv->td [index] =
 -(td_t *)(m32_swap(urb_priv->ed->hwTailP) & 
 ~0xf);
 +(td_t *)(uintptr_t)
 +(m32_swap(urb_priv->ed->hwTailP) & ~0xf);

 td->ed = urb_priv->ed;
 td->next_dl_td = NULL;
 td->index = index;
 -   td->data = (__u32)data;
 +   td->data = (uintptr_t)data;
  #ifdef OHCI_FILL_TRACE
 if 

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

2016-10-24 Thread André Przywara
On 21/10/16 11:28, Hans de Goede wrote:
> Hi,
> 
> On 21-10-16 12:06, Andre Przywara wrote:
>> Hi,
>>
>> On 21/10/16 10:31, 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 = 
>>>
>>> I think alias doesn’t require for probing emac, it will straight away
>>> probed like
>>>
 dm tree
>>> 
>>> eth [ + ] ethernet@01c3
>>>
>>> Did you find any issue while detecting eth?
>>
>> Yes, it just didn't work ;-) I don't have a board here, but can post the
>> error message later tonight.


Net:   phy interface7

Error: ethernet@01c3 address not set.
No ethernet found.


>> In fact I was wondering about that already, maybe it's worth
>> investigating this further.

So the reason is that CONFIG_NET_RANDOM_ETHADDR isn't defined, so
without the DT alias triggering the SID MAC generation there will be
_no_ MAC address at all, which makes the driver give up.
AFAIK on the A64 the MAC generation from the SID serial number works
just fine, so we should in any case add the alias.

I can resend the patch with an amended commit message.

Cheers,
Andre.

>>
>> But aside from that I think the MAC address calculation based on the SID
>> serial number does not get triggered without an alias, so we need this
>> line anyway.
> 
> Correct, the MAC address code relies on the alias.
> 
> Regards,
> 
> Hans
> 

-- 
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 v4 6/9] clk: sunxi-ng: Add A64 clocks

2016-10-24 Thread Maxime Ripard
Hi Stephen,

On Thu, Oct 20, 2016 at 11:46:01AM -0700, Stephen Boyd wrote:
> On 10/11, Maxime Ripard wrote:
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
> > b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > new file mode 100644
> > index ..c0e96bf6d104
> > --- /dev/null
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> > +
> > +static int sun50i_a64_ccu_probe(struct platform_device *pdev)
> > +{
> > +   struct resource *res;
> > +   void __iomem *reg;
> > +   u32 val;
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   reg = devm_ioremap_resource(>dev, res);
> > +   if (IS_ERR(reg)) {
> > +   dev_err(>dev, "Could not map the clock registers\n");
> 
> devm_ioremap_resource() should already spit out an error.
> 
> > +   return PTR_ERR(reg);
> > +   }
> > +
> > +   /* Force the PLL-Audio-1x divider to 4 */
> > +   val = readl(reg + SUN50I_A64_PLL_AUDIO_REG);
> > +   val &= ~GENMASK(19, 16);
> > +   writel(val | (3 << 16), reg + SUN50I_A64_PLL_AUDIO_REG);
> > +
> > +   writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
> > +
> > +   return sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
> > +}
> > +
> > +static const struct of_device_id sun50i_a64_ccu_ids[] = {
> > +   { .compatible = "allwinner,sun50i-a64-ccu" },
> > +   { },
> 
> Nitpick: drop the comma

Thanks for your comments, it's fixed.

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 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu

2016-10-24 Thread Maxime Ripard
On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
> 
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> 
> Signed-off-by: Icenowy Zheng 

Cc'ing stable would be nice.

Apart from that, Acked-by: Maxime Ripard 

Thanks!
Maxime

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

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


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 3/7] drm: sunxi: add DE2 HDMI support

2016-10-24 Thread Maxime Ripard
Hi,

On Fri, Oct 21, 2016 at 10:08:06AM +0200, Jean-Francois Moine wrote:
> This patch adds a HDMI driver to the DE2 based Allwinner's SoCs
> as A83T and H3.
> Audio and video are supported.
> 
> Signed-off-by: Jean-Francois Moine 

Output from checkpatch:
total: 26 errors, 31 warnings, 70 checks, 1458 lines checked

Please run checkpatch before sending your patches.

Apart from that, this looks an awful lot like the designware HDMI
controller, for which a driver already exists. Any reason to create a
new driver from scratch?

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 3/4] Documentation: devicetree: add vendor prefix for Pine64

2016-10-24 Thread Maxime Ripard
Hi Jonathan,

On Fri, Oct 21, 2016 at 11:30:01AM +1100, Jonathan Liu wrote:
> On 21 October 2016 at 05:00, Maxime Ripard
>  wrote:
> > From: Andre Przywara 
> >
> > Signed-off-by: Andre Przywara 
> > Acked-by: Rob Herring 
> > Acked-by: Chen-Yu Tsai 
> > [Maxime: Change title prefix to match the usual style]
> > Signed-off-by: Maxime Ripard 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index f0a48ea78659..4eefd1c3ff16 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -208,7 +208,7 @@ parade  Parade Technologies Inc.
> >  pericomPericom Technology Inc.
> >  phytec PHYTEC Messtechnik GmbH
> >  picochip   Picochip Ltd
> > -pixcir  PIXCIR MICROELECTRONICS Co., Ltd
> 
> Why is "pixcir  PIXCIR MICROELECTRONICS Co., Ltd" removed?

Probably a poor rebase on my side. Good catch, thanks!
Maxime

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

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


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v5 2/4] arm64: dts: add Allwinner A64 SoC .dtsi

2016-10-24 Thread Maxime Ripard
Hi André,

On Mon, Oct 24, 2016 at 12:57:04AM +0100, André Przywara wrote:
> > +   pio: pinctrl@1c20800 {
> > +   compatible = "allwinner,sun50i-a64-pinctrl";
> > +   reg = <0x01c20800 0x400>;
> > +   interrupts = ,
> > +,
> > +;
> > +   clocks = < CLK_BUS_PIO>;
> > +   gpio-controller;
> > +   #gpio-cells = <3>;
> > +   interrupt-controller;
> > +   #interrupt-cells = <3>;
> > +
> > +   i2c1_pins: i2c1_pins {
> > +   allwinner,pins = "PH2", "PH3";
> > +   allwinner,function = "i2c1";
> 
> So as Icenowy pointed out, we are missing the drive and pull properties
> here, at least as long as we don't have your patch (series) in place to
> cope with that.

Yeah sorry, we noticed first with Chen-Yu that the binding should not
need it, and then we realised that the driver was making the
assumption that they were... Sorry :/

> But if we rely on this series (which seems OK to me), shouldn't we then
> use the generic properties for pins and function here as well?

Definitely. I'll update this.

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] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3

2016-10-24 Thread Maxime Ripard
On Sun, Oct 23, 2016 at 10:26:31AM +0200, LABBE Corentin wrote:
> On Thu, Oct 20, 2016 at 10:36:54PM +0200, Maxime Ripard wrote:
> > On Wed, Oct 19, 2016 at 09:40:16AM +0200, LABBE Corentin wrote:
> > > On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> > > > On Wed,  5 Oct 2016 11:48:24 +0200
> > > > Corentin Labbe  wrote:
> > > > 
> > > > > This patch add support for the sunxi-sid driver to the device tree 
> > > > > for sun8i-h3.
> > > > > 
> > > > > Signed-off-by: Corentin Labbe 
> > > > > ---
> > > > >  arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
> > > > >  1 file changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > > > > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > index 9f58bb4..abfd29c 100644
> > > > > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > > > > @@ -211,6 +211,11 @@
> > > > >   #size-cells = <0>;
> > > > >   };
> > > > >  
> > > > > + sid: eeprom@01c14200 {
> > > > > + compatible = "allwinner,sun7i-a20-sid";
> > > > > + reg = <0x01c14200 0x200>;
> > > > 
> > > > The datasheet says 1Kb starting at 0x01c14000.
> > > > Is there any reason to reduce the area and to shift the offset?
> > > > 
> > > 
> > > According to http://linux-sunxi.org/SID_Register_Guide "For
> > > Allwinner A83T and H3 the SID address space starts at 0x01c14000,
> > > and the e-fuses are at offset 0x200".
> > >
> > > So I use this offset, since the sunxi_sid driver need the base
> > > address of e-fuses.
> > > 
> > > The easiest solution is to use 0x01c14200 since the other part of
> > > sid is not used and not known (A83T/H3 user manual doesnt give any
> > > information on all sid space, worse for A64 which reference SID only
> > > in memory map).
> > > 
> > > So probably for H3/A64/A83T, there will never any usage of the rest
> > > of the SID address space.
> > 
> > And since we can't know that, and we have to maintain the DT ABI,
> > using the whole address map and an offset, with a new compatible, is
> > definetely the safest thing to do.
> > 
> 
> I have two way of doing it, which one do you prefer ?
> 
> - Adding two optionnal properties: efuses-offset and efuses-size defaulting 
> to 0 and resourcesize.
> - Adding a subnode called efuses with its own reg=<>
> 
> The first one is easy and didnt need any work on previous DT entries.

I'd prefer to have a compatible, and the size and/or offset of the
efuses associated to 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


Re: [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

2016-10-24 Thread Maxime Ripard
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.

Maxime

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

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


signature.asc
Description: PGP signature


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

2016-10-24 Thread Maxime Ripard
Hi,

On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
> 
> Signed-off-by: Jean-Francois Moine 

Output from checkpatch:
total: 0 errors, 20 warnings, 83 checks, 1799 lines checked

> ---
>  .../bindings/display/sunxi/sunxi-de2.txt   |  83 +++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/sunxi/Kconfig  |  21 +
>  drivers/gpu/drm/sunxi/Makefile |   7 +
>  drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +
>  drivers/gpu/drm/sunxi/de2_crtc.h   |  63 +++
>  drivers/gpu/drm/sunxi/de2_de.c | 591 
> +
>  drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
>  drivers/gpu/drm/sunxi/de2_drv.c| 378 +
>  drivers/gpu/drm/sunxi/de2_plane.c  | 119 +
>  11 files changed, 1787 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
>  create mode 100644 drivers/gpu/drm/sunxi/Makefile
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
>  create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
>  create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> new file mode 100644
> index 000..f9cd67a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
> @@ -0,0 +1,83 @@
> +Allwinner sunxi Display Engine 2 subsystem
> +==
> +
> +The sunxi DE2 subsystem contains a display controller (DE2),

sunxi is a made up name, and doesn't really mean anything. You can
call it either sun8i (because it was introduced in that family).

> +one or two LCD controllers (TCON) and their external interfaces.
> +
> +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.

> +
> +- resets: phandle to the reset of the device
> +
> +- ports: phandle's to the LCD ports

Please use the OF graph.

> +
> +LCD controller
> +==
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> + "allwinner,sun8i-a83t-lcd"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: must contain
> + "gate": for LCD activation
> + "clock": pixel clock
> +
> +- resets: phandle to the reset of the device
> +
> +- port: port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + de: de-controller@0100 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + ...
> + clocks = <& CLK_BUS_DE>, < CLK_DE>;
> + clock-names = "gate", "clock";
> + resets = < RST_BUS_DE>;
> + ports = <_p>;
> + };
> +
> + lcd0: lcd-controller@01c0c000 {
> + compatible = "allwinner,sun8i-a83t-lcd";
> + ...
> + clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
> + clock-names = "gate", "clock";
> + resets = < RST_BUS_TCON0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> +
> + hdmi: hdmi@01ee {
> + ...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port {
> + type = "video";
> + hdmi_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };

> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 483059a..afd576f 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -187,6 +187,8 @@ source "drivers/gpu/drm/shmobile/Kconfig"
>  
>  source 

[linux-sunxi] Re: [PATCH v4 4/9] clk: sunxi-ng: Add minimums for all the relevant structures and clocks

2016-10-24 Thread Maxime Ripard
On Fri, Oct 21, 2016 at 11:57:11PM +0100, André Przywara wrote:
> Salut,
> 
> On 11/10/16 15:28, Maxime Ripard wrote:
> > Modify the current clocks we have to be able to specify the minimum for
> > each clocks we support, just like we support the max.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/clk/sunxi-ng/ccu_mult.c |  7 ++-
> >  drivers/clk/sunxi-ng/ccu_nk.c   | 12 
> >  drivers/clk/sunxi-ng/ccu_nkm.c  | 18 --
> >  drivers/clk/sunxi-ng/ccu_nkmp.c | 16 
> >  drivers/clk/sunxi-ng/ccu_nm.c   | 12 
> >  5 files changed, 46 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/clk/sunxi-ng/ccu_mult.c 
> > b/drivers/clk/sunxi-ng/ccu_mult.c
> > index 32a1964439a2..6a02ffee5386 100644
> > --- a/drivers/clk/sunxi-ng/ccu_mult.c
> > +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> > @@ -14,7 +14,7 @@
> >  #include "ccu_mult.h"
> >  
> >  struct _ccu_mult {
> > -   unsigned long   mult, max;
> > +   unsigned long   mult, min, max;
> >  };
> >  
> >  static void ccu_mult_find_best(unsigned long parent, unsigned long rate,
> > @@ -23,6 +23,9 @@ static void ccu_mult_find_best(unsigned long parent, 
> > unsigned long rate,
> > int _mult;
> >  
> > _mult = rate / parent;
> > +   if (_mult < mult->min)
> > +   _mult = mult->min;
> > +
> > if (_mult > mult->max)
> > _mult = mult->max;
> >  
> > @@ -37,6 +40,7 @@ static unsigned long ccu_mult_round_rate(struct 
> > ccu_mux_internal *mux,
> > struct ccu_mult *cm = data;
> > struct _ccu_mult _cm;
> >  
> > +   _cm.min = 1;
> > _cm.max = 1 << cm->mult.width;
> > ccu_mult_find_best(parent_rate, rate, &_cm);
> >  
> > @@ -101,6 +105,7 @@ static int ccu_mult_set_rate(struct clk_hw *hw, 
> > unsigned long rate,
> > ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
> > _rate);
> >  
> > +   _cm.min = 1;
> > _cm.max = 1 << cm->mult.width;
> > ccu_mult_find_best(parent_rate, rate, &_cm);
> >  
> > diff --git a/drivers/clk/sunxi-ng/ccu_nk.c b/drivers/clk/sunxi-ng/ccu_nk.c
> > index e7e2e75618ef..a42d870ba0ef 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nk.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nk.c
> > @@ -14,8 +14,8 @@
> >  #include "ccu_nk.h"
> >  
> >  struct _ccu_nk {
> > -   unsigned long   n, max_n;
> > -   unsigned long   k, max_k;
> > +   unsigned long   n, min_n, max_n;
> > +   unsigned long   k, min_k, max_k;
> >  };
> >  
> >  static void ccu_nk_find_best(unsigned long parent, unsigned long rate,
> > @@ -25,8 +25,8 @@ static void ccu_nk_find_best(unsigned long parent, 
> > unsigned long rate,
> > unsigned int best_k = 0, best_n = 0;
> > unsigned int _k, _n;
> >  
> > -   for (_k = 1; _k <= nk->max_k; _k++) {
> > -   for (_n = 1; _n <= nk->max_n; _n++) {
> > +   for (_k = nk->min_k; _k <= nk->max_k; _k++) {
> > +   for (_n = nk->min_n; _n <= nk->max_n; _n++) {
> > unsigned long tmp_rate = parent * _n * _k;
> >  
> > if (tmp_rate > rate)
> > @@ -97,7 +97,9 @@ static long ccu_nk_round_rate(struct clk_hw *hw, unsigned 
> > long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate *= nk->fixed_post_div;
> >  
> > +   _nk.min_n = 1;
> > _nk.max_n = 1 << nk->n.width;
> > +   _nk.min_k = 1;
> > _nk.max_k = 1 << nk->k.width;
> >  
> > ccu_nk_find_best(*parent_rate, rate, &_nk);
> > @@ -120,7 +122,9 @@ static int ccu_nk_set_rate(struct clk_hw *hw, unsigned 
> > long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate = rate * nk->fixed_post_div;
> >  
> > +   _nk.min_n = 1;
> > _nk.max_n = 1 << nk->n.width;
> > +   _nk.min_k = 1;
> > _nk.max_k = 1 << nk->k.width;
> >  
> > ccu_nk_find_best(parent_rate, rate, &_nk);
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > index 0b08d000eb38..b2a5fccf2f8c 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > @@ -14,9 +14,9 @@
> >  #include "ccu_nkm.h"
> >  
> >  struct _ccu_nkm {
> > -   unsigned long   n, max_n;
> > -   unsigned long   k, max_k;
> > -   unsigned long   m, max_m;
> > +   unsigned long   n, min_n, max_n;
> > +   unsigned long   k, min_k, max_k;
> > +   unsigned long   m, min_m, max_m;
> >  };
> >  
> >  static void ccu_nkm_find_best(unsigned long parent, unsigned long rate,
> > @@ -26,9 +26,9 @@ static void ccu_nkm_find_best(unsigned long parent, 
> > unsigned long rate,
> > unsigned long best_n = 0, best_k = 0, best_m = 0;
> > unsigned long _n, _k, _m;
> >  
> > -   for (_k = 1; _k <= nkm->max_k; _k++) {
> > -   for (_n = 1; _n <= nkm->max_n; _n++) {
> > -   for (_m = 1; _n <= nkm->max_m; _m++) {
> > +   for (_k = nkm->min_k; _k <= nkm->max_k; _k++) {
> > +   for (_n = nkm->min_n; _n <= nkm->max_n; _n++) {
> > +   for (_m = 

Re: [linux-sunxi] ISP scaling A20

2016-10-24 Thread Manuel Braga
Hi.

On Fri, 21 Oct 2016 03:19:46 -0700 (PDT) Milos Ladni
 wrote:
> Hi everyone,
> 
> Because there are PoC of hardware JPEG encoding and decoding, i am
> now interesting of hw scaling..
> Does does anyone tried to scale image (raw yuv 4:2:2 4:2:0 or rgb)
> with A20 hardware?
> How can i do this? I need scaler to scale image from one resolution
> to another.
> Concretely i read frame from tvin 720x576 4:2:0 and convert it to
> jpeg with libjpegturbo, but i want to switch to hw scaler-encoder

I forgot last time, there is another way from what was writing in the
previous email, but is only better if what is need is only a scale down
image at multiple of image sizes (size divided by 1, 2 and 4 factors)

As said, the VEISP has a scaler that can use arbitrary scale factors
(within a min/max), but doesn't need to use it, because when configured
to (also) output raw pixels is possible to choose the outputted size.
For your example of a source of 720x576, it can output (simultaneous
when encoding) the sizes 720x576 or 360x288 or 180x144.

If this isn't what you are looking or instead also wants to correct
the aspect ratio to get square pixels, then the only option is to use
the arbitrary scale factor scaler, as talked in the other email.


> conversion now. The best solution would be 
> {[raw image] -> [scaler] -> [raw image]}
>  but alternative solution can be 
> {[raw image] -> [scaler -> encoder (jpeg-h264)] -> [compressed 
> image-stream]}
> Can i use ISP as separated block or i need to use it as part of
> jpeg-h264 encoder?
> Can i utilize G2D for this purpose for example?
> Does anyone tried anything similar with A20?
> 

-- 
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: [linux-sunxi] [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu

2016-10-24 Thread Ondřej Jirman
Dne 24.10.2016 v 05:59 Icenowy Zheng napsal(a):
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
> 
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b9342a2..ff8e9dd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - if (data->cfg->enable_pmu_unk1) {
> + if (phy->index != 0 && data->cfg->enable_pmu_unk1) {

It might be better to check for phy->pmu directly.

regards,
  o.
>   val = readl(phy->pmu + REG_PMU_UNK1);
>   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>   }
> 



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