On 03/29/2013 11:53 AM, Santosh Shilimkar wrote:

On Friday 29 March 2013 04:15 PM, Daniel Lezcano wrote:

quoted

On 03/29/2013 11:38 AM, Santosh Shilimkar wrote:

quoted

On Friday 29 March 2013 04:01 PM, Daniel Lezcano wrote:

quoted

The driver is initialized several times. This is wrong and if the
return code of the function was checked, it will return -EINVAL.

Move this initialization out of the loop.

Signed-off-by: Daniel Lezcano <redacted>
---

Fix for this is already and v2 of the patch is here [1]

Ah, ok. Thanks for reviewing the patch.

Can we find a solution to have a single entry point to sumbit patches
for all the cpuidle drivers ?

Otherwise, consolidating them is a pain: a patch for the samsung tree,
another one for the at91 tree, etc ... and wait for all the trees to
sync before continuing to consolidate the code.

Wouldn't be worth to move these drivers under the PM umbrella instead of
the SoC specific code ?

Any idea to simplify the cpuidle consolidation and maintenance ?

Fisrtly patches get posted to right mailing list based on where the
code resides. So one must keep a watch on LAKML for the patches.

Yes, I agree.

The main issue is the multiple tree for the different drivers making
hard to track, modify and improve the drivers in one shot.

It is not the first time, a modification of the cpuidle framework
implied to modify all the drivers.

When Rob introduced the first code consolidation, that took months to
add a simple flag in the drivers because we had to wait for the merge
before the changes in drivers/cpuidle/cpuidle.c were visible.

Talking specific to OMAP idle code, there is plan to move
to drivers/idle/* but for that to happen there are some PRM/CM
dependency for which also driver movement is planned. Once
that happen, OMAP idle will find its way in drivers/idle/*

That would be *really* great. If we can do that for all the drivers,
that will solve the multi-location / multi-tree problem.

The u8500 driver will be moved soon to this directory also.

I did some modifications around the at91 some months ago to encapsulate
the code more, maybe it could be also a good candidate. Nicolas ?

For OMAP3 that could be a bit more difficult. Who is maintaining the
driver now ?

I Cc'ed the different maintainers for the other boards, may be they can
react ?

Thanks
  -- Daniel

-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog