Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

[Rajendra Nayak]

On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:

* Rajendra Nayak  [111214 03:24]:

Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Acked-by: Rob Herring
Signed-off-by: Rajendra Nayak


This we can't merge because this breaks serial console for
omap2 because you're not adding the omap2 specific dtsi
entries for omap2..


But we never had omap2 working with DT, because we never added
a .dtsi file for omap2 or a .dts file for any omap2 board variants.

Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
with boards limited to omap3beagle/omap4Panda and omap4sdp.

So when we do add base support for omap2, we could update those
with the serial entries.




--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);

-   omap_serial_init();
omap_sdrc_init(NULL, NULL);

of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);


..and you're removing the call for omap_serial_init.

Please just update this patch with the omap2 entries
as well. Other than that looks good to me.

Tony



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: git oddness

[Andy Doan]

On 12/14/2011 08:06 PM, Tom Gall wrote:
> Hi All,
> 
> I'm trying to push some code to my repo on git.linaro.org and it's
> like the repo is silently failing Note the following:
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
> ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
> android:origin/1.2-beta-linaro-andoid
> Counting objects: 5, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 429 bytes, done.
> Total 3 (delta 2), reused 0 (delta 0)
> To ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
>746c51b..95ed21e  android -> origin/1.2-beta-linaro-andoid
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status
> # On branch android
> # Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit.
> #
> nothing to commit (working directory clean)
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
> ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
> android:origin/1.2-beta-linaro-andoid
> Everything up-to-date
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch
> * android
>   master
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch -r
>   origin/1.1.0-linaro
>   origin/1.1.1-linaro
>   origin/1.1.1-linaro-android
>   origin/1.2-beta-linaro-andoid
>   origin/HEAD -> origin/master
>   origin/master
> 
> git log does correctly show the commit on the local branch:
> 
> commit 95ed21e84965f859da0792558742f9cbf9d4ac7a
> Author: Tom Gall 
> Date:   Wed Dec 14 19:20:49 2011 -0600
> 
> Remove config.h since it was conflicting with other Android
> components. From cyang.
> 
> 
> ideas? suggestions?
> 

If you didn't create the local branch with the --tracking you might need
to be explicit with your push like:

$ git push origin/1.2-beta-linaro-andoid HEAD

I think you could use "android" instead of "HEAD" but they'd be
equivalent since you are on that branch.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: git oddness

[Andy Green]

On 12/15/2011 11:08 AM, Somebody in the thread at some point said:

On Wed, Dec 14, 2011 at 8:55 PM, Yasushi SHOJI  wrote:

Hi,

At Wed, 14 Dec 2011 20:06:14 -0600,
Tom Gall wrote:


I'm trying to push some code to my repo on git.linaro.org and it's
like the repo is silently failing Note the following:



To ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git



   Push  URL: 
git://git.linaro.org/people/tomgall/libjpeg-turbo/libjpeg-turbo.git


Is it because these two paths are not the same?  You're pushing to one 
place on the remote filesystem but pulling / gitwebbing from another?


-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: git oddness

[Tom Gall]

On Wed, Dec 14, 2011 at 8:55 PM, Yasushi SHOJI  wrote:
> Hi,
>
> At Wed, 14 Dec 2011 20:06:14 -0600,
> Tom Gall wrote:
>>
>> I'm trying to push some code to my repo on git.linaro.org and it's
>> like the repo is silently failing Note the following:
>>
>> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
>> ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
>> android:origin/1.2-beta-linaro-andoid
>> Counting objects: 5, done.
>> Delta compression using up to 4 threads.
>> Compressing objects: 100% (3/3), done.
>> Writing objects: 100% (3/3), 429 bytes, done.
>> Total 3 (delta 2), reused 0 (delta 0)
>> To ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
>>    746c51b..95ed21e  android -> origin/1.2-beta-linaro-andoid
>>
>> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status
>> # On branch android
>> # Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit.
>> #
>> nothing to commit (working directory clean)
> [...]
>> ideas? suggestions?
>
> if your origin and the repo you are pushing to is different, git tells
> you that your local is ahead of the origin, because the origin is not
> updated yet.
>
> $ git remote show origin
>

Hi Yashi,

Thanks for the response.

Hmm this looks right. The git web interface isn't showing the new
commit nor does the new commit appear when a fresh clone etc is
obtained.

tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git remote show origin
* remote origin
  Fetch URL: git://git.linaro.org/people/tomgall/libjpeg-turbo/libjpeg-turbo.git
  Push  URL: git://git.linaro.org/people/tomgall/libjpeg-turbo/libjpeg-turbo.git
  HEAD branch: master
  Remote branches:
1.1.0-linaro   tracked
1.1.1-linaro   tracked
1.1.1-linaro-android   tracked
1.2-beta-linaro-andoid tracked
master tracked
  Local branches configured for 'git pull':
android merges with remote 1.2-beta-linaro-andoid
master  merges with remote master
  Local ref configured for 'git push':
master pushes to master (up to date)


> might help.
> --
>            yashi



-- 
Regards,
Tom

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: git oddness

[Yasushi SHOJI]

Hi,

At Wed, 14 Dec 2011 20:06:14 -0600,
Tom Gall wrote:
> 
> I'm trying to push some code to my repo on git.linaro.org and it's
> like the repo is silently failing Note the following:
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
> ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
> android:origin/1.2-beta-linaro-andoid
> Counting objects: 5, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 429 bytes, done.
> Total 3 (delta 2), reused 0 (delta 0)
> To ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
>746c51b..95ed21e  android -> origin/1.2-beta-linaro-andoid
> 
> tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status
> # On branch android
> # Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit.
> #
> nothing to commit (working directory clean)
[...]
> ideas? suggestions?

if your origin and the repo you are pushing to is different, git tells
you that your local is ahead of the origin, because the origin is not
updated yet.

$ git remote show origin

might help.
--
yashi

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

git oddness

[Tom Gall]

Hi All,

I'm trying to push some code to my repo on git.linaro.org and it's
like the repo is silently failing Note the following:

tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
android:origin/1.2-beta-linaro-andoid
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 429 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
   746c51b..95ed21e  android -> origin/1.2-beta-linaro-andoid

tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git status
# On branch android
# Your branch is ahead of 'origin/1.2-beta-linaro-andoid' by 1 commit.
#
nothing to commit (working directory clean)

tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git push
ssh://tomg...@git.linaro.org/~/public_git/libjpeg-turbo/libjpeg-turbo.git
android:origin/1.2-beta-linaro-andoid
Everything up-to-date

tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch
* android
  master
tgall@mars:~/libjpeg-turbo-android/libjpeg-turbo$ git branch -r
  origin/1.1.0-linaro
  origin/1.1.1-linaro
  origin/1.1.1-linaro-android
  origin/1.2-beta-linaro-andoid
  origin/HEAD -> origin/master
  origin/master

git log does correctly show the commit on the local branch:

commit 95ed21e84965f859da0792558742f9cbf9d4ac7a
Author: Tom Gall 
Date:   Wed Dec 14 19:20:49 2011 -0600

Remove config.h since it was conflicting with other Android
components. From cyang.


ideas? suggestions?

-- 
Regards,
Tom

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

[Tony Lindgren]

* Rajendra Nayak  [111214 03:24]:
> Pass minimal data needed for console boot, from dt, for
> OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
> static initialization from generic board file.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Rajendra Nayak 

This we can't merge because this breaks serial console for
omap2 because you're not adding the omap2 specific dtsi
entries for omap2..

> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
>   if (node)
>   irq_domain_add_simple(node, 0);
>  
> - omap_serial_init();
>   omap_sdrc_init(NULL, NULL);
>  
>   of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);

..and you're removing the call for omap_serial_init.

Please just update this patch with the omap2 entries
as well. Other than that looks good to me.

Tony

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Turquette, Mike]

On Tue, Dec 13, 2011 at 8:52 PM, Ryan Mallon  wrote:
> On 14/12/11 14:53, Mike Turquette wrote:
>> +void __clk_unprepare(struct clk *clk)
>> +{
>> +     if (!clk)
>> +             return;
>> +
>> +     if (WARN_ON(clk->prepare_count == 0))
>> +             return;
>> +
>> +     if (--clk->prepare_count > 0)
>> +             return;
>> +
>> +     WARN_ON(clk->enable_count > 0);
>> +
>> +     if (clk->ops->unprepare)
>> +             clk->ops->unprepare(clk);
>> +
>> +     __clk_unprepare(clk->parent);
>> +}
>
>
> I think you can rewrite this to get rid of the recursion as below:
>
>        while (clk) {
>                if (WARN_ON(clk->prepare_count == 0))
>                        return;
>
>                if (--clk->prepare_count > 0)
>                        return;
>
>                WARN_ON(clk->enable_count > 0)
>
>                if (clk->ops->unprepare)
>                        clk->ops->unprepare(clk);
>
>                clk = clk->parent;
>        }

Looks good.  I'll roll into next set.

> Also, should this function be static?

No, since platform clk code will occasionally be forced to call
clk_(un)prepare while the prepare_lock mutex is held.  For a valid
example see:
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=b2412574b63829944593c1a7a6eda5fa4350686f;hb=738bde65918ae1ac743b1498801da0b860e2ee32#l461

>> +void clk_unprepare(struct clk *clk)
>> +{
>> +     mutex_lock(&prepare_lock);
>> +     __clk_unprepare(clk);
>> +     mutex_unlock(&prepare_lock);
>> +}
>> +EXPORT_SYMBOL_GPL(clk_unprepare);
>> +
>> +int __clk_prepare(struct clk *clk)
>> +{
>> +     int ret = 0;
>> +
>> +     if (!clk)
>> +             return 0;
>> +
>> +     if (clk->prepare_count == 0) {
>> +             ret = __clk_prepare(clk->parent);
>> +             if (ret)
>> +                     return ret;
>> +
>> +             if (clk->ops->prepare) {
>> +                     ret = clk->ops->prepare(clk);
>> +                     if (ret) {
>> +                             __clk_unprepare(clk->parent);
>> +                             return ret;
>> +                     }
>> +             }
>> +     }
>> +
>> +     clk->prepare_count++;
>> +
>> +     return 0;
>> +}
>
>
> This is unfortunately a bit tricky to remove the recursion from without
> keeping a local stack of the clocks leading up to first unprepared
> client :-/.
>
> Again, should this be static? What outside this file needs to
> prepare/unprepare clocks without the lock held?

Same as above.

>> +int clk_prepare(struct clk *clk)
>> +{
>> +     int ret;
>> +
>> +     mutex_lock(&prepare_lock);
>> +     ret = __clk_prepare(clk);
>> +     mutex_unlock(&prepare_lock);
>> +
>> +     return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(clk_prepare);
>> +
>> +void __clk_disable(struct clk *clk)
>> +{
>> +     if (!clk)
>> +             return;
>> +
>> +     if (WARN_ON(clk->enable_count == 0))
>> +             return;
>> +
>> +     if (--clk->enable_count > 0)
>> +             return;
>> +
>> +     if (clk->ops->disable)
>> +             clk->ops->disable(clk);
>> +
>> +     if (clk->parent)
>> +             __clk_disable(clk->parent);
>
>
> Easy to get rid of the recursion here. Also should be static?

Yes the enable/disable should be static.  I originally made them
non-static when I converted the prepare/unprepare set, but of course
it's possible to call these with the prepare_lock mutex held so I'll
fix this up in the next set.

>> +long clk_round_rate(struct clk *clk, unsigned long rate)
>> +{
>> +     if (clk && clk->ops->round_rate)
>> +             return clk->ops->round_rate(clk, rate, NULL);
>> +
>> +     return rate;
>> +}
>> +EXPORT_SYMBOL_GPL(clk_round_rate);
>
>
> If the clock doesn't provide a round rate function then shouldn't we
> return an error to the caller? Telling the caller that the rate is
> perfect might lead to odd driver bugs?

Yes this code should so something better.  I've been focused mostly on
the "write" aspects of the clk API (set_rate, set_parent,
enable/disable and prepare/unprepare) and less on the "read" aspects
of the clk API (get_rate, get_parent, round_rate, etc).  I'll give
this a closer look for the next set.

>> +/**
>> + * DOC: Using the CLK_PARENT_SET_RATE flag
>> + *
>> + * __clk_set_rate changes the child's rate before the parent's to more
>> + * easily handle failure conditions.
>> + *
>> + * This means clk might run out of spec for a short time if its rate is
>> + * increased before the parent's rate is updated.
>> + *
>> + * To prevent this consider setting the CLK_GATE_SET_RATE flag on any
>> + * clk where you also set the CLK_PARENT_SET_RATE flag
>> + */
>
>
> Is this standard kerneldoc format?

It is:
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=Documentation/kernel-doc-nano-HOWTO.txt;h=3d8a97747f7731c801ca7d3a1483858feeb76b6c;hb=refs/heads/v3.2-rc5-clkv4-omap#l298

>> +struct clk *__clk_set_rate(struct clk *clk, unsigned long rate)
>
>
> static?

I'll make i

Re: [PATCH v3 0/4] OMAP serial device tree support

[Greg KH]

On Wed, Dec 14, 2011 at 05:18:43PM +, Alan Cox wrote:
> On Wed, 14 Dec 2011 07:20:13 -0800
> Kevin Hilman  wrote:
> 
> > Greg, Alan,
> > 
> > Rajendra Nayak  writes:
> > 
> > > v3 is rebased on top of the latest serial runtime
> > > patches[1] and boot tested with/without DT on OMAP4
> > > SDP and OMAP4 Panda boards.
> > 
> > With your ack on the drivers/tty/* stuff, I can queue this via the
> > OMAP tree on top of the runtime PM conversion that it depends on.
> 
> Go for it

Fine with me as well.

greg k-h

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [Patch 06/06] Regulator: DA9052/53 Regulator support v5

[Mark Brown]

On Fri, Dec 09, 2011 at 07:48:20PM +0530, Ashish Jangam wrote:
> The Dialog PMIC has below featured regulators:-
> DA9052-BC - 4 DVS Buck converters 0.5V - 3.6V upto 1Amp.
> DA9053-AA/BX - 4 DVS Buck converters 0.5V - 2.5V upto 3Amp.
> DA9052/53 - 10 Programmable LDO's High PSSR, 1% accuracy.

Applied but there are some small issues - please send incremental
patches fixing these.

> + if (chip_id == DA9052) {
> + for (i = 0; i < ARRAY_SIZE(da9052_regulator_info); i++) {
> + info = &da9052_regulator_info[i];
> + if (info->reg_desc.id == id)
> + return info;
> + }
> + } else {
> + for (i = 0; i < ARRAY_SIZE(da9053_regulator_info); i++) {
> + info = &da9053_regulator_info[i];
> + if (info->reg_desc.id == id)
> + return info;
> + }
> + }

This would be better written as a switch statement.

> + regulator = kzalloc(sizeof(struct da9052_regulator), GFP_KERNEL);
> + if (!regulator)
> + return -ENOMEM;

You should use devm_kzalloc().

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 0/4] OMAP serial device tree support

[Alan Cox]

On Wed, 14 Dec 2011 07:20:13 -0800
Kevin Hilman  wrote:

> Greg, Alan,
> 
> Rajendra Nayak  writes:
> 
> > v3 is rebased on top of the latest serial runtime
> > patches[1] and boot tested with/without DT on OMAP4
> > SDP and OMAP4 Panda boards.
> 
> With your ack on the drivers/tty/* stuff, I can queue this via the
> OMAP tree on top of the runtime PM conversion that it depends on.

Go for it

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework

[Nicolas Pitre]

On Wed, 14 Dec 2011, Amit Kachhap wrote:

> Hi Nicolas,
> 
> Please pull my samsung thermal implementation work from git repository
> (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling).
> Some of the patches are under review and some are in mainline in 3.2 rc*
> version.
> It is all based on the tip of your tree.

Merged.  There were minor conflicts in Kconfig and Makefile with your 
previous patches that I fixed up.


Nicolas

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework

[Nicolas Pitre]

On Wed, 14 Dec 2011, Amit Kachhap wrote:

> Hi Nicolas,
> 
> Is it possible for you to add these 2 patches for this month release? I am
> not able to give you the git link as there is seems some problem with the
> linaro git server.
> Also I attached the patches in case required.

I merged them.  However it would be a good idea if you could gather at 
least one Acked-by tag from someone else who is also familiar with that 
code next time.


Nicolas

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework

[Amit Kachhap]

Hi Nicolas,

Please pull my samsung thermal implementation work from git repository
(git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling).
Some of the patches are under review and some are in mainline in 3.2 rc*
version.
It is all based on the tip of your tree.

The patches are added since commit id
971be11492b1e248798f7078592b1fa0dfbf3534

Thanks,
Amit Daniel

On 14 December 2011 20:11, Amit Kachhap  wrote:

> Hi Nicolas,
>
> Is it possible for you to add these 2 patches for this month release? I am
> not able to give you the git link as there is seems some problem with the
> linaro git server.
> Also I attached the patches in case required.
>
> Thanks,
> Amit Daniel
>
>
> On 13 December 2011 20:43, Amit Daniel Kachhap 
> wrote:
> > PATCH 1)  [thermal: Add a new trip type to use cooling device instance
> number]
> > This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
> > cooling device instance number and may be helpful for cpufreq cooling
> devices
> > to take the correct cooling action.
> >
> > PATCH 2)  [thermal: Add generic cpu cooling implementation]
> > This patch adds generic cpu cooling low level implementation through
> frequency
> > clipping and cpu hotplug. In future, other cpu related cooling devices
> may be
> > added here. An ACPI version of this already
> exists(drivers/acpi/processor_thermal.c).
> > But this will be useful for platforms like ARM using the generic thermal
> interface
> > along with the generic cpu cooling devices. The cooling device
> registration API's
> > return cooling device pointers which can be easily binded with the
> thermal zone
> > trip points.
> >
> >
> > Amit Daniel Kachhap (2):
> >  thermal: Add a new trip type to use cooling device instance number
> >  thermal: Add generic cpu cooling implementation
> >
> >  Documentation/thermal/cpu-cooling-api.txt |   52 +
> >  Documentation/thermal/sysfs-api.txt   |4 +-
> >  drivers/thermal/Kconfig   |   11 +
> >  drivers/thermal/Makefile  |1 +
> >  drivers/thermal/cpu_cooling.c |  302
> +
> >  drivers/thermal/thermal_sys.c |   27 +++-
> >  include/linux/cpu_cooling.h   |   45 +
> >  include/linux/thermal.h   |1 +
> >  8 files changed, 440 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
> >  create mode 100644 drivers/thermal/cpu_cooling.c
> >  create mode 100644 include/linux/cpu_cooling.h
> >
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Problems with timers with linux-next on snowball

[Linus Walleij]

On Wed, Dec 14, 2011 at 4:27 PM, Daniel Lezcano
 wrote:

> while trying the linux-next at the point it boots (commit
> be9b7335e70696bee731c152429b1737e42fe163, after v3.2-rc4), I noticed the
> timers were not working properly with CONFIG_NO_HZ.
>
> It is easy to reproduce with 'time sleep 1' where the timer expires 1, 2
> or 3 seconds later.
>
> It seems that does not happen with linux-linaro-3.1 but I was able to
> reproduce the problem on a vanilla kernel 3.1.5.
>
> Is it a known problem ?

Sleeps are only guaranteed at max speed.

Since this is jiffy-based sleep I think these patches (which I just updated
and put into Russell's patch tracker) are needed:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7210/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7211/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7212/1

If these patches solve your issue please ACK them on the linux-arm-kernel
maillist, so Russell et al can see that they solve problems for people...

You will then encounter the same problem at the udelay(), mdelay() etc
to which these patches provide a solution (with an additional ux500 MTU
patch that is somewhere in our tree):
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6873/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6874/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6875/1

Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ANN: git.linaro.org going down for up to 1h

[Jon Medhurst (Tixy)]

On Wed, 2011-12-14 at 15:06 +, Peter Maydell wrote:
> On 14 December 2011 14:46, Jon Medhurst (Tixy)  wrote:
> > On Wed, 2011-12-14 at 15:38 +0100, Danilo Šegan wrote:
> >> We should be back up, with everything ready to go.  Do note that the ssh
> >> key has changed, so you will be prompted with warning notices about
> >> that.
> 
> > So all peoples personal git repositories are in-accessible via git
> > because they are still on mombin. So we have to copy these over?
> 
> I'd assumed they were all going to be copied over, since it was
> an officially advertised way of setting up a git repo there.

It looks like they've been copied over now.

-- 
Tixy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Problems with timers with linux-next on snowball

[Daniel Lezcano]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

while trying the linux-next at the point it boots (commit
be9b7335e70696bee731c152429b1737e42fe163, after v3.2-rc4), I noticed the
timers were not working properly with CONFIG_NO_HZ.

It is easy to reproduce with 'time sleep 1' where the timer expires 1, 2
or 3 seconds later.

It seems that does not happen with linux-linaro-3.1 but I was able to
reproduce the problem on a vanilla kernel 3.1.5.

Is it a known problem ?

Thanks
  -- Daniel

- -- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO6MBZAAoJEAKBbMCpUGYAUI4IAMOMK+90biBp+1tj/tY/A1is
FJEQXi1wzhLGo23gIh6D65dcLRsxr3TSdvcHGz2dzB1ZquaaUUJCv8vM909bCSF8
y3dH4WIzEF/rNPcyI2WgtjDq/KVcZK28in8XresC7yC0fEmEB6fHRvQoqBk5fhsb
jWPM8nGbyXJpBFK4yCZRgrz2TYsDInyazplHtGzABMj9j374Wk6yGAsDnCd6/XJM
dArM2IP4Mcd7Zv6m4kJ2vncTCnKR+D4wVTXdRrXTqAd8byfKBgyUHxY/cviXirHp
03nSKJYaw683YhdJ0JVQQJfdOEl+kaCDOkCEV5MUUiSCRors1Z8FcK+DAPAjG84=
=spxQ
-END PGP SIGNATURE-

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 0/4] OMAP serial device tree support

[Kevin Hilman]

Greg, Alan,

Rajendra Nayak  writes:

> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.

With your ack on the drivers/tty/* stuff, I can queue this via the OMAP
tree on top of the runtime PM conversion that it depends on.

Thanks,

Kevin

> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
>
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
>
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
>
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
>
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
>
> Rajendra Nayak (4):
>   omap-serial: Get rid of all pdev->id usage
>   omap-serial: Use default clock speed (48Mhz) if not specified
>   omap-serial: Add minimal device tree support
>   ARM: omap: pass minimal SoC/board data for UART from dt
>
>  .../devicetree/bindings/serial/omap_serial.txt |   10 +++
>  arch/arm/boot/dts/omap3.dtsi   |   31 
>  arch/arm/boot/dts/omap4.dtsi   |   28 +++
>  arch/arm/mach-omap2/board-generic.c|1 -
>  drivers/tty/serial/omap-serial.c   |   80 +++
>  5 files changed, 132 insertions(+), 18 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 v3 0/4] OMAP serial device tree support

[Govindraj]

Hi Rajendra,

On Wed, Dec 14, 2011 at 5:25 PM, Rajendra Nayak  wrote:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
>
> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
>
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
>
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
>
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
>
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
>

I merged this patch series to a tmp_intg branch [1]
having uart runtime changes and sanity tested on
3430sdp/zoom3/panda seems fine.

--
Thanks,
Govindraj.R

[1]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/tmp_rc4_uart_pm_intg

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ANN: git.linaro.org going down for up to 1h

[Peter Maydell]

On 14 December 2011 14:46, Jon Medhurst (Tixy)  wrote:
> On Wed, 2011-12-14 at 15:38 +0100, Danilo Šegan wrote:
>> We should be back up, with everything ready to go.  Do note that the ssh
>> key has changed, so you will be prompted with warning notices about
>> that.

> So all peoples personal git repositories are in-accessible via git
> because they are still on mombin. So we have to copy these over?

I'd assumed they were all going to be copied over, since it was
an officially advertised way of setting up a git repo there.

thanks
-- PMM

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ANN: git.linaro.org going down for up to 1h

[Jon Medhurst (Tixy)]

On Wed, 2011-12-14 at 15:38 +0100, Danilo Šegan wrote:
> Hi all,
> 
> У сре, 14. 12 2011. у 13:08 +0100, Danilo Šegan пише:
> 
> > This means that we'll be shutting off any git access to git.linaro.org
> > shortly (at 12:30 UTC), and we expect a downtime of 30 minutes to get
> > new machine up (but let's keep the window of 1h just in case).  If you
> > have any urgent issues, please shout before we go for the downtime.
> 
> We should be back up, with everything ready to go.  Do note that the ssh
> key has changed, so you will be prompted with warning notices about
> that.
> 
> The new RSA key's fingerprint is
> 
>   62:1e:b1:73:39:f3:9d:eb:81:87:b8:f8:f7:a8:79:97.
> 
> 
> Everything else that lived on git.linaro.org has remained on the old
> machine which is available as mombin.canonical.com 

So all peoples personal git repositories are in-accessible via git
because they are still on mombin. So we have to copy these over?

-- 
Tixy 


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework

[Amit Kachhap]

Hi Nicolas,

Is it possible for you to add these 2 patches for this month release? I am
not able to give you the git link as there is seems some problem with the
linaro git server.
Also I attached the patches in case required.

Thanks,
Amit Daniel

On 13 December 2011 20:43, Amit Daniel Kachhap 
wrote:
> PATCH 1)  [thermal: Add a new trip type to use cooling device instance
number]
> This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
> cooling device instance number and may be helpful for cpufreq cooling
devices
> to take the correct cooling action.
>
> PATCH 2)  [thermal: Add generic cpu cooling implementation]
> This patch adds generic cpu cooling low level implementation through
frequency
> clipping and cpu hotplug. In future, other cpu related cooling devices
may be
> added here. An ACPI version of this already
exists(drivers/acpi/processor_thermal.c).
> But this will be useful for platforms like ARM using the generic thermal
interface
> along with the generic cpu cooling devices. The cooling device
registration API's
> return cooling device pointers which can be easily binded with the
thermal zone
> trip points.
>
>
> Amit Daniel Kachhap (2):
>  thermal: Add a new trip type to use cooling device instance number
>  thermal: Add generic cpu cooling implementation
>
>  Documentation/thermal/cpu-cooling-api.txt |   52 +
>  Documentation/thermal/sysfs-api.txt   |4 +-
>  drivers/thermal/Kconfig   |   11 +
>  drivers/thermal/Makefile  |1 +
>  drivers/thermal/cpu_cooling.c |  302
+
>  drivers/thermal/thermal_sys.c |   27 +++-
>  include/linux/cpu_cooling.h   |   45 +
>  include/linux/thermal.h   |1 +
>  8 files changed, 440 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/thermal/cpu-cooling-api.txt
>  create mode 100644 drivers/thermal/cpu_cooling.c
>  create mode 100644 include/linux/cpu_cooling.h
>
From 8719c5aca30fc986a7e89c600fa54d340342e9e2 Mon Sep 17 00:00:00 2001
From: Amit Daniel Kachhap 
Date: Thu, 1 Dec 2011 18:51:39 +0530
Subject: [RFC PATCH 1/2] thermal: Add a new trip type to use cooling device instance number

This patch adds a new trip type THERMAL_TRIP_STATE_ACTIVE. This
trip behaves same as THERMAL_TRIP_ACTIVE but also passes the cooling
device instance number. This helps the cooling device registered as
different instances to perform appropriate cooling action decision in
the set_cur_state call back function.

Also since the trip temperature's are in ascending order so some logic
is put in place to skip the un-necessary checks.

Signed-off-by: Amit Daniel Kachhap 
---
 Documentation/thermal/sysfs-api.txt |4 ++--
 drivers/thermal/thermal_sys.c   |   27 ++-
 include/linux/thermal.h |1 +
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index b61e46f..5c1d44e 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -184,8 +184,8 @@ trip_point_[0-*]_temp
 
 trip_point_[0-*]_type
 	Strings which indicate the type of the trip point.
-	E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
-	thermal zone.
+	E.g. it can be one of critical, hot, passive, active[0-1],
+	state-active[0-*] for ACPI thermal zone.
 	RO, Optional
 
 cdev[0-*]
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
index dd9a574..72b1ab3 100644
--- a/drivers/thermal/thermal_sys.c
+++ b/drivers/thermal/thermal_sys.c
@@ -192,6 +192,8 @@ trip_point_type_show(struct device *dev, struct device_attribute *attr,
 		return sprintf(buf, "passive\n");
 	case THERMAL_TRIP_ACTIVE:
 		return sprintf(buf, "active\n");
+	case THERMAL_TRIP_STATE_ACTIVE:
+		return sprintf(buf, "state-active\n");
 	default:
 		return sprintf(buf, "unknown\n");
 	}
@@ -1035,7 +1037,7 @@ EXPORT_SYMBOL(thermal_cooling_device_unregister);
 void thermal_zone_device_update(struct thermal_zone_device *tz)
 {
 	int count, ret = 0;
-	long temp, trip_temp;
+	long temp, trip_temp, max_state, last_trip_change = 0;
 	enum thermal_trip_type trip_type;
 	struct thermal_cooling_device_instance *instance;
 	struct thermal_cooling_device *cdev;
@@ -1086,6 +1088,29 @@ void thermal_zone_device_update(struct thermal_zone_device *tz)
 	cdev->ops->set_cur_state(cdev, 0);
 			}
 			break;
+		case THERMAL_TRIP_STATE_ACTIVE:
+			list_for_each_entry(instance, &tz->cooling_devices,
+	node) {
+if (instance->trip != count)
+	continue;
+
+if (temp <= last_trip_change)
+	continue;
+
+cdev = instance->cdev;
+cdev->ops->get_max_state(cdev, &max_state);
+
+if ((temp >= trip_temp) &&
+		((count + 1) <= max_state))
+	cdev->ops->set_cur_state(cdev,
+count + 1);
+else if ((temp < trip_temp) &&
+			(count <= max_state))
+	cdev->ops->set_cur_state(cdev, count)

Re: ANN: git.linaro.org going down for up to 1h

[Danilo Šegan]

Hi all,

У сре, 14. 12 2011. у 13:08 +0100, Danilo Šegan пише:

> This means that we'll be shutting off any git access to git.linaro.org
> shortly (at 12:30 UTC), and we expect a downtime of 30 minutes to get
> new machine up (but let's keep the window of 1h just in case).  If you
> have any urgent issues, please shout before we go for the downtime.

We should be back up, with everything ready to go.  Do note that the ssh
key has changed, so you will be prompted with warning notices about
that.

The new RSA key's fingerprint is

  62:1e:b1:73:39:f3:9d:eb:81:87:b8:f8:f7:a8:79:97.


Everything else that lived on git.linaro.org has remained on the old
machine which is available as mombin.canonical.com (or any other of the
hostnames it runs, such as snapshots.linaro.org or status.linaro.org).
That machine has not had the key changed.

Cheers,
Danilo


signature.asc
Description: This is a digitally signed message part
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 05/06] Power: DA9052 Battery module V6

[Mark Brown]

On Wed, Dec 14, 2011 at 05:42:09PM +0400, Anton Vorontsov wrote:

> I presume this depends on other patches, so I'm fine if this goes via
> non-battery tree,

There should be no direct dependencies for new MFDs - the Kconfig
required to depend on the MFD core means that the drivers can't be
selected until the core appears.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v3 0/4] OMAP serial device tree support

[Rob Herring]

On 12/14/2011 05:55 AM, Rajendra Nayak wrote:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
> 
> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
> 
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
> 
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
> 
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
> 
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
> 
> Rajendra Nayak (4):
>   omap-serial: Get rid of all pdev->id usage
>   omap-serial: Use default clock speed (48Mhz) if not specified
>   omap-serial: Add minimal device tree support
>   ARM: omap: pass minimal SoC/board data for UART from dt
> 
>  .../devicetree/bindings/serial/omap_serial.txt |   10 +++
>  arch/arm/boot/dts/omap3.dtsi   |   31 
>  arch/arm/boot/dts/omap4.dtsi   |   28 +++
>  arch/arm/mach-omap2/board-generic.c|1 -
>  drivers/tty/serial/omap-serial.c   |   80 +++
>  5 files changed, 132 insertions(+), 18 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

Looks good. For the series:

Reviewed-by: Rob Herring 


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Thomas Gleixner]

On Tue, 13 Dec 2011, Mike Turquette wrote:
> +void __clk_unprepare(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->prepare_count == 0))
> + return;
> +
> + if (--clk->prepare_count > 0)
> + return;
> +
> + WARN_ON(clk->enable_count > 0);

So this leaves the clock enable count set. I'm a bit wary about
that. Shouldn't it either return (including bumping the prepare_count
again) or call clk_disable() ?

> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent.  It is up to the caller to hold the
> + * prepare_lock, if desired.  Returns NULL if clk is NULL.

Holding the prepare lock in the caller will deadlock. So it's not a
real good idea to document it as an option :)

> + */
> +struct clk *clk_get_parent(struct clk *clk)
> +{
> + struct clk *parent;
> +
> + if (!clk)
> + return NULL;
> +
> + mutex_lock(&prepare_lock);

> +/**
> + * clk_init - initialize the data structures in a struct clk
> + * @dev: device initializing this clk, placeholder for now
> + * @clk: clk being initialized
> + *
> + * Initializes the lists in struct clk, queries the hardware for the
> + * parent and rate and sets them both.  Adds the clk to the sysfs tree
> + * topology.
> + *
> + * Caller must populate clk->name and clk->flags before calling

I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.

Why can't we make struct clk a real cookie and confine the data
structure to the core code ?

That would change the init call to something like:

struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
 struct clk *parent)

And have:
struct clk_hw {
   struct clk_hw_ops *ops;
   const char*name;
   unsigned long flags;
};   

Implementers can do:
struct my_clk_hw {
   struct clk_hwhw;
   mydata;
};

And then change the clk ops callbacks to take struct clk_hw * as an
argument.

So the core code can allocate the clk data structure and you return a
real opaque cookie. You do the same thing for the basic gated clock in
one of the next patches, so doing it for struct clk itself is just
consequent.

> + * clk_init.  A key assumption in the call to .get_parent is that clks
> + * are being initialized in-order.

We should not require that, see below.

> + */

> +void clk_init(struct device *dev, struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + INIT_HLIST_HEAD(&clk->children);
> + INIT_HLIST_NODE(&clk->child_node);
> +
> + mutex_lock(&prepare_lock);
> +
> + /*
> +  * .get_parent is mandatory for populating .parent for clks with
> +  * multiple possible parents.  For clks with a fixed parent
> +  * .get_parent is not mandatory and .parent can be statically
> +  * initialized
> +  */
> + if (clk->ops->get_parent)
> + clk->parent = clk->ops->get_parent(clk);
> +
> + /* clks without a parent are considered root clks */

I'd rather prefer that root clocks are explicitely marked with a flag
instead of relying on clk->parent being NULL.

> + if (clk->parent)
> + hlist_add_head(&clk->child_node,
> + &clk->parent->children);
> + else
> + hlist_add_head(&clk->child_node, &clk_root_list);

You could put clocks which have no parent and are not marked as root
clock onto a separate list clk_orphaned or such. You might need this
for handling clocks which are disconnected from any parent runtime as
well.

And to avoid the whole in-order initialization issue, you could change
clk_init to:

struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
 unsigned long flags, const char *parent_name)

Then you can lookup the requested parent by name. If that fails, you
put the clock into the orphaned list. When a new clock is initialized,
then you walk the orphaned list and check whether something is waiting
for that clock.

To handle multi-parent clocks you need to go one step further and add:

struct clk_hw {
   struct clk_hw_ops *ops;
   const char*name;
   const char**possible_parents;
};

You also require a get_parent_idx() function in clk_hw_ops. So when
clk_init() is called with parent_name = NULL and get_parent_idx() is
implemented, then you call it and the clock returns you the index of
the possible_parents array. If that parent clock is not yet
registered, you store the requested name and do the lookup when new
clocks are registered.

That has also the advantage, that you can validate parent settings
upfront and for setting the parent during runtime, you don't 

Re: [PATCH 05/06] Power: DA9052 Battery module V6

[Fabio Estevam]

On Wed, Dec 14, 2011 at 10:27 AM, Ashish Jangam
 wrote:

> +static u32 const vc_tbl[3][68][2] = {
> +       /* For temperature 10 degree celisus*/

s/celisus/Celsius

Same on other places.

Regards,

Fabio Estevam

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 05/06] Power: DA9052 Battery module V6

[Ashish Jangam]

Driver for DA9052 battery charger. This driver depends on DA9052 MFD core dirver
for definitions and methods.

This patch is functionally tested on Samsung SMDKV6410.

Signed-off-by: David Dajun Chen 
Signed-off-by: Ashish Jangam 
---
As per the thread https://lkml.org/lkml/2011/11/9/42 a transceiver notifications
will be added in the usb gadget driver to support setting of USB charge current
limit in the battery driver. This patch adds logic to support that notification.
Later when usb gadget driver gets modified this driver needs modification only
for registration with event notification.
---
Changes since v5
- Added notifier callback for setting USB charging current limit
Changes since v4
- Remove unnecessary type cast
- Improve code readability
Changes since v3
- Included power_supply.h file
- Corrected the definition of DA9052_BAT_THRESHOLD macro
- Changed definition of charger_type_enum
- Added API da9052_battery_read_end_current
- Added API da9052_battery_check_status
- Changed the way of handling the interrupts in da9052_bat_irq
Changes since v2
- Correct code styling for inline functions
- Remove averaging algorithm
- Set use_for_apm thru board specific parameter
---
 drivers/power/Kconfig  |7 +
 drivers/power/Makefile |1 +
 drivers/power/da9052-battery.c |  665 
 3 files changed, 673 insertions(+), 0 deletions(-)
 create mode 100644 drivers/power/da9052-battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 9f88641..9696502 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -150,6 +150,13 @@ config BATTERY_DA9030
  Say Y here to enable support for batteries charger integrated into
  DA9030 PMIC.
 
+config BATTERY_DA9052
+   tristate "Dialog DA9052 Battery"
+   depends on PMIC_DA9052
+   help
+ Say Y here to enable support for batteries charger integrated into
+ DA9052 PMIC.
+
 config BATTERY_MAX17040
tristate "Maxim MAX17040 Fuel Gauge"
depends on I2C
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b4af13d..c570e20 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_BATTERY_WM97XX)  += wm97xx_battery.o
 obj-$(CONFIG_BATTERY_BQ20Z75)  += bq20z75.o
 obj-$(CONFIG_BATTERY_BQ27x00)  += bq27x00_battery.o
 obj-$(CONFIG_BATTERY_DA9030)   += da9030_battery.o
+obj-$(CONFIG_BATTERY_DA9052)   += da9052-battery.o
 obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
 obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
 obj-$(CONFIG_BATTERY_Z2)   += z2_battery.o
diff --git a/drivers/power/da9052-battery.c b/drivers/power/da9052-battery.c
new file mode 100644
index 000..37b2840
--- /dev/null
+++ b/drivers/power/da9052-battery.c
@@ -0,0 +1,665 @@
+/*
+ * Batttery Driver for Dialog DA9052 PMICs
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+
+ * Author: David Dajun Chen 
+ *
+ *  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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* STATIC CONFIGURATION */
+#define DA9052_BAT_CUTOFF_VOLT 2800
+#define DA9052_BAT_TSH 62000
+#define DA9052_BAT_LOW_CAP 4
+#define DA9052_AVG_SZ  4
+#define DA9052_VC_TBL_SZ   68
+#define DA9052_VC_TBL_REF_SZ   3
+
+#define DA9052_ISET_USB_MASK   0x0F
+#define DA9052_CHG_USB_ILIM_MASK   0x40
+#define DA9052_CHG_LIM_COLS16
+
+#define DA9052_MEAN(x, y)  ((x + y) / 2)
+
+enum charger_type_enum {
+   DA9052_NOCHARGER = 1,
+   DA9052_CHARGER,
+};
+
+static const u16 da9052_chg_current_lim[2][DA9052_CHG_LIM_COLS] = {
+   {70,  80,  90,  100, 110, 120, 400,  450,
+500, 550, 600, 650, 700, 900, 1100, 1300},
+   {80,  90,  100, 110,  120,  400,  450,  500,
+550, 600, 800, 1000, 1200, 1400, 1600, 1800},
+};
+
+static const u16 vc_tbl_ref[3] = {10, 25, 40};
+/* Lookup table for voltage vs capacity */
+static u32 const vc_tbl[3][68][2] = {
+   /* For temperature 10 degree celisus*/
+   {
+   {4082, 100}, {4036, 98},
+   {4020, 96}, {4008, 95},
+   {3997, 93}, {3983, 91},
+   {3964, 90}, {3943, 88},
+   {3926, 87}, {3912, 85},
+   {3900, 84}, {3890, 82},
+   {3881, 80}, {3873, 79},
+   {3865, 77}, {3857, 76},
+   {3848, 74}, {3839, 73},
+   {3829, 71}, {3820, 70},
+   {3811, 68}, {3802, 67},
+   {3794, 65}, {3785, 64},
+   {3778, 62}, {3770, 61},
+   {3763, 59}, {3756, 58},
+   {3750, 56}, {3744, 55},
+   {3738, 53}, {3732, 52},
+   {3727, 50}, {3722, 49},
+   {3717, 47}, {3712, 46},
+   {3708, 

ANN: git.linaro.org going down for up to 1h

[Danilo Šegan]

Hi all,

We've experienced slowness with git.linaro.org yesterday that is harming
our release process.  Since we've already had new machine for hosting
git.linaro.org being set up (in the final stages of it), we're about to
switch the machines around.  We've spent the morning testing the new
machine and it seems ready to go.

This means that we'll be shutting off any git access to git.linaro.org
shortly (at 12:30 UTC), and we expect a downtime of 30 minutes to get
new machine up (but let's keep the window of 1h just in case).  If you
have any urgent issues, please shout before we go for the downtime.

Sorry for such a short notice!

Cheers,
Danilo



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v3 1/4] omap-serial: Get rid of all pdev->id usage

[Rajendra Nayak]

With Device tree, pdev->id would no longer be Valid.
Hence get rid of all instances of its usage in the
driver. Device tree support for the driver is added
in subsequent patches.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |   30 +++---
 1 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..a02cc9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -115,7 +115,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
 {
struct uart_omap_port *up = (struct uart_omap_port *)port;
 
-   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
up->ier |= UART_IER_MSI;
@@ -418,7 +418,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port 
*port)
unsigned int ret = 0;
 
pm_runtime_get_sync(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->port.line);
spin_lock_irqsave(&up->port.lock, flags);
ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
spin_unlock_irqrestore(&up->port.lock, flags);
@@ -436,7 +436,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port 
*port)
status = check_modem_status(up);
pm_runtime_put(&up->pdev->dev);
 
-   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line);
 
if (status & UART_MSR_DCD)
ret |= TIOCM_CAR;
@@ -454,7 +454,7 @@ static void serial_omap_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char mcr = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
if (mctrl & TIOCM_RTS)
mcr |= UART_MCR_RTS;
if (mctrl & TIOCM_DTR)
@@ -478,7 +478,7 @@ static void serial_omap_break_ctl(struct uart_port *port, 
int break_state)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
spin_lock_irqsave(&up->port.lock, flags);
if (break_state == -1)
@@ -504,7 +504,7 @@ static int serial_omap_startup(struct uart_port *port)
if (retval)
return retval;
 
-   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -545,7 +545,7 @@ static int serial_omap_startup(struct uart_port *port)
0);
init_timer(&(up->uart_dma.rx_timer));
up->uart_dma.rx_timer.function = serial_omap_rxdma_poll;
-   up->uart_dma.rx_timer.data = up->pdev->id;
+   up->uart_dma.rx_timer.data = up->port.line;
/* Currently the buffer size is 4KB. Can increase it */
up->uart_dma.rx_buf = dma_alloc_coherent(NULL,
up->uart_dma.rx_buf_size,
@@ -573,7 +573,7 @@ static void serial_omap_shutdown(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
 
-   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -883,7 +883,7 @@ serial_omap_set_termios(struct uart_port *port, struct 
ktermios *termios,
 
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_put(&up->pdev->dev);
-   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
 }
 
 static void
@@ -893,7 +893,7 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char efr;
 
-   dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->pdev->id);
+   dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->port.line);
 
pm_runtime_get_sync(&up->pdev->dev);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
@@ -932,7 +932,7 @@ static void serial_omap_config_port(struct uart_port *port, 
int flags)
struct uart_omap_port *up = (struct uart_omap_port *)port;
 
dev_dbg(up->port.dev, "serial_omap_config_port+%d\n",
- 

[PATCH v3 3/4] omap-serial: Add minimal device tree support

[Rajendra Nayak]

Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smartidle bits and handling
remote wakeup and dynamic muxing.

Acked-by: Rob Herring 
Signed-off-by: Rajendra Nayak 
---
 .../devicetree/bindings/serial/omap_serial.txt |   10 
 drivers/tty/serial/omap-serial.c   |   45 ++-
 2 files changed, 52 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- ti,hwmods : Must be "uart", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, 
void *data)
return;
 }
 
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+   struct omap_uart_port_info *omap_up_info;
+
+   omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+   if (!omap_up_info)
+   return NULL; /* out of memory */
+
+   of_property_read_u32(dev->of_node, "clock-frequency",
+&omap_up_info->uartclk);
+   return omap_up_info;
+}
+
 static int serial_omap_probe(struct platform_device *pdev)
 {
struct uart_omap_port   *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;
 
+   if (pdev->dev.of_node)
+   omap_up_info = of_get_uart_port_info(&pdev->dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device 
*pdev)
up->port.regshift = 2;
up->port.fifosize = 64;
up->port.ops = &serial_omap_pops;
-   up->port.line = pdev->id;
-   sprintf(up->name, "OMAP UART%d", up->port.line);
 
+   if (pdev->dev.of_node)
+   up->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+   else
+   up->port.line = pdev->id;
+
+   if (up->port.line < 0) {
+   dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+   up->port.line);
+   ret = -ENODEV;
+   goto err;
+   }
+
+   sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
if (!up->port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
 
-   if (!pdata->enable_wakeup)
+   if (!pdata || !pdata->enable_wakeup)
return 0;
 
if (pdata->get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = 
{
serial_omap_runtime_resume, NULL)
 };
 
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+   { .compatible = "ti,omap2-uart" },
+   { .compatible = "ti,omap3-uart" },
+   { .compatible = "ti,omap4-uart" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
 static struct platform_driver serial_omap_driver = {
.probe  = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name   = DRIVER_NAME,
.pm = &serial_omap_dev_pm_ops,
+   .of_match_table = of_match_ptr(omap_serial_of_match),
},
 };
 
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v3 0/4] OMAP serial device tree support

[Rajendra Nayak]

v3 is rebased on top of the latest serial runtime
patches[1] and boot tested with/without DT on OMAP4
SDP and OMAP4 Panda boards.

Patches can be found here..
git://gitorious.org/omap-pm/linux.git for-dt/serial

I also had to pull in a fix[2] for DT testing (already in linux-omap
master) which was missing as the serial runtime branch[1]
was based on an older master commit.

Changes in v3:
-1- Rebased on latest serial runtime patches
-2- Minor typr fixes

Changes in v2:
-1- Got rid of binding to define which uart is console
-2- Added checks to default clock speed to 48Mhz
-3- Added compatible for each OMAP family
-4- Used of_alias_get_id to populate port.line

[1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
[2] http://www.spinics.net/lists/arm-kernel/msg150751.html

Rajendra Nayak (4):
  omap-serial: Get rid of all pdev->id usage
  omap-serial: Use default clock speed (48Mhz) if not specified
  omap-serial: Add minimal device tree support
  ARM: omap: pass minimal SoC/board data for UART from dt

 .../devicetree/bindings/serial/omap_serial.txt |   10 +++
 arch/arm/boot/dts/omap3.dtsi   |   31 
 arch/arm/boot/dts/omap4.dtsi   |   28 +++
 arch/arm/mach-omap2/board-generic.c|1 -
 drivers/tty/serial/omap-serial.c   |   80 +++
 5 files changed, 132 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt

[Rajendra Nayak]

Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.

Acked-by: Rob Herring 
Signed-off-by: Rajendra Nayak 
---
 arch/arm/boot/dts/omap3.dtsi|   31 +++
 arch/arm/boot/dts/omap4.dtsi|   28 
 arch/arm/mach-omap2/board-generic.c |1 -
 3 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
 / {
compatible = "ti,omap3430", "ti,omap3";
 
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
+   };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4902 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x49042000 {
+   compatible = "ti,omap3-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
 
aliases {
+   serial0 = &uart1;
+   serial1 = &uart2;
+   serial2 = &uart3;
+   serial3 = &uart4;
};
 
cpus {
@@ -99,5 +103,29 @@
reg = <0x48241000 0x1000>,
  <0x48240100 0x0100>;
};
+
+   uart1: serial@0x4806a000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart1";
+   clock-frequency = <4800>;
+   };
+
+   uart2: serial@0x4806c000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart2";
+   clock-frequency = <4800>;
+   };
+
+   uart3: serial@0x4802 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart3";
+   clock-frequency = <4800>;
+   };
+
+   uart4: serial@0x4806e000 {
+   compatible = "ti,omap4-uart";
+   ti,hwmods = "uart4";
+   clock-frequency = <4800>;
+   };
};
 };
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
 
