date:20140401

Re: [linux-sunxi] sun6i SPL support status update

2014-04-01 Thread Koen Kooi


Op 1 apr. 2014, om 21:55 heeft Olliver Schinagl  het 
volgende geschreven:

> On 03/31/2014 08:27 AM, Chen-Yu Tsai wrote:
>> Hi Hans,
>> 
>> On Sun, Mar 30, 2014 at 8:04 PM, Hans de Goede  wrote:
>>> Hi,
>>> 
>>> After wens pointed me to:
>>> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31
>>> 
>>> I've tried to get a full SPL going on sun6i. No luck sofar,
>>> dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram
>>> going, at least get_ram_size() likes it. But I cannot get the
>>> mmc to work in the SPL. I've narrowed this down to 2  problems,
>>> which I believe are related:
>>> 
>>> 1) The mmc controller will simply not work with pll6 as source,
>>> after adding a test for the pll6 lock bit I believe this is caused
>>> by pll6 never locking.
>>> 
>>> 2) When switching the mmc controller clocksource to OSC24M, then
>>> it does work, but gets stuck reading the first sector from the card.
>>> I believe this happens because the card is only being supplied 3.0V'
>>> rather then 3.3V.
>>> 
>>> Note that the same code works fine in the no SPL u-boot when loaded
>>> through boot0 + boot1.
>>> 
>>> Likely wrong power supply voltages are the culprit in both cases
>>> (the A31 also has a vdd-pll power pin.
>>> 
>>> So it looks like the next step is to first get the pmic going in
>>> u-boot (which will be useful even if booted through boot0 + 1, to
>>> enable the nic-phy if nothing else).
>> 
>> The A23 lichee u-boot has drivers for P2WI (used in sun6i) and RSB
>> (reduced serial bus, used on A23):
> Are they not the same? I haven't looked I admit, I just figured they changed 
> the name a little to make it sound distinctive.
> 
> Are they similar at all? If so, I guess that the i2c vs p2wi discussion held 
> a few days ago is moot then :)

"2 wire interface" is a way of avoiding paying NXP royalties for I2C while 
still producing the same hardware :)

regards,

Koen


> 
> Olliver
>> 
>> https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/p2wi
>> https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/rsb
>> 
>> And also PMIC drivers:
>> 
>> https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/power
>> 
>> Judging from the code, my guess is AXP221 and AXP223 or differ in
>> the type of interface supported.
>> 
>> Hope this helps. :)
>> 
>>> And then see from there. Maybe I'll take a shot at this tonight,
>>> for now I'm going to spend some time with my family.
>> 
>> 
>> Cheers,
>> ChenYu
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Build sunxi-next for A20

2014-04-01 Thread Olliver Schinagl


On 04/01/2014 10:04 PM, hmandevt...@gmail.com wrote:

I saw that Hans have a 3.13 branch
https://github.com/jwrdegoede/linux-sunxi/tree/sunxi-3.13

so, is it possible to use sunxi-fedora-scripts
https://github.com/jwrdegoede/sunxi-fedora-scripts

to build uboot and kernel image with this kernel ?
As long as you realize that the 3.13 kernel miss a lot of features ... 
Things like display etc.


But I don't see why not :)

--
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] Current u-boot crashes my cubietruck!

2014-04-01 Thread Olliver Schinagl


Top Posting!

I found the culprit. FAST_MBUS breaks it. After 48 hours of runs, 
enabling fast_mbus immediately breaks it even after boot.


Jens and Emilio hinted that the 3.4 driver reads the FEX file for the 
voltage. So the higher freq. runs at a lower voltage and that may cause it.


So I'll run without fast mbus for now, and it's stable again. Rock Solid 
if I may.


Sorry for all the noise :(

Olliver

On 03/30/2014 08:56 PM, Olliver Schinagl wrote:

On 03/30/2014 05:59 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote:

That said the sorts of random crashed you've been posting sound a lot
like either a DRAM issue or overheating. Either of which could be down
to u-boot setting up something wrong or bad hardware I suppose.

Overheating, maybe. It feels hottish to the touch, but can hold a finger
on it without any problem whatsoever. Not close to the pain point. So I
estimate < 50 C? Shouldn't be reason to be concerned imo.


Doesn't sound like it.


Power might be the problem, i see the input voltage under heavy load
drop to 4.65 Volts @ 0.9 amps


Could be that.


Have you checked the checksum of the tarball you are extracting and
tried unpacking it on a known good system?

The sha1sum matches, calculated on the board, so that's good. xz -d
completed successfully!

tar xvf fails however, with a big ass 5 page long oops.


I'd have thought that xz -d would be *far* more CPU intensive and
therefore liable to cause issues than tar xvf. If you were using
spinning rust rather than an SSD then I would be inclined to suspect the
power draw, but with you using an SSD I'm just not sure.


I agree! though even a heavily stressed CPU doesn't change power draw
hugely. Ssvb and I did some power tests a few months ago on the list.

Additionally! I should mention, my CT has a battery backup which should
be near full charge. a 1220 mAh battery, so even if the power supply
should drop to low or something, Wens assured me that the battery would
take over and no problem should be caused by bad power. Unless the
battery has run down of course, which I highly doubt, especially seeing
the constant current draw over USB.

So for now, I just hope it's not user error ...

Olliver



Ian.





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

Re: [linux-sunxi] Re: Build sunxi-next for A20

2014-04-01 Thread hmandevteam

I saw that Hans have a 3.13 branch
https://github.com/jwrdegoede/linux-sunxi/tree/sunxi-3.13

so, is it possible to use sunxi-fedora-scripts
https://github.com/jwrdegoede/sunxi-fedora-scripts

to build uboot and kernel image with this kernel ?

-- 
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] Current u-boot crashes my cubietruck!

2014-04-01 Thread Michal Suchanek

On 1 April 2014 15:48, Siarhei Siamashka  wrote:
> On Sun, 30 Mar 2014 20:56:57 +0200
> Olliver Schinagl  wrote:
>

> Too bad that really few people are willing or able to do the current
> draw measurements on their hardware. But at the same time, tweaking
> the CPU clock speed seems to be somewhat popular. It is not good when
> people overclock their CPU and decide that this is 'stable' after
> only letting it idle for a while. Then the very same people may
> encounter problems later and blame the first random thing that
> seems to be 'wrong' in their opinion, for example using the
> non-mainline kernel :-)
>
> To make power consumption measurements easier even for inexperienced
> users, I tried to hack on the AXP209 voltage/current monitoring support
> and sent some preliminary patches:
>
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03447.html

This is very nice.

There is always this option
http://www.dx.com/p/usb-av-usb-power-current-voltage-tester-translucent-blue-silver-235090
but you still have to power down the board, find enough adaptors to
put that thing in between the board and the PSU, and then the
measurements aren't scriptable, anyway.

Thanks

Michal

-- 
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 u-boot-sunxi 00/23] Add sun6i / A31 support (no SPL)

2014-04-01 Thread Olliver Schinagl


Hans and Maxime

Many thanks for working on this! I just wanted to share my appreciation 
on the whole series.


Also I see you have found use of my random patches i was typing without 
compile testing, without hardware ;) Hans, I do hope you saw my my notes 
that i started to make on one of the github commits pointing out some 
obvious mistakes that I made while hacking late at night many months ago!


I hope you received my other e-mail as well?

Thanks you two! Well everybody for all the hacking!

Olliver

On 04/01/2014 01:28 PM, Hans de Goede wrote:

Hi All,

This patch series adds basic support for sun6i. There are some bits there
to get SPL support going (clock setup, axp related code has been tested in SPL
mode too), but DRAM setup is missing, so no SPL support.

This series will give you a u-boot.bin binary which can be used to generate
the u-boot.bin on an sdcard image generated by the allwinner tools.

This u-boot.bin supports reading from mmc, has proper fdt support, and
properly sets up all the power supply voltages on the axp221:
-properly power the gpio's and sdcard at 3.3v, rather then undervolt them at 3v
-activate ldo1, and thus give power to the phy, so now we can go and test wens
  gmac for a31 work

If there are no objections I plan to push this series to the u-boot-sunxi repo
sunxi branch in a couple of days. In the mean time you can find it here:
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-a31-axp221

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] sun6i SPL support status update

2014-04-01 Thread Olliver Schinagl

On 03/31/2014 08:27 AM, Chen-Yu Tsai wrote:

Hi Hans,

On Sun, Mar 30, 2014 at 8:04 PM, Hans de Goede wrote:

Hi,

After wens pointed me to:
http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31

I've tried to get a full SPL going on sun6i. No luck sofar,
dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram
going, at least get_ram_size() likes it. But I cannot get the
mmc to work in the SPL. I've narrowed this down to 2 problems,
which I believe are related:

1) The mmc controller will simply not work with pll6 as source,
after adding a test for the pll6 lock bit I believe this is caused
by pll6 never locking.

2) When switching the mmc controller clocksource to OSC24M, then
it does work, but gets stuck reading the first sector from the card.
I believe this happens because the card is only being supplied 3.0V'
rather then 3.3V.

Note that the same code works fine in the no SPL u-boot when loaded
through boot0 + boot1.

Likely wrong power supply voltages are the culprit in both cases
(the A31 also has a vdd-pll power pin.

So it looks like the next step is to first get the pmic going in
u-boot (which will be useful even if booted through boot0 + 1, to
enable the nic-phy if nothing else).

The A23 lichee u-boot has drivers for P2WI (used in sun6i) and RSB
(reduced serial bus, used on A23):
Are they not the same? I haven't looked I admit, I just figured they
changed the name a little to make it sound distinctive.

Are they similar at all? If so, I guess that the i2c vs p2wi discussion
held a few days ago is moot then :)

