Re: [linux-sunxi] AXP209 problems
Hi and thanks for quick reply, I have both the chinese (translated) and english (original) versions of AXP209 datasheet (English version is quite new linux-sunxi.org/File:AXP209_Datasheet_v1.0en.pdf), and I can't find this feature anywhere. I would have thought that this would be avoided if bit3 of register 0x36 (PEK Key parameter settings) is set to '0' (no automatic shutdown). However this only disables the max. 6sec timer. This hard 16sec timer I could not find anywhere. Could you please give me a page number/paragraph where this is written? I need it to justify the workaround that I'm implementing. Furthermore, I thought that actually these Force Power Off features are configurable to some extent and mostly done externally with WD or discrete timers - I wouldn't expect them to be inside the PMIC completely hard-coded and seemingly undocumented. As I said, I've disabled all the timers and all the interrupts are masked - I've also read the datasheet cover to cover and I can't find this information that you say it's there. Chapter 9.1, where Shutdown Control is discussed, mentions 5 ways that lead to system shutdown, none of which implying any hard timers... Cheers! Ivan On Wednesday, June 24, 2015 at 5:34:30 PM UTC+2, Chen-Yu Tsai wrote: Hi, On Wed, Jun 24, 2015 at 11:24 PM, Ivan Kozic jimm...@gmail.com javascript: wrote: Hi all, Maybe it's not really the right place to ask, but since there has been a lot of patches for AXP209 lately, maybe someone knows... It is regarding PEK button - it seems to have some kind of timer for shutdown/restart which is not documented. I have turned off all the shutdown timers (like register 0x36) and also masked all the interrupt registers (0x40..0x44). However, holding the PEK button longer than 16 seconds will always restart the system. This seems to be either a HW bug or an undocumented feature, as I can't find anything relating to it in the datasheet. Does anyone know why this is happening? This is a properly documented (if you can read Chinese) feature in the datasheet. Just think of it as a force power off. The other options for tablets is to yank out the battery... Same thing happens on your PC or laptop. Hold the power button for more than 4 seconds (?) and it powers off. ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Further Allwinner misbehaviour.
Hello, On 25 June 2015 at 11:56, 'Simos Xenitellis' via linux-sunxi linux-sunxi@googlegroups.com wrote: The way I see the whole situation is this: It is true that Allwinner did not make effort over the years for mainline Linux kernel support. Whatever support is there for the A10, A13, A20, etc, is the result of the hard work of this community. Working on mainline support is initially expensive in terms of resources but builds an ecosystem and opens up markets. It makes business sense. As a community, we need to figure out what we need from Allwinner. Do we need specific SoC information so that we do the mainline effort on our own? And among all things that can be asked, we prioritize to those that are really needed at the moment. Do we need Allwinner to fund some developers so that they work full-time on this? We would need to start talking about goals and targets. The goal in general is to get enough information and/or opensource properly licensed code to run GNU/Linux and *BSD on the allwinner SoCs with full feature support on current and future versions of these systems. Given that we have reverse-engineered documentation for Cedar there is really not much technical benefit in Allwinner releasing the Cedar driver source with proper licensing so it can be reused as-is. It might be mere convenience to reuse some of the code. On the other hand, given the documentation exists there is little reason for Allwinner to pretend there are secrets protected by not releasing the code. There is also legal obligation to release the source of the binaries of ffmepg which is (L)GPL even after adding the proprietary bits. That said the ffmpeg author(s) do not seem to press the legal issue. Overall the Cedar discussion is pretty much pointless. It only restarts for no good when somebody (from Allwinner or otherwise) points at the repo and says Look, allwinner released the Cedar sources and then there is half of the implementation or binary blob. So to say it clearly: To fulfill the legal obligations to the letter allwinner has to release the full source under (L)GPL compatible license of all the Cedar codec binaries it released in the past since it has been pointed out that these binaries contain substantial portions of ffmpeg which is (L)GPL licensed. Using (L)GPL code brings this obligation. To fulfill the obligation in spirit without possibly infringing on license of some third party proprietary modules linked into said ffmpeg binaries Allwinner could release an alternative fully opensource and (L)GPL compatible codec implementing all the features of those binaries. Given that this isn't really needed for the goal of getting full support for Allwinner SoCs I personally do not really care if such thing happens or not. It might change for future revisions of the codec with new features, though. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Problem with HDMI on Olinuxino A10-LIME
Hi, i followed this guide: https://eewiki.net/display/linuxonarm/A10-OLinuXino-LIME and i created an SD CARD with Debian 8. Then i installed XFCE 4 as minimal Desktop Linux. I was able to make it all work, but i hasn't audio on HDMI. What is the problem? Can someone help me, please? -- 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 1/4] ARM: dts: sunxi: Add regulator-boot-on to usb host port regulator nodes
On Tue, Jun 23, 2015 at 10:19:10AM +0200, Hans de Goede wrote: Hi, On 23-06-15 09:16, Maxime Ripard wrote: On Mon, Jun 22, 2015 at 10:28:16AM +0200, Hans de Goede wrote: Hi, On 22-06-15 02:30, Julian Calaby wrote: Hi Hans, On Sun, Jun 21, 2015 at 1:40 AM, Hans de Goede hdego...@redhat.com wrote: u-boot will have turned on the power to the usb host ports, so mark them as regulator-boot-on, this stops the power on the ports from temporarily getting turned off during boot, causing issues with e.g. usb powered harddisks. Stupid question: shouldn't u-boot set this property? We could make u-boot set this property but that will require a lot of code on u-boot's side which is simply not there atm. And traditionally this property is is simply a part of the dts files as shipped with the kernel. What happens if the property is set but the regulator is not actually enabled? Then its gets enabled when the regulator loads, so assuming that the usb driver is enabled in the kernel config 0.5 (built-in) - 3 (module) seconds earlier then it otherwise would. Ok, perfect then. This is not a problem since usb-ports are normally always powered anyways That might be true using mainline u-boot, but might not be on other bootloaders, hence why I asked that. 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] [PATCH] Remove deprecated symbol from defconfig files
This patch is to re-apply the changes from https://groups.google.com/forum/#!topic/linux-sunxi/Hhx2CR2YWhI It removes the deprecated/obsolete symbol CONFIG_POWER_RESET_SUN6I from multi_v7_defconfig and sunxi_defconfig in arch/arm/configs/. mripard's tree incorporated the changes, but they somehow didn't make it upstream. The symbol is still present as of v4.1. Signed-off-by: Bernhard Nortmann bernhard.nortm...@web.de --- arch/arm/configs/multi_v7_defconfig | 1 - arch/arm/configs/sunxi_defconfig| 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index fbbb191..0d686b1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -322,7 +322,6 @@ CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y CONFIG_POWER_RESET_GPIO_RESTART=y CONFIG_POWER_RESET_KEYSTONE=y -CONFIG_POWER_RESET_SUN6I=y CONFIG_POWER_RESET_RMOBILE=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 8ecba00..2c7af0a 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -77,7 +77,6 @@ CONFIG_SPI_SUN6I=y CONFIG_GPIO_SYSFS=y CONFIG_POWER_SUPPLY=y CONFIG_POWER_RESET=y -CONFIG_POWER_RESET_SUN6I=y CONFIG_THERMAL=y CONFIG_CPU_THERMAL=y CONFIG_WATCHDOG=y -- 2.0.5 -- 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] Problem with HDMI on Olinuxino A10-LIME
On Thu, Jun 25, 2015 at 8:24 AM, Daniele Belmonti daniele.belmo...@gmail.com wrote: Hi, i followed this guide: https://eewiki.net/display/linuxonarm/A10-OLinuXino-LIME and i created an SD CARD with Debian 8. Then i installed XFCE 4 as minimal Desktop Linux. I was able to make it all work, but i hasn't audio on HDMI. What is the problem? Can someone help me, please? Daniele, Audio is still on the todo for mainline: https://linux-sunxi.org/Linux_mainlining_effort#Difficult_Tasks Regards, -- Robert Nelson https://rcn-ee.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] Re: [PATCH V4 2/2] devicetree: Add msi to the vendor-prefix list
On Tue, Jun 23, 2015 at 07:02:29PM +0200, Karsten Merker wrote: Document the the msi (Micro-Star International Co. Ltd.) vendor prefix which is used in sun6i-a31s-primo81.dts. Signed-off-by: Karsten Merker mer...@debian.org Applied, 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 V4 1/2] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
On Tue, Jun 23, 2015 at 07:02:28PM +0200, Karsten Merker wrote: The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND, 1024x768 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer and rtl8188etv usb wifi. Has power, volume+ and volume- buttons (both volume buttons are also connected to the UBOOT_SEL pin). The external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB OTG and 3.5mm headphone jack. More details are available at http://linux-sunxi.org/MSI_Primo81 This initial dts file only provides support for mmc, wifi and uart (there is no external connector for uart though). Graphics can be used via simplefb. However, without usb otg, there are no reasonable means to handle user input yet. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Signed-off-by: Karsten Merker mer...@debian.org --- Changelog: Version 1 = - Original patch by Siarhei Siamashka Version 2 = - Use symbolic instead of numeric pinctrl values. - Change the include syntax from /include/ to #include to make the dts build with current kernels. Version 3 = - Use labels for nodes with modifications in relation to the dtsi instead of replicating the tree structure. - Remove the FSF address from the license header as done in http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/340437.html for the other dts files to remove a checkpatch warning. - Add msi to the vendor prefix list. - Remove earlyprintk from the default kernel commandline. - Replace the console kernel commandline parameter by a /chosen/stdout-path node and add an alias serial0 - uart0. Version 4 = - Split out the vendor prefix documentation into a separate patch. - Add a comment regarding the uart0 accessibility to the corresponding entry in the dts. arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/sun6i-a31s-primo81.dts | 103 +++ 2 files changed, 105 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 867e6e3..31686c7 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -552,7 +552,8 @@ dtb-$(CONFIG_MACH_SUN6I) += \ sun6i-a31-i7.dtb \ sun6i-a31-m9.dtb \ sun6i-a31-mele-a1000g-quad.dtb \ - sun6i-a31s-cs908.dtb + sun6i-a31s-cs908.dtb \ + sun6i-a31s-primo81.dtb dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-bananapi.dtb \ sun7i-a20-bananapro.dtb \ diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts new file mode 100644 index 000..bd15ee1 --- /dev/null +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts @@ -0,0 +1,103 @@ +/* + * Copyright 2014 Siarhei Siamashka siarhei.siamas...@gmail.com + * Copyright 2015 Karsten Merker mer...@debian.org + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the Software), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
[linux-sunxi] Re: [PATCH 0/4] ARM: dts: sunxi: Enable otg on more boards
On Sat, Jun 20, 2015 at 05:40:06PM +0200, Hans de Goede wrote: Hi Maxime, Here is a dts series with 1 fix + 3 patches enabling otg on more boards, this applies on top of my previous dts otg work. Merged all 4, 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
Re: [linux-sunxi] Further Allwinner misbehaviour.
Let's dissect. On Wed, Jun 24, 2015 at 11:56 PM, Andrés Domínguez andres...@gmail.com wrote: 2015-06-24 21:25 GMT+02:00 Simos Xenitellis simos.li...@googlemail.com: If something needs to get fixed in those repositories (https://github.com/allwinner-zh/), point it out constructively. Sorry, I didn't make the infringement statement and I don't know about it, but knowing about allwinner's past behavior and libv it's clear that it has some credibility. Here you say it's clear for a reference to _past behaviour_, while a more appropriate wording would be I assume. You *assume* it has some credibility. You also use the term past behavior, which is a term that probably means a different thing to each recipient of these emails. It is not constructive to use such terms; in those TV shows that depict family problems, you get to see family members picking on each other for things that happened in the past, remaining stuck perpetually for that other thing in the past. What I criticized was your non constructive attitude with libv just because you don't like their way to say things, instead of explaining why do you think that you are right and others are wrong. My point has been that if there are things in the repository that should be fixed, then point them out and explain them. And no, saying that header files are easy to fix (it seems that you don't understand that changing license text is not enough, but also fulfilling with the LGPL conditions, like releasing source code) don't matter in this topic. About Such cases occur frequently with many companies (I doubt it) is sad if true. Let's see a recent case. It's about the MediaTek kernel for the bq E4.5 phone Ubuntu Edition, and the post was written by Carsten Munk, http://mer-project.blogspot.gr/2015/03/some-doubts-about-gpl-licensing-and-bq.html Phoronix covered it with style, https://www.phoronix.com/scan.php?page=news_itempx=BQ-Ubuntu-Phone-Bad-Kernel It was about header files and here is the commit that fixed it, https://github.com/bq/aquaris-E4.5/commit/34cf494bca625acad06274c3cba10aca148813c0 The way I see the whole situation is this: It is true that Allwinner did not make effort over the years for mainline Linux kernel support. Whatever support is there for the A10, A13, A20, etc, is the result of the hard work of this community. Working on mainline support is initially expensive in terms of resources but builds an ecosystem and opens up markets. It makes business sense. As a community, we need to figure out what we need from Allwinner. Do we need specific SoC information so that we do the mainline effort on our own? And among all things that can be asked, we prioritize to those that are really needed at the moment. Do we need Allwinner to fund some developers so that they work full-time on this? We would need to start talking about goals and targets. 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: [linux-sunxi] Further Allwinner misbehaviour.
On Thu, Jun 25, 2015 at 12:56:37PM +0300, 'Simos Xenitellis' via linux-sunxi wrote: My point has been that if there are things in the repository that should be fixed, then point them out and explain them. The bad copyright headers is just stupidity. The direct loading of non-LGPLed binaries into LGPLed code is very deliberate. We could very well push for a full and complete release of the original code, and get Allwinner in even more legal trouble with other parties. Or, and this is, or was if allwinner keeps this bullshit up, clearly what i was aiming for, Allwinner plays nice and releases _everything_ in freshly written code which does not violate the IP/copyright of non-open source participants. Allwinner clearly does not want to go there, so perhaps we should go do what we legally can do. The way I see the whole situation is this: It is true that Allwinner did not make effort over the years for mainline Linux kernel support. Whatever support is there for the A10, A13, A20, etc, is the result of the hard work of this community. Working on mainline support is initially expensive in terms of resources but builds an ecosystem and opens up markets. It makes business sense. As a community, we need to figure out what we need from Allwinner. Do we need specific SoC information so that we do the mainline effort on our own? And among all things that can be asked, we prioritize to those that are really needed at the moment. Do we need Allwinner to fund some developers so that they work full-time on this? We would need to start talking about goals and targets. Stop it, you are just stalling. Allwinner knows what we want, but it very clearly does not want to give it. Let me quote a recent comment on phoronix: But to find people accusing phoronix of copy-paste journalism (which as far as I know would be no crime) and at the same time justifying a multimillion company for taking the work of others and infringing the law is astonishing. So big companies must be prompty excused and gently persuaded that obeying the law is good for them so that they maybe can find a way to further their profits even without selling other people's (companies and volunteers) works without their consent, but a website must be required to excel in journalistic fact-checking and never blow the whistle? What's next ? Are they going to arrest me for public disorder if I cry thief! at someone running away with my wallet ? Someone which of course has a different enterpreneurship culture, faces neck-breaking competition and tries hard to improve best practices in his pickpocketing cutting edge innovation, so should be invited to tea in a cozy lobby at his earliest convenience and nicely begged (again) asking to maybe please return the wallet or at least some documents there when he can spare a little moment and kindly get his busy fingers to it. Simos, you are not in any way credible. You very one-sidedly chose Allwinners side, and have always downplayed allwinners legal obligations. Whatever Allwinner has promised you or is paying you, it is being wasted, as very few people take you seriously. You are noise, and are wasting a lot of our time in the process, and on top of that giving Allwinner false ideas of what they could potentially get away with. 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 1/3] mfd: ax20x: Add axp152 support
On Tue, 23 Jun 2015, Hans de Goede wrote:
From: Michal Suchanek hramr...@gmail.com
The axp152 is a stripped down version of the axp202 pmic with the battery
charging function removed as it is intended for top-set boxes.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 4 +-
This should be in a separate patch.
drivers/mfd/axp20x.c | 92
include/linux/mfd/axp20x.h | 61 +++-
3 files changed, 155 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 753f14f..4181122 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -1,12 +1,14 @@
AXP family PMIC device tree bindings
The axp20x family current members :
+axp152 (X-Powers)
axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
Required properties:
-- compatible: x-powers,axp202, x-powers,axp209, x-powers,axp221
+- compatible: x-powers,axp152, x-powers,axp202, x-powers,axp209,
+ x-powers,axp221
- reg: The I2C slave address for the AXP chip
- interrupt-parent: The parent interrupt controller
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
For this patch, when it is separated out:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index ca4a604..49bba28 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -30,12 +30,34 @@
#define AXP20X_OFF 0x80
static const char * const axp20x_model_names[] = {
+ AXP152,
AXP202,
AXP209,
AXP221,
AXP288,
};
+static const struct regmap_range axp152_writeable_ranges[] = {
+ regmap_reg_range(AXP152_LDO3456_DC1234_CTRL, AXP152_IRQ3_STATE),
+ regmap_reg_range(AXP152_DCDC_MODE, AXP152_PWM1_DUTY_CYCLE),
+};
+
+static const struct regmap_range axp152_volatile_ranges[] = {
+ regmap_reg_range(AXP152_PWR_OP_MODE, AXP152_PWR_OP_MODE),
+ regmap_reg_range(AXP152_IRQ1_EN, AXP152_IRQ3_STATE),
+ regmap_reg_range(AXP152_GPIO_INPUT, AXP152_GPIO_INPUT),
+};
+
+static const struct regmap_access_table axp152_writeable_table = {
+ .yes_ranges = axp152_writeable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp152_writeable_ranges),
+};
+
+static const struct regmap_access_table axp152_volatile_table = {
+ .yes_ranges = axp152_volatile_ranges,
+ .n_yes_ranges = ARRAY_SIZE(axp152_volatile_ranges),
+};
+
static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
@@ -99,6 +121,20 @@ static const struct regmap_access_table
axp288_volatile_table = {
.n_yes_ranges = ARRAY_SIZE(axp288_volatile_ranges),
};
+static struct resource axp152_pek_resources[] = {
+ {
+ .name = PEK_DBR,
+ .start = AXP152_IRQ_PEK_RIS_EDGE,
+ .end= AXP152_IRQ_PEK_RIS_EDGE,
+ .flags = IORESOURCE_IRQ,
+ }, {
+ .name = PEK_DBF,
+ .start = AXP152_IRQ_PEK_FAL_EDGE,
+ .end= AXP152_IRQ_PEK_FAL_EDGE,
+ .flags = IORESOURCE_IRQ,
+ },
+};
DEFINE_RES_*()
After you've fixed this up, please add my:
Acked-by: Lee Jones lee.jo...@linaro.org
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] Further Allwinner misbehaviour.
Hi Simos, On Thu, Jun 25, 2015 at 7:56 PM, 'Simos Xenitellis' via linux-sunxi linux-sunxi@googlegroups.com wrote: Let's dissect. Yes, let's dissect. On Wed, Jun 24, 2015 at 11:56 PM, Andrés Domínguez andres...@gmail.com wrote: 2015-06-24 21:25 GMT+02:00 Simos Xenitellis simos.li...@googlemail.com: If something needs to get fixed in those repositories (https://github.com/allwinner-zh/), point it out constructively. Sorry, I didn't make the infringement statement and I don't know about it, but knowing about allwinner's past behavior and libv it's clear that it has some credibility. Here you say it's clear for a reference to _past behaviour_, while a more appropriate wording would be I assume. You *assume* it has some credibility. Allwinner's past behaviour is very clear. They release stuff without checking that it complies with the license they release it under then appear to ignore it (or at least don't communicate) when the community, us, rightly complains. As for libv, arguably he's just the messenger here, the person who shouts the loudest about this. The fact that he keeps shouting this message when things don't change is commendable. And you know what, he's right: GPL violations are serious business and ignoring them is simply not a viable strategy for anyone involved. Luc has been consistently right on this subject from the very beginning, that's credibility. You also use the term past behavior, which is a term that probably means a different thing to each recipient of these emails. It is not constructive to use such terms; in those TV shows that depict family problems, you get to see family members picking on each other for things that happened in the past, remaining stuck perpetually for that other thing in the past. I outlined the behaviour I, and a lot of other people, perceive from companies like Allwinner in my previous email. Again, it's very clear. Are you saying that we shouldn't argue about serious legal issues because they happened in the past? Yet you attack Luc for the things he's done in the past. What exactly are you trying to argue here? So maybe you're trying to argue that we should focus less on the past and more on the future. Focusing less on the past isn't going to happen. These are, again, serious legal issues, they're not going to just go away. As for focusing on the future, we've made it very clear what we want from Allwinner: (L)GPL compliant code to replace the binary blobs they keep releasing. Very simple. What I criticized was your non constructive attitude with libv just because you don't like their way to say things, instead of explaining why do you think that you are right and others are wrong. My point has been that if there are things in the repository that should be fixed, then point them out and explain them. This isn't just about some little changes in a repository. This is about a systematic company practice of violating the licence agreements the software their continued existence is built on. As far as I know, every single SoC they've produced since the A10 has had GPL issues. _Every_ one. There's a saying: Once is happenstance. Twice is coincidence. The third time it's enemy action. We've seen this happen for ~9 different products. This is not a coincidence any more. And no, saying that header files are easy to fix (it seems that you don't understand that changing license text is not enough, but also fulfilling with the LGPL conditions, like releasing source code) don't matter in this topic. About Such cases occur frequently with many companies (I doubt it) is sad if true. Let's see a recent case. It's about the MediaTek kernel for the bq E4.5 phone Ubuntu Edition, and the post was written by Carsten Munk, http://mer-project.blogspot.gr/2015/03/some-doubts-about-gpl-licensing-and-bq.html Phoronix covered it with style, https://www.phoronix.com/scan.php?page=news_itempx=BQ-Ubuntu-Phone-Bad-Kernel It was about header files and here is the commit that fixed it, https://github.com/bq/aquaris-E4.5/commit/34cf494bca625acad06274c3cba10aca148813c0 You're missing the forest for the trees: the point is that code with proprietary licenses shouldn't have been released in the first place. It might be easy to change, the point was that the change didn't happen before it left their hands. In the case of the BQ Ubuntu phone issue, a company released thousands of lines of code and got a couple of bits wrong. In our case we're looking at a source release that touched 29 files. 9 were added with unusable headers: that's 1/3 of the files they touched and almost 70% of the code they released. This sort of thing doesn't happen by accident. This was deliberate. Also, it was almost a week ago, if it's such a small change, why hasn't it been made? The way I see the whole situation is this: It is true that Allwinner did not make effort over the years for mainline Linux kernel support. Whatever support is there
Re: [linux-sunxi] Problem with HDMI on Olinuxino A10-LIME
Thank you Robert, thus i wait the updates. Meanwhile, i bought a USB soundcard with analog output. Regards Il giorno giovedì 25 giugno 2015 15:47:41 UTC+2, Robert Nelson ha scritto: On Thu, Jun 25, 2015 at 8:24 AM, Daniele Belmonti daniele@gmail.com javascript: wrote: Hi, i followed this guide: https://eewiki.net/display/linuxonarm/A10-OLinuXino-LIME and i created an SD CARD with Debian 8. Then i installed XFCE 4 as minimal Desktop Linux. I was able to make it all work, but i hasn't audio on HDMI. What is the problem? Can someone help me, please? Daniele, Audio is still on the todo for mainline: https://linux-sunxi.org/Linux_mainlining_effort#Difficult_Tasks Regards, -- Robert Nelson https://rcn-ee.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] Re: [PATCH 2/3] ARM: dts: axp152: Add a dtsi file for the axp152 pmic
Hi, On Tue, Jun 23, 2015 at 09:41:42PM +0200, Hans de Goede wrote: From: Michal Suchanek hramr...@gmail.com Add a dtsi file for the axp152 pmic, this mirrors the way things are handled for the axp202 pmic. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/boot/dts/axp152.dtsi | 49 +++ 1 file changed, 49 insertions(+) create mode 100644 arch/arm/boot/dts/axp152.dtsi Unfortunately, Mark expressed clearly that he didn't want such files. Sorry... 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: [linux-sunxi] openwrt finally released for sunxi
On Wed, 2015-06-24 at 21:46 +0300, Dmitriy B. wrote: 2015-05-25 10:54 GMT+03:00 Benjamin Henrion zoo...@gmail.com: Openwrt is finally released for sunxi: https://downloads.openwrt.org/chaos_calmer/15.05-rc1/sunxi/generic/ We had to wait because otherwise there were only daily builds available. If you use it, feel free to report bugs. 1) Cubietruck defconfig seems to miss something needed for onboard broadcom to power up. Anyone got success running its wifi? 2) A20 boards device trees seem to include cryptodev, which was proven to have HW bug on all Allwinner SoCs, fixed in A83. grep linux -sunxi mailing list for answers from Kevin in crypto hw acceleration patch threads. Does the version of crypto driver included in openwrt have updated patch? Since we have 3.1x here with patches from 4.x backported, this issue might be easily missed. Only AES/DES/3DES CTR and CTS modes were flawed: https://groups.google.com/forum/#!searchin/linux -sunxi/AES$2FDES$2F3DS$20/linux-sunxi/tIQd4Bpxtzg/Btq0uBBcH48J http://sunxi.montjoie.ovh/#support_overview And the mainlining effort status with links to most of the patches: http://linux-sunxi.org/Mainlining_Effort#Work_In_Progress Päikest, Priit Laes :) -- 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] openwrt finally released for sunxi
2015-06-24 22:31 GMT+03:00 Zoltan HERPAI wigy...@uid0.hu: Dmitriy B. wrote: 2015-05-25 10:54 GMT+03:00 Benjamin Henrion zoo...@gmail.com mailto: zoo...@gmail.com: Openwrt is finally released for sunxi: https://downloads.openwrt.org/chaos_calmer/15.05-rc1/sunxi/generic/ We had to wait because otherwise there were only daily builds available. If you use it, feel free to report bugs. 1) Cubietruck defconfig seems to miss something needed for onboard broadcom to power up. Anyone got success running its wifi? 2) A20 boards device trees seem to include cryptodev, which was proven to have HW bug on all Allwinner SoCs, fixed in A83. grep linux-sunxi mailing list for answers from Kevin in crypto hw acceleration patch threads. Does the version of crypto driver included in openwrt have updated patch? Since we have 3.1x here with patches from 4.x backported, this issue might be easily missed. Apart from Cubietruck, I've got ok results from A10 boards, nothing seriously frustrating, almost everything works out of the git build. Hi Dmitriy, 1) I don't have a cubietruck so this wasn't tested - IIRC it was left off where brcmfmac would've needed the SDIO code built as well. Patches are most welcome. :) If brcmfmac SDIO is selected, driver can see the chip, but can't load the firmware - its missing from openwrt firmware packages. When I added brcmfmac43362-sdio.bin by hand from linux-firmware.git driver couldnt load the firmware, probably missing patches from upstream for brcm43362 support or some sunxi SDIO work from Hans. 2) I'll check this one, can't recall the exact series, probably it was a v4 or a v5, based off the timestamps. The last one I saw around the crypto driver is the v9 patchset, is that the one You're referring to? Yes, see Priit Laes answer. Thanks, Zoltan H Best Regards, Dmitriy Beykun -- 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 v2 3/4] mfd: axp20x: Add a cell for the usb power_supply part of the axp20x PMICs
On Wed, 24 Jun 2015, Hans de Goede wrote:
On 24-06-15 13:23, Lee Jones wrote:
Add a cell for the usb power_supply part of the axp20x PMICs.
Why are you duplicating the subject line?
Heh, because some maintainers insist that the main-body part of the
commit message must stand by itself, without needing the subject to be
understandable...
Some Maintainers are crazy. ;)
Note that this cell is only for the usb power_supply part and not the
ac-power / battery-charger / rtc-backup-bat-charger bits.
Depending on the board each of those must be enabled / disabled separately
in devicetree as most boards do not use all 4. So in dt each one needs its
own child-node of the axp20x node. Another reason for using separate child
nodes for each is so that other devicetree nodes can have a power-supply
property with a phandle referencing a node representing a single
power-supply.
The decision to use a separate devicetree node for each is reflected on
the kernel side by each getting its own mfd-cell / platform_device and
platform-driver.
You don't really need to say any of this, as this is the 'norm'.
I agree it should be the norm, but I'm not sure if it actually is, while
working on this I've seen several drivers which instantiate multiple
power-supply class devices from a single mfd-cell. And this is what
Bruno's original patches did, so I would prefer to keep this
Up to you, but it's really not required. No one else says this stuff.
What you didn't mention however, is that you're taking the opportunity
to fix some formatting issues and that there are no functional changes
in these lines.
That is the end result of your request to change the indentation to
avoid line-wrapping :)
Fine, you can add my Suggested-by too then [don't actually do that],
but regardless of where the idea came from you should still tell us
what the patch does in the commit log. I was looking for functional
differences within those formatting changes. If I wanted to be really
religious about it I would [rightly] say don't mix functional changes
with clean-ups, but instead I'll politely ask for a quick mention in
the commit log when you re-submit. Aren't I nice?! ;)
Cc: Bruno Prémont bonb...@linux-vserver.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Changes in v2:
-Use DEFINE_RES_IRQ_NAMED
-Change indentation of axp20x_cells initializers to avoid line wrapping
---
drivers/mfd/axp20x.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
Patch looks okay however:
Acked-by: Lee Jones lee.jo...@linaro.org
Thanks.
Regards,
Hans
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index f9a3c2d..ca4a604 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -113,6 +113,13 @@ static struct resource axp20x_pek_resources[] = {
},
};
+static struct resource axp20x_usb_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_PLUGIN, VBUS_PLUGIN),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_REMOVAL, VBUS_REMOVAL),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_VALID, VBUS_VALID),
+ DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_VBUS_NOT_VALID, VBUS_NOT_VALID),
+};
+
static struct resource axp22x_pek_resources[] = {
{
.name = PEK_DBR,
@@ -363,11 +370,16 @@ static const struct regmap_irq_chip
axp288_regmap_irq_chip = {
static struct mfd_cell axp20x_cells[] = {
{
- .name = axp20x-pek,
- .num_resources = ARRAY_SIZE(axp20x_pek_resources),
- .resources = axp20x_pek_resources,
+ .name = axp20x-pek,
+ .num_resources = ARRAY_SIZE(axp20x_pek_resources),
+ .resources = axp20x_pek_resources,
}, {
- .name = axp20x-regulator,
+ .name = axp20x-regulator,
+ }, {
+ .name = axp20x-usb-power-supply,
+ .of_compatible = x-powers,axp202-usb-power-supply,
+ .num_resources = ARRAY_SIZE(axp20x_usb_power_supply_resources),
+ .resources = axp20x_usb_power_supply_resources,
},
};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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.
