Mark Brown | 1 Apr 02:53 2011

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 31, 2011 at 06:49:11PM -0400, Nicolas Pitre wrote:
> On Thu, 31 Mar 2011, Linus Torvalds wrote:

> > The only way to get quality code is to try to improve the quality from
> > the "leaf nodes", because otherwise you'll always end up playing
> > catch-up. You'll get new bad code faster than you can clean it up.
> 
> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

It's also often the case that the leaf maintainers are themselves
overloaded with work, especially those who don't have much code in tree
already or who have advanced power management features in their devices
that they're trying to support (which tend to be the area that requires
most work as they're system wide in impact).  

> > This really isn't the argument. The argument should be that if they
> > want their code up-stream, they need to do a good job. If they don't,
> > why should you take it at all?

> Embedded vendors did keep their code out of the kernel before.  We've 
(Continue reading)

Mark Brown | 1 Apr 03:17 2011

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Wed, Mar 30, 2011 at 03:14:10PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux <at> arm.linux.org.uk> [110330 14:05]:

> > And I have got to the point of just not giving a damn.  I can't change
> > the ARM community (I've tried over the years to get more active review
> > of platform changes and failed - and had it pointed out by folk like
> > Alan Cox, that such a system is impossible due to lack of motivation
> > by, eg, an OMAP person to review a Samsung change.)

> I think this is happening more and more as we have more ARM generic
> and Linux generic code.

Plus you've now got some non-trivial code for off-SoC devices which
means you've got a growing number of people who do actively work over
many SoCs.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mark Brown | 1 Apr 03:42 2011

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 31, 2011 at 12:56:33AM +0200, Thomas Gleixner wrote:
> On Wed, 30 Mar 2011, Tony Lindgren wrote:
> > * Thomas Gleixner <tglx <at> linutronix.de> [110330 15:22]:
> > > On Wed, 30 Mar 2011, Tony Lindgren wrote:

> > > > One thing that will help here and distribute the load is to move
> > > > more things under drivers/ as then we have more maintainers looking
> > > > at the code.

> > > Guess what's that going to solve? Nothing, nada.

> > > Really, you move the problem to people who are not prepared to deal
> > > with the wave either. So what's the gain?

> > I guess my point is that with creating more common frameworks people
> > will be using common code. Some examples that come to mind are clock
> > framework, gpiolib, dma engine, runtime PM and so on.

> For all that to happen you need a really experienced team with a
> strong team lead to fight that through and go through the existing
> horror while dealing  with the incoming flood at the same time.

My experience is that it's not that bad doing this providing you can
convince people to actually show their code to the relevant subsystem
maintainers and they have time to look at the code.  The first step is
reasonably tractable since it's a fairly basic level of review and as a
subsystem maintainer you're well enough motivated to at least ensure
that people aren't breaking the abstractions enough to cause problems
for anyone but the people directly working with the drivers.
(Continue reading)

David Brown | 1 Apr 06:50 2011

Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, Mar 31 2011, Nicolas Pitre wrote:

> Leaf nodes on ARM are people coming from corporate background with the 
> old school software development methodologies.  They do it as a _job_ 
> first and foremost.  They only work on Linux because that's what their 
> boss assigned them to. Don't get me wrong: that doesn't mean they are 
> bad people.  Simply that they are not into it for the public recognition 
> (or flaming) from their peers.  Once their code works they lose interest 
> and move on.  That mindset is extremely hard to change and take time, on 
> a scale of years.  Much more time than required to produce the code 
> needed to support that new SOC out of the pipeline.  There are notable 
> exceptions obviously.  But this is still a scalability problem in 
> itself.  So we need men-in-the-middle attacks.

An additional mindset that is difficult to work with in this environment
is that the corporate development methodology has a focus on schedules
and deliverables.  Even people who would otherwise like to contribute
will have pressure to get something done.  Many think of "submit to
mainline" is kind of a last step in a development process, instead of
even a goal to accomplish.

When we push back, there is a good chance they just won't bother, not
because they don't want to do it, but because it doesn't fit a schedule,
and there is already something else for them to work on.

