Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states

[Santosh Shilimkar]

Jean,

On Monday 21 May 2012 07:55 PM, Shilimkar, Santosh wrote:
 Jean,
 
 On Mon, May 21, 2012 at 7:23 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
 Hi Santosh,

 On Thu, May 17, 2012 at 12:04 PM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:

[...]

 What do you think?

 I like the idea as mentioned. I just think the series should already
 take care of memory state, logic state and quirk flags to see how
 it looks overall. Will have one more fresh look at the series but if
 you have subsequent WIP patches which can handle the other
 parameters, please send that link.
 
I have scanned the series again. Somehow I still find myself
not convinced with the approach. I found having PD OSWR
CSWR state is the only change from this series helps to
some extent. But if you look from PRCM point of view,
they are already two distinct power domain states. Only
bad part from programming perspective, is, it's needs
to take care of additional bit to set and get PD state.

If we actually support 'PWRDM_POWER_OSWRET and
'PWRDM_POWER_CSWRET as valid state then we can do
everything without the functional power state series.
I mean we can use 'omap_set_pwrdm_state()' as a single
API for programming the PD, instead of duplicating
these all over the place.

OSWR by definition can be customised per power
domain based on various supported logic and
memory states.With this series, OSWR definition
also become static and if that is agreed then
we should cab just make that as a state like
ON/OFF/INACTIVE.

But I don't want to object this series if
Paul is convinced and agrees with the approach.
My view may be bit narrow but I am not convinced
with the approach.

Btw, ther are some real differences in PD INACTIVE state
in OMAP3 and OMAP4+ devices. I had some discussion with
Paul before on it. It needs to be clubbed with
voltagedomain layer to properly represent. Some
discussion was on the list [1] and some of that
was off list with hardware designers. Relevant
thread is here [1]

Regards
Santosh

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041133.html
--
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

Re: [PATCH] iommu/core: pass a user-provided token to fault handlers

[Joerg Roedel]

On Mon, May 21, 2012 at 08:20:05PM +0300, Ohad Ben-Cohen wrote:
 Sometimes a single IOMMU user may have to deal with several
 different IOMMU devices (e.g. remoteproc).
 
 When an IOMMU fault happens, such users have to regain their
 context in order to deal with the fault.
 
 Users can't use the private fields of neither the iommu_domain nor
 the IOMMU device, because those are already used by the IOMMU core
 and low level driver (respectively).
 
 This patch just simply allows users to pass a private token (most
 notably their own context pointer) to iommu_set_fault_handler(),
 and then makes sure it is provided back to the users whenever
 an IOMMU fault happens.
 
 The patch also adopts remoteproc to the new fault handling
 interface, but the real functionality using this (recovery of
 remote processors) will only be added later in a subsequent patch
 set.
 
 Cc: Fernando Guzman Lugo fernando.l...@ti.com
 Signed-off-by: Ohad Ben-Cohen o...@wizery.com

Applied, thanks.


-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Hiremath, Vaibhav]

On Wed, Apr 25, 2012 at 21:06:43, Paul Walmsley wrote:
 On Wed, 25 Apr 2012, Cousson, Benoit wrote:
 
  Please take care of changing the hwmod main_clk as well. But maybe 
  that's not part of that series.
 
 It's not part of the series yet.
 
 Vaibhav, could you take care of changing the main_clk in your hwmod data 
 patches, and send those to the list?
 
 

Paul,

Just an update on the status,

I used your cleaned version of clocktree data, where you have removed all 
leaf-nodes and merged multiple clocks nodes into one; but it did not work. I 
attempted to review the cleanup and tried to debug, but found it bit hard to 
come back to working clocktree from stripped version. So moved back to my 
submitted clocktree and started stripping the clock leaf-nodes, same way you 
had done it. Now I reached to the stage where I have working clocktree 
without peripheral leaf-nodes and booting on BeagleBone.

I will start working on migrating to common clock framework now, and hoping 
to finish it soon.


Just FYI (may need your help), I got into some issues (still open) during 
this cleanup -


1. In cases where we have clock selection option for node-leafs, like, 
   Timers, I removed enable_reg entry from the node, which results into a 
   kernel error message from function omap2_dflt_clk_disable()

clock: clk_disable called on independent clock %s which has no enable_reg


2. clkdm_name entry: 
   The issue is, two entries available for clockdomain associated for 
   module/clock 
- hwmod_data.main_clk and 
- clk.clkdm_name

   They must match, right? The parent/root clocks flows from one domain to 
   another domain, so I have to keep the nodes just for sake of matching 
   clockdomain entry present in associated main_clk data.

   I am still reviewing the code from Rajendra, but one of Rajendra's patch 
   actually will help here, made it to use hwmod_data.clkdm (if available) 
   always, instead of directly using clk.clkdm.

3. If I understand correctly, hwmod_data.main_clk is functional clock and
   hwmod_ocp_if.clk is interface clock, right?

   So currently, I have mentioned same entry in both the places (especially 
   for Peripherals/modules).
   I am planning to remove ocp_if/clk entry data for all modules..
   

Thanks,
Vaibhav
--
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

Re: [PATCH 1/7] remoteproc: resource table overhaul

[Ohad Ben-Cohen]

Hi Ludovic,

On Tue, May 22, 2012 at 3:51 PM, frq09524 ludovic.ba...@stericsson.com wrote:
 In my previous patch, to find the correct subdevice that match with physical 
 memory, I used pa member of rproc_mem_entry.

I'm not sure we want to find these subdevices using the physical
memory of the expected region.

Doing so means more work when setting up those numbers initially, and
may also break if/when those number changes.

What do you think about looking up those subdevices by names?

E.g. before allocating the vrings, we may look for a subdevice called
vrings-mem. If one exists, we'll use it when invoking the DMA API.
If not, we'll just use the default rproc device.

This way we don't need to change the firmware if/when we change the
memory regions allocated for each purpose.

Thanks,
Ohad.
--
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

Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

[Menon, Nishanth]

On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman khil...@ti.com wrote:
 Woodruff, Richard r-woodru...@ti.com writes:

 From: Hilman, Kevin
 Sent: Tuesday, May 08, 2012 5:17 PM

 A basic OMAP AVS driver has been in mainline for a long time, yet we
 have not seen support submitted for all of these features.

 1.5/3.5 is a feature.

 And I'm still waiting for it to be submitted upstream.

 ABB is requirement for a production useable driver. Higher speed rated
 OMAP4 and all OMAP5 added these to be useable.

 ditto

 Yes this is effort. Point of mentioning is to raise awareness of need.

 I'm well aware of the need.

 Yet to be added feature has different meaning than functional gap.

 And both need to be submitted upstream.

SR 1.5: http://marc.info/?l=linux-omapm=129933897910785w=2
ABB: http://marc.info/?l=linux-omapm=130939399209099w=2

I am not sure what you mean need to be submitted upstream?

Just tired of seeing things perpetually change without considering
even how to handle features that are mandatory for SoC even with code
posted upstream to show exactly what it takes.. I think you do mean
merged upstream in this context.


Regards,
Nishanth Menon
--
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

Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc

[Paul Walmsley]

On Tue, 22 May 2012, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [120521 23:51]:
  
  Next, I'd suggest implementing the code to allow GPMC timing configuration 
  from raw register data (the second method above).  This is hackish but for 
  some boards, this is all we'll have.  This will also presumably require 
  some extra DT bindings for the register data.  If this method is used, 
  this code should also call a PM function to block clock rate changes on 
  the GPMC clock, and an explanatory warning should be logged to the 
  console.
 
 Also something to note here is that generating dynamic timings from the
 fixed GPMC register values won't work for other frequencies.
 
 As far as I remember, the main problem trying to convert fixed value
 GPMC timings into dynamic timings is the fact that some GPMC values
 calculated depend on clock cycles, while other values depend on time.
 
 So the cycle values remain unknown trying to upsample from fixed timings.

Yep indeed.  That's why clock rate changes have to be blocked on the GPMC 
clock.  If we don't have GPMC clock rate-independent timing data, then 
I think we'll have to keep the GPMC clock rate fixed.

  For boards that we don't have access to, and all someone would have are 
  the register values set by the bootloader, I'd propose a phased approach:
  
  1. The kernel should log the bootloader-provided GPMC timing registers to 
  the console during boot, along with a warning message that indicates that 
  GPMC for these boards will cease to function in the near future unless 
  patches are provided to update the kernel board file and/or DT data with 
  the GPMC register contents.  This should allow people who have those 
  boards and who care about them to submit kernel patches to allow the 
  GPMC-attached devices to continue to function.
 
 Unfortunately for many of the older boards these values will probably
 remain unknown.
 
 So the better approach here is to just disable frequency scaling
 for these cases. Otherwise we'll be breaking old boards with smsc911x
 where the timings for the FPGA controlling smsc911x are unknown.
 
 If we somehow manage to get those values without breaking support for
 these boards, then yes I agree we should deprecate hardcoded and
 bootloader values.

