Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Monday 05 March 2012 01:24 PM, Rajendra Nayak wrote: On Friday 24 February 2012 03:40 PM, Rajendra Nayak wrote: Chris, On Thursday 23 February 2012 04:56 PM, Rajendra Nayak wrote: Re-sending as these patches did not make it to the lists due to issues with my 'git send-email' This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. v2 mainly has some minor changes to get rid of a debug print which was still using host-id and getting rid of 'id' field entirely from omap_hsmmc_host struct. The series is tested on OMAP4SDP, OMAP4panda, OMAP3beagle and OMAP2430SDP boards. This series is reviewed/tested and acked by Balaji and Venkat. Care to pull this in for 3.4? I have one other cleanup patch on top of this series to make all remaining pr_* prints in the driver to dev_* [1]. It would be great if you could pick that up as well. These patches are cleanups leading to the DT conversion of omap_hsmmc driver. Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) regards, Rajendra regards, Rajendra [1] http://marc.info/?l=linux-mmcm=132999677405098w=3 regards, Rajendra Balaji T K (3): mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channels mmc: omap_hsmmc: remove unused .set_sleep function mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host-id based hardcoding Rajendra Nayak (3): mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power function mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power function mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supply arch/arm/plat-omap/include/plat/mmc.h | 2 - drivers/mmc/host/omap_hsmmc.c | 175 +++-- 2 files changed, 16 insertions(+), 161 deletions(-) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
TI Landing Team kernel fails to build
Hi there, As of last night TILT fails to build for omap4_defconfig. panto@sles11esa:~/ti/kernels/kernel-tilt$ git checkout -b tilt-tracking-work origin/tilt-tracking Branch tilt-tracking-work set up to track remote branch tilt-tracking from origin. Switched to a new branch 'tilt-tracking-work' ... panto@sles11esa:~/ti/kernels/kernel-tilt$ make omap4_defconfig warning: (ARCH_OMAP4 ARCH_OMAP5) selects LOCAL_TIMERS which has unmet direct dependencies (SMP !ARM_SMP_TWD) warning: (ARCH_OMAP4 ARCH_OMAP5) selects LOCAL_TIMERS which has unmet direct dependencies (SMP !ARM_SMP_TWD) ^ This is dubious panto@sles11esa:~/ti/kernels/kernel-tilt$ make -j 2 CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC arch/arm/kernel/smp_twd.o arch/arm/kernel/smp_twd.c: In function 'twd_timer_setup': arch/arm/kernel/smp_twd.c:226:7: error: 'twd_evt' undeclared (first use in this function) arch/arm/kernel/smp_twd.c:226:7: note: each undeclared identifier is reported only once for each function it appears in arch/arm/kernel/smp_twd.c:251:2: warning: ISO C90 forbids mixed declarations and code arch/arm/kernel/smp_twd.c:267:2: warning: type defaults to 'int' in type name arch/arm/kernel/smp_twd.c:267:17: warning: initialization makes pointer from integer without a cast arch/arm/kernel/smp_twd.c:267:2: warning: type defaults to 'int' in type name arch/arm/kernel/smp_twd.c:267:2: warning: type defaults to 'int' in type name arch/arm/kernel/smp_twd.c:267:2: warning: type defaults to 'int' in type name arch/arm/kernel/smp_twd.c:267:15: warning: assignment makes pointer from integer without a cast ^ twd_evt is nowhere to be found; make[1]: *** [arch/arm/kernel/smp_twd.o] Error 1 make: *** [arch/arm/kernel] Error 2 make: *** Waiting for unfinished jobs CC arch/arm/mach-omap2/omap_tps6236x.o AS arch/arm/mach-omap2/omap-headsmp.o CC arch/arm/mach-omap2/omap-hotplug.o arch/arm/mach-omap2/omap_tps6236x.c:267:3: error: unknown field 'omap_chip' specified in initializer arch/arm/mach-omap2/omap_tps6236x.c:267:3: error: implicit declaration of function 'OMAP_CHIP_INIT' arch/arm/mach-omap2/omap_tps6236x.c:267:31: error: 'CHIP_IS_OMAP4460ES1_0' undeclared here (not in a function) make[1]: *** [arch/arm/mach-omap2/omap_tps6236x.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [arch/arm/mach-omap2] Error 2 ^ That's a different build error. Regards -- Pantelis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[RFC PATCH] cpuidle: avoid unnecessary expensive governor processing
There a few cases when a platform's cpuidle_device will only have one
cpuidle state. e.g., when a single idle state system uses cpuidle
to provide sysfs staticstics for profiling (powertop, etc). This can
also be the case for coupled smp system implementations that keep
all but one cpuidle_device at a state_count of 1, but they still want
to export idle statistics for these states using cpuidle.
Signed-off-by: Robert Lee rob@linaro.org
---
drivers/cpuidle/governors/ladder.c |7 +--
drivers/cpuidle/governors/menu.c |7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/cpuidle/governors/ladder.c
b/drivers/cpuidle/governors/ladder.c
index b6a09ea..13abdba 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -71,8 +71,11 @@ static int ladder_select_state(struct cpuidle_driver *drv,
int last_residency, last_idx = ldev-last_state_idx;
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
- /* Special case when user has set very strict latency requirement */
- if (unlikely(latency_req == 0)) {
+ /*
+* Special case when user has set very strict latency requirement or
+* there is currently only one state for this device.
+*/
+ if ((latency_req == 0) || (dev-state_count == 1)) {
ladder_do_selection(ldev, last_idx, 0);
return 0;
}
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index ad09526..80eb606 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -249,8 +249,11 @@ static int menu_select(struct cpuidle_driver *drv, struct
cpuidle_device *dev)
data-last_state_idx = 0;
data-exit_us = 0;
- /* Special case when user has set very strict latency requirement */
- if (unlikely(latency_req == 0))
+ /*
+* Special case when user has set very strict latency requirement or
+* there is currently only one state for this device.
+*/
+ if ((latency_req == 0) || (dev-state_count == 1))
return 0;
/* determine the expected residency time, round up */
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v9] Regulator: Add Anatop regulator driver
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Anatop is an integrated regulator inside i.MX6 SoC.
There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
This patch adds the Anatop regulator driver.
Signed-off-by: Nancy Chen nancy.c...@freescale.com
Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org
Acked-by: Shawn Guo shawn@linaro.org
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Liam Girdwood l...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
.../bindings/regulator/anatop-regulator.txt| 28 +++
drivers/regulator/Kconfig |8 +
drivers/regulator/Makefile |1 +
drivers/regulator/anatop-regulator.c | 231
4 files changed, 268 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/anatop-regulator.txt
create mode 100644 drivers/regulator/anatop-regulator.c
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
new file mode 100644
index 000..500463e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -0,0 +1,28 @@
+Anatop Voltage regulators
+
+Required properties:
+- compatible: Must be fsl,anatop-regulator
+- vol-bit-shift: Bit shift for the register
+- vol-bit-width: Number of bits used in the register
+- min-bit-val: Minimum value of this register
+- min-voltage: Minimum voltage of this regulator
+- max-voltage: Maximum voltage of this regulator
+
+Any property defined as part of the core regulator
+binding, defined in regulator.txt, can also be used.
+
+Example:
+
+ reg_vddpu: regulator-vddpu@140 {
+ compatible = fsl,anatop-regulator;
+ regulator-name = vddpu;
+ regulator-min-microvolt = 725000;
+ regulator-max-microvolt = 130;
+ regulator-always-on;
+ reg = 0x140;
+ vol-bit-shift = 9;
+ vol-bit-width = 5;
+ min-bit-val = 1;
+ min-voltage = 725000;
+ max-voltage = 130;
+ };
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 7a61b17..5366991 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -335,5 +335,13 @@ config REGULATOR_AAT2870
If you have a AnalogicTech AAT2870 say Y to enable the
regulator driver.
+config REGULATOR_ANATOP
+ tristate Freescale i.MX on-chip ANATOP LDO regulators
+ depends on MFD_ANATOP
+ help
+ Say y here to support Freescale i.MX on-chip ANATOP LDOs
+ regulators. It is recommended that this option be
+ enabled on i.MX6 platform.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 503bac8..8440871 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -48,5 +48,6 @@ obj-$(CONFIG_REGULATOR_AB8500)+= ab8500.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
+obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
new file mode 100644
index 000..1e20690
--- /dev/null
+++ b/drivers/regulator/anatop-regulator.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ */
+
+/*
+ * This program 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 program 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.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include linux/slab.h
+#include linux/device.h
+#include linux/module.h
+#include linux/err.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/mfd/anatop.h
+#include linux/regulator/driver.h
+#include linux/regulator/of_regulator.h
+
+struct anatop_regulator {
+ const char *name;
+ u32 control_reg;
+ struct anatop *mfd;
+ int vol_bit_shift;
+ int vol_bit_width;
+ int min_bit_val;
+ int min_voltage;
+ int max_voltage;
+ struct regulator_desc rdesc;
+ struct
Re: [PATCH v9] Regulator: Add Anatop regulator driver
On Wed, Mar 07, 2012 at 02:22:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: +- compatible: Must be fsl,anatop-regulator +- vol-bit-shift: Bit shift for the register +- vol-bit-width: Number of bits used in the register +- min-bit-val: Minimum value of this register +- min-voltage: Minimum voltage of this regulator +- max-voltage: Maximum voltage of this regulator specific properites need to be prefix by the vendor This really doesn't seem at all sane for a device which is already vendor specific, it's just noise in the bindings. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
Hi Rajendra, On Wed, Mar 07 2012, Rajendra Nayak wrote: Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) Sorry for the delay, thanks for the ping; I've pushed these to mmc-next for 3.4 now. Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage and KVM
Dnia 2012-03-06, wto o godzinie 14:50 +, Rob Herring pisze: What are the plans for single zImage? Where does the vexpress-a15 fit in with that? Could I bump it to the front of the list? DT support for vexp A9 is going into 3.4 I believe. Pawel has been working on it and can probably give details on A15 support. A single kernel for these 2 platforms (and A7 as well) is much simpler than getting to a single zImage in general (i.e. omap plus i.mx). But we'll be a lot closer in 3.4. Yes - the DT4VE will be (hopefully :-) merged in 3.4, but is already available in LT kernel and in arm-soc repo. Single zImage can be used to boot V2P-CA9, V2P-CA5s, V2P-CA15 (this platform is a bit unstable though, and I haven't tried LPAE configuration yet), FPGA board with A7 setup and RTSM_VE-AEMv7 model. The coretile DTSes are available in kernel, the rest live in our http://linux-arm.org/git?p=arm-dts.git DTS repo (there will be more as I get them working on other models). The current main problem is CLCD driver DT support, or rather lack of it, but this is the first thing I'll take care of as soon as I can (I'm out of office this week, so I may replay to emails with substantial delay) Cheers! Paweł -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] Regulator: Add Anatop regulator driver
On Wed, Mar 07, 2012 at 04:36:22PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: This really doesn't seem at all sane for a device which is already vendor specific, it's just noise in the bindings. No it's ...? Here is a good example as we have regulator generic binding vendor specific bindig It's not vendor specific, it's device specific and people are doing it even for devices with no generic bindings at all which is particularly silly. Device specific prefixes probably make sense, but vendor specific ones are just noise. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] Regulator: Add Anatop regulator driver
On 21:24 Wed 07 Mar , Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is an integrated regulator inside i.MX6 SoC. There are 3 digital regulators which controls PU, CORE (ARM), and SOC. And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB). This patch adds the Anatop regulator driver. Signed-off-by: Nancy Chen nancy.c...@freescale.com Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org Acked-by: Shawn Guo shawn@linaro.org Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Liam Girdwood l...@ti.com Cc: Samuel Ortiz sa...@linux.intel.com --- .../bindings/regulator/anatop-regulator.txt| 28 +++ drivers/regulator/Kconfig |8 + drivers/regulator/Makefile |1 + drivers/regulator/anatop-regulator.c | 231 4 files changed, 268 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/anatop-regulator.txt create mode 100644 drivers/regulator/anatop-regulator.c diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt new file mode 100644 index 000..500463e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt @@ -0,0 +1,28 @@ +Anatop Voltage regulators + +Required properties: +- compatible: Must be fsl,anatop-regulator +- vol-bit-shift: Bit shift for the register +- vol-bit-width: Number of bits used in the register +- min-bit-val: Minimum value of this register +- min-voltage: Minimum voltage of this regulator +- max-voltage: Maximum voltage of this regulator specific properites need to be prefix by the vendor Best Regards, J. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
implementing suspend to ram on cortex A8 based on linux 3.0.8
dear all: I am working on arm cortex a8 now, trying to implement suspend to ram based on linux 3.0.8. Before i start my work, the soc already support standby(the cpu is on wfi state), so in order to implement suspend to ram, i think i just need to implement the arch-specific related api. The suspend to ram works like this: echo mem /sys/power/state - enter_state - suspend_devices_and_enter -suspend_ops-enter(state) Is that right? Do you think the suspend to ram can be realized in this way? In order to power off the cortex A8, i save all the writable co-processor and all modes's state register set, and restore them when resuming. All the code seems work ok, because when I just does not power off the cortex-A8 and jump to excute the resume code, the system works well. But, when I power off the cpu, and wake up and excute resume code, the kernel seem ok, but the busybox toolkit does not work proper, eg: ls can not output the result through serial port. i add printk statement trying to locate the reason, but at this time, the ls work fine. hence, i doubt something must be corrupted after resume. I have checked all the state register and co-processor, having not found any exception, and I also compared all the dram data before power off and after wake up, nothing have changed. Right now, I do not know what has happened, and what should I do to locate the real problem to make the busybox works ok. I also want to know does the linux kernel 3.0.8 support suspend to ram like this: echo mem /sys/power/state - enter_state - suspend_devices_and_enter -suspend_ops-enter(state)? Can anyone give me some suggestion? Any comment is welcome, thanks a lot. -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] Regulator: Add Anatop regulator driver
On 13:45 Wed 07 Mar , Mark Brown wrote: On Wed, Mar 07, 2012 at 02:22:25PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: +- compatible: Must be fsl,anatop-regulator +- vol-bit-shift: Bit shift for the register +- vol-bit-width: Number of bits used in the register +- min-bit-val: Minimum value of this register +- min-voltage: Minimum voltage of this regulator +- max-voltage: Maximum voltage of this regulator specific properites need to be prefix by the vendor This really doesn't seem at all sane for a device which is already vendor specific, it's just noise in the bindings. No it's Here is a good example as we have regulator generic binding vendor specific bindig Best Regards, J. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Call for topics for the 12.03 release of linux-linaro kernel
Greetings, I've pushed the baseline for the 12.03 linux-linaro kernel tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. Currently this is v3.3-rc6 plus: - 4 topics from the ARM LT - few commits being carried over from linux-linaro-3.1 This tree is not a history one, it will be rebased fairly often. We are moving to a new process (more details will come later). That's why the call for topics, not patches. If you have something to be included into the 12.03 and the following linux-linaro kernel releases, please send me a link to the git branch to pull from. This must be a permanent location, as this topic branch will be used for all the following releases (until there is a request from the topic owner to stop tracking it). As long as the topic branch merges OK into linux-linaro, it will be present in the linux-linaro releases. The topic branch should be based on recent linux-linaro or mainline Linus tree (like v3.3-rc5 or v3.3-rc6). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for topics for the 12.03 release of linux-linaro kernel
On Thu, 2012-03-08 at 00:07 +0400, Andrey Konovalov wrote: Greetings, I've pushed the baseline for the 12.03 linux-linaro kernel tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. Currently this is v3.3-rc6 plus: - 4 topics from the ARM LT - few commits being carried over from linux-linaro-3.1 This tree is not a history one, it will be rebased fairly often. We are moving to a new process (more details will come later). That's why the call for topics, not patches. If you have something to be included into the 12.03 and the following linux-linaro kernel releases, please send me a link to the git branch to pull from. This must be a permanent location, as this topic branch will be used for all the following releases (until there is a request from the topic owner to stop tracking it). As long as the topic branch merges OK into linux-linaro, it will be present in the linux-linaro releases. The topic branch should be based on recent linux-linaro or mainline Linus tree (like v3.3-rc5 or v3.3-rc6). Here's the current AOSP 3.3 android queue, with no modifications: git://git.linaro.org/people/jstultz/android.git linaro-android-3.3 thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 02/03] HWMON: HWMON driver for DA9052/53 PMIC v3
On Fri, 2012-03-02 at 09:29 -0500, Ashish Jangam wrote: The DA9052 PMIC provides an Analogue to Digital Converter with 10 bits resolution and 10 channels. This patch monitors the DA9052 PMIC's ADC channels mostly for battery parameters like battery temperature, junction temperature, battery current etc. This patch is functionally tested on Samsung SMDKV6410 Signed-off-by: David Dajun Chen dc...@diasemi.com Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com Only comment I would have is that it might make sense to use DIV_ROUND_CLOSEST(). That is a minor issue, though, so feel free to add Acked-by: Guenter Roeck guenter.ro...@ericsson.com Question is where this is going. I can not add it to hwmon-next without the matching mfd changes. Any idea ? Thanks, Guenter ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 4/4] clk: basic clock hardware types
On Sat, Mar 03, 2012 at 12:29:01AM -0800, Mike Turquette wrote:
+struct clk *clk_register_divider(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 shift, u8 width,
+ u8 clk_divider_flags, spinlock_t *lock)
+{
+ struct clk_divider *div;
+ char **parent_names = NULL;
+ u8 len;
+
+ div = kmalloc(sizeof(struct clk_divider), GFP_KERNEL);
+
+ if (!div) {
+ pr_err(%s: could not allocate divider clk\n, __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ /* struct clk_divider assignments */
+ div-reg = reg;
+ div-shift = shift;
+ div-width = width;
+ div-flags = clk_divider_flags;
+ div-lock = lock;
+
+ if (parent_name) {
+ parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
+
+ if (! parent_names)
+ goto out;
+
+ len = sizeof(char) * strlen(parent_name);
+
+ parent_names[0] = kmalloc(len, GFP_KERNEL);
+
+ if (!parent_names[0])
+ goto out;
+
+ strncpy(parent_names[0], parent_name, len);
+ }
+
+out:
+ return clk_register(dev, name,
+ clk_divider_ops, div-hw,
+ parent_names,
+ (parent_name ? 1 : 0),
+ flags);
+}
clk_register_divider and also clk_register_gate have some problems.
First you allocate memory with exactly the string length without
the terminating 0. Then the functions leak memory when clk_register
fails. Could you fold in the following patch to fix this?
Sascha
8--
fix divider/gate registration
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/clk/clk-divider.c| 34 +++---
drivers/clk/clk-gate.c | 33 ++---
include/linux/clk-provider.h |2 ++
3 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 8f02930..99b6b55 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -156,14 +156,13 @@ struct clk *clk_register_divider(struct device *dev,
const char *name,
u8 clk_divider_flags, spinlock_t *lock)
{
struct clk_divider *div;
- char **parent_names = NULL;
- u8 len;
+ struct clk *clk;
- div = kmalloc(sizeof(struct clk_divider), GFP_KERNEL);
+ div = kzalloc(sizeof(struct clk_divider), GFP_KERNEL);
if (!div) {
pr_err(%s: could not allocate divider clk\n, __func__);
- return ERR_PTR(-ENOMEM);
+ return NULL;
}
/* struct clk_divider assignments */
@@ -174,25 +173,22 @@ struct clk *clk_register_divider(struct device *dev,
const char *name,
div-lock = lock;
if (parent_name) {
- parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
-
- if (! parent_names)
- goto out;
-
- len = sizeof(char) * strlen(parent_name);
-
- parent_names[0] = kmalloc(len, GFP_KERNEL);
-
- if (!parent_names[0])
+ div-parent[0] = kstrdup(parent_name, GFP_KERNEL);
+ if (!div-parent[0])
goto out;
-
- strncpy(parent_names[0], parent_name, len);
}
-out:
- return clk_register(dev, name,
+ clk = clk_register(dev, name,
clk_divider_ops, div-hw,
- parent_names,
+ div-parent,
(parent_name ? 1 : 0),
flags);
+ if (clk)
+ return clk;
+
+out:
+ kfree(div-parent[0]);
+ kfree(div);
+
+ return NULL;
}
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index e831f7b..92c0489 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -80,14 +80,13 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
u8 clk_gate_flags, spinlock_t *lock)
{
struct clk_gate *gate;
- char **parent_names = NULL;
- u8 len;
+ struct clk *clk;
- gate = kmalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
if (!gate) {
pr_err(%s: could not allocate gated clk\n, __func__);
- return ERR_PTR(-ENOMEM);
+ return NULL;
}
/* struct clk_gate assignments */
@@ -97,25 +96,21 @@ struct clk *clk_register_gate(struct device *dev, const
char *name,
gate-lock = lock;
if (parent_name) {
- parent_names = kmalloc(sizeof(char *), GFP_KERNEL);
-
- if (! parent_names)
- goto out;
-
- len = sizeof(char) *
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Tue, Mar 6, 2012 at 11:00 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Mar 05, 2012 at 12:03:15PM -0800, Turquette, Mike wrote:
On Sun, Mar 4, 2012 at 11:38 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
I believe this patch already does what you suggest, but I might be
missing your point.
In include/linux/clk-private.h you expose struct clk outside the core.
This has to be done to make static initializers possible. There is a big
warning in this file that it must not be included from files
implementing
struct clk_ops. You can simply avoid this warning by declaring struct
clk
with only a single member:
include/linux/clk.h:
struct clk {
struct clk_internal *internal;
};
This way everybody knows struct clk (thus can embed it in their static
initializers), but doesn't know anything about the internal members. Now
in drivers/clk/clk.c you declare struct clk_internal exactly like struct
clk was declared before:
struct clk_internal {
const char *name;
const struct clk_ops *ops;
struct clk_hw *hw;
struct clk *parent;
char **parent_names;
struct clk **parents;
u8 num_parents;
unsigned long rate;
unsigned long flags;
unsigned int enable_count;
unsigned int prepare_count;
struct hlist_head children;
struct hlist_node child_node;
unsigned int notifier_count;
#ifdef CONFIG_COMMON_CLK_DEBUG
struct dentry *dentry;
#endif
};
An instance of struct clk_internal will be allocated in
__clk_init/clk_register. Now the private data stays completely inside
the core and noone can abuse it.
Hi Sascha,
I see the disconnect here. For OMAP (and possibly other platforms) at
least some clock data is necessary during early boot, before the
regular allocation methods are available (timers for instance).
We had this problem on i.MX aswell. It turned out that the timer clock
is the only clock that is needed so early. We solved this by moving the
clock init to the system timer init function.
When you say mov[ed] the clock init to the system timer init
function do you mean that you statically allocated struct clk and
used the clk framework api, or instead you just did some direct
register writes to initialize things properly?
I meant that on i.MX we do the clock tree initialization when kmalloc is
available, see the attached patch for omap4 based on your branch which
does the same for Omap. The first clock you need is the one for the
timer, so you can initialize the clocktree at the beginning of
time_init() and don't need statically initialized clocks anymore.
Well, the file is work in progress, you probably fix this before sending
it out, but I bet people will include clk-private.h and nobody else
notices it.
clock44xx_data.c does not violate that rule. None of the logic that
implements ops for those clocks is present clock44xx_data.c.
Indeed, I missed that. It only has the ops but not the individual
functions.
All of
the code in that file is simply initialization and registration of
OMAP4 clocks. Many of the clocks are basic clock types (divider,
multiplexer and fixed-rate are used in that file) with protected code
drivers/clk/clk-*.c and the remaining clocks are of the struct
clk_hw_omap variety, which has code spread across several files:
arch/arm/mach-omap2/clock.c
arch/arm/mach-omap2/clock.h
arch/arm/mach-omap2/clkt_dpll.c
arch/arm/mach-omap2/clkt_clksel.c
arch/arm/mach-omap2/dpll3xxx.c
arch/arm/mach-omap2/dpll4xxx.c
All of the above files include linux/clk-provider.h, not
linux/clk-private.h. That code makes heavy use of the
__clk_get_whatever helpers and shows how a platform might honor the
layer of separation between struct clk and stuct clk_ops/struct
clk_foo. You are correct that the code is a work-in-progress, but
there are no layering violations that I can see.
I also think we are talking past each other to some degree. One point
I would like to make (and maybe you already know this from code
review) is that it is unnecessary to have pointers to your parent
struct clk*'s when either initializing or registering your clocks. In
fact the existing clk_register_foo functions don't even allow you to
pass in parent pointers and rely wholly on string name matching. I
just wanted to point that out in case it went unnoticed, as it is a
new way of doing things from the previous series and was born out of
Thomas' review of V4 and multi-parent handling. This also keeps
device-tree in mind where we might not know the struct clk *pointer at
compile time for
Re: TI Landing Team kernel fails to build
On 03/07/2012 06:13 PM, Somebody in the thread at some point said: Hi there, As of last night TILT fails to build for omap4_defconfig. panto@sles11esa:~/ti/kernels/kernel-tilt$ git checkout -b tilt-tracking-work origin/tilt-tracking Branch tilt-tracking-work set up to track remote branch tilt-tracking from origin. Switched to a new branch 'tilt-tracking-work' Yes it's broken for OMAP4 config at the moment, it does say so at the table at the top. We're transitioning to a tree based on OMAP5 stuff, we had intended to audit it for OMAP4 already but Jassi has gotten diverted into firefighting something else. The last old tree for tilt-tracking is at this tag old-tree-cam, you should get better results with that until we can normalize the main tree for OMAP4 again. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 02/03] HWMON: HWMON driver for DA9052/53 PMIC v3
Only comment I would have is that it might make sense to use DIV_ROUND_CLOSEST(). That is a minor issue, though, so feel free to add Acked-by: Guenter Roeck guenter.ro...@ericsson.com Question is where this is going. I can not add it to hwmon-next without the matching mfd changes. Any idea ? This patch will depends on DA9052 MFD which is already merged in main line. However this also depends on a incremental patch for MFD which is yet to get ACK but soon should be in. Thanks, Guenter ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Wednesday 07 March 2012 08:29 PM, Chris Ball wrote: Hi Rajendra, On Wed, Mar 07 2012, Rajendra Nayak wrote: Chris, Ping. I am basing my DT support patches on top of these cleanups. Would be great if you can have a look and pull them in. Chris, just realized the last two requests from me to get this merged weren't addressed to you directly, but instead you were copied. Resending with you in 'To', hope this lands in your inbox :) Sorry for the delay, thanks for the ping; I've pushed these to mmc-next for 3.4 now. Great, thanks Chris. Thanks, - Chris. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree
Hi Rob/Grant,
On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote:
Define dt bindings for the ti-omap-hsmmc, and adapt
the driver to extract data (which was earlier passed as
platform_data) from device tree.
Any comments on these bindings for omap hsmmc? All the dependent
patches/series on which this series was based have now made it to
the respective -next of Mark and Chris.
regards,
Rajendra
Signed-off-by: Rajendra Nayakrna...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 +
drivers/mmc/host/omap_hsmmc.c | 68
2 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
new file mode 100644
index 000..e4fa8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -0,0 +1,31 @@
+* TI Highspeed MMC host controller for OMAP
+
+The Highspeed MMC Host Controller on TI OMAP family
+provides an interface for MMC, SD, and SDIO types of memory cards.
+
+Required properties:
+- compatible:
+ Should be ti,omap2-hsmmc, for OMAP2/3 controllers
+ Should be ti,omap4-hsmmc, for OMAP4 controllers
+- ti,hwmods: Must be mmcn, n is controller instance starting 1
+- reg : should contain hsmmc registers location and length
+
+Optional properties:
+ti,dual-volt: boolean, supports dual voltage cards
+supply-name-supply: phandle to the regulator device tree node
+supply-name examples are vmmc, vmmc_aux etc
+ti,bus-width: Number of data lines, default assumed is 1 if the property is
missing.
+cd-gpios: GPIOs for card detection
+wp-gpios: GPIOs for write protection
+ti,non-removable: non-removable slot (like eMMC)
+
+Example:
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg =0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,bus-width =4;
+ vmmc-supply =vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 35f6dc1..0c93d58 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -26,6 +26,9 @@
#includelinux/platform_device.h
#includelinux/timer.h
#includelinux/clk.h
+#includelinux/of.h
+#includelinux/of_gpio.h
+#includelinux/of_device.h
#includelinux/mmc/host.h
#includelinux/mmc/core.h
#includelinux/mmc/mmc.h
@@ -1718,6 +1721,46 @@ static void omap_hsmmc_debugfs(struct mmc_host *mmc)
#endif
+#ifdef CONFIG_OF
+static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
+{
+ struct omap_mmc_platform_data *pdata;
+ struct device_node *np = dev-of_node;
+ u32 bus_width;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL; /* out of memory */
+
+ if (of_find_property(np, ti,dual-volt, NULL))
+ pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
+
+ /* This driver only supports 1 slot */
+ pdata-nr_slots = 1;
+ pdata-slots[0].switch_pin = of_get_named_gpio(np, cd-gpios, 0);
+ pdata-slots[0].gpio_wp = of_get_named_gpio(np, wp-gpios, 0);
+
+ if (of_find_property(np, ti,non-removable, NULL)) {
+ pdata-slots[0].nonremovable = true;
+ pdata-slots[0].no_regulator_off_init = true;
+ }
+ of_property_read_u32(np, ti,bus-width,bus_width);
+ if (bus_width == 4)
+ pdata-slots[0].caps |= MMC_CAP_4_BIT_DATA;
+ else if (bus_width == 8)
+ pdata-slots[0].caps |= MMC_CAP_8_BIT_DATA;
+ return pdata;
+}
+#else
+static inline struct omap_mmc_platform_data
+ *of_get_hsmmc_pdata(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
+static const struct of_device_id omap_mmc_of_match[];
+
static int __init omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
@@ -1725,6 +1768,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
struct omap_hsmmc_host *host = NULL;
struct resource *res;
int ret, irq;
+ const struct of_device_id *match;
+
+ match = of_match_device(omap_mmc_of_match,pdev-dev);
+ if (match) {
+ pdata = of_get_hsmmc_pdata(pdev-dev);
+ if (match-data)
+ pdata-reg_offset = *(u16 *)match-data;
+ }
if (pdata == NULL) {
dev_err(pdev-dev, Platform Data is missing\n);
@@ -2120,12 +2171,29 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.runtime_resume = omap_hsmmc_runtime_resume,
};
+#if defined(CONFIG_OF)
+static u16 omap4_reg_offset = 0x100;
+
+static const struct of_device_id omap_mmc_of_match[] = {
Re: Linaro embedded Linux distro?
On Tue, Feb 21, 2012 at 7:37 AM, Wookey woo...@wookware.org wrote: +++ Kalle Vahlman [2012-02-21 11:06 +0200]: 2012/2/21 Amit Kucheria amit.kuche...@linaro.org Well minimal is all I care... not buildroot. But I would expect it to be 20M in size. Does that make sense or am i speaking gibberish :-) ? Doesn't the nano flavour take care of this? Nano rootfs is 33M compressed tarball which expands to 95M. That's small, not embedded ;) quite. You can get a debian-based distro down to about 56MB uncompressed: http://www.emdebian.org/grip/index.html (using the grip bloat-removal tools), or 90Mb without (corresponds to 'nano'). I guess something we can work on at the Nano image is to try to at least use the same grip tools to make it at least a bit smaller. Guess something we can work during 12.04, once we switch officially to armhf and Ubuntu precise-based builds. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