-   omap_serial_init();
omap_sdrc_init(NULL, NULL);
 
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH v3 2/4] omap-serial: Use default clock speed (48Mhz) if not specified

[Rajendra Nayak]

Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.

Signed-off-by: Rajendra Nayak 
---
 drivers/tty/serial/omap-serial.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
 #include 
 #include 
 
+#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
+
 static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
 
 /* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device 
*pdev)
 
up->port.flags = omap_up_info->flags;
up->port.uartclk = omap_up_info->uartclk;
+   if (!up->port.uartclk) {
+   up->port.uartclk = DEFAULT_CLK_SPEED;
+   dev_warn(&pdev->dev, "No clock speed specified: using default:"
+   "%d\n", DEFAULT_CLK_SPEED);
+   }
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
 
-- 
1.7.1


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 01/06] MFD: DA9052/53 MFD core module v10

[Mark Brown]

On Mon, Dec 12, 2011 at 08:06:56PM +0530, Ashish Jangam wrote:
> The DA9052/53 is a highly integrated PMIC subsystem with supply domain
> flexibility to support wide range of high performance application.

Applied, thanks.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 03/06] MFD: DA9052/53 MFD core module add SPI support v2

[Mark Brown]

On Mon, Dec 12, 2011 at 08:37:41PM +0530, Ashish Jangam wrote:
> This patch add SPI support for DA9052/53 MFD core module.

Applied, thanks.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 3/6] clk: introduce the common clock framework

[Ryan Mallon]

On 14/12/11 14:53, Mike Turquette wrote:

> The common clk framework is an attempt to define a common struct clk
> which can be used by most platforms, and an API that drivers can always
> use safely for managing clks.
> 
> The net result is consolidation of many different struct clk definitions
> and platform-specific clk framework implementations.
> 
> This patch introduces the common struct clk, struct clk_ops and
> definitions for the long-standing clk API in include/clk/clk.h.
> Platforms may define their own hardware-specific clk structure, so long
> as it wraps an instance of the common struct clk which is passed to
> clk_init at initialization time.  From this point on all of the usual
> clk APIs should be supported, so long as the platform supports them
> through hardware-specific callbacks in struct clk_ops.
> 
> See Documentation/clk.txt for more details.
> 
> This patch is based on the work of Jeremy Kerr, which in turn was based
> on the work of Ben Herrenschmidt.  Big thanks to both of them for
> kickstarting this effort.
> 
> Signed-off-by: Mike Turquette 
> Cc: Jeremy Kerr 


Hi Mike,

Some comments below,

~Ryan

> ---
>  drivers/clk/Kconfig  |4 +
>  drivers/clk/Makefile |1 +
>  drivers/clk/clk.c|  564 
> ++
>  include/linux/clk.h  |  130 +++-
>  4 files changed, 695 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/clk/clk.c
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 7a9899bd..adc0586 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -8,3 +8,7 @@ config HAVE_MACH_CLKDEV
>  
>  config HAVE_CLK_PREPARE
>   bool
> +
> +config GENERIC_CLK
> + bool
> + select HAVE_CLK_PREPARE
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 07613fa..570d5b9 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -1,2 +1,3 @@
>  
>  obj-$(CONFIG_CLKDEV_LOOKUP)  += clkdev.o
> +obj-$(CONFIG_GENERIC_CLK)+= clk.o
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> new file mode 100644
> index 000..8cadadd
> --- /dev/null
> +++ b/drivers/clk/clk.c
> @@ -0,0 +1,564 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd 
> + * Copyright (C) 2011 Linaro Ltd 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Standard functionality for the common clock API.  See 
> Documentation/clk.txt
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static DEFINE_SPINLOCK(enable_lock);
> +static DEFINE_MUTEX(prepare_lock);
> +
> +static HLIST_HEAD(clk_root_list);
> +
> +/***clk API***/
> +
> +void __clk_unprepare(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->prepare_count == 0))
> + return;
> +
> + if (--clk->prepare_count > 0)
> + return;
> +
> + WARN_ON(clk->enable_count > 0);
> +
> + if (clk->ops->unprepare)
> + clk->ops->unprepare(clk);
> +
> + __clk_unprepare(clk->parent);
> +}


I think you can rewrite this to get rid of the recursion as below:

while (clk) {
if (WARN_ON(clk->prepare_count == 0))
return;

if (--clk->prepare_count > 0)
return;

WARN_ON(clk->enable_count > 0)

if (clk->ops->unprepare)
clk->ops->unprepare(clk);

clk = clk->parent;
}

Also, should this function be static?

> +
> +/**
> + * clk_unprepare - perform the slow part of a clk gate
> + * @clk: the clk being gated
> + *
> + * clk_unprepare may sleep, which differentiates it from clk_disable.  In a
> + * simple case, clk_unprepare can be used instead of clk_disable to gate a 
> clk
> + * if the operation may sleep.  One example is a clk which is accessed over
> + * I2c.  In the complex case a clk gate operation may require a fast and a 
> slow
> + * part.  It is this reason that clk_unprepare and clk_disable are not 
> mutually
> + * exclusive.  In fact clk_disable must be called before clk_unprepare.
> + */
> +void clk_unprepare(struct clk *clk)
> +{
> + mutex_lock(&prepare_lock);
> + __clk_unprepare(clk);
> + mutex_unlock(&prepare_lock);
> +}
> +EXPORT_SYMBOL_GPL(clk_unprepare);
> +
> +int __clk_prepare(struct clk *clk)
> +{
> + int ret = 0;
> +
> + if (!clk)
> + return 0;
> +
> + if (clk->prepare_count == 0) {
> + ret = __clk_prepare(clk->parent);
> + if (ret)
> + return ret;
> +
> + if (clk->ops->prepare) {
> + ret = clk->ops->prepare(clk);
> + if (ret) {
> + __clk_unprepare(clk->parent);
> + return ret;
> + 

Re: [PATCH v4 5/6] clk: basic gateable and fixed-rate clks

[Ryan Mallon]

On 14/12/11 14:53, Mike Turquette wrote:

> Many platforms support simple gateable clks and fixed-rate clks that
> should not be re-implemented by every platform.
> 
> This patch introduces a gateable clk with a common programming model of
> gate control via a write of 1 bit to a register.  Both set-to-enable and
> clear-to-enable are supported.
> 
> Also introduced is a fixed-rate clk which has no reprogrammable aspects.
> 
> The purpose of both types of clks is documented in drivers/clk/basic.c.
> 
> TODO: add support for a simple divider, simple mux and a dummy clk for
> stubbing out platform support.
> 
> Based on original patch by Jeremy Kerr and contribution by Jamie Iles.
> 
> Signed-off-by: Mike Turquette 
> Cc: Jeremy Kerr 
> Cc: Jamie Iles 



> +int clk_register_gate(struct device *dev, const char *name, unsigned long 
> flags,
> + struct clk *fixed_parent, void __iomem *reg, u8 bit_idx,
> + int set_to_enable)
> +{
> + struct clk_hw_gate *gclk;
> + struct clk *clk;
> +
> + gclk = kmalloc(sizeof(struct clk_hw_gate), GFP_KERNEL);
> +
> + if (!gclk) {
> + pr_err("%s: could not allocate gated clk\n", __func__);
> + return -ENOMEM;
> + }
> +
> + clk = &gclk->clk;
> +
> + /* struct clk_hw_gate assignments */
> + gclk->fixed_parent = fixed_parent;
> + gclk->reg = reg;
> + gclk->bit_idx = bit_idx;
> +
> + /* struct clk assignments */
> + clk->name = name;
> + clk->flags = flags;
> +
> + if (set_to_enable)
> + clk->ops = &clk_hw_gate_set_enable_ops;
> + else
> + clk->ops = &clk_hw_gate_set_disable_ops;


You could avoid having two sets of operations if you stored the
set_to_enable value in struct clk_hw_gate. It might be useful to store
additional information in struct clk_hw_gate if you also want to extend
to supporting non-32bit registers (readb, etc), clocks with write only
registers, or support clocks which require more than one bit to be set
or cleared to enable them, etc. See the basic mmio gpio driver for a
similar case.

~Ryan


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 3/7] HACK: omap: convert 44xx data to common struct clk

[Paul Walmsley]

Hi

On Tue, 13 Dec 2011, Mike Turquette wrote:

> omap_clk_get_by_name must die.

You do realize that it exists for a reason?  That hardware clock names 
don't have anything to do with the Linux device model?


- Paul

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 3/7] HACK: omap: convert 44xx data to common struct clk

[Paul Walmsley]

On Tue, 13 Dec 2011, Turquette, Mike wrote:

> On Tue, Dec 13, 2011 at 8:27 PM, Paul Walmsley  wrote:
> > On Tue, 13 Dec 2011, Mike Turquette wrote:
> >
> >> omap_clk_get_by_name must die.
> >
> > You do realize that it exists for a reason?  That hardware clock names
> > don't have anything to do with the Linux device model?
> 
> We have a tree structure of clks in the new common clk code, and a
> list of clks in clkdev (which admittedly is meant to be a subset, but
> in reality we register every OMAP clk with it), and then the omap clk
> list which is only really used by omap_get_clk_by_name for hwmod and
> some initialization stuff.  What I'd really like to do is get rid of
> the OMAP clk code keeping track of it's clks in a separate list, which
> seems quite wasteful.

Clock lookups that only involve a hardware clock name, with no device, 
should be the province of the clock code itself, not clkdev.  The clkdev 
code may handle this today in the OMAP code, but this is simply due to 
legacy reasons.

In general, on OMAP, we've got much faster ways now to implement 
clk_get().


- Paul___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Powering up snowball over USB

[Dave Pigott]

Lee's right. Someone on Igloo told me it was a BSP (he mistyped) version 
problem. I'm trying to find a stable version that will work for a master image.

Dave

Dave Pigott
Validation Engineer
T: +44 1223 45 00 24 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

On 13 Dec 2011, at 16:46, Lee Jones wrote:

> On 13/12/11 16:09, Paul Larson wrote:
>> Possibly a kernel bug?  Lee, anything on snowball that would cause it to
>> not go through with the reboot when on usb power?
> 
> Last I saw, Dave was chatting with the guys at Igloo about it and a DSP
> issue was fingered. Check back with him to see if his investigations
> have been furthered since.
> 
> Kind regards,
> Lee
> 
>> On Tue, Dec 13, 2011 at 9:50 AM, Dave Pigott > > wrote:
>> 
>>Hi all,
>> 
>>Sorry for the wide distribution, but I've got a rather curious problem.
>> 
>>I'm trying to get a Snowball V11 PDK working in the validation lab,
>>and the only way to get it to boot on power-on is to power it over
>>USB and control the power through a USB power adaptor. While this
>>works admirably, the problem is that when I try to soft-reboot I get
>>the usual:
>> 
>>Broadcast message from root@master
>>(/dev/ttyAMA2) at 15:48 ...
>> 
>>The system is going down for reboot NOW!
>> * Asking all remaining processes to terminate...  
>> [ OK ] 
>> * All processes ended within 1 seconds
>> [ OK ] 
>> * Deconfiguring network interfaces...  
>>[ OK ] 
>> * Deactivating swap...
>> [ OK ] 
>>umount: /run/lock: not mounted
>> * Will now restart
>>[ 1279.346801] Restarting system.
>> 
>> 
>>and then nothing. It just hangs and never comes back until I power
>>cycle it.
>> 
>>BTW: Sometimes I get the whole of the "Restarting system" message,
>>sometimes just half of it.
>> 
>>Has anybody any idea why this might be the case and, if so, what I
>>can do about it?
>> 
>>Thanks
>> 
>>Dave
>> 
>>Dave Pigott
>>Validation Engineer
>>T: +44 1223 45 00 24  | M +44 7940
>>45 93 44 
>>Linaro.org * **│ *Open source software for
>>ARM SoCs
>>Follow *Linaro: *Facebook
>> | Twitter
>> | Blog
>>
>> 
>> 
>>___
>>linaro-dev mailing list
>>linaro-dev@lists.linaro.org 
>>http://lists.linaro.org/mailman/listinfo/linaro-dev
>> 
>> 
> 
> 
> -- 
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> M: +44 77 88 633 515
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 6/6] HACK: arm: reprogram twd based on clk notifier

[Linus Walleij]

Hi Mike,

I just sent new patches for the TWD CPUfreq stuff, including the bug fix you
provide below for clk_prepare(). They're in Russell's patch tracker:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7210/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7211/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7212/1

On Wed, Dec 14, 2011 at 5:31 AM, Mike Turquette  wrote:

> The primary purpose behind this change is to test the new clk notifier
> code.  If you find it useful beyond that, please let me know!

This is way more elegant that the cpufreq way of doing things.
For several years I was confused by TI:s way of re-reading any
peripheral clock speed in CPUfreq notifiers when there was strictly
no theoretical requirement for the CPU to actually change it's frequency
when the clock frequency for that particular device changed.

See for example drivers/mmc/host/davinci_mmc.c:

#ifdef CONFIG_CPU_FREQ
static int mmc_davinci_cpufreq_transition(struct notifier_block *nb,
 unsigned long val, void *data)
{
struct mmc_davinci_host *host;
unsigned int mmc_pclk;
struct mmc_host *mmc;
unsigned long flags;

host = container_of(nb, struct mmc_davinci_host, freq_transition);
mmc = host->mmc;
mmc_pclk = clk_get_rate(host->clk);

if (val == CPUFREQ_POSTCHANGE) {
spin_lock_irqsave(&mmc->lock, flags);
host->mmc_input_clk = mmc_pclk;
calculate_clk_divider(mmc, &mmc->ios);
spin_unlock_irqrestore(&mmc->lock, flags);
}

return 0;
}


...what does the CPU has to do with the MMC host->clk again?
Absolutely nothing. There is no point in the MMC framework
knowing that the CPU is changing operating point.
(There is a similar hack in the s3c MMC driver.)

The clk notifiers are the sane way of doing this.

Yours,
Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-next not booting on snowball

[Linus Walleij]

On Wed, Dec 14, 2011 at 9:27 AM, Mark Brown
 wrote:
> On Wed, Dec 14, 2011 at 09:24:33AM +0100, Linus Walleij wrote:
>
>> The above remaps and reads from some random ROM page to get
>> the ASIC ID is actually not screwing things up. Right now.
>
> The ASIC ID reads are also done by Samsung platforms which boot fine -
> it's not strictly good but it happens to work (and has done for some
> considerable time).

Yes some chicken and egg problem here to some extent :-/

What would be elegant is some readl_early_physical(u32 addr);
that is guaranteed to set up a temporary mapping, read out that
32-bit word wherever it lives and tear it the map down in a
controlled manner afterwards. We could tag it __init so it
is not abused at runtime.

This could atleast collect these hacks in one place.

Don't know how easy it'd be to achieve that...

Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-next not booting on snowball

[Mark Brown]

On Wed, Dec 14, 2011 at 09:24:33AM +0100, Linus Walleij wrote:

> The above remaps and reads from some random ROM page to get
> the ASIC ID is actually not screwing things up. Right now.

The ASIC ID reads are also done by Samsung platforms which boot fine -
it's not strictly good but it happens to work (and has done for some
considerable time).

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: linux-next not booting on snowball

[Linus Walleij]

On Tue, Dec 13, 2011 at 1:35 PM, Linus Walleij  wrote:
> On Wed, Dec 7, 2011 at 5:09 AM, Nicolas Pitre  
> wrote:
>
>>> The kernel hangs at:
>>>
>>> u8500_map_io
>>>  -> ux500_map_io
>>>    -> ux500_read_asicid(addr=9001dbf4), base=9001d000
>>>      ->  readl(__io_address(9001dbf4)=f901dbf4);
>
> This code isn't strictly necessary so I moved it out of the way.
>
> Then it hangs on the second iotable_init() call instead.

I found the cause: overlapping iotable entries, sent a separate
patch, check it out...

The above remaps and reads from some random ROM page to get
the ASIC ID is actually not screwing things up. Right now.

Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev