date:20130409

On 04/09/2013 08:52 AM, Santosh Shilimkar wrote:
 I suggest Peter resend the patch with also Grant + Linus W cc:d so
 they can queue it unless there are other related patches pending
 somewhere else.

 Am curious on your suggestion. DMA engine patches are going via Vinod
 Koul's tree so I think the $subject patch should follow the same
 tree, No ?

AFAIK Vinod should be the correct person to pick it up, but I can CC Grant and
Linus W as well.

 Peter, if you plan to re-send, feel free to add my ack.

I'll figure out which stable release should have this applied and will resend.

-- 
Péter
--
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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels

On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
 Now that I'm back from a short 4 day break, then yes, and the answer is
 that it's fine.  Who's handling the patch?

Thank you,
Péter
--
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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels

Russell,

On 04/09/2013 09:19 AM, Peter Ujfalusi wrote:
 On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
 Now that I'm back from a short 4 day break, then yes, and the answer is
 that it's fine.  Who's handling the patch?
 
 Thank you,
 Péter

Can I add you acked-by to the patch?

-- 
Péter
--
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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels

2013-04-09 Thread Vinod Koul

On Tue, Apr 09, 2013 at 09:19:31AM +0200, Peter Ujfalusi wrote:
 On 04/09/2013 08:52 AM, Santosh Shilimkar wrote:
  I suggest Peter resend the patch with also Grant + Linus W cc:d so
  they can queue it unless there are other related patches pending
  somewhere else.
 
  Am curious on your suggestion. DMA engine patches are going via Vinod
  Koul's tree so I think the $subject patch should follow the same
  tree, No ?
 
 AFAIK Vinod should be the correct person to pick it up, but I can CC Grant and
 Linus W as well.
Yes it should go thru dmaengine tree, sorry was travelling hence the delay, pls
resend the patch and I will do the needful
 
  Peter, if you plan to re-send, feel free to add my ack.
 
 I'll figure out which stable release should have this applied and will resend.
 
 -- 
 Péter
--
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 0/6] mfd: omap-usb-host: Device tree support for 3.10

2013-04-09 Thread Samuel Ortiz

Hi Roger,

On Mon, Mar 25, 2013 at 12:42:04PM +0200, Roger Quadros wrote:
 Hi Samuel,
 
 I've rebased this now on top of 3.9-rc4. Please pull this into your
 next branch when appropriate. Thanks.
 
 The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
 
   Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
 
 are available in the git repository at:
   git://github.com/rogerq/linux.git usbhost-mfd-next
 
 Roger Quadros (5):
   mfd: omap-usb-host: update nports in platform_data
   mfd: omap-usb-host: Remove PHY reset handling code
   mfd: omap-usb-tll: move configuration code to omap_tll_init()
   mfd: omap-usb-tll: Add device tree support and binding information
   mfd: omap-usb-host: Add device tree support and binding information
I had to apply them manually, as patches #2 and #5 do not apply.
I am pushing #1, #3 and #4, please rebase 2 and 5 on top of mfd-next and
resend them to me.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

2013-04-09 Thread Thierry Reding

On Mon, Apr 08, 2013 at 03:16:57PM -0700, Tony Lindgren wrote:
 * Thierry Reding thierry.red...@avionic-design.de [130408 15:01]:
  On Mon, Apr 08, 2013 at 02:46:24PM -0700, Tony Lindgren wrote:
   * Andrew Chew ac...@nvidia.com [130313 15:37]:
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe.  Initialize a dummy regulator to satisfy this
requirement.

Signed-off-by: Andrew Chew ac...@nvidia.com
---
Changed the device name of the backlight regulator supply to 
pwm-backlight,
per Peter's comment.

Changed the name of the regulator to backlight-enable, per Thierry's
suggestion.
   
   Thanks applying into omap-for-v3.10/board. Note that I'm not taking the
   second one, that should be resent to the related driver maintainers.
   You can get that list by running scripts/get_maintainer.pl against it.
  
  The plan was to take these all through one tree, preferably the PWM tree
  because it's all PWM related and the pwm-backlight change will go
  through that tree as well. Technically these individual patches can be
  applied as is and aren't harmful, but keeping track of the dependencies
  might be difficult if they go in via separate trees.
 
 Registering the regulator alone should not do anything. Also the driver
 should do the right thing if the regulator is not yet registered.
 
 Can you please check your driver patch so the driver won't do anything
 if the regulator is not (yet) registered and repost it alone as I've
 already applied the board-*.c change.

That's not the way that the regulator subsystem works, unfortunately.
There's no way you can distinguish between the case where a regulator
just hasn't been registered yet, or whether it's missing. That's the
whole reason why we need to add the dummy regulators in the first
place.

 The reason why we want to do queue these patches separately is to cut
 away the dependency between drivers and the core arch/arm changes. 
 Otherwise we'll end up with pointless merge conflicts as we've seen
 earlier several times with the USB patches for example.

We could possibly postpone merging the pwm-backlight changes until all
other patches have been merged. If you have this in you for-3.10 branch
I guess it will go into linux-next when the 3.9 merge window closes? If
so I could possibly base my for-3.10 branch on your branch if you can
provide a stable one that you can guarantee not to rebase. There are
other alternatives too, but certainly the easiest would've been to take
all patches through the PWM tree. The potential for merge conflicts
should be rather minimal.

Thierry


pgpeLKFSlr5GV.pgp
Description: PGP signature

RE: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Monday, April 08, 2013 11:00 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; khil...@linaro.org; p...@pwsan.com;
 Nayak, Rajendra; linux-arm-ker...@lists.infradead.org
 Subject: Re: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter
 for debugSS module control

 Hi,

 * hvaib...@ti.com hvaib...@ti.com [130304 03:40]:
  From: Vaibhav Hiremath hvaib...@ti.com

  Currently there is no clean mechanism to control debugSS module and
  you have to always keep clocks enabled, either,

  - By enabling it during boot as part of clk_init function.
  Or
  - By having HWMOD_INIT_NO_IDLE flag in hwmod data.

  Based on the discussion,
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg81771.html

  This patch introduces new kernel parameter omap_debugss_en,
  which will allow user to control debugSS module enable/disable
  part during boot-time.

 I suggest you just make this part into a standard DT only
 device driver. That way the command line parsing and clock
 enabling can happen the normal way.

That’s good idea, as we are moving towards DT only boot support.
Also, are you suggesting to have both command-line param and DT
Property for this?

 Is there any reason why this could not be a loadable module?

Because we want to keep it enabled before late_initcall. As part of 
late_initcall
Clock/hwmod framework will start disabling unused modules, which will impact the
Debugs as well. Consider the case where this debugss is loaded as a module, the 
user
Will loose the JTAG connection until the module is loaded; and once module is
Loaded, he has to again re-connect to the debugss.

With only DT option the code will look like below, is this what you also have 
in your mind -

arch/arm/boot/dts/am33xx.dtsi:

debugss: debugss@4b00 {
compatible = ti,debugss;
ti,hwmods = debugss;
reg = 0x4b00 100;
status = disabled;/* User need to enable it if he need 
JTAG connectivity*/
};

arch/arm/mach-omap2/debugss.c:

static int __init _omap2_debugss_enable(void)
{
struct device_node *np;

np = of_find_matching_node(oh_name);
if (!node || ! of_device_is_available()) {
pr_err(debugss device is not found\n);
return -ENODEV;
}
...
hwmod lookup./setup/enable along with optional clock enable.
...

}
device_initcall(_omap2_debugss_enable);

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: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter for debugSS module control

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Monday, April 08, 2013 11:01 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; khil...@linaro.org; p...@pwsan.com;
 Nayak, Rajendra; linux-arm-ker...@lists.infradead.org
 Subject: Re: [RFC PATCH 0/3] ARM: OMAP2+: Add command line parameter
 for debugSS module control

 * Hiremath, Vaibhav hvaib...@ti.com [130314 04:33]:
   From: Hiremath, Vaibhav
   This patch introduces new kernel parameter omap_debugss_en,
   which will allow user to control debugSS module enable/disable
   part during boot-time.

   In case of OMAP3, the debugSS is part of EMU domain and
   is currently controlled by clock tree alone.

   In case of OMAP4, the debugSS is part of EMU domain and
   is currently controlled by clock tree, as MODULEMODE_SWCTRL
   is not defined for hwmod.

   In case of AM335x, the debugSS is in wakeup domain and is currently
   controlled through hwmod alone. Currently we keep it always
 enabled.

  Any comments or input on this patch series?

 No comments on adding the clocks, but the enabling of
 them should be just a regular device driver.

Thanks for review, on this patch I will add your Reviewed-by line on next 
version
Of the patch-series.

I have just responded my comment to the other mail on this, and based on
Your response we can conclude. 

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/1] of/irq: store IRQ trigger/level in struct resource flags

2013-04-09 Thread Javier Martinez Canillas

On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote:
 On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
 On 04/09/2013 12:16 AM, Stephen Warren wrote:
 On 04/08/2013 04:05 PM, Rob Herring wrote:
 On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
 According to 
 Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 the #interrupt-cells property of an interrupt-controller is used
 to define the number of cells needed to specify a single interrupt.
 ...
 But the type is never returned so it can't be saved on the IRQ struct
 resource flags member.

 This means that drivers that need the IRQ type/level flags defined in
 the DT won't be able to get it.

 But the interrupt controllers that need the information should be able
 to get to it via irqd_get_trigger_type. What problem exactly are you
 trying to fix? What driver would use this?

 FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
 back, I'm not sure if that was the right thing or whether I should have
 sent this same patch:-)


 Hi Stephen,

 I'm glad you agree :-)

 I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags for
 the IRQ with irqd_get_trigger_type() but I prefer $subject because:

 irqd_get_trigger_type probably is not meant for outside of irqchips.
 Creating an irq_get_irq_type function which takes an irq number would be
 the right function as that does not expose struct irq_data.


Ok, I can add an irqd_get_trigger_type() that just return the flags to
the caller without exposing the struct irq_data and using it on the
SMSC 911x driver instead using struct resource *irq_res-flags

I hope networking folks understand why this change is needed in this
driver to get the type/level flags for an IRQ defined on a DT...

 a) This works in the non-DT case with board files and filling the resources 
 from
 platform data in arch/arm/mach-omap2/gpmc-smsc911x.c. So this is definitely a
 bug on the DT core.

 And hackery/abuse like this:

 arch/arm/mach-omap2/board-3630sdp.c:32:.flags  =
 GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,

 b) I don't see why of_irq_to_resource() should discard the type/level flags 
 when
 filling the IORESOURCE_IRQ if it was specified on the DT.

 c) We will have to change all drivers that expect to get the IRQ type flags 
 from
 a IORESOURCE_IRQ struct resource.

 I'm not convinced that is a high number of drivers. Nearly all the
 occurrences of IORESOURCE_IRQ_ in drivers/ are for ISA (acpi/pnp) and
 drivers for ISA devices.


If IORESOURCE_IRQ is just supposed to be used for ISA devices drivers
that use ACPI/PnP instead DT, then of_irq_to_resource() callers should
just use irq_of_parse_and_map() that returns the virtual IRQ number
for an index within a controller instead of a struct resource.

In fact I wonder what's the point to have an of_irq_to_resource()
function at all if  IORESOURCE_IRQ is not supposed to be used for
devices connected through dumb buses that need a DT and the struct
resource will only hold the mapped virtual IRQ number and no the IRQ
flags.

 Rob


Best regards,
Javier
--
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/1] of/irq: store IRQ trigger/level in struct resource flags

2013-04-09 Thread Javier Martinez Canillas

On Tue, Apr 9, 2013 at 10:26 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 On Tue, Apr 9, 2013 at 4:45 AM, Rob Herring robherri...@gmail.com wrote:
 On 04/08/2013 05:56 PM, Javier Martinez Canillas wrote:
 On 04/09/2013 12:16 AM, Stephen Warren wrote:
 On 04/08/2013 04:05 PM, Rob Herring wrote:
 On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote:
 According to 
 Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 the #interrupt-cells property of an interrupt-controller is used
 to define the number of cells needed to specify a single interrupt.
 ...
 But the type is never returned so it can't be saved on the IRQ struct
 resource flags member.

 This means that drivers that need the IRQ type/level flags defined in
 the DT won't be able to get it.

 But the interrupt controllers that need the information should be able
 to get to it via irqd_get_trigger_type. What problem exactly are you
 trying to fix? What driver would use this?

 FYI, that is indeed what I did in sound/soc/codecs/wm8903.c. Thinking
 back, I'm not sure if that was the right thing or whether I should have
 sent this same patch:-)


 Hi Stephen,

 I'm glad you agree :-)

 I could change drivers/net/ethernet/smsc/smsc911x.c to get the type flags 
 for
 the IRQ with irqd_get_trigger_type() but I prefer $subject because:

 irqd_get_trigger_type probably is not meant for outside of irqchips.
 Creating an irq_get_irq_type function which takes an irq number would be
 the right function as that does not expose struct irq_data.


 Ok, I can add an irqd_get_trigger_type() that just return the flags to

I meant irq_get_irq_type() of course.

Best regards,
Javier
--
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

[PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m as the main clock

2013-04-09 Thread Kishon Vijay Abraham I

commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and hence made as the main
clock for ocp2scp.

Cc: Keerthy j-keer...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 9e05765..c1fb090 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2714,16 +2714,12 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
{ }
 };
 
-static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
-   { .role = 48mhz, .clk = ocp2scp_usb_phy_phy_48m },
-};
-
 /* ocp2scp_usb_phy */
 static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name   = ocp2scp_usb_phy,
.class  = omap44xx_ocp2scp_hwmod_class,
.clkdm_name = l3_init_clkdm,
-   .main_clk   = func_48m_fclk,
+   .main_clk   = ocp2scp_usb_phy_phy_48m,
.prcm = {
.omap4 = {
.clkctrl_offs = 
OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
@@ -2732,8 +2728,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = 
{
},
},
.dev_attr   = ocp2scp_dev_attr,
-   .opt_clks   = ocp2scp_usb_phy_opt_clks,
-   .opt_clks_cnt   = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
 };
 
 /*
-- 
1.7.10.4

--
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 0/6] mfd: omap-usb-host: Device tree support for 3.10

Samuel,

You had the conflicts because a patch [*] was introduced and is not
required since the reset logic is being removed from the driver.

Anyways, I've rebased the 2 patches on top of mfd-next, so now it
shouldn't matter.

cheers,
-roger

[*]
commit 71f4b9cdfccfb82cff702fe61f4ace97a1dfb0e0
Author: Jingoo Han jg1@samsung.com
Date:   Wed Feb 20 18:29:30 2013 +0900

mfd: omap-usb-host: Use devm_gpio_request_one()

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

[PATCH 1/2] mfd: omap-usb-host: Remove PHY reset handling code

PHY reset GPIO handling will be done in the PHY driver

Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/omap-usb-host.c |   28 
 1 files changed, 0 insertions(+), 28 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eb5db28..138ee98 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -430,24 +430,10 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
usbhs_hcd_omap *omap,
 static void omap_usbhs_init(struct device *dev)
 {
struct usbhs_hcd_omap   *omap = dev_get_drvdata(dev);
-   struct usbhs_omap_platform_data *pdata = omap-pdata;
unsignedreg;
 
dev_dbg(dev, starting TI HSUSB Controller\n);
 
-   if (pdata-phy_reset) {
-   if (gpio_is_valid(pdata-reset_gpio_port[0]))
-   devm_gpio_request_one(dev, pdata-reset_gpio_port[0],
-GPIOF_OUT_INIT_LOW, USB1 PHY reset);
-
-   if (gpio_is_valid(pdata-reset_gpio_port[1]))
-   devm_gpio_request_one(dev, pdata-reset_gpio_port[1],
-GPIOF_OUT_INIT_LOW, USB2 PHY reset);
-
-   /* Hold the PHY in RESET for enough time till DIR is high */
-   udelay(10);
-   }
-
pm_runtime_get_sync(dev);
 
