Re: [linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[Thomas Kaiser]

Siarhei Siamashka wrote:

> It's likely that the credit for "unlocking" the 1.5 GHz clock speed
> actually belongs to third-party modders.

Thanks for clarifying this (and all the additional informations). I'll
try to correct this where I spread wrong "informations"/assumptions
asapissimo.

> As there were no real objections, I have just pushed the Orange Pi PC
> fex file to the sunxi-boards repository. This makes it the first FEX
> file for the H3 SoC :-)

Great. Only one single question (I've overlooked before). Why

boot_clock = 1200

(especially since you wrote about SY8106A's default 1.2V voltage being
safe for operation at 1008 MHz)

Thx,

Thomas




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

Re: [linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[Siarhei Siamashka]

On Wed, 9 Dec 2015 00:40:18 -0800 (PST)
Thomas Kaiser  wrote:

> Siarhei Siamashka:
> 
> > Extracted from the Lubuntu_1404_For_OrangePiPC_v0_8_0_.img.xz image: 
> >
> > http://www.orangepi.org/downloadresources/orangepipc/oragepipc_4a0e8d960f7f0a52606dfaba58.html
> >  
> >
> > Not necessarily the best one
> >  
> 
> This is the worst one since it's the origin of all thermal problems with 
> Orange Pis

It is not the worst one. This particular FEX file only allows clock
speeds up to 1.2 GHz because the CPU clock frequency must satisfy
*both* cpufreq and also cooling state requirements at once. Yes, the
cpufreq table lists 1.5GHz as the maximum clock frequency. But at the
same time, the highest cooling state only allows 4 cores running at
1.2GHz in this FEX. I had some explanations about this in my third
patch "h3: Update cpufreq and cooling state tables on Orange Pi PC".

It's likely that the credit for "unlocking" the 1.5 GHz clock speed
actually belongs to third-party modders.

> and the result of product marketing: Advertising the H3 to be 
> able to run at "up to 1.6Ghz".

Right now http://www.orangepi.org/orangepipc/ page does not say
anything about the CPU clock frequency. I guess, there was a time
period when nobody had any idea about what would be the CPU clock
speed limit because Allwinner does not really provide this information
in the H3 manual.

Regarding the product marketing. The primary competitors are probably
the Raspberry Pi 2 running at 900 MHz and the ODROID C1 running at 1.5
GHz. So 1.6 GHz would definitely look attractive in the marketing
materials if this was true.

It looks like H3 can be clocked at least up to 1.3 GHz with the
CPU core voltage not exceeding the 1.4V limit specified in the H3
manual. But running all 4 cores at this clock speeds for prolonged
periods of time may be difficult because of thermal throttling.
On the other hand, a single-threaded workload at 1.3 GHz is
probably perfectly fine. It's roughly the same as
https://en.wikipedia.org/wiki/Intel_Turbo_Boost
Intel is playing safe and provides two clock frequencies in the
marketing materials (the "nominal" clock frequency and the "boosted"
one). Maybe that's the way to go?

A heatsink is just an optional performance feature, which may allow
your system to run faster and keep the cores always running at full
speed. It is not necessary for reliable operation, but the peak
performance may degrade without it.

> All Steven did was to increase clockspeeds 
> and to adjust the Vcore voltage of the two available operting points in the 
> dvs table he took from Draco by 200mV (to be able to reach the 
> extremity_freq as scaling_max_freq).
> 
> And the result is that everyone using OS images for H3 based Orange Pi 
> models has to suffer from heat/stability problems. When you replace this 
> moronic dvfs table with something sane (a few more operating points and not 
> only 2 already exceeding the recommended maximum values), you won't even 
> need a heatsink:
> 
> http://linux-sunxi.org/User_talk:Tkaiser#Lessons_to_learn_from_Xunlong
> 
> With Xunlong's dvfs settings switching between 1.2 Ghz and 1.56 GHz *while 
> being idle* the SoC's temperature increases by 12°C.
> 
> I don't know what I'm doing wrong but I can fire up cpuburn-a7 running on 
> all 4 CPU cores at 1.2Ghz on my Orange Pi PC without thermal throttling, 
> without CPU cores being dropped and also without heatsink/fan attached. Can 
> please anyone explain to me what's wrong with my Orange Pi?

This is called undervolting. With overclocking one is pushing the
absolute performance limits. And with undervolting one pushing the
performance/watt limits.

But there is some variation in voltage tolerances between different
samples, so sufficient safety headroom must be provided in the
general purpose configuration to make it suitable for everyone.
Even if you can reduce the voltage to the very minimum on your
board, this does not automatically mean that any other guy with
a different Orange Pi PC board would be also able to use the same
voltage safely.

As there were no real objections, I have just pushed the Orange Pi PC
fex file to the sunxi-boards repository. This makes it the first FEX
file for the H3 SoC :-)

-- 
Best regards,
Siarhei Siamashka

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

[linux-sunxi] Re: BUG - Bananapi USB not working on Mainline

[m . silentcreek]

Hi again,

Am Freitag, 18. Dezember 2015 21:22:43 UTC+1 schrieb m.sile...@gmail.com:
> I can confirm there is an issue with USB (not OTG) on the Bananapi in Linux 
> 4.4-rc5. I just compiled and booted a 4.4-rc5 kernel image with a new dtb - 
> or be more precise, I failed to boot it because the kernel couldn't mount the 
> usb drives that I listed in my fstab. The defconfig I used was basically the 
> same that I use for my 4.1.y kernels which is based on sunxi_defconfig but 
> adds a lot more stuff like drivers, netfilter, etc (I merged the changes that 
> happened in sunxi_defconfig between 4.1 and 4.4, though).
> 
> I haven't had the time yet to look into it further to bisect the issue. I 
> also haven't tried any other kernel versions between 4.1.15 and 4.4-rc5, so I 
> can't say when the problem slipped in. I just can say that there is an issue 
> on my Lemaker Bananapi. The symptoms are the same as descrived by David. My 
> usb drives don't seem the get power anymore once the kernel boots.
> 
> I'll try to find time to look into it in more detail over the weekend and 
> provide configs and logs.
> 

so, I did some more testing. I took a second Lemaker Bananpi with two usb 
devices attached (a flash drive and a sd card reader) and compiled several 
kernel images along with their device tree blobs to figure out which version 
introduced the issue.

I tested linux 4.2, 4.3, 4.4-rc1 and 4.4-rc5. The U-Boot version used was 
2015.10. I took the same defconfig for all builds. 

The break seems to have occured between 4.3 and 4.4-rc1, meaning that both 4.2 
and 4.3 work fine, but with 4.4-rc1 and 4.4-rc5 the USB devices get turned off 
during boot.

The defconfig, full configs and the corresponding dmesg output for 4.3 (USB 
working) and 4.4-rc1 (USB *not* working) can be found here:
http://pastebin.com/HYwCGwcx (config 4.3)
http://pastebin.com/hbW7iLEh (dmesg 4.3)
http://pastebin.com/tKMSXMCW (config 4.4-rc1)
http://pastebin.com/g5NXw42t (dmesg 4.4-rc1)
http://pastebin.com/kW8MjcTq (defconfig, used for all builds)

What caught my eye here are these lines in the 4.4-rc1 dmesg output:
[0.539619] usb0-vbus: disabling
[0.539641] usb1-vbus: disabling
[0.539664] usb2-vbus: disabling

When I submitted the patch to enable the regulators on Bananapi and tested the 
patch on some linux-next build at that time, I didn't see those in my kernel 
log. So maybe there was another change leading to that?

As David described as well, the LEDs on my flash drive and my card reader get 
turned on during the U-Boot phase. When the kernel is loading, they stay on (or 
keep blinking) with linux 4.3 and earlier. In 4.4-rc1 and later they both turn 
off, once the kernel is loading. 

Interesting enough, though, the power does not seem to be lost completly. 
Because if I unplug the card reader once linux 4.4-rc1 has fully booted, and 
plug it back in, the LED turns on again but the device does not show up in 
/dev/ and is not mountable. The flash drive stays dark even with this 
unplugging/plugging cycle.


Regards,

Timo

-- 
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 5/5] ARM: dts: sun5i: Add backlight node to sun5i-q8-common.dtsi

