Re: [linux-sunxi] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Hi Jens, On Fri, Mar 13, 2015 at 2:56 AM, Jens Thiele wrote: > 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 Why am I not surprised that Allwinner isn't consistent in naming this parameter? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] touchscreen: sun4i-ts: Really fix A10 temperature reporting
On Mon, Mar 09, 2015 at 10:37:50AM +0100, Hans de Goede wrote:
> The commit titled:
> "touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
> contains a math error, the offset it uses is in degrees, but the actual code
> applies the offset before multiplying by stepsize :|
>
> Given that this is rather backwards (every math course ever thought applies
> the multiplication before the offset for linear functions), this commit
> fixes things by changing the code applying the offset to do the logical
> thing, adjusting the offset for the other models accordingly.
>
> This has been tested on an A10, A13, A20 and A31 to make sure everything
> really
> is correct now.
>
> Signed-off-by: Hans de Goede
> ---
> Note if possible this commit should be squashed into the original
> "touchscreen: sun4i-ts: A10 (sun4i) has a different temperature curve"
> commit as a fixup.
It's a bit too late, I do not like rewinding my 'next' branch unless it
is a compile error caught recently. So applied as a separate commit.
Thanks.
> ---
> drivers/input/touchscreen/sun4i-ts.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/touchscreen/sun4i-ts.c
> b/drivers/input/touchscreen/sun4i-ts.c
> index 66ccd5a..178d2ef 100644
> --- a/drivers/input/touchscreen/sun4i-ts.c
> +++ b/drivers/input/touchscreen/sun4i-ts.c
> @@ -193,7 +193,7 @@ static int sun4i_get_temp(const struct sun4i_ts_data *ts,
> long *temp)
> if (ts->temp_data == -1)
> return -EAGAIN;
>
> - *temp = (ts->temp_data - ts->temp_offset) * ts->temp_step;
> + *temp = ts->temp_data * ts->temp_step - ts->temp_offset;
>
> return 0;
> }
> @@ -255,17 +255,17 @@ static int sun4i_ts_probe(struct platform_device *pdev)
> ts->ignore_fifo_data = true;
> ts->temp_data = -1;
> if (of_device_is_compatible(np, "allwinner,sun6i-a31-ts")) {
> - /* Allwinner SDK has temperature = -271 + (value / 6) (C) */
> - ts->temp_offset = 1626;
> + /* Allwinner SDK has temperature (C) = (value / 6) - 271 */
> + ts->temp_offset = 271000;
> ts->temp_step = 167;
> } else if (of_device_is_compatible(np, "allwinner,sun4i-a10-ts")) {
> /*
>* The A10 temperature sensor has quite a wide spread, these
>* parameters are based on the averaging of the calibration
>* results of 4 completely different boards, with a spread of
> - * temp_step from 96 - 170 and temp_offset from 1758 - 3310.
> + * temp_step from 0.096 - 0.170 and temp_offset from 176 - 331.
>*/
> - ts->temp_offset = 2570;
> + ts->temp_offset = 257000;
> ts->temp_step = 133;
> } else {
> /*
> @@ -273,13 +273,13 @@ static int sun4i_ts_probe(struct platform_device *pdev)
>* the temperature. The formula used here is from the AXP209,
>* which is designed by X-Powers, an affiliate of Allwinner:
>*
> - * temperature = -144.7 + (value * 0.1)
> + * temperature (C) = (value * 0.1) - 144.7
>*
>* Allwinner does not have any documentation whatsoever for
>* this hardware. Moreover, it is claimed that the sensor
>* is inaccurate and cannot work properly.
>*/
> - ts->temp_offset = 1447;
> + ts->temp_offset = 144700;
> ts->temp_step = 100;
> }
>
> --
> 2.3.1
>
--
Dmitry
--
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] GSL1680 on A20
Yes, that one. Later I've decided to give this driver a try: https://github.com/rastersoft/gsl1680 It worked like a charm. I just had to swap the x and y coordinates on code, because it was working in portrait mode, but that's all. 2015-03-12 5:17 GMT-03:00 Priit Laes : > On Wed, 2015-03-11 at 20:08 -0300, Leonardo wrote: > > Hello everybody. I'm having such a hard time trying to get the > > GSL1680 touch panel working on my A20 device. Actually it's a INET > > K70 tablet and I would like to replace it's Android for a full Linux > > distro. > > This one? http://linux-sunxi.org/Inet_k70hc > > If not, then please start here: > http://linux-sunxi.org/New_Device_howto > > > Currently I'm booting using a SD card with Cubian (kernel 3.4.79), > > which is a distro made for Cubieboard, but as they're both A20, it > > works perfectly. I'm using this driver: > > > > https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/discussion > > https://gitorious.org/gslx680-for-sunxi/gslx680-for-sunxi > > > > It is the most recommended, according to > > http://linux-sunxi.org/GSL1680#Linux_driver > > > > From the Android's driver I could extract the following firmwares: > > GSL1680D_FW_K70.fw > > GSL1680E_FW_K70.fw > > GSL1680E_FW_K70_GG.fw > > GSL1680E_FW_K70_SG_NSM.fw > > GSL1680E_FW_K702B_PG_GS00.fw > > GSL1680E_FW_K703_PG.fw > > GSL1680E_FW_K70L_PG_YPD.fw > > GSL1680E_FW_K70L_V2.fw > > GSL1680E_FW_K70T_PG.fw > > GSL1680E_FW_K70T_PG_80048.fw > > GSL1688E_FW_K71_GG_102460.fw > > GSL1688E_FW_K71_OGS_10246.fw > > GSL1688E_FW_K71_OGS_80048.fw > > GSL1688E_FW_K71_PG_102460.fw > > GSL1688E_FW_K71_PG_800480.fw > > GSL1688E_FW_K72EW_OGS.fw > > GSL1688E_FW_K72EW_OGS_800.fw > > GSL1688E_FW_K72EW_PG.fw > > GSL1688E_FW_K72EW_PG_8004.fw > > GSL2682A_FW_K70_TOPSUN_OG.fw > > GSL2682B_FW_K790_OGS.fw > > GSL2682B_FW_K790_OGS_QSD.fw > > GSL2682B_FW_K790_PG_C1961.fw > > GSL2682B_FW_K790_PG_V2.fw > > GSL3680_FW_K100_PG_QLT100.fw > > GSL3680_FW_K9701L2B_TOPSU.fw > > Since on my chip it's written "GSL1680" and my tablet is a K70, I'm > > assuming the ones I colored blue are the good ones. > > > > After compiling the driver, I started getting a "gslx680: probe of 2- > > 0040 failed with error -22" error during boot. I got around this one > > by removing the IRQF_TRIGGER_FALLING flag from source code, as > > suggested here: > > > > https://groups.google.com/d/msg/linux-sunxi/SZGxiTQcFyY/qAFBsbt_9doJ > > > > It seems to be an A20 issue, as the same patch is required for the > > FT5x panel (see here). > > > > Now the kernel crashes when I try to boot. Luckily SSH still works, > > so I am able to disable the module and recover the system. A few > > times, despite the crash, the desktop loads successfully and I can > > get the cursor to move, but it's rare. The boot log is bellow. Could > > anyone help me getting it right? > > > > Thank you. > > > > [ 105.001094] > > ===gslx680_ts_init= > > [ 105.003649] _fetch_sysconfig_para. > > [ 105.007681] gslx680 firmware GSL1680E_FW_K70L_V2.fw. > > [ 105.016815] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, > > dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe > > [ 105.020912] _fetch_sysconfig_para: ctp_twi_id is 2. > > [ 105.025235] _fetch_sysconfig_para: screen_max_x = 1024. > > [ 105.029424] _fetch_sysconfig_para: screen_max_y = 600. > > [ 105.033526] _fetch_sysconfig_para: revert_x_flag = 0. > > [ 105.037662] _fetch_sysconfig_para: revert_y_flag = 0. > > [ 105.042123] _fetch_sysconfig_para: exchange_x_y_flag = 0. > > [ 105.046904] _init_platform_resource: tp_io request gpio fail! [ > > 105.052219] i2c-core: driver [gslx680] using legacy suspend method [ > > 105.057347] i2c-core: driver [gslx680] using legacy resume method [ > > 105.059769] incomplete xfer (0x20) > > [ 105.065004] incomplete xfer (0x20) > > [ 105.071175] ctp_detect: Detected chip gslx680 at adapter 2, > > address 0x40 > > [ 105.075078] gslx680_ts_probe begin=. > > [ 105.077122] ==kzalloc success= > > [ 105.079955] [GSLX680] Enter gsl_ts_init_ts > > [ 105.084326] ctp_set_irq_mode: config gpio to int mode. > > [ 105.090373] ctp_set_irq_mode, 854: gpio_int_info, port = 8, > > port_num = 21. > > [ 105.092447] INTERRUPT CONFIG > > [ 105.102321] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c- > > 2/2-0040/input/input1 > > [ 105.193666] =gsl_load_fw start== > > [ 105.235179] usb 2-1: new high-speed USB device number 2 using sw- > > ehci [ 106.638105] =gsl_load_fw end== > > [ 106.952754] ==gslx680_ts_probe over = > > [ 112.663989] EXT4-fs (mmcblk0p1): mounted filesystem with ordered > > data mode. Opts: (null) > > [ 117.500978] Installing knfsd (copyright (C) 1996 o...@monad.swb.de > > ). [ 128.578084] Unable to handle kernel paging request at virtual > > address 12d51004 > > [ 128.579812] pgd = ee7b8000 > > [ 128.603298] [12d51004] *pgd= > > [ 128.610688] Internal error: Oops: 5 [#1] PREEMPT S
Re: OFFTOPIC: Re: [linux-sunxi] Derailed thread
Hi, if someone want to make a binary analysis/reverse engineering of proprietary driver I would donate to the project. Is there some paypal accepting donations to this project? Or some donation box for the linux-sunxi project as well? Em quinta-feira, 12 de março de 2015 06:25:41 UTC-3, Simos Xenitellis escreveu: > > On Wed, Mar 11, 2015 at 3:48 PM, Benjamin Henrion > wrote: > > On Wed, Mar 11, 2015 at 12:34 PM, Simos Xenitellis > > > wrote: > >> On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion > wrote: > >>> > >>> > >>> On Tuesday, March 10, 2015, Quink > > wrote: > I have communicated with the author of source code of libvdecoder.so. > The code has been rewrote completely, has no relationship with > FFmpeg, > >>> > >>> I don't think it would resist a binary analysis. > >>> > >> > >> Doesn't pass the code of conduct (for example, > >> http://www.ubuntu.com/about/about-ubuntu/conduct). > > > > I don't see how I am violating any code of conduct here, quite the > contrary. > > > > The issue is that you *insinuate* that the claim (no relationship with > FFmpeg) is false. > What would be the next step to such a discussion? The one side claims > no, the other yes, ad infinitum. > > For this to go forward, you or someone else needs to do this "binary > analysis". > Once the binary analysis is done and you have something to show, you > can reply with your data. In that way, such a discussion could > potentially move forward. > > In terms of "code of conduct" documents, the idea is, when replying, > to move a discussion forward. > If a thread veers off, then change the Subject:, thus start a new thread. > If you find any evidence of common binary code, you can present it > respectfully > and still it is going to be strong evidence (i.e. I did > "arm-linux-gnueabihf-objdump -d libvdecoder.so" > and the same to that other lib, and function xyz matches as shown here > and here). > > Simos > > > I was maintaining the ISL3893 project 10 years ago, where one of the > > vendor was sued in court in Germany for not giving out the sources: > > > > http://isl3893.sourceforge.net/ > > > > But that was on the action of copyright holders at the time (Harald > Welte). > > > > -- > > Benjamin Henrion > > FFII Brussels - +32-484-566109 - +32-2-4148403 > > "In July 2005, after several failed attempts to legalise software > > patents in Europe, the patent establishment changed its strategy. > > Instead of explicitly seeking to sanction the patentability of > > software, they are now seeking to create a central European patent > > court, which would establish and enforce patentability rules in their > > favor, without any possibility of correction by competing courts or > > democratically elected legislators." > > > > -- > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On 03/12/15 12:12, Simos Xenitellis wrote: However, that analysis would refer to a prior version of the library. In this thread the discussion is about the "March 2015" libvdecode.so/libvencode.so libraries. releasing a binary that removes GPL code does not discharge the obligation to release the source code for the infringing version you cannot unsteal something -- simon Simon Kenyon e: simoncken...@gmail.com m: +353 86 240 0005 l: http://ie.linkedin.com/pub/simon-kenyon/0/6b2/744/ s: simonckenyon t: @simonckenyon g: google.com/+SimonKenyon -- 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: OFFTOPIC: Re: [linux-sunxi] Derailed thread
>On Thu, 12/3/15, Simos Xenitellis wrote: [snip] > communicate with Allwinner How? Where ARE Allwinner in this? If they're contactable WHERE IS THE SOURCE? I see a big, bad, unresponsive, uncaring company stealing other people's code and not obeying licences. Shame on Allwinner. If you Simos can change them please get on and do so. If not then I see no way in which you are helping. John -- 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: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Thu, Mar 12, 2015 at 12:20 PM, Luc Verhaegen wrote: > On Thu, Mar 12, 2015 at 11:25:19AM +0200, Simos Xenitellis wrote: >> On Wed, Mar 11, 2015 at 3:48 PM, Benjamin Henrion wrote: >> > On Wed, Mar 11, 2015 at 12:34 PM, Simos Xenitellis >> > wrote: >> >> On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion >> >> wrote: >> >>> >> >>> >> >>> On Tuesday, March 10, 2015, Quink wrote: >> I have communicated with the author of source code of libvdecoder.so. >> The code has been rewrote completely, has no relationship with FFmpeg, >> >>> >> >>> I don't think it would resist a binary analysis. >> >>> >> >> >> >> Doesn't pass the code of conduct (for example, >> >> http://www.ubuntu.com/about/about-ubuntu/conduct). >> > >> > I don't see how I am violating any code of conduct here, quite the >> > contrary. >> > >> >> The issue is that you *insinuate* that the claim (no relationship with >> FFmpeg) is false. >> What would be the next step to such a discussion? The one side claims >> no, the other yes, ad infinitum. >> >> For this to go forward, you or someone else needs to do this "binary >> analysis". >> Once the binary analysis is done and you have something to show, you >> can reply with your data. In that way, such a discussion could >> potentially move forward. > > I have done a full symbol analysis of libvecore as shipped on the > cubieboard back in august. It clearly shows ffmpeg and libavcodec vs > libvp62 and other questionable code whose origins are not clear. It's a > txt file, but i should still toss it onto the wiki. > If it is a big txt file, it should go to a pastebin and be linked from the Wiki. However, that analysis would refer to a prior version of the library. In this thread the discussion is about the "March 2015" libvdecode.so/libvencode.so libraries. Moreover, Quink asked earlier a specific technical question. In terms of "code of conduct", if there is no answer to that question, then the question would remain unanswered (for the time being). It's not good to hijack a question and instead another thread should be created. > I have done a brief nm of the newly "LGPL"ed binary to find libavcodec > and libvp62 symbols. I will happily spend a few hours and take that new > library apart as i did the older one. I stated that i would do so last > week, but i of course have not gotten to that yet. > > Having an allwinner employee state that that violating code has all been > removed now, in this last... Week? That is just not credible. > > After legal advice has been acquired, i will be happy to do the binary > analysis, accounting for every hour, and Allwinner will then end up > paying for my time. I can then get the cedrus guys a wide range of hw, > and stick some cash in our linux-sunxi infrastructure. Everyone wins. > > Except allwinner. > >> In terms of "code of conduct" documents, the idea is, when replying, >> to move a discussion forward. >> If a thread veers off, then change the Subject:, thus start a new thread. >> If you find any evidence of common binary code, you can present it >> respectfully >> and still it is going to be strong evidence (i.e. I did >> "arm-linux-gnueabihf-objdump -d libvdecoder.so" >> and the same to that other lib, and function xyz matches as shown here >> and here). > > Again, if anyone who states anything that is supporting established and > proven open source licenses, licenses which allwinner has been proven, > without a doubt, to breach, you want to see them removed or at least > silenced. How many people will be left in that ideal linux-sunxi > community of yours, and how many of them will be able to usefully > contribute code, documentation, or user help in your dystopia? > It is OK to express any relevant viewpoint, as long as it is done respectfully. What I see here, however, is extreme anger, the anger is expressed in the list, and it affects the people in the discussions. In addition, the important issue is how you see yourself in the community, in an aftermath of "Luc is now fully satisfied with all licensing issues" situation. Do you see yourself content to contribute and communicate with Allwinner for any future mainline efforts? My view is that the accumulating anger has taken its toll and there will be no happy "after" situation; the interest to contribute would have been exhausted. Simos -- 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: OFFTOPIC: Re: [linux-sunxi] Derailed thread
>On Thu, 12/3/15, Simos Xenitellis wrote: [snip] The code has been rewrote completely, has no relationship with FFmpeg Even if true, Allwinner still must release previous versions of infringing code. WHERE IS THE SOURCE LOTS IS MISSING. Sorry for shouting but Allwinner are bad. It's in their hands to change. It's sad, indeed pathetic, to see anyone apologising for and trying to excuse/explain their bad behaviour. No apologies etc are needed, just the sources. John -- 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: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Thu, Mar 12, 2015 at 11:25:19AM +0200, Simos Xenitellis wrote: > On Wed, Mar 11, 2015 at 3:48 PM, Benjamin Henrion wrote: > > On Wed, Mar 11, 2015 at 12:34 PM, Simos Xenitellis > > wrote: > >> On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion wrote: > >>> > >>> > >>> On Tuesday, March 10, 2015, Quink wrote: > I have communicated with the author of source code of libvdecoder.so. > The code has been rewrote completely, has no relationship with FFmpeg, > >>> > >>> I don't think it would resist a binary analysis. > >>> > >> > >> Doesn't pass the code of conduct (for example, > >> http://www.ubuntu.com/about/about-ubuntu/conduct). > > > > I don't see how I am violating any code of conduct here, quite the contrary. > > > > The issue is that you *insinuate* that the claim (no relationship with > FFmpeg) is false. > What would be the next step to such a discussion? The one side claims > no, the other yes, ad infinitum. > > For this to go forward, you or someone else needs to do this "binary > analysis". > Once the binary analysis is done and you have something to show, you > can reply with your data. In that way, such a discussion could > potentially move forward. I have done a full symbol analysis of libvecore as shipped on the cubieboard back in august. It clearly shows ffmpeg and libavcodec vs libvp62 and other questionable code whose origins are not clear. It's a txt file, but i should still toss it onto the wiki. I have done a brief nm of the newly "LGPL"ed binary to find libavcodec and libvp62 symbols. I will happily spend a few hours and take that new library apart as i did the older one. I stated that i would do so last week, but i of course have not gotten to that yet. Having an allwinner employee state that that violating code has all been removed now, in this last... Week? That is just not credible. After legal advice has been acquired, i will be happy to do the binary analysis, accounting for every hour, and Allwinner will then end up paying for my time. I can then get the cedrus guys a wide range of hw, and stick some cash in our linux-sunxi infrastructure. Everyone wins. Except allwinner. > In terms of "code of conduct" documents, the idea is, when replying, > to move a discussion forward. > If a thread veers off, then change the Subject:, thus start a new thread. > If you find any evidence of common binary code, you can present it > respectfully > and still it is going to be strong evidence (i.e. I did > "arm-linux-gnueabihf-objdump -d libvdecoder.so" > and the same to that other lib, and function xyz matches as shown here > and here). Again, if anyone who states anything that is supporting established and proven open source licenses, licenses which allwinner has been proven, without a doubt, to breach, you want to see them removed or at least silenced. How many people will be left in that ideal linux-sunxi community of yours, and how many of them will be able to usefully contribute code, documentation, or user help in your dystopia? Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Derailed thread
Wow!! "Search and Replace" is not the same as coming clean from license violations! Do you really believe that one could do: a) Replace all strings, b) replace all function name and claim they're now good ? People are smarter than that! On Tuesday, March 10, 2015 at 11:32:28 AM UTC-5, Zhao Zhili wrote: > > I have communicated with the author of source code of libvdecoder.so. > The code has been rewrote completely, has no relationship with FFmpeg, > except some function names. This is a silly mistake, but maybe it's true. > Does anybody know how to prove that? > > If the LGPL violations of libvdecoder.so can be cleaned up, how can we use > the shared library on open source sunxi kernel, and even mainline kernel? > I don't what's the low level part in the kernel that libvdecoder.so > depends on, > a thin VPU driver and some special memory management modules? If those > parts can be solved, does the cedar + openmax + gstreamor openmax plugin > workable? > > On Tue, Mar 10, 2015 at 11:01 PM, Luc Verhaegen > wrote: > >> On Tue, Mar 10, 2015 at 01:38:30PM +, Manuel Braga wrote: >> > Hi, >> > >> > That was a joke mail, in response to the joke that allwinner gave us >> > when allwinner added the LGPL license to source code that includes a >> > binary accused of being in noncompliance. >> >> This was not a joke email. Its contents was very serious, and it should >> be interpreted as such. Allwinner needs/needed to know what it had just >> done, and that it has to fullfill its obligations. >> >> The fact that I did so, _after_ the facts had been often and openly >> discussed, and after allwinner had been explained their obligations >> countless times, does make it less than serious. >> >> The contents however is nothing to be laughed about. >> >> > > try to get the support of something like the SFC so that they can >> > > evaluate the merits of pursuing. >> > > And then the SFC would do the talking. >> > >> > I heared (but don't have the details), and this looks to be true. SFC >> > or someone from SFC is aware of this issue. But maybe others can make >> > this more clear. >> > >> > But nobody is here to sue, (why do i have to keep saying this) >> > i think i can speak for all and say that we want to resolve this in a >> > friendly way, but for that, there most be dialog between parties. >> > Not excuse to ignore the issues. >> > >> > And Simos look at the news, with SFC and vmware, look at the time it >> > took and no result. >> >> People tried talking to VMWare for 7-8 years. We have been trying to >> talk to Allwinner at least since 2012 (i am sure that LKCL would be >> happy to divulge his conversations with allwinner if it comes to legal >> action). Allwinners case is pretty open and shut, especially since they >> actively use both the kernel and uboot, and the symbols in cedar are >> clearly visible. And unlike VMWare Allwinner has its _whole_ business to >> lose. >> >> When there is any legal action, it could be a lot swifter. Perhaps >> Allwinner should act quickly and do so in an all encompassing way. If >> not, it stands to lose quite a lot. >> >> Luc Verhaegen. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "linux-sunxi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to linux-sunxi...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Hans Fosdem video is here
On Wed, Mar 11, 2015 at 5:18 PM, Benjamin Henrion wrote: > Hi, > > Just to let you know that FOSDEM videos are being released, if you > have not yet seen Hans's presentation: > > http://video.fosdem.org/2015/devroom-embedded/allwinner_upstream__CROPPED_PRES.mp4 > > The video seems to start not from the beginning of the talk. > > Don't know if the slides are published somewhere online. > They are published online at https://fosdem.org/2015/schedule/event/allwinner_upstream/ See the "Attachments" section. Simos -- 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: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Wed, Mar 11, 2015 at 3:48 PM, Benjamin Henrion wrote: > On Wed, Mar 11, 2015 at 12:34 PM, Simos Xenitellis > wrote: >> On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion wrote: >>> >>> >>> On Tuesday, March 10, 2015, Quink wrote: I have communicated with the author of source code of libvdecoder.so. The code has been rewrote completely, has no relationship with FFmpeg, >>> >>> I don't think it would resist a binary analysis. >>> >> >> Doesn't pass the code of conduct (for example, >> http://www.ubuntu.com/about/about-ubuntu/conduct). > > I don't see how I am violating any code of conduct here, quite the contrary. > The issue is that you *insinuate* that the claim (no relationship with FFmpeg) is false. What would be the next step to such a discussion? The one side claims no, the other yes, ad infinitum. For this to go forward, you or someone else needs to do this "binary analysis". Once the binary analysis is done and you have something to show, you can reply with your data. In that way, such a discussion could potentially move forward. In terms of "code of conduct" documents, the idea is, when replying, to move a discussion forward. If a thread veers off, then change the Subject:, thus start a new thread. If you find any evidence of common binary code, you can present it respectfully and still it is going to be strong evidence (i.e. I did "arm-linux-gnueabihf-objdump -d libvdecoder.so" and the same to that other lib, and function xyz matches as shown here and here). Simos > I was maintaining the ISL3893 project 10 years ago, where one of the > vendor was sued in court in Germany for not giving out the sources: > > http://isl3893.sourceforge.net/ > > But that was on the action of copyright holders at the time (Harald Welte). > > -- > Benjamin Henrion > FFII Brussels - +32-484-566109 - +32-2-4148403 > "In July 2005, after several failed attempts to legalise software > patents in Europe, the patent establishment changed its strategy. > Instead of explicitly seeking to sanction the patentability of > software, they are now seeking to create a central European patent > court, which would establish and enforce patentability rules in their > favor, without any possibility of correction by competing courts or > democratically elected legislators." > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Derailed thread
On Wed, Mar 11, 2015 at 06:29:50PM +0100, Luc Verhaegen wrote: > > The only workable solution for Allwinner now is full support of the > cedrus REing project, and using the code that comes from that, across > the board. As was suggested on August 23rd last year, when i publically exposed the (L)GPL violation while also reaching out to allwinner in private conversation, about the much more volatile libvp62 illegal code. Nobody believes allwinner any more at this point. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
Hi, On 11-03-15 14:41, Maxime Ripard wrote: On Tue, Mar 10, 2015 at 11:33:51PM +0100, Hans de Goede wrote: and we have no way to replace U-Boot in NAND so far (afaik). But replacing them by stdout-path is a very good solution too. You mean putting stdout-path in the dts, I'm not sure if I like that, to me both bootargs and stdout-path are something which should be left to the bootloader to set. But I understand that when not using upstream u-boot that may be an issue. I know that some other platforms ask for stdout-path when they review it, because iirc, barebox uses it to know on which console to output its log and export its shell, which is also a valid interpretation of that property, and, contrary to bootargs, doesn't really imply that the bootloader should update it. Hmm, that is interesting we should probably start doing the same in all the sunxi dts files, as eventually I would like to move all u-boot board config to devicetree, so that we only need to maintain dts files and not both dts files and u-boot board configs. I had the plan to remove all earlyprintk in the bootargs of the DTS, I can do it to convert all DTS to use stdout-path as well. Sounds good, please do. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On 11-03-15 13:50, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 11 March 2015 05:09 PM, Hans de Goede wrote:
Hi,
On 11-03-15 10:13, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 10 March 2015 04:33 PM, Hans de Goede wrote:
Hi,
On 10-03-15 11:53, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 10 March 2015 03:43 PM, Hans de Goede wrote:
Hi,
On 10-03-15 09:57, Arnd Bergmann wrote:
On Tuesday 10 March 2015 09:04:43 Hans de Goede wrote:
Hi,
On 09-03-15 22:47, Arnd Bergmann wrote:
On Monday 09 March 2015 21:40:15 Hans de Goede wrote:
+void sun4i_usb_phy_update_iscr(struct phy *_phy, u32 clr, u32 set)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ u32 iscr;
+
+ iscr = readl(data->base + REG_ISCR);
+ iscr &= ~clr;
+ iscr |= set;
+ writel(iscr, data->base + REG_ISCR);
+}
+EXPORT_SYMBOL(sun4i_usb_phy_update_iscr);
+
I would generally consider this a bad design. What is the purpose of
calling sun4i_usb_phy_update_iscr()
right. That would bind the PHY driver and the controller driver and would
start creating problems when a different PHY is connected with the
controller.
There are 2 different use cases for this one is to enable the dataline
pull-ups at driver init and disable them at driver exit, this could /
should probably be moved to the phy_init / phy_exit code for the usb0 phy
removing the need to do this from within the sunxi musb glue.
The second use-case is more tricky, for some reasons Allwinner has decided
to not use the dedicated id-detect and vusb-sense pins of the phy they are
using (these pins are not routed to the outside).
Instead id-detect and vusb-sense are done through any $random gpio pins
(including non irq capable pins on some designs requiring polling).
The polling can still be done in PHY driver and can use the extcon framework
to report the status to controller driver no?
Technically the polling can be moved to the phy driver yes, but it is not easy,
e.g. we only need to poll when we're in otg mode rather then host-only
or peripheral-only mode, and the mode gets set by the musb driver not phy
the phy driver. The sunxi musb implementation uses an integrated phy, so it
is just much easier and more logical to have all control / polling happening
from a single module rather then from 2 different modules.
But the musb-core still needs to know the status of the id and vbus pins,
musb-core or the musb-glue (musb/sunxi.c in this case)?
and gets this from the usb0-phy iscr register, which reflects the status of
the not connected dedicated pins of the phy. The reason this can still
work at all is because the iscr register allows the user to override
whatever the not connected phy pins are seeing and forcing a value to
report to the musb core as id and vbus status.
This is done by these 2 functions in the musb sunxi glue:
static void sunxi_musb_force_id(struct musb *musb, u32 val)
{
struct sunxi_glue *glue =
dev_get_drvdata(musb->controller->parent);
if (val)
val = SUNXI_ISCR_FORCE_ID_HIGH;
else
val = SUNXI_ISCR_FORCE_ID_LOW;
sun4i_usb_phy_update_iscr(glue->phy, SUNXI_ISCR_FORCE_ID_MASK,
val);
What will writing to this register lead to? call to sunxi_musb_id_vbus_det_irq
interrupt handler?
No this changes the vbus and id status as seen by the musb core, and the musb
responds to this, by e.g. starting a session, or when vbus does not get high
after a session request by reporting a vbus-error interrupt.
The sunxi_musb_id_vbus_det_irq handler gets triggered by edges on the gpio
pins which are used to monitor the id and vbus status.
}
static void sunxi_musb_force_vbus(struct musb *musb, u32 val)
{
struct sunxi_glue *glue =
dev_get_drvdata(musb->controller->parent);
if (val)
val = SUNXI_ISCR_FORCE_VBUS_HIGH;
else
val = SUNXI_ISCR_FORCE_VBUS_LOW;
sun4i_usb_phy_update_iscr(glue->phy, SUNXI_ISCR_FORCE_VBUS_MASK,
val);
}
I will happily admit that these 2 functions are a better API between the
sunxi musb
glue and the sunxi usb phy driver. I started with the minimal
sun4i_usb_phy_update_iscr
approach as I wanted to keep the API as small as possible, but having 2
functions like
the one above, which actually reflect what is happening would indeed be
better.
Ok, that would definitely improve things.
Note that the polling of the pins cannot (easily) be moved into the phy
driver for various
reasons:
1) It depends on dr_mode, the otg may be used in host only mode in which
case there are no
pins at all.
2) the musb set_vbus callback needs access to the pins
3) When id changes some musb core state changes are necessary.
I'll respin the patch set to do things this way as soon as we've
agreement on
your second point.
> and why can't there be a high-level
PHY API for this?
The current generic
Re: [linux-sunxi] GSL1680 on A20
On Wed, 2015-03-11 at 20:08 -0300, Leonardo wrote: > Hello everybody. I'm having such a hard time trying to get the > GSL1680 touch panel working on my A20 device. Actually it's a INET > K70 tablet and I would like to replace it's Android for a full Linux > distro. This one? http://linux-sunxi.org/Inet_k70hc If not, then please start here: http://linux-sunxi.org/New_Device_howto > Currently I'm booting using a SD card with Cubian (kernel 3.4.79), > which is a distro made for Cubieboard, but as they're both A20, it > works perfectly. I'm using this driver: > > https://groups.google.com/d/topic/linux-sunxi/SZGxiTQcFyY/discussion > https://gitorious.org/gslx680-for-sunxi/gslx680-for-sunxi > > It is the most recommended, according to > http://linux-sunxi.org/GSL1680#Linux_driver > > From the Android's driver I could extract the following firmwares: > GSL1680D_FW_K70.fw > GSL1680E_FW_K70.fw > GSL1680E_FW_K70_GG.fw > GSL1680E_FW_K70_SG_NSM.fw > GSL1680E_FW_K702B_PG_GS00.fw > GSL1680E_FW_K703_PG.fw > GSL1680E_FW_K70L_PG_YPD.fw > GSL1680E_FW_K70L_V2.fw > GSL1680E_FW_K70T_PG.fw > GSL1680E_FW_K70T_PG_80048.fw > GSL1688E_FW_K71_GG_102460.fw > GSL1688E_FW_K71_OGS_10246.fw > GSL1688E_FW_K71_OGS_80048.fw > GSL1688E_FW_K71_PG_102460.fw > GSL1688E_FW_K71_PG_800480.fw > GSL1688E_FW_K72EW_OGS.fw > GSL1688E_FW_K72EW_OGS_800.fw > GSL1688E_FW_K72EW_PG.fw > GSL1688E_FW_K72EW_PG_8004.fw > GSL2682A_FW_K70_TOPSUN_OG.fw > GSL2682B_FW_K790_OGS.fw > GSL2682B_FW_K790_OGS_QSD.fw > GSL2682B_FW_K790_PG_C1961.fw > GSL2682B_FW_K790_PG_V2.fw > GSL3680_FW_K100_PG_QLT100.fw > GSL3680_FW_K9701L2B_TOPSU.fw > Since on my chip it's written "GSL1680" and my tablet is a K70, I'm > assuming the ones I colored blue are the good ones. > > After compiling the driver, I started getting a "gslx680: probe of 2- > 0040 failed with error -22" error during boot. I got around this one > by removing the IRQF_TRIGGER_FALLING flag from source code, as > suggested here: > > https://groups.google.com/d/msg/linux-sunxi/SZGxiTQcFyY/qAFBsbt_9doJ > > It seems to be an A20 issue, as the same patch is required for the > FT5x panel (see here). > > Now the kernel crashes when I try to boot. Luckily SSH still works, > so I am able to disable the module and recover the system. A few > times, despite the crash, the desktop loads successfully and I can > get the cursor to move, but it's rare. The boot log is bellow. Could > anyone help me getting it right? > > Thank you. > > [ 105.001094] > ===gslx680_ts_init= > [ 105.003649] _fetch_sysconfig_para. > [ 105.007681] gslx680 firmware GSL1680E_FW_K70L_V2.fw. > [ 105.016815] _fetch_sysconfig_para: after: ctp_twi_addr is 0x40, > dirty_addr_buf: 0x40. dirty_addr_buf[1]: 0xfffe > [ 105.020912] _fetch_sysconfig_para: ctp_twi_id is 2. > [ 105.025235] _fetch_sysconfig_para: screen_max_x = 1024. > [ 105.029424] _fetch_sysconfig_para: screen_max_y = 600. > [ 105.033526] _fetch_sysconfig_para: revert_x_flag = 0. > [ 105.037662] _fetch_sysconfig_para: revert_y_flag = 0. > [ 105.042123] _fetch_sysconfig_para: exchange_x_y_flag = 0. > [ 105.046904] _init_platform_resource: tp_io request gpio fail! [ > 105.052219] i2c-core: driver [gslx680] using legacy suspend method [ > 105.057347] i2c-core: driver [gslx680] using legacy resume method [ > 105.059769] incomplete xfer (0x20) > [ 105.065004] incomplete xfer (0x20) > [ 105.071175] ctp_detect: Detected chip gslx680 at adapter 2, > address 0x40 > [ 105.075078] gslx680_ts_probe begin=. > [ 105.077122] ==kzalloc success= > [ 105.079955] [GSLX680] Enter gsl_ts_init_ts > [ 105.084326] ctp_set_irq_mode: config gpio to int mode. > [ 105.090373] ctp_set_irq_mode, 854: gpio_int_info, port = 8, > port_num = 21. > [ 105.092447] INTERRUPT CONFIG > [ 105.102321] input: gslx680 as /devices/platform/sunxi-i2c.2/i2c- > 2/2-0040/input/input1 > [ 105.193666] =gsl_load_fw start== > [ 105.235179] usb 2-1: new high-speed USB device number 2 using sw- > ehci [ 106.638105] =gsl_load_fw end== > [ 106.952754] ==gslx680_ts_probe over = > [ 112.663989] EXT4-fs (mmcblk0p1): mounted filesystem with ordered > data mode. Opts: (null) > [ 117.500978] Installing knfsd (copyright (C) 1996 o...@monad.swb.de > ). [ 128.578084] Unable to handle kernel paging request at virtual > address 12d51004 > [ 128.579812] pgd = ee7b8000 > [ 128.603298] [12d51004] *pgd= > [ 128.610688] Internal error: Oops: 5 [#1] PREEMPT SMP ARM > [ 128.612584] Modules linked in: nfsd exportfs gslx680_ts(O) 8188eu > cp210x sunxi_cedar_mod mali ump gpio_sunxi > [ 128.624646] CPU: 1Tainted: G O (3.4.79-sun7i #14) [ > 128.627862] PC is at module_refcount+0x3c/0xb0 > [ 128.631080] LR is at module_refcount+0x54/0xb0 > [ 128.640242] pc : []lr : []psr: > 2013 [ 128.640262] sp : eeaf9eb8 ip : fp : bf0f0534 > [ 128.644299] r10: r9 : c0
[linux-sunxi] [PATCH v3] input: Add support for ChipOne icn8318 based touchscreens
The ChipOne icn8318 is an i2c capacitive touchscreen controller typically
used in cheap android tablets, this commit adds a driver for it.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix spurious events after a close + open of the evdev node.
Changes in v3:
-Add a msleep after waking the device on open, to wait for it to be ready
for i2c communications, otherwise we get communication errors on device open
---
.../bindings/input/touchscreen/chipone_icn8318.txt | 46 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 7 +
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/chipone_icn8318.c| 318 +
6 files changed, 386 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
create mode 100644 drivers/input/touchscreen/chipone_icn8318.c
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
new file mode 100644
index 000..b405493
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
@@ -0,0 +1,46 @@
+* ChipOne icn8318 I2C touchscreen controller
+
+Required properties:
+ - compatible: "chipone,icn8318"
+ - reg : I2C slave address of the chip (0x40)
+ - interrupt-parent : a phandle pointing to the interrupt controller
+ serving the interrupt for this chip
+ - interrupts: interrupt specification for the icn8318 interrupt
+ - wake-gpios: GPIO specification for the WAKE input
+ - touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
+ - touchscreen-size-y: vertical resolution of touchscreen (in pixels)
+
+Optional properties:
+ - pinctrl-names : should be "default"
+ - pinctrl-0:: a phandle pointing to the pin settings for the
+ control gpios
+ - touchscreen-fuzz-x: horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y: vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+ - touchscreen-swap-x-y : X and Y axis are swapped (boolean)
+ Swapping is done after inverting the axis
+
+Example:
+
+i2c@ {
+ /* ... */
+
+ chipone_icn8318@40 {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ interrupt-parent = <&pio>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_wake_pin_p66>;
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swap-x-y;
+ };
+
+ /* ... */
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca13..b5dea36 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -35,6 +35,7 @@ capella Capella Microsystems, Inc
cavium Cavium, Inc.
cdns Cadence Design Systems Inc.
chipidea Chipidea, Inc
+chiponeChipOne
chipspark ChipSPARK
chrp Common Hardware Reference Platform
chunghwa Chunghwa Picture Tubes Ltd.
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..d39304c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2512,6 +2512,13 @@ L: linux-...@vger.kernel.org
S: Maintained
F: drivers/usb/chipidea/
+CHIPONE ICN8318 I2C TOUCHSCREEN DRIVER
+M: Hans de Goede
+L: linux-in...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
+F: drivers/input/touchscreen/chipone_icn8318.c
+
CHROME HARDWARE PLATFORM SUPPORT
M: Olof Johansson
S: Maintained
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..19ca23e 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -140,6 +140,19 @@ config TOUCHSCREEN_BU21013
To compile this driver as a module, choose M here: the
module will be called bu21013_ts.
+config TOUCHSCREEN_CHIPONE_ICN8318
+ tristate "chipone icn8318 touchscreen controller"
+ depends on GPIOLIB
+ depends on I2C
+ depends on OF
+ help
+ Say Y here if you have a ChipOne icn8318 based I2C touchscreen.
+
+ If unsure, say N.
+
+
Re: [linux-sunxi] Derailed thread
I have communicated with the author of source code of libvdecoder.so. The code has been rewrote completely, has no relationship with FFmpeg, except some function names. This is a silly mistake, but maybe it's true. Does anybody know how to prove that? If the LGPL violations of libvdecoder.so can be cleaned up, how can we use the shared library on open source sunxi kernel, and even mainline kernel? I don't what's the low level part in the kernel that libvdecoder.so depends on, a thin VPU driver and some special memory management modules? If those parts can be solved, does the cedar + openmax + gstreamor openmax plugin workable? On Tue, Mar 10, 2015 at 11:01 PM, Luc Verhaegen wrote: > On Tue, Mar 10, 2015 at 01:38:30PM +, Manuel Braga wrote: > > Hi, > > > > That was a joke mail, in response to the joke that allwinner gave us > > when allwinner added the LGPL license to source code that includes a > > binary accused of being in noncompliance. > > This was not a joke email. Its contents was very serious, and it should > be interpreted as such. Allwinner needs/needed to know what it had just > done, and that it has to fullfill its obligations. > > The fact that I did so, _after_ the facts had been often and openly > discussed, and after allwinner had been explained their obligations > countless times, does make it less than serious. > > The contents however is nothing to be laughed about. > > > > try to get the support of something like the SFC so that they can > > > evaluate the merits of pursuing. > > > And then the SFC would do the talking. > > > > I heared (but don't have the details), and this looks to be true. SFC > > or someone from SFC is aware of this issue. But maybe others can make > > this more clear. > > > > But nobody is here to sue, (why do i have to keep saying this) > > i think i can speak for all and say that we want to resolve this in a > > friendly way, but for that, there most be dialog between parties. > > Not excuse to ignore the issues. > > > > And Simos look at the news, with SFC and vmware, look at the time it > > took and no result. > > People tried talking to VMWare for 7-8 years. We have been trying to > talk to Allwinner at least since 2012 (i am sure that LKCL would be > happy to divulge his conversations with allwinner if it comes to legal > action). Allwinners case is pretty open and shut, especially since they > actively use both the kernel and uboot, and the symbols in cedar are > clearly visible. And unlike VMWare Allwinner has its _whole_ business to > lose. > > When there is any legal action, it could be a lot swifter. Perhaps > Allwinner should act quickly and do so in an all encompassing way. If > not, it stands to lose quite a lot. > > Luc Verhaegen. > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