So what's the right answer here.  Practically, someone just sent out a
fairly complete DMA driver for a new MSM device.  Naturally, this
hardware is nothing like anyone else's DMA, but the driver itself pretty
much independent from other kernel APIs.  It isn't even similar to the
existing DMA driver in the MSM.  With it are patches to ifdef-up various
(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH 0/5] regulator: twl: make 6030 regulators useable

TWL6030 regulator dynamic operations such as those on vaux2 and vaux3
were reported to be broken on platforms such as pandaboard(OMAP4).
Digging deeper into the code, found that 6030 regulator support
requires quiet a bit of fixes to make it useable. Major change w.r.t
TWL4030 has been the introduction of CFG_STATE register in TWL6030
which is needed to be used for regulator control compared to messages
which were used in TWL4030.

This could have been the real root cause of the issue fixed in:
  commit 8b8e2ef328c3378c74fb4347f66df8e58feeaf46
  Author: David Anders <x0132446 <at> ti.com>
  Date:   Fri Mar 18 16:53:20 2011 -0700

  OMAP4: PandaBoard: remove unused power regulators

  the pandaboard does not use the VUSIM or VAUX1 power regulators on the TWL6030
  and are left floating. if the VUSIM and VAUX1 power regulators are initilized,
  noise on the unloaded regulators generates an overcurrent interrupt causing the
  system to power down. this patch removes the initialization of the unused power
  regulators of VUSIM and VAUX1.

Normally just having the regulator resources in board file should'nt have caused
them to have been enabled in the first place - they should have been enabled
only when regulator_enable is invoked and disabled in regulator_disable.
These unfortunately, are'nt working at the moment and the series fixes the same.

This series also allows the regulator framework to actually be able to use the
regulator in lower power "SUSPEND" state which if properly used could reduce
power consumption in usecases.

(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH 1/5] regulator: twl: fix twl6030 enable/disable

From: Saquib Herman <saquib <at> ti.com>

TWL6030 requires an additional register write to CFG_STATE register
to explicitly state that the regulator is in a certain state. Merely
associating the regulator with the group is not enough. Add the
required register field definitions and fix the handling for
TWL6030 enable/disable.

Signed-off-by: Nishanth Menon <nm <at> ti.com>
Signed-off-by: Saquib Herman <saquib <at> ti.com>
---
 drivers/regulator/twl-regulator.c |   31 ++++++++++++++++++++++++++++++-
 1 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 6a29285..3e9060c 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
 <at>  <at>  -76,6 +76,11  <at>  <at>  struct twlreg_info {
 #define VREG_BC_PROC		3
 #define VREG_BC_CLK_RST		4

+/* TWL6030 LDO register values for CFG_STATE */
+#define TWL6030_CFG_STATE_OFF	0x00
+#define TWL6030_CFG_STATE_ON	0x01
+#define TWL6030_CFG_STATE_GRP_SHIFT	5
+
 static inline int
 twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
 {
(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH 2/5] regulator: twl: remap has no meaning for 6030

From: Saquib Herman <saquib <at> ti.com>

TWL6030 does not have remap register. The current implementation
causes value of remap to be written to state register, accidentally
causing the regulators which are probed to be switched on as well.
This is wrong as regulators should be controllable based on calls
to enable/disable for TWL regulator framework. Further, the values
initialized make no sense as well. We hence remove this from the
initalizers and also write to remap register only if the TWL
is 4030.

Signed-off-by: Nishanth Menon <nm <at> ti.com>
Signed-off-by: Saquib Herman <saquib <at> ti.com>
---
 drivers/regulator/twl-regulator.c |   37 +++++++++++++++++--------------------
 1 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 3e9060c..2e88865 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
 <at>  <at>  -517,10 +517,9  <at>  <at>  static struct regulator_ops twl6030_fixed_resource = {
 			remap_conf) \
 		TWL_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
 			remap_conf, TWL4030)
-#define TWL6030_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
-			remap_conf) \
+#define TWL6030_FIXED_LDO(label, offset, mVolts, num, turnon_delay) \
 		TWL_FIXED_LDO(label, offset, mVolts, num, turnon_delay, \
-			remap_conf, TWL6030)
(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH 3/5] regulator: twl: fix twl6030 regulator is_enabled

