Re: [PATCH v2 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev->id

[Rajendra Nayak]

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-mmc&m=132999677405098&w=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

[Pantelis Antoniou]

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

[Robert Lee]

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 
---
 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

[Ying-Chun Liu (PaulLiu)]

From: "Ying-Chun Liu (PaulLiu)" 

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 
Signed-off-by: Ying-Chun Liu (PaulLiu) 
Acked-by: Shawn Guo 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Samuel Ortiz 
---
 .../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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+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 regulator_init_data *initdata;
+};
+
+static int anatop_set_voltage(struct regulator_dev *reg, int min_uV,
+ int max_uV, unsigned *selector)
+{
+   struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
+   u32 val, sel;
+   int uv;
+
+   uv = min_uV;
+ 

Re: [PATCH v9] Regulator: Add Anatop regulator driver

[Mark Brown]

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

[Chris Ball]

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  
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

[Pawel Moll]

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

[Mark Brown]

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

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:24 Wed 07 Mar , Ying-Chun Liu (PaulLiu) wrote:
> From: "Ying-Chun Liu (PaulLiu)" 
> 
> 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 
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> Acked-by: Shawn Guo 
> Cc: Mark Brown 
> Cc: Liam Girdwood 
> Cc: Samuel Ortiz 
> ---
>  .../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

[yang gqyang]

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

[Jean-Christophe PLAGNIOL-VILLARD]

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

[Andrey Konovalov]

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

[john stultz]

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

[Guenter Roeck]

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 
> Signed-off-by: Ashish Jangam 

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 

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

[Sascha Hauer]

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 
---
 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;
-
-

Re: [PATCH v5 3/4] clk: introduce the common clock framework

[Turquette, Mike]

On Tue, Mar 6, 2012 at 11:00 AM, Sascha Hauer  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  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 st

Re: TI Landing Team kernel fails to build

[Andy Green]

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

[Ashish Jangam]

> 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 
> 
> 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

[Rajendra Nayak]

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

[Rajendra Nayak]

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 Nayak
---
  .../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 "mmc", 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: 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 @@
  #include
  #include
  #include
+#include
+#include
+#include
  #include
  #include
  #include
@@ -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[] = {
+   {
+   .compatible = "ti,omap2-hsmmc",
+   },
+   {
+   .compatible

Re: Linaro embedded Linux distro?

[Ricardo Salveti]

On Tue, Feb 21, 2012 at 7:37 AM, Wookey  wrote:
> +++ Kalle Vahlman [2012-02-21 11:06 +0200]:
>> 2012/2/21 Amit Kucheria 
>> >
>> > > 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