[linux-sunxi] Hans Fosdem video is here
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. Best, -- Benjamin Henrion bhenrion at ffii.org 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.
Re: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Wed, Mar 11, 2015 at 01:34:18PM +0200, Simos Xenitellis wrote: On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion zoo...@gmail.com wrote: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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). Simos Am i reading this right? Do you now wish to see Ben removed from the linux-sunxi community as well? So basically, everyone who wants established and proven open source licenses honoured, you would like to see them removed from linux-sunxi? Good luck with that. 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
On Wed, Mar 11, 2015 at 12:32:25AM +0800, 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, except some function names. This is a silly mistake, but maybe it's true. Does anybody know how to prove that? We've proven extensively that Allwinner breached not only ffmpeg/libavcodec licensing, it also used illegal code, and given that wide a span of very foul license violations, nobody can trust allwinner any more when it claims that it now has clean hands. Allwinner should not be asking linux-sunxi.org for advice on how to prove that their hands are clean today. They should have a small army of lawyers at the ready this point. These lawyers should be well versed in international copyright and IP matters, and also have a good grasp of the english language. 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? 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. Any solution which has allwinner using any binary is now suspicious and allwinner will not be able to satisfactorilly prove the origins of such code or the fact that no licenses or other things are breached this time round. Plus, some well known REers probably need to go waste a lot of time on said binaries, and this time will in the end be billed to Allwinner. So Allwinner should give up on any strategy that involves binaries. Now. And have some chance of seeing this resolved amicably. 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.
[linux-sunxi] Re: [PATCH] pinctrl: sun4i: GPIOs configured as irq must be set to input before reading
On Sun, Mar 08, 2015 at 10:13:57PM +0100, Hans de Goede wrote: On sun4i-a10, when GPIOs are configured as external interrupt the value for them in the data register does not seem to get updated, so set their mux to input (and restore afterwards) when reading the pin. Missed edges seem to be buffered, so this does not introduce a race condition. I've also tested this on sun5i-a13 and sun7i-a20 and those do not seem to be affected, the input value representation in the data register does seem to correctly get updated to the actual pin value while in irq mode there. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] GSL1680 on A20
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. Currently I'm booting using a SD card with Cubian http://cubian.org (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 http://linux-sunxi.org/Touchscreen#FT5x06). 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 : [c007f130]lr : [c007f148]psr: 2013 [ 128.640262] sp : eeaf9eb8 ip : fp : bf0f0534 [ 128.644299] r10: r9 : c0acc658 r8 : c0acbac8 [ 128.649592] r7 : bf0f0530 r6 : c078ba34 r5 : r4 : c0acc374 [ 128.654884] r3 : 12d51000 r2 : 12d51000 r1 : 0002 r0 : [ 128.660780] Flags: nzCv IRQs on FIQs on
Re: [linux-sunxi] Derailed thread
On 11 Mar 2015 19:03, Henrik Nordström hen...@henriknordstrom.net wrote: ons 2015-03-11 klockan 08:39 +0100 skrev Benjamin Henrion: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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. Which was one of my concerns back at the start of this saga. If the author of the LGPL code the binary is claimed to infringe on says it does not then there is no case. That doesn't mean we can't do the analysis for them. Thanks, 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.
OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion zoo...@gmail.com wrote: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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). 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.
[linux-sunxi] Re: [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
On Wed, Mar 11, 2015 at 11:11:49AM +0800, Chen-Yu Tsai wrote: On Wed, Mar 11, 2015 at 5:32 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO. The IC also takes a power enable signal via GPIO. This is supported with the new power sequencing bindings. The WiFi module supports out-of-band interrupt signaling via GPIO, but this is buggy and not enabled yet. Signed-off-by: Chen-Yu Tsai w...@csie.org There's two almost identical patches 12/12. Which one am I suppose to apply? This one is the right one. I forgot to clear the patches after changing the description. The buggy part in the description is probably not needed. Hans explained that the SD resets have nothing to do with interrupt handling. Just to be clear, you want the last sentence to be: The WiFi module supports out-of-band interrupt signaling via GPIO, but this is not enabled yet. Right? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
On Wed, Mar 11, 2015 at 4:52 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Wed, Mar 11, 2015 at 11:11:49AM +0800, Chen-Yu Tsai wrote: On Wed, Mar 11, 2015 at 5:32 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO. The IC also takes a power enable signal via GPIO. This is supported with the new power sequencing bindings. The WiFi module supports out-of-band interrupt signaling via GPIO, but this is buggy and not enabled yet. Signed-off-by: Chen-Yu Tsai w...@csie.org There's two almost identical patches 12/12. Which one am I suppose to apply? This one is the right one. I forgot to clear the patches after changing the description. The buggy part in the description is probably not needed. Hans explained that the SD resets have nothing to do with interrupt handling. Just to be clear, you want the last sentence to be: The WiFi module supports out-of-band interrupt signaling via GPIO, but this is not enabled yet. Right? That's right. Thanks. ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
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 phy API seems to not have any bus specific methods, I
know that
in the long run people want to get rid of struct usb_phy, so maybe we should
consider
adding bus specific methods to
Re: [linux-sunxi] Derailed thread
ons 2015-03-11 klockan 08:39 +0100 skrev Benjamin Henrion: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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. If the author of the LGPL code the binary is claimed to infringe on says it does not then there is no case. Regards Henrik -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On Wednesday 11 March 2015 06:33 PM, Hans de Goede wrote:
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
Re: OFFTOPIC: Re: [linux-sunxi] Derailed thread
Hi Simos, On Wed, Mar 11, 2015 at 10:34 PM, Simos Xenitellis simos.li...@googlemail.com wrote: On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion zoo...@gmail.com wrote: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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). Are you referring to Ben's short reply or are you implying that Allwinner follows that code? If it's the former, he probably could have better articulated his comments, if it's the latter, then I believe that not violating the (L)GPL would be considered a violation of that code. Either way, I'll rephrase his comment: In my experience, from what I've seen when other projects have had to deal with license violations, the company accused of violating the license will expend the smallest amount of time and effort required to deal with the accusations. In general, when binary files containing strings referring to some project that is licensed in a manner requiring the release of source code have been released without source code, companies generally fix the situation by removing or replacing the strings instead of rewriting the component or releasing the source code. Or to put it another way, I highly doubt that Allwinner's programmers have rewritten the code they were using from ffmpeg in a non-license-violating manner that quickly. Given Allwinner's previous behaviour (embedding LGPL code in closed source binaries), I highly doubt that anyone here will be satisfied with any solution Allwinner produces that isn't the release of the complete source code licensed under an applicable license. 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.
Re: [linux-sunxi] [PATCH] sun6i: Add support for the Mixtile LOFT-Q board
Hi, On 11-03-15 05:50, Phil Han wrote: From: Han Pengfei pengp...@sina.com The Mixtile LOFT-Q is an A31 based board with 2G RAM, 8G EMMC, sdio wifi, 1Gbit ethernet, HDMI display, toslink audio plug, 4 USB2.0 port, external USB2SATA connector, sd card plug, 3x60 external fpic expansion connector, NXP JN5168 zigbee gw, remote support. Also see http://focalcrest.com/en/pc.html#pro02 Can you please send a new version of of this patch which also adds an entry to board/sunxi/MAINTAINERS for this board, and sign off the patch by adding: Signed-off-by: Han Pengfei pengp...@sina.com At the end of the commit message ? Thanks, Hans --- configs/mixtile_loftq_defconfig | 17 + 1 file changed, 17 insertions(+) create mode 100644 configs/mixtile_loftq_defconfig diff --git a/configs/mixtile_loftq_defconfig b/configs/mixtile_loftq_defconfig new file mode 100644 index 000..7d4229b --- /dev/null +++ b/configs/mixtile_loftq_defconfig @@ -0,0 +1,17 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPA(21) +CONFIG_MACH_TYPE=3892 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_MIXTILE_LOFTQ=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=251 ++S:CONFIG_MMC_SUNXI_SLOT=0 ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=PH24 +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN= -- 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 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 phy API seems to not have any bus specific methods, I
know that
Re: [linux-sunxi] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Hi Jens,
On Thu, Mar 12, 2015 at 12:49 AM, Jens Thiele ka...@karme.de wrote:
Julian Calaby julian.cal...@gmail.com 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).
I'm a noob when it comes to device tree too, however apart from a
couple of points which I'll detail inline below, it looks good to me.
I'd recommend you post it as a [RFC] patch.
Thanks,
Julian Calaby
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?
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.
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.
/*
-* 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.
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] Re: [PATCH v5 12/12] ARM: dts: sun6i: hummingbird: Enable the onboard WiFi module
On Wed, Mar 11, 2015 at 05:08:08PM +0800, Chen-Yu Tsai wrote: On Wed, Mar 11, 2015 at 4:52 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Wed, Mar 11, 2015 at 11:11:49AM +0800, Chen-Yu Tsai wrote: On Wed, Mar 11, 2015 at 5:32 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Tue, Mar 10, 2015 at 07:59:24PM +0800, Chen-Yu Tsai wrote: The Hummingbird A31 has an AMPAK AP6210 WiFi+Bluetooth module. The WiFi part is a BCM43362 IC connected to MMC1 in the A31 SoC via SDIO. The IC also takes a power enable signal via GPIO. This is supported with the new power sequencing bindings. The WiFi module supports out-of-band interrupt signaling via GPIO, but this is buggy and not enabled yet. Signed-off-by: Chen-Yu Tsai w...@csie.org There's two almost identical patches 12/12. Which one am I suppose to apply? This one is the right one. I forgot to clear the patches after changing the description. The buggy part in the description is probably not needed. Hans explained that the SD resets have nothing to do with interrupt handling. Just to be clear, you want the last sentence to be: The WiFi module supports out-of-band interrupt signaling via GPIO, but this is not enabled yet. Right? That's right. Thanks. Ack. I just applied it without the buggy mention. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 02/15] phy-sun4i-usb: Add a helper function to update the iscr register
Hi,
On 11-03-15 14:07, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 11 March 2015 06:33 PM, Hans de Goede wrote:
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
Re: [linux-sunxi] fyi: sun4i-ts, TP_SENSITIVE_ADJUST
Julian Calaby julian.cal...@gmail.com 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.
Re: [linux-sunxi] Re: [PATCH] ARM: sun6i: dt: Add new Mele I7 device
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. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: OFFTOPIC: Re: [linux-sunxi] Derailed thread
On Wed, Mar 11, 2015 at 12:34 PM, Simos Xenitellis simos.li...@googlemail.com wrote: On Wed, Mar 11, 2015 at 9:39 AM, Benjamin Henrion zoo...@gmail.com wrote: On Tuesday, March 10, 2015, Quink wantl...@gmail.com 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. 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 bhenrion at ffii.org 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.
[linux-sunxi] [PATCH] sun6i: Add support for the Mixtile LOFT-Q board
From: Han Pengfei pengp...@sina.com The Mixtile LOFT-Q is an A31 based board with 2G RAM, 8G EMMC, sdio wifi, 1Gbit ethernet, HDMI display, toslink audio plug, 4 USB2.0 port, external USB2SATA connector, sd card plug, 3x60 external fpic expansion connector, NXP JN5168 zigbee gw, remote support. Also see http://focalcrest.com/en/pc.html#pro02 Signed-off-by: Han Pengfei pengp...@sina.com --- board/sunxi/MAINTAINERS | 5 + configs/mixtile_loftq_defconfig | 16 2 files changed, 21 insertions(+) create mode 100644 configs/mixtile_loftq_defconfig diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS index ef3c937..90a634e 100644 --- a/board/sunxi/MAINTAINERS +++ b/board/sunxi/MAINTAINERS @@ -143,3 +143,8 @@ WEXLER-TAB7200 BOARD M: Aleksei Mamlin mamli...@gmail.com S: Maintained F: configs/Wexler_TAB7200_defconfig + +MIXTILE-LOFTQ BOARD +M: Phil Han pengp...@sina.com +S: Maintained +F: configs/mixtile_loftq_defconfig diff --git a/configs/mixtile_loftq_defconfig b/configs/mixtile_loftq_defconfig new file mode 100644 index 000..94ebdc8 --- /dev/null +++ b/configs/mixtile_loftq_defconfig @@ -0,0 +1,16 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI,SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPA(21) ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN6I=y ++S:CONFIG_TARGET_MIXTILE_LOFTQ=y ++S:CONFIG_DRAM_CLK=312 ++S:CONFIG_DRAM_ZQ=251 ++S:CONFIG_MMC_SUNXI_SLOT=0 ++S:CONFIG_MMC_SUNXI_SLOT_EXTRA=2 +# Wifi power ++S:CONFIG_AXP221_ALDO1_VOLT=3300 +# Vbus gpio for usb1 ++S:CONFIG_USB1_VBUS_PIN=PH24 +# No Vbus gpio for usb2 ++S:CONFIG_USB2_VBUS_PIN= -- 1.9.1 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