I was thinking that if we log the register values supplied by the 
bootloader to the console, then someone can write a patch to the board 
file or DT data to set those register values explicitly in the kernel, 
once they're known.  Or at least just report them to the l-o list.

So then that should reduce the problem cases down to boards which no one 
reports the data to the mailing list within a few mainline kernel releases 
-- i.e., boards which are unmaintained.  For those boards, I'd suggest 
that we just drop GPMC support until someone shows up who has a board and 
can test-boot it.  Or just drop the board completely ;-)


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

RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Paul Walmsley]

Hi Vaibhav

On Wed, 23 May 2012, Hiremath, Vaibhav wrote:

 I used your cleaned version of clocktree data, where you have removed all 
 leaf-nodes and merged multiple clocks nodes into one; but it did not work. I 
 attempted to review the cleanup and tried to debug, but found it bit hard to 
 come back to working clocktree from stripped version. So moved back to my 
 submitted clocktree and started stripping the clock leaf-nodes, same way you 
 had done it. Now I reached to the stage where I have working clocktree 
 without peripheral leaf-nodes and booting on BeagleBone.

Okay great, please post that to the list so we can diff it against the 
version that I did, and also so we can queue it for merging in 3.6?

 Just FYI (may need your help), I got into some issues (still open) during 
 this cleanup -
 
 1. In cases where we have clock selection option for node-leafs, like, 
Timers, I removed enable_reg entry from the node, which results into a 
kernel error message from function omap2_dflt_clk_disable()
 
 clock: clk_disable called on independent clock %s which has no enable_reg

Shouldn't those clocks use clkops_null then?

 2. clkdm_name entry: 
The issue is, two entries available for clockdomain associated for 
module/clock 
 - hwmod_data.main_clk and 
 - clk.clkdm_name
 
They must match, right? The parent/root clocks flows from one domain to 
another domain, so I have to keep the nodes just for sake of matching 
clockdomain entry present in associated main_clk data.
 
I am still reviewing the code from Rajendra, but one of Rajendra's patch 
actually will help here, made it to use hwmod_data.clkdm (if available) 
always, instead of directly using clk.clkdm.

Well because of this CLKDIV32K snafu, we'll need to keep the clock 
framework-based clockdomain control for AM33xx, at the very least for 
the CLKDIV32K clock.

I'd suggest starting with specifying a clockdomain name for each clock.  
If nothing else, this should help think through the power management 
behavior for each clock.  Then those can be easily removed later with a 
simple grep.

 3. If I understand correctly, hwmod_data.main_clk is functional clock and
hwmod_ocp_if.clk is interface clock, right?

Basically, yes.  To be more precise, in cases where 
modules have multiple functional clocks, hwmod_data.main_clk is the 
functional clock that is needed in order for register reads and writes to 
the IP block to succeed.

So currently, I have mentioned same entry in both the places (especially 
for Peripherals/modules).
I am planning to remove ocp_if/clk entry data for all modules..

Hmmm, could you explain this further?

Every ocp_if structure that you create should have an interface clock 
specified.  And almost all of your hwmods should have a main_clk 
specified.


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

RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Hiremath, Vaibhav]

On Wed, May 23, 2012 at 20:38:27, Paul Walmsley wrote:
 Hi Vaibhav
 
 On Wed, 23 May 2012, Hiremath, Vaibhav wrote:
 
  I used your cleaned version of clocktree data, where you have removed all 
  leaf-nodes and merged multiple clocks nodes into one; but it did not work. 
  I 
  attempted to review the cleanup and tried to debug, but found it bit hard 
  to 
  come back to working clocktree from stripped version. So moved back to my 
  submitted clocktree and started stripping the clock leaf-nodes, same way 
  you 
  had done it. Now I reached to the stage where I have working clocktree 
  without peripheral leaf-nodes and booting on BeagleBone.
 
 Okay great, please post that to the list so we can diff it against the 
 version that I did, and also so we can queue it for merging in 3.6?
 