Olliver

https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/p2wi
https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/rsb

And also PMIC drivers:

https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/power

Judging from the code, my guess is AXP221 and AXP223 or differ in
the type of interface supported.

Hope this helps. :)

And then see from there. Maybe I'll take a shot at this tonight,
for now I'm going to spend some time with my family.

Cheers,
ChenYu

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

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-04-01 Thread Olliver Schinagl


On 03/30/2014 08:56 PM, Olliver Schinagl wrote:

On 03/30/2014 05:59 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote:

That said the sorts of random crashed you've been posting sound a lot
like either a DRAM issue or overheating. Either of which could be down
to u-boot setting up something wrong or bad hardware I suppose.

Overheating, maybe. It feels hottish to the touch, but can hold a finger
on it without any problem whatsoever. Not close to the pain point. So I
estimate < 50 C? Shouldn't be reason to be concerned imo.


Doesn't sound like it.


Power might be the problem, i see the input voltage under heavy load
drop to 4.65 Volts @ 0.9 amps


Could be that.


Have you checked the checksum of the tarball you are extracting and
tried unpacking it on a known good system?

The sha1sum matches, calculated on the board, so that's good. xz -d
completed successfully!

tar xvf fails however, with a big ass 5 page long oops.


I'd have thought that xz -d would be *far* more CPU intensive and
therefore liable to cause issues than tar xvf. If you were using
spinning rust rather than an SSD then I would be inclined to suspect the
power draw, but with you using an SSD I'm just not sure.


I agree! though even a heavily stressed CPU doesn't change power draw
hugely. Ssvb and I did some power tests a few months ago on the list.

Additionally! I should mention, my CT has a battery backup which should
be near full charge. a 1220 mAh battery, so even if the power supply
should drop to low or something, Wens assured me that the battery would
take over and no problem should be caused by bad power. Unless the
battery has run down of course, which I highly doubt, especially seeing
the constant current draw over USB.

So for now, I just hope it's not user error ...

It is not, it is FAST_MBUS,

the board is still happily compiling, 24 hours later, latest u-boot, but 
without FAST_MBUS. It managed to do about 43 compiles this time :)


So for now, FAST_MBUS should be conciderd an 'overclocking option'. I'll 
try to enable it again;a nd maybe tune the voltage a little higher, then 
again; i don't have time fort hat right now ...


Olliver


Olliver



Ian.





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

[linux-sunxi] [PATCHv2 3.4 2/4] sunxi: axp20x: Human readable label for the temperature sensor

2014-04-01 Thread Siarhei Siamashka

Signed-off-by: Siarhei Siamashka 
---
 drivers/power/axp_power/axp20-mfd.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/power/axp_power/axp20-mfd.h 
b/drivers/power/axp_power/axp20-mfd.h
index 0021fb5..6ec26f6 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -39,6 +39,8 @@ show_temp(struct device *dev, struct device_attribute 
*devattr, char *buf)
return sprintf(buf, "264800\n");
if (attr->index == 2)
return sprintf(buf, "-144700\n");
+   if (attr->index == 3)
+   return sprintf(buf, "AXP20X temperature\n");
return sprintf(buf, "%d\n", data->temperature * 100);
 }
 
@@ -46,11 +48,13 @@ show_temp(struct device *dev, struct device_attribute 
*devattr, char *buf)
 static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
 static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
 static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_temp, NULL, 3);
 
 static struct attribute *axp20_attributes[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_min.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
+   &sensor_dev_attr_temp1_label.dev_attr.attr,
NULL
 };
 
-- 
1.8.3.2

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

[linux-sunxi] [PATCHv2 3.4 1/4] sunxi: axp20x: Fix misuse of the lowest 4-bits of temperature ADC

2014-04-01 Thread Siarhei Siamashka

Apparently bitwise '&' operator was supposed to be used here
instead of logical '&&'.

Signed-off-by: Siarhei Siamashka 
---
 drivers/power/axp_power/axp20-mfd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/axp_power/axp20-mfd.h 
b/drivers/power/axp_power/axp20-mfd.h
index 214856e..0021fb5 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -88,7 +88,7 @@ static struct axp_mfd_chip *axp20_update_device(struct device 
*dev)
low = 0;
}
 
-   data->temperature = -1447 + ((high << 4) + (low && 0x0F));
+   data->temperature = -1447 + ((high << 4) + (low & 0x0F));
data->last_updated = jiffies;
data->valid = 1;
}
-- 
1.8.3.2

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

[linux-sunxi] [PATCHv2 3.4 4/4] sunxi: axp20x: Calculate moving average for ACIN voltage/current/power