[8001010]

> + default-brightness-level = <8>;


Why?
Is not better 100% ?

Silviop

-- 
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: BUG - Bananapi USB not working on Mainline

[Hans de Goede]

Hi,

On Wednesday, December 16, 2015 at 2:47:40 AM UTC+1, David Tulloh wrote:
>
> Hi,
>
> I am working on a SinoVoip Bananapi M1
>
> With the current mainline USB does not work. I believe that power to the 
> USB vbus is being disabled during boot.
>
> Failing build v4.4-rc5
> Working build v4.2.3
>
> Compiled with
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sunxi_defconfig 
> menuconfig zImage dtbs
>
> The boot log is attached, debug and CONFIG_REGULATOR_DEBUG were enabled.
> The config file is also attached.
>
> I am happy to do further work on the problem but my unfamiliarity with the 
> kernel means I'm flailing in the dark.
>
>
> David
>

The sunxi usb-phy driver now requires extcon (due to the added otg 
support), maybe the defconfig is not enabling extcon and thereby you are 
not getting the sunxi usb-phy driver build, or not build-in at least ?

Can you edit .config after the make defconfig and see what the value for 
CONFIG_PHY_SUN4I_USB is ?

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.

Re: [linux-sunxi] Transport stream controller usage at A20-olinuxino

