headers
Mark Brown | 1 Apr 2011 03:17
Favicon
Gravatar

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
Permalink | Reply | 0 comments |
headers
David Brown | 1 Apr 2011 06:50
Gravatar

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)

Permalink | Reply | 51 comments |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 8 comments |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 0 comments |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 0 comments |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 0 comments |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 1 comment |
headers
Nishanth Menon | 1 Apr 2011 06:52
Picon
Favicon
Gravatar

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

Permalink | Reply | 0 comments |
headers
Menon, Nishanth | 1 Apr 2011 07:01
Picon
Favicon
Gravatar

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

On Fri, Apr 1, 2011 at 10:22, Nishanth Menon <nm <at> ti.com> wrote:

Opps.. apologies.. the v2 in $subject was a typo.. not that impacts
either git am/patchworks/functionality.. but just fyi, in case anyone
wonders..

Regards,
Nishanth Menon
--
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
Permalink | Reply | 0 comments |
headers
Hiremath, Vaibhav | 1 Apr 2011 07:05
Picon
Favicon
Gravatar

RE: Question regarding suspend/resume


> -----Original Message-----
> From: linux-omap-owner <at> vger.kernel.org [mailto:linux-omap-
> owner <at> vger.kernel.org] On Behalf Of Hilman, Kevin
> Sent: Friday, April 01, 2011 2:18 AM
> To: Peter Barada
> Cc: Linux OMAP list
> Subject: Re: Question regarding suspend/resume
> 
> Hi Peter,
> 
> Peter Barada <peter.barada <at> gmail.com> writes:
> 
> [...]
> 
> > Thanks for helping me to understand things.
> >
> > The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1]
> > with their u-boot [2] and x-loader[3], modified to run on Logic's
> > DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP).
> 
> I'm afraid somone who supports that older TI kernel will have to help
> you out.
> 
[Hiremath, Vaibhav] Peter,

I have validated the release kernel (along with x-loader/uboot) on OMAP3EVM, and it does work without any issues.

I have personally validated this with latest Arago repos, probably you may want to share the changes you
have made in x-loader/uboot/kernel to port PSP2.6.32 to LogicPD hardware.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane