[linux-sunxi] MIPI CSI capture issues on A31
Hi, We are using A31 based board which is derived from Merrii HummingBird. On this board, we want to get HDMI capture up using TC358743 (HDMI to MIPI CSI2 Bridge IC). This IC interfaces to MIPI CSI port of A31. We have added TC358743 sub-dev driver and it behaves as if CMOS sensor is connected to the A31. Calls which are not applicable are just stubs. Presently, we are not able to get any frames on A31 side. When we checked MIPI DPHY registers, we see that clock and data lanes are active and toggling in LP and HS mode as expected. But MIPI interface is not showing any packet reception. We are more or less sure about TC358743 settings as they have come from vendor. We have also checked all MIPI/CSI settings and they appear to be fine. Since data is being received till DPHY but not in MIPI we are not sure if we are missing any other board specific settings required to get MIPI interface working e.g. PRCM, MIPI peripheral PLL clock, On board PMIC settings, MIPI IO pins enabling etc. If you have any inputs/pointers about the same, please let us know. Also, please let us know if any MIPI sensor is validated with A31. Exact CMOS sensor part number would help. Is MIPI driver (/drivers/media/video/sunxi-vfe/) complete? Is new CMOS sensor expected to work just by hooking new MIPI sub-device? Or some more changes in MIPI driver at other places is needed? We see that in 'bsp_mipi_csi_set_dphy_timing' function of drivers/media/video/sunxi-vfe/bsp_mipi_csi.c file, functions like 'dphy_rx_set_entm_to_enrx_dly' and 'dphy_rx_set_lp_ulps_wp' are configured with some default values. Do they need to be changed depending on frequency, lanes, resolution etc? DPHY_CLK is used in vfe.c and it is hardcoded to 150MHz. Should this be hardcoded or matched with input MIPI clock? Please let us know. Apologies for so many questions. We are new to this platform. Any inputs/pointers will be very helpful. Thanks and regards, Satyajit -- 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] MIPI CSI Issues on A31 | Trying with TC358743 (HDMI to MIPI CSI2 Bridge IC)
Hi, We are using A31 based board which is derived from Merrii HummingBird. On this board, we want to get HDMI capture up using TC358743 (HDMI to MIPI CSI2 Bridge IC). This IC interfaces to MIPI CSI port of A31. We have added TC358743 sub-dev driver and it behaves as if CMOS sensor is connected to the A31. Calls which are not applicable are just stubs. Presently, we are not able to get any frames on A31 side. When we checked MIPI DPHY registers, we see that clock and data lanes are active and toggling in LP and HS mode as expected. But MIPI interface is not showing any packet reception. We are more or less sure about TC358743 settings as they have come from vendor. We have also checked all MIPI/CSI settings and they appear to be fine. Since data is being received till DPHY but not in MIPI we are not sure if we are missing any other board specific settings required to get MIPI interface working e.g. PRCM, MIPI peripheral PLL clock, On board PMIC settings, MIPI IO pins enabling etc. If you have any inputs/pointers about the same, please let us know. Also, please let us know if any MIPI sensor is validated with A31. Exact CMOS sensor part number would help. Is MIPI driver (/drivers/media/video/sunxi-vfe/) complete? Is new CMOS sensor expected to work just by hooking new MIPI sub-device? Or some more changes in MIPI driver at other places is needed? We see that in 'bsp_mipi_csi_set_dphy_timing' function of drivers/media/video/sunxi-vfe/bsp_mipi_csi.c file, functions like 'dphy_rx_set_entm_to_enrx_dly' and 'dphy_rx_set_lp_ulps_wp' are configured with some default values. Do they need to be changed depending on frequency, lanes, resolution etc? DPHY_CLK is used in vfe.c and it is hardcoded to 150MHz. Should this be hardcoded or matched with input MIPI clock? Please let us know. Apologies for so many questions. We are new to this platform. Any inputs/pointers will be very helpful. Thanks and regards, Satyajit -- 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 v6 0/4] musb: sunxi: Add support for the Allwinner sunxi musb
Hi Felipe, As requested here is a new version of my musb: sunxi: Add support for the Allwinner sunxi musb controller patch, fixing the Should it be static? compiler warning. While working on this I noticed that sun4i_usb_phy_set_squelch_detect() from phy-sun4i-usb.c is missing an EXPORT_SYMBOL, something which I did not notice before I was always building both phy-sun4i-usb and musb into the kernel. I've added a patch fixing this, and I'm posting a new version of the entire set including this patch. I believe that like the original patch adding the sun4i_usb_phy_set_squelch_detect function, this patch should go upstream through your (Felipe's) tree as the musb-sunxi patches depend on this. The other oustanding phy-sun4i-usb patches can still go upstream through Kishon's tree, they do not conflict with the small patch fixing the missing EXPORT_SYMBOL. Thanks 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] [PATCH v6 4/4] musb: sunxi: Add support for musb controller in A33 SoC
The A33 SoC uses the same musb controller as found on the A31 and later,
but allwinner has removed the configdata register, this commit adds special
handling for this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt | 3 ++-
drivers/usb/musb/sunxi.c | 15 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index fde180b..862cd7c 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,7 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller
---
Required properties:
- - compatible : allwinner,sun4i-a10-musb or allwinner,sun6i-a31-musb
+ - compatible : allwinner,sun4i-a10-musb, allwinner,sun6i-a31-musb
+ or allwinner,sun8i-a33-musb
- reg : mmio address range of the musb controller
- clocks : clock specifier for the musb controller ahb gate clock
- reset : reset specifier for the ahb reset (A31 and newer only)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index df2f75e..f9f6304 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -73,6 +73,7 @@
#define SUNXI_MUSB_FL_PHY_ON 4
#define SUNXI_MUSB_FL_HAS_SRAM 5
#define SUNXI_MUSB_FL_HAS_RESET6
+#define SUNXI_MUSB_FL_NO_CONFIGDATA7
/* Our read/write methods need access and do not get passed in a musb ref :| */
static struct musb *sunxi_musb;
@@ -370,6 +371,8 @@ static u32 sunxi_musb_busctl_offset(u8 epnum, u16 offset)
static u8 sunxi_musb_readb(const void __iomem *addr, unsigned offset)
{
+ struct sunxi_glue *glue;
+
if (addr == sunxi_musb-mregs) {
/* generic control or fifo control reg access */
switch (offset) {
@@ -392,6 +395,12 @@ static u8 sunxi_musb_readb(const void __iomem *addr,
unsigned offset)
case MUSB_RXFIFOSZ:
return readb(addr + SUNXI_MUSB_RXFIFOSZ);
case MUSB_CONFIGDATA + 0x10: /* See musb_read_configdata() */
+ glue = dev_get_drvdata(sunxi_musb-controller-parent);
+ /* A33 saves a reg, and we get to hardcode this */
+ if (test_bit(SUNXI_MUSB_FL_NO_CONFIGDATA,
+glue-flags))
+ return 0xde;
+
return readb(addr + SUNXI_MUSB_CONFIGDATA);
/* Offset for these is fixed by sunxi_musb_busctl_offset() */
case SUNXI_MUSB_TXFUNCADDR:
@@ -643,6 +652,11 @@ static int sunxi_musb_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, allwinner,sun6i-a31-musb))
set_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags);
+ if (of_device_is_compatible(np, allwinner,sun8i-a33-musb)) {
+ set_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags);
+ set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, glue-flags);
+ }
+
glue-clk = devm_clk_get(pdev-dev, NULL);
if (IS_ERR(glue-clk)) {
dev_err(pdev-dev, Error getting clock: %ld\n,
@@ -723,6 +737,7 @@ static int sunxi_musb_remove(struct platform_device *pdev)
static const struct of_device_id sunxi_musb_match[] = {
{ .compatible = allwinner,sun4i-a10-musb, },
{ .compatible = allwinner,sun6i-a31-musb, },
+ { .compatible = allwinner,sun8i-a33-musb, },
{}
};
--
2.4.3
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v6 3/4] musb: sunxi: Add support for musb controller in A31 SoC
The A31 SoC uses the same musb controller as found in earlier SoCs, but it
is hooked up slightly different. Its SRAM is private and no longer controlled
through the SRAM controller, and its reset is controlled via a separate
reset controller. This commit adds support for this setup.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 3 +-
drivers/usb/musb/sunxi.c | 50 +++---
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index 9254a6c..fde180b 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,9 +2,10 @@ Allwinner sun4i A10 musb DRC/OTG controller
---
Required properties:
- - compatible : allwinner,sun4i-a10-musb
+ - compatible : allwinner,sun4i-a10-musb or allwinner,sun6i-a31-musb
- reg : mmio address range of the musb controller
- clocks : clock specifier for the musb controller ahb gate clock
+ - reset : reset specifier for the ahb reset (A31 and newer only)
- interrupts : interrupt to which the musb controller is connected
- interrupt-names : must be mc
- phys: phy specifier for the otg phy
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 00d7248..df2f75e 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -26,6 +26,7 @@
#include linux/of.h
#include linux/phy/phy-sun4i-usb.h
#include linux/platform_device.h
+#include linux/reset.h
#include linux/soc/sunxi/sunxi_sram.h
#include linux/usb/musb.h
#include linux/usb/of.h
@@ -70,6 +71,8 @@
#define SUNXI_MUSB_FL_HOSTMODE_PEND2
#define SUNXI_MUSB_FL_VBUS_ON 3
#define SUNXI_MUSB_FL_PHY_ON 4
+#define SUNXI_MUSB_FL_HAS_SRAM 5
+#define SUNXI_MUSB_FL_HAS_RESET6
/* Our read/write methods need access and do not get passed in a musb ref :| */
static struct musb *sunxi_musb;
@@ -78,6 +81,7 @@ struct sunxi_glue {
struct device *dev;
struct platform_device *musb;
struct clk *clk;
+ struct reset_control*rst;
struct phy *phy;
struct platform_device *usb_phy;
struct usb_phy *xceiv;
@@ -229,14 +233,22 @@ static int sunxi_musb_init(struct musb *musb)
musb-phy = glue-phy;
musb-xceiv = glue-xceiv;
- ret = sunxi_sram_claim(musb-controller-parent);
- if (ret)
- return ret;
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags)) {
+ ret = sunxi_sram_claim(musb-controller-parent);
+ if (ret)
+ return ret;
+ }
ret = clk_prepare_enable(glue-clk);
if (ret)
goto error_sram_release;
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags)) {
+ ret = reset_control_deassert(glue-rst);
+ if (ret)
+ goto error_clk_disable;
+ }
+
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb-mregs + SUNXI_MUSB_VEND0);
/* Register notifier before calling phy_init() */
@@ -244,7 +256,7 @@ static int sunxi_musb_init(struct musb *musb)
ret = extcon_register_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
if (ret)
- goto error_clk_disable;
+ goto error_reset_assert;
}
ret = phy_init(glue-phy);
@@ -273,10 +285,14 @@ error_unregister_notifier:
if (musb-port_mode == MUSB_PORT_MODE_DUAL_ROLE)
extcon_unregister_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
+error_reset_assert:
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags))
+ reset_control_assert(glue-rst);
error_clk_disable:
clk_disable_unprepare(glue-clk);
error_sram_release:
- sunxi_sram_release(musb-controller-parent);
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags))
+ sunxi_sram_release(musb-controller-parent);
return ret;
}
@@ -296,8 +312,12 @@ static int sunxi_musb_exit(struct musb *musb)
extcon_unregister_notifier(glue-extcon, EXTCON_USB_HOST,
glue-host_nb);
+ if (test_bit(SUNXI_MUSB_FL_HAS_RESET, glue-flags))
+ reset_control_assert(glue-rst);
+
clk_disable_unprepare(glue-clk);
- sunxi_sram_release(musb-controller-parent);
+ if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, glue-flags))
+ sunxi_sram_release(musb-controller-parent);
return 0;
}
@@
[linux-sunxi] [PATCH v6 2/4] musb: sunxi: Add support for the Allwinner sunxi musb controller
This is based on initial code to get the Allwinner sunxi musb controller
supported by Chen-Yu Tsai and Roman Byshko.
This adds support for the Allwinner sunxi musb controller in both host only
and otg mode. Peripheral only mode is not supported, as no boards use that.
This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
(A13 SoC) with a variety of devices in host mode and with the g_serial gadget
driver in peripheral mode, plugging otg / host cables in/out a lot of times
in all possible imaginable plug orders.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Move polling of id and vbus-det gpio-s to the phy driver
-Use extcon to get id (USB_HOST mode) status changes from the phy driver
-Stop using syscon, instead use Maxime Ripard's sunxi SRAM controller driver
Changes in v3:
-Check that USB_MUSB_FOO config is compatible with the dr_mode setting from dt
Changes in v4:
-Squash in musb: sunxi: Add pre/post root reset end platform functions patch
-Adjust for sunxi_sram controller driver changes
-Stop musb work from turning vbus off again when in host mode
Changes in v5:
-Squash in musb: sunxi: Remove special MUSB_SUN4I flag patch, as it was
mostly reverting changes done by this patch
-Adjust for extcon api changes landing in 4.2
Changes in v6:
-Mark private variables and functions static
---
.../bindings/usb/allwinner,sun4i-a10-musb.txt | 27 +
drivers/usb/musb/Kconfig | 13 +-
drivers/usb/musb/Makefile | 1 +
drivers/usb/musb/sunxi.c | 703 +
4 files changed, 743 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
create mode 100644 drivers/usb/musb/sunxi.c
diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
new file mode 100644
index 000..9254a6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -0,0 +1,27 @@
+Allwinner sun4i A10 musb DRC/OTG controller
+---
+
+Required properties:
+ - compatible : allwinner,sun4i-a10-musb
+ - reg : mmio address range of the musb controller
+ - clocks : clock specifier for the musb controller ahb gate clock
+ - interrupts : interrupt to which the musb controller is connected
+ - interrupt-names : must be mc
+ - phys: phy specifier for the otg phy
+ - phy-names : must be usb
+ - dr_mode : Dual-Role mode must be host or otg
+ - extcon : extcon specifier for the otg phy
+
+Example:
+
+ usb_otg: usb@01c13000 {
+ compatible = allwinner,sun4i-a10-musb;
+ reg = 0x01c13000 0x0400;
+ clocks = ahb_gates 0;
+ interrupts = 38;
+ interrupt-names = mc;
+ phys = usbphy 0;
+ phy-names = usb;
+ extcon = usbphy 0;
+ status = disabled;
+ };
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 39db8b6..37081ed 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -5,7 +5,7 @@
# (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
config USB_MUSB_HDRC
- tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
+ tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
depends on (USB || USB_GADGET)
help
Say Y here if your system has a dual role high speed USB
@@ -20,6 +20,8 @@ config USB_MUSB_HDRC
Analog Devices parts using this IP include Blackfin BF54x,
BF525 and BF527.
+ Allwinner SoCs using this IP include A10, A13, A20, ...
+
If you do not know what this is, please say N.
To compile this driver as a module, choose M here; the
@@ -60,6 +62,15 @@ endchoice
comment Platform Glue Layer
+config USB_MUSB_SUNXI
+ tristate Allwinner (sunxi)
+ depends on ARCH_SUNXI
+ depends on NOP_USB_XCEIV
+ depends on PHY_SUN4I_USB
+ depends on EXTCON
+ depends on GENERIC_PHY
+ select SUNXI_SRAM
+
config USB_MUSB_DAVINCI
tristate DaVinci
depends on ARCH_DAVINCI_DMx
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index ba49501..f95befe 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
+obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
new file mode 100644
index
[linux-sunxi] [PATCH v6 1/4] phy-sun4i-usb: Add missing EXPORT_SYMBOL for sun4i_usb_phy_set_squelch_detect
sun4i_usb_phy_set_squelch_detect is used by other code, which may be built
as a module, so it should be exported.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v6:
-New patch in v6 of the sunxi musb support series
---
drivers/phy/phy-sun4i-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e17c539..b82aa26 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -212,6 +212,7 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy,
bool enabled)
sun4i_usb_phy_write(phy, PHY_SQUELCH_DETECT, enabled ? 0 : 2, 2);
}
+EXPORT_SYMBOL(sun4i_usb_phy_set_squelch_detect);
static struct phy_ops sun4i_usb_phy_ops = {
.init = sun4i_usb_phy_init,
--
2.4.3
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] AXP209 : Disable auto start
Hello, I have a question about the AXP209 management over a FEX File. I'm using an A20-OlinuXino-Micro board with a battery connected to it. When I plug in the power source, the board start by itself. I tried to twek the FEX file, but nothing changed. How to disable this behavior ? I have been looking through AXP209 data-sheet http://linux-sunxi.org/images/8/89/AXP209_Datasheet_v1.0en.pdf especially on page 15 where it says Automatic booting on power supply connection can be configured by the developer but I could not find any more information... Any ideas ? Thank -- 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] Your outrageous wiki edits.
On Wed, Jul 8, 2015 at 5:36 PM, Luc Verhaegen l...@skynet.be wrote: Hi Kevin, I just noticed your edits to our GPL violations page. It seems that you and Allwinnwer still have not fully comprehended just how you went wrong and what can be done to fix it. The most remarkable changes (which i have undone) were: a) that since you aren't really using some parts of the code (dram scaling) anymore these days, Allwinner isn't really violating the gpl all that much anymore and then the fact that it once violated the GPL can be totally brushed under the carpet. Allwinner needs to clarify if they own the code in question. If they don't own it, it should be sufficient to state that they have tried and failed to secure a source release. Since getting the source was not possible, rewriting it and releasing it under the GPL should be ok. If you really want to pursue this, then Allwinner can identify the company that won't release the original code and someone can spend the money to take them to court. It is also possible that Allwinner has simply lost the original source. Their version control practices are not very good. I'm still waiting for them to start keeping everything on public git servers. b) the fact that allwinner was not the original violator on some touchscreen drivers, the fact that it was not allwinner that produced those binaries, makes it all totally ok that allwinner shipped those binaries, which in turn makes allwinner definitely not a repeat violator of the gpl, and this bit of history should totally be brushed under the carpet as well. I don't think b) is a GPL violation by Allwinner. Since Allwinner does not possess the source code to these binaries they are unable to determine if they are a derived work or not. This is NVidia's defense in shipping binaries. NVidia claims the binaries are not derived works of the kernel (that they are developed on Windows and then ported with a wrapper layer). Reshipping a non-derived binary is not a GPL violation. That doesn't imply that we have to like this. And I also don't believe that the touchscreen driver is a non-derived work. But that is not Allwinner's problem, it is the developer of the touchscreen driver's problem. Allwinner should exercise its rights under the GPL and request source from the vendor of the touchscreen driver and see what they claim. If they refuse to deliver source maybe Allwinner might want to file a court action to compel its release. But the GPL does not require you to take action. Allwinner should also consider not doing business in the future with vendors that won't supply source. This is parallel to the Mali problem. Mali is clearly in violation of the GPL and there is nothing Allwinner can do except make a GPL request that source code be delivered. The violator is ARM, Inc. WTF? Have you not learned anything, or are you actively playing with us? How many months now have you and the rest of your company had to get up to speed on this topic? What is it that is so difficult here, or why are you trying to play these games still? Also, with changes like this, it would not be wrong for me or others to block your wiki account. Be very careful what future steps you take. In a case like this, it is also seriously not done to execute such controversial edits yourself. You ask someone from the opposite side (like me) or someone totally independent (as in, not one of your pathetic strawmen) to review the current status and validity of the content of such a controversial wiki page. It seems that you and Allwinner haven't learned anything there either. Are the things that i beat into you and allwinner really the only things that stick? 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. -- Jon Smirl jonsm...@gmail.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.
[linux-sunxi] Your outrageous wiki edits.
Hi Kevin, I just noticed your edits to our GPL violations page. It seems that you and Allwinnwer still have not fully comprehended just how you went wrong and what can be done to fix it. The most remarkable changes (which i have undone) were: a) that since you aren't really using some parts of the code (dram scaling) anymore these days, Allwinner isn't really violating the gpl all that much anymore and then the fact that it once violated the GPL can be totally brushed under the carpet. b) the fact that allwinner was not the original violator on some touchscreen drivers, the fact that it was not allwinner that produced those binaries, makes it all totally ok that allwinner shipped those binaries, which in turn makes allwinner definitely not a repeat violator of the gpl, and this bit of history should totally be brushed under the carpet as well. WTF? Have you not learned anything, or are you actively playing with us? How many months now have you and the rest of your company had to get up to speed on this topic? What is it that is so difficult here, or why are you trying to play these games still? Also, with changes like this, it would not be wrong for me or others to block your wiki account. Be very careful what future steps you take. In a case like this, it is also seriously not done to execute such controversial edits yourself. You ask someone from the opposite side (like me) or someone totally independent (as in, not one of your pathetic strawmen) to review the current status and validity of the content of such a controversial wiki page. It seems that you and Allwinner haven't learned anything there either. Are the things that i beat into you and allwinner really the only things that stick? 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.