2014-04-01 Thread Siarhei Siamashka

As long as somebody is regularly accessing axp20x hwmon sysfs entries,
maintain a work queue for 25Hz periodic sampling of ACIN voltage/current
information. And calculate moving average using this data. This periodic
sampling stops after ~1 minute from the last access to axp20x hwmon sysfs.

Comparison of the current draw (in mA) for different workloads, measured
by the axp20x hwmon averaged stats (on the left side) and with a multimeter
(on the right side). The following sunxi based hardware has been tested
(without anything extra connected to USB/SATA):

Olinuxino-Lime (Allwinner A10):
   300  315
   555  590
   990 1060

Cubietruck (Allwinner A20):
   215  240
   310  345
   730  800

Cubieboard2 (Allwinner A20):
80  245
   180  415
   325  610
   490  820

Mele A2000 (Allwinner A10):
   180  450
   280  560
   450  770

AXP209 on Olinuxino-Lime and Cubietruck reports reasonably accurate
results. But not so much for the other devices.

v2: The decision whether to run periodic sampling is now fully
automatic. No configuration is needed. And no parasitic background
activity is expected when nobody is interested in axp20x hwmon
sysfs data.

Signed-off-by: Siarhei Siamashka 
---
 drivers/power/axp_power/axp-mfd.c   |  4 +++
 drivers/power/axp_power/axp20-mfd.h | 68 +
 include/linux/mfd/axp-mfd.h |  3 ++
 3 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/drivers/power/axp_power/axp-mfd.c 
b/drivers/power/axp_power/axp-mfd.c
index cfa894a..6fd1264 100644
--- a/drivers/power/axp_power/axp-mfd.c
+++ b/drivers/power/axp_power/axp-mfd.c
@@ -365,6 +365,10 @@ static int __devexit axp_mfd_remove(struct i2c_client 
*client)
 
 #ifdef CONFIG_AXP_HWMON
if (chip->itm_enabled == 1) {
+   cancel_delayed_work(&axp_hwmon_work);
+   flush_workqueue(wq);
+   destroy_workqueue(wq);
+
hwmon_device_unregister(chip->hwmon_dev);
sysfs_remove_group(&client->dev.kobj, &axp20_group);
}
diff --git a/drivers/power/axp_power/axp20-mfd.h 
b/drivers/power/axp_power/axp20-mfd.h
index 4244d49..fe7aeb1 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -28,13 +28,14 @@
 #include 
 #include 
 
-static struct axp_mfd_chip *axp20_update_device(struct device *dev);
+static struct
+axp_mfd_chip *axp20_update_device(struct device *dev, int from_wq);
 
 static ssize_t
 show_temp(struct device *dev, struct device_attribute *devattr, char *buf)
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
-   struct axp_mfd_chip *data = axp20_update_device(dev);
+   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
if (attr->index == 1)
return sprintf(buf, "264800\n");
if (attr->index == 2)
@@ -49,9 +50,11 @@ show_acin_voltage(struct device *dev, struct 
device_attribute *devattr,
  char *buf)
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
-   struct axp_mfd_chip *data = axp20_update_device(dev);
+   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
if (attr->index == 3)
return sprintf(buf, "ACIN voltage\n");
+   if (attr->index == 4)
+   return sprintf(buf, "%d\n", data->acin_avg_voltage / 64);
return sprintf(buf, "%d\n", data->acin_voltage);
 }
 
@@ -60,9 +63,11 @@ show_acin_current(struct device *dev, struct 
device_attribute *devattr,
  char *buf)
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
-   struct axp_mfd_chip *data = axp20_update_device(dev);
+   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
if (attr->index == 3)
return sprintf(buf, "ACIN current\n");
+   if (attr->index == 4)
+   return sprintf(buf, "%d\n", data->acin_avg_current / 64);
return sprintf(buf, "%d\n", data->acin_current);
 }
 
@@ -70,9 +75,11 @@ static ssize_t
 show_acin_power(struct device *dev, struct device_attribute *devattr, char 
*buf)
 {
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
-   struct axp_mfd_chip *data = axp20_update_device(dev);
+   struct axp_mfd_chip *data = axp20_update_device(dev, 0);
if (attr->index == 3)
return sprintf(buf, "ACIN power\n");
+   if (attr->index == 4)
+   return sprintf(buf, "%d\n", data->acin_avg_power / 64);
return sprintf(buf, "%d\n", data->acin_power);
 }
 