[yangkkokk]

在 2015年12月11日星期五 UTC+8下午4:46:03，User Android写道：
> Hello,
> 
> I try get Transport Stream on A-20-Olinuxino. I fix *.fex file, use patch 
> Allwinner_TSC_driver.0.0.4.A.linux-sunxi-stage3.4.schorpp.04, compile the 
> kernel (3.4.104) and modules, read data from /dev/tsc_dev but i have only 0. 
> I read TSC registers and all values are equal 0. I make memory mapping with 
> flags PROT_READ | PROT_WRITE and try change this value (for example, enable 
> TSG and change TSFMUXR) but my changes don't happen :( 
> this registers (for example TSC TSF INPUT MULTIPLEX CONTROL REGISTER) have 
> R/W, but i can't write new value. 
> 
> Maybe someone knows as to solve such a problem?
> 
> Thanks in advance,
> 
> Roman
> 
> понедельник, 10 февраля 2014 г., 23:39:55 UTC+3 пользователь thomas schorpp 
> написал:Am 10.02.2014 15:57, schrieb vladimir...@gmail.com:
> 
> > Hello,
> 
> >
> 
> > Could you please point me out how to utilize TSC subsystem at the 
> > A20-Olinuxino? What driver should I use? Is the any samples?
> 
> > I'm using linux sunxi version 3.4.67+
> 
> >
> 
> > Thanks in advance,
> 
> > Vladimir.
> 
> >
> 
> 
> 
> Hi Vladimir,
> 
> 
> 
> search the list archive for my address, You should find my analysis doc, the 
> patches for Olimex A20 fex and a port of AW's basic Android /dev driver
> 
> You could try to attach as module to Your own higher OSI- layer driver if not 
> DVB/ATSC, don't know where in the sunxi repos yet and
> 
> the port should be out of sync with the sunxi-devel tree for months now. Last 
> state was driver loading and basic init success.
> 
> 
> 
> The /dev ioctl() does not look like V4L or linux DVB API, maybe some AW 
> testing driver, beware, license *possibly proprietary*.
> 
> If You want to have "cleanroom design", better rewrite it from scratch for 
> V4L/DVB ABI/API and license it for GPL or compatible.
> 
> 
> 
> You should find links to a preliminary A10 Transport Stream Controller manual 
> in the sunxi, Olimex repo, wiki or cubiebord download section.
> 
> If You've questions or need more TSC/A20- programming info, maybe Ben @ 
> cubieboard can help with contacts to AW staff.
> 
> For DMA (buffer) support (required) status in linux-sunxi search list, wiki, 
> ask the developers in IRC.
> 
> 
> 
> You need the schematics of Your Olimex board with correct PCB revision from 
> the Olimex git repo, too, if You want to attach
> 
> a TV receiver module to the GPIO PIN headers and the datasheet of the module 
> *with* support by mainline dvb frontend drivers modified and attached
> 
> to the sunxi-twi/i2c drivers.
> 
> 
> 
> If Your project is an IPTV TS -> CedarX (Cedrus) VE driver, surely of 
> interest, too :-)
> 
> 
> 
> Patches and reports (to this list, CC linux-media list and sunxi wiki)  
> welcome, I'll show up on IRC as soon as my provider has cleared his "EU 
> issues",
> 
> good luck.
> 
> 
> 
> I'm still busy with other linux media homebrew stuff, migrations, and VDR 
> people seem not to be interested in SoC platforms, yet, so low priority.
> 
> 
> 
> y
> 
> tom
> 
> P.S.: Just found the patches in local storage here, -attached-, but can't 
> remember if complete and expect kernel build breakage and crashes on use :D

hi,
  ts port is a input,use dib3000 ts output to a20 input,use ffmpeg deviver ts 
dev to a video.

-- 
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: BUG - Bananapi USB not working on Mainline

[m . silentcreek]

Hi,

Am Samstag, 19. Dezember 2015 20:38:08 UTC+1 schrieb Hans de Goede:
> The sunxi usb-phy driver now requires extcon (due to the added otg support), 
> maybe the defconfig is not enabling extcon and thereby you are not getting 
> the sunxi usb-phy driver build, or not build-in at least ?
> 
> Can you edit .config after the make defconfig and see what the value for 
> CONFIG_PHY_SUN4I_USB is ?

I found the solution! The problem is CONFIG_AXP20X_POWER which was introduced 
in 4.4-rc1 but defaults to no and not set in sunxi_defconfig. Adding 
CONFIG_AXP20X_POWER=y to sunxi_defconfig solves that and get's my USB devices 
working again on linux 4.4-rc5. I actually brought that up on IRC once, but at 
that time nobody seemed to know so I forgot it again.

Anyway, wouldn't it be a better to just have it automatically be selected when 
e.g. CONFIG_PHY_SUN4I_USB or something else that depends on it is enabled?

Regards,

Timo

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

Re: [linux-sunxi] Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Hans de Goede]

Hi,

On 18-12-15 12:08, Maxime Ripard wrote:

On Wed, Dec 16, 2015 at 12:21:48PM +0100, Philipp Zabel wrote:

Hi Maxime,

Am Mittwoch, den 16.12.2015, 11:29 +0100 schrieb Maxime Ripard:

On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote:

Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard:

Hi,

On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:

diff --git a/include/linux/reset.h b/include/linux/reset.h
index c4c097d..1cca8ce 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
  int reset_control_assert(struct reset_control *rstc);
  int reset_control_deassert(struct reset_control *rstc);
  int reset_control_status(struct reset_control *rstc);
+int reset_control_assert_shared(struct reset_control *rstc);
+int reset_control_deassert_shared(struct reset_control *rstc);


Shouldn't that be handled in reset_control_get directly?


I think I see your point now. Maybe we should add a flags parameter to
reset_control_get and/or wrap it in two versions,
reset_control_get_exclusive and reset_control_get_shared (or just add
the _shared variant). Then reset_control_get(_exclusive) could return
-EBUSY if a reset line is already in use.


I guess the current assumption was that reset_control_get was
exclusive.

So we could have something like:

reset_control_get (..) {
   return __reset_control_get(.., 0);
}

reset_control_get_shared (..) {
   return __reset_control_get(.., RESET_SHARED);
}

And all the logic shared between the two, without exposing any flag
(that would change the prototype and require to fix every callers).




This is about different expectations of the caller.
A driver calling reset_control_assert expects the reset line to be
asserted after the call.


Is that behaviour documented explicitly somewhere?


/**
  * reset_control_assert - asserts the reset line
  * @rstc: reset controller
  */


Yeah, but it's not said when it would happen, or if it happens
synchronously.


Also, that expected behavior matches the function name, which I like.
So I still welcome adding new API calls for the shared/refcounting
variant.


A driver calling reset_control_assert_shared
just signals that it doesn't care about the state of the reset line
anymore.
We could just as well call the two new functions
reset_control_deassert_get and reset_control_deassert_put.


What happens if you mix them? What happens if you have several drivers
ignoring this API?


The core should give useful error messages and disallow non-shared reset
calls on shared lines.


I guess we could also have something like this:

   * The driver gets the reference to the reset line using
 reset_control_get or its shared variant.

 - If you call reset_control_get on a free line, it succeeds, and
   marks the line in exclusive use.
 - If you call reset_control_get on a busy line, it fails with
   EBUSY

 - If you call the shared variant on a free line, it succeeds
 - If you call the shared variant on a busy exclusive line, it
   fails with EBUSY
 - If you call the shared variant on a busy !exclusive line, it
   succeeds.

   * The customer driver can then call reset_control_assert / deassert:

 - If the reset line is in exclusive use, the assertion happens
   right away, it succeeds and returns 0.

 - If the reset line is in a !exclusive use, but with a single
   user, the assertion happens right away, it succeeds and returns
   0.