From: Saquib Herman <saquib <at> ti.com>

With TWL6030, it is not enough to ensure that the regulator is the
group of P1 group (CPU/Linux), but we need to check the state as far
as APP is concerned as well.

Split the current is_enabled to 6030 and 4030 specific ones. This
split impacts few macros and variables as well, but sets up the
stage for further fixes to set_mode and get_status in subsequent
patches.

Signed-off-by: Nishanth Menon <nm <at> ti.com>
Signed-off-by: Saquib Herman <saquib <at> ti.com>
---
 drivers/regulator/twl-regulator.c |   61 ++++++++++++++++++++++++++++---------
 1 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 2e88865..11d2e08 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
 <at>  <at>  -80,6 +80,10  <at>  <at>  struct twlreg_info {
 #define TWL6030_CFG_STATE_OFF	0x00
 #define TWL6030_CFG_STATE_ON	0x01
 #define TWL6030_CFG_STATE_GRP_SHIFT	5
+#define TWL6030_CFG_STATE_APP_SHIFT	2
+#define TWL6030_CFG_STATE_APP_MASK	(0x03 << TWL6030_CFG_STATE_APP_SHIFT)
+#define TWL6030_CFG_STATE_APP(v)	(((v) & TWL6030_CFG_STATE_APP_MASK) >>\
+						TWL6030_CFG_STATE_APP_SHIFT)

(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH v2 4/5] regulator: twl: add twl6030 get_status

From: Saquib Herman <saquib <at> ti.com>

Current get_status logic does not support 6030 get_status.
The logic for 4030 is not reusable for 6030 as the status
check for 6030 now depends on the new CFG_STATE register.
We hence rename the old get_status as being specific to
4030 and remove the redundant check for the same.

Signed-off-by: Nishanth Menon <nm <at> ti.com>
Signed-off-by: Saquib Herman <saquib <at> ti.com>
---
 drivers/regulator/twl-regulator.c |   44 +++++++++++++++++++++++++++++-------
 1 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index 11d2e08..d2f7e71 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
 <at>  <at>  -79,6 +79,8  <at>  <at>  struct twlreg_info {
 /* TWL6030 LDO register values for CFG_STATE */
 #define TWL6030_CFG_STATE_OFF	0x00
 #define TWL6030_CFG_STATE_ON	0x01
+#define TWL6030_CFG_STATE_OFF2	0x02
+#define TWL6030_CFG_STATE_SLEEP	0x03
 #define TWL6030_CFG_STATE_GRP_SHIFT	5
 #define TWL6030_CFG_STATE_APP_SHIFT	2
 #define TWL6030_CFG_STATE_APP_MASK	(0x03 << TWL6030_CFG_STATE_APP_SHIFT)
 <at>  <at>  -217,13 +219,10  <at>  <at>  static int twlreg_disable(struct regulator_dev *rdev)
 	return ret;
 }
(Continue reading)

Nishanth Menon | 1 Apr 06:52 2011
Picon

[PATCH 5/5] regulator: twl: add twl6030 set_mode

From: Saquib Herman <saquib <at> ti.com>

Current set_mode logic does not support 6030. The logic for 4030 is
not reusable for 6030 as the mode setting for 6030 now uses the new
CFG_STATE register. We hence rename the old get_status as being
specific to 4030.

Signed-off-by: Nishanth Menon <nm <at> ti.com>
Signed-off-by: Saquib Herman <saquib <at> ti.com>
---
 drivers/regulator/twl-regulator.c |   42 +++++++++++++++++++++++++++++-------
 1 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c
index d2f7e71..bf7c402 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
 <at>  <at>  -262,15 +262,12  <at>  <at>  static int twl6030reg_get_status(struct regulator_dev *rdev)
 	return REGULATOR_STATUS_OFF;
 }

-static int twlreg_set_mode(struct regulator_dev *rdev, unsigned mode)
+static int twl4030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
 {
 	struct twlreg_info	*info = rdev_get_drvdata(rdev);
 	unsigned		message;
 	int			status;

-	if (twl_class_is_6030())
-		return 0; /* FIXME return for 6030 regulator */
(Continue reading)


Gmane