reg = usbhs_read(omap-uhh_base, OMAP_UHH_HOSTCONFIG);
@@ -476,20 +462,6 @@ static void omap_usbhs_init(struct device *dev)
dev_dbg(dev, UHH setup done, uhh_hostconfig=%x\n, reg);
 
pm_runtime_put_sync(dev);
-   if (pdata-phy_reset) {
-   /* Hold the PHY in RESET for enough time till
-* PHY is settled and ready
-*/
-   udelay(10);
-
-   if (gpio_is_valid(pdata-reset_gpio_port[0]))
-   gpio_set_value_cansleep
-   (pdata-reset_gpio_port[0], 1);
-
-   if (gpio_is_valid(pdata-reset_gpio_port[1]))
-   gpio_set_value_cansleep
-   (pdata-reset_gpio_port[1], 1);
-   }
 }
 
 /**
-- 
1.7.4.1

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

[PATCH 2/2] mfd: omap-usb-host: Add device tree support and binding information

Allows the OMAP HS USB host controller to be specified
via device tree.

Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Mark Rutland mark.rutl...@arm.com
---
 .../devicetree/bindings/mfd/omap-usb-host.txt  |   80 ++
 drivers/mfd/omap-usb-host.c|  161 +++-
 2 files changed, 235 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..b381fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+  from the IP's revision register but can be overridden by specifying
+  this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+  from 1 to 3. If the port mode is not specified, that port is treated
+  as unused. When specified, it must be one of the following.
+   ehci-phy,
+ehci-tll,
+ehci-hsic,
+ohci-phy-6pin-datse0,
+ohci-phy-6pin-dpdm,
+ohci-phy-3pin-datse0,
+ohci-phy-4pin-dpdm,
+ohci-tll-6pin-datse0,
+ohci-tll-6pin-dpdm,
+ohci-tll-3pin-datse0,
+ohci-tll-4pin-dpdm,
+ohci-tll-2pin-datse0,
+ohci-tll-2pin-dpdm,
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+  ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@4a064800 {
+   compatible = ti,ohci-omap3, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 76 0x4;
+   };
+
+   usbhsehci: ehci@4a064c00 {
+   compatible = ti,ehci-omap, usb-ehci;
+   reg = 0x4a064c00 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 77 0x4;
+   };
+};
+
+usbhshost {
+   port1-mode = ehci-phy;
+   port2-mode = ehci-tll;
+   port3-mode = ehci-phy;
+};
+
+usbhsehci {
+   phys = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 138ee98..d3b6e94 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
 /**
  * omap-usb-host.c - The USBHS core driver for OMAP EHCI  OHCI
  *
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
  * Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@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  of
@@ -27,6 +28,8 @@
 #include linux/platform_device.h
 #include linux/platform_data/usb-omap.h
 #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
 
 #include omap-usb.h
 
@@ -137,6 +140,49 @@ static inline u8 usbhs_readb(void __iomem *base, u8 reg)
 
 /*-*/
 