Ack for all of the above, this is what I had in mind at first, but I started
with a more lightweight version as I'm lazy :)  If Philipp likes this
suggestion I can rework my patch-set into this.


 - If the reset line is in a !exclusive use with more than 1 user,
   the refcount is modified and an error is returned to notify that
   it didn't happen.


Also ack, except for returning the error, if a driver has used
reset_control_get_shared, it should simply be aware that doing an assert
might not necessarily actually assert the line, just like doing a clk-disable
does not really necessary disable the clock, etc. If a driver is not prepared
to deal with this, it should simply not use reset_control_get_shared.

I see returning an error if the assert did not happen due to other users /
deassert_count != 0 as inconsistent compared to how clks, regulators and phys
handle this, these all simply return success in this case.

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][PATCH v2] ARM: sunxi: dt: enable audio codec on mk802

[codekipper]

From: Marcus Cooper 

This commit enables the on-chip audio codec present on some variants
of the MK802.

Signed-off-by: Marcus Cooper 
---
 arch/arm/boot/dts/sun4i-a10-mk802.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts 
b/arch/arm/boot/dts/sun4i-a10-mk802.dts
index 3c7eebe..ddf0683 100644
--- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
@@ -58,6 +58,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.4

-- 
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 v2] ARM: dt: sun7i: Enable audio codec on MK808C

[codekipper]

From: Marcus Cooper 

This commit enables the on-chip audio codec present on the MK808C.

Signed-off-by: Marcus Cooper 
---
 arch/arm/boot/dts/sun7i-a20-mk808c.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts 
b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
index 4f432f8..c9e648d 100644
--- a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
+++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
@@ -68,6 +68,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.4

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

Re: [linux-sunxi] Re: [PATCH v3 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi

[Hans de Goede]

Hi,

On 18-12-15 22:41, Maxime Ripard wrote:

Hi,

On Fri, Dec 18, 2015 at 09:30:50PM +0800, Vishnu Patekar wrote:

Allwinner A83T is new octa-core cortex-a7 SOC.
This adds the basic dtsi, the clocks differs from
earlier sun8i SOCs.

Signed-off-by: Vishnu Patekar 
---
  arch/arm/boot/dts/sun8i-a83t.dtsi | 206 ++
  1 file changed, 206 insertions(+)
  create mode 100644 arch/arm/boot/dts/sun8i-a83t.dtsi

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
new file mode 100644
index 000..e577c64
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -0,0 +1,206 @@
+/*
+ * Copyright 2015 Vishnu Patekar
+ *
+ * Vishnu Patekar 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+
+ */
+
+#include "skeleton.dtsi"
+
+#include 
+
+#include 
+
+/ {
+   interrupt-parent = <>;
+
+   chosen {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <1>;
+   };
+
+   cpu@2 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <2>;
+   };
+
+   cpu@3 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <3>;
+   };


A \n here please


+   cpu@100 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x100>;
+   };
+
+   cpu@101 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x101>;
+   };


Ditto.


+   cpu@102 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x102>;
+   };
+
+   cpu@103 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0x103>;
+   };
+   };
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };


Is mainline u-boot usable ? If so, you can remove that node entirely.


mainline u-boot works for me when cold-booting from a sdcard, so I consider
it usable :)

Regards,

Hans






+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+ 

[linux-sunxi][PATCH v2 0/5] ARM: dt: sunxi: Add Itead Ibox support

[codekipper]

From: Marcus Cooper 

Hi All,

this patch series is an extension of the initial patch delivery for the
Itead Ibox as found here
https://groups.google.com/d/msg/linux-sunxi/GR_co3ObW8s/0BTPQljmAAAJ.

There seems to be a few Itead variants out there based on their A10/A20
core module and this patch series attempts to organise the device tree
files with some consideration that these variants may be added later.

I've also converted the A10 Itead Iteaduino dts to use these common files.
As I don't have this board to verify the changes I simply compared the
output of the fdtdump before and after applying these patches. The only
difference was the addition of codec support and a reduction to the dcdc2
max voltage.

BR,
CK

---
Changes since v1:
- Added audio codec.
- Seperated into individual patches
- added Itead A10 core dtsi
- modified sun4i-a10-itead-iteaduino-plus.dts to use itead common core dtsi

Marcus Cooper (5):
  ARM: dts: sunxi: Add sunxi-itead-core-common.dtsi
  ARM: dts: sun7i: Add Itead A20 Core support
  ARM: dts: sun7i: Add Itead Ibox support
  ARM: dts: sun4i: Add Itead A10 Core support
  ARM: dts: sun4i: Itead Iteaduino to use common code

 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun4i-a10-itead-core.dtsi|  86 
 .../boot/dts/sun4i-a10-itead-iteaduino-plus.dts| 102 +-
 arch/arm/boot/dts/sun7i-a20-itead-core.dtsi|  87 
 arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 111 
 arch/arm/boot/dts/sunxi-itead-core-common.dtsi | 114 +
 6 files changed, 401 insertions(+), 100 deletions(-)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-itead-core.dtsi
 create mode 100644 arch/arm/boot/dts/sun7i-a20-itead-core.dtsi
 create mode 100644 arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
 create mode 100644 arch/arm/boot/dts/sunxi-itead-core-common.dtsi

-- 
1.9.1

-- 
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 v2 4/5] ARM: dts: sun4i: Add Itead A10 Core support

[codekipper]

From: Marcus Cooper 

The A10 Itead Core module comes with 4GB NAND and 1GB DDR RAM. All of the
I/O interfaces are exposed via 4 groups of 2*30 1mm pitched female headers.

Signed-off-by: Marcus Cooper 
---
 arch/arm/boot/dts/sun4i-a10-itead-core.dtsi | 86 +
 1 file changed, 86 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-itead-core.dtsi

diff --git a/arch/arm/boot/dts/sun4i-a10-itead-core.dtsi 
b/arch/arm/boot/dts/sun4i-a10-itead-core.dtsi
new file mode 100644
index 000..97f653a
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-itead-core.dtsi
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun4i-a10.dtsi"
+#include "sunxi-itead-core-common.dtsi"
+
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
-- 
1.9.1

-- 
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 v2 1/5] ARM: dts: sunxi: Add sunxi-itead-core-common.dtsi

[codekipper]

From: Marcus Cooper 

Itead have a core module board that can be populated with either
an Allwinner A10 or A20 SoC. This patch creates a common dtsi
which these boards can use.

Signed-off-by: Marcus Cooper 
---
 arch/arm/boot/dts/sunxi-itead-core-common.dtsi | 114 +
 1 file changed, 114 insertions(+)
 create mode 100644 arch/arm/boot/dts/sunxi-itead-core-common.dtsi

diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi 
b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
new file mode 100644
index 000..41449fa
--- /dev/null
+++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
@@ -0,0 +1,114 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   target-supply = <_ahci_5v>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_ahci_5v {
+   pinctrl-0 = <_pwr_pin_a>;
+   gpio = < 1 8 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+};
+
+_usb1_vbus {
+   status = "okay";
+};
+
+_usb2_vbus {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+ {
+   usb1_vbus-supply = <_usb1_vbus>;
+   usb2_vbus-supply = <_usb2_vbus>;
+   status = "okay";
+};
-- 
1.9.1

-- 
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 v2 2/5] ARM: dts: sun7i: Add Itead A20 Core support

[codekipper]

From: Marcus Cooper 

The A20 Itead Core module comes with 4GB NAND and 1GB DDR RAM. All of the
I/O interfaces are exposed via 4 groups of 2*30 1mm pitched female headers.

Signed-off-by: Marcus Cooper 
---
 arch/arm/boot/dts/sun7i-a20-itead-core.dtsi | 87 +
 1 file changed, 87 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-itead-core.dtsi

diff --git a/arch/arm/boot/dts/sun7i-a20-itead-core.dtsi 
b/arch/arm/boot/dts/sun7i-a20-itead-core.dtsi
new file mode 100644
index 000..db8c0f9
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-itead-core.dtsi
@@ -0,0 +1,87 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun7i-a20.dtsi"
+#include "sunxi-itead-core-common.dtsi"
+
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   };
+};
+
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
-- 
1.9.1

-- 
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 v2 5/5] ARM: dts: sun4i: Itead Iteaduino to use common code

[codekipper]

From: Marcus Cooper 

