Re: [linux-sunxi] Intermittent U-boot hang on A20 devices after reboot
Priit Laes writes: > Heya! > > I've been running into intermittent u-boot hangs > (latest u-boot and kernel mainline versions) on various > Olimex A20 Lime2 boards. These hangs seem to happen always > in the same spot after rebooting mainline kernel: > > [snip] > U-Boot SPL 2018.11-rc2-00064-gada6bb81d9-dirty (Nov 16 2018 - 15:48:29 +0200) > DR > [/snip] > > Any ideas what to test? is your power supply unit strong enough? (especially if you have LCD displays attached) jens -- 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: sunxi-3.4 display driver dpms bug?
pie...@gmail.com writes: > On Thursday, July 24, 2014 at 7:04:32 AM UTC-7, Jens Thiele wrote: >> if I do: P="/sys/devices/platform/disp/graphics/fb0/blank" echo 4 > >> $P; echo 4 > $P sleep 1 echo 0 > $P >> >> the display is switched off and i can't switch the display on >> anymore >> >> can someone confirm? > > I see the same thing, although I don't need to set it to '4' > twice. once is sufficient. > > i can't find any way to turn the display back on after... fyi: i switched to mainline kernel in the mean-time and use a ugly hack there, to switch the display on/off the proper way to go would be to add pwm backlight support in mainline but i never got around to be of any help there s.a. thread "simplefb and gpio_backlight?" starting with Message-ID: <87pp95mwwj@karme.de> greetings, jens -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Allwinner A20: systemd / Time has been changed
philippe.ba...@gmail.com writes: > Le lundi 23 novembre 2015 21:04:33 UTC+1, Karsten Merker a écrit : >> --> https://github.com/systemd/systemd/issues/1143 >> >> You could try booting with init=/bin/sh, manually set the correct >> time and write it to the RTC with hwclock. Afterwards - at least >> in theory - systemd should boot again... >> >> HTH, >> Karsten >> -- > > Thank you for the reply. > > I have kind of tried that solution. I have booted into the NAND image > (which was not using systemd). I booted successfully. Then i did > "hwclock -r" to read the time stored in RTC. It was correct > value. Then i reboot into the FBX using the microSD card. It did not > work. afair you really had to write to the RTC hwclock --systohc -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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: A20‑OLinuXino‑MICRO + A13‑LCD10TS: display sometimes distorted after soft reset
thought this problem might be caused by a too weak PSU as well and tested with a 12V/1A instead of 12V/0.5A - but that doesn't help. -- 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] A20‑OLinuXino‑LIME2: soft reset sometimes doesn't work and results in power off
Tsvetan Usunov writes: > try again with 2A PSU, the 10" backlight needs lot of power! > Tsvetan now tested with a 5V, 2.4A PSU so far I did only a quick test but until now I couldn't reproduce the problem (if it happens again I will report back). looks like that ugly problem is solved \o/ thanks! PS: guess I will have to make a table summing up the power consumption of the different boards, displays, peripherals and suggest some PSU based on that... Looks like Olimex doesn't have a nice fit there? Maybe this one: http://www.watterott.com/de/Netzteil-5V-3A will suffice PPS: i will also take another look at the display corruption problem mentioned in the other thread - maybe it is caused by a to weak PSU, too. -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] A20‑OLinuXino‑LIME2: soft reset sometimes doesn't work and results in power off
Hans de Goede writes: > Hi, > > On 22-10-15 17:20, Jens Thiele wrote: >> Hi, >> >> I _sometimes_ see another soft reset problem with another A20-based >> device (A20‑OLinuXino‑LIME2). [1] >> >> Anybody else? >> >> tested using kernel: >> 3.16.0-4-armmp-lpae #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) >> and u-boot: >> U-Boot SPL 2015.07+dfsg1~karme1-2 (Sep 23 2015 - 19:41:09) >> >> third reboot didn't work. > > Could it be this is a problem with your powersupply ? I have seen it with 2 different boards and PSUs. Unfortunately it only happens sometimes (needed up to 6 reset cycles to reproduce). To be precise, the setup was in both cases: A20‑OLinuXino‑LIME2 + LCD‑OLinuXino‑10TS + PSU: Olimex SY0605E [1] Maybe the PSU is to weak on boot? because otherwise the setup runs rock solid? Or there really is some problem on reset? Will try to reproduce without display or with the display separately powered... jens [1] https://www.olimex.com/Products/Power/SY0605E/ -- 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] A20‑OLinuXino‑LIME2: soft reset sometimes doesn't work and results in power off
Hi, I _sometimes_ see another soft reset problem with another A20-based device (A20‑OLinuXino‑LIME2). [1] Anybody else? tested using kernel: 3.16.0-4-armmp-lpae #1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09) and u-boot: U-Boot SPL 2015.07+dfsg1~karme1-2 (Sep 23 2015 - 19:41:09) third reboot didn't work. jens [1] see also "A20‑OLinuXino‑MICRO + A13‑LCD10TS: display sometimes distorted after soft reset" Message-ID: <87twpsy2le@karme.de> -- 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: A20‑OLinuXino‑MICRO + A13‑LCD10TS: display sometimes distorted after soft reset
Jens Thiele writes: > will try to build a version based on unstable (2015.10~rc4+dfsg1-1) and > report back just saw there is already a newer version in testing and built a slightly modified lcd+simplefb supporting version based on that one: $ dpkg --status u-boot-sunxi|grep ^Version Version: 2015.10~rc4+dfsg1~karme1-1 unfortunately it didn't fix the problem -- 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: A20‑OLinuXino‑MICRO + A13‑LCD10TS: display sometimes distorted after soft reset
Ian Campbell writes: > On Thu, 2015-10-15 at 10:10 +0200, Jens Thiele wrote: >> Hi, >> >> my display is sometimes distorted after a soft reset. >> (color components somehow shifted/mixed up?) >> >> tested with kernel up to >> $ uname -a >> Linux green 4.2.0-1-armmp-lpae #1 SMP Debian 4.2.1-2 (2015-09-27) >> armv7l GNU/Linux >> >> Anybody else seeing this? > > I don't have this platform but it might be worth trying a newer u-boot > (either from testing or upstream). should have included that: up to now used a slightly modified debian/testing version: $ dpkg --status u-boot-sunxi|grep ^Version Version: 2015.07+dfsg1~karme1-2 will try to build a version based on unstable (2015.10~rc4+dfsg1-1) and report back -- 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] A20‑OLinuXino‑MICRO + A13‑LCD10TS: display sometimes distorted after soft reset
Hi, my display is sometimes distorted after a soft reset. (color components somehow shifted/mixed up?) tested with kernel up to $ uname -a Linux green 4.2.0-1-armmp-lpae #1 SMP Debian 4.2.1-2 (2015-09-27) armv7l GNU/Linux Anybody else seeing this? -- 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 2/6] ARM: dts: sun7i: Enable USB DRC on Bananapi
Hans de Goede writes: > Enable the otg/drc usb controller on the Bananapi. would something similar apply to the a20 olimex olinuxino micro/lime2 boards? is there some documentation how to port devicetree improvements/new features to all boards or to at least help with that? i think you did some workshop like that? i think i have seen other features being added only to some boards? pwm backlight? audio output? but my understanding of all of this is really very limited. thanks, Jens -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Mainline kernel- usb don't work after "startx"
91.mate...@gmail.com writes: > Can anybody help me with this? I only need minimal debian with > mainline kernel, lxde and working usb. any specific reason not to use the debian/jessie kernel? s.a. https://wiki.debian.org/InstallingDebianOn/Allwinner jens PS: afaik if you want to have working usb keyboard in u-boot you still have to use a usb hub (maybe this is no longer true for newer u-boots?) -- 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] mainline and a20 olinuxino micro/lime2: battery charging supported?
Hi, what's the state of mainline regarding battery charging a20 olinuxino micro/lime2? did only have a quick look at the code and i think it isn't supported yet? or is it supported anyway and there are just no "controls"? just don't want to see those lipos to be on fire -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Backporting simplefb support to 3.16 kernel
sorry, did send to early, by accident¹ finally got around to also test: A20‑OLinuXino‑MICRO + - VGA - second SD card slot (MMC1) - A13-LCD7-TS - A13-LCD10TS - HDMI everything looks good and very stable so far there seems to be a small problem with (serial?) console output on boot, but I don't know, when i will have time to take a closer look. jens ¹ Emacs org-mode toggle check-box button key combo is the same as gnus send -- 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] Backporting simplefb support to 3.16 kernel
Jens Thiele writes: > tests with 7" display, A20‑OLinuXino‑MICRO, HDMI, VGA, second sd-card > slot on micro, ... will follow. If everything works fine i will just > downgrade from 3.19 to 3.16 then... finally got around to test: A20‑OLinuXino‑MICRO - [ ] A13-LCD7-TS -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Julian Calaby writes:
>> Modified
>> Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> index aef5779..b4ea9c4 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> @@ -7,9 +7,13 @@ Required properties:
>> - interrupts: interrupt to which the chip is connected
>>
>> Optional properties:
>> - - allwinner,ts-attached: boolean indicating that an actual touchscreen is
>> - attached to the controller
>> -
>> + - allwinner,ts-attached: boolean indicating that an actual
>> touchscreen
>> + is attached to the controller
>> + - allwinner,ts-sensitive-adjust : integer (4 bits), adjust sensitivity
>> + between 0 (least sensitive) and 15
>> + (defaults to 15)
>> + todo: added in 4.x?
>> + is there some "standard" way to track
>> this?
>
> It's called "Sensitive level" in the FEX files, so I'd recommend
> calling it that here to help people when they're converting FEX files,
> however the code calls it sensitive adjust so both are probably
> equally good.
the A20 manual calls it TP_SENSITIVE_ADJUST
=> changed to tp-sensitive-adjust
see also patch just submitted
>> Example:
>>
>> rtp: rtp@01c25000 {
>> @@ -17,4 +21,5 @@ Example:
>> reg = <0x01c25000 0x100>;
>> interrupts = <29>;
>> allwinner,ts-attached;
>> + allwinner,ts-sensitive-adjust = <0>;
>> };
>> Modified drivers/input/touchscreen/sun4i-ts.c
>> diff --git a/drivers/input/touchscreen/sun4i-ts.c
>> b/drivers/input/touchscreen/sun4i-ts.c
>> index e692f8e..973 100644
>> --- a/drivers/input/touchscreen/sun4i-ts.c
>> +++ b/drivers/input/touchscreen/sun4i-ts.c
>> @@ -216,6 +216,7 @@ static int sun4i_ts_probe(struct platform_device *pdev)
>> struct device *hwmon;
>> int error;
>> bool ts_attached;
>> + u32 ts_sensitive_adjust = 15; /* use old fixed value as default */
>>
>> ts = devm_kzalloc(dev, sizeof(struct sun4i_ts_data), GFP_KERNEL);
>> if (!ts)
>> @@ -263,11 +264,19 @@ static int sun4i_ts_probe(struct platform_device *pdev)
>> writel(ADC_CLK_SEL(0) | ADC_CLK_DIV(2) | FS_DIV(7) | T_ACQ(63),
>>ts->base + TP_CTRL0);
>>
>> + /* optional property
>> + todo:
>> + - use of_property_read_u8 ?
>> + - check range / 4bits, 0 - 15 ?
>> +"device tree schemas and validation"
>> +http://lwn.net/Articles/568217/
>> +or clamp? or ... */
>> + of_property_read_u32(np, "allwinner,ts-sensitive-adjust",
>> &ts_sensitive_adjust);
>> +
>
> Personally, if there's a u8 version of of_property_read() I'd use that
> (and make the variable above a u8 also). Either way there needs to be
> some level of validation and clamping before it gets passed into
> writel() below.
after taking a look at the other drivers, i think of_property_read_u32
is easier and the devicetree is supposed to have valid values
>
>> /*
>> -* sensitive_adjust = 15 : max, which is not all that sensitive,
>> * tp_mode = 0 : only x and y coordinates, as we don't use dual touch
>> */
>> - writel(TP_SENSITIVE_ADJUST(0) | TP_MODE_SELECT(0),
>> + writel(TP_SENSITIVE_ADJUST(ts_sensitive_adjust) | TP_MODE_SELECT(0),
>
> I'm guessing this is on top of your original patch? You should make
> your patches on top of upstream.
fixed
> Thanks,
thanks,
jens
--
Prisirah - Building digital photo frames for family and friends using
open-source hardware. http://karme.de/prisirah/
--
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] Input: sun4i-ts - allow to adjust some settings via device-tree properties.
This commit introduces two new optional device-tree properties: "tp-sensitive-adjust": adjust sensitivity of pen down detection "filter-type": select median and averaging filter The previous fixed defaults, didn't work well for the Olimex A13-LCD10TS (I have). Signed-off-by: Jens Thiele --- .../devicetree/bindings/input/touchscreen/sun4i.txt | 19 +-- drivers/input/touchscreen/sun4i-ts.c| 17 + 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt index 42d..c93edfa 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt @@ -8,8 +8,20 @@ Required properties: - #thermal-sensor-cells: shall be 0 Optional properties: - - allwinner,ts-attached: boolean indicating that an actual touchscreen is - attached to the controller + - allwinner,ts-attached: boolean indicating that an actual touchscreen + is attached to the controller + - allwinner,tp-sensitive-adjust : integer (4 bits) + adjust sensitivity of pen down detection + between 0 (least sensitive) and 15 + (defaults to 15) + - allwinner,filter-type: integer (2 bits) + select median and averaging filter + samples used for median / averaging filter + 0: 4/2 + 1: 5/3 + 2: 8/4 + 3: 16/8 + (defaults to 1) Example: @@ -19,4 +31,7 @@ Example: interrupts = <29>; allwinner,ts-attached; #thermal-sensor-cells = <0>; + /* sensitive/noisy touch panel */ + allwinner,tp-sensitive-adjust = <0>; + allwinner,filter-type = <3>; }; diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c index b93a28b..d1cf847 100644 --- a/drivers/input/touchscreen/sun4i-ts.c +++ b/drivers/input/touchscreen/sun4i-ts.c @@ -30,6 +30,10 @@ * These kinds of heuristics are just asking for trouble (and don't belong * in the kernel). So this driver offers straight forward, reliable single * touch functionality only. + * + * s.a. A20 User Manual "1.15 TP" (Documentation/arm/sunxi/README) + * (looks like the description in the A20 User Manual v1.3 is better + * than the one in the A10 User Manual v.1.5) */ #include @@ -246,6 +250,9 @@ static int sun4i_ts_probe(struct platform_device *pdev) int error; u32 reg; bool ts_attached; + /* optional device-tree properties, use old fixed values as default */ + u32 tp_sensitive_adjust = 15; + u32 filter_type = 1; ts = devm_kzalloc(dev, sizeof(struct sun4i_ts_data), GFP_KERNEL); if (!ts) @@ -313,14 +320,16 @@ static int sun4i_ts_probe(struct platform_device *pdev) ts->base + TP_CTRL0); /* -* sensitive_adjust = 15 : max, which is not all that sensitive, +* tp_sensitive_adjust is an optional property * tp_mode = 0 : only x and y coordinates, as we don't use dual touch */ - writel(TP_SENSITIVE_ADJUST(15) | TP_MODE_SELECT(0), + of_property_read_u32(np, "allwinner,tp-sensitive-adjust", &tp_sensitive_adjust); + writel(TP_SENSITIVE_ADJUST(tp_sensitive_adjust) | TP_MODE_SELECT(0), ts->base + TP_CTRL2); - /* Enable median filter, type 1 : 5/3 */ - writel(FILTER_EN(1) | FILTER_TYPE(1), ts->base + TP_CTRL3); + /* Enable median and averaging filter, optional property for filter type */ + of_property_read_u32(np, "allwinner,filter-type", &filter_type); + writel(FILTER_EN(1) | FILTER_TYPE(filter_type), ts->base + TP_CTRL3); /* Enable temperature measurement, period 1953 (2 seconds) */ writel(TEMP_ENABLE(1) | TEMP_PERIOD(1953), ts->base + TP_TPR); -- 1.7.10.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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Julian Calaby writes:
> Hi Jens,
Hi,
[...]
> IMHO we should have access to all the parameters that can be
> configured per-device in the DTS. That we don't is a bug that arguably
> should be fixed. Again, I urge you to make that parameter available in
> device tree as it'll be useful for you in conjunction with device tree
> overlays.
ok, I thought I will give it a try and that it should be trivial to at
least add a property for TP_SENSITIVE_ADJUST in a few minutes. But it
looks like the details need some more knowledge/thinking (I am a kernel
and device tree noob). My current diff is attached (inline), any review
/ comments are very welcome (especially the "todo:" points).
thanks,
jens
--
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.
Changes at prisirah
Modified Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
index aef5779..b4ea9c4 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
@@ -7,9 +7,13 @@ Required properties:
- interrupts: interrupt to which the chip is connected
Optional properties:
- - allwinner,ts-attached: boolean indicating that an actual touchscreen is
- attached to the controller
-
+ - allwinner,ts-attached: boolean indicating that an actual touchscreen
+ is attached to the controller
+ - allwinner,ts-sensitive-adjust : integer (4 bits), adjust sensitivity
+ between 0 (least sensitive) and 15
+ (defaults to 15)
+ todo: added in 4.x?
+ is there some "standard" way to track this?
Example:
rtp: rtp@01c25000 {
@@ -17,4 +21,5 @@ Example:
reg = <0x01c25000 0x100>;
interrupts = <29>;
allwinner,ts-attached;
+ allwinner,ts-sensitive-adjust = <0>;
};
Modified drivers/input/touchscreen/sun4i-ts.c
diff --git a/drivers/input/touchscreen/sun4i-ts.c
b/drivers/input/touchscreen/sun4i-ts.c
index e692f8e..973 100644
--- a/drivers/input/touchscreen/sun4i-ts.c
+++ b/drivers/input/touchscreen/sun4i-ts.c
@@ -216,6 +216,7 @@ static int sun4i_ts_probe(struct platform_device *pdev)
struct device *hwmon;
int error;
bool ts_attached;
+ u32 ts_sensitive_adjust = 15; /* use old fixed value as default */
ts = devm_kzalloc(dev, sizeof(struct sun4i_ts_data), GFP_KERNEL);
if (!ts)
@@ -263,11 +264,19 @@ static int sun4i_ts_probe(struct platform_device *pdev)
writel(ADC_CLK_SEL(0) | ADC_CLK_DIV(2) | FS_DIV(7) | T_ACQ(63),
ts->base + TP_CTRL0);
+ /* optional property
+ todo:
+ - use of_property_read_u8 ?
+ - check range / 4bits, 0 - 15 ?
+"device tree schemas and validation"
+http://lwn.net/Articles/568217/
+or clamp? or ... */
+ of_property_read_u32(np, "allwinner,ts-sensitive-adjust",
&ts_sensitive_adjust);
+
/*
-* sensitive_adjust = 15 : max, which is not all that sensitive,
* tp_mode = 0 : only x and y coordinates, as we don't use dual touch
*/
- writel(TP_SENSITIVE_ADJUST(0) | TP_MODE_SELECT(0),
+ writel(TP_SENSITIVE_ADJUST(ts_sensitive_adjust) | TP_MODE_SELECT(0),
ts->base + TP_CTRL2);
/* Enable median filter, type 1 : 5/3 */
--
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: backporting A20-OLinuXino-LIME2 support to 3.16 kernel
Jens Thiele writes: > just got: > [12041.992438] usb 4-1: SerialNumber: [...] > [12042.115080] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD RTO !! > [12042.263156] sunxi-mmc 1c0f000.mmc: data error, sending stop command > [12042.419970] sunxi-mmc 1c0f000.mmc: send stop command failed > [12042.561641] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12042.703576] mmcblk0: error -110 sending status command, retrying > [12042.853876] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12042.995393] mmcblk0: error -110 sending status command, retrying > [12043.145709] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12043.287337] mmcblk0: error -110 sending status command, aborting > [12043.437671] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12043.579375] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12043.721055] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12043.862702] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! > [12044.004662] mmc0: card removed aeh - shame on me "card removed" yes, so it was - i accidently removed the card without noticing sorry, for the noise :( $ translate extrem peinlich extrem peinlich :: cringe-making -- 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.
backporting A20-OLinuXino-LIME2 support to 3.16 kernel (Was: Re: [linux-sunxi] Backporting simplefb support to 3.16 kernel)
Jens Thiele writes: > just tested on A20‑OLinuXino‑LIME2 + LCD‑OLinuXino‑10TS > prisirah@prisirah:~$ uname -a > Linux prisirah 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) armv7l > GNU/Linux > and it works™ :-) just got: [12041.992438] usb 4-1: SerialNumber: [...] [12042.115080] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 18, RD RTO !! [12042.263156] sunxi-mmc 1c0f000.mmc: data error, sending stop command [12042.419970] sunxi-mmc 1c0f000.mmc: send stop command failed [12042.561641] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12042.703576] mmcblk0: error -110 sending status command, retrying [12042.853876] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12042.995393] mmcblk0: error -110 sending status command, retrying [12043.145709] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12043.287337] mmcblk0: error -110 sending status command, aborting [12043.437671] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12043.579375] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12043.721055] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12043.862702] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 13, RTO !! [12044.004662] mmc0: card removed maybe sunxi-mmc needs some backporting, too? -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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.
touchscreen .dts variants for debian's 3.16 kernel? (Was: Re: [linux-sunxi] Backporting simplefb support to 3.16 kernel)
would it be possible to add touchscreen .dts variants to the debian
kernel source? the touchscreen variant adds:
+ rtp: rtp@01c25000 {
+ allwinner,ts-attached;
+ };
yes, it is ugly, and afair Hans de Goede proposed a different solution
on linux-sunxi (device tree overlays?) i didn't have time to understand,
yet.
But it would make it simple to support the A13‑LCD7‑TS, A13‑LCD10TS,
LCD‑OLinuXino‑7TS, LCD-OLinuXino-10TS touchscreens. But maybe I miss
something obvious here?
to make it more clear:
arch/arm/boot/dts$ diff -u sun7i-a20-olinuxino-lime2.dts
sun7i-a20-olinuxino-lime2-ts.dts
--- sun7i-a20-olinuxino-lime2.dts 2015-02-26 08:58:23.835048514 +0100
+++ sun7i-a20-olinuxino-lime2-ts.dts2015-02-26 08:58:23.831048451 +0100
@@ -107,6 +107,10 @@
};
};
+ rtp: rtp@01c25000 {
+ allwinner,ts-attached;
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
arch/arm/boot/dts$ diff -u sun7i-a20-olinuxino-micro.dts
sun7i-a20-olinuxino-micro-ts.dts
--- sun7i-a20-olinuxino-micro.dts 2015-02-26 08:58:23.835048514 +0100
+++ sun7i-a20-olinuxino-micro-ts.dts2015-03-06 17:06:33.375603380 +0100
@@ -103,6 +103,10 @@
};
};
+ rtp: rtp@01c25000 {
+ allwinner,ts-attached;
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
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] Backporting simplefb support to 3.16 kernel
Jens Thiele writes: > thanks, for clarifying. Will test > Package: linux-image-3.16.0-4-armmp > Version: 3.16.7-ckt7-1 > then. just tested on A20‑OLinuXino‑LIME2 + LCD‑OLinuXino‑10TS prisirah@prisirah:~$ uname -a Linux prisirah 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) armv7l GNU/Linux and it works™ :-) tests with 7" display, A20‑OLinuXino‑MICRO, HDMI, VGA, second sd-card slot on micro, ... will follow. If everything works fine i will just downgrade from 3.19 to 3.16 then... PS: it somehow feels a bit slower? (maybe just caused by different kernel config?!) do the DRAM clocks differ bettween 3.16 and 3.19? don't think so as u-boot sets them up? -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Backporting simplefb support to 3.16 kernel
Karsten Merker writes: > On Fri, Mar 06, 2015 at 02:17:06PM +0100, Jens Thiele wrote: >> reading >> http://linux-sunxi.org/Linux_mainlining_effort >> " >> Merged into 3.19 >> □ USB phy driver support for usb0 >> " >> i think usb kernel support is missing in 3.16 or do i misunderstand/is >> there a backport, too? > > That is probably a misunderstanding - this commit refers to the > OTG port, for which there is indeed no support in kernel 3.16. > > The two USB host ports are supported in kernel 3.16. thanks, for clarifying. Will test Package: linux-image-3.16.0-4-armmp Version: 3.16.7-ckt7-1 then. >> On the other hand maybe flash-kernel is supposed to also handle >> u-boot updates (didn't even know this exists)? > > No, flash-kernel does not update u-boot. It generates boot > scripts to be executed by u-boot, builds uImages to be loaded > by u-boot and has the ability to write kernel images to onboard > flash on certain devices, but it does not touch u-boot itself. ok, thanks. => imho simplefb+lcd support for debian/jessie u-boot isn't that important, then. Greetings, jens -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Backporting simplefb support to 3.16 kernel
Karsten Merker writes: > On Fri, Mar 06, 2015 at 12:52:01PM +0100, Jens Thiele wrote: > >> Does that mean there is a realistic chance to have Olimex A20-Olinuxino >> Micro+simplefb support in jessie (maybe not A20-OLinuXino-LIME2)? > > General support for the LIME2 in Jessie is on the way. Kernel support > for it is in the linux 3.16.7-ckt7-1 package which will hopefully > enter Jessie this weekend; installer support has already migrated to > Jessie, just u-boot is still an open topic - I have backported > support for the LIME2 to u-boot 2014.10+dfsg1-3, but that is > currently only available in unstable. > > I will update the wiki accordingly as soon as the kernel migration is > finished. wow, great! thanks a lot! will have to test then (if usb works - see also other mail). >> That would be really great (somehow didn't expect that, but I didn't >> look at the diff from 3.16). Last time I looked u-boot in testing/jessie >> was to old, too. Did someone look at that, too? > > See above - u-boot 2014.10+dfsg1-3 in unstable has backported system > support for the LIME2, but it does not contain a backport of the > simplefb infrastructure bits, so for using simplefb, you would still > need a newer upstream u-boot in any case. > >> 4.2 U-Boot >> >> To boot the Linux kernel the boot loader "Das U-Boot" is used. U-Boot's state >> is similar to the kernel's. Debian's U-Boot package can't be used, yet. Also >> thanks to the sunxi community it became possible to use a U-Boot version very >> close to upstream^20. > > Why "very close to upstream"? AFAICS current upstream u-boot supports > everything you need, doesn't it? afair, at the time i wrote that it didn't / i had troubles with "Unknown command 'part'" likely this was fixed some time ago, s.a. Message-ID: <54d607ad.7020...@redhat.com> " You need the attached patch for upstream u-boot/master to work on sunxi devices, this should get merged upstream soon. From: Hans de Goede Date: Sat, 7 Feb 2015 13:23:39 +0100 Subject: [PATCH v2] config_distro_bootcmd.h: Enable CONFIG_CMD_PART The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be defined, as the default bootcmd now uses the "part" command. This fixes sunxi boards not booting with v2015.04-rc1. Signed-off-by: Hans de Goede " but I didn't get around to test it. the git tree at http://www.karme.de/git/u-boot ¹ is git://git.denx.de/u-boot-sunxi.git commit 5abdb156bb5c2685744be3620c4bdb1875bd81ce + additional defconfigs for lcd(+ts) support. -- 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. Changes from prisirah~1^2 to prisirah Newconfigs/A20-OLinuXino-Lime2-lcd10_defconfig diff --git a/configs/A20-OLinuXino-Lime2-lcd10_defconfig b/configs/A20-OLinuXino-Lime2-lcd10_defconfig new file mode 100644 index 000..5ee48ab --- /dev/null +++ b/configs/A20-OLinuXino-Lime2-lcd10_defconfig @@ -0,0 +1,12 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI" +CONFIG_FDTFILE="sun7i-a20-olinuxino-lime2-ts.dtb" +CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:45000,le:150,ri:16,up:21,lo:2,hs:10,vs:2,sync:3,vmode:0" +CONFIG_VIDEO_LCD_POWER="PH8" +CONFIG_VIDEO_LCD_BL_PWM="PB2" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_DRAM_CLK=480 ++S:CONFIG_DRAM_ZQ=127 ++S:CONFIG_DRAM_EMR1=4 Newconfigs/A20-OLinuXino-Lime2-lcd7_defconfig diff --git a/configs/A20-OLinuXino-Lime2-lcd7_defconfig b/configs/A20-OLinuXino-Lime2-lcd7_defconfig new file mode 100644 index 000..64cd30a --- /dev/null +++ b/configs/A20-OLinuXino-Lime2-lcd7_defconfig @@ -0,0 +1,12 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI" +CONFIG_FDTFILE="sun7i-a20-olinuxino-lime2-ts.dtb" +CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0" +CONFIG_VIDEO_LCD_POWER="PH8" +CONFIG_VIDEO_LCD_BL_PWM="PB2" ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_DRAM_CLK=480 ++S:CONFIG_DRAM_ZQ=127 ++S:CONFIG_DRAM_EMR1=4 Newconfigs/A20-OLinuXino_MICRO-lcd10_defconfig diff --git a/configs/A20-OLinuXino_MICRO-lcd10_defconfig b/configs/A20-OLinuXino_MICRO-lcd10_defconfig new file mode 100644 index 000..f382d71 --- /dev/null +++ b/configs/A20-OLinuXino_MICRO-lcd10_defconfig @@ -0,0 +1,15 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_O
Re: [linux-sunxi] Backporting simplefb support to 3.16 kernel
Ian Campbell writes: > https://wiki.debian.org/InstallingDebianOn/Allwinner says the platform > is already there, so this should enable the FB given a suitably new > u-boot. reading http://linux-sunxi.org/Linux_mainlining_effort " Merged into 3.19 □ USB phy driver support for usb0 " i think usb kernel support is missing in 3.16 or do i misunderstand/is there a backport, too? >> That would be really great (somehow didn't expect that, but I didn't >> look at the diff from 3.16). Last time I looked u-boot in testing/jessie >> was to old, too. Did someone look at that, too? > > I haven't and likely won't be looking at that. > > I've not looked but I think that backporting the u-boot side of the > framebuffer changes would be too much given the freeze etc, but who > knows... after re-reading https://wiki.debian.org/InstallingDebianOn/Allwinner and looking at: http://d-i.debian.org/daily-images/armhf/daily/u-boot/ i think those are the ones from the debian/unstable package $ strings u-boot-sunxi-with-spl.bin |grep ^U-Boot U-Boot SPL 2014.10+dfsg1-3 (Feb 21 2015 - 21:49:10) https://packages.qa.debian.org/u/u-boot.html " testing save 2014.10+dfsg1-2 unstable save 2014.10+dfsg1-3 " and as there will be a seperate step to setup the boot anyway (https://wiki.debian.org/InstallingDebianOn/Allwinner#Pre-installation_preparations "Pre-installation preparations") it maybe really isn't that important to have simplefb in debian/jessie u-boot. On the other hand maybe flash-kernel is supposed to also handle u-boot updates (didn't even know this exists)? -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] Backporting simplefb support to 3.16 kernel
"B.R. Oake" writes: > Hi Ian, Hans, > > On 28/02/15 16:18, Ian Campbell wrote: >> On Sat, 2015-02-21 at 11:49 +0100, Hans de Goede wrote: >> > On 21-02-15 11:26, Ian Campbell wrote: >> > > Speaking of which, if someone were to identify a suitable set of >> > > simple-fb backports for 3.16 and they are reasonably self contained I'd >> > > happily backport them to the kenrel which is going to be in the next >> > > Debian release too... [...] > Hans, do you agree? > Ian, do you need me to raise a Debian bug about this last missing patch? Does that mean there is a realistic chance to have Olimex A20-Olinuxino Micro+simplefb support in jessie (maybe not A20-OLinuXino-LIME2)? That would be really great (somehow didn't expect that, but I didn't look at the diff from 3.16). Last time I looked u-boot in testing/jessie was to old, too. Did someone look at that, too? I would especially be happy if I could drop: https://www.karme.de/prisirah/#sec-4 " 4.1 Linux kernel At the moment Debian's Linux kernel can't be used directly. But thanks to the sunxi community^17 it became possible to use the linux mainline kernel version 3.19 for our purpose.^18 For now the corresponding Debian binary packages are provided in the Prisirah repository^19 and the kernel source is in the Git repository at https://www.karme.de/git/linux^3. 4.2 U-Boot To boot the Linux kernel the boot loader "Das U-Boot" is used. U-Boot's state is similar to the kernel's. Debian's U-Boot package can't be used, yet. Also thanks to the sunxi community it became possible to use a U-Boot version very close to upstream^20. At the moment for each possible hardware setup a different U-Boot binary is provided in the u-boot-sunxi Debian binary package in the Prisirah repository^19. The source is in the u-boot Debian source package and in the Git repository at https://www.karme.de/git/u-boot^3. " Greetings, jens -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Julian Calaby writes: > Hi Jens, Hi, > On Fri, Feb 27, 2015 at 1:41 AM, Jens Thiele wrote: >> Do you think it is reasonable to expect the display/touchscreen of two >> Allwinner based tablets sold by the same name (including model number) >> are identical, or do they use different displays / touchscreen elements >> all the time? > > I think the answer is "It depends" > > I have two Allwinner SoC based tablets, one is a "generic" board that > has been put into at least three different tablets I'm aware of. The > FEX file and Android instance for it have configuration and drivers > for at least three different models of touch screen. are those resistive touchscreens => sun4i-ts driver? are the fex files available on git://github.com/linux-sunxi/sunxi-boards.git ? (see also below) > The other is manufactured by HP and I believe that while the > particular board is put into at least 2 different models, they're all > slight variations on the same thing (different / cheaper LCD) and > consequently should all have the same touch screen chip. The differences I see are with the resistive touchscreen panels / cover themself / even the surface feels different ... hard to explain those parts: https://www.olimex.com/Products/OLinuXino/LCD/A13-TS7/ https://www.olimex.com/Products/OLinuXino/LCD/A13-TS10/ > I think the general consensus is that one can assume that all tablets > with the same name and details will have the same touch screen. In > your case, with development boards, that's less viable and we possibly > should be using device tree overlays (or whatever they're called) to > separate peripheral configuration (the LCD + touch screen board) from > system configuration (the development board itself) but I'm hazy on > the details. > > IMHO, you should write the patch to get the value from device tree and > worry about the board configuration details when submitting that. Just wanted to start with this, but then had look at the fex files from git://github.com/linux-sunxi/sunxi-boards.git having "rtp_used = 1". They nearly all have the same rtp_para block: [rtp_para] rtp_used = 1 rtp_screen_size = 5 rtp_regidity_level = 5 rtp_press_threshold_enable = 0 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 The exceptions are: ./a10/iteaduino_plus_a10.fex [rtp_para] rtp_used = 1 rtp_screen_size = 7 rtp_regidity_level = 5 rtp_press_threshold_enable = 1 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 ./a13/ampe_a76.fex [rtp_para] rtp_used = 1 rtp_screen_size = 7 rtp_regidity_level = 5 rtp_press_threshold_enable = 0 rtp_press_threshold = 0x1f40 rtp_sensitive_level = 0xf rtp_exchange_x_y_flag = 0 But both use rtp_sensitive_level = 0xf, too. Now I am not sure, it is really worth it. Greetings, jens -- Prisirah - Building digital photo frames for family and friends using open-source hardware. http://karme.de/prisirah/ -- 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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Hi Tsvetan, maybe you can shed some light on this. Hans de Goede writes: > Hi, > > On 26-02-15 11:41, Jens Thiele wrote: >> the problem i see: >> at least the touch screens i have got all differ in quality/sensitivity >> => imho a static assignment via devicetree won't really cut it (but yes >> it would make adjustment easier). > > Well devicetree files are per board / tablet, so when creating the dts > files the brand / model of touchscreen is known, and I would expect > the sensitivity to be constant for the same brand/model touchscreen. My experience with the Olimex LCD displays is different (so far). I have got: 2* A13-LCD7-TS differing in quality (the older one having the "better" touch screen) A A13-LCD10TS and a LCD-OLinuXino-10TS. Okay those are different models, but I somehow hoped the LCD-OLinuXino-10TS would be a A13-LCD10TS + the additional ports for the lime/lime2. The A13-LCD10TS (I have) is the one that definitely needs the sensitivity adjustment. The A13-LCD10TS is matte and the LCD-OLinuXino-10TS is unfortunately glossy. @Tsvetan: does Olimex have multiple display/touch screen suppliers? did you see the quality difference with the A13-LCD7-TS, too? Can you give any "guarantees" (please don't take that in any way as a legal thing) about the quality of future displays? will they stay the same model? The LCD-OLinuXino-10TS I just got, has a "ARISING" label on the back. And finally to get really back on topic: Do you think it is reasonable to expect the display/touchscreen of two Allwinner based tablets sold by the same name (including model number) are identical, or do they use different displays / touchscreen elements all the time? greetings, jens -- 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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Hans de Goede writes: > Hi, Hi, Sorry, I should really have written at least some text and not only "fyi" in the subject line. It really was only meant as "for your interest" and the patch isn't intended to be applied upstream / it is just what i use for myself and to maybe help others that might prefer such a settting with the touch screen they have at hand. Especially, I don't think it is the better setting in general. [...] > Now as for the patch itself: > >> diff --git a/drivers/input/touchscreen/sun4i-ts.c >> b/drivers/input/touchscreen/sun4i-ts.c >> index 28a0674..e692f8e 100644 >> --- a/drivers/input/touchscreen/sun4i-ts.c >> +++ b/drivers/input/touchscreen/sun4i-ts.c >> @@ -267,7 +267,7 @@ static int sun4i_ts_probe(struct platform_device *pdev) >> * sensitive_adjust = 15 : max, which is not all that sensitive, >> * tp_mode = 0 : only x and y coordinates, as we don't use dual touch >> */ >> -writel(TP_SENSITIVE_ADJUST(15) | TP_MODE_SELECT(0), >> +writel(TP_SENSITIVE_ADJUST(0) | TP_MODE_SELECT(0), >> ts->base + TP_CTRL2); >> >> /* Enable median filter, type 1 : 5/3 */ >> > > > Hmm, what about using 7 by default as middle ground ? i don't think this will really help anyone > And can you please make this configurable > through devicetree, and when you do so also update > Documentation/devicetree/bindings/input/touchscreen/sun4i.txt > > Thanks & Regards, the problem i see: at least the touch screens i have got all differ in quality/sensitivity => imho a static assignment via devicetree won't really cut it (but yes it would make adjustment easier). I thought about a module argument or even better adjustment at runtime, but I don't even know wether there is something like a standard user space API for that (afair the synaptics touchpad always had a special handling for that?) greetings, jens -- 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] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
commit a5586a2f4aee9b5a5c571b47bbd87790a1ea0f83 (HEAD, refs/remotes/karme/master, refs/heads/prisirah) Author: Jens Thiele Date: Thu Feb 26 10:51:49 2015 +0100 TP_SENSITIVE_ADJUST(0) works better for me (using touch pen) using TP_SENSITIVE_ADJUST(15) i get a lot of noise painting with low pressure. I prefer not to get any events in that case. Modified drivers/input/touchscreen/sun4i-ts.c diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c index 28a0674..e692f8e 100644 --- a/drivers/input/touchscreen/sun4i-ts.c +++ b/drivers/input/touchscreen/sun4i-ts.c @@ -267,7 +267,7 @@ static int sun4i_ts_probe(struct platform_device *pdev) * sensitive_adjust = 15 : max, which is not all that sensitive, * tp_mode = 0 : only x and y coordinates, as we don't use dual touch */ - writel(TP_SENSITIVE_ADJUST(15) | TP_MODE_SELECT(0), + writel(TP_SENSITIVE_ADJUST(0) | TP_MODE_SELECT(0), ts->base + TP_CTRL2); /* Enable median filter, type 1 : 5/3 */ -- 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] linux 3.19, sunxi-mmc: a20-olinuxino-micro second sd card slot: mmc1: card never left busy state
Jens Thiele writes: > seems to depend on SD card / microSD<->SD adapter?! Don't see a clear > pattern, yet. > hardware problem? anybody else seeing this? really looks like a problem with one SD adapter (could reproduce with my laptop). sorry for the noise -- 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] linux 3.19, sunxi-mmc: a20-olinuxino-micro second sd card slot: mmc1: card never left busy state
I _sometimes_ get: [ 2519.090006] mmc1: card never left busy state [ 2519.094302] mmc1: error -110 whilst initialising SD card [ 2519.100518] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 1, RTO !! seems to depend on SD card / microSD<->SD adapter?! Don't see a clear pattern, yet. hardware problem? anybody else seeing this? -- 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] simplefb and gpio_backlight?
Hans de Goede writes:
> Hi,
>
> On 19-02-15 22:09, Jens Thiele wrote:
>> would dpms-like functionality work using simplefb with gpio_backlight
>> (CONFIG_BACKLIGHT_GPIO) if one provides correct information in the .dts
>> file?
>
> I believe that that would depend on your desktop environments, the
> sysfs backlight interface is typically used by the desktop environment
> and not by X itself, so if the desktop environment not only makes X server
> calls to do dpms but also sets the backlight off then yes it should work.
ah, yes thanks!
would have to take a closer look (again) - but yes, afair x fbdev used
something like:
int fd=open("/dev/fb0",O_RDWR)
ioctl(fd, FBIOBLANK, ...)
as i just use x+wm (no desktop environment) i wouldn't gain that much
(but yes, it would be nicer anyway)
> It would be better to use the pwm backlight devicetree binding though,
> that way we can actually control brightness, and the upstream kernel
> recently has gotten support for the pwm pins on the Axx SOCs.
>
> I would certainly welcome patches adding pwm backlight devicetree nodes
> to supported devices, since we will need those in the future anyways.
Brightness control would be nice. But I will have to learn how this is
supposed to work, first.
> Note that a pwm backlight devicetree node will give you both a brightness
> and a bl_enable attribute, since not all desktop environments will do the
> right thing, we could als patch the fbdev and/or turbfo fb drivers to
> look for a backlight device in sysfs and toggle its bl_enable setting
> when dpms is turned on/off, I believe that that would be the best way
> to fix this until we get a kms driver.
ok, will head into the pwm backlight direction.
thank you very much, again!
greetings, jens
--
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] simplefb and gpio_backlight?
would dpms-like functionality work using simplefb with gpio_backlight (CONFIG_BACKLIGHT_GPIO) if one provides correct information in the .dts file? maybe someone already has a backlight block for the a20 olinuxino micro/lime2 (sun7i-a20-olinuxino-micro.dts, sun7i-a20-olinuxino-lime2.dts) ? PS: at the moment i use a userspace hack hooked up to X's ScreenSaverNotify event based on u-boot sunxi_display.c and http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel http://linux-sunxi.org/LCD ;; todo: to support other boards we would have to adjust this (define-constant CONFIG_VIDEO_LCD_POWER 232) (define-constant CONFIG_VIDEO_LCD_BL_PWM 34) (define (lcd-on) (gpio-out CONFIG_VIDEO_LCD_BL_PWM #t) (sys-nanosleep 40e6) (gpio-out CONFIG_VIDEO_LCD_POWER #t) (sys-nanosleep 40e6) (gpio-out CONFIG_VIDEO_LCD_BL_PWM #f)) (define (lcd-off) (gpio-out CONFIG_VIDEO_LCD_BL_PWM #t) (sys-nanosleep 40e6) (gpio-out CONFIG_VIDEO_LCD_POWER #t)) -- 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] [OT][ANN] Prisirah, building digital photo frames for family and friends
Prisirah
Building digital photo frames for family and friends using open-source
hardware and free software.
As I recently became a father I was more or less forced by many to
share photos of our lovely son. At the same time it became evident
that our internet traffic is monitored and captured and even worse
that you can't trust your hardware. First of all this is a political
and social problem, but it likely will need some time to get that
fixed. That was the reason to build digital picture frames for family
and friends using open-source hardware and free software that allow to
share photos via internet while at least trying to protect our
privacy.
For details please see
http://www.karme.de/prisirah/
greetings,
Jens
PS:
relevance for linux-sunxi: using mainline kernel 3.19 +
A20-OLinuXino-{MICRO,LIME2}+LCD‑OLinuXino‑{7,10}TS
relevance for freedombox-discuss:
"In the long run this project maybe should be based upon Debian's
FreedomBox project and/or the parts should be integrated into Debian."
--
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] PH07 is not connected to LCD_CON on the A20-OlinuXino-MICRO.
--- sys_config/a20/a20-olinuxino_micro-lcd10.fex |4 ++-- sys_config/a20/a20-olinuxino_micro-lcd7.fex |4 ++-- sys_config/a20/a20-olinuxino_micro.fex |4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sys_config/a20/a20-olinuxino_micro-lcd10.fex b/sys_config/a20/a20-olinuxino_micro-lcd10.fex index 8ed8f03..9a02bed 100644 --- a/sys_config/a20/a20-olinuxino_micro-lcd10.fex +++ b/sys_config/a20/a20-olinuxino_micro-lcd10.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 diff --git a/sys_config/a20/a20-olinuxino_micro-lcd7.fex b/sys_config/a20/a20-olinuxino_micro-lcd7.fex index 817ba73..b690d77 100644 --- a/sys_config/a20/a20-olinuxino_micro-lcd7.fex +++ b/sys_config/a20/a20-olinuxino_micro-lcd7.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 diff --git a/sys_config/a20/a20-olinuxino_micro.fex b/sys_config/a20/a20-olinuxino_micro.fex index 9b48fa7..27e4938 100644 --- a/sys_config/a20/a20-olinuxino_micro.fex +++ b/sys_config/a20/a20-olinuxino_micro.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 -- 1.7.10.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] sunxi-boards: a20-olinuxino_micro*.fex: PH7 not connected to LCD_CON (Was: Re: hack to switch off olimex a13-lcd10ts with mainline kernel)
Jens Thiele writes: > Jens Thiele writes: > >> PH7 => 231 >> echo 231 > /sys/class/gpio/export >> echo out > /sys/class/gpio/gpio231/direction >> echo 1 > /sys/class/gpio/gpio231/value >> nothing happens >> echo 0 > /sys/class/gpio/gpio231/value >> nothing happens > > looking at the docs (A20 Datasheet V1.41 20131230.pdf) and the a20 > olinuxino micro brd file (A20-OLINUXINO-MICRO_4GB_REV_E2.brd via kicad > pcbnew) with still very limited understanding i wonder wether the PH7 > has anything to do with the lcd at all? PH7 (ball is B4) is only > connected to gpio-3 != lcd connector? > > am i missing something or should the a20-olinuxino_micro*.fex files (and > http://linux-sunxi.org/LCD) be fixed? looking at the nice picture at [1] i am quite confident my findings are correct and PH7 (aka PH07) really isn't connected to the LCD_CON. => propose this patch: $ git --no-pager diff diff --git a/sys_config/a20/a20-olinuxino_micro-lcd10.fex b/sys_config/a20/a20-olinuxino_micro-lcd10.fex index 8ed8f03..9a02bed 100644 --- a/sys_config/a20/a20-olinuxino_micro-lcd10.fex +++ b/sys_config/a20/a20-olinuxino_micro-lcd10.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 diff --git a/sys_config/a20/a20-olinuxino_micro-lcd7.fex b/sys_config/a20/a20-olinuxino_micro-lcd7.fex index 817ba73..b690d77 100644 --- a/sys_config/a20/a20-olinuxino_micro-lcd7.fex +++ b/sys_config/a20/a20-olinuxino_micro-lcd7.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 diff --git a/sys_config/a20/a20-olinuxino_micro.fex b/sys_config/a20/a20-olinuxino_micro.fex index 9b48fa7..27e4938 100644 --- a/sys_config/a20/a20-olinuxino_micro.fex +++ b/sys_config/a20/a20-olinuxino_micro.fex @@ -346,8 +346,8 @@ lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 lcd_gamma_tbl_255 = 0xff -lcd_bl_en_used = 1 -lcd_bl_en = port:PH07<1><0><1> +lcd_bl_en_used = 0 +lcd_bl_en = lcd_power_used = 1 lcd_power = port:PH08<1><0><1> lcd_pwm_used = 1 git finished. [1] https://www.olimex.com/wiki/images/a/a9/Example.jpg -- 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: hack to switch off olimex a13-lcd10ts with mainline kernel
Jens Thiele writes: > PH7 => 231 > echo 231 > /sys/class/gpio/export > echo out > /sys/class/gpio/gpio231/direction > echo 1 > /sys/class/gpio/gpio231/value > nothing happens > echo 0 > /sys/class/gpio/gpio231/value > nothing happens looking at the docs (A20 Datasheet V1.41 20131230.pdf) and the a20 olinuxino micro brd file (A20-OLINUXINO-MICRO_4GB_REV_E2.brd via kicad pcbnew) with still very limited understanding i wonder wether the PH7 has anything to do with the lcd at all? PH7 (ball is B4) is only connected to gpio-3 != lcd connector? am i missing something or should the a20-olinuxino_micro*.fex files (and http://linux-sunxi.org/LCD) be fixed? -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: u-boot olimex a13-lcd10ts (now aka LCD-OLinuXino-10TS?)
Hans de Goede writes: > Hi, > > On 18-01-15 13:42, Jens Thiele wrote: >> will you re-add A20-OLinuXino_MICRO-lcd10_defconfig to your sunxi-wip >> branch or did you change your mind? > > We've decided to not carry defconfig-s for board + addon combos upstream as > that simply leads to a too large explosion of defconfig-s, instead for > LCD-s we've created this page where the necessary info can be found: > http://linux-sunxi.org/LCD i see, thanks! >> would it be somehow possible to detect connected lcds? > > No. > >> or at least a connected touchscreen? > > A resistive touchscreen can only be differentiated from not-connected > pins when it is actually pressed, so no. :( >> i think most will either connect the lcd with touchscreen or no lcd all? > > Olimex has sold both versions with and without the touchscreen for > various lcd displays. thanks, again jens -- 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.
u-boot olimex a13-lcd10ts (now aka LCD-OLinuXino-10TS?) (Was: Re: [linux-sunxi] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot)
Hans de Goede writes: > I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, > can you > give this a try with my personal git tree, sunxi-wip branch: > > https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip > [...] > CONFIG_SPL=y > CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI" > CONFIG_FDTFILE="sun7i-a20-olinuxino-micro.dtb" > CONFIG_MMC_SUNXI_SLOT_EXTRA=3 > CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:45000,le:150,ri:16,up:21,lo:2,hs:10,vs:2,sync:3,vmode:0" > CONFIG_VIDEO_LCD_POWER="PH8" > CONFIG_VIDEO_LCD_BL_EN="PH7" > CONFIG_VIDEO_LCD_BL_PWM="PB2" > +S:CONFIG_MMC0_CD_PIN="PH1" > +S:CONFIG_MMC3_CD_PIN="PH11" > +S:CONFIG_ARM=y > +S:CONFIG_ARCH_SUNXI=y > +S:CONFIG_MACH_SUN7I=y > +S:CONFIG_TARGET_A20_OLINUXINO_M=y will you re-add A20-OLinuXino_MICRO-lcd10_defconfig to your sunxi-wip branch or did you change your mind? would it be somehow possible to detect connected lcds? or at least a connected touchscreen? i think most will either connect the lcd with touchscreen or no lcd all? this would allow a single u-boot for the board: lcd connected => use lcd hdmi connected => use hdmi otherwise vga? jens -- 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] A20, AXP, linux mainline, no power off on halt
Hans de Goede writes: > Well there is your problem... > > If it still does not work with that enabled let us know. works, thanks -- 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] A20, AXP, linux mainline, no power off on halt
Hans de Goede writes: > Which board are you using, is the axp209 driver build > and loaded ? a20 olinuxino micro /boot$ grep -i axp config-3.19.0-rc3 # CONFIG_MFD_AXP20X is not set looks like it is set in sunxi_defconfig but not in multi_v7_defconfig. -- 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] A20, AXP, linux mainline, no power off on halt
Lars Doelle writes: > Hi everyone, > > the subject say it. The very last message I get, is > > | reboot: System halted. > > but then, the device does not power off, i.e. the > screen remains active displaying the text and I > have to power it off manually. +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.
hack to switch off olimex a13-lcd10ts with mainline kernel (Was: Re: [linux-sunxi] sunxi-3.4.103 and CONFIG_CMA=y => no mmc)
Jens Thiele writes: > as far as i understand maybe i could use a hack to switch the lcd off > (fake dpms) via the sysfs gpio interface for now? [...] > I think the pins for A20 OLinuXino MICRO + A13-LCD10TS would be: > CONFIG_VIDEO_LCD_POWER="PH8" > CONFIG_VIDEO_LCD_BL_EN="PH7" > CONFIG_VIDEO_LCD_BL_PWM="PB2" > > will read [1] and try with mainline kernel. Does that make sense? Any > side-effects? it somehow works PH8 => 232 echo 232 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio232/direction echo 0 > /sys/class/gpio/gpio232/value => display is off switch on again: echo 1 > /sys/class/gpio/gpio232/value (white flicker as mentioned in the u-boot code) PH7 => 231 echo 231 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio231/direction echo 1 > /sys/class/gpio/gpio231/value nothing happens echo 0 > /sys/class/gpio/gpio231/value nothing happens PB2 => 34 echo 34 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio34/direction echo 1 > /sys/class/gpio/gpio34/value => backlight? is off (can't see a difference to display off) echo 0 > /sys/class/gpio/gpio34/value => display is on (no flicker) lol: cd /sys/class/gpio/gpio34 while true; do echo 0 > value; sleep 0.0001; echo 1 > value; sleep 0.0001; done (depending on your work-load is a unsteady dim or looks like a broken display) -- 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] sunxi-3.4.103 and CONFIG_CMA=y => no mmc
Siarhei Siamashka writes:
> On Fri, 16 Jan 2015 23:30:11 +0100
> Jens Thiele wrote:
>
>> with kernel sunxi-3.4.103 (sunxi-3.4 branch) and CONFIG_CMA=y (as in
>> sun7i_defconfig) i have no mmc device.
>>
>> hardware:
>> a20 olinuxino micro
>>
>> [3.494360] [mmc-msg] sw_mci_init
>> [3.503435] [mmc-msg] MMC host used card: 0x9, boot card: 0x0, io_card 8
>> [3.513585] [mmc-err] alloc dma des failed
>> [3.522066] [mmc-err] sunxi-mmc.0: Failed to get resouce.
>> [3.530705] [mmc-err] alloc dma des failed
>> [3.539168] [mmc-err] sunxi-mmc.3: Failed to get resouce.
>>
>> should sun7i_defconfig be adjusted (is CONFIG_CMA=y)?
>> other hints?
>
> You can check whether you have initrd enabled, it might be clashing
> with the CMA area reservation. If CMA is enabled but fails to
> initialize, then mmc fails too.
bull's eye
using initrd indeed
thanks!
> If this is the case, then just move initrd to a different location in
> RAM.
will have a look (or maybe not - see below).
>> all using mainline now?
>
> As for "using", this depends on whether you want full cedar and mali
> acceleration right now.
mali and cedar are not important for my usage.
things i am still missing in mainline:
- dpms support
- audio
via:
http://linux-sunxi.org/Linux_mainlining_effort
https://groups.google.com/forum/#!topic/linux-sunxi/svXhZ_GFxsA
Message-ID: <20140702173537.9698.50825.stgit@studio>
"
This is first pass at a mainline driver for the A20 on-chip
codec. This patch will boot and install the ALSA SOC driver. But it
won't play any music. Something is wrong in either the DMA or clock
code. Anyone want to give this a try and see if you can figure out
what is wrong? The patch sits on top of Emilio's DMA driver for the
A20.
"
> But as for "developing", the 3.4 kernel is de-facto in the "critical
> bugfixes only" mode since at least half a year ago. New features are
> not likely to appear in 3.4, and the known non-critical limitations
> are not likely to be lifted.
>
> This does not mean that it is forbidden to contribute to 3.4 though.
> Anyone is welcome to submit 3.4 patches, as long as (s)he finds at
> least one reviewer for them. Please note that even if the patches
> are posted to the mailing list, not everyone is eager to waste time
> reviewing 3.4 patches today.
thanks for clearing that up for me.
=> i will try to stop wasting my time with 3.4
as far as i understand maybe i could use a hack to switch the lcd off
(fake dpms) via the sysfs gpio interface for now? looking at the sunxi
3.4 code and the newer u-boot code i think i would have to change 2+1
gpios?
in u-boot:
"
static void sunxi_lcdc_panel_enable(void)
{
int pin;
/*
* Start with backlight disabled to avoid the screen flashing to
* white while the lcd inits.
*/
pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_BL_EN);
if (pin != -1) {
gpio_request(pin, "lcd_backlight_enable");
gpio_direction_output(pin, 0);
}
pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_BL_PWM);
if (pin != -1) {
gpio_request(pin, "lcd_backlight_pwm");
/* backlight pwm is inverted, set to 1 to disable backlight */
gpio_direction_output(pin, 1);
}
/* Give the backlight some time to turn off and power up the panel. */
mdelay(40);
pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_POWER);
if (pin != -1) {
gpio_request(pin, "lcd_power");
gpio_direction_output(pin, 1);
}
}
"
I think the pins for A20 OLinuXino MICRO + A13-LCD10TS would be:
CONFIG_VIDEO_LCD_POWER="PH8"
CONFIG_VIDEO_LCD_BL_EN="PH7"
CONFIG_VIDEO_LCD_BL_PWM="PB2"
will read [1] and try with mainline kernel. Does that make sense? Any
side-effects?
jens
PS: Sorry, for the noise.
[1]
http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_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.
[linux-sunxi] sunxi-3.4.103 and CONFIG_CMA=y => no mmc
with kernel sunxi-3.4.103 (sunxi-3.4 branch) and CONFIG_CMA=y (as in sun7i_defconfig) i have no mmc device. hardware: a20 olinuxino micro [3.494360] [mmc-msg] sw_mci_init [3.503435] [mmc-msg] MMC host used card: 0x9, boot card: 0x0, io_card 8 [3.513585] [mmc-err] alloc dma des failed [3.522066] [mmc-err] sunxi-mmc.0: Failed to get resouce. [3.530705] [mmc-err] alloc dma des failed [3.539168] [mmc-err] sunxi-mmc.3: Failed to get resouce. should sun7i_defconfig be adjusted (is CONFIG_CMA=y)? other hints? all using mainline now? greetings, jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Hans de Goede writes: > The problem was that a commit in my sunxi-wip branch was doing 64 bit > integer math, which causes problems when the toolchain does not have > soft-float support libs even though it is not float related ... scary (browsing through the git log it looks like other arches also had that problem). > This has been fixed by rewriting the code to do things in a way which > fits into 32 bits integers. I see, thanks. (I likely didn't find the change because you did a git rebase right?) Greetings, jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Michal Suchanek writes: > Is this being fixed? > > Depending on particular toolchain default ABI just because somebody > decided to frob compiler options is kind of stupid. for the archives: looks like this is fixed in current¹ master (didn't find when/how this was fixed)? jens ¹ f411b8f2270bc75113d60f2ad662f25de6242b7d -- 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: A20-OLinuXino-MICRO + A13-LCD10TS and mainline kernel
Hans de Goede writes:
> Ah, sorry I did not look at $subject, and thought we we were talking
> about a capacative touchscreen as found on most tablets.
>
> So yes support for a resistive touchscreen with the build-in resistive
> touchscreen controller is upstream, and ti should work fine.
>
> I'm pretty sure about that as I wrote the code :)
>
> But to use this you must explicitly enable it in devicetree, iow you
> need this change:
>
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> @@ -155,6 +155,10 @@
> };
> };
>
> + rtp: rtp@01c25000 {
> + allwinner,ts-attached;
> + };
> +
> uart0: serial@01c28000 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pins_a>;
>
> And then rebuild the dtb, and put it where your boot setup
> searches for the dtb.
done
> Then you can run e.g. evemu-record from a text-console and it
> should show a touchscreen and report events when you press it.
>
> Then follow this howto:
> http://www.dimrobotics.com/2013/06/olinuxino-a13-touchscreen-support-in.html
> To get it to work with Xorg
skipped that and just tested with my old (sunxi-3.4) config and it
worked out of the box - yeah :-)
(only had to re-run xinput_calibrator)
thanks very much!
greetings
jens (t)
PS: maybe the sensitivity parameters (TP_SENSITIVE_ADJUST) could use
some tweaking - afair i had "better" results using less sensitivity
(afair high sensitivity caused many jumps heading to 0,0 if touching
only slightly)
--
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.
A20-OLinuXino-MICRO + A13-LCD10TS and mainline kernel (Was: Re: [linux-sunxi] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot)
Hans de Goede writes: > On 10-01-15 21:38, Jens Thiele wrote: >> what's missing: >> - touchscreen doesn't work (not sure why) > > Likely because the upstream kernel does not yet have a driver for it. thought it is sun4i-ts and that it is already in mainline, but will have to take a look... greetings, jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Hans de Goede writes: [...] > Note that when used with a 3.19 kernel + this patch: > https://github.com/jwrdegoede/linux-sunxi/commit/d1b7faa5c69ef1ad52b739aa88cd803e08955360 > This will also give you video out support while using an upstream kernel. just tested - and it works :-) what's missing: - touchscreen doesn't work (not sure why) - dpms / switch lcd off (seems like this is expected with simplefb) greetings, jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Chen-Yu Tsai writes: > On Mon, Dec 29, 2014 at 12:11 AM, Hans de Goede wrote: >> >> Weird, you did build upstream u-boot from source for your previous tests. >> right? >> >> and then it did work, right ? yes > It seems some recent changes in upstream broke building with hard float > toolchains. Best use soft float. > > It's probably these commits: > > bf1af3d ARM: merge commonly-defined PLATFORM_RELFLAGS > 3102274 ARM: refactor compiler options in config.mk only had little time => just rebuilt using debian/jessie/armel toolchain and the result is: A20-OLinuXino-MICRO + A13-LCD10TS + USB keyboard works with u-boot \o/ thanks! kernel test will follow as time permits jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Hans de Goede writes: [...] > Correct, the default environment of upstream u-boot does not read uEnv.txt, > but usually old setups come with a boot.scr which does read uEnv.txt and it > should honor your boot.scr, this works for e.g. the Fedora allwinner remix > images. i see, thanks. (didn't have a boot.scr myself) > I see that you've a 10" olimex lcd module to go with your A20-OLinuXino-MICRO, > > I've written lcd support for u-boot (currently under review before going > upstream), > and I've tested it with the 7" olimex lcd module, it would be nice to also > include > an example defconfig for the 10" lcd module for users. > > I've created and attached a defconfig for 20-OLinuXino-MICRO + A13-LCD10TS, > can you > give this a try with my personal git tree, sunxi-wip branch: > > https://github.com/jwrdegoede/u-boot-sunxi/tree/sunxi-wip get an error at the moment (native compile on debian/jessie/armhf): LD u-boot ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o) ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o) ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o) Makefile:1065: recipe for target 'u-boot' failed make: *** [u-boot] Error 1 greetings, jens -- 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] linux-sunxi/u-boot-sunxi is no longer supported, time to switch to upstream u-boot
Hans de Goede writes: > 2) How to build upstream u-boot for use with linux-sunxi sunxi-3.4 kernels [...] just wanted to report: success and thank you! will switch to upstream u-boot works for me using: A20-OLinuXino-MICRO + A13-LCD10TS (A20-OLinuXino_MICRO_defconfig) and slightly modified (older) sunxi-3.4 kernel (vmlinuz-3.4.75+) had some trouble getting my own modifications to work at first (maybe uEnv.txt isn't used at all?) but after all succeeded on the u-boot command line using: setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 load mmc 0 0x4300 script.bin load mmc 0 0x4800 vmlinuz-3.4.75+ bootz 0x4800 greetings, jens -- 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] sunxi-3.4 display driver dpms bug?
Michal Suchanek writes: > Linux A10 3.4.79+ #3 PREEMPT Mon Feb 17 21:33:07 CET 2014 armv7l GNU/Linux not that old >> consoleblank=0 in /proc/cmdline ? > > Why would I do that !? you shouldn't it was just a wild guess on my side why switching off the display might not work for you at all sorry for the confusion -- 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] sunxi-3.4 display driver dpms bug?
Michal Suchanek writes: > I have exactly opposite problem. When I connect a display to A10 it > never turns off. It only shows either console or fully backlit blank > screen. different problem then > I may have quite dated kernel, though. sunxi-3.4 branch? consoleblank=0 in /proc/cmdline ? greetings karme -- 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] sunxi-3.4 display driver dpms bug?
Neal Peacock writes:
> Isn't that expected?
no
> The last command turned it off, did you try turning it back on?
echo 0 turns it on
and to be clear:
"echo 4 > $P"
is not enough to produce the problem
you have to call it twice
"echo 4 > $P; echo 4 > $P"
you can also try something like:
/*BINFMTC:
*/
#include
#include
#include
#include
#include
#include
int main(int argc, char** argv) {
int fd=open("/dev/fb0",O_RDWR);
assert(fd!=-1);
printf("%d\n",ioctl(fd, FBIOBLANK, FB_BLANK_POWERDOWN));
printf("%d\n",ioctl(fd, FBIOBLANK, FB_BLANK_POWERDOWN));
printf("%d\n",ioctl(fd, FBIOBLANK, FB_BLANK_UNBLANK));
return 0;
}
greetings,
karme
--
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] sunxi-3.4 display driver dpms bug?
if I do: P="/sys/devices/platform/disp/graphics/fb0/blank" echo 4 > $P; echo 4 > $P sleep 1 echo 0 > $P the display is switched off and i can't switch the display on anymore can someone confirm? -- 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] which fex to use for sunxi-3.4 + A20-OLinuXino-MICRO + LCD10?
Hi, comparing the fex file created by olimex change_display_a20_OlinuXino.sh script from the official olimex debian image from here: https://drive.google.com/file/d/0B-bAEPML8fwlX2tYS2FmNXV5OUU/edit?usp=sharing via https://www.olimex.com/wiki/A20-OLinuXino-MICRO and comparing it to the one from git://github.com/linux-sunxi/sunxi-boards.git sys_config/a20a20-olinuxino_micro-lcd10.fex i wonder which one to use? using the one from the official olimex debian image my lcd is flickering / the picture is very unstable greetings, jens PS: attached a diff -- 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. --- a20-olinuxino_micro-lcd10.fex 2014-07-11 23:18:22.911913979 +0200 +++ a20-olinuxino_micro-lcd10.fex.official 2014-07-13 11:43:16.145767205 +0200 @@ -1,6 +1,6 @@ [product] version = "100" -machine = "A20-OLinuXino-MICRO" +machine = "OlinuXino-A20" [platform] eraseflag = 0 @@ -16,7 +16,6 @@ storage_type = 1 [clock] -pll3 = 297 pll4 = 300 pll6 = 600 pll7 = 297 @@ -60,18 +59,18 @@ [uart_force_debug] uart_debug_port = 0 -uart_debug_tx = port:PF02<4><1> -uart_debug_rx = port:PF04<4><1> +uart_debug_tx = port:PB22<2><1> +uart_debug_rx = port:PB23<2><1> [jtag_para] -jtag_enable = 0 +jtag_enable = 1 jtag_ms = port:PB14<3> jtag_ck = port:PB15<3> jtag_do = port:PB16<3> jtag_di = port:PB17<3> [pm_para] -standby_mode = 1 +standby_mode = 0 [dram_para] dram_baseaddr = 0x4000 @@ -191,15 +190,15 @@ uart_used = 1 uart_port = 6 uart_type = 2 -uart_tx = port:PI12<4><1> -uart_rx = port:PI13<4><1> +uart_tx = port:PI12<3><1> +uart_rx = port:PI13<3><1> [uart_para7] uart_used = 1 uart_port = 7 uart_type = 2 -uart_tx = port:PI20<4><1> -uart_rx = port:PI21<4><1> +uart_tx = port:PI20<3><1> +uart_rx = port:PI21<3><1> [spi0_para] spi_used = 0 @@ -245,17 +244,27 @@ rtp_exchange_x_y_flag = 0 [ctp_para] -ctp_used = 1 +ctp_used = 0 +ctp_name = "gsl1680" ctp_twi_id = 2 -ctp_twi_name = -ctp_screen_max_x = 800 -ctp_screen_max_y = 480 +ctp_twi_addr = 0x40 +ctp_screen_max_x = 1024 +ctp_screen_max_y = 600 ctp_revert_x_flag = 0 ctp_revert_y_flag = 0 -ctp_exchange_x_y_flag = 0 +ctp_exchange_x_y_flag = 1 ctp_int_port = port:PH21<6> ctp_wakeup = port:PB13<1><1> +[ctp_list_para] +ctp_det_used = 0 +ft5x_ts = 1 +gt82x = 1 +gslX680 = 1 +gt9xx_ts = 1 +gt811 = 1 +zet622x = 1 + [tkey_para] tkey_used = 0 tkey_twi_id = 2 @@ -295,17 +304,21 @@ screen0_output_type = 1 screen0_output_mode = 5 screen1_output_type = 1 -screen1_output_mode = 5 +screen1_output_mode = 4 fb0_framebuffer_num = 2 -fb0_format = 9 -fb0_pixel_sequence = 2 +fb0_format = 10 +fb0_pixel_sequence = 0 fb0_scaler_mode_enable = 0 +fb0_width = 0 +fb0_height = 0 fb1_framebuffer_num = 2 -fb1_format = 9 -fb1_pixel_sequence = 2 +fb1_format = 10 +fb1_pixel_sequence = 0 fb1_scaler_mode_enable = 0 -lcd0_backlight = 197 -lcd1_backlight = 197 +fb1_width = 0 +fb1_height = 0 +lcd0_backlight = 250 +lcd1_backlight = 100 lcd0_bright = 50 lcd0_contrast = 50 lcd0_saturation = 57 @@ -329,19 +342,19 @@ lcd_ht = 1200 lcd_vbp = 23 lcd_vt = 1250 +lcd_vspw = 2 +lcd_hspw = 10 lcd_hv_if = 0 lcd_hv_smode = 0 lcd_hv_s888_if = 0 lcd_hv_syuv_if = 0 -lcd_hv_vspw = 2 -lcd_hv_hspw = 10 lcd_lvds_ch = 0 lcd_lvds_mode = 0 lcd_lvds_bitwidth = 0 lcd_lvds_io_cross = 0 lcd_cpu_if = 0 lcd_frm = 1 -lcd_io_cfg0 = 268435456 +lcd_io_cfg0 = 0 lcd_gamma_correction_en = 0 lcd_gamma_tbl_0 = 0x0 lcd_gamma_tbl_1 = 0x10101 @@ -444,12 +457,6 @@ lcdd19 = port:PH19<2><0> lcdd20 = port:PH20<2><0> lcdd21 = port:PH21<2><0> -lcdd22 = port:PH22<2><0> -lcdd23 = port:PH23<2><0> -lcdclk = port:PH24<2><0> -lcdde = port:PH25<2><0> -lcdhsync = port:PH26<2><0> -lcdvsync = port:PH27<2><0> [tv_out_dac_para] dac_used = 1 @@ -460,21 +467,41 @@ [hdmi_para] hdmi_used = 1 +hdcp_enable = 0 + +[i2s2_para] +i2s_channel = 2 +i2s_master = 4 +i2s_select = 1 +audio_format = 1 +signal_inversion = 1 +over_sample_rate = 256 +sample_resolution = 16 +word_select_size = 32 +pcm_sync_period = 256 +msb_lsb_first = 0 +sign_extend = 0 +slot_index = 0 +slot_width = 16 +frame_width = 1 +tx_data_mode = 0 +rx_data_mode = 0 [camera_list_para] -camera_list_para_used = 0 +camera_list_para_used = 1 ov7670 = 0 -gc0308 = 1 -gt2005 = 0 +gc0308 = 0 +gt2005 = 1 hi704 = 0 sp0838 = 0 mt9m112 = 0 mt9m113 = 0 +gc2035 = 0 ov2655 = 0 hi253 = 0 gc0307 = 0 mt9d112 = 0 -ov5640 = 1 +ov5640 = 0 gc2015 = 0 ov2643 = 0 gc0329 = 0 @@ -488,20 +515,32 @@ csi_used = 0 csi_dev_qty = 1 csi_stby_mode = 0 -csi_mname = "gc0308" +csi_mname = "gc2005" +csi_twi_id = 1 +csi_twi_addr = 0x78 csi_if = 0 +csi_vflip = 0 +csi_hflip = 0 csi_iovdd = "" csi_avdd = "" csi_dvdd = "" -csi_vol_iovdd = +csi_vol_iovdd = 2800 csi_vol_dvdd = csi_vol_avdd = -csi_vflip = 0 -csi_hflip = 0 cs
Re: [linux-sunxi] Cubietruck lockup with current sunxi 3.4
Jens Thiele writes: > yes, using olimex olinuxino a20 micro > details will follow (if time permits) no complete lock-up this time: [10615.721305] [ cut here ] [10615.734257] WARNING: at lib/list_debug.c:58 __list_del_entry+0x88/0xd0() [10615.748967] list_del corruption. next->prev should be ee2817d0, but was ee222680 [10615.759565] Modules linked in: tcp_diag inet_diag bnep rfcomm nbd sun4i_keyboard sun4i_ts rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 btusb bluetooth [10615.793484] [] (unwind_backtrace+0x0/0x138) from [] (warn_slowpath_common+0x4c/0x64) [10615.812212] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [10615.831427] [] (warn_slowpath_fmt+0x30/0x40) from [] (__list_del_entry+0x88/0xd0) [10615.847837] [] (__list_del_entry+0x88/0xd0) from [] (list_del+0xc/0x24) [10615.863406] [] (list_del+0xc/0x24) from [] (unlink_anon_vmas+0x70/0x164) [10615.879813] [] (unlink_anon_vmas+0x70/0x164) from [] (free_pgtables+0x78/0xc8) [10615.895988] [] (free_pgtables+0x78/0xc8) from [] (exit_mmap+0x118/0x1d8) [10615.910933] [] (exit_mmap+0x118/0x1d8) from [] (mmput+0x4c/0xf4) [10615.925630] [] (mmput+0x4c/0xf4) from [] (flush_old_exec+0x318/0x5c8) [10615.942067] [] (flush_old_exec+0x318/0x5c8) from [] (load_elf_binary+0x2cc/0x124c) [10615.959977] [] (load_elf_binary+0x2cc/0x124c) from [] (search_binary_handler+0xcc/0x2ac) [10615.977814] [] (search_binary_handler+0xcc/0x2ac) from [] (do_execve+0x2c0/0x360) [10615.994241] [] (do_execve+0x2c0/0x360) from [] (sys_execve+0x34/0x54) [10616.010750] [] (sys_execve+0x34/0x54) from [] (ret_fast_syscall+0x0/0x30) [10616.024002] ---[ end trace 0637c111a7e74fe8 ]--- [10616.035777] Unable to handle kernel NULL pointer dereference at virtual address [10616.047324] pgd = ee26c000 [10616.053747] [] *pgd= [10616.061830] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [10616.068987] Modules linked in: tcp_diag inet_diag bnep rfcomm nbd sun4i_keyboard sun4i_ts rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 btusb bluetooth [10616.099537] CPU: 1Tainted: GW (3.4.75-01488-g43da4b4 #1) [10616.109575] PC is at unlink_anon_vmas+0x2c/0x164 [10616.117171] LR is at get_parent_ip+0x10/0x2c [10616.130325] pc : []lr : []psr: 200f0013 [10616.130339] sp : ef059da8 ip : ef059d20 fp : [10616.145743] r10: ed84c318 r9 : ee237ba0 r8 : ed84c350 [10616.156196] r7 : ee237ba0 r6 : ee222648 r5 : ee281bd0 r4 : ee281bd8 [10616.167947] r3 : ee222650 r2 : 80aa0064 r1 : d05c5020 r0 : [10616.180311] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [10616.191890] Control: 10c5387d Table: 6e26c06a DAC: 0015 [10616.199301] [10616.199308] PC: 0xc00cb108: [10616.204040] b108 e596 e284 eb1263f2 e355 0a0b e285301c f57ff05f e1932f9f [10616.219321] b128 e2422001 e1831f92 e331 1afa f57ff05f e352 1a01 e1a5 [10616.234605] b148 eb88 e1a7 ebfffb1a eab9 c0913480 e92d4ff8 e1a08000 e5b84038 [10616.249908] b168 e1a0a000 e1540008 e2445008 e5946000 e2466008 08bd8ff8 e3a07000 e595b004 [10616.265190] b188 e59b9000 e1570009 0a04 e357 1a37 e2890004 e1a07009 eb12643e [10616.280463] b1a8 e2850010 eb07d4f6 e59b2020 e28b3020 e1a4 e1520003 e1a04006 0a02 [10616.295733] b1c8 eb07d4ef e1a5 ebfffafa e5b43008 e1a05006 e1540008 e2436008 1ae6 [10616.311003] b1e8 e357 0a01 e2870004 eb1263b9 e59a6038 e1560008 e5965000 e1a04006 [10616.327487] [10616.327493] LR: 0xc005bf68: [10616.332224] bf68 e12fff33 e1a4 eb142801 eb01175e e7972105 e1a03006 e0833002 e59314a4 [10616.347494] bf88 e59324a8 e1510002 0a05 e3a03000 e5c434d8 e1a4 e1a01005 e8bd49f8 [10616.362764] bfa8 ea00226d e5932008 e352 1af6 e5933574 e2733001 33a03000 eaf3 [10616.378034] bfc8 c0810658 c07fd6c0 c08000c0 c08f8700 e92d4818 e28db00c e1a04000 eb007ee3 [10616.393304] bfe8 e350 0a02 e3a0 e1a04000 eb007ede e1a4 e8bd8818 e59f30bc [10616.408573] c008 e92d4830 e1a05000 e5933000 e28db00c e353 e1a0300d e3c34d7f e3c4403f [10616.423843] c028 1a04 e5943004 e153 ba0b e35000fe 9a14 e5943004 e1550003 [10616.439113] c048 0a03 e5943004 e0655003 e5845004 e8bd8830 e3a0 ebdc eaf8 [10616.455598] [10616.455604] SP: 0xef059d28: [10616.460334] 9d28 80aa0064 ed84c318 ee237900 c055ea84 c000ec40 80aa0064 c00360c0 [10616.475604] 9d48 c00cb188 200f0013 ef059d94 ed84c350 c000e7d8 d05c5020 [10616.490873] 9d68 80aa0064 ee222650 ee281bd8 ee281bd0 ee222648 ee237ba0 ed84c350 ee237ba0 [10616.506142] 9d88 ed84c318 ef059d20 ef059da8 c005bfe8 c00cb188 200f0013 [10616.521410] 9da8 b6e7a000 ed84c318 ed84cdc0 b5d0 1000 ef059e08 ee3ab880 [10616.536682] 9dc8 ed8de374 c00c136c b5d0 edad77e8 ee3ab880 edad77e8 ee3ab880 [10616.551952] 9de8 ef059e28 ef07e600 400f0013 c00c8498
Re: [linux-sunxi] Cubietruck lockup with current sunxi 3.4
Michal Suchanek writes: > Anyone else is experiencing stability issues? yes, using olimex olinuxino a20 micro details will follow (if time permits) -- 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/groups/opt_out.