+/**
+ * Map 'enum usbhs_omap_port_mode' found in linux/platform_data/usb-omap.h
+ * to the device tree binding portN-mode found in
+ * 'Documentation/devicetree/bindings/mfd/omap-usb-host.txt'
+ */
+static const char * const port_modes[] = {
+   [OMAP_USBHS_PORT_MODE_UNUSED]   = ,
+   [OMAP_EHCI_PORT_MODE_PHY]   = ehci-phy,
+   [OMAP_EHCI_PORT_MODE_TLL]   = ehci-tll,
+   [OMAP_EHCI_PORT_MODE_HSIC]  = ehci-hsic,
+   [OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0]   = ohci-phy-6pin-datse0,
+   [OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM] = ohci-phy-6pin-dpdm,
+   [OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0]   = ohci-phy-3pin-datse0,
+   [OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM] = ohci-phy-4pin-dpdm,
+   [OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0]   = ohci-tll-6pin-datse0,
+   [OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM] = ohci-tll-6pin-dpdm,
+   [OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0]   = ohci-tll-3pin-datse0,
+   [OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM] =

Re: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m as the main clock

2013-04-09 Thread Benoit Cousson

Hi Kishon,

On 04/09/2013 10:28 AM, Kishon Vijay Abraham I wrote:
 commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
 functional clock causing regression in MUSB. But this 48MHz clock is a
 mandatory clock for usb phy attached to ocp2scp and hence made as the main
 clock for ocp2scp.

It is a fix for 3.9-rcX?

Regards,
Benoit

 
 Cc: Keerthy j-keer...@ti.com
 Cc: Benoît Cousson b-cous...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 index 9e05765..c1fb090 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -2714,16 +2714,12 @@ static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
   { }
  };
  
 -static struct omap_hwmod_opt_clk ocp2scp_usb_phy_opt_clks[] = {
 - { .role = 48mhz, .clk = ocp2scp_usb_phy_phy_48m },
 -};
 -
  /* ocp2scp_usb_phy */
  static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
   .name   = ocp2scp_usb_phy,
   .class  = omap44xx_ocp2scp_hwmod_class,
   .clkdm_name = l3_init_clkdm,
 - .main_clk   = func_48m_fclk,
 + .main_clk   = ocp2scp_usb_phy_phy_48m,
   .prcm = {
   .omap4 = {
   .clkctrl_offs = 
 OMAP4_CM_L3INIT_USBPHYOCP2SCP_CLKCTRL_OFFSET,
 @@ -2732,8 +2728,6 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod 
 = {
   },
   },
   .dev_attr   = ocp2scp_dev_attr,
 - .opt_clks   = ocp2scp_usb_phy_opt_clks,
 - .opt_clks_cnt   = ARRAY_SIZE(ocp2scp_usb_phy_opt_clks),
  };
  
  /*
 

--
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] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m as the main clock

2013-04-09 Thread Kishon Vijay Abraham I


Hi,

On Tuesday 09 April 2013 02:24 PM, Benoit Cousson wrote:

Hi Kishon,

On 04/09/2013 10:28 AM, Kishon Vijay Abraham I wrote:

commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
functional clock causing regression in MUSB. But this 48MHz clock is a
mandatory clock for usb phy attached to ocp2scp and hence made as the main
clock for ocp2scp.


It is a fix for 3.9-rcX?


Yeah.

Thanks
Kishon
--
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 0/6] mfd: omap-usb-host: Device tree support for 3.10

2013-04-09 Thread Samuel Ortiz

On Tue, Apr 09, 2013 at 11:39:16AM +0300, Roger Quadros wrote:
 Samuel,
 
 You had the conflicts because a patch [*] was introduced and is not
 required since the reset logic is being removed from the driver.
 
 Anyways, I've rebased the 2 patches on top of mfd-next, so now it
 shouldn't matter.
Both patches applied, thanks a lot.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

On 04/05/2013 06:58 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130405 03:44]:
 On 04/04/2013 07:41 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130404 00:39]:
 On 04/04/2013 02:42 AM, Tony Lindgren wrote:
 For v3.10, let's just make sure that USB works with DT as then
 after v3.10 we can make omap4 DT only and get rid of estimated
 7K lines of code and data. I guess this is the last piece missing
 for that, or are we also missing something else?

 For panda we just need a way to map the auxclk to the USB PHY device
 and the relevant dts data to get USB host working with DT.
 Beagle USB host should work already with DT without any changes.


 Can't you set up a clock alias for your device so it can find the
 auxclk when requesting it with the dev entry?


 which clock is mapped to which PHY device depends on board design
 and that cannot be per-determined at one place. This information
 needs to come from the board.dts file.
 
 OK that makes sense.
  
 There was an earlier attempt to provide a way of building clock aliases
 at runtime from device tree [1], but the current approach is way better

 [1]
 https://lkml.org/lkml/2013/3/12/241

 For the DT clock driver if needed for v3.10, how about just do a
 minimal drivers/clock/omap/ that uses the standard binding?
 Then that driver can just do clk_get() from cclock44xx_data.c

 I don't understand how to do it and why it is better than the current
 approach.
 
 Well your approach is fine as a first step moving all the clock
 code, but it needs to be a real driver under drivers/clock/omap.
 And the DT binding needs to stay the same for the driver(s) in the
 long term as we start moving clocks to DT + /lib/firmware.

The code needs to be there were the clock structs are defined.
Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4.

 
 If this all is too late for v3.10, I suggest you just set up the
 right clock alias for panda with machine_is_compatible flag in
 board-generic.c so we get EHCI working with DT for v3.10. Then
 it's easy to to deal with it properly for v3.11.

OK, let's do it this way for Panda for 3.10.

 
 How can that driver do clk_get() from cclock44xx_data.c?
 from where does it get the clk_id to pass into clk_get()?
 
 Can't you just use the clock name there to get it?

In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.

e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt

  
 for now? And then later on we'll just move all the clocks to a
 combination of DT + /lib/firmware.

 What is the benefit of moving clock data to /lib/firmware? We could
 as well just move it to DT only, no?
 
 DT only clocks option is naturally available with this too. It
 just gets easily inefficient with such a huge number of clocks.
  

OK.
 e.g. auxclk are required to be specified in DT nodes for USB PHY.
 Without this we can't get USB host working on Panda.

 OK. So if the USB PHY has a dev entry, can't you just set up a
 clock alias in struct omap_clk omap44xx_clks[] for it?

 I've explained why this can't be done above.
 
 Yes I understand now, the clock is board specific. 
   
 As Rajendra points out, it seems moving entire clock data to DT is not
 going to happen soon. So this is the simplistic way things can work.

 Right but seems like we can get started there without moving
 them all at once.

 What if we provide a complete clock list instead of only auxclks in
 dt_clks[]?

 This approach is similar to arch/arm/mach-imx/clk-imx35.c

 Device drivers can then use them as they migrate to DT. Then later
 we could migrate clock data to DT, without impacting device drivers.
 
 As long as the binding stays the same in the long run too, this
 clock remapping approach is just fine as a starting point. And
 the driver needs to go to drivers/clock/omap. But in the long run
 we just want to get the huge amounts static data out of the kernel
 for clocks and hwmod data to fix things for good.

In that case we need to identify what clocks need to be supported.
If it is all (~200) of them, is this method good enough?

cheers,
-roger
--
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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

On 04/05/2013 08:56 PM, Grygorii Strashko wrote:
 On 04/04/2013 07:41 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130404 00:39]:
 On 04/04/2013 02:42 AM, Tony Lindgren wrote:
 --- a/arch/arm/mach-omap2/cclock44xx_data.c
 +++ b/arch/arm/mach-omap2/cclock44xx_data.c
 @@ -27,6 +27,7 @@
   #include linux/clk-private.h
   #include linux/clkdev.h
   #include linux/io.h
 +#include linux/of.h
 #include soc.h
   #include iomap.h
 @@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
   CLK(NULL,cpufreq_ck,dpll_mpu_ck,CK_443X),
   };
   +static struct clk *scrm_clks[] = {
 +auxclk0_ck,
 +auxclk1_ck,
 +auxclk2_ck,
 +auxclk3_ck,
 +auxclk4_ck,
 +auxclk5_ck,
 +};
 Hmm I don't like the idea of specifying the auxclk both in the
 cclock44xx_data.c and in DT..
 Right, but till we have all clocks moved to DT we only need this
 approach for general purpose clocks that are not mapped to devices
 by hwmod.
 For v3.10, let's just make sure that USB works with DT as then
 after v3.10 we can make omap4 DT only and get rid of estimated
 7K lines of code and data. I guess this is the last piece missing
 for that, or are we also missing something else?

 Can't you set up a clock alias for your device so it can find the
 auxclk when requesting it with the dev entry?

 For the DT clock driver if needed for v3.10, how about just do a
 minimal drivers/clock/omap/ that uses the standard binding?
 Then that driver can just do clk_get() from cclock44xx_data.c
 for now? And then later on we'll just move all the clocks to a
 combination of DT + /lib/firmware.

 Hi Roger, Rajendra, All
 
 Sorry that disturbing you.

Hi Grygorri,

Nothing to disturb at all ;).

 
 I'm supporting Android OMAP4 kernels (K3.0/K3.4) and like to clarify few
 points regarding this approach (having into account possible future migrations
 on newer Kernels and OMAP5).
 If I understand everything right, this patch series allows to create clock 
 binding
 in DT using following syntax: clocks = aux_clks 3

Actually in v2 of the patch this would be clocks = clks 3

  - does it means that in worst case there will be ~200 clock IDs defined?

I'm afraid so yes. But when I wrote this I was only thinking of generic clocks, 
i.e. AUXCLKS.
So when we start talking of all clocks we might need to reconsider the approach.

  - does it means that clock nodes binding using phandles (human-friendly 
 notation)
 isn't going to be supported?
 for example:
 clocks = sys_clkin_ck
 clocks = dss_sys_clk dss_tv_clk dss_dss_clk)

This would depend if we define the clock nodes within DT or not. From what Tony
mentioned (i.e. inefficiency) it seems that the clock nodes won't be defined
in the device tree. Then we are left with using an index.
 
 I was horrified to think about the problems of this approach support
 (in case if there would be more then ~30 IDs) - just miss with on digit
 and weeks of debugging would be guaranteed.
 
 Please, say me that i'm wrong.

It is still not written in stone so if you have a better idea we could
go that route.

cheers,
-roger

 And why clock DT data can't be auto-generated like all other OMAP data
 to close this questions?
 
 Thanks.
 
 e.g. auxclk are required to be specified in DT nodes for USB PHY.
 Without this we can't get USB host working on Panda.
 OK. So if the USB PHY has a dev entry, can't you just set up a
 clock alias in struct omap_clk omap44xx_clks[] for it?
  
 As Rajendra points out, it seems moving entire clock data to DT is not
 going to happen soon. So this is the simplistic way things can work.
 Right but seems like we can get started there without moving
 them all at once.

 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

Re: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels

On 04/09/2013 09:26 AM, Vinod Koul wrote:
 Yes it should go thru dmaengine tree, sorry was travelling hence the delay, 
 pls
 resend the patch and I will do the needful

I already have the patch rebased on today's linux-next, just waiting for
Russell to confirm that I can add his Acked-by to the patch.
I take this from Russell as ACK: Now that I'm back from a short 4 day break,
then yes, and the answer is that it's fine.  Who's handling the patch?

But I want to be sure I can add that line...

-- 
Péter
--
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: [GIT PULL] mailbox driver framework for v3.10 merge window

On Thursday 04 April 2013, Anna, Suman wrote:
 OMAP and ST-Ericsson platforms are both using mailbox to communicate with 
 some coprocessors. This series creates a consolidated framework, living under 
 drivers/mailbox.
 The changes mainly contain:
 - create a mailbox framework independent from OMAP h/w
 - creates dbx500 mailbox driver for ST-Ericsson platforms
 - move the omap mailbox out of plat-omap/mach-omapX  adapting to the new 
 framework.
 - minor bug fixes in mailbox code

Pulled into a new next/mailbox branch, to keep it separate from the
existing subsystems.

As a note for you: when you send a pull request, please make sure that you
use a tag that includes the changeset text (your description above), so I
don't have to copy it from the email. I noticed that you do have a tag
mailbox-for-v3.10 in your tree, but the pull request was for the branch
with the same contents.

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

[PATCH 1/1] Documentation: dt: update TI GPMC ethernet binding properties

2013-04-09 Thread Javier Martinez Canillas

The GPMC timing properties for device-tree have been updated
by adding a -ns or -ps suffix to indicate the units of
time the property represents. Therefore, update the timing
property names for TI GPMC ethernet binding.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Jon, Benoit:

Sorry that I didn't send this patch before but I just realized
that the GPMC timing properties changed after

commit 5330dc16 (ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes)

got queued.

Tony,

Is still possible to queue this patch on your omap-for-v3.10/gpmc branch
or it is too late?

Thanks a lot and best regards,
Javier

 Documentation/devicetree/bindings/net/gpmc-eth.txt |   56 ++--
 1 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt 
b/Documentation/devicetree/bindings/net/gpmc-eth.txt
index 24cb4e4..ace4a64 100644
--- a/Documentation/devicetree/bindings/net/gpmc-eth.txt
+++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
@@ -26,16 +26,16 @@ Required properties:
 - bank-width:  Address width of the device in bytes. GPMC supports 
8-bit
and 16-bit devices and so must be either 1 or 2 bytes.
 - compatible:  Compatible string property for the ethernet child 
device.
-- gpmc,cs-on:  Chip-select assertion time
-- gpmc,cs-rd-off:  Chip-select de-assertion time for reads
-- gpmc,cs-wr-off:  Chip-select de-assertion time for writes
-- gpmc,oe-on:  Output-enable assertion time
-- gpmc,oe-off  Output-enable de-assertion time
-- gpmc,we-on:  Write-enable assertion time
-- gpmc,we-off: Write-enable de-assertion time
-- gpmc,access: Start cycle to first data capture (read access)
-- gpmc,rd-cycle:   Total read cycle time
-- gpmc,wr-cycle:   Total write cycle time
+- gpmc,cs-on-ns:   Chip-select assertion time
+- gpmc,cs-rd-off-ns:   Chip-select de-assertion time for reads
+- gpmc,cs-wr-off-ns:   Chip-select de-assertion time for writes
+- gpmc,oe-on-ns:   Output-enable assertion time
+- gpmc,oe-off-ns:  Output-enable de-assertion time
+- gpmc,we-on-ns:   Write-enable assertion time
+- gpmc,we-off-ns:  Write-enable de-assertion time
+- gpmc,access-ns:  Start cycle to first data capture (read access)
+- gpmc,rd-cycle-ns:Total read cycle time
+- gpmc,wr-cycle-ns:Total write cycle time
 - reg: Chip-select, base address (relative to chip-select)
and size of the memory mapped for the device.
Note that base address will be typically 0 as this
@@ -65,24 +65,24 @@ gpmc: gpmc@6e00 {
bank-width = 2;
 
gpmc,mux-add-data;
-   gpmc,cs-on = 0;
-   gpmc,cs-rd-off = 186;
-   gpmc,cs-wr-off = 186;
-   gpmc,adv-on = 12;
-   gpmc,adv-rd-off = 48;
-   gpmc,adv-wr-off = 48;
-   gpmc,oe-on = 54;
-   gpmc,oe-off = 168;
-   gpmc,we-on = 54;
-   gpmc,we-off = 168;
-   gpmc,rd-cycle = 186;
-   gpmc,wr-cycle = 186;
-   gpmc,access = 114;
-   gpmc,page-burst-access = 6;
-   gpmc,bus-turnaround = 12;
-   gpmc,cycle2cycle-delay = 18;
-   gpmc,wr-data-mux-bus = 90;
-   gpmc,wr-access = 186;
+   gpmc,cs-on-ns = 0;
+   gpmc,cs-rd-off-ns = 186;
+   gpmc,cs-wr-off-ns = 186;
+   gpmc,adv-on-ns = 12;
+   gpmc,adv-rd-off-ns = 48;
+   gpmc,adv-wr-off-ns = 48;
+   gpmc,oe-on-ns = 54;
+   gpmc,oe-off-ns = 168;
+   gpmc,we-on-ns = 54;
+   gpmc,we-off-ns = 168;
+   gpmc,rd-cycle-ns = 186;
+   gpmc,wr-cycle-ns = 186;
+   gpmc,access-ns = 114;
+   gpmc,page-burst-access-ns = 6;
+   gpmc,bus-turnaround-ns = 12;
+   gpmc,cycle2cycle-delay-ns = 18;
+   gpmc,wr-data-mux-bus-ns = 90;
+   gpmc,wr-access-ns = 186;
gpmc,cycle2cycle-samecsen;
gpmc,cycle2cycle-diffcsen;
 
-- 
1.7.7.6

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

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

2013-04-09 Thread Archit Taneja

When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
passes control to the update_plane op defined by the drm driver.

In omapdrm, we have a worker thread which queues framebuffers objects received
from update_plane and displays them at the appropriate time.

It is possible that the framebuffer is destoryed by userspace between the time
of calling the ioctl and apply-worker being scheduled. If this happens, the
apply-worker holds a pointer to a framebuffer which is already destroyed.

Take an extra refernece/unreference of the fb in omap_plane_update() to prevent
this from happening. A reference is taken of the fb passed to update_plane(),
the previous framebuffer (held by plane-fb) is unreferenced. This will prevent
drm from destroying the framebuffer till the time it's unreferenced by the
apply-worker.

This is in addition to the exisitng reference/unreference in update_pin(),
which is taken for the scanout of the plane's current framebuffer, and an
unreference the previous framebuffer.

Signed-off-by: Archit Taneja arc...@ti.com
Cc: Rob Clark robdcl...@gmail.com
---
 drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 2882cda..8d225d7 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
 {
struct omap_plane *omap_plane = to_omap_plane(plane);
omap_plane-enabled = true;
+
+   if (plane-fb)
+   drm_framebuffer_unreference(plane-fb);
+
+   drm_framebuffer_reference(fb);
+
return omap_plane_mode_set(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h,
-- 
1.7.10.4

--
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] drm/omap: Take a fb reference in omap_plane_update()

2013-04-09 Thread Rob Clark

On Tue, Apr 9, 2013 at 8:26 AM, Archit Taneja arc...@ti.com wrote:
 When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
 passes control to the update_plane op defined by the drm driver.

 In omapdrm, we have a worker thread which queues framebuffers objects received
 from update_plane and displays them at the appropriate time.

 It is possible that the framebuffer is destoryed by userspace between the time
 of calling the ioctl and apply-worker being scheduled. If this happens, the
 apply-worker holds a pointer to a framebuffer which is already destroyed.

 Take an extra refernece/unreference of the fb in omap_plane_update() to 
 prevent
 this from happening. A reference is taken of the fb passed to update_plane(),
 the previous framebuffer (held by plane-fb) is unreferenced. This will 
 prevent
 drm from destroying the framebuffer till the time it's unreferenced by the
 apply-worker.

 This is in addition to the exisitng reference/unreference in update_pin(),
 which is taken for the scanout of the plane's current framebuffer, and an
 unreference the previous framebuffer.

 Signed-off-by: Archit Taneja arc...@ti.com
 Cc: Rob Clark robdcl...@gmail.com

Good catch

Signed-off-by: Rob Clark robdcl...@gmail.com

 ---
  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
  1 file changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
 b/drivers/gpu/drm/omapdrm/omap_plane.c
 index 2882cda..8d225d7 100644
 --- a/drivers/gpu/drm/omapdrm/omap_plane.c
 +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
 @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
  {
 struct omap_plane *omap_plane = to_omap_plane(plane);
 omap_plane-enabled = true;
 +
 +   if (plane-fb)
 +   drm_framebuffer_unreference(plane-fb);
 +
 +   drm_framebuffer_reference(fb);
 +
 return omap_plane_mode_set(plane, crtc, fb,
 crtc_x, crtc_y, crtc_w, crtc_h,
 src_x, src_y, src_w, src_h,
 --
 1.7.10.4

--
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: [GIT PULL 3/5] omap board changes for v3.10 merge window

On Tuesday 09 April 2013, Tony Lindgren wrote:
 The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
 
   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.10/board-signed
 
 for you to fetch changes up to 06993d6a8a51b90fc78c8c3cb7a81c9b4b88c683:
 
   ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight (2013-04-08 
 14:01:05 -0700)
 
 
 Board related changes for v3.10 merge window. These are pretty
 much all non-critical fixes for platform device initialization
 that will be needed until we can drop the board-*.c files and
 move to DT based boot.
 

Pulled into next/boards branch

Arnd
--
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] drm/omap: Take a fb reference in omap_plane_update()

2013-04-09 Thread Daniel Vetter

On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
 When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
 passes control to the update_plane op defined by the drm driver.
 
 In omapdrm, we have a worker thread which queues framebuffers objects received
 from update_plane and displays them at the appropriate time.
 
 It is possible that the framebuffer is destoryed by userspace between the time
 of calling the ioctl and apply-worker being scheduled. If this happens, the
 apply-worker holds a pointer to a framebuffer which is already destroyed.
 
 Take an extra refernece/unreference of the fb in omap_plane_update() to 
 prevent
 this from happening. A reference is taken of the fb passed to update_plane(),
 the previous framebuffer (held by plane-fb) is unreferenced. This will 
 prevent
 drm from destroying the framebuffer till the time it's unreferenced by the
 apply-worker.
 
 This is in addition to the exisitng reference/unreference in update_pin(),
 which is taken for the scanout of the plane's current framebuffer, and an
 unreference the previous framebuffer.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 Cc: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
 b/drivers/gpu/drm/omapdrm/omap_plane.c
 index 2882cda..8d225d7 100644
 --- a/drivers/gpu/drm/omapdrm/omap_plane.c
 +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
 @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
  {
   struct omap_plane *omap_plane = to_omap_plane(plane);
   omap_plane-enabled = true;
 +
 + if (plane-fb)
 + drm_framebuffer_unreference(plane-fb);

Shouldn't the unref only happen once the flip has completed? Otherwise we
might free the memory which is still being scanned out and put some other
crap there.

Note that I've been too lazy to read the code, but I expected the unref of
the old one to happen after the ref-taking for the new one, with a vblank
wait/delay in between ... Might be that I'm completely off ;-)
-Daniel

 +
 + drm_framebuffer_reference(fb);
 +
   return omap_plane_mode_set(plane, crtc, fb,
   crtc_x, crtc_y, crtc_w, crtc_h,
   src_x, src_y, src_w, src_h,
 -- 
 1.7.10.4
 
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] drm/omap: Take a fb reference in omap_plane_update()

2013-04-09 Thread Rob Clark

On Tue, Apr 9, 2013 at 8:53 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
 When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb 
 and
 passes control to the update_plane op defined by the drm driver.

 In omapdrm, we have a worker thread which queues framebuffers objects 
 received
 from update_plane and displays them at the appropriate time.

 It is possible that the framebuffer is destoryed by userspace between the 
 time
 of calling the ioctl and apply-worker being scheduled. If this happens, the
 apply-worker holds a pointer to a framebuffer which is already destroyed.

 Take an extra refernece/unreference of the fb in omap_plane_update() to 
 prevent
 this from happening. A reference is taken of the fb passed to update_plane(),
 the previous framebuffer (held by plane-fb) is unreferenced. This will 
 prevent
 drm from destroying the framebuffer till the time it's unreferenced by the
 apply-worker.

 This is in addition to the exisitng reference/unreference in update_pin(),
 which is taken for the scanout of the plane's current framebuffer, and an
 unreference the previous framebuffer.

 Signed-off-by: Archit Taneja arc...@ti.com
 Cc: Rob Clark robdcl...@gmail.com
 ---
  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
  1 file changed, 6 insertions(+)

 diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
 b/drivers/gpu/drm/omapdrm/omap_plane.c
 index 2882cda..8d225d7 100644
 --- a/drivers/gpu/drm/omapdrm/omap_plane.c
 +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
 @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
  {
   struct omap_plane *omap_plane = to_omap_plane(plane);
   omap_plane-enabled = true;
 +
 + if (plane-fb)
 + drm_framebuffer_unreference(plane-fb);

 Shouldn't the unref only happen once the flip has completed? Otherwise we
 might free the memory which is still being scanned out and put some other
 crap there.

yup, there is a 2nd ref grabbed when we start scanout and dropped when
we finish scanout..  so that part was already covered.  What wasn't
covered before was the time between the ioctl and the worker thread
(which was grabbing/dropping the scanout ref)

BR,
-R

 Note that I've been too lazy to read the code, but I expected the unref of
 the old one to happen after the ref-taking for the new one, with a vblank
 wait/delay in between ... Might be that I'm completely off ;-)
 -Daniel

 +
 + drm_framebuffer_reference(fb);
 +
   return omap_plane_mode_set(plane, crtc, fb,
   crtc_x, crtc_y, crtc_w, crtc_h,
   src_x, src_y, src_w, src_h,
 --
 1.7.10.4

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] drm/omap: Take a fb reference in omap_plane_update()

2013-04-09 Thread Daniel Vetter

On Tue, Apr 9, 2013 at 3:17 PM, Rob Clark robdcl...@gmail.com wrote:
 diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
 b/drivers/gpu/drm/omapdrm/omap_plane.c
 index 2882cda..8d225d7 100644
 --- a/drivers/gpu/drm/omapdrm/omap_plane.c
 +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
 @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
  {
   struct omap_plane *omap_plane = to_omap_plane(plane);
   omap_plane-enabled = true;
 +
 + if (plane-fb)
 + drm_framebuffer_unreference(plane-fb);

 Shouldn't the unref only happen once the flip has completed? Otherwise we
 might free the memory which is still being scanned out and put some other
 crap there.

 yup, there is a 2nd ref grabbed when we start scanout and dropped when
 we finish scanout..  so that part was already covered.  What wasn't
 covered before was the time between the ioctl and the worker thread
 (which was grabbing/dropping the scanout ref)

Ah, I see. And the ordering doesn't seem to matter here since it's all
protected by locks (against races with the worker thread) anyway.
Thanks for the explanation.
-Daniel

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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: [GIT PULL 1/5] omap pm fixes for v3.10 merge window

On Tuesday 09 April 2013, Tony Lindgren wrote:
 The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:
 
   Merge branch 'for_3.10/omap_generic_cleanup_v2' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into 
 omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)
 

Pulled into next/cleanup branch because of the dependency. Thanks,

Arnd
--
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: [RFC v2] dmaengine: omap-dma: Start DMA without delay for cyclic channels

2013-04-09 Thread Russell King - ARM Linux

On Tue, Apr 09, 2013 at 09:21:40AM +0200, Peter Ujfalusi wrote:
 Russell,
 
 On 04/09/2013 09:19 AM, Peter Ujfalusi wrote:
  On 04/08/2013 07:09 PM, Russell King - ARM Linux wrote:
  Now that I'm back from a short 4 day break, then yes, and the answer is
  that it's fine.  Who's handling the patch?
  
  Thank you,
  Péter
 
 Can I add you acked-by to the patch?

You may, using the rmk+kernel address, not this one.  Thanks.
--
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

[PATCH] dmaengine: omap-dma: Start DMA without delay for cyclic channels

cyclic DMA is only used by audio which needs DMA to be started without a
delay.
If the DMA for audio is started using the tasklet we experience random
channel switch (to be more precise: channel shift).

Reported-by: Peter Meerwald pme...@pmeerw.net
CC: sta...@vger.kernel.org  # v3.7+
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
Hi Vinod,

Would it be possible to send this patch for 3.9. The channel shift (or switch)
issue in audio has been noticed recently and it turns out that it has been
present since 3.7 kernel.
It would be great if 3.9 kernel could work correctly out of box...

Changes since RFCv2:
- added Acked-by from Santosh and Russell

Thank you,
Peter

 drivers/dma/omap-dma.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 2ea3d7e..ec3fc4f 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -282,12 +282,20 @@ static void omap_dma_issue_pending(struct dma_chan *chan)
 
spin_lock_irqsave(c-vc.lock, flags);
if (vchan_issue_pending(c-vc)  !c-desc) {
-   struct omap_dmadev *d = to_omap_dma_dev(chan-device);
-   spin_lock(d-lock);
-   if (list_empty(c-node))
-   list_add_tail(c-node, d-pending);
-   spin_unlock(d-lock);
-   tasklet_schedule(d-task);
+   /*
+* c-cyclic is used only by audio and in this case the DMA need
+* to be started without delay.
+*/
+   if (!c-cyclic) {
+   struct omap_dmadev *d = to_omap_dma_dev(chan-device);
+   spin_lock(d-lock);
+   if (list_empty(c-node))
+   list_add_tail(c-node, d-pending);
+   spin_unlock(d-lock);
+   tasklet_schedule(d-task);
+   } else {
+   omap_dma_start_desc(c);
+   }
}
spin_unlock_irqrestore(c-vc.lock, flags);
 }
-- 
1.8.1.5

--
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: [GIT PULL 4/5] omap soc changes for v3.10 merge window

On Tuesday 09 April 2013, Tony Lindgren wrote:
 The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6:
 
   Linux 3.9-rc6 (2013-04-07 20:49:54 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.10/soc-signed
 
 for you to fetch changes up to 7a9819950f47dbf319895ee78220f2761f3687a3:
 
   ARM: OMAP4: Enable fix for Cortex-A9 erratas (2013-04-08 16:14:51 -0700)
 
 
 Changes needed for enabling SOC_BUS for the SoC revision
 information. Also enable few HW errata workarounds for omap4.

Pulled into next/soc, thanks!

Arnd
--
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: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

On Tuesday 09 April 2013, Tony Lindgren wrote:
 The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
 
   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.10/cleanup-pm-signed
 
 for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
 
   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into 
 omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
 
 
 
 PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
 
 OMAP3/4 CPUidle cleanups for v3.10

Adding Daniel and Rafael to Cc.

Is this series coordinated with the other cpuidle changes? Please tell me if 
this
is good to go into arm-soc.

Arnd

 
 Daniel Lezcano (1):
   ARM: omap3: cpuidle: enable time keeping
 
 Santosh Shilimkar (5):
   ARM: OMAP4: CPUidle: Avoid double idle driver registration
   ARM: OMAP: CPUidle: Unregister drivere on device registration failure
   ARM: OMAP4: CPUidle: Make C-state description field more precise
   ARM: OMAP4+: CPUidle: Deprecate use of 
 omap4_mpuss_read_prev_context_state()
   ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support
 
 Tony Lindgren (1):
   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of 
 git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.10/cleanup-pm
 
  arch/arm/mach-omap2/common.h  |  5 
  arch/arm/mach-omap2/cpuidle34xx.c | 11 +--
  arch/arm/mach-omap2/cpuidle44xx.c | 48 
 +--
  arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 -
  4 files changed, 35 insertions(+), 43 deletions(-)
 

--
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: [GIT PULL] mailbox driver framework for v3.10 merge window

2013-04-09 Thread Anna, Suman

 On Thursday 04 April 2013, Anna, Suman wrote:
  OMAP and ST-Ericsson platforms are both using mailbox to communicate with
 some coprocessors. This series creates a consolidated framework, living under
 drivers/mailbox.
  The changes mainly contain:
  - create a mailbox framework independent from OMAP h/w
  - creates dbx500 mailbox driver for ST-Ericsson platforms
  - move the omap mailbox out of plat-omap/mach-omapX  adapting to the new
 framework.
  - minor bug fixes in mailbox code
 
 Pulled into a new next/mailbox branch, to keep it separate from the existing
 subsystems.
 
 As a note for you: when you send a pull request, please make sure that you 
 use a
 tag that includes the changeset text (your description above), so I don't 
 have to
 copy it from the email. I noticed that you do have a tag mailbox-for-v3.10 
 in
 your tree, but the pull request was for the branch with the same contents.
 

Thanks Arnd. Yes, the tag is for the same SHA, and has the same comments as 
above. I understood the process only a bit later.

Regards
Suman
--
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/1] Documentation: dt: update TI GPMC ethernet binding properties

2013-04-09 Thread Jon Hunter


On 04/09/2013 07:11 AM, Javier Martinez Canillas wrote:
 The GPMC timing properties for device-tree have been updated
 by adding a -ns or -ps suffix to indicate the units of
 time the property represents. Therefore, update the timing
 property names for TI GPMC ethernet binding.
 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
 
 Jon, Benoit:
 
 Sorry that I didn't send this patch before but I just realized
 that the GPMC timing properties changed after
 
 commit 5330dc16 (ARM: OMAP2+: Add GPMC DT support for Ethernet child nodes)
 
 got queued.

Thanks, I missed this one too. Looks like I need to update the gpmc-nand
documentation as well :-(

 Tony,
 
 Is still possible to queue this patch on your omap-for-v3.10/gpmc branch
 or it is too late?

If it is I think that this could be queued as a fix. Tony?

 Thanks a lot and best regards,
 Javier
 
  Documentation/devicetree/bindings/net/gpmc-eth.txt |   56 
 ++--
  1 files changed, 28 insertions(+), 28 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/net/gpmc-eth.txt 
 b/Documentation/devicetree/bindings/net/gpmc-eth.txt
 index 24cb4e4..ace4a64 100644
 --- a/Documentation/devicetree/bindings/net/gpmc-eth.txt
 +++ b/Documentation/devicetree/bindings/net/gpmc-eth.txt
 @@ -26,16 +26,16 @@ Required properties:
  - bank-width:Address width of the device in bytes. GPMC 
 supports 8-bit
   and 16-bit devices and so must be either 1 or 2 bytes.
  - compatible:Compatible string property for the ethernet 
 child device.
 -- gpmc,cs-on:Chip-select assertion time
 -- gpmc,cs-rd-off:Chip-select de-assertion time for reads
 -- gpmc,cs-wr-off:Chip-select de-assertion time for writes
 -- gpmc,oe-on:Output-enable assertion time
 -- gpmc,oe-offOutput-enable de-assertion time
 -- gpmc,we-on:Write-enable assertion time
 -- gpmc,we-off:   Write-enable de-assertion time
 -- gpmc,access:   Start cycle to first data capture (read access)
 -- gpmc,rd-cycle: Total read cycle time
 -- gpmc,wr-cycle: Total write cycle time
 +- gpmc,cs-on-ns: Chip-select assertion time
 +- gpmc,cs-rd-off-ns: Chip-select de-assertion time for reads
 +- gpmc,cs-wr-off-ns: Chip-select de-assertion time for writes
 +- gpmc,oe-on-ns: Output-enable assertion time
 +- gpmc,oe-off-ns:Output-enable de-assertion time
 +- gpmc,we-on-ns: Write-enable assertion time
 +- gpmc,we-off-ns:Write-enable de-assertion time
 +- gpmc,access-ns:Start cycle to first data capture (read access)
 +- gpmc,rd-cycle-ns:  Total read cycle time
 +- gpmc,wr-cycle-ns:  Total write cycle time
  - reg:   Chip-select, base address (relative to 
 chip-select)
   and size of the memory mapped for the device.
   Note that base address will be typically 0 as this
 @@ -65,24 +65,24 @@ gpmc: gpmc@6e00 {
   bank-width = 2;
  
   gpmc,mux-add-data;
 - gpmc,cs-on = 0;
 - gpmc,cs-rd-off = 186;
 - gpmc,cs-wr-off = 186;
 - gpmc,adv-on = 12;
 - gpmc,adv-rd-off = 48;
 - gpmc,adv-wr-off = 48;
 - gpmc,oe-on = 54;
 - gpmc,oe-off = 168;
 - gpmc,we-on = 54;
 - gpmc,we-off = 168;
 - gpmc,rd-cycle = 186;
 - gpmc,wr-cycle = 186;
 - gpmc,access = 114;
 - gpmc,page-burst-access = 6;
 - gpmc,bus-turnaround = 12;
 - gpmc,cycle2cycle-delay = 18;
 - gpmc,wr-data-mux-bus = 90;
 - gpmc,wr-access = 186;
 + gpmc,cs-on-ns = 0;
 + gpmc,cs-rd-off-ns = 186;
 + gpmc,cs-wr-off-ns = 186;
 + gpmc,adv-on-ns = 12;
 + gpmc,adv-rd-off-ns = 48;
 + gpmc,adv-wr-off-ns = 48;
 + gpmc,oe-on-ns = 54;
 + gpmc,oe-off-ns = 168;
 + gpmc,we-on-ns = 54;
 + gpmc,we-off-ns = 168;
 + gpmc,rd-cycle-ns = 186;
 + gpmc,wr-cycle-ns = 186;
 + gpmc,access-ns = 114;
 + gpmc,page-burst-access-ns = 6;
 + gpmc,bus-turnaround-ns = 12;
 + gpmc,cycle2cycle-delay-ns = 18;
 + gpmc,wr-data-mux-bus-ns = 90;
 + gpmc,wr-access-ns = 186;
   gpmc,cycle2cycle-samecsen;
   gpmc,cycle2cycle-diffcsen;

Acked-by: Jon Hunter jon-hun...@ti.com

Cheers
Jon
--
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: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control

* Hiremath, Vaibhav hvaib...@ti.com [130409 01:12]:
  From: Tony Lindgren [mailto:t...@atomide.com]
  
  I suggest you just make this part into a standard DT only
  device driver. That way the command line parsing and clock
  enabling can happen the normal way.
  
 
 That’s good idea, as we are moving towards DT only boot support.
 Also, are you suggesting to have both command-line param and DT
 Property for this?
 
 
  Is there any reason why this could not be a loadable module?
  
 
 Because we want to keep it enabled before late_initcall. As part of 
 late_initcall
 Clock/hwmod framework will start disabling unused modules, which will impact 
 the
 Debugs as well. Consider the case where this debugss is loaded as a module, 
 the user
 Will loose the JTAG connection until the module is loaded; and once module is
 Loaded, he has to again re-connect to the debugss.

It will get run before late_initcall if compiled in. Sounds
like there are no issues also make it work as a loadable module
as needed.
 
 With only DT option the code will look like below, is this what you also have 
 in your mind -
 
 arch/arm/boot/dts/am33xx.dtsi:
 
   debugss: debugss@4b00 {
   compatible = ti,debugss;
   ti,hwmods = debugss;
   reg = 0x4b00 100;
   status = disabled;/* User need to enable it if he need 
 JTAG connectivity*/
   };


 arch/arm/mach-omap2/debugss.c:
 
   static int __init _omap2_debugss_enable(void)
   {
   struct device_node *np;
   
   np = of_find_matching_node(oh_name);
   if (!node || ! of_device_is_available()) {
   pr_err(debugss device is not found\n);
   return -ENODEV;
   }
   ...
   hwmod lookup./setup/enable along with optional clock enable.
   ...
 
   }
   device_initcall(_omap2_debugss_enable);

It should be all standard device driver stuff. I'd make it just
regular module_platform_driver and only initialize it earlier if
compiled in.

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

Re: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

Arnd Bergmann a...@arndb.de writes:

 On Tuesday 09 April 2013, Tony Lindgren wrote:
 The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9:
 
   Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v3.10/cleanup-pm-signed
 
 for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
 
   Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
 into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
 
 
 
 PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
 
 OMAP3/4 CPUidle cleanups for v3.10

 Adding Daniel and Rafael to Cc.

 Is this series coordinated with the other cpuidle changes? Please tell me if 
 this
 is good to go into arm-soc.

Hmm, looks like it's not ready.  There are some minor conflicts with
what Rafael has queued up from Daniel.

I will work this out with Daniel to figure out how we should proceed.

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: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

* Thierry Reding thierry.red...@avionic-design.de [130409 01:00]:
 On Mon, Apr 08, 2013 at 03:16:57PM -0700, Tony Lindgren wrote:
  * Thierry Reding thierry.red...@avionic-design.de [130408 15:01]:
   On Mon, Apr 08, 2013 at 02:46:24PM -0700, Tony Lindgren wrote:
* Andrew Chew ac...@nvidia.com [130313 15:37]:
 The pwm-backlight driver now takes a mandatory regulator that is 
 gotten
 during driver probe.  Initialize a dummy regulator to satisfy this
 requirement.
 
 Signed-off-by: Andrew Chew ac...@nvidia.com
 ---
 Changed the device name of the backlight regulator supply to 
 pwm-backlight,
 per Peter's comment.
 
 Changed the name of the regulator to backlight-enable, per Thierry's
 suggestion.

Thanks applying into omap-for-v3.10/board. Note that I'm not taking the
second one, that should be resent to the related driver maintainers.
You can get that list by running scripts/get_maintainer.pl against it.
   
   The plan was to take these all through one tree, preferably the PWM tree
   because it's all PWM related and the pwm-backlight change will go
   through that tree as well. Technically these individual patches can be
   applied as is and aren't harmful, but keeping track of the dependencies
   might be difficult if they go in via separate trees.
  
  Registering the regulator alone should not do anything. Also the driver
  should do the right thing if the regulator is not yet registered.
  
  Can you please check your driver patch so the driver won't do anything
  if the regulator is not (yet) registered and repost it alone as I've
  already applied the board-*.c change.
 
 That's not the way that the regulator subsystem works, unfortunately.
 There's no way you can distinguish between the case where a regulator
 just hasn't been registered yet, or whether it's missing. That's the
 whole reason why we need to add the dummy regulators in the first
 place.

But then the regulator is not found and the driver should just exit,
or do nothing. If this is an optional regulator, then that should be
indicated in some platform data flags?
 
  The reason why we want to do queue these patches separately is to cut
  away the dependency between drivers and the core arch/arm changes. 
  Otherwise we'll end up with pointless merge conflicts as we've seen
  earlier several times with the USB patches for example.
 
 We could possibly postpone merging the pwm-backlight changes until all
 other patches have been merged. If you have this in you for-3.10 branch
 I guess it will go into linux-next when the 3.9 merge window closes? If
 so I could possibly base my for-3.10 branch on your branch if you can
 provide a stable one that you can guarantee not to rebase. There are
 other alternatives too, but certainly the easiest would've been to take
 all patches through the PWM tree. The potential for merge conflicts
 should be rather minimal.

The driver parts really must be done in independently from any platform
data or .dts changes. The only common part needed should be changes
to include/linux/platform_data/*.h files.

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

Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

* Roger Quadros rog...@ti.com [130409 03:00]:
 On 04/05/2013 06:58 PM, Tony Lindgren wrote:
  
  Well your approach is fine as a first step moving all the clock
  code, but it needs to be a real driver under drivers/clock/omap.
  And the DT binding needs to stay the same for the driver(s) in the
  long term as we start moving clocks to DT + /lib/firmware.
 
 The code needs to be there were the clock structs are defined.
 Currently they are in arch/arm/mach-omap2/cclock44xx_data.c for OMAP4.

But if you do just a passthrough driver then that should not
be needed. 
 
  If this all is too late for v3.10, I suggest you just set up the
  right clock alias for panda with machine_is_compatible flag in
  board-generic.c so we get EHCI working with DT for v3.10. Then
  it's easy to to deal with it properly for v3.11.
 
 OK, let's do it this way for Panda for 3.10.

Yes otherwise we'll be delaying omap4 DT conversion again. 
 
  How can that driver do clk_get() from cclock44xx_data.c?
  from where does it get the clk_id to pass into clk_get()?
  
  Can't you just use the clock name there to get it?
 
 In device tree we don't pass around clock names. You can either get
 a phandle or an index to the clock.
 
 e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt

Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.

  As long as the binding stays the same in the long run too, this
  clock remapping approach is just fine as a starting point. And
  the driver needs to go to drivers/clock/omap. But in the long run
  we just want to get the huge amounts static data out of the kernel
  for clocks and hwmod data to fix things for good.
 
 In that case we need to identify what clocks need to be supported.
 If it is all (~200) of them, is this method good enough?

We should support any clock we need for booting the device with
just DT bindings to get timers, console and rootfs working. Then
we just need to load the complete set from /lib/firmware.

It seems that the binding can be the same for all the clocks.
For now, we can just use the standard clock binding and do the
remapping in the clock driver.

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

Re: [PATCH v3 2/4] ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5

* Santosh Shilimkar santosh.shilim...@ti.com [130408 23:16]:
  
 As I said, the IP has been there from OMAP2XX days. Here the case that
 IP version is very similar between OMAP4, OMAP5. DRA(next SOC) and its
 derivatives. Hence can share most of the code. I thought this was good
 enough reason considering at least 4 family of SOC's can make use
 of the code.

Well at least that might be enough of a reasoning to rename it as
it is somewhat futureproof.
 
 It has nothing to do with SMP etc specifically and rather the similarity
 between the PM infrastructure on the mentioned SOCs. 

 Let me know if you can suggested better name than what I chose ?

Not really except something like pm-iprevXXX.[chS] where the rev is
the first revision that it works with?

But then again if it's touching registers all over the place directly,
that naming does not make much sense either :)

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

Re: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

* Kevin Hilman khil...@linaro.org [130409 09:43]:
 Arnd Bergmann a...@arndb.de writes:
 
  On Tuesday 09 April 2013, Tony Lindgren wrote:
  The following changes since commit 
  07961ac7c0ee8b546658717034fe692fd12eefa9:
  
Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
  
  are available in the git repository at:
  
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
  tags/omap-for-v3.10/cleanup-pm-signed
  
  for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
  
Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
  into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
  
  
  
  PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
  
  OMAP3/4 CPUidle cleanups for v3.10
 
  Adding Daniel and Rafael to Cc.
 
  Is this series coordinated with the other cpuidle changes? Please tell me 
  if this
  is good to go into arm-soc.
 
 Hmm, looks like it's not ready.  There are some minor conflicts with
 what Rafael has queued up from Daniel.
 
 I will work this out with Daniel to figure out how we should proceed.

OK it seems that this branch can also be queued by Rafael after
updating it if there's a dependency. So far it's not conflicting
with anything else we have queued up for arm soc tree.

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

Re: [PATCH 1/1] Documentation: dt: update TI GPMC ethernet binding properties

* Jon Hunter jon-hun...@ti.com [130409 09:31]:
 
 On 04/09/2013 07:11 AM, Javier Martinez Canillas wrote:
  The GPMC timing properties for device-tree have been updated
  by adding a -ns or -ps suffix to indicate the units of
  time the property represents. Therefore, update the timing
  property names for TI GPMC ethernet binding.
  
  Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
  ---
  
  Jon, Benoit:
  
  Sorry that I didn't send this patch before but I just realized
  that the GPMC timing properties changed after
  
  commit 5330dc16 (ARM: OMAP2+: Add GPMC DT support for Ethernet child 
  nodes)
  
  got queued.
 
 Thanks, I missed this one too. Looks like I need to update the gpmc-nand
 documentation as well :-(
 
  Tony,
  
  Is still possible to queue this patch on your omap-for-v3.10/gpmc branch
  or it is too late?
 
 If it is I think that this could be queued as a fix. Tony?

Yes let's plan on making this a fix. Then it can be merged during
the merge window or right after it.

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

[PATCH] Documentation: dt: update properties in TI GPMC NAND example

2013-04-09 Thread Jon Hunter

The GPMC timing properties for device-tree have been updated
by adding a -ns or -ps suffix to indicate the units of
time the property represents. Therefore, update the timing
property names for TI GPMC NAND example.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 .../devicetree/bindings/mtd/gpmc-nand.txt  |   28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index e7f8d7e..6a983c1 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -56,20 +56,20 @@ Example for an AM33xx board:
nand-bus-width = 16;
ti,nand-ecc-opt = bch8;
 
-   gpmc,sync-clk = 0;
-   gpmc,cs-on = 0;
-   gpmc,cs-rd-off = 44;
-   gpmc,cs-wr-off = 44;
-   gpmc,adv-on = 6;
-   gpmc,adv-rd-off = 34;
-   gpmc,adv-wr-off = 44;
-   gpmc,we-off = 40;
-   gpmc,oe-off = 54;
-   gpmc,access = 64;
-   gpmc,rd-cycle = 82;
-   gpmc,wr-cycle = 82;
-   gpmc,wr-access = 40;
-   gpmc,wr-data-mux-bus = 0;
+   gpmc,sync-clk-ps = 0;
+   gpmc,cs-on-ns = 0;
+   gpmc,cs-rd-off-ns = 44;
+   gpmc,cs-wr-off-ns = 44;
+   gpmc,adv-on-ns = 6;
+   gpmc,adv-rd-off-ns = 34;
+   gpmc,adv-wr-off-ns = 44;
+   gpmc,we-off-ns = 40;
+   gpmc,oe-off-ns = 54;
+   gpmc,access-ns = 64;
+   gpmc,rd-cycle-ns = 82;
+   gpmc,wr-cycle-ns = 82;
+   gpmc,wr-access-ns = 40;
+   gpmc,wr-data-mux-bus-ns = 0;
 
#address-cells = 1;
#size-cells = 1;
-- 
1.7.10.4

--
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: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@linaro.org [130409 09:43]:
 Arnd Bergmann a...@arndb.de writes:
 
  On Tuesday 09 April 2013, Tony Lindgren wrote:
  The following changes since commit 
  07961ac7c0ee8b546658717034fe692fd12eefa9:
  
Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)
  
  are available in the git repository at:
  
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
  tags/omap-for-v3.10/cleanup-pm-signed
  
  for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:
  
Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
  into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)
  
  
  
  PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:
  
  OMAP3/4 CPUidle cleanups for v3.10
 
  Adding Daniel and Rafael to Cc.
 
  Is this series coordinated with the other cpuidle changes? Please tell me 
  if this
  is good to go into arm-soc.
 
 Hmm, looks like it's not ready.  There are some minor conflicts with
 what Rafael has queued up from Daniel.
 
 I will work this out with Daniel to figure out how we should proceed.

 OK it seems that this branch can also be queued by Rafael after
 updating it if there's a dependency. So far it's not conflicting
 with anything else we have queued up for arm soc tree.

Right, I just did a test rebase onto the relevant commit in Rafael
linux-next branch, and fixed up all the conflicts[1].

If Rafael agrees, it's fine with me if it goes via him.

Rafael, the signed tag for the updated branch is below[1], based on the
commit in your linux-next branch where you merged the rest of the
CPUidle changes.  Let me know if you want a different base commit, or an
official pull request.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
tags/omap-pm-v3.10/cleanup/cpuidle-v2
--
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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

* Tony Lindgren t...@atomide.com [130409 09:54]:
 * Roger Quadros rog...@ti.com [130409 03:00]:
  On 04/05/2013 06:58 PM, Tony Lindgren wrote:
   
   Can't you just use the clock name there to get it?
  
  In device tree we don't pass around clock names. You can either get
  a phandle or an index to the clock.
  
  e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
 
 Yes I understand that. But the driver/clock/omap driver can just
 remap the DT device initially so the board specific clock is
 found from the clock alias table. Basically initially a passthrough
 driver that can be enhanced to parse DT clock bindings and load
 data from /lib/firmware.

Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.

As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.

Then other features can be added later on like to allocate a
clock entirely based on the binding etc.

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

RE: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and updates for 3.10

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Tony Lindgren
 Sent: Friday, April 05, 2013 10:41 PM
 To: Shilimkar, Santosh
 Cc: Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; Kristo, Tero; Menon, Nishanth; Nayak,
 Rajendra; Valentin, Eduardo; Anna, Suman; Bedia, Vaibhav; Hiremath,
 Vaibhav
 Subject: Re: [GIT PULL] ARM: OMAP5: hwmod, prm/cm data files and
 updates for 3.10

 * Santosh Shilimkar santosh.shilim...@ti.com [130405 09:52]:
  On Thursday 04 April 2013 10:27 PM, Santosh Shilimkar wrote:
   On Thursday 04 April 2013 10:22 PM, Tony Lindgren wrote:
   * Santosh Shilimkar santosh.shilim...@ti.com [130404 04:15]:
  [..]

   Can't we already trim the am33xx hwmod data after your patches for
   v3.10 as am33xx is already DT only? Unfortunately we cannot create
   negative diffstat in other ways for v3.10 merge window as we
 cannot
   make omap4 DT only just quite yet.

   Yes we can and I can take a stab it tomorrow. The only thing is I
   might need some support for testing but thats manageable. Will
   take a stab at it tomorrow and if everything goes well, post a
   patch for smae.

  Patch for the AM33XX to trim is end of the email. Thanks to
  Sricharan and Pekon for patch and testing. Looping both
  Vaibhav's if they have any objection on the patch.

  Regards,
  Santosh

  From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
 2001
  From: Sricharan R r.sricha...@ti.com
  Date: Fri, 5 Apr 2013 20:39:12 +0530
  Subject: [PATCH] ARM: AM33XX: hwmod data: Clean up the data file

  - The IO resource information like dma request lines, irq number and
  ocp address space can be populated via dt blob. So such data can be
 stripped
  from SOC hwmod data file.

  - The devices like adc, mailbox, gpmc which are missing the device
  tree bindings, hwmod data is not added since AM33XX is DT only build.
  When such devices add the dt bindings, respective hwmod data can be
  added along with it.

  - The hwmod like firewall etc which are not useful are also dropped.

  This gets us around ~2000 loc of negative diff. Patch is boot tested
 on
  AM335X EVM.

 Great, that's a nice reduction :) Considering am33xx is DT only, it
 should be safe.. But can the am33xx guys please test and ack it?

I am reviewing the patch-diff and will give my comment as soon as possible.

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: [PATCHv3] driver: serial: prevent UART console idle on suspend while using no_console_suspend

2013-04-09 Thread Sourav Poddar


Hi Kevin,
On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:

Sourav Poddarsourav.pod...@ti.com  writes:


With dt boot, uart wakeup after suspend is non functional while using
no_console_suspend in the bootargs. With no_console_suspend used, we
should prevent the runtime suspend of the uart port which is getting used
as an console.

Cc: Santosh Shilimkarsantosh.shilim...@ti.com
Cc: Felipe Balbiba...@ti.com
Cc: Rajendra nayakrna...@ti.com
Tested on omap5430evm, omap4430sdp.

Signed-off-by: Sourav Poddarsourav.pod...@ti.com

Rather than make these special checks inside the driver's runtime PM
callbacks, you should just disable runtime PM (pm_runtime_disable())

Then, this should be broken into 2 patches.

1) serial core: add the '-is_console' flag.  (nit on naming: don't call
it port_is_console, since the struct is already a uart_port)

2) In the OMAP UART driver's -prepare callback, check the is_console flag
and pm_runtime_disable() accordingly  (then pm_runtime_enable() in
the drivers's -complete callback.

Kevin


I was working on your above suggestions, but realised there is not only 
console

uart which has the requirement of keeping the clocks enabled while going on
suspend.

If you see arch/arm/boot/dts/am33xx.dtsi, there is a ocmcram which has
no_idle_on_suspend property used.

ocmcram: ocmcram@4030 {
compatible = ti,am3352-ocmcram;
reg = 0x4030 0x1;
ti,hwmods = ocmcram;
ti,no_idle_on_suspend;
};
This property gets checked in omap_device file and correspondingly 
od-flags is set.


Based on your above inputs, the patches which I cooked up is inlined[1]. 
Though, the below
patches works fine for uart case. The patches will effect ocmcram case 
and I am inling them

just for discussion.

I am not sure, if there is any other cleaner way of getting around this 
no_idle_on_suspend flag

as they are getting used for ocmcram also. ?

Thanks,
Sourav

[1]:
From: Sourav Poddar sourav.pod...@ti.com
Date: Wed, 13 Mar 2013 20:32:36 +0530
Subject: [PATCH 1/2] arm: mach-omap2: remove 
OMAP_DEVICE_NO_IDLE_ON_SUSPEND check


Remove the OMAP_DEVICE_NO_IDLE_ON_SUSPEND check, since serial core and 
driver

takes care of the case when no_console_suspend is used in the bootargs and
you need to keep the clock enable for console even while suspend.

Tested on omap5430evm, omap4430sdp.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 arch/arm/mach-omap2/omap_device.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c

index 381be7a..d6dce8f 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -620,11 +620,8 @@ static int _od_suspend_noirq(struct device *dev)
ret = pm_generic_suspend_noirq(dev);

if (!ret  !pm_runtime_status_suspended(dev)) {
-   if (pm_generic_runtime_suspend(dev) == 0) {
-   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
-   omap_device_idle(pdev);
+   if (pm_generic_runtime_suspend(dev) == 0)
od-flags |= OMAP_DEVICE_SUSPENDED;
-   }
}

return ret;
@@ -638,8 +635,6 @@ static int _od_resume_noirq(struct device *dev)
if ((od-flags  OMAP_DEVICE_SUSPENDED) 
!pm_runtime_status_suspended(dev)) {
od-flags = ~OMAP_DEVICE_SUSPENDED;
-   if (!(od-flags  OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
-   omap_device_enable(pdev);
pm_generic_runtime_resume(dev);
}

--

From: Sourav Poddar sourav.pod...@ti.com
Date: Wed, 13 Mar 2013 20:32:36 +0530
Subject: [PATCH 2/2] driver: serial: omap: add prepare/complete callback 
for no_console_suspend case


This patch adapt the serial core/driver to take care of the case when 
no_console_suspend
is used in the bootargs. This patch will remove dependency to set 
od-flags to
OMAP_DEVICE_NO_IDLE_ON_SUSPEND in serial.c(non dt case) and 
omap_device.c(dt case).


Prepare and complete callbacks will ensure that clocks remain active for 
the console

uart when no_console_suspend is used in the bootargs.

Tested on omap5430evm, omap4430sdp.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
 drivers/tty/serial/omap-serial.c |   20 
 drivers/tty/serial/serial_core.c |3 +++
 include/linux/serial_core.h  |1 +
 3 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c 
b/drivers/tty/serial/omap-serial.c

index 08332f3..b726b2b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1278,6 +1278,24 @@ static struct uart_driver serial_omap_reg = {
 };

 #ifdef CONFIG_PM_SLEEP
+static int serial_omap_prepare(struct device *dev)
+{
+   struct uart_omap_port *up = dev_get_drvdata(dev);
+
+

Re: [PATCHv3] driver: serial: prevent UART console idle on suspend while using no_console_suspend

Sourav Poddar sourav.pod...@ti.com writes:

 Hi Kevin,
 On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
 Sourav Poddarsourav.pod...@ti.com  writes:

 With dt boot, uart wakeup after suspend is non functional while using
 no_console_suspend in the bootargs. With no_console_suspend used, we
 should prevent the runtime suspend of the uart port which is getting used
 as an console.

 Cc: Santosh Shilimkarsantosh.shilim...@ti.com
 Cc: Felipe Balbiba...@ti.com
 Cc: Rajendra nayakrna...@ti.com
 Tested on omap5430evm, omap4430sdp.

 Signed-off-by: Sourav Poddarsourav.pod...@ti.com
 Rather than make these special checks inside the driver's runtime PM
 callbacks, you should just disable runtime PM (pm_runtime_disable())

 Then, this should be broken into 2 patches.

 1) serial core: add the '-is_console' flag.  (nit on naming: don't call
 it port_is_console, since the struct is already a uart_port)

 2) In the OMAP UART driver's -prepare callback, check the is_console flag
 and pm_runtime_disable() accordingly  (then pm_runtime_enable() in
 the drivers's -complete callback.

 Kevin

 I was working on your above suggestions, but realised there is not
 only console
 uart which has the requirement of keeping the clocks enabled while going on
 suspend.

 If you see arch/arm/boot/dts/am33xx.dtsi, there is a ocmcram which has
 no_idle_on_suspend property used.

Can you please ask the AM33xx folks how (and why) this is being used?

I don't see/find a driver for this device in mainline, so without a
driver this flag will not be used.

 ocmcram: ocmcram@4030 {
 compatible = ti,am3352-ocmcram;
 reg = 0x4030 0x1;
 ti,hwmods = ocmcram;
 ti,no_idle_on_suspend;
 };
 This property gets checked in omap_device file and correspondingly
 od-flags is set.

 Based on your above inputs, the patches which I cooked up is
 inlined[1]. Though, the below
 patches works fine for uart case. The patches will effect ocmcram case
 and I am inling them
 just for discussion.

Could you also have a look at Russell's suggestion for getting rid of
the 'is_console' flag.

Thanks,

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: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

2013-04-09 Thread Thierry Reding

On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote:
[...]
 But then the regulator is not found and the driver should just exit,
 or do nothing. If this is an optional regulator, then that should be
 indicated in some platform data flags?

Yes, if the regulator isn't found then the driver fails. However the
goal was to maintain bisectability. If we apply them in the wrong order
we can't guarantee that because pwm-backlight will fail to work between
both patches.

 The driver parts really must be done in independently from any platform
 data or .dts changes. The only common part needed should be changes
 to include/linux/platform_data/*.h files.

We don't even need to touch platform data because the regulators are
looked up via a global table. And the changes are all done independently
but as I mentioned above, bisectability isn't maintained, so the
preferred patch order is the one in which pwm-backlight keeps working at
each point in the commit history.

Thierry


pgpObfBiWBDf0.pgp
Description: PGP signature

[RFC PATCH v2 0/4] USB: OMAP: Tahvo USB support for 770

Hi,

These patches add support for Tahvo USB transceiver and allow using both
host and peripheral modes on Nokia 770.

Patches are currently based on top of Felipe's next branch
(git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git,
9b192de60b5a584ee4ed967fb6758773c75e4643). To make them work on 770,
some additional OMAP1 fixes are also needed which are already present
in 3.9-rc6 or queued for 3.10.

Test cases were roughly following:

- CONFIG_TAHVO_USB_HOST_BY_DEFAULT
- ohci-hcd, omap_udc, g_ether loaded as modules during boot
- check host mode functionality after boot with USB keyboard
- switch to peripheral mode and check functionality with ssh
- switch back to host mode

- !CONFIG_TAHVO_USB_HOST_BY_DEFAULT
- ohci-hcd, omap_udc, g_ether loaded as modules during boot
- check peripheral mode after boot with ssh
- switch to host mode and check with USB keyboard
- switch back to peripheral mode

- other
- check USB cable on/off detection (Tahvo vbus interrupt)

Changes since the first RFC
(http://marc.info/?l=linux-omapm=136266725827698w=2):

- retu-mfd
- use i2c address to detect retu vs. tahvo
- phy-omap-otg
- don't mess with isp1301_omap.c
- move to drivers/usb/phy, rename omap-otg - phy-omap-otg
- phy-tahvo
- drop illegal includes
- move to drivers/usb/phy, rename tahvo-usb - phy-tahvo
- serialize vbus interrupt handling
- delete dummy/unimplemented functions
- drop peripheral/host only config
- don't use OTG interrupt, not needed
- don't write to OTG_SYSCON_1/2, this is handled by board code
- move OTG CTRL handling to omap-otg

Please review and comment. Thanks,

A.

Aaro Koskinen (4):
  retu-mfd: support also Tahvo
  ARM: OMAP1: nokia770: enable Tahvo
  USB: OMAP: add omap-otg
  USB: OMAP: Tahvo USB transceiver driver

 arch/arm/mach-omap1/board-nokia770.c |   10 +
 drivers/mfd/Kconfig  |6 +-
 drivers/mfd/retu-mfd.c   |   85 ++-
 drivers/usb/phy/Kconfig  |   24 ++
 drivers/usb/phy/Makefile |2 +
 drivers/usb/phy/phy-omap-otg.c   |  126 ++
 drivers/usb/phy/phy-tahvo.c  |  429 ++
 include/linux/mfd/retu.h |8 +-
 include/linux/usb/omap-otg.h |   19 ++
 9 files changed, 695 insertions(+), 14 deletions(-)
 create mode 100644 drivers/usb/phy/phy-omap-otg.c
 create mode 100644 drivers/usb/phy/phy-tahvo.c
 create mode 100644 include/linux/usb/omap-otg.h

-- 
1.7.10.4

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

[RFC PATCH v2 2/4] ARM: OMAP1: nokia770: enable Tahvo

Add platform data for Tahvo.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/mach-omap1/board-nokia770.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap1/board-nokia770.c 
b/arch/arm/mach-omap1/board-nokia770.c
index 62a15e2..91449c5 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -234,16 +234,26 @@ static struct i2c_board_info nokia770_i2c_board_info_2[] 
__initdata = {
{
I2C_BOARD_INFO(retu-mfd, 0x01),
},
+   {
+   I2C_BOARD_INFO(tahvo-mfd, 0x02),
+   },
 };
 
 static void __init nokia770_cbus_init(void)
 {
const int retu_irq_gpio = 62;
+   const int tahvo_irq_gpio = 40;
 
if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
return;
+   if (gpio_request_one(tahvo_irq_gpio, GPIOF_IN, Tahvo IRQ)) {
+   gpio_free(retu_irq_gpio);
+   return;
+   }
irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+   irq_set_irq_type(gpio_to_irq(tahvo_irq_gpio), IRQ_TYPE_EDGE_RISING);
nokia770_i2c_board_info_2[0].irq = gpio_to_irq(retu_irq_gpio);
+   nokia770_i2c_board_info_2[1].irq = gpio_to_irq(tahvo_irq_gpio);
i2c_register_board_info(2, nokia770_i2c_board_info_2,
ARRAY_SIZE(nokia770_i2c_board_info_2));
platform_device_register(nokia770_cbus_device);
-- 
1.7.10.4

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

[RFC PATCH v2 3/4] USB: OMAP: add omap-otg

Transceivers need to manage OTG controller state on OMAP1 to enable
switching between peripheral and host modes. Provide a driver for that.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/usb/phy/Kconfig|   10 
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/phy-omap-otg.c |  126 
 include/linux/usb/omap-otg.h   |   19 ++
 4 files changed, 156 insertions(+)
 create mode 100644 drivers/usb/phy/phy-omap-otg.c
 create mode 100644 include/linux/usb/omap-otg.h

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..8c051c2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -135,6 +135,16 @@ config USB_GPIO_VBUS
  optionally control of a D+ pullup GPIO as well as a VBUS
  current limit regulator.
 
+config OMAP_OTG
+   tristate OMAP USB OTG controller driver
+   depends on ARCH_OMAP_OTG
+   help
+ Enable this to support some transceivers on OMAP1 platforms. OTG
+ controller is needed to switch between host and peripheral modes.
+
+ This driver can also be built as a module. If so, the module
+ will be called omap-otg.
+
 config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..7e67e96 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= phy-isp1301.omap.o
 obj-$(CONFIG_MV_U3D_PHY)   += phy-mv-u3d-usb.o
 obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
+obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
 obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
 obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
 obj-$(CONFIG_SAMSUNG_USBPHY)   += phy-samsung-usb.o
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
new file mode 100644
index 000..cb00ffe
--- /dev/null
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP OTG controller driver
+ *
+ * Based on code from tahvo-usb.c and isp1301_omap.c drivers.
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * 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.
+ *
+ * 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.
+ */
+
+#include linux/io.h
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+struct otg_device {
+   void __iomem*base;
+   struct mutexserialize;
+};
+static struct otg_device *otg_dev;
+
+#define OMAP_OTG_CTRL  (otg_dev-base + 0x0c)
+#define OMAP_OTG_ASESSVLD  (1  20)
+#define OMAP_OTG_BSESSEND  (1  19)
+#define OMAP_OTG_BSESSVLD  (1  18)
+#define OMAP_OTG_VBUSVLD   (1  17)
+#define OMAP_OTG_ID(1  16)
+#define OMAP_OTG_XCEIV_OUTPUTS \
+   (OMAP_OTG_ASESSVLD | OMAP_OTG_BSESSEND | OMAP_OTG_BSESSVLD | \
+OMAP_OTG_VBUSVLD  | OMAP_OTG_ID)
+
+static void omap_otg_ctrl(u32 outputs)
+{
+   u32 l;
+
+   l = readl(OMAP_OTG_CTRL);
+   l = ~OMAP_OTG_XCEIV_OUTPUTS;
+   l |= outputs;
+   writel(l, OMAP_OTG_CTRL);
+}
+
+void omap_otg_set_mode(enum omap_otg_mode mode)
+{
+   if (!otg_dev) {
+   WARN(1, %s: controller not present\n, __func__);
+   return;
+   }
+   mutex_lock(otg_dev-serialize);
+   switch (mode) {
+   case OMAP_OTG_MODE_DEVICE:
+   /*
+* Set B-session valid.
+*/
+   omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSVLD);
+   break;
+   case OMAP_OTG_MODE_HOST:
+   /*
+* Set A-session valid.
+*/
+   omap_otg_ctrl(OMAP_OTG_ASESSVLD);
+   break;
+   case OMAP_OTG_MODE_DISCONNECT:
+   /*
+* Set B-session end to indicate no VBUS.
+*/
+   omap_otg_ctrl(OMAP_OTG_ID | OMAP_OTG_BSESSEND);
+   break;
+   default:
+   WARN(1, %s: unknown mode: %d\n, __func__, mode);
+   }
+   mutex_unlock(otg_dev-serialize);
+}
+EXPORT_SYMBOL_GPL(omap_otg_set_mode);
+
+static int omap_otg_probe(struct platform_device *dev)
+{
+   struct otg_device *odev;
+   u32 rev;
+
+   if (otg_dev)
+

[RFC PATCH v2 4/4] USB: OMAP: Tahvo USB transceiver driver

Add Tahvo USB transceiver driver.

Based on old code from linux-omap tree. The original driver was written
by Juha Yrjölä, Tony Lindgren, and Timo Teräs.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 drivers/usb/phy/Kconfig |   14 ++
 drivers/usb/phy/Makefile|1 +
 drivers/usb/phy/phy-tahvo.c |  429 +++
 3 files changed, 444 insertions(+)
 create mode 100644 drivers/usb/phy/phy-tahvo.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 8c051c2..85b2e2c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -145,6 +145,20 @@ config OMAP_OTG
  This driver can also be built as a module. If so, the module
  will be called omap-otg.
 
+config TAHVO_USB
+   tristate Tahvo USB transceiver driver
+   depends on MFD_RETU  OMAP_OTG
+   help
+ Enable this to support USB transceiver on Tahvo. This is used
+ at least on Nokia 770.
+
+config TAHVO_USB_HOST_BY_DEFAULT
+   depends on TAHVO_USB
+   boolean Device in USB host mode by default
+   help
+ Say Y here, if you want the device to enter USB host mode
+ by default on bootup.
+
 config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 7e67e96..c6079ff 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -13,6 +13,7 @@ phy-fsl-usb2-objs := phy-fsl-usb.o 
phy-fsm-usb.o
 obj-$(CONFIG_FSL_USB2_OTG) += phy-fsl-usb2.o
 obj-$(CONFIG_ISP1301_OMAP) += phy-isp1301.omap.o
 obj-$(CONFIG_MV_U3D_PHY)   += phy-mv-u3d-usb.o
+obj-$(CONFIG_TAHVO_USB)+= phy-tahvo.o
 obj-$(CONFIG_NOP_USB_XCEIV)+= phy-nop.o
 obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
 obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
new file mode 100644
index 000..51bc40e
--- /dev/null
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -0,0 +1,429 @@
+/*
+ * Tahvo USB transceiver driver
+ *
+ * Copyright (C) 2005-2006 Nokia Corporation
+ *
+ * Parts copied from isp1301_omap.c.
+ * Copyright (C) 2004 Texas Instruments
+ * Copyright (C) 2004 David Brownell
+ *
+ * Original driver written by Juha Yrjölä, Tony Lindgren and Timo Teräs.
+ * Modified for Retu/Tahvo MFD by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * 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.
+ */
+
+#include linux/io.h
+#include linux/clk.h
+#include linux/usb.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb/otg.h
+#include linux/mfd/retu.h
+#include linux/usb/gadget.h
+#include linux/usb/omap-otg.h
+#include linux/platform_device.h
+
+#define DRIVER_NAME tahvo-usb
+
+#define TAHVO_REG_IDSR 0x02
+#define TAHVO_REG_USBR 0x06
+
+#define USBR_SLAVE_CONTROL (1  8)
+#define USBR_VPPVIO_SW (1  7)
+#define USBR_SPEED (1  6)
+#define USBR_REGOUT(1  5)
+#define USBR_MASTER_SW2(1  4)
+#define USBR_MASTER_SW1(1  3)
+#define USBR_SLAVE_SW  (1  2)
+#define USBR_NSUSPEND  (1  1)
+#define USBR_SEMODE(1  0)
+
+#define TAHVO_MODE_HOST0
+#define TAHVO_MODE_PERIPHERAL  1
+
+struct tahvo_usb {
+   struct platform_device  *pt_dev;
+   struct usb_phy  phy;
+   int vbus_state;
+   struct mutexserialize;
+   struct clk  *ick;
+   int irq;
+   int tahvo_mode;
+};
+
+static ssize_t vbus_state_show(struct device *device,
+  struct device_attribute *attr, char *buf)
+{
+   struct tahvo_usb *tu = dev_get_drvdata(device);
+   return sprintf(buf, %d\n, tu-vbus_state);
+}
+static DEVICE_ATTR(vbus_state, 0444, vbus_state_show, NULL);
+
+static void check_vbus_state(struct tahvo_usb *tu)
+{
+   struct retu_dev *rdev = dev_get_drvdata(tu-pt_dev-dev.parent);
+   int reg, prev_state;
+
+   reg = retu_read(rdev, TAHVO_REG_IDSR);
+   if (reg  TAHVO_STAT_VBUS) {
+   switch (tu-phy.state) {
+   case OTG_STATE_B_IDLE:
+   /* Enable the gadget driver */
+   if (tu-phy.otg-gadget)
+   usb_gadget_vbus_connect(tu-phy.otg-gadget);
+   omap_otg_set_mode(OMAP_OTG_MODE_DEVICE);
+   tu-phy.state = OTG_STATE_B_PERIPHERAL;
+

[RFC PATCH v2 1/4] retu-mfd: support also Tahvo

Tahvo is a multi-function device on Nokia 770, implementing USB
transceiver and charge/battery control.

It's so close to Retu that a single driver can support both.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
Cc: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/Kconfig  |6 ++--
 drivers/mfd/retu-mfd.c   |   85 --
 include/linux/mfd/retu.h |8 -
 3 files changed, 85 insertions(+), 14 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index c346941..8628955 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1102,13 +1102,13 @@ config MFD_VIPERBOARD
  The drivers do not support all features the board exposes.
 
 config MFD_RETU
-   tristate Support for Retu multi-function device
+   tristate Support for Retu and Tahvo multi-function devices
select MFD_CORE
depends on I2C  GENERIC_HARDIRQS
select REGMAP_IRQ
help
- Retu is a multi-function device found on Nokia Internet Tablets
- (770, N800 and N810).
+ Retu and Tahvo are multi-function devices found on Nokia
+ Internet Tablets (770, N800 and N810).
 
 config MFD_AS3711
bool Support for AS3711
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
index 3ba0486..a183098 100644
--- a/drivers/mfd/retu-mfd.c
+++ b/drivers/mfd/retu-mfd.c
@@ -1,5 +1,5 @@
 /*
- * Retu MFD driver
+ * Retu/Tahvo MFD driver
  *
  * Copyright (C) 2004, 2005 Nokia Corporation
  *
@@ -33,7 +33,8 @@
 #define RETU_REG_ASICR 0x00/* ASIC ID and revision */
 #define RETU_REG_ASICR_VILMA   (1  7)/* Bit indicating Vilma */
 #define RETU_REG_IDR   0x01/* Interrupt ID */
-#define RETU_REG_IMR   0x02/* Interrupt mask */
+#define RETU_REG_IMR   0x02/* Interrupt mask (Retu) */
+#define TAHVO_REG_IMR  0x03/* Interrupt mask (Tahvo) */
 
 /* Interrupt sources */
 #define RETU_INT_PWR   0   /* Power button */
@@ -84,6 +85,62 @@ static struct regmap_irq_chip retu_irq_chip = {
 /* Retu device registered for the power off. */
 static struct retu_dev *retu_pm_power_off;
 
+static struct resource tahvo_usb_res[] = {
+   {
+   .name   = tahvo-usb,
+   .start  = TAHVO_INT_VBUS,
+   .end= TAHVO_INT_VBUS,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct mfd_cell tahvo_devs[] = {
+   {
+   .name   = tahvo-usb,
+   .resources  = tahvo_usb_res,
+   .num_resources  = ARRAY_SIZE(tahvo_usb_res),
+   },
+};
+
+static struct regmap_irq tahvo_irqs[] = {
+   [TAHVO_INT_VBUS] = {
+   .mask = 1  TAHVO_INT_VBUS,
+   }
+};
+
+static struct regmap_irq_chip tahvo_irq_chip = {
+   .name   = TAHVO,
+   .irqs   = tahvo_irqs,
+   .num_irqs   = ARRAY_SIZE(tahvo_irqs),
+   .num_regs   = 1,
+   .status_base= RETU_REG_IDR,
+   .mask_base  = TAHVO_REG_IMR,
+   .ack_base   = RETU_REG_IDR,
+};
+
+static const struct retu_data {
+   char*chip_name;
+   char*companion_name;
+   struct regmap_irq_chip  *irq_chip;
+   struct mfd_cell *children;
+   int nchildren;
+} retu_data[] = {
+   [0] = {
+   .chip_name  = Retu,
+   .companion_name = Vilma,
+   .irq_chip   = retu_irq_chip,
+   .children   = retu_devs,
+   .nchildren  = ARRAY_SIZE(retu_devs),
+   },
+   [1] = {
+   .chip_name  = Tahvo,
+   .companion_name = Betty,
+   .irq_chip   = tahvo_irq_chip,
+   .children   = tahvo_devs,
+   .nchildren  = ARRAY_SIZE(tahvo_devs),
+   }
+};
+
 int retu_read(struct retu_dev *rdev, u8 reg)
 {
int ret;
@@ -173,9 +230,14 @@ static struct regmap_config retu_config = {
 
 static int retu_probe(struct i2c_client *i2c, const struct i2c_device_id *id)
 {
+   struct retu_data const *rdat;
struct retu_dev *rdev;
int ret;
 
+   if (i2c-addr  ARRAY_SIZE(retu_data))
+   return -ENODEV;
+   rdat = retu_data[i2c-addr - 1];
+
rdev = devm_kzalloc(i2c-dev, sizeof(*rdev), GFP_KERNEL);
if (rdev == NULL)
return -ENOMEM;
@@ -190,25 +252,27 @@ static int retu_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
 
ret = retu_read(rdev, RETU_REG_ASICR);
if (ret  0) {
-   dev_err(rdev-dev, could not read Retu revision: %d\n, ret);
+   dev_err(rdev-dev, could not read %s revision: %d\n,
+   rdat-chip_name, ret);
return ret;
}
 
-   dev_info(rdev-dev, Retu%s v%d.%d found\n,
-(ret  RETU_REG_ASICR_VILMA) ?   Vilma : ,
+

Re: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

* Thierry Reding thierry.red...@avionic-design.de [130409 12:45]:
 On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote:
 [...]
  But then the regulator is not found and the driver should just exit,
  or do nothing. If this is an optional regulator, then that should be
  indicated in some platform data flags?
 
 Yes, if the regulator isn't found then the driver fails. However the
 goal was to maintain bisectability. If we apply them in the wrong order
 we can't guarantee that because pwm-backlight will fail to work between
 both patches.

But it's fixing something that's not working anyways for board-4430sdp.c,
It seems so as these patches just add new features?
 
  The driver parts really must be done in independently from any platform
  data or .dts changes. The only common part needed should be changes
  to include/linux/platform_data/*.h files.
 
 We don't even need to touch platform data because the regulators are
 looked up via a global table. And the changes are all done independently
 but as I mentioned above, bisectability isn't maintained, so the
 preferred patch order is the one in which pwm-backlight keeps working at
 each point in the commit history.

Bisectability is a good point. But in the 4430sdp case I'm sure it's enough
that it builds and boots no matter how the patches get merged :)

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

Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

2013-04-09 Thread Nishanth Menon

On 10:43-20130409, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [130409 09:54]:
  * Roger Quadros rog...@ti.com [130409 03:00]:
   On 04/05/2013 06:58 PM, Tony Lindgren wrote:

Can't you just use the clock name there to get it?
   
   In device tree we don't pass around clock names. You can either get
   a phandle or an index to the clock.
   
   e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
  
  Yes I understand that. But the driver/clock/omap driver can just
  remap the DT device initially so the board specific clock is
  found from the clock alias table. Basically initially a passthrough
  driver that can be enhanced to parse DT clock bindings and load
  data from /lib/firmware.
 
 Actually probably the driver/clock/omap can even do even less
 initially. There probably even no need to remap clocks there.
 
 As long as the DT clock driver understands that a board specific
 auxclk is specified in the DT it can just call clk_add_alias() so
 the driver will get the right auxclk from cclock44xx_data.c.
 
 Then other features can be added later on like to allocate a
 clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;

Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr

Would an cleaned up version be good enough as a step #1 of transition?

From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.

Dummy patch based on Roger's original idea

Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/boot/dts/omap3.dtsi  |5 ++
 arch/arm/boot/dts/omap34xx.dtsi   |2 +
 arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
 arch/arm/mach-omap2/cclock44xx_data.c |3 +-
 arch/arm/mach-omap2/pm.c  |   11 +++-
 drivers/clk/Kconfig   |6 ++
 drivers/clk/Makefile  |2 +
 drivers/clk/ti.c  |  100 +
 include/linux/clk/ti.h|   30 ++
 9 files changed, 157 insertions(+), 5 deletions(-)
 create mode 100644 drivers/clk/ti.c
 create mode 100644 include/linux/clk/ti.h

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
 
+   clks: clocks {
+   compatible = ti,clock;
+   #clock-cells = 1;
+   };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60  135
;
clock-latency = 30; /* From legacy driver */
+   clocks = clks 249; /* index to cpufreq_ck */
+   clock-names = cpu;
};
};
 };
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
 #include linux/clk-private.h
 #include linux/list.h
 #include linux/io.h
+#include linux/clk/ti.h
 
 #include soc.h
 #include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c  omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
 c++)
if (c-cpu  cpu_clkflg) {
-   clkdev_add(c-lk);
+   ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c 
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
 #include linux/clk-private.h
 #include linux/clkdev.h
 #include linux/io.h
+#include linux/clk/ti.h
 
 #include soc.h
 #include iomap.h
@@ -1697,7 +1698,7 @@ int __init omap4xxx_clk_init(void)
for (c = omap44xx_clks; c  omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
c++) {
if (c-cpu  cpu_clkflg

Re: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

2013-04-09 Thread Thierry Reding

On Tue, Apr 09, 2013 at 01:17:46PM -0700, Tony Lindgren wrote:
 * Thierry Reding thierry.red...@avionic-design.de [130409 12:45]:
  On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote:
  [...]
   But then the regulator is not found and the driver should just exit,
   or do nothing. If this is an optional regulator, then that should be
   indicated in some platform data flags?
  
  Yes, if the regulator isn't found then the driver fails. However the
  goal was to maintain bisectability. If we apply them in the wrong order
  we can't guarantee that because pwm-backlight will fail to work between
  both patches.
 
 But it's fixing something that's not working anyways for board-4430sdp.c,
 It seems so as these patches just add new features?

Not quite. It's adding a dummy regulator to represent hardware where the
enable pin is always high. So I think pwm-backlight will work in the
current state, but if we make the pwm-backlight driver change without
adding the dummy regulator, then pwm-backlight will fail to probe and
therefore the PWM won't be enabled either and the display will stay
black.

   The driver parts really must be done in independently from any platform
   data or .dts changes. The only common part needed should be changes
   to include/linux/platform_data/*.h files.
  
  We don't even need to touch platform data because the regulators are
  looked up via a global table. And the changes are all done independently
  but as I mentioned above, bisectability isn't maintained, so the
  preferred patch order is the one in which pwm-backlight keeps working at
  each point in the commit history.
 
 Bisectability is a good point. But in the 4430sdp case I'm sure it's enough
 that it builds and boots no matter how the patches get merged :)

If you don't mind some intermediary breakage, I will no longer object.

Thierry


pgpTcneQMYGuc.pgp
Description: PGP signature

Re: [PATCH] ARM: OMAP4: HWMOD: make 'ocp2scp_usb_phy_phy_48m as the main clock

2013-04-09 Thread Paul Walmsley

Hi

On Tue, 9 Apr 2013, Kishon Vijay Abraham I wrote:

 commit 92702d (ARM: OMAP4: PM: fix PM regression introduced by recent
 clock cleanup) makes the 'ocp2scp_usb_phy_phy_48m' as optional
 functional clock causing regression in MUSB. But this 48MHz clock is a
 mandatory clock for usb phy attached to ocp2scp and hence made as the main
 clock for ocp2scp.
 
 Cc: Keerthy j-keer...@ti.com
 Cc: Benoît Cousson b-cous...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

This patch is missing the big comment that I requested in the hwmod 
data:

http://marc.info/?l=linux-omapm=136544098331552w=2

Once that's added, it should be good to go.


- Paul

Re: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

2013-04-09 Thread Daniel Lezcano

On 04/09/2013 07:36 PM, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:

* Kevin Hilman khil...@linaro.org [130409 09:43]:
Arnd Bergmann a...@arndb.de writes:

On Tuesday 09 April 2013, Tony Lindgren wrote:
The following changes since commit
07961ac7c0ee8b546658717034fe692fd12eefa9:

Linux 3.9-rc5 (2013-03-31 15:12:43 -0700)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.10/cleanup-pm-signed

for you to fetch changes up to ca8cdff548da76da01f3783548ceb917139a5ddc:

Merge tag 'omap-pm-v3.10/cleanup/cpuidle' of
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm
into omap-for-v3.10/cleanup-pm (2013-04-08 09:51:00 -0700)

PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:

OMAP3/4 CPUidle cleanups for v3.10

Adding Daniel and Rafael to Cc.

Kevin,

I just want to point you this patch:

https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb

I did not yet send it to Rafael.

Is this series coordinated with the other cpuidle changes? Please tell me
if this
is good to go into arm-soc.

Hmm, looks like it's not ready. There are some minor conflicts with
what Rafael has queued up from Daniel.

I will work this out with Daniel to figure out how we should proceed.

OK it seems that this branch can also be queued by Rafael after
updating it if there's a dependency. So far it's not conflicting
with anything else we have queued up for arm soc tree.

Right, I just did a test rebase onto the relevant commit in Rafael
linux-next branch, and fixed up all the conflicts[1].

If Rafael agrees, it's fine with me if it goes via him.

Rafael, the signed tag for the updated branch is below[1], based on the
commit in your linux-next branch where you merged the rest of the
CPUidle changes. Let me know if you want a different base commit, or an
official pull request.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
tags/omap-pm-v3.10/cleanup/cpuidle-v2

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

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

4430sdp nfsroot broken with ff5c9059

Hi Jon,

Looks like at least 4430sdp nfsroot got broken with commit
ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells
property).

Do we need to pass the GPIO edge/level info now?

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

Re: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

Daniel Lezcano daniel.lezc...@linaro.org writes:

[...]


 PM cleanup to prepare for omap5 PM via Kevin Hilman khil...@linaro.org:

 OMAP3/4 CPUidle cleanups for v3.10

 Adding Daniel and Rafael to Cc.

 Kevin,

 I just want to point you this patch:

 https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb

 I did not yet send it to Rafael.

I haven't seen that one posted anywhere so it's not in my queue, and
probably too late for v3.10.

Once it's posted, I'll queue it up, and we can maybe get it in for
v3.10-rc.

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: [GIT PULL 2/5] omap pm clean-up for v3.10 merge window

2013-04-09 Thread Daniel Lezcano

On 04/09/2013 11:47 PM, Kevin Hilman wrote:
 Daniel Lezcano daniel.lezc...@linaro.org writes:
 
 [...]
 

 PM cleanup to prepare for omap5 PM via Kevin Hilman 
 khil...@linaro.org:

 OMAP3/4 CPUidle cleanups for v3.10

 Adding Daniel and Rafael to Cc.

 Kevin,

 I just want to point you this patch:

 https://git.linaro.org/gitweb?p=people/dlezcano/cpuidle-next.git;a=commit;h=e03a37fdf942a25154ccb5539524afd336f130bb

 I did not yet send it to Rafael.
 
 I haven't seen that one posted anywhere so it's not in my queue, and
 probably too late for v3.10.
 
 Once it's posted, I'll queue it up, and we can maybe get it in for
 v3.10-rc.

Yes, I just did the fix very recently. It was just a head up. I will
send it to Rafael as soon as the 'bleeding edge' branch is merged with
'linux-next'.


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

--
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: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

2013-04-09 Thread Nishanth Menon

On 15:49-20130409, Nishanth Menon wrote:
 On 10:43-20130409, Tony Lindgren wrote:
  * Tony Lindgren t...@atomide.com [130409 09:54]:
   * Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
 
 Can't you just use the clock name there to get it?

In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.

e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
   
   Yes I understand that. But the driver/clock/omap driver can just
   remap the DT device initially so the board specific clock is
   found from the clock alias table. Basically initially a passthrough
   driver that can be enhanced to parse DT clock bindings and load
   data from /lib/firmware.
  
  Actually probably the driver/clock/omap can even do even less
  initially. There probably even no need to remap clocks there.
  
  As long as the DT clock driver understands that a board specific
  auxclk is specified in the DT it can just call clk_add_alias() so
  the driver will get the right auxclk from cclock44xx_data.c.
  
  Then other features can be added later on like to allocate a
  clock entirely based on the binding etc.
 I did try to have an implementation for cpufreq using clock nodes.
 unfortunately, device tree wont let me have arguments of strings :(
 So, I am unable to do clock = clk mpu_dpll;
 instead, I am forced to do clock = clk 249;
 
 Here is an attempt on beagleXM - adds every clock node to the list.
 Tons of un-necessary prints added to give an idea - see log:
 http://pastebin.com/F9A2zSTr
 
 Would an cleaned up version be good enough as a step #1 of transition?
 
Approach #2:
Here is yet another revision - here I am trying to avoid the risk of
folks messing up indexing. for example: using an older DTB with newer
kernel, clocks being inserted into existing list etc. to prevent these,
we add an DT_ID for omap clock nodes, and use it to uniquely identify
the clock node. We try to minimize(not avoidable with integer indexing)
mistakes during development/productization.

From 2b576affdc6f6bf0b51ebf9b85ef4319357a7994 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [RFC PATCH V2] OMAP: add devicetree support for clock nodes.(rev 2)

Dummy patch based on Roger's original idea
this time have lesser possibiltiy of screwing up indices. instead
use a specific integer ID to uniquely (TI SoC wide) identify an clock.
on the flip side, we do not all make clock nodes to be accesible from DT
clock indexing.

Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
 .../devicetree/bindings/clock/ti,clock.txt |   48 +++
 arch/arm/boot/dts/omap3.dtsi   |5 ++
 arch/arm/boot/dts/omap34xx.dtsi|2 +
 arch/arm/boot/dts/omap4.dtsi   |5 ++
 arch/arm/boot/dts/omap443x.dtsi|2 +
 arch/arm/mach-omap2/cclock3xxx_data.c  |5 +-
 arch/arm/mach-omap2/cclock44xx_data.c  |5 +-
 arch/arm/mach-omap2/clock.h|   12 +++
 arch/arm/mach-omap2/pm.c   |   11 ++-
 drivers/clk/Kconfig|6 ++
 drivers/clk/Makefile   |2 +
 drivers/clk/ti.c   |   85 
 include/linux/clk/ti.h |   30 +++
 13 files changed, 211 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/ti,clock.txt
 create mode 100644 drivers/clk/ti.c
 create mode 100644 include/linux/clk/ti.h

diff --git a/Documentation/devicetree/bindings/clock/ti,clock.txt 
b/Documentation/devicetree/bindings/clock/ti,clock.txt
new file mode 100644
index 000..53c947c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,clock.txt
@@ -0,0 +1,48 @@
+* Clock bindings for Texas Instruments clocks
+
+Required properties:
+- compatible: Should be ti,clock
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell.  The following is a list of ID reservations
+across TI SoCs
+
+   Clock   ID
+   --
+   cpu clock   1
+
+The definition is used by SoC clock data using CLKDT() macro
+(example of OMAP2+).
+
+Example Steps:
+/* step 1: definiting an SoC nodes compatible with ti clocks -skip if already 
done */
+clks: clocks {
+   compatible = ti,clock;
+   #clock-cells = 1;
+};
+
+/* step 2: Modify the bindings documentation to reserve an ID */
+   auxclk0_ck  2
+   auxclk1_ck  3
+   auxclk2_ck  4
+   auxclk3_ck  5
+   auxclk4_ck  6
+   auxclk5_ck  7
+etc. use an unique number not conflicting with previous reservations.
+WARNING: DONOT insert values - this breaks backward compatibility.
+/* Step 3: replace in clock data file

Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs

* Nishanth Menon n...@ti.com [130409 13:53]:
 I did try to have an implementation for cpufreq using clock nodes.
 unfortunately, device tree wont let me have arguments of strings :(
 So, I am unable to do clock = clk mpu_dpll;
 instead, I am forced to do clock = clk 249;

It seems that you should have a separate clock defines for each
clock instead. That way we can later on populate that with
the clock specific data.
 
 Here is an attempt on beagleXM - adds every clock node to the list.
 Tons of un-necessary prints added to give an idea - see log:
 http://pastebin.com/F9A2zSTr
 
 Would an cleaned up version be good enough as a step #1 of transition?

Well I would make it even simpler initially. Just a standard .dts
clock defined that gets parsed by drivers/clock/ driver that just
calls clk_add_alias(). Then the consumer driver can just do clk_get()
and and the right clock is found, see below.

 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -73,6 +73,11 @@
   ti,hwmods = counter_32k;
   };
  
 + clks: clocks {
 + compatible = ti,clock;
 + #clock-cells = 1;
 + };
 +
   intc: interrupt-controller@4820 {
   compatible = ti,omap2-intc;
   interrupt-controller;

There should be a separate entry for each clock defined,
like auxclk1 in the USB case assuming the clock being used
is aux clock #1. I doubt that we want to map all the auxclks
as a single clock as they are separate clocks AFAIK.

 --- a/arch/arm/boot/dts/omap34xx.dtsi
 +++ b/arch/arm/boot/dts/omap34xx.dtsi
 @@ -23,6 +23,8 @@
   60  135
   ;
   clock-latency = 30; /* From legacy driver */
 + clocks = clks 249; /* index to cpufreq_ck */
 + clock-names = cpu;
   };
   };
  };

Then in the consumer driver you would just have:

clocks = auxclk1 0;

for the USB case, then something else for the cpufreq driver.

 --- a/arch/arm/mach-omap2/cclock3xxx_data.c
 +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
 @@ -22,6 +22,7 @@
  #include linux/clk-private.h
  #include linux/list.h
  #include linux/io.h
 +#include linux/clk/ti.h
  
  #include soc.h
  #include iomap.h
 @@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
   for (c = omap3xxx_clks; c  omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
   if (c-cpu  cpu_clkflg) {
 - clkdev_add(c-lk);
 + ti_clk_node_add(c-lk);
   if (!__clk_init(NULL, c-lk.clk))
   omap2_init_clk_hw_omap_clocks(c-lk.clk);
   }

AFAIK no need to tinkering with the clock_data.c files.

 --- /dev/null
 +++ b/drivers/clk/ti.c
 @@ -0,0 +1,100 @@
 +/*
 + * TI Clock node provider
 + *
 + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
 + *   Nishanth Menon
 + *
 + * 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 as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +#include linux/kernel.h
 +#include linux/list.h
 +#include linux/clk-private.h
 +#include linux/clkdev.h
 +#include linux/io.h
 +#include linux/of.h
 +#include linux/clk/ti.h

Then this can be just a minimal DT device driver that initially just
calls clk_add_alias() so the right clock is found when the driver
does clk_get(). Probably should be drivers/clock/omap/clk.c.

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

Re: [PATCH V3 1/2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

* Thierry Reding thierry.red...@avionic-design.de [130409 14:01]:
 On Tue, Apr 09, 2013 at 01:17:46PM -0700, Tony Lindgren wrote:
  * Thierry Reding thierry.red...@avionic-design.de [130409 12:45]:
   On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote:
   [...]
But then the regulator is not found and the driver should just exit,
or do nothing. If this is an optional regulator, then that should be
indicated in some platform data flags?
   
   Yes, if the regulator isn't found then the driver fails. However the
   goal was to maintain bisectability. If we apply them in the wrong order
   we can't guarantee that because pwm-backlight will fail to work between
   both patches.
  
  But it's fixing something that's not working anyways for board-4430sdp.c,
  It seems so as these patches just add new features?
 
 Not quite. It's adding a dummy regulator to represent hardware where the
 enable pin is always high. So I think pwm-backlight will work in the
 current state, but if we make the pwm-backlight driver change without
 adding the dummy regulator, then pwm-backlight will fail to probe and
 therefore the PWM won't be enabled either and the display will stay
 black.

OK
 
The driver parts really must be done in independently from any platform
data or .dts changes. The only common part needed should be changes
to include/linux/platform_data/*.h files.
   
   We don't even need to touch platform data because the regulators are
   looked up via a global table. And the changes are all done independently
   but as I mentioned above, bisectability isn't maintained, so the
   preferred patch order is the one in which pwm-backlight keeps working at
   each point in the commit history.
  
  Bisectability is a good point. But in the 4430sdp case I'm sure it's enough
  that it builds and boots no matter how the patches get merged :)
 
 If you don't mind some intermediary breakage, I will no longer object.

In this case it should be fine. If you are worried about it, you could
add something that enables the new features in the driver only in
a follow-up patch after the merge window. But I doubt that it's needed.

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

[GIT PULL] OMAP PM cleanups for v3.10

Tony,

Here's the final set of OMAP PM cleanups for v3.10.  This is a small set
of cleanups from Santosh to consolidate and prepare for OMAP5 PM additions.

It's based on your cleanup-v2 branch.

Kevin


The following changes since commit c309f7f46167e85d1aae2fd31f23e7d2b5cdfbe0:

  Merge branch 'for_3.10/omap_generic_cleanup_v2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux into 
omap-for-v3.10/cleanup-v2 (2013-03-28 14:45:31 -0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
tags/omap-pm-v3.10/cleanup/pm

for you to fetch changes up to 705814b5ea6ff69d4da8ad581c3da5d26d1eae83:

  ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5 (2013-04-09 
10:53:06 -0700)


OMAP PM cleanups for v3.10


Santosh Shilimkar (4):
  ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power 
states except off
  ARM: OMAP4+: PM: Consolidate MPU subsystem PM code for re-use
  ARM: OMAP4+: Make secondary_startup function name more consistent
  ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5

 arch/arm/mach-omap2/common.h  |  4 +-
 arch/arm/mach-omap2/omap-headsmp.S|  8 ++--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 69 +--
 arch/arm/mach-omap2/omap-smp.c|  6 +--
 arch/arm/mach-omap2/pm44xx.c  | 58 +-
 5 files changed, 113 insertions(+), 32 deletions(-)
--
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

[GIT PULL] CPUidle: OMAP cleanups for v3.10

Rafael,

Please pull the following OMAP CPUidle changes for v3.10.

Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.

Kevin

The following changes since commit f69e44b2059f2238ac558b4a115ebcdefe20b9be:

  Merge branch 'pm-cpuidle-next' into linux-next (2013-04-08 12:32:07 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
tags/omap-pm-v3.10/cleanup/cpuidle-v2

for you to fetch changes up to db4f3dab629109882170a7b1b8fb655a34c52846:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-09 
09:48:21 -0700)


OMAP CPUidle cleanups for v3.10


Daniel Lezcano (1):
  ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
  ARM: OMAP4: CPUidle: Avoid double idle driver registration
  ARM: OMAP: CPUidle: Unregister drivere on device registration failure
  ARM: OMAP4: CPUidle: Make C-state description field more precise
  ARM: OMAP4+: CPUidle: Deprecate use of 
omap4_mpuss_read_prev_context_state()
  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/common.h  |  5 
 arch/arm/mach-omap2/cpuidle34xx.c | 11 +--
 arch/arm/mach-omap2/cpuidle44xx.c | 48 +--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 -
 4 files changed, 35 insertions(+), 43 deletions(-)
--
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

[PATCH] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

From: Nishanth Menon n...@ti.com

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
omap-cpufreq device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
a) Will only run on platforms that create the platform_device
   omap-cpufreq.
b) Since the platform_device is registered only when device tree nodes
   are *not* populated, omap-cpufreq driver does not conflict with
   the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
   device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

Cc: Kevin Hilman khil...@linaro.org
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Keerthy j-keer...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Shawn Guo shawn@linaro.org
[robherri...@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring robherri...@gmail.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Kevin Hilman khil...@linaro.org
---
Rafael, can you add this one for v3.10?  It applies on top the
rest of your cpufreq changes and I've verified that the OMAP
changes are OK and don't conflict with anything else we have
queued for v3.10 on OMAP.

This patch was previously part of a 2-patch series, but the 
other part is still in discussion, and this part can be merged
independently.

 arch/arm/mach-omap2/pm.c   |  9 +
 drivers/cpufreq/omap-cpufreq.c | 19 ++-
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 673a4c1..8d15f9a 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva);
 }
 
+static inline void omap_init_cpufreq(void)
+{
+   struct platform_device_info devinfo = { .name = omap-cpufreq, };
+   platform_device_register_full(devinfo);
+}
+
 static int __init omap2_common_pm_init(void)
 {
if (!of_have_populated_dt())
@@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
 
/* Smartreflex device init */
omap_devinit_smartreflex();
+
+   /* cpufreq dummy device instantiation */
+   omap_init_cpufreq();
}
 
 #ifdef CONFIG_SUSPEND
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..d4f84b8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
 #include linux/opp.h
 #include linux/cpu.h
 #include linux/module.h
+#include linux/platform_device.h
 #include linux/regulator/consumer.h
 
 #include asm/smp_plat.h
@@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
.attr   = omap_cpufreq_attr,
 };
 
-static int __init omap_cpufreq_init(void)
+static int omap_cpufreq_probe(struct platform_device *pdev)
 {
mpu_dev = get_cpu_device(0);
if (!mpu_dev) {
@@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
return cpufreq_register_driver(omap_driver);
 }
 
-static void __exit omap_cpufreq_exit(void)
+static int omap_cpufreq_remove(struct platform_device *pdev)
 {
-   cpufreq_unregister_driver(omap_driver);
+   return cpufreq_unregister_driver(omap_driver);
 }
 
+static struct platform_driver omap_cpufreq_platdrv = {
+   .driver = {
+   .name   = omap-cpufreq,
+   .owner  = THIS_MODULE,
+   },
+   .probe  = omap_cpufreq_probe,
+   .remove = omap_cpufreq_remove,
+};
+module_platform_driver(omap_cpufreq_platdrv);
+
 MODULE_DESCRIPTION(cpufreq driver for OMAP SoCs);
 MODULE_LICENSE(GPL);
-module_init(omap_cpufreq_init);

[GIT PULL] CPUidle: OMAP cleanups for v3.10

[resend with correct address for linux-pm]

Rafael,

Please pull the following OMAP CPUidle changes for v3.10.

Due to dependencies on other CPUidle changes that are already in your
linux-next branch, this branch is based on the commit where you merged
your pm-cpuidle-next branch into linux-next.

Kevin

The following changes since commit f69e44b2059f2238ac558b4a115ebcdefe20b9be:

  Merge branch 'pm-cpuidle-next' into linux-next (2013-04-08 12:32:07 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
tags/omap-pm-v3.10/cleanup/cpuidle-v2

for you to fetch changes up to db4f3dab629109882170a7b1b8fb655a34c52846:

  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support (2013-04-09 
09:48:21 -0700)


OMAP CPUidle cleanups for v3.10


Daniel Lezcano (1):
  ARM: omap3: cpuidle: enable time keeping

Santosh Shilimkar (5):
  ARM: OMAP4: CPUidle: Avoid double idle driver registration
  ARM: OMAP: CPUidle: Unregister drivere on device registration failure
  ARM: OMAP4: CPUidle: Make C-state description field more precise
  ARM: OMAP4+: CPUidle: Deprecate use of 
omap4_mpuss_read_prev_context_state()
  ARM: OMAP4+: CPUidle: Consolidate idle driver for OMAP5 support

 arch/arm/mach-omap2/common.h  |  5 
 arch/arm/mach-omap2/cpuidle34xx.c | 11 +--
 arch/arm/mach-omap2/cpuidle44xx.c | 48 +--
 arch/arm/mach-omap2/omap-mpuss-lowpower.c | 14 -
 4 files changed, 35 insertions(+), 43 deletions(-)
--
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: [RFC PATCH 3/3] ARM: OMAP2+: Add command line parameter for debugSS module control