Re: [linux-sunxi] Re: [RFC] A2x touchpad temperature readout

[Julian Calaby]

Hi Heiko,

On Fri, Jun 19, 2015 at 2:02 AM, Heiko Schröter
 wrote:
> Hello,
>
> just seen that Hans did a temperature readout in sunxi-next in the sun4i-ts
> module.
> Sorry for the noise.

I was thinking of pointing out that any temperature sensor driver that
conflicts with the touch screen driver isn't going to fly and that you
should build your improvements (your driver is more configurable,
right?) into that driver instead of building a completely new one.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
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] AllWinner A13: I2C bus locked

[bruce bushby]

Hi

I wanted to ask if anybody is having or has had problems with "A13 I2C bus
locked"?

I'm using a "Latest" version of u-boot and 4.1 release candidate. I've also
tried using an older U-Boot (2014.04)  tomorrow I'll try some older
kernels but thought I would check with the list at the same time.

I'm using the Olimex A13-SOM with nothing connected and have tried a couple
of different power supplies just in case it was a voltage issue.



Some console extracts:


U-Boot SPL 2015.04 (Jun 18 2015 - 17:32:42)
DRAM: 512 MiB
Failed to set core voltage! Can't set CPU frequency


U-Boot 2015.04 (Jun 18 2015 - 17:32:42) Allwinner Technology

CPU:   Allwinner A13 (SUN5I)
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

Setting up a 1024x768 vga console
In:serial
Out:   vga
Err:   vga
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
318 bytes read in 21 ms (14.6 KiB/s)
## Executing script at 4310
reading uImage
4281912 bytes read in 666 ms (6.1 MiB/s)
reading sun5i-a13-olinuxino-micro.dtb
14674 bytes read in 36 ms (397.5 KiB/s)
## Booting kernel from Legacy Image at 4600 ...
   Image Name:   Linux-4.1.0-rc6
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4281848 Bytes = 4.1 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4900
   Booting using the fdt blob at 0x4900
   Loading Kernel Image ... OK
   Using Device Tree in place at 4900, end 49006951

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.1.0-rc6 (br...@core.home.local) (gcc version
4.9.2 (Buildroot 2015.08-git-00187-g0db1c13) ) #1 SMP Thu Jun 18 17:40:32
BST 2015

..




#
# uname -a
Linux A13-SOM 4.1.0-rc6 #1 SMP Thu Jun 18 17:40:32 BST 2015 armv7l GNU/Linux
#
# dmesg | grep i2c
[0.162429] i2c-core: driver [dummy] registered
[0.197051] i2c-core: driver [tps65217] registered
[0.197202] i2c-core: driver [tps65910] registered
[0.197326] i2c-core: driver [tps65912] registered
[0.197543] i2c-core: driver [tps80031] registered
[0.197816] i2c-core: driver [da9052] registered
[0.197940] i2c-core: driver [da9055-pmic] registered
[0.198061] i2c-core: driver [tps6586x] registered
[0.198183] i2c-core: driver [tps65090] registered
[0.198301] i2c-core: driver [palmas] registered
[0.442578] i2c-core: driver [lp872x] registered
[1.128358] i2c-core: driver [tps65218] registered
[1.128487] i2c-core: driver [twl] registered
[1.129017] i2c-core: driver [twl6040] registered
[1.129152] i2c-core: driver [axp20x] registered
[1.172919] i2c /dev entries driver
[1.178191] i2c-dev: adapter [mv64xxx_i2c adapter] registered as minor 0
[1.178304] i2c i2c-0: adapter [mv64xxx_i2c adapter] registered
[1.178407] i2c i2c-0: of_i2c: walking child nodes
[1.179639] i2c-dev: adapter [mv64xxx_i2c adapter] registered as minor 1
[1.179739] i2c i2c-1: adapter [mv64xxx_i2c adapter] registered
[1.179840] i2c i2c-1: of_i2c: walking child nodes
[1.181004] i2c-dev: adapter [mv64xxx_i2c adapter] registered as minor 2
[1.181096] i2c i2c-2: adapter [mv64xxx_i2c adapter] registered
[1.181190] i2c i2c-2: of_i2c: walking child nodes
[1.181489] i2c-core: driver [ir-kbd-i2c] registered
#
# ls -l /dev | grep i2c
crw---1 root root   89,   0 Jan  1 00:00 i2c-0
crw---1 root root   89,   1 Jan  1 00:00 i2c-1
crw---1 root root   89,   2 Jan  1 00:00 i2c-2
#
# i2cdetect -l
i2c-0   i2c mv64xxx_i2c adapter I2C adapter
i2c-1   i2c mv64xxx_i2c adapter I2C adapter
i2c-2   i2c mv64xxx_i2c adapter I2C adapter
#
# i2cdetect -y 0
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  [   55.294387] i2c i2c-0: mv64xxx: I2C bus locked, block: 1,
time_left: 0
-- [   57.294387] i2c i2c-0: mv64xxx: , block: 1, time_left: 0
-- [   59.294474] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
-- [   61.294381] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
-- ^C[   63.294436] i2c i2c-0: mv64xxx: I2C bus locked, block: 1,
time_left: 0

#
# i2cdetect -y 1
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  [   67.604383] i2c i2c-1: mv64xxx: I2C bus locked, block: 1,
time_left: 0
-- [   69.604378] i2c i2c-1: mv64xxx: I2C bus locked, block: 1, time_left: 0
-- [   71.604421] i2c i2c-1: mv64xxx: I2C bus l

[linux-sunxi] Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Hans de Goede]

Hi,

On 18-06-15 20:37, Maxime Ripard wrote:

On Wed, Jun 17, 2015 at 09:16:02AM +0200, Hans de Goede wrote:

Hi,

On 16-06-15 19:41, Maxime Ripard wrote:

Hi,

On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:

Pantelis, to sum things up, we have a case of a tablet that comes with
the exact same board, but coming in two flavours with two differents
screen resolutions. It looks like a great case for your DT quirks
work, but we have no way of runtime detecting the difference between
the two variants. What do you think about this? Should we go with
using the DT quirks or is this simply out of scope?

There's not so much example of similar cases in the kernel, and none
of them use quirks so far (obviously) but they all boil down to either
the solution you were suggesting in that patch or adding the alternate
configuration as a comment.

I don't think the latter would work for you, and I agree with that, so
I guess that depending on what Pantelis says, either we go with a
better solution using the quirks, or we end up using what you
suggested (with a nitpick though, I'd prefer if you used the display
standard instead of the resolution, which would make it xga I guess?)


If we go with a separate dts file for each of the 800x480 and 1024x600
screens, I would greatly prefer to stick with the lcd1024x600 in the dts
filename instead of using something like xga, the fact that you say:
"I guess" that my answer to that is: I dunno I would need to look this
up in wikipedia or some such makes me think that using a qualifier like
xga is not going the help end users decide which dts file to pick, it
will just lead to them needing to go to wikipedia too. Also note that
the advertising of these tablets on ebay / aliexpress almost always
uses the resolution and not something like "xga".

<> >>

So all in all if we do not decide to use quirks for this I would like
to keep the filename as is.


Yeah, except that the display standard is also encoding the refresh
rate and color depth


Huh? No it does not, see e.g.:

https://en.wikipedia.org/wiki/Graphics_display_resolution

Note nothing about depth and refresh-rate there, and I've really never
heard anyone use things like xga to refer to colordepth and/or refreshrate


I was somehow convinced it did, and

https://en.wikipedia.org/wiki/Computer_display_standard


Hmm, that is a weird page it seems to be a rather low quality page for
wikipedia standards, for some reason it throws Atari ST models in there
as being display standards, and the bpp column makes sense for hercules,
cga and ega but not much which comes after that.

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 v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Wed, Jun 17, 2015 at 09:16:02AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 16-06-15 19:41, Maxime Ripard wrote:
> >Hi,
> >
> >On Sat, Jun 13, 2015 at 04:18:59PM +0200, Hans de Goede wrote:
> >>>Pantelis, to sum things up, we have a case of a tablet that comes with
> >>>the exact same board, but coming in two flavours with two differents
> >>>screen resolutions. It looks like a great case for your DT quirks
> >>>work, but we have no way of runtime detecting the difference between
> >>>the two variants. What do you think about this? Should we go with
> >>>using the DT quirks or is this simply out of scope?
> >>>
> >>>There's not so much example of similar cases in the kernel, and none
> >>>of them use quirks so far (obviously) but they all boil down to either
> >>>the solution you were suggesting in that patch or adding the alternate
> >>>configuration as a comment.
> >>>
> >>>I don't think the latter would work for you, and I agree with that, so
> >>>I guess that depending on what Pantelis says, either we go with a
> >>>better solution using the quirks, or we end up using what you
> >>>suggested (with a nitpick though, I'd prefer if you used the display
> >>>standard instead of the resolution, which would make it xga I guess?)
> >>
> >>If we go with a separate dts file for each of the 800x480 and 1024x600
> >>screens, I would greatly prefer to stick with the lcd1024x600 in the dts
> >>filename instead of using something like xga, the fact that you say:
> >>"I guess" that my answer to that is: I dunno I would need to look this
> >>up in wikipedia or some such makes me think that using a qualifier like
> >>xga is not going the help end users decide which dts file to pick, it
> >>will just lead to them needing to go to wikipedia too. Also note that
> >>the advertising of these tablets on ebay / aliexpress almost always
> >>uses the resolution and not something like "xga".
<> >>
> >>So all in all if we do not decide to use quirks for this I would like
> >>to keep the filename as is.
> >
> >Yeah, except that the display standard is also encoding the refresh
> >rate and color depth
> 
> Huh? No it does not, see e.g.:
> 
> https://en.wikipedia.org/wiki/Graphics_display_resolution
> 
> Note nothing about depth and refresh-rate there, and I've really never
> heard anyone use things like xga to refer to colordepth and/or refreshrate

I was somehow convinced it did, and

https://en.wikipedia.org/wiki/Computer_display_standard

seems to say that as well... Maybe not then, my bad.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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: Digital signature

[linux-sunxi] Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support

[Maxime Ripard]

On Wed, Jun 17, 2015 at 09:16:41AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 16-06-15 19:55, Maxime Ripard wrote:
> >Hi Pantelis,
> >
> >On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote:
> >>>I think we need to discuss this with Pantelis and what is his feeling
> >>>about this.
> >>>
> >>>Pantelis, to sum things up, we have a case of a tablet that comes with
> >>>the exact same board, but coming in two flavours with two differents
> >>>screen resolutions. It looks like a great case for your DT quirks
> >>>work, but we have no way of runtime detecting the difference between
> >>>the two variants. What do you think about this? Should we go with
> >>>using the DT quirks or is this simply out of scope?
> >>>
> >>>There's not so much example of similar cases in the kernel, and none
> >>>of them use quirks so far (obviously) but they all boil down to either
> >>>the solution you were suggesting in that patch or adding the alternate
> >>>configuration as a comment.
> >>>
> >>>I don't think the latter would work for you, and I agree with that, so
> >>>I guess that depending on what Pantelis says, either we go with a
> >>>better solution using the quirks, or we end up using what you
> >>>suggested (with a nitpick though, I'd prefer if you used the display
> >>>standard instead of the resolution, which would make it xga I guess?)
> >>>
> >>
> >>First of all, the quirks interface is at an RFC stage (new name
> >>suggested is ‘variants’); getting that out of the way this seems
> >>like what it is designed to do.
> >>
> >>The idea of the DT quirks is to drastically cut down on the number
> >>of different DTs required, each different for each board with minute
> >>differences from one another.
> >
> >We're on the same page then :)
> >
> >>In your case you have boards that have no way to be probed about
> >>what they ‘are’, but that’s no big problem. You can easily pass the
> >>board variant in the kernel command line and use that to select the
> >>quirk to apply.
> >
> >Hans actually pointed out that this would just move the logic
> >somewhere else, but not remove it. In our case, that would mean U-Boot
> >(Hans being the U-Boot maintainer for the SoCs that are used in this
> >particular board).
> >
> >That would still require us to have a different configuration and to
> >add some logic to pass that extra parameter to the kernel. I'd be glad
> >to have less stuff in the kernel, but I can understand that he doesn't
> >want more stuff either.
> >
> >>In fact the original patchset does contain a command line quirk for
> >>enabling and disabling the onboard emmc & hdmi of the beaglebone
> >>black for capes that need to use those signals.
> >
> >Ah. I somehow overlooked that when reading it.
> >
> >>Saying that, if you’re in a hurry I’d say go with a different DTSs
> >>for now, since that’s going to go in a near kernel cycle; DT quirks
> >>will be discussed at plumber’s in a couple of months, and then we’ll
> >>if it will go in and in what form.
> >
> >Ok. I won't be here this year, but if you could raise the topic of how
> >to handle "non-discoverable boards" then, it would be great.
> >
> >Hans, I guess we can go for your suggestion then: apply a "generic" DT
> >for the board right now, we're going to need it anyway. Then, when
> >will have real display support, depending on the current state of the
> >discussion for the quirks, we will either merge a different DT
> >including the generic one, or if the quirks have something that work
> >for both of us then, use the quirks. Sounds good?
> 
> Sounds good to me, will you make the changes while merging, or shall
> I do a new version of the patch ?

I'll apply and fix.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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: Digital signature

[linux-sunxi] Re: [PATCH 09/20] ARM: dts: sun4i: Enable USB DRC on the Cubieboard

[Hans de Goede]

Hi,

On 18-06-15 17:59, Maxime Ripard wrote:

Hi Hans,

On Fri, Jun 05, 2015 at 09:02:12PM +0200, Hans de Goede wrote:

Enable the otg/drc usb controller on the Cubieboard. Note that the
5V of the otg is directly connected to the general 5V, so we only use
the id pin.

Signed-off-by: Hans de Goede 
---
  arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts 
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 9afb4e0..046a84d 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -155,6 +155,10 @@
status = "okay";
  };

+&otg_sram {
+   status = "okay";
+};
+
  &pio {
led_pins_cubieboard: led_pins@0 {
allwinner,pins = "PH20", "PH21";
@@ -162,6 +166,13 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   usb0_id_detect_pin: usb0_id_detect_pin@0 {
+   allwinner,pins = "PH4";
+   allwinner,function = "gpio_in";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
  };

  ®_ahci_5v {
@@ -216,7 +227,15 @@
status = "okay";
  };

+&usb_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
  &usbphy {
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb0_id_detect_pin>;
+   usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */


Does that work?


Yes :)


Your phy driver seem to actively check at probe time for both the ID
detect and VBUS detect pins to be set in the DT, which is not the case
here.


My initial version did, later on I added a patch adding special handling
for boards which have Vusb hardwired to the 5V of the board such as the
cubieboard (the schematics show both a current regulator and an optional
0 ohm resistor to short-circuit that, it seems that the boards are
shipped with short-circuiting resistor, at least all mine are (both a10
and a20 variants).

See here for the patch:
https://github.com/jwrdegoede/linux-sunxi/commit/b73922986cab2bad9d54a2a1223583008e155bc4

This is part of the v5 phy-sun4i-usb series I send to Kishon a week ago.


I don't really get either why VBUS detect has to be set. Can't it work
just fine if you have a regulator that you can control and the ID pin
alone ?


Not really, we can work around it as done in the above commit, but it
is not ideal.

Vbus detect going low is used by the musb silicon to determine that the
current session has ended, and without this happening it will not
switch from host to device mode or vice versa no matter what the id pin
does.

Vbus detect is also used to not provide power to the port if external
power is present as doing so is not a good idea.

Last vbus-detect is used to detect that the devices connected to the
port are using too much power.

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: [RFC] A2x touchpad temperature readout

[Heiko Schröter]

Hello,

just seen that Hans did a temperature readout in sunxi-next in the 
sun4i-ts module.

Sorry for the noise.

Regards
Heiko


Am 18.06.2015 um 15:31 schrieb Heiko Schröter:

Hello,

i'd like to place a RFC for a Kernel Module reading out the TP
temperature of the A2x SoC.

- output via sysfs
- all THS registers are user configurable including start/stop
- module is initially turned off after loading. THS has to be enabled or
module loaded with param.
- module honors /proc/ioports

This module is the (base) test layout for the A33 (which i dont have)
and the A80 (which i hopefully get within the next days).

Tested on cubietruck 3.4.103 as module or compiled into kernel.
Compiles under mainline kernel but not tested.

This module should work for the A33 out of the box BUT no guarantee for
correct temp reading.
On A33 the calibration value for the THS is placed in the SID register(s).

Is such temp monitoring stuff useful at all ?
What do you think ?

Regards
Heiko


--
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 09/20] ARM: dts: sun4i: Enable USB DRC on the Cubieboard

[Maxime Ripard]

Hi Hans,

On Fri, Jun 05, 2015 at 09:02:12PM +0200, Hans de Goede wrote:
> Enable the otg/drc usb controller on the Cubieboard. Note that the
> 5V of the otg is directly connected to the general 5V, so we only use
> the id pin.
> 
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts 
> b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> index 9afb4e0..046a84d 100644
> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> @@ -155,6 +155,10 @@
>   status = "okay";
>  };
>  
> +&otg_sram {
> + status = "okay";
> +};
> +
>  &pio {
>   led_pins_cubieboard: led_pins@0 {
>   allwinner,pins = "PH20", "PH21";
> @@ -162,6 +166,13 @@
>   allwinner,drive = ;
>   allwinner,pull = ;
>   };
> +
> + usb0_id_detect_pin: usb0_id_detect_pin@0 {
> + allwinner,pins = "PH4";
> + allwinner,function = "gpio_in";
> + allwinner,drive = ;
> + allwinner,pull = ;
> + };
>  };
>  
>  ®_ahci_5v {
> @@ -216,7 +227,15 @@
>   status = "okay";
>  };
>  
> +&usb_otg {
> + dr_mode = "otg";
> + status = "okay";
> +};
> +
>  &usbphy {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb0_id_detect_pin>;
> + usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */

Does that work? 

Your phy driver seem to actively check at probe time for both the ID
detect and VBUS detect pins to be set in the DT, which is not the case
here.

I don't really get either why VBUS detect has to be set. Can't it work
just fine if you have a regulator that you can control and the ID pin
alone ?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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: Digital signature

Re: [linux-sunxi] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

The board is now on its way to Hans and I just took some pictures before 
and created an early wiki stub for 
M2: http://linux-sunxi.org/Sinovoip_Banana_Pi_M2

-- 
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] [RFC] A2x touchpad temperature readout

[Heiko Schröter]

Hello,

i'd like to place a RFC for a Kernel Module reading out the TP 
temperature of the A2x SoC.


- output via sysfs
- all THS registers are user configurable including start/stop
- module is initially turned off after loading. THS has to be enabled or 
module loaded with param.

- module honors /proc/ioports

This module is the (base) test layout for the A33 (which i dont have) 
and the A80 (which i hopefully get within the next days).


Tested on cubietruck 3.4.103 as module or compiled into kernel.
Compiles under mainline kernel but not tested.

This module should work for the A33 out of the box BUT no guarantee for 
correct temp reading.

On A33 the calibration value for the THS is placed in the SID register(s).

Is such temp monitoring stuff useful at all ?
What do you think ?

Regards
Heiko


From 615e5e0dda0715d4cb0f483b5a4cf39c68d61157 Mon Sep 17 00:00:00 2001
From: Heiko Schroeter 
Date: Thu, 18 Jun 2015 15:18:30 +0200
Subject: [PATCH 1/1] arm: Added A2X SoC temperature readout

 * Register values are user settable for platform depending
 * power saving etc.
 * THS registers: /sys/bus/platform/devices/a2x_thermal/
 * Naming scheme identical to A23 datasheet.
 * All settable register values in HEX.
 * /sys/bus/platform/devices/a2x_ths/settings shows all THS
 * register HEX values.
 *
 * THS registers are preset on module load, but NOT enabled
 * by default.
 * To start THS:
 * echo "0x1" > /sys/bus/platform/devices/a2x_thermal/ths_en
 * or
 * module_param: start_on_load=1 starts THS on module load.
 *
 * Temperature output in Celcius*100.

Signed-off-by: Heiko Schroeter 
---
 drivers/hwmon/Kconfig   |  14 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/a2x_thermal.c | 667 


 3 files changed, 682 insertions(+)
 create mode 100644 drivers/hwmon/a2x_thermal.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 25d9e72..9b996db 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,20 @@ config HWMON_DEBUG_CHIP

 comment "Native drivers"

+
+config A2X_THERMAL
+tristate "A2x SoC TP sensor controller"
+depends on !TOUCHSCREEN_SUN4I_TS
+help
+  If you say yes here you get support for the hardware temperature
+  monitoring sensor present in the touch screen controller on 
A2x SoC.
+  Output via sysfs i.e. 
/sys/bus/platform/devices/a2x_thermal/ths_data

+  Divied ths_data by 100 to get Celcius.
+  All other THS register settings are user settable by writing 
to sysfs.

+
+  This driver can be build as a module. If so, the module will 
called

+  a2x_thermal
+
 config SENSORS_AB8500
 tristate "AB8500 thermal monitoring"
 depends on AB8500_GPADC && AB8500_BM
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index b4a40f1..4e9d9cc 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -161,3 +161,4 @@ obj-$(CONFIG_PMBUS)+= pmbus/

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG

+obj-$(CONFIG_A2X_THERMAL)   += a2x_thermal.o
diff --git a/drivers/hwmon/a2x_thermal.c b/drivers/hwmon/a2x_thermal.c
new file mode 100644
index 000..a15bba2
--- /dev/null
+++ b/drivers/hwmon/a2x_thermal.c
@@ -0,0 +1,667 @@
+/*
+ * a2x_thermal.c  -- A2x touchpad temperature readout
+ *
+ * Copyright 2015 Heiko Schroeter
+ *
+ * Author: Heiko Schroeter
+ * schro...@physik.uni-bremen.de
+ *
+ * Ideas taken from various Authors using the hwmon_device interface.
+ *
+ *  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.
+ *
+ *
+ * ##
+ *
+ * Register values are user settable for platform depending
+ * power saving etc.
+ * THS registers: /sys/bus/platform/devices/a2x_thermal/
+ * Naming scheme identical to A23 datasheet.
+ * All settable register values in HEX.
+ * /sys/bus/platform/devices/a2x_ths/settings shows all THS
+ * register HEX values.
+ *
+ * THS registers are preset on module load, but NOT enabled
+ * by default.
+ * To start THS:
+ * echo "0x1" > /sys/bus/platform/devices/a2x_thermal/ths_en
+ * or
+ * module_param: start_on_load=1 starts THS on module load.
+ *
+ * Temperature output in Celcius*100.
+ *
+ * ###
+ *
+ * From A23 User Manual (Revision 1.0):
+ *
+ * 3.19 Thermal Sensor Controller
+ * 3.19.1 Overview
+ *
+ * The A23 supports thermal sensor controller to monitor the chip 
temperature.

+ *
+ * 3.19.2 Clock Tree and ADC Conversion Time
+ *
+ * A/D CONVERSION TIME
+ * When the clock source is 24MHz and the prescaler value M*N is 6,
+ * total 12-bit conversion time is as follows.
+ *
+ * CLK_IN = 24MHz/6 = 4MHz
+ *
+ * Conversion Time = 1/(4MHz/14Cycles) =3.50us
+ *
+ * If  ADC acquire  time  divider  is, the

[linux-sunxi] Re: [RFC PATCH V3] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet

[Maxime Ripard]

Hi,

On Tue, Jun 16, 2015 at 09:11:08PM +0200, Karsten Merker wrote:
> On Tue, Jun 16, 2015 at 11:40:27AM +0200, Maxime Ripard wrote:
> 
> > What I meant in my previous review was to use the syntax
> > 
> > &uart0 {
> >some-property;
> > };
> >   
> > Instead of duplicating the tree structure like you're doing
> > here. We've converted all the DT to that, so you can look around and
> > see how it's done in other boards (note that the nodes should be
> > sorted by alphabetical order).
> 
> Ah, sorry, I had misunderstood your original email in this regard.
> Following is a reworked version of the patch.
> 
> Changelog:
> 
> Version 1
> =
> - Original patch by Siarhei Siamashka
> 
> Version 2
> =
> - Use symbolic instead of numeric pinctrl values.
> 
> - Change the include syntax from /include/ to #include to make
>   the dts build with current kernels.
> 
> Version 3
> =
> - Use labels for nodes with modifications in relation to the dtsi
>   instead of replicating the tree structure.
> 
> - Remove the FSF address from the license header as done in
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/340437.html
>   for the other dts files to remove a checkpatch warning.
> 
> - Add msi to the vendor prefix list.
> 
> - Remove earlyprintk from the default kernel commandline.
> 
> - Replace the console kernel commandline parameter by a
>   /chosen/stdout-path node and add an alias serial0 -> uart0.

Next time, pleas try to keep the changelog with your patch, it's much
easier to read.

And please make the vendor prefix change a different patch.

> I have tagged this patch RFC as I am unsure what to do with the
> /chosen/stdout-path node. For now, I have set Siarhei's original
> choice (first serial port), but I am unsure whether this is the
> right thing to do as the Primo81 does by default not have a
> user-accessible serial port.  The only way to get a serial
> console is to either break the case open and find some test
> points that carry the RX/TX lines (which with the Primo81 case
> poses a high risk of breaking the display glass), or to use an SD
> card breakout board and change the pinmuxing for the SD card pins
> to the "serial" function.  The latter would not work without
> modifying the dts, so the SD-breakout case doesn't really count
> for setting the default stdout-path in the general use case.

Having that as a comment on top of whatever uart you've been using
would be great, so that people know where to look at on their device
to find it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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: Digital signature

Re: [linux-sunxi] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform

[bruce . he7]

Can you share the operating steps. 
Thanks.
On Tuesday, May 19, 2015 at 7:02:10 PM UTC+8, sergk...@gmail.com wrote:
> The problem is that there is usually NOAndroid kernel for device, for example 
> Chuwi vi8 super with its plarform (vendor) drivers and platform initial 
> settings.
> Actually I have found of the way how to detect corresponding gpio pin but it 
> is manual (scripted + manual) guessing (enumerating).
> Moreover from kenel to kernel this is different gpio pin number. I still 
> could not fix it how to immediately find out which exactly pin inside Z3735F 
> architecture is used and how to find out it's number in any linux kernelю
> Currently - I just enumerating all on concrete linux kernel and for each 
> kernel finding out its number - :( this is ridiculous but its works!
> 
> Regards, 
>    Serge.
> 
> On Tuesday, May 19, 2015 at 10:58:21 AM UTC+3, Henrik Nordström wrote:fre 
> 2015-05-15 klockan 18:40 -0400 skrev jons...@gmail.com:
> 
> > Another way - hook up JTAG. Use boundary scan to toggle the pins. That
> 
> > will tell you the pin number. Look up the pin number and figure out
> 
> > the GPIO.
> 
> 
> 
> Or look at the source of the Android kernel running on the device for
> 
> any hints.
> 
> 
> 
> Regards
> 
> Henrik

-- 
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] Banana Pi M2 (A31s based) ready to donate

[Thomas Kaiser]

Hi,

Hans de Goede wrote:
>
> On 18-06-15 08:53, Thomas Kaiser wrote: 
> > Anyone interested in a chinese A31s SBC called Banana Pi M2? 
>
> I'm interested, so that I can add upstream u-boot and kernel (dts file) 
> support for it. If you're ok with donating it to me let know and I'll 
> send you a private mail with my address (I'm in the Netherlands so 
> shipping should be ok).
>

Glad to hear that. Please send me address as well as the preferred shipping 
method based on your experiences (never sent anything to Netherlands before)
 

> > The board works, UART is accessible but the software the vendor provides 
> > (and his attitude) really suck: 
> > 
> http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2-regarding-software-support#2538
>  
> 
>  
>
> I feel I have to respond to this, I agree that bananapi.com is not 
> a good community player and the BPI boards they sell are best avoided (*).
>

Yes, it seems they don't understand that it also helps themselves if they 
would contribute to the community. If they would just publish the fex file 
they used for their 3.3 based images I could add the necessary AP6218 stuff 
to the dts file I recreated from the dtb file they supply with their 
4.0.0-rc5 based images (http://pastebin.com/GzHMW31m ) and I could use the 
board with mainline utilizing both GBit Ethernet as well as Wi-Fi. But they 
refuse to provide this stuff.

Regarding the M2 as a reference. I put some stuff online -- maybe it is of 
help to you or others working on the M2 or A31/A31s in general:

- stuff from their Raspbian 2.0 image (kernel 3.3.0, u-boot 
2011.09-rc1-dirty): http://kaiser-edv.de/tmp/OYrTyl/
- console output from this Raspbian image: http://pastebin.com/bXtb1buf
- console output from their 'Bananian' rip-off (same settings as before but 
also display initialisation f*cked up): http://pastebin.com/MJSVSfBc
- console output from their "Google Rpitc Image for M2" (u-boot 2015.04-rc4 
and kernel 4.0.0-rc2): http://pastebin.com/8uyu9hN6 
 

> However it is important to not mixup these bananapi people with the 
> original bananapi people from lemaker.org and the original bananapi 
> and bananapro boards. The people from lemaker.org are nice friendly 
> people who do work together with the linux-sunxi community, unlike 
> the people from bananapi.com.
>

Yes, I totally agree. But unfortunately the LeMaker guys seem to focus on a 
different set of SBCs now (2 based on Actions Semi's SoCs and one on i.MX6 
-- they published these images yesterday accidentally on their forum they 
messed up the last days totally: http://kaiser-edv.de/tmp/Wxnnxw/) so we'll 
have to see what that means regarding the Alwinner SBCs they supported in 
the past.
 
Regards,

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] Banana Pi M2 (A31s based) ready to donate

[Hans de Goede]

Hi,

On 18-06-15 08:53, Thomas Kaiser wrote:

Anyone interested in a chinese A31s SBC called Banana Pi M2?


I'm interested, so that I can add upstream u-boot and kernel (dts file)
support for it. If you're ok with donating it to me let know and I'll
send you a private mail with my address (I'm in the Netherlands so
shipping should be ok).


The board works, UART is accessible but the software the vendor provides
(and his attitude) really suck:
http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2-regarding-software-support#2538


I feel I have to respond to this, I agree that bananapi.com is not
a good community player and the BPI boards they sell are best avoided (*).

However it is important to not mixup these bananapi people with the
original bananapi people from lemaker.org and the original bananapi
and bananapro boards. The people from lemaker.org are nice friendly
people who do work together with the linux-sunxi community, unlike
the people from bananapi.com.

Confusing I know, which is why I felt I had to put in a good word
for the people from lemaker.org, who as said are good people.

Regards,

Hans


*) Still as the sunxi community we should try to help people unfortunate
enough to have bought such a board

--
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] Banana Pi M2 (A31s based) ready to donate

[Priit Laes]

On Wed, 2015-06-17 at 23:53 -0700, Thomas Kaiser wrote:
> Anyone interested in a chinese A31s SBC called Banana Pi M2?
> 
> The board works, UART is accessible but the software the vendor 
> provides (and his attitude) really suck: http://www.bananapi.com/inde
> x.php/forum/general-discussion-for-bpi-m2/895-status-quo-of-m2
> -regarding-software-support#2538
> 
> If any of the A31/A31s developers is interested I could donate this 
> piece of hardware (preferably in Germany/Europe -- shipping costs)

Well, you can't fully blame SinoVoip for that because according to
Olimex [1], the A31/A31s has been EOL'd by Allwinner and is a dead end.

[1] https://olimex.wordpress.com/2015/05/18/a31-som-update/

Though, someone from Allwinner should confirm that for us too ;)


Päikest,
Priit Laes :)

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