Convert the Itead Iteaduino A10 to use the new common itead core dtsi.

Signed-off-by: Marcus Cooper 
---
 .../boot/dts/sun4i-a10-itead-iteaduino-plus.dts| 102 +
 1 file changed, 2 insertions(+), 100 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts 
b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
index 985e155..86d7b7a 100644
--- a/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
+++ b/arch/arm/boot/dts/sun4i-a10-itead-iteaduino-plus.dts
@@ -1,5 +1,6 @@
 /*
  * Copyright 2015 Josef Gajdusek 
+ * Copyright 2015 - Marcus Cooper 
  *
  * This file is dual-licensed: you can use it either under the terms
  * of the GPL or the X11 license, at your option. Note that this dual
@@ -41,40 +42,11 @@
  */
 
 /dts-v1/;
-#include "sun4i-a10.dtsi"
-#include "sunxi-common-regulators.dtsi"
-
-#include 
-#include 
+#include "sun4i-a10-itead-core.dtsi"
 
 / {
model = "Iteaduino Plus A10";
compatible = "itead,iteaduino-plus-a10", "allwinner,sun4i-a10";
-
-   aliases {
-   serial0 = 
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-};
-
- {
-   target-supply = <_ahci_5v>;
-   status = "okay";
-};
-
- {
-   cpu-supply = <_dcdc2>;
-};
-
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
 };
 
  {
@@ -88,17 +60,6 @@
status = "okay";
 };
 
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   status = "okay";
-
-   axp209: pmic@34 {
-   reg = <0x34>;
-   interrupts = <0>;
-   };
-};
-
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -135,68 +96,9 @@
status = "okay";
 };
 
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
-_ahci_5v {
-   status = "okay";
-};
-
-#include "axp209.dtsi"
-
-_dcdc2 {
-   regulator-always-on;
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <145>;
-   regulator-name = "vdd-cpu";
-};
-
-_dcdc3 {
-   regulator-always-on;
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <140>;
-   regulator-name = "vdd-int-dll";
-};
-
-_ldo1 {
-   regulator-name = "vdd-rtc";
-};
-
-_ldo2 {
-   regulator-always-on;
-   regulator-min-microvolt = <300>;
-   regulator-max-microvolt = <300>;
-   regulator-name = "avcc";
-};
-
-_usb1_vbus {
-   status = "okay";
-};
-
-_usb2_vbus {
-   status = "okay";
-};
-
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>,
<_cs0_pins_a>;
status = "okay";
 };
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   status = "okay";
-};
-
- {
-   usb1_vbus-supply = <_usb1_vbus>;
-   usb2_vbus-supply = <_usb2_vbus>;
-   status = "okay";
-};
-- 
1.9.1

-- 
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 1/4] ARM: dts: sun7i: Enable touchscreen on Wexler TAB7200 tablet

[Aleksei Mamlin]

2015-12-19 0:25 GMT+03:00 Maxime Ripard :

> Hi,
>
> On Fri, Dec 18, 2015 at 11:51:50AM +0300, Aleksei Mamlin wrote:
> > Add a node for the Goodix GT911 touchscreen found on the Wexler TAB7200
> tablet
> >
> > Signed-off-by: Aleksei Mamlin 
> > ---
> >  arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > index 239b5d2..ec3b837 100644
> > --- a/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > +++ b/arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
> > @@ -102,6 +102,18 @@
> >   pinctrl-names = "default";
> >   pinctrl-0 = <_pins_a>;
> >   status = "okay";
> > +
> > + gt911: touchscreen@5d {
> > + compatible = "goodix,gt911";
> > + reg = <0x5d>;
> > + interrupt-parent = <>;
> > + interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; /* EINT21
> (PH21) */
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_reset_pin>;
> > + irq-gpios = < 7 21 GPIO_ACTIVE_HIGH>; /* INT (PH21) */
>
> It seems odd that you need both irq-gpios and interrupts. These two
> are completely redundant, and you should even actually use only one in
> your driver, since the second request_irq will fail.
>
>
We need both interrupts and irq-gpios because the driver uses the interrupt
gpio pin as output to reset the device. See bindings documentation [1]

[1]
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/tree/Documentation/devicetree/bindings/input/touchscreen/goodix.txt?h=goodix


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



-- 
Thanks and regards,
Aleksei Mamlin

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