Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren wrote: > Note that with device tree things get simpler for muxing as we can > get rid of the hardcoded grouping of pins in mux drivers. Instead of > hardcoded pingroups, the groups can be created dynamically based on > what the driver DT entries have. Yes, I know too little about DT to figure out how these should come in. > The reason why we want to avoid hardcoded pin groups is because trying > to map all the pad combinations in the pinmux driver is not a scalable > way to go. And it's not even possible at least on omaps because of the > huge number of combinations with alternative pins and multiple packages. Yes, that's a solid case! > FYI I'm playing with a DT based pinmux-simple.c driver that should > be pretty generic and work for all kinds of hardware hopefully. I love it. > It will be few days before I can post anything though, there are > some pinctrl fwk issues to deal with first. Like the hardcoded > pinmux_maps that assumes that dev entries are static. This means > that multiple instances of pinmux drivers won't work.. I'm not following, but I guess I will understand when I see the patches. The idea behind the current map concept is that you get either a string or struct device * to identify the pin controller and mapped device, that's as far as I thought it out, sorry for any inherent limitations, they're not intentional... Thanks, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Wed, Nov 23, 2011 at 1:28 AM, Stephen Warren wrote: > Describing the HW doesn't necessarily > mean that each device needs to describe what pinmux pins it uses; one > could quite easily have the pinmux describe what settings the various > pins should have and which drivers will use those pins. That would map > very well to the pinctrl subsystem's mapping table, and at least Tegra's > existing pinmux tables, which are both just a big array of settings which > end up getting provided to drivers. That sounds true. It's also something that is cleanly cut out as a very well defined and abstract piece of hardware information to live in the device tree and which would be useful for any OS using DT. I'd have to see the device trees and corresponding map bindings before I understand it fully though. Just my €0.01 Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Build instructions for directfb-1.6.0pre1-2011.11 ?
I just downloaded directfb-1.6.0pre1-2011.11.tar.bz2 from [1] and wonder what are the build options for this? I.e. what are the best/tested/recommended configure/compile options for this? And maybe which compiler to use (if this matters ;) )? Are there any binary packages available, too? Many thanks and best regards Dirk [1] https://launchpad.net/linaro-multimedia-project/2011.11/2011.11/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2] S5PC2XX: Rename S5pc2XX to exynos4
As per new conventions Samsung SoC's are named as Exynos.
Cortex-A9 based Soc's are named as exynos4. s5pc2xx is cortex-A9
based, hence renamed to exynos4. This is done as per kernel
naming convetions.
Similerly s5pc210 is now exynos4210. Hence S5PC210/s5pc210
suffix/prefix has been renamed to EXYNOS4210/exynos4210.
Signed-off-by: Chander Kashyap
---
Changes for v2:
- Removed renaming of s5p-common to exynos4-common
- Renamed s5pc210 prefixes to exynos4210
MAINTAINERS|6 +-
Makefile |2 +-
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile |0
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c| 50
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c |0
.../asm/{arch-s5pc2xx => arch-exynos4}/adc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/clk.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/clock.h |2 +-
.../asm/{arch-s5pc2xx => arch-exynos4}/cpu.h | 62 ++--
.../asm/{arch-s5pc2xx => arch-exynos4}/gpio.h | 28 +-
.../asm/{arch-s5pc2xx => arch-exynos4}/mmc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/pwm.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/sromc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/uart.h |0
board/samsung/origen/lowlevel_init.S | 26
board/samsung/origen/mem_setup.S | 12 ++--
board/samsung/origen/origen.c |8 +-
board/samsung/origen/origen_setup.h|8 +-
board/samsung/smdkv310/lowlevel_init.S | 22
board/samsung/smdkv310/mem_setup.S |8 +-
board/samsung/smdkv310/smdkv310.c |8 +-
board/samsung/universal_c210/lowlevel_init.S | 24
board/samsung/universal_c210/universal.c |8 +-
boards.cfg |6 +-
include/configs/origen.h |6 +-
include/configs/s5pc210_universal.h| 10 ++--
include/configs/smdkv310.h |6 +-
28 files changed, 151 insertions(+), 151 deletions(-)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile (100%)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c (80%)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/adc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clk.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clock.h (99%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/cpu.h (64%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/gpio.h (83%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/mmc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/pwm.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sromc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/uart.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 030fe4a..36f8400 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -690,12 +690,12 @@ Minkyu Kang
SMDKC100ARM ARMV7 (S5PC100 SoC)
s5p_goniARM ARMV7 (S5PC110 SoC)
- s5pc210_universal ARM ARMV7 (S5PC210 SoC)
+ s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
Chander Kashyap
- origen ARM ARMV7 (S5PC210 SoC)
- SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (EXYNOS4210 SoC)
+ SMDKV310ARM ARMV7 (EXYNOS4210 SoC)
Torsten Koschorrek
scb9328 ARM920T (i.MXL)
diff --git a/Makefile b/Makefile
index 294c762..641b644 100644
--- a/Makefile
+++ b/Makefile
@@ -303,7 +303,7 @@ endif
ifeq ($(SOC),s5pc1xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-ifeq ($(SOC),s5pc2xx)
+ifeq ($(SOC),exynos4)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
diff --git a/arch/arm/cpu/armv7/s5pc2xx/Makefile
b/arch/arm/cpu/armv7/exynos4/Makefile
similarity index 100%
rename from arch/arm/cpu/armv7/s5pc2xx/Makefile
rename to arch/arm/cpu/armv7/exynos4/Makefile
diff --git a/arch/arm/cpu/armv7/s5pc2xx/clock.c
b/arch/arm/cpu/armv7/exynos4/clock.c
similarity index 80%
rename from arch/arm/cpu/armv7/s5pc2xx/clock.c
rename to arch/arm/cpu/armv7/exynos4/clock.c
index 5ecd475..668166a 100644
--- a/arch/arm/cpu/armv7/s5pc2xx/clock.c
+++ b/arch/arm/cpu/armv7/exynos4/clock.c
@@ -30,11 +30,11 @@
#define CONFIG_SYS_CLK_FREQ_C210 2400
#endif
-/* s5pc210: return pll clock frequency */
-static unsigned long s5pc210_get_pll_clk(int pllreg)
+/* exynos4210: return pll clock frequency */
+static unsigned long exynos4210_get_pll_clk(int
Re: [PATCH 01/11] MFD: DA9052 MFD core module v8
On Fri, Nov 18, 2011 at 02:49:54PM +0530, Ashish Jangam wrote:
There's still a few issues in here. It'd be very much easier to review
this stuff if you split the patch down into smaller patches, for example
having the ADC, SPI and I2C as separate patches. The bigger each
individual e-mail is the more work it is to review.
Please also try to fix whatever problems you're having posting patch
serieses - this claims to be patch 1/11 but it looked like only patches
numbered 1, 4 and 5 got posted and none of those were threaded together.
> +int da9052_adc_manual_read(struct da9052 *da9052, unsigned char channel)
> +{
> + struct da9052_auxadc_req *req;
> + int ret;
> + unsigned short calc_data;
> + unsigned short data;
> + unsigned char mux_sel;
> +
> + req = kzalloc(sizeof(*req), GFP_KERNEL);
> + if (!req)
> + return -ENOMEM;
This function sometimes returns errnos but at other times...
> + ret = da9052_reg_read(da9052, DA9052_ADC_RES_H_REG);
> + if (ret < 0)
> + return IRQ_NONE;
...it returns irqreturn_t values. In the above case I'd *really* expect
to see the error from the return passed back to the caller. It also
looks like this error case returns with the auxadc_lock held which is
going to deadlock the next time someone tries to use the ADC - the same
problem exists for some other code.
> +int da9052_add_regulator_devices(struct da9052 *da9052,
> + struct da9052_pdata *pdata)
> +{
> + struct platform_device *pdev;
> + int i, ret;
> +
> + for (i = 0; i < pdata->num_regulators; i++) {
> + pdev = platform_device_alloc("da9052-regulator", i);
> + if (!pdev)
> + return -ENOMEM;
> +
> + pdev->dev.parent = da9052->dev;
> + ret = platform_device_add(pdev);
> + if (ret) {
> + platform_device_put(pdev);
> + return ret;
> + }
As I think has been previously said it's better style to unconditionally
register all the regulators the device has. The core should cope fine
with missing platform data and this gives readback support for the
regulators that aren't software configured yet.
> +static struct mfd_cell __initdata da9052_subdev_info[] = {
> + {"da9052-onkey", .resources = &da9052_onkey_resource,
> + .num_resources = 1},
Spaces around the { }.
> + ret = request_threaded_irq(pdata->irq_base + 13,
> +NULL, da9052_auxadc_irq,
Should replace the magic number with a define.
> + da9052_i2c->bustype = BUS_I2C;
bustype should be redundant now, it certianly doesn't seem to be
referred to in this patch.
> +/*
> + * Interrupt controller support for Dilaog DA9052 PMICs.
This looks very much like it could be replaced with regmap-irq. The
code would be slightly less efficient due to the support for sparse
interrupt registers but it'd be less code.
> +static struct spi_driver da9053_ba_spi_driver = {
> + .probe = da9052_spi_probe,
> + .remove = __devexit_p(da9052_spi_remove),
> + .driver = {
> + .name = "da9053-ba",
> + .bus = &spi_bus_type,
> + .owner = THIS_MODULE,
> + },
> +};
> +
> +static struct spi_driver da9053_bb_spi_driver = {
Use spi_device_id rather than registering multiple driver instances.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] Android Platform Team 2011-11-14 to 2011-11-20
Hello. Here is the weekly status report from the Android Platform Team. Key Points for wider discussion === * Android 2.3.7 Platform Release 11.11 complete and tested on all boards. * Android 4.0 ICS up and running on Snowball. Team Highlights === * ARM vexpress is now in android-build. * The Kernel configuration is now available on android-build Build details page. * A prototype of the kernel rebuild script exits. * Progress on ICS for iMX53 and Origen * The gator daemon for DS-5 running on all but the Origen builds. * ath6k Origen WiFi firmware has been integrated in Origen builds. * USB 2.0 Ethernet adapter works on Origen board. * Progress on MediaFrameworkTest integration. Bugs fixed === 878979, 886058, 889843, 889847, 891753, 892881, 884409, 842451, 877859, 891684, 884931 Miscellaneous === * New Team member Kejun Zhou from ST-Ericsson China. * Both fgiff (Dec. 16) and cyang (Dec. 9) are Leaving Linaro due to ST-Ericsson basingstoke site closing. Issues === * Time lost due to the build system becoming corrupted (#891753). Blueprints === https://launchpad.net/linaro-android/+milestone/11.11 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/5] OMAP4: cache fixes for 4460
On Wed, Nov 23, 2011 at 6:55 AM, Andy Green wrote: > On 11/22/2011 08:57 PM, Somebody in the thread at some point said: >> >> On Tue, Nov 22, 2011 at 6:02 PM, Mans Rullgard >> wrote: >>> >>> On 22 November 2011 05:14, Shilimkar, Santosh >>> wrote: Mans, On Tue, Nov 22, 2011 at 8:15 AM, Mans Rullgard wrote: > > These patches fix and tweak various cache settings for the 4460 > resulting in a speed increase exceeding 10% in some tests. > > Mans Rullgard (5): > OMAP4: apply L2 cache lockdown workaround only on 4460 ES1.0 This one is OK though the Panda were suppose to made out of es1.1 and es1.0 was not suppose to be supported. The WA is not full proof and you still might see corruption with this. Hence for mainline, we have decided not to push this patch. >>> >>> Well, currently the tilt kernel applies this to all 4460 versions, >>> twice even. This patch makes it do the right thing on both 1.0 and >>> 1.1. >>> >> I see. If it's for Linaro internal tree it's fine. > > Just a FYI TI LT tree is basis for customer for FOSS release from TI. > > What TI LT tree does for 4460 support is cobbled together and stolen from > other trees in various states of completion, it's workable at the moment but > any input from Mans or anyone else for making it better is super welcome. > >>> So keep them on by default but allow them to be turned off. In the >>> longer term, we should of course try to make these selectively >>> applied at runtime whenever possible. >>> >> Yep. That's the idea. On internal product kernels we do disable >> once which are NA for a chip. > > Issue is that for TI LT kernels, we target 4430 and 4460 support in one > build. We can't statically turn off stuff that 4430 needs. > We know and hence in mainline tree all of them are enabled so that both OMAP4430 and OMAP4460 works. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/5] OMAP4: cache fixes for 4460
On 24 November 2011 12:38, Shilimkar, Santosh wrote: > On Wed, Nov 23, 2011 at 6:55 AM, Andy Green wrote: >> On 11/22/2011 08:57 PM, Somebody in the thread at some point said: >>> >>> On Tue, Nov 22, 2011 at 6:02 PM, Mans Rullgard >>> wrote: So keep them on by default but allow them to be turned off. In the longer term, we should of course try to make these selectively applied at runtime whenever possible. >>> Yep. That's the idea. On internal product kernels we do disable >>> once which are NA for a chip. >> >> Issue is that for TI LT kernels, we target 4430 and 4460 support in one >> build. We can't statically turn off stuff that 4430 needs. >> > We know and hence in mainline tree all of them are enabled so that > both OMAP4430 and OMAP4460 works. Checking the manuals more carefully, it seems like 588369 does not affect 4430 either, having been fixed in PL310 r2p0. For 727915, it would be possible to replace outer_cache.set_debug by an empty function for r3p1 (4460), thus avoiding the monitor call if running on such a chip. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Cross Compiling Firefox with Multiarch
Hi, Just to let you all know, due to the ongoing multiarch work, it is not possible to cross-compile relatively complex packages in ubuntu. For example, following the instructions[1], Firefox. While building on oneiric, patched packages from the linaro-maintainers overlay are needed, many of those patches are on precise, and rest should get there during the next cycle. Cheers, Riku [1] https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompile ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cross Compiling Firefox with Multiarch
On 24 November 2011 15:32, Riku Voipio wrote: > Just to let you all know, due to the ongoing multiarch work, it is not > possible to cross-compile And of course I mean "now possible" .. Riku ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Hi, * Linus Walleij [24 01:29]: > On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren wrote: > > > Note that with device tree things get simpler for muxing as we can > > get rid of the hardcoded grouping of pins in mux drivers. Instead of > > hardcoded pingroups, the groups can be created dynamically based on > > what the driver DT entries have. > > Yes, I know too little about DT to figure out how these should > come in. > > > The reason why we want to avoid hardcoded pin groups is because trying > > to map all the pad combinations in the pinmux driver is not a scalable > > way to go. And it's not even possible at least on omaps because of the > > huge number of combinations with alternative pins and multiple packages. > > Yes, that's a solid case! So far it seems that device tree simplifies things here quite a bit in at least two ways: - We by default have automatically generated 1:1 mapping of devices to groups (of course others can be added too) - We should be able to support new SoC packages with different pin on existing kernels, like distro kernels, just by modifying the the device tree data ;) > > FYI I'm playing with a DT based pinmux-simple.c driver that should > > be pretty generic and work for all kinds of hardware hopefully. > > I love it. Still need few more days with these patches.. > > It will be few days before I can post anything though, there are > > some pinctrl fwk issues to deal with first. Like the hardcoded > > pinmux_maps that assumes that dev entries are static. This means > > that multiple instances of pinmux drivers won't work.. > > I'm not following, but I guess I will understand when I see the > patches. The idea behind the current map concept is that you > get either a string or struct device * to identify the pin controller > and mapped device, that's as far as I thought it out, sorry for > any inherent limitations, they're not intentional... Yeah we can sort those out afterwards. We should probably pass over the static board specific mapping as platform_data to the pinmux device and make it be part of struct pinctrl_dev. Then new driver instances can have their own pctldev->mapping and we can support both platform_data and device tree based drivers on the same system. Anyways, I'll try to get the initial patches working with just one instance to start with so we have something to play with. Regards, Tony ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Cross Compiling Firefox with Multiarch
Riku, On 24 November 2011 13:32, Riku Voipio wrote: > Hi, > > Just to let you all know, due to the ongoing multiarch work, it is not > possible to cross-compile > relatively complex packages in ubuntu. For example, following the > instructions[1], Firefox. Out of curiosity and having a few minutes right now, I tried following the instructions in an oneiric chroot on an amd64 host and I hit the following issues. 1. /etc/apt.conf.d does not really exist. so I had to create one and put 10local into it. 2. While following the instructions as in "Drag-in build dependencies for firefox" (oneiric)root@e102742:~# cat firefox-deps.sh apt-get install libx11-dev:armel libxt-dev:armel libgtk2.0-dev:armel liborbit2-dev:armel libidl-dev:armel libxft-dev:armel libfreetype6-dev:armel libxrender-dev:armel libxinerama-dev:armel libgnome2-dev:armel libgconf2-dev:armel libgnomeui-dev:armel libstartup-notification0-dev:armel libasound2-dev:armel libcurl4-openssl-dev:armel libdbus-glib-1-dev:armel libiw-dev:armel mesa-common-dev:armel libnotify-dev:armel libgnomevfs2-dev:armel libdbusmenu-gtk-dev:armel (oneiric)root@e102742:~# sh firefox-deps.sh Reading package lists... Done Building dependency tree Reading state information... Done libasound2-dev:armel is already the newest version. libcurl4-openssl-dev:armel is already the newest version. libdbus-glib-1-dev:armel is already the newest version. libfreetype6-dev:armel is already the newest version. libgtk2.0-dev:armel is already the newest version. libnotify-dev:armel is already the newest version. libx11-dev:armel is already the newest version. libxft-dev:armel is already the newest version. libxinerama-dev:armel is already the newest version. libxrender-dev:armel is already the newest version. libxt-dev:armel is already the newest version. mesa-common-dev:armel is already the newest version. libdbusmenu-gtk-dev:armel is already the newest version. liborbit2-dev:armel is already the newest version. libiw-dev:armel is already the newest version. libstartup-notification0-dev:armel is already the newest version. libgnome2-dev:armel is already the newest version. libgnomeui-dev:armel is already the newest version. libgnomevfs2-dev:armel is already the newest version. libgconf2-dev:armel is already the newest version. libidl-dev:armel is already the newest version. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libgnutls26:armel : Depends: libtasn1-3:armel (>= 1.6-0) but it is not going to be installed libtasn1-3-dev:armel : Depends: libtasn1-3:armel (= 2.9-4) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). (oneiric)root@e102742:~# apt-get install libtasn1-3-dev:armel Reading package lists... Done Building dependency tree Reading state information... Done libtasn1-3-dev:armel is already the newest version. You might want to run 'apt-get -f install' to correct these: The following packages have unmet dependencies: libgnutls26:armel : Depends: libtasn1-3:armel (>= 1.6-0) but it is not going to be installed libtasn1-3-dev:armel : Depends: libtasn1-3:armel (= 2.9-4) but it is not going to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). (oneiric)root@e102742:~# apt-get install libtasn1-3:armel Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: x11proto-record-dev libcairo-script-interpreter2 libssl-doc libglib2.0-dev zlib1g-dev libxtst6 libglobus-openssl Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: libtasn1-3:armel 0 upgraded, 1 newly installed, 0 to remove and 23 not upgraded. 235 not fully installed or removed. Need to get 0 B/37.7 kB of archives. After this operation, 139 kB of additional disk space will be used. debconf: delaying package configuration, since apt-utils is not installed (Reading database ... 44963 files and directories currently installed.) Unpacking libtasn1-3:armel (from .../libtasn1-3_2.9-4_armel.deb) ... dpkg: error processing /var/cache/apt/archives/libtasn1-3_2.9-4_armel.deb (--unpack): './usr/share/doc/libtasn1-3/NEWS.gz' is different from the same file on the system Errors were encountered while processing: /var/cache/apt/archives/libtasn1-3_2.9-4_armel.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Is there something I might be doing wrong ? Cheers, Ramana ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 04/11] Power: DA9052 Battery driver v4
On Fri, Nov 18, 2011 at 02:54:09PM +0530, Ashish Jangam wrote:
> Driver for DA9052 battery charger. This driver depends on DA9052 MFD core
> dirver
> for definitions and methods.
>
> Tested on Samsung SMDK6410 board with DA9052-BC and DA9053-BA evaluation
> boards.
>
> Signed-off-by: David Dajun Chen
> Signed-off-by: Ashish Jangam
> ---
Ashish,
Much thanks for your work! The code itself looks OK to me. But there are
some issues regarding readability and coding style. No big deal, but
please consider fixing.
[...]
[..]
> +static int da9052_battery_check_status(struct da9052_battery *battery,
> + int *status)
> +{
> + uint8_t v[2] = {0, 0};
> + uint8_t bat_status, chg_end;
In kernel code we try to use 'uXX' types. I.e. u8 here.
> + int ret, chg_current, chg_end_current;
Each declaration should be on its own line.
int ret;
int chr_current;
> +
> + ret = da9052_group_read(battery->da9052, DA9052_STATUS_A_REG, 2, v);
> + if (ret < 0)
> + return ret;
> +
> + bat_status = v[0];
> + chg_end = v[1];
> +
> + /* Preference to WALL(DCIN) charger unit */
> + if (((bat_status & DA9052_STATUSA_DCINSEL) &&
> + (bat_status & DA9052_STATUSA_DCINDET))
> + ||
> + ((bat_status & DA9052_STATUSA_VBUSSEL) &&
> + (bat_status & DA9052_STATUSA_VBUSDET))
> +) {
I can't parse it.
Maybe
bool dcinsel = bat_status & DA9052_STATUSA_DCINSEL;
bool dcindet = bat_status & DA9052_STATUSA_DCINDET;
bool vbussel = bat_status & DA9052_STATUSA_VBUSSEL;
bool vbusdet = bat_status & DA9052_STATUSA_VBUSDET;
bool dc = dcinsel && dcindet;
bool vbus = vbussel && vbusdet;
if (dc || vbus) {
...
} else if (dcindet || vbusdet) {
...
} else {
...
}
Note that it does not add a single line of code, but things become
much more readable.
> + battery->charger_type = DA9052_CHARGER;
> +
> + /* If charging end flag is set and Charging current is greater
> + * than charging end limit then battery is charging
> + */
> + if ((chg_end & DA9052_STATUSB_CHGEND) != 0) {
> + ret = da9052_battery_read_current(battery,
> + &chg_current);
> + if (ret < 0)
> + return ret;
> + ret = da9052_battery_read_end_current(battery,
> + &chg_end_current);
> + if (ret < 0)
> + return ret;
> +
> + if (chg_current >= chg_end_current)
> + battery->status = POWER_SUPPLY_STATUS_CHARGING;
> + else
> + battery->status =
> + POWER_SUPPLY_STATUS_NOT_CHARGING;
> + }
> + /* If Charging end flag is cleared then battery is charging */
> + else
> + battery->status = POWER_SUPPLY_STATUS_CHARGING;
> + } else if (bat_status & DA9052_STATUSA_DCINDET ||
> + bat_status & DA9052_STATUSA_VBUSDET) {
> + battery->charger_type = DA9052_CHARGER;
> + battery->status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> + } else {
> + battery->charger_type = DA9052_NOCHARGER;
> + battery->status = POWER_SUPPLY_STATUS_DISCHARGING;
> + }
> +
> + if (status != NULL)
> + *status = battery->status;
> + return 0;
> +}
[...]
> +unsigned char select_temperature(unsigned char temp_index, int
> bat_temperature)
> +{
> + int temp_temperature;
> +
> + temp_temperature = (temperature_lookup_ref[temp_index] +
> + temperature_lookup_ref[temp_index + 1]) / 2;
> +
> + if (bat_temperature >= temp_temperature) {
> + temp_index += 1;
> + return temp_index;
> + } else
should be "} else {", per coding style.
> + return temp_index;
> +}
> +
> +static int da9052_battery_read_capacity(struct da9052_battery *battery,
> + int *capacity)
> +{
> + int bat_temperature, bat_voltage;
> + int vbat_lower, vbat_upper, level_upper, level_lower;
> + int ret, flag, index, access_index = 0;
> +
> + ret = da9052_battery_read_volt(battery, &bat_voltage);
> + if (ret < 0)
> + return ret;
> +
> + bat_temperature = da9052_adc_temperature_read(battery->da9052);
> + if (bat_temperature < 0)
> + return bat_temperature;
> +
> + for (index = 0; index < (DA9052_NO_OF_LOOKUP_TABLE - 1); index++) {
> + if (bat_temperature <= temperature_lookup_ref[0]) {
> + access_index = 0;
> + break;
> + } else if (bat_temperature >
> +temperature_lookup_ref[DA9052_NO_OF_LOOKUP_TA
Re: [U-Boot] [PATCH v2] S5PC2XX: Rename S5pc2XX to exynos4
Dear Chander Kashyap,
On 24 November 2011 19:48, Chander Kashyap wrote:
> As per new conventions Samsung SoC's are named as Exynos.
> Cortex-A9 based Soc's are named as exynos4. s5pc2xx is cortex-A9
> based, hence renamed to exynos4. This is done as per kernel
> naming convetions.
>
> Similerly s5pc210 is now exynos4210. Hence S5PC210/s5pc210
> suffix/prefix has been renamed to EXYNOS4210/exynos4210.
>
> Signed-off-by: Chander Kashyap
> ---
> Changes for v2:
> - Removed renaming of s5p-common to exynos4-common
> - Renamed s5pc210 prefixes to exynos4210
>
> MAINTAINERS | 6 +-
> Makefile | 2 +-
> arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile | 0
> arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c | 50
> arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/adc.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/clk.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/clock.h | 2 +-
> .../asm/{arch-s5pc2xx => arch-exynos4}/cpu.h | 62
> ++--
> .../asm/{arch-s5pc2xx => arch-exynos4}/gpio.h | 28 +-
> .../asm/{arch-s5pc2xx => arch-exynos4}/mmc.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/pwm.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/sromc.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h | 0
> .../asm/{arch-s5pc2xx => arch-exynos4}/uart.h | 0
> board/samsung/origen/lowlevel_init.S | 26
> board/samsung/origen/mem_setup.S | 12 ++--
> board/samsung/origen/origen.c | 8 +-
> board/samsung/origen/origen_setup.h | 8 +-
> board/samsung/smdkv310/lowlevel_init.S | 22
> board/samsung/smdkv310/mem_setup.S | 8 +-
> board/samsung/smdkv310/smdkv310.c | 8 +-
> board/samsung/universal_c210/lowlevel_init.S | 24
> board/samsung/universal_c210/universal.c | 8 +-
> boards.cfg | 6 +-
> include/configs/origen.h | 6 +-
> include/configs/s5pc210_universal.h | 10 ++--
> include/configs/smdkv310.h | 6 +-
> 28 files changed, 151 insertions(+), 151 deletions(-)
> rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile (100%)
> rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c (80%)
> rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/adc.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clk.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clock.h (99%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/cpu.h (64%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/gpio.h (83%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/mmc.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/pwm.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sromc.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h (100%)
> rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/uart.h (100%)
>
Applying: S5PC2XX: Rename S5pc2XX to exynos4
error: patch failed: boards.cfg:195
error: boards.cfg: patch does not apply
Patch failed at 0001 S5PC2XX: Rename S5pc2XX to exynos4
I couldn't test your patch.
Please remake the patch.
Thanks
Minkyu Kang
--
from. prom.
www.promsoft.net
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ICS changes to use mksh
Hi, All
ICS has changed its default shell to mksh.
and the source of mksh is under ${AOSP}/external/mksh.
In ICS, mksh use /system/etc/mkshrc as the default profile if we log into
android with adb shell or on the serial console.
so if we want to export some environment variable like(PS1), we can change
this file.
and we can change the default profile file path by changing MKSHRC_PATH
in Android.mk.
if we don't log in, like just run "adb shell cmd", then the mkshrc will not
be used.
It says that mksh is *mostly* bourne shell compatible and is also POSIX sh
compatible,
but I'm not familiar with mksh, so if you are interested in it, you can go
to the homepage get more information.
this is the home page https://www.mirbsd.org/mksh.htm.
Thanks,
Yongqin Liu
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v2] S5PC2XX: Rename S5pc2XX to exynos4
As per new conventions Samsung SoC's are named as Exynos.
Cortex-A9 based Soc's are named as exynos4. s5pc2xx is cortex-A9
based, hence renamed to exynos4. This is done as per kernel
naming convetions.
Similerly s5pc210 is now exynos4210. Hence S5PC210/s5pc210
suffix/prefix has been renamed to exynos4210/EXYNOS4210
Signed-off-by: Chander Kashyap
---
Changes for v2:
- Removed renaming of s5p-common to exynos4-common
- Renamed s5pc210 prefixes to exynos4210
Rebased on following commit.
19cdfd3e84bff108febb127b598ac3f1634c768c
"Ethernut 5 board support"
MAINTAINERS|6 +-
Makefile |2 +-
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile |0
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c| 50
arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c |0
.../asm/{arch-s5pc2xx => arch-exynos4}/adc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/clk.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/clock.h |2 +-
.../asm/{arch-s5pc2xx => arch-exynos4}/cpu.h | 62 ++--
.../asm/{arch-s5pc2xx => arch-exynos4}/gpio.h | 28 +-
.../asm/{arch-s5pc2xx => arch-exynos4}/mmc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/pwm.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/sromc.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h |0
.../asm/{arch-s5pc2xx => arch-exynos4}/uart.h |0
board/samsung/origen/lowlevel_init.S | 26
board/samsung/origen/mem_setup.S | 12 ++--
board/samsung/origen/origen.c |8 +-
board/samsung/origen/origen_setup.h|8 +-
board/samsung/smdkv310/lowlevel_init.S | 22
board/samsung/smdkv310/mem_setup.S |8 +-
board/samsung/smdkv310/smdkv310.c |8 +-
board/samsung/universal_c210/lowlevel_init.S | 24
board/samsung/universal_c210/universal.c |8 +-
boards.cfg |6 +-
include/configs/origen.h |6 +-
include/configs/s5pc210_universal.h| 10 ++--
include/configs/smdkv310.h |6 +-
28 files changed, 151 insertions(+), 151 deletions(-)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/Makefile (100%)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/clock.c (80%)
rename arch/arm/cpu/armv7/{s5pc2xx => exynos4}/soc.c (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/adc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clk.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/clock.h (99%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/cpu.h (64%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/gpio.h (83%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/mmc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/pwm.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sromc.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/sys_proto.h (100%)
rename arch/arm/include/asm/{arch-s5pc2xx => arch-exynos4}/uart.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 37bbb34..d493e4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -691,12 +691,12 @@ Minkyu Kang
SMDKC100ARM ARMV7 (S5PC100 SoC)
s5p_goniARM ARMV7 (S5PC110 SoC)
- s5pc210_universal ARM ARMV7 (S5PC210 SoC)
+ s5pc210_universal ARM ARMV7 (EXYNOS4210 SoC)
Chander Kashyap
- origen ARM ARMV7 (S5PC210 SoC)
- SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (EXYNOS4210 SoC)
+ SMDKV310ARM ARMV7 (EXYNOS4210 SoC)
Torsten Koschorrek
scb9328 ARM920T (i.MXL)
diff --git a/Makefile b/Makefile
index fb658f4..646b105 100644
--- a/Makefile
+++ b/Makefile
@@ -296,7 +296,7 @@ endif
ifeq ($(SOC),s5pc1xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-ifeq ($(SOC),s5pc2xx)
+ifeq ($(SOC),exynos4)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
diff --git a/arch/arm/cpu/armv7/s5pc2xx/Makefile
b/arch/arm/cpu/armv7/exynos4/Makefile
similarity index 100%
rename from arch/arm/cpu/armv7/s5pc2xx/Makefile
rename to arch/arm/cpu/armv7/exynos4/Makefile
diff --git a/arch/arm/cpu/armv7/s5pc2xx/clock.c
b/arch/arm/cpu/armv7/exynos4/clock.c
similarity index 80%
rename from arch/arm/cpu/armv7/s5pc2xx/clock.c
rename to arch/arm/cpu/armv7/exynos4/clock.c
index 5ecd475..668166a 100644
--- a/arch/arm/cpu/armv7/s5pc2xx/clock.c
+++ b/arch/arm/cpu/armv7/exynos4/clock.c
@@ -30,11 +30,11 @@
#define CONFIG_SYS_CLK_FREQ_C210 2400
#endif
-/* s5pc210: return pll clock frequency */
-static unsigned long s5pc210_get_pll_clk(int pllre
Track the Linaro Roadmap on status.linaro.org
Hi all, To support the new Linaro roadmap process, the Infrastructure team has added new reports to status.linaro.org. You can find the status for the current quarter here and drill down into the cards targeted for Q4. http://status.linaro.org/11.11/roadmap-2011Q4.html There's of course work left to do, for instance there's a big backlog of status graphs and some layout tweaks to handle. Not to mention finding a good time to switch the status.linaro.org index page over to the roadmap. Still we believe that this will already be useful for everyone to keep an eye on the roadmap and how your work supports the long term goals. Direct any questions you may have about the tech details to Infrastructure and your TL can help you with connecting your blueprints to the roadmap cards. The Linaro Roadmap wiki page is also a good read: https://wiki.linaro.org/Process/Roadmap Thanks, Mattias ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