@@ -82,10 +89,13 @@ static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, 
NULL, 2);
 static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_temp, NULL, 3);
 static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, show_acin_voltage, NULL, 0);
 static SENSOR_DEVICE_ATTR(

[linux-sunxi] [PATCHv2 3.4 3/4] sunxi: axp20x: Report voltage, current and power for ACIN connector

2014-04-01 Thread Siarhei Siamashka

These measurements for ACIN (adapter input) are just the momentary
values sampled from ADC. But in order to have something more practical,
a lot of values need to be sampled and averaged. Just obtaining a
single output from the 'sensors' tool is not very meaningful,
because the momentary current draw changes very fast and within
a rather wide range (jumping up and down +-50% is not very uncommon).

To make accurate measurements possible at least from the userland,
it is unreasonable to limit the frequency of sysfs hwmon entries
update to just one read per two seconds. So this limitation has
been relaxed to allow polling at 50Hz.

v2: The measurement of ACIN current is done before anything else
because it is the most volatile parameter. And we want to
reduce the chances of the results being skewed by the CPU
activity related to reading the hwmon sysfs entry itself.

Signed-off-by: Siarhei Siamashka 
---
 drivers/power/axp_power/axp20-mfd.h | 92 +++--
 include/linux/mfd/axp-mfd.h |  3 ++
 2 files changed, 80 insertions(+), 15 deletions(-)

diff --git a/drivers/power/axp_power/axp20-mfd.h 
b/drivers/power/axp_power/axp20-mfd.h
index 6ec26f6..4244d49 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -44,17 +44,60 @@ show_temp(struct device *dev, struct device_attribute 
*devattr, char *buf)
return sprintf(buf, "%d\n", data->temperature * 100);
 }
 
+static ssize_t
+show_acin_voltage(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+   struct axp_mfd_chip *data = axp20_update_device(dev);
+   if (attr->index == 3)
+   return sprintf(buf, "ACIN voltage\n");
+   return sprintf(buf, "%d\n", data->acin_voltage);
+}
+
+static ssize_t
+show_acin_current(struct device *dev, struct device_attribute *devattr,
+ char *buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+   struct axp_mfd_chip *data = axp20_update_device(dev);
+   if (attr->index == 3)
+   return sprintf(buf, "ACIN current\n");
+   return sprintf(buf, "%d\n", data->acin_current);
+}
+
+static ssize_t
+show_acin_power(struct device *dev, struct device_attribute *devattr, char 
*buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+   struct axp_mfd_chip *data = axp20_update_device(dev);
+   if (attr->index == 3)
+   return sprintf(buf, "ACIN power\n");
+   return sprintf(buf, "%d\n", data->acin_power);
+}
 
 static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
 static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
 static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
 static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_temp, NULL, 3);
+static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, show_acin_voltage, NULL, 0);
+static SENSOR_DEVICE_ATTR(in0_label, S_IRUGO, show_acin_voltage, NULL, 3);
+static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, show_acin_current, NULL, 0);
+static SENSOR_DEVICE_ATTR(curr1_label, S_IRUGO, show_acin_current, NULL, 3);
+static SENSOR_DEVICE_ATTR(power1_input, S_IRUGO, show_acin_power, NULL, 0);
+static SENSOR_DEVICE_ATTR(power1_label, S_IRUGO, show_acin_power, NULL, 3);
 
 static struct attribute *axp20_attributes[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_min.dev_attr.attr,
&sensor_dev_attr_temp1_max.dev_attr.attr,
&sensor_dev_attr_temp1_label.dev_attr.attr,
+   &sensor_dev_attr_in0_input.dev_attr.attr,
+   &sensor_dev_attr_in0_label.dev_attr.attr,
+   &sensor_dev_attr_curr1_input.dev_attr.attr,
+   &sensor_dev_attr_curr1_label.dev_attr.attr,
+   &sensor_dev_attr_power1_input.dev_attr.attr,
+   &sensor_dev_attr_power1_label.dev_attr.attr,
NULL
 };
 
@@ -62,6 +105,25 @@ static const struct attribute_group axp20_group = {
.attrs = axp20_attributes,
 };
 
+static int axp_read_adc(struct device *dev, struct i2c_client *client, int reg)
+{
+   int err;
+   u8 high, low;
+
+   err = __axp_read(client, reg, &high);
+   if (err) {
+   dev_err(dev, "AXP Error while reading REG 0x%02X\n", reg);
+   high = 0;
+   }
+
+   err = __axp_read(client, reg + 1, &low);
+   if (err) {
+   dev_err(dev, "AXP Error while reading REG 0x%02X\n", reg + 1);
+   low = 0;
+   }
+
+   return (high << 4) + (low & 0x0F);
+}
 
 /*
  *  * function that update the status of the chips (temperature)
@@ -70,29 +132,29 @@ static struct axp_mfd_chip *axp20_update_device(struct 
device *dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct axp_mfd_chip *data = i2c_get_clientdata(client);
-   int err;
-   u8 high, low;
+   int adc_value;
 
mutex_lo

[linux-sunxi] [PATCHv2 3.4 0/4] Use AXP209 for the power consumption measurements

2014-04-01 Thread Siarhei Siamashka

These patches allow reasonably accurate voltage, current and power
consumption measurements on at least some of the Allwinner A10/A20 based
development boards using lm-sensors or by directly reading from sysfs.

So that some basic power consumption measurements can be done even by ordinary
users. Without access to lab power supplies, multimeters, cutting wires
and/or soldering :-)

These patches are also available here:
https://github.com/ssvb/linux-sunxi/commits/20140401-axp209-hwmon-v2

Example of a Cubietruck running under heavy load:

$ sensors
axp20_mfd-i2c-0-34
Adapter: sunxi-i2c.0
ACIN voltage:+5.03 V  (avg =  +5.01 V)
AXP20X temperature:  +57.6 C  (low  = -144.7 C, high = +264.8 C)
ACIN power:   3.02 W  (avg =   3.50 W)
ACIN current:+0.60 A  (avg =  +0.70 A)

For testing it is possible to run something like:

$ while sleep 5; do sensors; done;

And then try different CPU / GPU workloads. The reported 'avg' numbers
on the Cubietruck and on the A10-LIME should be pretty close to the numbers
measured by other methods (no more than 10% difference observed in my
tests). However there are some limitations. For example, USB peripherals
are apparently bypassing AXP209 on the Cubietruck and are not accounted
for. There is no such problem with the A10-LIME.

Some other devices (such as Cubieboard2 and Mele A2000) are showing
unrealistically low current draw. Apparently even more stuff is bypassing
AXP209 there. Or maybe just the calibration is off.

If anyone also has some means to measure voltage/current on some sunxi
hardware, please compare it with the information reported by the 'sensors'
tool after applying these patches and report your findings. Thanks.


v2: The decision whether to run periodic sampling is now fully
automatic. No configuration is needed. And no parasitic background
activity is expected when nobody is interested in axp20x hwmon
sysfs data.

Siarhei Siamashka (4):
  sunxi: axp20x: Fix misuse of the lowest 4-bits of temperature ADC
  sunxi: axp20x: Human readable label for the temperature sensor
  sunxi: axp20x: Report voltage, current and power for ACIN connector
  sunxi: axp20x: Calculate moving average for ACIN voltage/current/power

 drivers/power/axp_power/axp-mfd.c   |   4 +
 drivers/power/axp_power/axp20-mfd.h | 156 
 include/linux/mfd/axp-mfd.h |   6 ++
 3 files changed, 149 insertions(+), 17 deletions(-)

-- 
1.8.3.2

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

[linux-sunxi] [PATCH RESEND v5] ARM: sun4i: spi: Allow transfers larger than FIFO size

2014-04-01 Thread Alexandru Gagniuc

SPI transfers were limited to one FIFO depth, which is 64 bytes.
This was an artificial limitation, however, as the hardware can handle
much larger bursts. To accommodate this, we enable the interrupt when
the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
handler. The 3/4 ratio was chosen arbitrarily, with the intention to
reduce the potential number of interrupts.

Since the SUN4I_CTL_TP bit is set, the hardware will pause
transmission whenever the FIFO is full, so there is no risk of losing
data if we can't service the interrupt in time.

For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.

Signed-off-by: Alexandru Gagniuc 
Acked-by: Maxime Ripard 
---

Changes from v4:
 * use min3() instead of two if statements in sun4i_spi_fill_fifo()
 * fix trivial whitespace issue in if statement in sun4i_spi_handler()
 * use consistent style in assigning 'reg' in the added functions.

 drivers/spi/spi-sun4i.c | 71 ++---
 1 file changed, 62 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 3f82705..d80ceba 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -47,6 +47,8 @@
 #define SUN4I_CTL_TP   BIT(18)

 #define SUN4I_INT_CTL_REG  0x0c
+#define SUN4I_INT_CTL_RF_F34   BIT(4)
+#define SUN4I_INT_CTL_TF_E34   BIT(12)
 #define SUN4I_INT_CTL_TC   BIT(16)

 #define SUN4I_INT_STA_REG  0x10
@@ -62,11 +64,14 @@
 #define SUN4I_CLK_CTL_CDR1(div)(((div) & 
SUN4I_CLK_CTL_CDR1_MASK) << 8)
 #define SUN4I_CLK_CTL_DRS  BIT(12)

+#define SUN4I_MAX_XFER_SIZE0xff
+
 #define SUN4I_BURST_CNT_REG0x20
-#define SUN4I_BURST_CNT(cnt)   ((cnt) & 0xff)
+#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)

 #define SUN4I_XMIT_CNT_REG 0x24
-#define SUN4I_XMIT_CNT(cnt)((cnt) & 0xff)
+#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+

 #define SUN4I_FIFO_STA_REG 0x28
 #define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -97,6 +102,27 @@ static inline void sun4i_spi_write(struct sun4i_spi *sspi, 
u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
 }

+static inline u32 sun4i_spi_get_tx_fifo_count(struct sun4i_spi *sspi)
+{
+   u32 reg = sun4i_spi_read(sspi, SUN4I_FIFO_STA_REG);
+   reg >>= SUN4I_FIFO_STA_TF_CNT_BITS;
+   return reg & SUN4I_FIFO_STA_TF_CNT_MASK;
+}
+
+static inline void sun4i_spi_enable_interrupt(struct sun4i_spi *sspi, u32 mask)
+{
+   u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+   reg |= mask;
+   sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
+static inline void sun4i_spi_disable_interrupt(struct sun4i_spi *sspi, u32 
mask)
+{
+   u32 reg = sun4i_spi_read(sspi, SUN4I_INT_CTL_REG);
+   reg &= ~mask;
+   sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg);
+}
+
 static inline void sun4i_spi_drain_fifo(struct sun4i_spi *sspi, int len)
 {
u32 reg, cnt;
@@ -119,10 +145,13 @@ static inline void sun4i_spi_drain_fifo(struct sun4i_spi 
*sspi, int len)

 static inline void sun4i_spi_fill_fifo(struct sun4i_spi *sspi, int len)
 {
+   u32 cnt;
u8 byte;

-   if (len > sspi->len)
-   len = sspi->len;
+   /* See how much data we can fit */
+   cnt = SUN4I_FIFO_DEPTH - sun4i_spi_get_tx_fifo_count(sspi);
+
+   len = min3(len, (int)cnt, sspi->len);

while (len--) {
byte = sspi->tx_buf ? *sspi->tx_buf++ : 0;
@@ -175,8 +204,8 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
int ret = 0;
u32 reg;

-   /* We don't support transfer larger than the FIFO */
-   if (tfr->len > SUN4I_FIFO_DEPTH)
+   /* This is the maximum SPI burst size supported by the hardware */
+   if (tfr->len > SUN4I_MAX_XFER_SIZE)
return -EINVAL;

reinit_completion(&sspi->done);
@@ -274,7 +303,10 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);

/* Enable the interrupts */
-   sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
+   sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TC | 
SUN4I_INT_CTL_RF_F34);
+   /* Only enable Tx FIFO interrupt if we really need it */
+   if (tx_len > SUN4I_FIFO_DEPTH)
+   sun4i_spi_enable_interrupt(sspi, SUN4I_INT_CTL_TF_E34);

/* Start the transfer */
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
@@ -287,8 +319,6 @@ static int sun4i_spi_transfer_one(struct spi_master *master,

[linux-sunxi] Re: [PATCH v5] ARM: sun4i: spi: Allow transfers larger than FIFO size

2014-04-01 Thread Maxime Ripard

On Mon, Mar 31, 2014 at 09:16:51PM -0500, Alexandru Gagniuc wrote:
> SPI transfers were limited to one FIFO depth, which is 64 bytes.
> This was an artificial limitation, however, as the hardware can handle
> much larger bursts. To accommodate this, we enable the interrupt when
> the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
> handler. The 3/4 ratio was chosen arbitrarily, with the intention to
> reduce the potential number of interrupts.
> 
> Since the SUN4I_CTL_TP bit is set, the hardware will pause
> transmission whenever the FIFO is full, so there is no risk of losing
> data if we can't service the interrupt in time.
> 
> For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
> replenish the FIFO on large SPI bursts. This requires more care in
> when the interrupt is left enabled, as this interrupt will continually
> trigger when the FIFO is less than 1/4 full, even though we
> acknowledge it.
> 
> Signed-off-by: Alexandru Gagniuc 
> Acked-by: Maxime Ripard 

Hmmm, you forgot to Cc Mark Brown. Please resubmit it Ccing whoever
shows up using get_maintainer, otherwise, your patch won't be applied.

You also forgot the changes between this version and the previous one.

Thanks!
Maxime

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


signature.asc
Description: Digital signature

[linux-sunxi] Megafeis A08 wiki page.

2014-04-01 Thread Luc Verhaegen

Hi,

I have create the http://linux-sunxi.org/Megafeis_a08 device page and 
have done most of the work for you. Please fill in the blanks still and 
verify the information there.

Thanks.

Luc Verhaegen.

-- 
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] A31 u-boot with axp221 support now available

2014-04-01 Thread Maxime Ripard