Just doing final round of review and cleanup...may be by tomorrow, I should 
be able to submit it (without common-clock framework).


  Just FYI (may need your help), I got into some issues (still open) during 
  this cleanup -
  
  1. In cases where we have clock selection option for node-leafs, like, 
 Timers, I removed enable_reg entry from the node, which results into a 
 kernel error message from function omap2_dflt_clk_disable()
  
  clock: clk_disable called on independent clock %s which has no enable_reg
 
 Shouldn't those clocks use clkops_null then?
 
  2. clkdm_name entry: 
 The issue is, two entries available for clockdomain associated for 
 module/clock 
  - hwmod_data.main_clk and 
  - clk.clkdm_name
  
 They must match, right? The parent/root clocks flows from one domain to 
 another domain, so I have to keep the nodes just for sake of matching 
 clockdomain entry present in associated main_clk data.
  
 I am still reviewing the code from Rajendra, but one of Rajendra's patch 
 actually will help here, made it to use hwmod_data.clkdm (if available) 
 always, instead of directly using clk.clkdm.
 
 Well because of this CLKDIV32K snafu, we'll need to keep the clock 
 framework-based clockdomain control for AM33xx, at the very least for 
 the CLKDIV32K clock.
 
 I'd suggest starting with specifying a clockdomain name for each clock.  
 If nothing else, this should help think through the power management 
 behavior for each clock.  Then those can be easily removed later with a 
 simple grep.
 
  3. If I understand correctly, hwmod_data.main_clk is functional clock and   
   
 hwmod_ocp_if.clk is interface clock, right?
 
 Basically, yes.  To be more precise, in cases where 
 modules have multiple functional clocks, hwmod_data.main_clk is the 
 functional clock that is needed in order for register reads and writes to 
 the IP block to succeed.
 

I believe register read/write to IP block is depends on only interface 
Clocks? Atleast in case of OMAP3, it was like that, right??


Another issues is, 

I came across situation where, two modules fall into different clock domains 
but their functional clock is happened to be coming from same 
source/dpll-divider. So in order to satisfy clkdm match between them, I have
kept nodes without enable_regs.



 So currently, I have mentioned same entry in both the places (especially 
 for Peripherals/modules).
 I am planning to remove ocp_if/clk entry data for all modules..
 
 Hmmm, could you explain this further?
 

what if, module only has interface clock? Should it be present as main_clk or 
ocp_if.clk or both??
Example would be, TPCC, TPTC, smartreflex, etc...

Thanks,
Vaibhav

 Every ocp_if structure that you create should have an interface clock 
 specified.  And almost all of your hwmods should have a main_clk 
 specified.
 
 
 - Paul
 

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

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[David Brown]

On Fri, Nov 18, 2011 at 04:47:17PM +0530, Rajendra Nayak wrote:

 + xyzreg: regulator@0 {
 + regulator-min-microvolt = 100;
 + regulator-max-microvolt = 250;
 + regulator-always-on;
 + vin-supply = vin;
 + };

Just noticed this, but the '@0' shouldn't be on the name, since there
isn't a reg attribute on this node.  Perhaps it should be
regulator-xyz?

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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

Re: rx51: support for lis3lv02d accelerometer

[Pali Rohár]

On Monday 21 May 2012 09:08:40 Tony Lindgren wrote:
 Hi Pali,

 * Tony Lindgren t...@atomide.com [120508 17:12]:
  * Pali Rohár pali.ro...@gmail.com [120504 08:41]:
   Hi!
  
   Upstream linux kernel has already driver for lis3lv02d
   accelerometer in drivers/misc/lis3lv02d. So now can be
   added also platform support for nokia rx51. Patch exists
   for long time in meego obs repository:
   https://build.pub.meego.com/package/view_file?file=linux-2
   .6-omap-rx51-Platform-support-for-lis3lv02d-acceleromet.pat
   chpackage=kernel-adaptation-n900project�%3AAdaptation%3
   AN900
  
   It is possible to include this patch to upstream kernel?
 
  Thanks, applying into board branch with From: Ameya as in the
  link above.

 Just noticed that this one is still using OMAP_GPIO_IRQ that
 won't work any longer. Can you please send a fix on top of this
 patch against linux next to fix it?

 The fix is to use gpio_to_irq() in the related init function
 instead of static OMAP_GPIO_IRQ in the data structure.

 Regards,

 Tony

Sorry, but now I do not have time for it. Tony, if fix is simple
can you do it?

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.

[PATCH] omap2+: add drm device

[Andy Gross]

Register OMAP DRM/KMS platform device.  DMM is split into a
separate device using hwmod.

Signed-off-by: Andy Gross andy.gr...@ti.com
---
 arch/arm/mach-omap2/Makefile   |4 ++
 arch/arm/mach-omap2/drm.c  |   61 
 drivers/staging/omapdrm/omap_drv.h |2 +-
 drivers/staging/omapdrm/omap_priv.h|   55 
 include/linux/platform_data/omap_drm.h |   52 +++
 5 files changed, 118 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/mach-omap2/drm.c
 delete mode 100644 drivers/staging/omapdrm/omap_priv.h
 create mode 100644 include/linux/platform_data/omap_drm.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y  += dsp.o
 endif
 
+ifneq ($(CONFIG_DRM_OMAP),)
+obj-y  += drm.o
+endif
+
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
new file mode 100644
index 000..72e0f01b
--- /dev/null
+++ b/arch/arm/mach-omap2/drm.c
@@ -0,0 +1,61 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
+   .name = omapdrm,
+   .id = 0,
+};
+
+static int __init omap_init_drm(void)
+{
+   struct omap_hwmod *oh = NULL;
+   struct platform_device *pdev;
+
+   /* lookup and populate the DMM information, if present - OMAP4+ */
+   oh = omap_hwmod_lookup(dmm);
+
+   if (oh) {
+   pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+   false);
+   WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+   oh-name);
+   }
+
+   return platform_device_register(omap_drm_device);
+
+}
+
+arch_initcall(omap_init_drm);
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index b7e0f07..96296e0 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -25,8 +25,8 @@
 #include linux/types.h
 #include drm/drmP.h
 #include drm/drm_crtc_helper.h
+#include linux/platform_data/omap_drm.h
 #include omap_drm.h
-#include omap_priv.h
 
 #define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
 #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */
diff --git a/drivers/staging/omapdrm/omap_priv.h 
b/drivers/staging/omapdrm/omap_priv.h
deleted file mode 100644
index ef64414..000
--- a/drivers/staging/omapdrm/omap_priv.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * include/drm/omap_priv.h
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Rob Clark r...@ti.com
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see http://www.gnu.org/licenses/.
- */
-
-#ifndef __OMAP_PRIV_H__
-#define __OMAP_PRIV_H__
-
-/* Non-userspace facing APIs
- */
-
-/* optional platform data to configure the default configuration of which
- * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
- * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
- * one manager, with priority given to managers that are 

Re: [PATCH 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

Hi Tony, Benoit,

On 1 May 2012 12:47, Omar Ramirez Luna omar.l...@linaro.org wrote:
 To allow mailbox driver to function with device tree.

 Tested in OMAP4 and OMAP3. OMAP2 untested.

 Omar Ramirez Luna (2):
  OMAP: mailbox: add device tree support
  arm/dts: OMAP2+: Add mailbox nodes

  .../devicetree/bindings/arm/omap/mailbox.txt       |    9 +
  arch/arm/boot/dts/omap2.dtsi                       |    5 +
  arch/arm/boot/dts/omap3.dtsi                       |    5 +
  arch/arm/boot/dts/omap4.dtsi                       |    5 +
  arch/arm/mach-omap2/devices.c                      |    3 +++
  arch/arm/mach-omap2/mailbox.c                      |   12 
  6 files changed, 39 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

Can you share your thoughts for these patches?

Regards,

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

Re: [PATCH v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup

[Kevin Hilman]

Govindraj.R govindraj.r...@ti.com writes:

 From: Govindraj.R govindraj.r...@ti.com

 The commit (bce492c0  ARM: OMAP2+: UART: Fix incorrect population of
 default uart pads) removed default uart pads that where getting populated
 and which was making rx pin wakeup capable. If uart pads were used in
 different mode by any other module then it would fail since the default
 pads took over all the uart pins forcefully. With removal of default pads
 the rx_pad wakeup for console uart while waking up from off mode is broken.

 Utilise the mux api available to probe the availability of mux pins
 in uart mode and probe for availability of uart pin in mux mode0
 if uart is available as uart pin itself then configure rx pin
 as wakeup capable.

 This patch itself doesn't cater to all boards. Boards using uart rx wakeup
 mechanism should ensure the usage of omap_serial_init_port by configuring
 required uart ports and pass necessary mux data, till then this probing of
 uart pins can cater to enabling of rx pad wakeup to most of the boards.

 This patch can also throw some boot warning from _omap_mux_get_by_name
 if pin is requested for availability is not present while dynamically probing
 the uart pins availability such boot warnings can be addressed only when board
 files are patched with omap_serial_init_port calls passing the right pads
 needed for a given port.

 Discussion Threads for reference:
 http://www.spinics.net/lists/linux-omap/msg69859.html
 http://www.spinics.net/lists/linux-omap/msg68659.html

 Cc: Felipe Balbi ba...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Russ Dill russ.d...@gmail.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Ameya Palande ameya.pala...@ti.com
 Signed-off-by: Govindraj.R govindraj.r...@ti.com

Tony, it's up to you if you're OK with this mux interface, but I can at
least confirm that this gets runtime PM + UART wakeups working again on
the boards I tried: 3530/Overo, 3430/n900, 3530/OMAP3EVM.

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

MFD USB host: prevents CORE retention in idle

[Kevin Hilman]

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.

Any ideas what's going on here?  Is this expected behavior?

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

Re: MFD USB host: prevents CORE retention in idle

[Kevin Hilman]

On 05/23/2012 05:01 PM, Kevin Hilman wrote:

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.

Any ideas what's going on here?  Is this expected behavior?



If it helps, attached is a bootlog after enabling debug for 
mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related 
warnings from this driver as well.  Not sure if they're relevant:


usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

With debug enabled, I see the runtime resume during init followed by the 
runtime suspend.


[0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed 
error:-22

[0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
[0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
[0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
[0.944641] usbhs_omap usbhs_omap: OMAP3 ES version  ES2.1
[0.944671] usbhs_omap usbhs_omap: UHH setup done, 
uhh_hostconfig=8000121d

[0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend

However, later in the boot I see a runtime_resume and never see another 
suspend.  That seems to be the root cause of CORE not hitting retention.


From the boot log:

[2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
[2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
[3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
[3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 
pcc=3 ordered ports=3
[3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 
uframes 256/512/1024 park
[3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3 
ithresh=8 period=1024 Reset HALT

[3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller

Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how 
this driver is being runtime resumed.  Presumably it's due to how the 
rest of the USB stack works, which I'm not at all familiar with.


Hopefully, the above is enough to debug the problem,

Thanks,

Kevin
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.4.0-rc7-pm+debug+initramfs-01073-g0ecc382-dirty 
(khilman@paris) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #20 SMP Wed 
May 23 17:10:56 PDT 2012
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] Machine: Gumstix Overo
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c09c0dc0, node_mem_map 
c0f1e000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 64768 pages, LIFO batch:15
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz
[0.00] PERCPU: Embedded 9 pages/cpu @c1124000 s12992 r8192 d15680 u36864
[0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk 
ip=192.168.1.157:192.168.1.5:192.168.1.254:255.255.255.0:overo:eth0:none 
root=/dev/nfs 
nfsroot=192.168.1.236:/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=409
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 243328k/243328k available, 18816k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc066da70   (6551 kB)
[  

Re: [PATCH v3 08/10] arm: omap4panda: Add support for omap4iss camera

[Sergio Aguirre]

Hi Tony,

On Tue, May 8, 2012 at 6:46 PM, Tony Lindgren t...@atomide.com wrote:
 * Sergio Aguirre saagui...@ti.com [120502 08:21]:
 This adds support for camera interface with the support for
 following sensors:

 - OV5640
 - OV5650

 It seems that at this point we should initialize new things like this
 with DT only. We don't quite yet have the muxing in place, but I'd
 rather not add yet another big platform_data file for something that
 does not even need to be there for DT booted devices.

Ok.

I'll look at that.

By the way, I've been very out of the loop on al DT related development..

Are these instructions valid for current master k.org branch?

http://omappedia.org/wiki/Device_Tree#Booting_with_DT_blob

Regards,
Sergio


 Regards,

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