On Tue, Apr 01, 2014 at 01:18:53PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 04/01/2014 12:19 PM, Maxime Ripard wrote:
> > On Tue, Apr 01, 2014 at 01:12:21AM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> Here is a branch of u-boot for the A31 with preliminary axp221
> >> support:
> >>
> >> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-a31-axp221
> >>
> >> Many thanks to Olliver for the initial p2wi and axp221 code, it was
> >> a good starting point. Note still no SPL, this is to be loaded
> >> from boot00 + boot1.
> >>
> >> Advantages over the allwinner generated images u-boot are:
> >> -fdt support
> >> -axp221 code will properly power the gpio's and sdcard at 3.3v, rather
> >> then undervolt them at 3v
> >> -axp221 code will activate ldo1, and thus give power to the phy,
> >> so now we can go and test wens gmac for a31 work
> > 
> > Cool! Thanks a lot for that.
> > 
> > How do you load it usually? From a SD Card? 
> 
> Yes I use your a31-sdcard.img and replace u-boot.bin in the linux dir
> with one built from scratch.

Ok.

> > Have you tried flashing to the NAND?
> 
> No.

Ok. I will then. My MMC slot starts to wear off, so the MMC is not
really an option anymore. I used to use fastboot, but I guess moving
it to the NAND, and use the GMAC then.

> Note I've finished up my sun6i patch series (which includes your initial
> work) to make it ready for pushing to the official u-boot-sunxi git
> repo. So if you're going to play with this, please make sure you've
> the latest code from:
> https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-a31-axp221
> 
> (no functional changes, just cleanups / FIXUP patches merging)

Yeah, I saw that. Thanks a lot for your efforts.

Maxime

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


signature.asc
Description: Digital signature

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-04-01 Thread Siarhei Siamashka

On Sun, 30 Mar 2014 20:56:57 +0200
Olliver Schinagl  wrote:

> On 03/30/2014 05:59 PM, Ian Campbell wrote:
> > On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote:
> >>> That said the sorts of random crashed you've been posting sound a lot
> >>> like either a DRAM issue or overheating. Either of which could be down
> >>> to u-boot setting up something wrong or bad hardware I suppose.
> >> Overheating, maybe. It feels hottish to the touch, but can hold a finger
> >> on it without any problem whatsoever. Not close to the pain point. So I
> >> estimate < 50 C? Shouldn't be reason to be concerned imo.
> >
> > Doesn't sound like it.
> >
> >> Power might be the problem, i see the input voltage under heavy load
> >> drop to 4.65 Volts @ 0.9 amps
> >
> > Could be that.
> >
> >>> Have you checked the checksum of the tarball you are extracting and
> >>> tried unpacking it on a known good system?
> >> The sha1sum matches, calculated on the board, so that's good. xz -d
> >> completed successfully!
> >>
> >> tar xvf fails however, with a big ass 5 page long oops.
> >
> > I'd have thought that xz -d would be *far* more CPU intensive and
> > therefore liable to cause issues than tar xvf. If you were using
> > spinning rust rather than an SSD then I would be inclined to suspect the
> > power draw, but with you using an SSD I'm just not sure.
> 
> I agree! though even a heavily stressed CPU doesn't change power draw 
> hugely. Ssvb and I did some power tests a few months ago on the list.

I'm not sure if I can really agree with this statement. Heavily
stressed CPU can draw a *lot* of power. Especially if it is
overclocked and overvolted:

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00906.html

There is also a recent discussion thread in the cubieboard support
mailing list:

https://groups.google.com/forum/#!topic/cubieboard/9WMBFAL7JBE

It looks like the failures reported there are caused by overheating,
when the temperature is gradually increasing under constant CPU load.
And it appears that the cubieboard folks are providing pre-built images
which set the CPU clock speed 1008MHz. This may make a significant
difference.

Too bad that really few people are willing or able to do the current
draw measurements on their hardware. But at the same time, tweaking
the CPU clock speed seems to be somewhat popular. It is not good when
people overclock their CPU and decide that this is 'stable' after
only letting it idle for a while. Then the very same people may
encounter problems later and blame the first random thing that
seems to be 'wrong' in their opinion, for example using the
non-mainline kernel :-)

To make power consumption measurements easier even for inexperienced
users, I tried to hack on the AXP209 voltage/current monitoring support
and sent some preliminary patches:

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg03447.html

-- 
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] initlogo.rle file size miss-match error

2014-04-01 Thread Dave McLaughlin

I have followed the instructions on how to create a new initlogo file but 
the size does not match when init tries to use it.

I used the following on a png file that is 800 x 480 and the file size is 
119,306 bytes.

After I run *convert -depth 8 initlogo.png rgb:initlogo.raw* the .raw file 
is 1,152,000 bytes in size. This is close to what the BMP version would be 
and that I assume includes header info. 1,152,054

I then run* rgb2565 -rle < initilogo.raw > initlogo.rle* and the file size 
is now 206,156 bytes

When init creates fbsize for it, it uses 800 x 480 x 4 which is 1,536,6000 
and this does not match the 206,156 and these 2 values show as in boot

init: width = 800
init: height = 480
init: s.st_size = 206156
init: logo match failed!fbsize = 153600

What am I doing wrong that I can't see??

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

47 matches

Mail list logo