date:20130313

On Tue, Mar 12, 2013 at 12:11:54PM -0700, Andrew Chew wrote:
  From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
  Sent: Tuesday, March 12, 2013 12:01 AM
  To: Andrew Chew
  Cc: peter.ujfal...@ti.com; Alex Courbot; linux-omap@vger.kernel.org
  Subject: Re: [PATCH 1/1] ARM: OMAP: board-4430sdp: Provide regulator to
  pwm-backlight

  * PGP Signed by an unknown key

  On Mon, Mar 11, 2013 at 06:54:26PM -0700, Andrew Chew wrote:
   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
   ---
   This patch, along with many more soon to follow, attempts to satisfy
   the new mandatory regulator that pwm-backlight will grab during probe.
   The only board in mach-omap2 to use the pwm-backlight appears to be the
  4430sdp.

   I thought I'd start small and use this board as an example.

   I tested similar code in my Tegra board, so it should be okay.  Of
   course, I don't have a 4430sdp to test with.

  Hi Andrew,

  This looks good, one minor comment below. I think it might make sense to
  post this patch as part of a series that includes the change to the pwm-
  backlight driver. This will make things easier on potential testers.
  You can later extend that series to include all the other users and 
  eventually
  the whole series can be merged.

 Do you mean I should do a single patch series, accumulating other boards
 as I go?

Yes, that way everything needed will be in one patch series and people
can easily apply that to their trees. It will also make things easier if
we decide to merge all of them through one tree in the end.

 And by the way, do I have your reviewed-by for the pwm-backlight regulator
 patch?

I think it looks good, but I'll go over it again in your repost of the
whole series. I don't think you need my Reviewed-by, though, since I
maintain the pwm-backlight driver. =)

Thierry

pgpgrlZEo63Kk.pgp
Description: PGP signature

Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

2013-03-13 Thread Tomi Valkeinen

On 2013-03-12 17:01, Archit Taneja wrote:

 So, what I'm saying is that we should stick to output-dispc_channel. We
 iterate through all the panels, and by using output-dispc_channel, we
 get the manager for an output, and map that manager to a crtc, and make
 sure the number of unique managers we finally use is equal to NUM_CRTC.
 
 Does that sound good?

Yes, I think that sounds good.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: OMAP baseline test results for v3.9-rc1

2013-03-13 Thread Igor Grinberg

On 03/12/13 18:40, Paul Walmsley wrote:
 
 Here are some basic OMAP test results for Linux v3.9-rc1.
 Logs and other details at:
 
 http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/

[...]

 Failing tests: needing investigation
 

[...]

 * CM-T3517: boot hangs with MMC root
   - Due to missing MMC setup in board file
   - http://www.spinics.net/lists/arm-kernel/msg211471.html
   - Longstanding bug

This should have been fixed by:
ff95793 (ARM: OMAP3: cm-t3517: add MMC support)

I also can't find the MMC rootfs boot log on your website.


-- 
Regards,
Igor.
--
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: omap4 pandaboard: clock input for TiWi module inactive

On 03/12/2013 05:33 PM, Levi Pearson wrote:
 I spent some more time looking at clk-twl6030.c, and it seems it just turns 
 the
 twl6030 chip on when you ask it to enable the clock, and as far as I
 can tell that
 happens based on module dependencies?  There aren't any explicit references to
 it that I can find, so I'm not entirely sure how a clk-twl6040 would
 cause a clock
 to be enabled.

The clk-twl6040 is not really a good example for you start with. We only need
it to turn on in order to get the clock on the output. But the principle is
the same at the end. you need to enable/disable the clock from twl6030...

 If for whatever reason the commits cannot be reverted, would creating
 a driver like drivers/clk/clk-twl6040.c that enabled the twl6030's
 clock output be a suitable alternative?  I'd be willing to take a stab
 at writing it if there's not something like that in the works already.

 If you can take this it would be great. It is still in my to-do list to
 integrate the clk-twl6040 clock with the omap-mcpdm driver. I already got
 working code, but it is not working in a way I would really wanted to be.
 Integrating external clock to the SoC's clock tree does not seams to be that
 straight forward: at boot time when the clock tree is initialized the 
 external
 chip is yet to be probed - the root clock is not there, but later on for 
 some
 reason I can not get the CCF to enable the clock tree correctly.
 
 I looked into the early boot clock setup code, and that does look a lot less
 straightforward.

Yes, this is what I thought for the twl6040 clock integration with McPDM. It
turned out a bit more complicated.
At boot time you do not have the twl clock driver loaded.
You have the clock tree already defined.
When you boot further you add the clock for twl6040.
You want to hook it up with the existing clock tree - to set it as parent of
one of the clock root (which you already modified to not to be the root clock).
I shall work, but it does not:
for external chips we need to do the configuration/enable in clk_prepare time
(because they are over i2c).
So the driver goes and asks for a clock (which supposed to be at the end
rooted to this new external clock).
Nothing happens.
The relevant clock tree has been already got prepared earlier so new prepare
will not going to go down to the root, leaving the root clock disabled.

I'm still looking a way to somehow fix this, but my time is limited right now.


 There are already a few 32k clocks listed there, and
 I *think* they
 all source from the twl6040; do they just come up automatically at power-on?
 From what I can tell, clk32kg is just a gated fork of the regular 32k
 clock that is
 available at boot from twl6040.  I am surprised it doesn't come on by default.

I have not checked the schematics, but it could be that we have crystal 32K on
board as well. TWL6030 can gate some of it's 32K outputs and this is the case
with WiLink on PandaBoard.

 
 I also don't have a TRM for twl6040 that matches up with what twl-regulator.c 
 is
 doing to enable the clk32kg output; it looks like it's adding it to
 one of the power
 modes, but I'm not entirely sure how the registers it's writing to work, so my
 confidence level in being able to get it transplanted to a separate
 driver has lowered
 quite a bit.

I'm not sure if I have twl6030 TRM either, but I can try to come up with a
basic driver for the twl6030 clocks.

-- 
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 v2 0/5] cpsw interrupt pacing and get/set phy setting implementation

2013-03-13 Thread David Miller

From: Mugunthan V N mugunthan...@ti.com
Date: Tue, 12 Mar 2013 14:46:33 +0530

 This patch serires implements the following features in CPSW driver
 * get/set phy link settings
 * interrupt pacing
 * get phy id via ioctl cmd SIOCGMIIPHY
 
 Changes from initial version
 * Made active-slave common for cpts, ethtool and SIOCGMIIPHY ioctl
 * Cleaned CPSW DT binding documentation by seperating slave nodes
   under sub-section
 * implemented get phy id via ioctl cmd SIOCGMIIPHY

Series applied, 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

Re: Excessive ethernet interrupts on AM335x board

2013-03-13 Thread Koen Kooi


Op 12 mrt. 2013, om 16:35 heeft Mark Jackson mpfj-l...@mimc.co.uk het 
volgende geschreven:

 I'm just fighting an issue with ethernet on our custom AM335x board:-
 
 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux
 
 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-
 
 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)

You probably have PG2.x silicon, have a look at this patch: 
https://github.com/beagleboard/kernel/blob/3.8/patches/net/0003-cpsw-Fix-interrupt-storm-among-other-things.patch

I saw some patches going into net-next today that might address this in a 
different way, but I haven't tried 3.9rc on an am335x yet.--
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/5] usb: musb: omap: always glue have the correct vbus/id status

In the case where omap glue is loaded and musb core is not, glue-status
wont have a valid status if the phy drivers call omap_musb_mailbox. So
fixed the conditions here.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 78bfc50..28a0220 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -236,13 +236,10 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status 
status)
 {
struct omap2430_glue*glue = _glue;
 
-   if (glue  glue_to_musb(glue)) {
-   glue-status = status;
-   } else {
-   pr_err(%s: musb core is not yet ready\n, __func__);
+   if (!glue)
return;
-   }
 
+   glue-status = status;
schedule_work(glue-omap_musb_mailbox_work);
 }
 EXPORT_SYMBOL_GPL(omap_musb_mailbox);
@@ -307,7 +304,9 @@ static void omap_musb_mailbox_work(struct work_struct 
*mailbox_work)
 {
struct omap2430_glue *glue = container_of(mailbox_work,
struct omap2430_glue, omap_musb_mailbox_work);
-   omap_musb_set_mailbox(glue);
+
+   if (glue_to_musb(glue))
+   omap_musb_set_mailbox(glue);
 }
 
 static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
-- 
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

[PATCH 5/5] usb: otg: twl4030: fix cold plug on OMAP3

Having twl4030_usb_phy_init() (detects if a cable is connected before
twl4030 is probed) in twl4030 probe makes cable connect events to be
missed by musb glue, since it gets loaded after twl4030. Having
twl4030_usb_phy_init as a usb_phy ops lets twl4030_usb_phy_init to be
called when glue is ready.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/otg/twl4030-usb.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 5b20bb4..4040124 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -565,8 +565,9 @@ static void twl4030_id_workaround_work(struct work_struct 
*work)
}
 }
 
-static void twl4030_usb_phy_init(struct twl4030_usb *twl)
+static int twl4030_usb_phy_init(struct usb_phy *phy)
 {
+   struct twl4030_usb *twl = phy_to_twl(phy);
enum omap_musb_vbus_id_status status;
 
/*
@@ -581,6 +582,7 @@ static void twl4030_usb_phy_init(struct twl4030_usb *twl)
omap_musb_mailbox(twl-linkstat);
 
sysfs_notify(twl-dev-kobj, NULL, vbus);
+   return 0;
 }
 
 static int twl4030_set_suspend(struct usb_phy *x, int suspend)
@@ -657,6 +659,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl-phy.otg= otg;
twl-phy.type   = USB_PHY_TYPE_USB2;
twl-phy.set_suspend= twl4030_set_suspend;
+   twl-phy.init   = twl4030_usb_phy_init;
 
otg-phy= twl-phy;
otg-set_host   = twl4030_set_host;
@@ -696,8 +699,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
 
-   twl4030_usb_phy_init(twl);
-
dev_info(pdev-dev, Initialized TWL4030 USB module\n);
return 0;
 }
-- 
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

[PATCH 1/5] usb: musb: omap: remove the check before calling otg_set_vbus

No functional change. otg_set_vbus is already protected so removed the
check before calling otg_set_vbus.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 558c1d6..78bfc50 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -174,8 +174,7 @@ static void omap2430_musb_set_vbus(struct musb *musb, int 
is_on)
}
}
 
-   if (otg-set_vbus)
-   otg_set_vbus(otg, 1);
+   otg_set_vbus(otg, 1);
} else {
musb-is_active = 1;
otg-default_a = 1;
@@ -293,10 +292,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
}
 
omap2430_musb_set_vbus(musb, 0);
-   if (data-interface_type == MUSB_INTERFACE_UTMI) {
-   if (musb-xceiv-otg-set_vbus)
-   otg_set_vbus(musb-xceiv-otg, 0);
-   }
+   if (data-interface_type == MUSB_INTERFACE_UTMI)
+   otg_set_vbus(musb-xceiv-otg, 0);
omap_control_usb_set_mode(glue-control_otghs,
USB_MODE_DISCONNECT);
break;
-- 
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

[PATCH 4/5] usb: musb: omap: add usb_phy_init in omap2430_musb_init

Some PHYs load too early (twl4030) making omap glue to miss cable connect events
if the board is booted with cable connected. So adding usb_phy_init in
omap2430_musb_init lets PHYs to report events once glue is ready.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 28a0220..0786495 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -386,6 +386,8 @@ static int omap2430_musb_init(struct musb *musb)
if (glue-status != OMAP_MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
 
+   usb_phy_init(musb-xceiv);
+
pm_runtime_put_noidle(musb-controller);
return 0;
 
-- 
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

[PATCH 3/5] usb: otg: twl4030: use devres API for regulator get and request irq

Used devres APIs devm_request_threaded_irq and devm_regulator_get for
requesting irq and for getting regulator respectively.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/otg/twl4030-usb.c |   28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 04b732e2..5b20bb4 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -470,7 +470,7 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 3.1V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB3V1_DEV_GRP);
 
-   twl-usb3v1 = regulator_get(twl-dev, usb3v1);
+   twl-usb3v1 = devm_regulator_get(twl-dev, usb3v1);
if (IS_ERR(twl-usb3v1))
return -ENODEV;
 
@@ -479,18 +479,18 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
/* Initialize 1.5V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_DEV_GRP);
 
-   twl-usb1v5 = regulator_get(twl-dev, usb1v5);
+   twl-usb1v5 = devm_regulator_get(twl-dev, usb1v5);
if (IS_ERR(twl-usb1v5))
-   goto fail1;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V5_TYPE);
 
/* Initialize 1.8V regulator */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_DEV_GRP);
 
-   twl-usb1v8 = regulator_get(twl-dev, usb1v8);
+   twl-usb1v8 = devm_regulator_get(twl-dev, usb1v8);
if (IS_ERR(twl-usb1v8))
-   goto fail2;
+   return -ENODEV;
 
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB1V8_TYPE);
 
@@ -499,14 +499,6 @@ static int twl4030_usb_ldo_init(struct twl4030_usb *twl)
 TWL4030_PM_MASTER_PROTECT_KEY);
 
return 0;
-
-fail2:
-   regulator_put(twl-usb1v5);
-   twl-usb1v5 = NULL;
-fail1:
-   regulator_put(twl-usb3v1);
-   twl-usb3v1 = NULL;
-   return -ENODEV;
 }
 
 static ssize_t twl4030_usb_vbus_show(struct device *dev,
@@ -695,9 +687,9 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 * need both handles, otherwise just one suffices.
 */
twl-irq_enabled = true;
-   status = request_threaded_irq(twl-irq, NULL, twl4030_usb_irq,
-   IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
-   IRQF_ONESHOT, twl4030_usb, twl);
+   status = devm_request_threaded_irq(twl-dev, twl-irq, NULL,
+   twl4030_usb_irq, IRQF_TRIGGER_FALLING |
+   IRQF_TRIGGER_RISING | IRQF_ONESHOT, twl4030_usb, twl);
if (status  0) {
dev_dbg(pdev-dev, can't get IRQ %d, err %d\n,
twl-irq, status);
@@ -716,7 +708,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
int val;
 
cancel_delayed_work(twl-id_workaround_work);
-   free_irq(twl-irq, twl);
device_remove_file(twl-dev, dev_attr_vbus);
 
/* set transceiver mode to power on defaults */
@@ -738,9 +729,6 @@ static int __exit twl4030_usb_remove(struct platform_device 
*pdev)
 
if (!twl-asleep)
twl4030_phy_power(twl, 0);
-   regulator_put(twl-usb1v5);
-   regulator_put(twl-usb1v8);
-   regulator_put(twl-usb3v1);
 
return 0;
 }
-- 
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

[PATCH 0/5] usb: musb/otg: cleanup and fixes

This series has some misc cleanup and fixes. The fix solves the cold
plug issue in omap3 which some have reported. Developed these patches on
Linux 3.9-rc2 after applying 
http://www.spinics.net/lists/linux-usb/msg81563.html
(Grazvydas Ignotas patch series)

Tested for g_zero enumeration in pandaboard and beagleboard in both
cold plug and hot plug case. Any kind of testing for this series is welcome.

Kishon Vijay Abraham I (5):
  usb: musb: omap: remove the check before calling otg_set_vbus
  usb: musb: omap: always glue have the correct vbus/id status
  usb: otg: twl4030: use devres API for regulator get and request irq
  usb: musb: omap: add usb_phy_init in omap2430_musb_init
  usb: otg: twl4030: fix cold plug on OMAP3

 drivers/usb/musb/omap2430.c   |   22 ++
 drivers/usb/otg/twl4030-usb.c |   35 ---
 2 files changed, 22 insertions(+), 35 deletions(-)

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

On 03/12/2013 11:22 PM, Andrew Chew wrote:
 The pwm-backlight driver now takes a mandatory regulator that is gotten
 during driver probe.  Initialize a dummy regulator to satisfy this
 requirement.

I can test this tomorrow, but I have one comment:

 
 Signed-off-by: Andrew Chew ac...@nvidia.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index 35f3ad0..62022c0 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
   },
  };
  
 +/* Dummy regulator for pwm-backlight driver */
 +static struct regulator_consumer_supply backlight_supply =
 + REGULATOR_SUPPLY(enable, NULL);

'enable' is just too generic, the device name should be also provided:
REGULATOR_SUPPLY(enable, pwm-backlight);

 +
  static struct platform_pwm_backlight_data sdp4430_backlight_data = {
   .max_brightness = 127,
   .dft_brightness = 127,
 @@ -718,6 +722,7 @@ static void __init omap_4430sdp_init(void)
  
   omap4_i2c_init();
   omap_sfh7741prox_init();
 + regulator_register_always_on(-1, bl-enable, backlight_supply, 1, 0);
   platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
   omap_serial_init();
   omap_sdrc_init(NULL, NULL);
 


-- 
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 2/2 v2] pwm_bl: Add mandatory backlight enable regulator

On 03/12/2013 11:22 PM, Andrew Chew wrote:
 Many backlights need to be explicitly enabled.  Typically, this is done
 with a GPIO.  For flexibility, we generalize the enable mechanism to a
 regulator.
 
 If an enable regulator is not needed, then a dummy regulator can be given
 to the backlight driver.  If a GPIO is used to enable the backlight,
 then a fixed regulator can be instantiated to control the GPIO.
 
 The backlight enable regulator can be specified in the device tree node
 for the backlight, or can be done with legacy board setup code in the
 usual way.
 
 Signed-off-by: Andrew Chew ac...@nvidia.com
 Reviewed-by: Alexandre Courbot acour...@nvidia.com
 ---
  .../bindings/video/backlight/pwm-backlight.txt |   14 +
  drivers/video/backlight/pwm_bl.c   |   55 
 
  2 files changed, 59 insertions(+), 10 deletions(-)
 
 diff --git 
 a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt 
 b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
 index 1e4fc72..7e2e089 100644
 --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
 +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
 @@ -10,6 +10,11 @@ Required properties:
last value in the array represents a 100% duty cycle (brightest).
- default-brightness-level: the default brightness level (index into the
array defined by the brightness-levels property)
 +  - enable-supply: A phandle to the regulator device tree node. This
 +  regulator will be turned on and off as the pwm is enabled and disabled.
 +  Many backlights are enabled via a GPIO. In this case, we instantiate
 +  a fixed regulator and give that to enable-supply. If a regulator
 +  is not needed, then provide a dummy fixed regulator.
  
  Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
 @@ -19,10 +24,19 @@ Optional properties:
  
  Example:
  
 + bl_en: fixed-regulator {
 +compatible = regulator-fixed;
 +regulator-name = bl-en-supply;
 +regulator-boot-on;
 +gpio = some_gpio;
 +enable-active-high;
 + };
 +
   backlight {
   compatible = pwm-backlight;
   pwms = pwm 0 500;
  
   brightness-levels = 0 4 8 16 32 64 128 255;
   default-brightness-level = 6;
 + enable-supply = bl_en;
   };
 diff --git a/drivers/video/backlight/pwm_bl.c 
 b/drivers/video/backlight/pwm_bl.c
 index 1fea627..c557c51 100644
 --- a/drivers/video/backlight/pwm_bl.c
 +++ b/drivers/video/backlight/pwm_bl.c
 @@ -20,10 +20,13 @@
  #include linux/pwm.h
  #include linux/pwm_backlight.h
  #include linux/slab.h
 +#include linux/regulator/consumer.h
  
  struct pwm_bl_data {
   struct pwm_device   *pwm;
   struct device   *dev;
 + boolenabled;
 + struct regulator*enable_supply;
   unsigned intperiod;
   unsigned intlth_brightness;
   unsigned int*levels;
 @@ -35,6 +38,38 @@ struct pwm_bl_data {
   void(*exit)(struct device *);
  };
  
 +static void pwm_backlight_enable(struct backlight_device *bl)
 +{
 + struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
 +
 + /* Bail if we are already enabled. */
 + if (pb-enabled)
 + return;
 +
 + pwm_enable(pb-pwm);
 +
 + if (regulator_enable(pb-enable_supply) != 0)

I would loose the '!= 0'

 + dev_warn(bl-dev, Failed to enable regulator);
 +
 + pb-enabled = true;
 +}
 +
 +static void pwm_backlight_disable(struct backlight_device *bl)
 +{
 + struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
 +
 + /* Bail if we are already disabled. */
 + if (!pb-enabled)
 + return;
 +
 + if (regulator_disable(pb-enable_supply) != 0)
 + dev_warn(bl-dev, Failed to disable regulator);
 +
 + pwm_disable(pb-pwm);
 +
 + pb-enabled = false;
 +}

Would it not be better to have some locking here since the code started to use
flag for state tracking?

 +
  static int pwm_backlight_update_status(struct backlight_device *bl)
  {
   struct pwm_bl_data *pb = bl_get_data(bl);
 @@ -51,7 +86,7 @@ static int pwm_backlight_update_status(struct 
 backlight_device *bl)
  
   if (brightness == 0) {
   pwm_config(pb-pwm, 0, pb-period);
 - pwm_disable(pb-pwm);
 + pwm_backlight_disable(bl);
   } else {
   int duty_cycle;
  
 @@ -65,7 +100,7 @@ static int pwm_backlight_update_status(struct 
 backlight_device *bl)
   duty_cycle = pb-lth_brightness +
(duty_cycle * (pb-period - pb-lth_brightness) / max);
   pwm_config(pb-pwm, duty_cycle, pb-period);
 - pwm_enable(pb-pwm);
 + pwm_backlight_enable(bl);
   }
  
   if (pb-notify_after)
 @@

[PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy

With recent arm broadcast time clean-up from Mark Rutland, the dummy
broadcast device is always registered with timer subsystem. And since
the rating of the dummy clock event is very high, it is preferred
over a real broad-cast clock event.

This is a change in behavior from past and not an intended
one. So reduce the rating of the dummy clockevent so that
real broadcast device is selected when available.

Without this all the C states with C3STOP won't work since
the broad cast notifier will take an abort.

Cc: Mark Rutland mark.rutl...@arm.com
Cc: Russell King li...@arm.linux.org.uk

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Its a regression so hopefully can get into the 3.9-rcx. Noticed
this one on A15 platform. A9 platform the issue may not be seen
since the local timer check avoids dummy timer registration.

 arch/arm/kernel/smp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 31644f1..79078ed 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -480,7 +480,7 @@ static void __cpuinit broadcast_timer_setup(struct 
clock_event_device *evt)
evt-features   = CLOCK_EVT_FEAT_ONESHOT |
  CLOCK_EVT_FEAT_PERIODIC |
  CLOCK_EVT_FEAT_DUMMY;
-   evt-rating = 400;
+   evt-rating = 100;
evt-mult   = 1;
evt-set_mode   = broadcast_timer_set_mode;
 
-- 
1.7.9.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: [PATCH v3 0/7] ARM: dts: omap: Add dts data for USB

2013-03-13 Thread kishon


Benoit,

Will you be queuing this patch series?

Thanks
Kishon

On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote:

Hi Benoit,

Here are the dt data patches to get usb device functional in OMAP platforms.

All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt

Changes from v2:
* squashed the dt data for dwc3-omap with dwc3 core into a single patch.

Changes from v1:
Patch *ARM: dts: omap: Add usb_otg and glue data* has some properties with
names that has _. It's replaced with a - here.

This patch is developed on Linux 3.9-rc1.

Kishon Vijay Abraham I (7):
   ARM: dts: omap: Add omap control usb data
   ARM: dts: omap: Add omap-usb2 dt data
   ARM: dts: omap: Add usb_otg and glue data
   ARM: dts: omap5: Add omap control usb data
   ARM: dts: omap5: Add ocp2scp data
   ARM: dts: omap5: Add omap-usb3 and omap-usb2 dt data
   ARM: dts: omap5: add dwc3 omap and dwc3 core dt data

  Documentation/devicetree/bindings/usb/omap-usb.txt |1 +
  arch/arm/boot/dts/omap3-beagle-xm.dts  |6 +++
  arch/arm/boot/dts/omap3-evm.dts|6 +++
  arch/arm/boot/dts/omap3-overo.dtsi |6 +++
  arch/arm/boot/dts/omap3.dtsi   |   12 +
  arch/arm/boot/dts/omap4-panda.dts  |6 +++
  arch/arm/boot/dts/omap4-sdp.dts|6 +++
  arch/arm/boot/dts/omap4.dtsi   |   26 +++
  arch/arm/boot/dts/omap5.dtsi   |   48 
  arch/arm/boot/dts/twl4030.dtsi |2 +-
  10 files changed, 118 insertions(+), 1 deletion(-)



--
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] usb: dwc3: Set DWC3 context's mode based on selected mode.

2013-03-13 Thread Vivek Gautam

Hi Balbi,


On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Now that machines may select the mode of working of DWC3 (HOST only,
 GADGET only or DUAL_ROLE), lets set DWC3 mode based on that
 rather than fixing it to whatever DWC3 hardware says.
 This way we can skip initializing Gadget/Host in case
 we are using Host-only/Gadget-only mode respectively.


Hope this patch if fine, and mainlinable ?

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---

 Changes from RFC patch usb: dwc3: Set GCTL.PrtCapDir based on selected mode
  - Setting the mode in dwc3 context structure based on
selected mode in machine, rather than programming PrtCapDir

  drivers/usb/dwc3/core.c |7 ++-
  1 files changed, 6 insertions(+), 1 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 79f335f..be0672f 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -478,7 +478,12 @@ static int dwc3_probe(struct platform_device *pdev)
 goto err1;
 }

 -   mode = DWC3_MODE(dwc-hwparams.hwparams0);
 +   if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
 +   mode = DWC3_MODE_HOST;
 +   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
 +   mode = DWC3_MODE_DEVICE;
 +   else
 +   mode = DWC3_MODE_DRD;

 switch (mode) {
 case DWC3_MODE_DEVICE:
 --
 1.7.6.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks  Regards
Vivek
--
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] usb: dwc3: Set DWC3 context's mode based on selected mode.

2013-03-13 Thread Felipe Balbi

On Wed, Mar 13, 2013 at 02:42:22PM +0530, Vivek Gautam wrote:
 Hi Balbi,
 
 
 On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
  Now that machines may select the mode of working of DWC3 (HOST only,
  GADGET only or DUAL_ROLE), lets set DWC3 mode based on that
  rather than fixing it to whatever DWC3 hardware says.
  This way we can skip initializing Gadget/Host in case
  we are using Host-only/Gadget-only mode respectively.
 
 
 Hope this patch if fine, and mainlinable ?

yes, it's in my testing branch, you will receive mail soon

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: dwc3: Set DWC3 context's mode based on selected mode.

2013-03-13 Thread Vivek Gautam

On Wed, Mar 13, 2013 at 2:44 PM, Felipe Balbi ba...@ti.com wrote:
 On Wed, Mar 13, 2013 at 02:42:22PM +0530, Vivek Gautam wrote:
 Hi Balbi,


 On Sat, Mar 2, 2013 at 6:55 PM, Vivek Gautam gautam.vi...@samsung.com 
 wrote:
  Now that machines may select the mode of working of DWC3 (HOST only,
  GADGET only or DUAL_ROLE), lets set DWC3 mode based on that
  rather than fixing it to whatever DWC3 hardware says.
  This way we can skip initializing Gadget/Host in case
  we are using Host-only/Gadget-only mode respectively.
 

 Hope this patch if fine, and mainlinable ?

 yes, it's in my testing branch, you will receive mail soon


Sure, thanks.

 --
 balbi



-- 
Thanks  Regards
Vivek
--
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: smp: Allow real broadcast device selection instead of always dummy

(Forgot to CC Thomas)

On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
 With recent arm broadcast time clean-up from Mark Rutland, the dummy
 broadcast device is always registered with timer subsystem. And since
 the rating of the dummy clock event is very high, it is preferred
 over a real broad-cast clock event.
 
 This is a change in behavior from past and not an intended
 one. So reduce the rating of the dummy clockevent so that
 real broadcast device is selected when available.
 
 Without this all the C states with C3STOP won't work since
 the broad cast notifier will take an abort.
 
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Russell King li...@arm.linux.org.uk
 
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
 Its a regression so hopefully can get into the 3.9-rcx. Noticed
 this one on A15 platform. A9 platform the issue may not be seen
 since the local timer check avoids dummy timer registration.
 
Some one pointed me to a fix made by Mark which was discussed
under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
That patch seems to be more of work around since the root of the
problem is incorrect dummy timer rating. Either way, both patches
fix the issue.

  arch/arm/kernel/smp.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
 index 31644f1..79078ed 100644
 --- a/arch/arm/kernel/smp.c
 +++ b/arch/arm/kernel/smp.c
 @@ -480,7 +480,7 @@ static void __cpuinit broadcast_timer_setup(struct 
 clock_event_device *evt)
   evt-features   = CLOCK_EVT_FEAT_ONESHOT |
 CLOCK_EVT_FEAT_PERIODIC |
 CLOCK_EVT_FEAT_DUMMY;
 - evt-rating = 400;
 + evt-rating = 100;
   evt-mult   = 1;
   evt-set_mode   = broadcast_timer_set_mode;
  
 

--
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 net-next 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

On 18/02/13 08:19, Mugunthan V N wrote:
 CPDMA interrupts are not properly acknowledged which leads to interrupt
 storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
 Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
 used for rx and tx respectively.
 
 Reported-by: Pantelis Antoniou pa...@antoniou-consulting.com
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

Not sure if I'm seeing this same problem [1], but it doesn't appear fixed to me.

I've tried both mainline -rc2 and -next.

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

Regards
Mark J.
--
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: Excessive ethernet interrupts on AM335x board

On 13/03/13 08:44, Koen Kooi wrote:
 
 Op 12 mrt. 2013, om 16:35 heeft Mark Jackson mpfj-l...@mimc.co.uk het 
 volgende geschreven:
 
 I'm just fighting an issue with ethernet on our custom AM335x board:-

 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux

 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-

 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)
 
 You probably have PG2.x silicon, have a look at this patch: 
 https://github.com/beagleboard/kernel/blob/3.8/patches/net/0003-cpsw-Fix-interrupt-storm-among-other-things.patch

No, it's 1.0 ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.9.0-rc2-00113-gd60f039-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #141 Wed Mar 13 
09:14:03 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow 
AM335x NanoBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )

The patch certainly didn't fix things (and possibly made things worse i.e. my 
nfs root kept dropping off even more).

 I saw some patches going into net-next today that might address this in a 
 different way, but I haven't tried 3.9rc on an am335x yet.

I might track those down and test them.

Cheers
Mark J.
--
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 2/2 v2] pwm_bl: Add mandatory backlight enable regulator

On Wed, Mar 13, 2013 at 09:56:57AM +0100, Peter Ujfalusi wrote:
 On 03/12/2013 11:22 PM, Andrew Chew wrote:
[...]
  +static void pwm_backlight_disable(struct backlight_device *bl)
  +{
  +   struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
  +
  +   /* Bail if we are already disabled. */
  +   if (!pb-enabled)
  +   return;
  +
  +   if (regulator_disable(pb-enable_supply) != 0)
  +   dev_warn(bl-dev, Failed to disable regulator);
  +
  +   pwm_disable(pb-pwm);
  +
  +   pb-enabled = false;
  +}
 
 Would it not be better to have some locking here since the code started to use
 flag for state tracking?

I don't think that's necessary. The backlight core already uses the
ops_lock mutex to serial accesses. I just noticed that the documentation
mentions that update_lock is used for this purpose, but the code doesn't
use it after it is initialized. Still, the ops_lock should be enough.

Thierry


pgp0kA3PVkoTc.pgp
Description: PGP signature

Re: [PATCH] ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

2013-03-13 Thread Paul Walmsley

Hello Gražvydas,

On Mon, 11 Mar 2013, Grazvydas Ignotas wrote:

 For some unknown reason, allowing hwmod to control MIDLEMODE causes
 core_pwrdm to not hit idle states for musb in DM3730 at least.
 I've verified that setting any MIDLEMODE value other than force
 standby before enabling the device causes subsequent suspend
 attempts to fail with core_pwrdm not entering idle states, even
 if the driver is unloaded and force standby is restored before
 suspend attempt. To recover from this, soft reset can be used, but
 that's not suitable solution for suspend.
 
 Keeping the register set at force standby (reset value) makes it work
 and device still functions properly, as musb has driver-controlled
 OTG_FORCESTDBY register that controls MSTANDBY signal.
 Note that TI PSP kernels also have similar workarounds.
 
 This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
 actual flag name.
 
 Signed-off-by: Grazvydas Ignotas nota...@gmail.com

Thanks for the good patch description and for making those changes.  
Queued for v3.9-rc.

- Paul

Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy

2013-03-13 Thread Mark Rutland

Hi Santosh,

On Wed, Mar 13, 2013 at 09:28:22AM +, Santosh Shilimkar wrote:
 (Forgot to CC Thomas)
 
 On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
  With recent arm broadcast time clean-up from Mark Rutland, the dummy
  broadcast device is always registered with timer subsystem. And since
  the rating of the dummy clock event is very high, it is preferred
  over a real broad-cast clock event.
  
  This is a change in behavior from past and not an intended
  one. So reduce the rating of the dummy clockevent so that
  real broadcast device is selected when available.
  
  Without this all the C states with C3STOP won't work since
  the broad cast notifier will take an abort.
  
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Russell King li...@arm.linux.org.uk
  
  Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
  ---
  Its a regression so hopefully can get into the 3.9-rcx. Noticed
  this one on A15 platform. A9 platform the issue may not be seen
  since the local timer check avoids dummy timer registration.
  
 Some one pointed me to a fix made by Mark which was discussed
 under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
 That patch seems to be more of work around since the root of the
 problem is incorrect dummy timer rating. Either way, both patches
 fix the issue.

Is the problem that the dummy timer is being registered as the broadcast
source, or that it is selected as a local timer in preference of real timers?

If it is the former, Then I believe my patch solve the issue more generally -
if you happen to register a dummy timer before other timers, it will become the
broadcast source. Regardless of how temporary this is, it should never happen,
and lowering the rating of the dummy won't fix this.

If it is the latter, then this patch would ensure that a real timer with a
rating over 100 is selected in preference to the dummy, which is certainly what
we want. The proposed generic dummy timer in Stephen Boyd's local timer API
removal series [1] similarly uses a low rating to ensure that real timers are
selected in preference to an always-registered dummy. I note that the
architected timer has a higher rating (450) than the dummy (400), so this
shouldn't currently be a problem.

Have I missed something?

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/153208.html

Thanks,
Mark.
--
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: OMAP baseline test results for v3.9-rc1

2013-03-13 Thread Paul Walmsley

Hi Aaro,

On Tue, 12 Mar 2013, Aaro Koskinen wrote:

 On Tue, Mar 12, 2013 at 04:40:19PM +, Paul Walmsley wrote:
  * 2420N800: powers down 30 seconds after boot
- Presumably due to missing CBUS patches for watchdog control
- http://lkml.org/lkml/2012/9/3/265
- http://marc.info/?l=linux-omapm=135274739624125w=2
- http://marc.info/?l=linux-omapm=135664195831104w=2
- Should be working in v3.9-rc1 when CONFIG_RETU_WATCHDOG=y ?
 
 Yes, you need also CONFIG_I2C_CBUS_GPIO and CONFIG_MFD_RETU.

OK thanks, will add that in for the v3.9-rc2 test.

Would it make sense to add those dependencies to the Kconfig file for 
CONFIG_RETU_WATCHDOG?


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.9-rc1

2013-03-13 Thread Paul Walmsley

Hi Igor,

On Wed, 13 Mar 2013, Igor Grinberg wrote:

 This should have been fixed by:
 ff95793 (ARM: OMAP3: cm-t3517: add MMC support)
 
 I also can't find the MMC rootfs boot log on your website.

Hmm, I thought I had switched the CM-T3517 over to use MMC booting, but 
looks like it's still trying to use nfsroot.  Thanks for letting me know.  
Will switch to MMC and try again.


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Excessive ethernet interrupts on AM335x board

2013-03-13 Thread Daniel Mack

On Tue, Mar 12, 2013 at 4:35 PM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
 I'm just fighting an issue with ethernet on our custom AM335x board:-

 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux

 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-

 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)

 I've tried to force the problem by flood pinging from my PC.

 # while true
 do grep 58: /proc/interrupts; sleep 10
 done
  58:   1291  INTC  4a10.ethernet   normal pinging (about 100 
 irqs per 10sec)
  58:   1333  INTC  4a10.ethernet
  58:   1372  INTC  4a10.ethernet
  58:   3979  INTC  4a10.ethernet   start flood ping (about 4k 
 irqs per 10sec)
  58:   6540  INTC  4a10.ethernet
  58:  17519  INTC  4a10.ethernet   big jump 
  58:  20169  INTC  4a10.ethernet
  58:  22775  INTC  4a10.ethernet
  58:  25368  INTC  4a10.ethernet
  58:  34598  INTC  4a10.ethernet   big jump 
  58:  37182  INTC  4a10.ethernet
  58:  39730  INTC  4a10.ethernet
  58: 141220  INTC  4a10.ethernet   whoa !!! 
  58: 146080  INTC  4a10.ethernet
  58: 149351  INTC  4a10.ethernet
  58: 152922  INTC  4a10.ethernet
  58: 156420  INTC  4a10.ethernet
  58: 159538  INTC  4a10.ethernet
  58: 162711  INTC  4a10.ethernet
  58: 165746  INTC  4a10.ethernet
  58: 168973  INTC  4a10.ethernet
  58: 172128  INTC  4a10.ethernet
  58: 175030  INTC  4a10.ethernet
  58: 177957  INTC  4a10.ethernet
  58: 180782  INTC  4a10.ethernet
  58: 183618  INTC  4a10.ethernet
  58: 186450  INTC  4a10.ethernet
  58: 189242  INTC  4a10.ethernet
  58: 191909  INTC  4a10.ethernet
  58: 194565  INTC  4a10.ethernet
  58: 197153  INTC  4a10.ethernet
  58: 199730  INTC  4a10.ethernet   another big jump 
  58: 252629  INTC  4a10.ethernet
  58: 262955  INTC  4a10.ethernet
  58: 265557  INTC  4a10.ethernet
  58: 268131  INTC  4a10.ethernet
  58: 272586  INTC  4a10.ethernet
  58: 275623  INTC  4a10.ethernet   here I stop flood pings 
 [  631.727758] nfs: server 10.0.0.100 not responding, still trying
 [  638.738864] nfs: server 10.0.0.100 OK
  58: 277694  INTC  4a10.ethernet
  58: 277703  INTC  4a10.ethernet
  58: 277709  INTC  4a10.ethernet
  58: 277719  INTC  4a10.ethernet
  58: 277725  INTC  4a10.ethernet
  58: 277734  INTC  4a10.ethernet
  58: 277745  INTC  4a10.ethernet

 As you can see, when I stop the flood pings, the nfs link is now reported
 as being lost.

I had the same problem. Please check this patch, I'm sure it will fix you issue:

  
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0



Daniel
--
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 V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding

2013-03-13 Thread Mark Brown

On Mon, Mar 11, 2013 at 08:50:22AM +0100, Sebastien Guiriec wrote:
 Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+.
 In case of DT boot snd_dmaengine_generic_pcm_open function is used.
 
 Signed-off-by: Sebastien Guiriec s-guir...@ti.com

Discarded since it breaks the build as a result of depending on unmerged
patches.


signature.asc
Description: Digital signature

Re: Excessive ethernet interrupts on AM335x board

On 13/03/13 10:32, Daniel Mack wrote:
 On Tue, Mar 12, 2013 at 4:35 PM, Mark Jackson mpfj-l...@mimc.co.uk wrote:
 I'm just fighting an issue with ethernet on our custom AM335x board:-

 # uname -a
 Linux nanobone 3.9.0-rc2-00113-gd60f039 #139 Tue Mar 12 15:14:01 GMT 2013 
 armv7l GNU/Linux

 Every now and then, the whole unit slows to a crawl.  The only indication of 
 any problem is:-

 (a) the serial tty port becomes much less responsive
 (b) normal ping times jump from 1ms to 10sec (sometimes 20sec !!)
 (c) the ethernet interrupt count rockets (see below)

 I've tried to force the problem by flood pinging from my PC.

snip

 As you can see, when I stop the flood pings, the nfs link is now reported
 as being lost.
 
 I had the same problem. Please check this patch, I'm sure it will fix you 
 issue:
 
   
 https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=d35162f89b8f00537d7b240b76d2d0e8b8d29aa0

Brilliant ... that's the one !!  

Cheers
Mark J.
--
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: MTD : Kernel oops when remounting ubifs as read/write

On 12/03/13 11:25, Artem Bityutskiy wrote:
 On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
 I'm encountering an oops when remounting my ubifs volume as read/write.

 # mount -o remount,rw /
 [   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
 (ubifs_write_master+0x9c/0x134)
 [   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
 (ubifs_write_master+0xd8/0x134)
 [   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.585939] UBIFS: start fixing up free space
 [   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
 [   91.419951] UBIFS: free space fixup complete
 #

 If it's any help, if the remount is put into my inittab, I don't get any 
 oops.
 
 Would you please try this patch (also attached):
 
 diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
 index ac838b8..9791b3c 100644
 --- a/fs/ubifs/super.c
 +++ b/fs/ubifs/super.c
 @@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   c-remounting_rw = 1;
   c-ro_mount = 0;
  
 + if (c-space_fixup) {
 + err = ubifs_fixup_free_space(c);
 + if (err)
 + goto out;
 + }
 +
   err = check_free_space(c);
   if (err)
   goto out;
 @@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   err = dbg_check_space_info(c);
   }
  
 - if (c-space_fixup) {
 - err = ubifs_fixup_free_space(c);
 - if (err)
 - goto out;
 - }
 -
   mutex_unlock(c-umount_mutex);
   return err;
 

Sorry ... this just locks up the unit.

Mark J.
--
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: MTD : Kernel oops when remounting ubifs as read/write

2013-03-13 Thread Artem Bityutskiy

On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
  -   if (c-space_fixup) {
  -   err = ubifs_fixup_free_space(c);
  -   if (err)
  -   goto out;
  -   }
  -
  mutex_unlock(c-umount_mutex);
  return err;
  
 
 Sorry ... this just locks up the unit.

Am I right that to reproduce it I need any image with the 'fixup' flag
set, then I should put it on the flash, mount it R/O and then remount
R/W. Right?

-- 
Best Regards,
Artem Bityutskiy

--
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: MTD : Kernel oops when remounting ubifs as read/write

On 13/03/13 11:20, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 -   if (c-space_fixup) {
 -   err = ubifs_fixup_free_space(c);
 -   if (err)
 -   goto out;
 -   }
 -
 mutex_unlock(c-umount_mutex);
 return err;


 Sorry ... this just locks up the unit.
 
 Am I right that to reproduce it I need any image with the 'fixup' flag
 set, then I should put it on the flash, mount it R/O and then remount
 R/W. Right?
 

Yes ... this is on a custom AM335x board, where the ubi image must be created
with the -F flag.

Cheers
Mark J.
--
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: smp: Allow real broadcast device selection instead of always dummy

On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote:
 Hi Santosh,
 
 On Wed, Mar 13, 2013 at 09:28:22AM +, Santosh Shilimkar wrote:
 (Forgot to CC Thomas)

 On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
 With recent arm broadcast time clean-up from Mark Rutland, the dummy
 broadcast device is always registered with timer subsystem. And since
 the rating of the dummy clock event is very high, it is preferred
 over a real broad-cast clock event.

 This is a change in behavior from past and not an intended
 one. So reduce the rating of the dummy clockevent so that
 real broadcast device is selected when available.

 Without this all the C states with C3STOP won't work since
 the broad cast notifier will take an abort.

 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Russell King li...@arm.linux.org.uk

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
 Its a regression so hopefully can get into the 3.9-rcx. Noticed
 this one on A15 platform. A9 platform the issue may not be seen
 since the local timer check avoids dummy timer registration.

 Some one pointed me to a fix made by Mark which was discussed
 under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
 That patch seems to be more of work around since the root of the
 problem is incorrect dummy timer rating. Either way, both patches
 fix the issue.
 
 Is the problem that the dummy timer is being registered as the broadcast
 source, or that it is selected as a local timer in preference of real timers?

Dummy timer is preferred over real broadcast timer.
 
 If it is the former, Then I believe my patch solve the issue more generally -
 if you happen to register a dummy timer before other timers, it will become 
 the
 broadcast source. Regardless of how temporary this is, it should never happen,
 and lowering the rating of the dummy won't fix this.
 
Well by the time we need active broadcast functionality, clock-events are
already chosen if the ratings are appropriate.

 If it is the latter, then this patch would ensure that a real timer with a
 rating over 100 is selected in preference to the dummy, which is certainly 
 what
 we want. The proposed generic dummy timer in Stephen Boyd's local timer API
 removal series [1] similarly uses a low rating to ensure that real timers are
 selected in preference to an always-registered dummy. I note that the
 architected timer has a higher rating (450) than the dummy (400), so this
 shouldn't currently be a problem.
 
Because we always register dummy broadcast on ARM now 
and with higher rating, it is picked as broadcast source. We definitely don't
want such a behavior when we have real broadcast device is available.


With your patch, we are trying to avoid the registration which goes
against the the whole idea of registering it always and picking
the right clock-event based on rating by clock-event core.
The clock-event core except the proper ratings to be provided based on
the capability of the timer source and its resolution and in that case
dummy should have the lowest rating which is what I tried to patch.

 Have I missed something?
 
Not much. I was just looking at x86 code as well after your email
to see how the LAPIC issue is handled. They seems to also have
correct rating to take care of the selection.

Probably we can merge both the fixes but from clock-event core
code perspective, the ratings fix is more than enough.

Thomas might be able to comment better.

Regards,
Santosh


--
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 v2 12/12] USB: ehci-omap: Fix detection in HSIC mode

On 03/12/2013 06:07 PM, Alan Stern wrote:
 On Tue, 12 Mar 2013, Roger Quadros wrote:
 
 The HSIC devices need to be kept in reset while the EHCI controller
 is being initialized and only brought out of reset after the
 initialization is complete, else HSIC devices will not be detected.
 
 This is not a great description of what the patch does.  You should say
 that it moves PHY initialization until after EHCI initialization is
 complete, instead of initializing the PHYs first, shutting them down
 again, and then initializing them a second time.
 

Okay will update the description.

 Also remove outdated TODO list from header.

 Signed-off-by: Roger Quadros rog...@ti.com
 CC: Alan Stern st...@rowland.harvard.edu
 ---
  drivers/usb/host/ehci-omap.c |   38 +++---
  1 files changed, 15 insertions(+), 23 deletions(-)

 diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
 index 1ba1df8..dc2de47 100644
 --- a/drivers/usb/host/ehci-omap.c
 +++ b/drivers/usb/host/ehci-omap.c
 @@ -29,12 +29,6 @@
   * along with this program; if not, write to the Free Software
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
   *
 - * TODO (last updated Feb 27, 2010):
 - *  - add kernel-doc
 - *  - enable AUTOIDLE
 - *  - add suspend/resume
 - *  - add HSIC and TLL support
 - *  - convert to use hwmod and runtime PM
   */
  
  #include linux/kernel.h
 @@ -90,26 +84,13 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
  static int omap_ehci_init(struct usb_hcd *hcd)
  {
  struct ehci_hcd *ehci = hcd_to_ehci(hcd);
 -struct omap_hcd *omap = (struct omap_hcd *)ehci-priv;
 -int rc, i;
 -
 -/* Hold PHYs in reset while initializing EHCI controller */
 -for (i = 0; i  omap-nports; i++) {
 -if (omap-phy[i])
 -usb_phy_shutdown(omap-phy[i]);
 -}
 +int rc;
  
  /* we know this is the memory we want, no need to ioremap again */
  ehci-caps = hcd-regs;
  
  rc = ehci_setup(hcd);
  
 -/* Bring PHYs out of reset */
 -for (i = 0; i  omap-nports; i++) {
 -if (omap-phy[i])
 -usb_phy_init(omap-phy[i]);
 -}
 -
  return rc;
  }
 
 Now that there's almost nothing left of this function, you can get rid
 of it completely.  Move the assignment to ehci-caps into
 ehci_hcd_omap_probe() and remove the init entry in the overrides
 structure.

Right. Sounds good.

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: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'

2013-03-13 Thread Dietmar Eggemann


On 13/03/13 06:52, Lokesh Vutla wrote:

Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for self-hosted
debug} introduces debug powerdown support for self-hosted debug.
While merging the patch 'has_ossr' check was removed which
was needed for hardwares which doesn't support self-hosted debug.
Pandaboard (A9) is one such hardware and Dietmar's orginial
patch did mention this issue.
Without that check on Panda with CPUIDLE enabled, a flood of
below messages thrown.

[ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch
[ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch



Hi Lokesh,

I confirm that this has_ossr condition has to go back into the
pm_init(void) call. I just verified it again on my Panda board and I get
the same issue like you without it.

I guess what was happening is that Will asked me if this check is really
necessary and I said No without re-testing on my Panda board as an V7
debug architecture example where OSSR is not implemented. Since then I
only tested in on V7.1 debug architectures where OSSR is mandatory.
Sorry about this and thanks for catching this.

You can add my Acked-by: if you wish.

-- Dietmar


So restore that check back to avoid the mentioned issue.

Cc: Dietmar Eggemann dietmar.eggem...@arm.com
Cc: Will Deacon will.dea...@arm.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
  arch/arm/kernel/hw_breakpoint.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..0ba062d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1049,7 +1049,8 @@ static struct notifier_block __cpuinitdata dbg_cpu_pm_nb 
= {

  static void __init pm_init(void)
  {
- cpu_pm_register_notifier(dbg_cpu_pm_nb);
+ if (has_ossr)
+ cpu_pm_register_notifier(dbg_cpu_pm_nb);
  }
  #else
  static inline void pm_init(void)



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

--
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] Fix sprz319 erratum 2.1

2013-03-13 Thread Cliff Brake

On Tue, Mar 12, 2013 at 2:52 PM, Cliff Brake cliff.br...@gmail.com wrote:
 On Tue, Mar 12, 2013 at 11:33 AM, Cliff Brake cliff.br...@gmail.com wrote:
 On Tue, Mar 12, 2013 at 10:57 AM, Paul Walmsley p...@pwsan.com wrote:

 Are you in a position to test whether the patch works for you?

 I'd still like to find someone whose USB problem is fixed by the patch and
 is willing to try a slight modification of it before applying...

 Yes, I'm in a position to test.  Please send me any updates as I'm
 working on getting the patch applied now.  We have been running a
 fairly old kernel (2.6.39), but could run any version you recommend.

 This patch applied cleanly to the 2.6.39 tree I'm using, so I'm
 running an overnight test with it now.  Will report back later.

It ran overnight without any USB problems.  Continuing to test ...

Thanks,
Cliff

-- 
=
http://bec-systems.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] ARM: smp: Allow real broadcast device selection instead of always dummy

2013-03-13 Thread Mark Rutland

On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote:
On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote:
Hi Santosh,

On Wed, Mar 13, 2013 at 09:28:22AM +, Santosh Shilimkar wrote:
(Forgot to CC Thomas)

On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
With recent arm broadcast time clean-up from Mark Rutland, the dummy
broadcast device is always registered with timer subsystem. And since
the rating of the dummy clock event is very high, it is preferred
over a real broad-cast clock event.

This is a change in behavior from past and not an intended
one. So reduce the rating of the dummy clockevent so that
real broadcast device is selected when available.

Without this all the C states with C3STOP won't work since
the broad cast notifier will take an abort.

Cc: Mark Rutland mark.rutl...@arm.com
Cc: Russell King li...@arm.linux.org.uk

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Its a regression so hopefully can get into the 3.9-rcx. Noticed
this one on A15 platform. A9 platform the issue may not be seen
since the local timer check avoids dummy timer registration.

Some one pointed me to a fix made by Mark which was discussed
under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
That patch seems to be more of work around since the root of the
problem is incorrect dummy timer rating. Either way, both patches
fix the issue.

Is the problem that the dummy timer is being registered as the broadcast
source, or that it is selected as a local timer in preference of real
timers?

Dummy timer is preferred over real broadcast timer.

Ok.

If it is the former, Then I believe my patch solve the issue more generally
-
if you happen to register a dummy timer before other timers, it will become
the
broadcast source. Regardless of how temporary this is, it should never
happen,
and lowering the rating of the dummy won't fix this.

Well by the time we need active broadcast functionality, clock-events are
already chosen if the ratings are appropriate.

That's a fair point. I still think it's worth having the check in the core
broadcast code - rejecting dummy timers is always a sensible thing to do, and
it prevents future crashes if new timers are added without sensible rating
values.

If it is the latter, then this patch would ensure that a real timer with a
rating over 100 is selected in preference to the dummy, which is certainly
what
we want. The proposed generic dummy timer in Stephen Boyd's local timer API
removal series [1] similarly uses a low rating to ensure that real timers
are
selected in preference to an always-registered dummy. I note that the
architected timer has a higher rating (450) than the dummy (400), so this
shouldn't currently be a problem.

Because we always register dummy broadcast on ARM now
and with higher rating, it is picked as broadcast source. We definitely don't
want such a behavior when we have real broadcast device is available.

Agreed. We *never* want to pick a dummy timer as a broadcast source, as this
never makes sense.

With your patch, we are trying to avoid the registration which goes
against the the whole idea of registering it always and picking
the right clock-event based on rating by clock-event core.
The clock-event core except the proper ratings to be provided based on
the capability of the timer source and its resolution and in that case
dummy should have the lowest rating which is what I tried to patch.

Have I missed something?

Not much. I was just looking at x86 code as well after your email
to see how the LAPIC issue is handled. They seems to also have
correct rating to take care of the selection.

Probably we can merge both the fixes but from clock-event core
code perspective, the ratings fix is more than enough.

I do agree it'd be worth lowering the dummy timer's rating to ensure it doesn't
override a real timer elsewhere.

Thomas has already pulled my fix into tip timers/urgent [1].

[1]
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/urgentid=a7dc19b8652c862d5b7c4d2339bd3c428bd29c4a

Thanks,
Mark.
--
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: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'

2013-03-13 Thread Lokesh Vutla


Hi Dietmar,
On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:

On 13/03/13 06:52, Lokesh Vutla wrote:

Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
self-hosted
debug} introduces debug powerdown support for self-hosted debug.
While merging the patch 'has_ossr' check was removed which
was needed for hardwares which doesn't support self-hosted debug.
Pandaboard (A9) is one such hardware and Dietmar's orginial
patch did mention this issue.
Without that check on Panda with CPUIDLE enabled, a flood of
below messages thrown.

[ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch
[ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch



Hi Lokesh,

I confirm that this has_ossr condition has to go back into the
pm_init(void) call. I just verified it again on my Panda board and I get
the same issue like you without it.

I guess what was happening is that Will asked me if this check is really
necessary and I said No without re-testing on my Panda board as an V7
debug architecture example where OSSR is not implemented. Since then I
only tested in on V7.1 debug architectures where OSSR is mandatory.
Sorry about this and thanks for catching this.

Thanks for confirming..:)

Regards,
Lokesh



You can add my Acked-by: if you wish.

-- Dietmar


So restore that check back to avoid the mentioned issue.

Cc: Dietmar Eggemann dietmar.eggem...@arm.com
Cc: Will Deacon will.dea...@arm.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
  arch/arm/kernel/hw_breakpoint.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/hw_breakpoint.c
b/arch/arm/kernel/hw_breakpoint.c
index 96093b7..0ba062d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -1049,7 +1049,8 @@ static struct notifier_block __cpuinitdata
dbg_cpu_pm_nb = {

  static void __init pm_init(void)
  {
- cpu_pm_register_notifier(dbg_cpu_pm_nb);
+ if (has_ossr)
+ cpu_pm_register_notifier(dbg_cpu_pm_nb);
  }
  #else
  static inline void pm_init(void)



-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium.  Thank you.



--
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 v3 12/13] USB: ehci-omap: Fix detection in HSIC mode

Move PHY initialization until after EHCI initialization is
complete, instead of initializing the PHYs first, shutting
them down again, and then initializing them a second time.

This fixes HSIC device detection.

Signed-off-by: Roger Quadros rog...@ti.com
CC: Alan Stern st...@rowland.harvard.edu
---
 drivers/usb/host/ehci-omap.c |   32 +++-
 1 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 1ba1df8..755b428 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -90,26 +90,13 @@ static inline u32 ehci_read(void __iomem *base, u32 reg)
 static int omap_ehci_init(struct usb_hcd *hcd)
 {
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
-   struct omap_hcd *omap = (struct omap_hcd *)ehci-priv;
-   int rc, i;
-
-   /* Hold PHYs in reset while initializing EHCI controller */
-   for (i = 0; i  omap-nports; i++) {
-   if (omap-phy[i])
-   usb_phy_shutdown(omap-phy[i]);
-   }
+   int rc;
 
/* we know this is the memory we want, no need to ioremap again */
ehci-caps = hcd-regs;
 
rc = ehci_setup(hcd);
 
-   /* Bring PHYs out of reset */
-   for (i = 0; i  omap-nports; i++) {
-   if (omap-phy[i])
-   usb_phy_init(omap-phy[i]);
-   }
-
return rc;
 }
 
@@ -219,9 +206,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
}
 
omap-phy[i] = phy;
-   usb_phy_init(omap-phy[i]);
-   /* bring PHY out of suspend */
-   usb_phy_set_suspend(omap-phy[i], 0);
}
 
pm_runtime_enable(dev);
@@ -245,6 +229,20 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
goto err_pm_runtime;
}
 
+   /*
+* Bring PHYs out of reset.
+* Even though HSIC mode is a PHY-less mode, the reset
+* line exists between the chips and can be modelled
+* as a PHY device for reset control.
+*/
+   for (i = 0; i  omap-nports; i++) {
+   if (!omap-phy[i])
+   continue;
+
+   usb_phy_init(omap-phy[i]);
+   /* bring PHY out of suspend */
+   usb_phy_set_suspend(omap-phy[i], 0);
+   }
 
return 0;
 
-- 
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

Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

On 03/12/2013 06:40 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130312 04:47]:
 Hi Tony,

 These patches provide the SoC side code required to support
 the changes in the OMAP USB Host drivers done in [1], [2]  [3].
 ... 
 
  arch/arm/mach-omap2/board-3430sdp.c|   97 +++-
  arch/arm/mach-omap2/board-3630sdp.c|  100 +++-
  arch/arm/mach-omap2/board-am3517crane.c|   95 +--
  arch/arm/mach-omap2/board-am3517evm.c  |   66 ++-
  arch/arm/mach-omap2/board-cm-t35.c |   95 ++-
  arch/arm/mach-omap2/board-cm-t3517.c   |   97 +++-
  arch/arm/mach-omap2/board-devkit8000.c |   20 ++--
  arch/arm/mach-omap2/board-generic.c|   67 +++
  arch/arm/mach-omap2/board-igep0020.c   |  112 
 ---
  arch/arm/mach-omap2/board-omap3beagle.c|   93 +--
  arch/arm/mach-omap2/board-omap3evm.c   |   62 --
  arch/arm/mach-omap2/board-omap3pandora.c   |   52 +++--
  arch/arm/mach-omap2/board-omap3stalker.c   |   52 +++-
  arch/arm/mach-omap2/board-omap3touchbook.c |   62 +-
  arch/arm/mach-omap2/board-omap4panda.c |  122 
 ++--
  arch/arm/mach-omap2/board-overo.c  |   54 -
  arch/arm/mach-omap2/board-zoom.c   |   56 -
 
 Can't you have some mach-omap2/ehci-common.c that takes care
 of the initializiation to avoid this much addition to the
 board-*.c files? You may be able to have just a common function
 to do it and pass few parameters?

Since we moved reset and power handling for the USB PHYs from omap-echi
driver into the USB PHY driver we need to define the regulator data
for RESET and Power line of each PHY. So most of the code added is just
regulator data for the PHY rather than omap-ehci.

Instead of a common function, I can implement some macros that make it
easier to define the regulators for the PHY in the board files.
Does this sound OK?

Personally I don't like such macros because it hides the implementation
and is difficult to read/debug.

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: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy

2013-03-13 Thread Thomas Gleixner

On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
 On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
  With recent arm broadcast time clean-up from Mark Rutland, the dummy
  broadcast device is always registered with timer subsystem. And since
  the rating of the dummy clock event is very high, it is preferred
  over a real broad-cast clock event.
  
  This is a change in behavior from past and not an intended
  one. So reduce the rating of the dummy clockevent so that
  real broadcast device is selected when available.
  
  Without this all the C states with C3STOP won't work since
  the broad cast notifier will take an abort.
  
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Russell King li...@arm.linux.org.uk
  
  Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
  ---
  Its a regression so hopefully can get into the 3.9-rcx. Noticed
  this one on A15 platform. A9 platform the issue may not be seen
  since the local timer check avoids dummy timer registration.
  
 Some one pointed me to a fix made by Mark which was discussed
 under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
 That patch seems to be more of work around since the root of the
 problem is incorrect dummy timer rating. Either way, both patches
 fix the issue.

Well, using a dummy timer as the broadcast event device is a bug, no
matter what the rating is. The fix is in Linus tree already.

Though making the rating of the dummy lower is definitely a good
thing, so a real hardware device which is detected later can replace
the dummy device. So yes, the rating should be low for the dummy
timer.

Thanks,

tglx
--
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 12/13] USB: ehci-omap: Fix detection in HSIC mode

2013-03-13 Thread Alan Stern

On Wed, 13 Mar 2013, Roger Quadros wrote:

 Move PHY initialization until after EHCI initialization is
 complete, instead of initializing the PHYs first, shutting
 them down again, and then initializing them a second time.
 
 This fixes HSIC device detection.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 CC: Alan Stern st...@rowland.harvard.edu

Acked-by: Alan Stern st...@rowland.harvard.edu

--
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 13/13] USB: ehci-omap: Get rid of omap_ehci_init()

2013-03-13 Thread Alan Stern

On Wed, 13 Mar 2013, Roger Quadros wrote:

 As it does almost nothing, get rid of omap_ehci_init()
 and move the ehci-caps initialization part into probe().
 
 Also remove the outdated TODO list from header.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 CC: Alan Stern st...@rowland.harvard.edu

Acked-by: Alan Stern st...@rowland.harvard.edu

--
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/8] usb: phy: nop: Add some parameters to platform data

On 03/12/2013 04:20 PM, Roger Quadros wrote:
 Adding Peter to the loop. I faintly remember him mentioning this issue before
 for beagle. We really need the deferred probe mechanism or we need to resort
 to device registering order.

Yes, BeagleBoard is a good example. Long story short: we have external
dependency and the correct way to handle that is via deferred probe.

As of now we are not ready to kill the legacy support but over time we should
move as much as we can to DT only mode.

 The first user for needs_vcc flag will be the beagleboard file. I just didn't
 implement it in this patch [1].
 
 On second thoughts, since [1] does work on beagleboard without requiring the
 needs_vcc flag, I think we can just live without it.

The BeagleBoard works because the bootloader happen to enable the PWM
generator which is used as a GPIO for the external HUB enable port. As soon as
the bootloader stops doing this we are going to be in trouble.

 
 Felipe, Peter, what do you think?
 
 cheers,
 -roger
 
 [1] https://lkml.org/lkml/2013/3/12/244
 


-- 
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] ARM: smp: Allow real broadcast device selection instead of always dummy

On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote:
 On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
 On Wednesday 13 March 2013 02:36 PM, Santosh Shilimkar wrote:
 With recent arm broadcast time clean-up from Mark Rutland, the dummy
 broadcast device is always registered with timer subsystem. And since
 the rating of the dummy clock event is very high, it is preferred
 over a real broad-cast clock event.

 This is a change in behavior from past and not an intended
 one. So reduce the rating of the dummy clockevent so that
 real broadcast device is selected when available.

 Without this all the C states with C3STOP won't work since
 the broad cast notifier will take an abort.

 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Russell King li...@arm.linux.org.uk

 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
 Its a regression so hopefully can get into the 3.9-rcx. Noticed
 this one on A15 platform. A9 platform the issue may not be seen
 since the local timer check avoids dummy timer registration.

 Some one pointed me to a fix made by Mark which was discussed
 under '[BUG] ARM Architected timers appear broken in 3.9-rc1' subject.
 That patch seems to be more of work around since the root of the
 problem is incorrect dummy timer rating. Either way, both patches
 fix the issue.
 
 Well, using a dummy timer as the broadcast event device is a bug, no
 matter what the rating is. The fix is in Linus tree already.

Agree.
 
 Though making the rating of the dummy lower is definitely a good
 thing, so a real hardware device which is detected later can replace
 the dummy device. So yes, the rating should be low for the dummy
 timer.
 
Exactly. As Mark pointed out, you have already applied Mark's patch.
I was just wondering whether you can take the $subject patch as well
with ack from Russell, Mark.

Regards,
Santosh

--
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: dts: OMAP2+: Add SDMA controller bindings and nodes

Salut Jon,

On 03/12/2013 10:43 PM, Jon Hunter wrote:
 Salut Benoit!
 
 On 03/12/2013 06:00 AM, Benoit Cousson wrote:
 + Seb G.

 Hi Jon,

 How to you plan to merge that series?
 
 Good question ... my thinking was that you or Tony would take 1/2 and
 once that is queued then I would ask Tony to ack 2/2 and Vinod take that
 patch.

Yep, this is what I was thinking too.

 By the way, I have accumulated several DT patches which I sent out
 altogether [1] (at least for my own sanity if no one elses ;-) and I
 have included the below patch with it. I was hoping that may be I could
 create a branch for you to pull. If you would rather cherry-pick the
 various patches and merge yourself then I can separate them too.

Merging your branch is indeed even better for me. So go ahead.

Thanks,
Benoit

 
 Seb's just posted a McBSP adaptation to SDMA binding, so I'll have to
 take this one before being able to merge any other SDMA driver
 adaptation patches.

 I'm fine to take that one, if you are OK, to avoid merge conflict in DTS
 later.
 
 Fine with me and that would be preferred. I don't see any downside in
 taking this one and then having Vinod take the other later.


 
 On 02/26/2013 07:27 PM, Jon Hunter wrote:
 Add SDMA controller binding for OMAP2+ devices and populate DMA client
 information for SPI and MMC periperhal on OMAP3+ devices. Please note

 typo---^
 
 Thanks! Will fix.
 
 that OMAP24xx devices do not have SPI and MMC bindings available yet and
 so DMA client information is not populated.

 Signed-off-by: Jon Hunter jon-hun...@ti.com
 Reviewed-by: Felipe Balbi ba...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Tested-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  .../devicetree/bindings/dma/omap-sdma.txt  |   51 
 

 That's a detail, but the bindings should be introduced along with the
 driver DT adaptation since it does represent its interface.
 
 Ok, I can add that to patch 2/2 instead.
 
  arch/arm/boot/dts/omap2.dtsi   |   12 +
  arch/arm/boot/dts/omap3.dtsi   |   40 +++
  arch/arm/boot/dts/omap4.dtsi   |   41 
  arch/arm/boot/dts/omap5.dtsi   |   41 
  5 files changed, 185 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt

 diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt 
 b/Documentation/devicetree/bindings/dma/omap-sdma.txt
 new file mode 100644
 index 000..22aab28
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
 @@ -0,0 +1,51 @@
 +* TI OMAP SDMA controller
 +
 +Required properties:
 +- compatible:  Should be set to one of the following:
 +
 +   ti,omap2420-sdma (omap2420)
 +   ti,omap2430-sdma (omap2430)
 +   ti,omap3430-sdma (omap3430)
 +   ti,omap3630-sdma (omap3630)
 +   ti,omap4430-sdma (omap4430  omap4460  omap543x)
 +
 +- reg: Contains DMA registers location and length.
 +- interrupts:  Contains DMA interrupt information.
 +- #dma-cells:  Must be 1.
 +- #dma-channels:   Contains total number of programmable DMA channels.
 +- #dma-requests:   Contains total number of DMA requests.
 +
 +Example:
 +
 +   sdma: dma-controller@4A056000 {
 +   compatible = ti,omap-sdma;
 +   reg = 0x4A056000 0x1000;


 Nit: you do have several hexa values in upper case, here and in some dts
 as well.
 
 Yes will fix that too.
 
 Cheers
 Jon
 
 [1]
 http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg28050.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: smp: Allow real broadcast device selection instead of always dummy

On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
 On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote:
 On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote:
 Hi Santosh,

[..]


 Is the problem that the dummy timer is being registered as the broadcast
 source, or that it is selected as a local timer in preference of real 
 timers?

 Dummy timer is preferred over real broadcast timer.
 
 Ok.
 
  
 If it is the former, Then I believe my patch solve the issue more generally 
 -
 if you happen to register a dummy timer before other timers, it will become 
 the
 broadcast source. Regardless of how temporary this is, it should never 
 happen,
 and lowering the rating of the dummy won't fix this.

 Well by the time we need active broadcast functionality, clock-events are
 already chosen if the ratings are appropriate.
 
 That's a fair point. I still think it's worth having the check in the core
 broadcast code - rejecting dummy timers is always a sensible thing to do, and
 it prevents future crashes if new timers are added without sensible rating
 values.
 

 If it is the latter, then this patch would ensure that a real timer with a
 rating over 100 is selected in preference to the dummy, which is certainly 
 what
 we want. The proposed generic dummy timer in Stephen Boyd's local timer API
 removal series [1] similarly uses a low rating to ensure that real timers 
 are
 selected in preference to an always-registered dummy. I note that the
 architected timer has a higher rating (450) than the dummy (400), so this
 shouldn't currently be a problem.

 Because we always register dummy broadcast on ARM now 
 and with higher rating, it is picked as broadcast source. We definitely don't
 want such a behavior when we have real broadcast device is available.
 
 Agreed. We *never* want to pick a dummy timer as a broadcast source, as this
 never makes sense.
 
 With your patch, we are trying to avoid the registration which goes
 against the the whole idea of registering it always and picking
 the right clock-event based on rating by clock-event core.
 The clock-event core except the proper ratings to be provided based on
 the capability of the timer source and its resolution and in that case
 dummy should have the lowest rating which is what I tried to patch.

 Have I missed something?

 Not much. I was just looking at x86 code as well after your email
 to see how the LAPIC issue is handled. They seems to also have
 correct rating to take care of the selection.

 Probably we can merge both the fixes but from clock-event core
 code perspective, the ratings fix is more than enough.
 
 I do agree it'd be worth lowering the dummy timer's rating to ensure it 
 doesn't
 override a real timer elsewhere. 
 
Yep. Can I add you acked-by tag then for $subject patch ?
Would be good to get this one merged as well.

Regards
Santosh

--
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/8] usb: phy: nop: Add some parameters to platform data

On 03/13/2013 05:17 PM, Peter Ujfalusi wrote:
 On 03/12/2013 04:20 PM, Roger Quadros wrote:
 Adding Peter to the loop. I faintly remember him mentioning this issue before
 for beagle. We really need the deferred probe mechanism or we need to resort
 to device registering order.
 
 Yes, BeagleBoard is a good example. Long story short: we have external
 dependency and the correct way to handle that is via deferred probe.
 
 As of now we are not ready to kill the legacy support but over time we should
 move as much as we can to DT only mode.
 
 The first user for needs_vcc flag will be the beagleboard file. I just didn't
 implement it in this patch [1].

 On second thoughts, since [1] does work on beagleboard without requiring the
 needs_vcc flag, I think we can just live without it.
 
 The BeagleBoard works because the bootloader happen to enable the PWM
 generator which is used as a GPIO for the external HUB enable port. As soon as
 the bootloader stops doing this we are going to be in trouble.
 

Wasn't it the LED A out GPO from PMIC that is used to enable the HUB? Just cross
checking so I haven't missed anything.

I will resend the board support patch for beagle implementing
needs_vcc flag for the deferred probe mechanism. Thanks.

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: [PATCH 1/8] usb: phy: nop: Add some parameters to platform data

2013-03-13 Thread Marc Kleine-Budde

On 03/13/2013 04:17 PM, Peter Ujfalusi wrote:
 On 03/12/2013 04:20 PM, Roger Quadros wrote:
 Adding Peter to the loop. I faintly remember him mentioning this issue before
 for beagle. We really need the deferred probe mechanism or we need to resort
 to device registering order.
 
 Yes, BeagleBoard is a good example. Long story short: we have external
 dependency and the correct way to handle that is via deferred probe.

Sure.

 As of now we are not ready to kill the legacy support but over time we should
 move as much as we can to DT only mode.

I was assuming you're already on DT only :)

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V3 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes

On 03/13/2013 04:50 PM, Jon Hunter wrote:
 
 On 03/13/2013 10:35 AM, Benoit Cousson wrote:
 Salut Jon,

 On 03/12/2013 10:43 PM, Jon Hunter wrote:
 Salut Benoit!

 On 03/12/2013 06:00 AM, Benoit Cousson wrote:
 + Seb G.

 Hi Jon,

 How to you plan to merge that series?

 Good question ... my thinking was that you or Tony would take 1/2 and
 once that is queued then I would ask Tony to ack 2/2 and Vinod take that
 patch.

 Yep, this is what I was thinking too.

 By the way, I have accumulated several DT patches which I sent out
 altogether [1] (at least for my own sanity if no one elses ;-) and I
 have included the below patch with it. I was hoping that may be I could
 create a branch for you to pull. If you would rather cherry-pick the
 various patches and merge yourself then I can separate them too.

 Merging your branch is indeed even better for me. So go ahead.
 
 Ok. Care to take a quick review to see if there is anything else you
 feel needs fixing before I re-submit fixing the commments posted so far?

OK, I will.

 Do you have an updated branch for v3.10 that I should base on?

Yep, I've just pushed the old one rebased on top of 3.9-rc2.

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts


Regards,
Benoit


--
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: omap4 pandaboard: clock input for TiWi module inactive

2013-03-13 Thread Levi Pearson

On Wed, Mar 13, 2013 at 2:29 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 On 03/12/2013 05:33 PM, Levi Pearson wrote:
 I spent some more time looking at clk-twl6030.c, and it seems it just turns 
 the
 twl6030 chip on when you ask it to enable the clock, and as far as I
 can tell that
 happens based on module dependencies?  There aren't any explicit references 
 to
 it that I can find, so I'm not entirely sure how a clk-twl6040 would
 cause a clock
 to be enabled.

 The clk-twl6040 is not really a good example for you start with. We only need
 it to turn on in order to get the clock on the output. But the principle is
 the same at the end. you need to enable/disable the clock from twl6030...


Well, it's at least a nice minimal example of how to interface with the clk API.

 I looked into the early boot clock setup code, and that does look a lot less
 straightforward.

 Yes, this is what I thought for the twl6040 clock integration with McPDM. It
 turned out a bit more complicated.
 At boot time you do not have the twl clock driver loaded.
 You have the clock tree already defined.
 When you boot further you add the clock for twl6040.

I can't see where exactly this is done, though.  I think I'm just
going to have to
poke around the clock trees for other platforms or something to see how it's
normally done, but unfortunately my time to work on this is pretty limited too!

 You want to hook it up with the existing clock tree - to set it as parent of
 one of the clock root (which you already modified to not to be the root 
 clock).
 I shall work, but it does not:
 for external chips we need to do the configuration/enable in clk_prepare time
 (because they are over i2c).
 So the driver goes and asks for a clock (which supposed to be at the end
 rooted to this new external clock).
 Nothing happens.
 The relevant clock tree has been already got prepared earlier so new prepare
 will not going to go down to the root, leaving the root clock disabled.

 I'm still looking a way to somehow fix this, but my time is limited right now.

Is it possible to do static config on the clocks to create the basic
structure during
the early boot phase, and then add the dynamic control functions to
the structure
later after i2c has been set up?  See below for more details, but TWL6030 is the
parent of all 32k clocks on the board, it just enables some of them by
default when
it's powered on.  Seems like that should be reflected in the early set
up structure.

 There are already a few 32k clocks listed there, and
 I *think* they
 all source from the twl6040; do they just come up automatically at power-on?
 From what I can tell, clk32kg is just a gated fork of the regular 32k
 clock that is
 available at boot from twl6040.  I am surprised it doesn't come on by 
 default.

 I have not checked the schematics, but it could be that we have crystal 32K on
 board as well. TWL6030 can gate some of it's 32K outputs and this is the case
 with WiLink on PandaBoard.

There is a crystal 32k; it's connected directly to TWL6030 via OSC32KIN and
OSC32KOUT.  There are also 3 gated outputs:
  * CLK32K_AUD  - this goes to TWL6040 as the CLK32K input of its PLL block
  * CLK32K_MAIN  - this goes to OMAP4430's SYS32K input
  * CLK32K_GATE  - this is goes to WL172x chip's SLOW_CLK input

And those are all the 32k clocks on the board.  No one gets a 32k clock except
through TWL6030, though I guess there may be some internal 32k clock gating
inside the OMAP. The question in the back of my mind is why CLK32K_AUD and
CLK32K_MAIN are enabled by default in the power modes we use but
CLK32K_GATE is not.  Or... maybe it is and we are specifically disabling it
somewhere?

 I also don't have a TRM for twl6040 that matches up with what 
 twl-regulator.c is
 doing to enable the clk32kg output; it looks like it's adding it to
 one of the power
 modes, but I'm not entirely sure how the registers it's writing to work, so 
 my
 confidence level in being able to get it transplanted to a separate
 driver has lowered
 quite a bit.

 I'm not sure if I have twl6030 TRM either, but I can try to come up with a
 basic driver for the twl6030 clocks.

I actually found a TRM for it on google, but the register addresses in
the code don't
seem to match up with what's documented in the TRM I have.  Wouldn't
be the first
time that external docs didn't list all the registers

---

 --Levi
--
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: smp: Allow real broadcast device selection instead of always dummy

2013-03-13 Thread Mark Rutland

On Wed, Mar 13, 2013 at 03:44:03PM +, Santosh Shilimkar wrote:
 On Wednesday 13 March 2013 05:55 PM, Mark Rutland wrote:
  On Wed, Mar 13, 2013 at 11:24:01AM +, Santosh Shilimkar wrote:
  On Wednesday 13 March 2013 03:46 PM, Mark Rutland wrote:
  Hi Santosh,
 
 [..]
 
 
  Is the problem that the dummy timer is being registered as the broadcast
  source, or that it is selected as a local timer in preference of real 
  timers?
 
  Dummy timer is preferred over real broadcast timer.
  
  Ok.

[...]

  I do agree it'd be worth lowering the dummy timer's rating to ensure it 
  doesn't
  override a real timer elsewhere. 
  
 Yep. Can I add you acked-by tag then for $subject patch ?
 Would be good to get this one merged as well.

Sure. Though could you reword the commit message? The patch solves the more
general issue of a dummy being preferred over real hardware even outside of
choosing the broadcast device.

Acked-by: Mark Rutland mark.rutl...@arm.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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

2013-03-13 Thread Tony Lindgren

* Roger Quadros rog...@ti.com [130313 06:46]:
 On 03/12/2013 06:40 PM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [130312 04:47]:
  Hi Tony,
 
  These patches provide the SoC side code required to support
  the changes in the OMAP USB Host drivers done in [1], [2]  [3].
  ... 
  
   arch/arm/mach-omap2/board-3430sdp.c|   97 +++-
   arch/arm/mach-omap2/board-3630sdp.c|  100 +++-
   arch/arm/mach-omap2/board-am3517crane.c|   95 +--
   arch/arm/mach-omap2/board-am3517evm.c  |   66 ++-
   arch/arm/mach-omap2/board-cm-t35.c |   95 ++-
   arch/arm/mach-omap2/board-cm-t3517.c   |   97 +++-
   arch/arm/mach-omap2/board-devkit8000.c |   20 ++--
   arch/arm/mach-omap2/board-generic.c|   67 +++
   arch/arm/mach-omap2/board-igep0020.c   |  112 
  ---
   arch/arm/mach-omap2/board-omap3beagle.c|   93 +--
   arch/arm/mach-omap2/board-omap3evm.c   |   62 --
   arch/arm/mach-omap2/board-omap3pandora.c   |   52 +++--
   arch/arm/mach-omap2/board-omap3stalker.c   |   52 +++-
   arch/arm/mach-omap2/board-omap3touchbook.c |   62 +-
   arch/arm/mach-omap2/board-omap4panda.c |  122 
  ++--
   arch/arm/mach-omap2/board-overo.c  |   54 -
   arch/arm/mach-omap2/board-zoom.c   |   56 -
  
  Can't you have some mach-omap2/ehci-common.c that takes care
  of the initializiation to avoid this much addition to the
  board-*.c files? You may be able to have just a common function
  to do it and pass few parameters?
 
 Since we moved reset and power handling for the USB PHYs from omap-echi
 driver into the USB PHY driver we need to define the regulator data
 for RESET and Power line of each PHY. So most of the code added is just
 regulator data for the PHY rather than omap-ehci.

It seems that you're now repeating minor variations of the same PHY
over and over again though.
 
 Instead of a common function, I can implement some macros that make it
 easier to define the regulators for the PHY in the board files.
 Does this sound OK?
 
 Personally I don't like such macros because it hides the implementation
 and is difficult to read/debug.

I'd prefer a common function to initialize the PHY though as it sounds
like using macros would just allocate similar PHY many times which seems
unnecessary.

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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

On 03/13/2013 06:24 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130313 06:46]:
 On 03/12/2013 06:40 PM, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [130312 04:47]:
 Hi Tony,

 These patches provide the SoC side code required to support
 the changes in the OMAP USB Host drivers done in [1], [2]  [3].
 ... 

  arch/arm/mach-omap2/board-3430sdp.c|   97 +++-
  arch/arm/mach-omap2/board-3630sdp.c|  100 +++-
  arch/arm/mach-omap2/board-am3517crane.c|   95 +--
  arch/arm/mach-omap2/board-am3517evm.c  |   66 ++-
  arch/arm/mach-omap2/board-cm-t35.c |   95 ++-
  arch/arm/mach-omap2/board-cm-t3517.c   |   97 +++-
  arch/arm/mach-omap2/board-devkit8000.c |   20 ++--
  arch/arm/mach-omap2/board-generic.c|   67 +++
  arch/arm/mach-omap2/board-igep0020.c   |  112 
 ---
  arch/arm/mach-omap2/board-omap3beagle.c|   93 +--
  arch/arm/mach-omap2/board-omap3evm.c   |   62 --
  arch/arm/mach-omap2/board-omap3pandora.c   |   52 +++--
  arch/arm/mach-omap2/board-omap3stalker.c   |   52 +++-
  arch/arm/mach-omap2/board-omap3touchbook.c |   62 +-
  arch/arm/mach-omap2/board-omap4panda.c |  122 
 ++--
  arch/arm/mach-omap2/board-overo.c  |   54 -
  arch/arm/mach-omap2/board-zoom.c   |   56 -

 Can't you have some mach-omap2/ehci-common.c that takes care
 of the initializiation to avoid this much addition to the
 board-*.c files? You may be able to have just a common function
 to do it and pass few parameters?

 Since we moved reset and power handling for the USB PHYs from omap-echi
 driver into the USB PHY driver we need to define the regulator data
 for RESET and Power line of each PHY. So most of the code added is just
 regulator data for the PHY rather than omap-ehci.
 
 It seems that you're now repeating minor variations of the same PHY
 over and over again though.

Yes it is the vcc and reset regulator data for the PHY that
is getting repeated with variations in the GPIO number.

  
 Instead of a common function, I can implement some macros that make it
 easier to define the regulators for the PHY in the board files.
 Does this sound OK?

 Personally I don't like such macros because it hides the implementation
 and is difficult to read/debug.
 
 I'd prefer a common function to initialize the PHY though as it sounds
 like using macros would just allocate similar PHY many times which seems
 unnecessary.
 
OK, so we want to create the regulator data at runtime to save some memory?
I'll come up with something.

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: [PATCH] arm: dts: Add uart1 and uart2 to igep boards.

Hi Javier,

On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
 On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
 Hi Matthias,


 On 2/15/2013 10:35 AM, Matthias Brugger wrote:

 2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:

 On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
 matthias@gmail.com
 wrote:

 Hi Benoit,

 2012/12/12 Benoit Cousson b-cous...@ti.com:

 Hi Matthias,

 On 12/12/2012 04:33 PM, Matthias Brugger wrote:

 This patch is a follow-up patch for Javier Martinez effort adding
 initial
 device tree support to IGEP technology devices. [1]

 It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
 boards.

 [1] http://www.spinics.net/lists/linux-omap/msg83409.html

 Signed-off-by: Matthias Brugger matthias@gmail.com
 ---
   arch/arm/boot/dts/omap3-igep.dtsi |   24 
   1 file changed, 24 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 125fe00..c02e3c0 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -27,6 +27,20 @@
   };

   omap3_pmx_core {
 + uart1_pins: pinmux_uart1_pins {
 + pinctrl-single,pins = 
 + 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
 MODE0
 */
 + 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
 MODE0 */
 + ;
 + };
 +
 + uart2_pins: pinmux_uart2_pins {
 + pinctrl-single,pins = 
 + 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
 MODE0
 */
 + 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
 MODE0 */
 + ;
 + };
 +
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = 
0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
 MODE0
 */
 @@ -77,6 +91,16 @@
status = disabled;
   };

 +uart1 {
 +   pinctrl-names = default;
 +   pinctrl-0 = uart1_pins;
 +};
 +
 +uart2 {
 +   pinctrl-names = default;
 +   pinctrl-0 = uart2_pins;
 +};
 +
   uart3 {
  pinctrl-names = default;
  pinctrl-0 = uart3_pins;


 That looks good to me. I'll apply it on top of javier's series for 3.9.


 Can you pin-point me to the repository where this patches are in right
 now? I tried to figure it out these days, but didn't found where to
 clone the repository from.

 Thanks,
 Matthias


 Hi Matthias,

 OMAP DT tree is:
 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git


 Hi all,

 unfortunately I can't find the patch in this tree.


 Sorry about that. I've never pushed the latest branch, and was busy the past
 month. I'll refresh the branch with all the pending patches.

 Regards,
 Benoit

 
 Hi Benoit,
 
 I realized that your for_3.9/dts branch has not landed in mainline yet
 and we are near to the end of the merge window.
 
 Are you still planing to include those changes for 3.9 or are you
 going to wait until the next release?

I'm really sorry about that. I was not available to push it at the proper time.

I've just rebased it on 3.9-rc2 and pushed it to a new branch.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts

It includes the one from Matthias and yours as well. I'm still checking my 
inbox to catch up on the new ones I missed.

I'm planning to push this ASAP to avoid missing the deadline again.


Regards,
Benoit
--
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: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data

Hi Sourav,

I've just applied your branch after a minor subject cleanup for consistency.

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts

Regards,
Benoit


On 03/11/2013 04:42 PM, Sourav Poddar wrote:
 On Monday 11 March 2013 08:02 PM, Benoit Cousson wrote:
 Hi Sourav,

 On 03/11/2013 02:44 PM, Sourav Poddar wrote:
 Hi Tony/Benoit,

 These patches had been sent couple of times before, but there were no
 comments on it.
 Sorry for that. I got a big flu in Jan and was in Linaro Connect last
 week.
 Patches look good, I just have to check that they apply nicely to the
 dts/for_3.9 I already prepared.

 Ok. Thanks!!
 I still have to rebase that branch on top of a recent master branch and
 then check your branch.

 If there are no comments, Can these be picked ?
 Cc: Andrew Mortona...@osdl.org

 The following changes since commit
 f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

 are available in the git repository at:
g...@gitorious.org:linux-connectivity/linux-connectivity.git
 omap_i2c_spi_dts_data

 Felipe Balbi (1):
arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file

 Sourav Poddar (4):
arm: dts: omap4-sdp: Add I2c pinctrl data
arm: dts: omap5-evm: Add I2c pinctrl data
arm: dts: omap4-panda: Add I2c pinctrl data
arm: dts: omap5-evm: Add mcspi data
 Thanks,
 Benoit

 

--
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 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

2013-03-13 Thread Tony Lindgren

* Roger Quadros rog...@ti.com [130313 09:40]:
 On 03/13/2013 06:24 PM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [130313 06:46]:
  On 03/12/2013 06:40 PM, Tony Lindgren wrote:
  * Roger Quadros rog...@ti.com [130312 04:47]:
  Hi Tony,
 
  These patches provide the SoC side code required to support
  the changes in the OMAP USB Host drivers done in [1], [2]  [3].
  ... 
 
   arch/arm/mach-omap2/board-3430sdp.c|   97 
  +++-
   arch/arm/mach-omap2/board-3630sdp.c|  100 
  +++-
   arch/arm/mach-omap2/board-am3517crane.c|   95 
  +--
   arch/arm/mach-omap2/board-am3517evm.c  |   66 ++-
   arch/arm/mach-omap2/board-cm-t35.c |   95 
  ++-
   arch/arm/mach-omap2/board-cm-t3517.c   |   97 
  +++-
   arch/arm/mach-omap2/board-devkit8000.c |   20 ++--
   arch/arm/mach-omap2/board-generic.c|   67 +++
   arch/arm/mach-omap2/board-igep0020.c   |  112 
  ---
   arch/arm/mach-omap2/board-omap3beagle.c|   93 
  +--
   arch/arm/mach-omap2/board-omap3evm.c   |   62 --
   arch/arm/mach-omap2/board-omap3pandora.c   |   52 +++--
   arch/arm/mach-omap2/board-omap3stalker.c   |   52 +++-
   arch/arm/mach-omap2/board-omap3touchbook.c |   62 +-
   arch/arm/mach-omap2/board-omap4panda.c |  122 
  ++--
   arch/arm/mach-omap2/board-overo.c  |   54 -
   arch/arm/mach-omap2/board-zoom.c   |   56 -
 
  Can't you have some mach-omap2/ehci-common.c that takes care
  of the initializiation to avoid this much addition to the
  board-*.c files? You may be able to have just a common function
  to do it and pass few parameters?
 
  Since we moved reset and power handling for the USB PHYs from omap-echi
  driver into the USB PHY driver we need to define the regulator data
  for RESET and Power line of each PHY. So most of the code added is just
  regulator data for the PHY rather than omap-ehci.
  
  It seems that you're now repeating minor variations of the same PHY
  over and over again though.
 
 Yes it is the vcc and reset regulator data for the PHY that
 is getting repeated with variations in the GPIO number.
 
   
  Instead of a common function, I can implement some macros that make it
  easier to define the regulators for the PHY in the board files.
  Does this sound OK?
 
  Personally I don't like such macros because it hides the implementation
  and is difficult to read/debug.
  
  I'd prefer a common function to initialize the PHY though as it sounds
  like using macros would just allocate similar PHY many times which seems
  unnecessary.
  
 OK, so we want to create the regulator data at runtime to save some memory?
 I'll come up with something.

Or I guess you can have just one instance that gets filled in by some PHY
platform init function.

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 v2] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off

2013-03-13 Thread Kevin Hilman

Santosh Shilimkar santosh.shilim...@ti.com writes:

 Kevin,

 On Wednesday 13 February 2013 02:25 PM, Santosh Shilimkar wrote:
 Current CPU PM code code make use of common cpu_suspend() path for all the
 CPU power states which is not optimal. In fact cpu_suspend() path is needed
 only when we put CPU power domain to off state where the CPU context is lost.
 
 Update the code accordingly so that the expensive cpu_suspend() path
 can be avoided for the shallow CPU power states like CPU PD INA/CSWR.
 
 The patch has been tested on OMAP4430 and OMAP5430(with few out of tree 
 patches)
 devices for suspend and CPUidle.
 
 Cc: Kevin Hilman khil...@deeprootsystems.com
 
 Reported-by: Richard Woodruff r-woodru...@ti.com
 Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
 Update changelog to include testing details as suggested
 by Kevin Hilman.
 
 Ping.
 It can get into rc's but since it is not strict regression,
 and if it has to wait for 3.10 then I can add this one
 along with rest of the PM patches posted towards 3.10

 Either way, let me know.

I have this updated one queued for v3.10 in my PM cleanup branch
(for_3.10/cleanup/pm)

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] arm: dts: Add uart1 and uart2 to igep boards.

2013-03-13 Thread Javier Martinez Canillas

On Wed, Mar 13, 2013 at 5:41 PM, Benoit Cousson b-cous...@ti.com wrote:
 Hi Javier,

 On 03/02/2013 02:52 AM, Javier Martinez Canillas wrote:
 On Fri, Feb 15, 2013 at 11:03 AM, Cousson, Benoit b-cous...@ti.com wrote:
 Hi Matthias,


 On 2/15/2013 10:35 AM, Matthias Brugger wrote:

 2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:

 On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
 matthias@gmail.com
 wrote:

 Hi Benoit,

 2012/12/12 Benoit Cousson b-cous...@ti.com:

 Hi Matthias,

 On 12/12/2012 04:33 PM, Matthias Brugger wrote:

 This patch is a follow-up patch for Javier Martinez effort adding
 initial
 device tree support to IGEP technology devices. [1]

 It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
 boards.

 [1] http://www.spinics.net/lists/linux-omap/msg83409.html

 Signed-off-by: Matthias Brugger matthias@gmail.com
 ---
   arch/arm/boot/dts/omap3-igep.dtsi |   24 
   1 file changed, 24 insertions(+)

 diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
 b/arch/arm/boot/dts/omap3-igep.dtsi
 index 125fe00..c02e3c0 100644
 --- a/arch/arm/boot/dts/omap3-igep.dtsi
 +++ b/arch/arm/boot/dts/omap3-igep.dtsi
 @@ -27,6 +27,20 @@
   };

   omap3_pmx_core {
 + uart1_pins: pinmux_uart1_pins {
 + pinctrl-single,pins = 
 + 0x152 0x100 /* uart1_rx.uart1_rx INPUT |
 MODE0
 */
 + 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
 MODE0 */
 + ;
 + };
 +
 + uart2_pins: pinmux_uart2_pins {
 + pinctrl-single,pins = 
 + 0x14a 0x100 /* uart2_rx.uart2_rx INPUT |
 MODE0
 */
 + 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
 MODE0 */
 + ;
 + };
 +
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = 
0x16e 0x100 /* uart3_rx.uart3_rx INPUT |
 MODE0
 */
 @@ -77,6 +91,16 @@
status = disabled;
   };

 +uart1 {
 +   pinctrl-names = default;
 +   pinctrl-0 = uart1_pins;
 +};
 +
 +uart2 {
 +   pinctrl-names = default;
 +   pinctrl-0 = uart2_pins;
 +};
 +
   uart3 {
  pinctrl-names = default;
  pinctrl-0 = uart3_pins;


 That looks good to me. I'll apply it on top of javier's series for 3.9.


 Can you pin-point me to the repository where this patches are in right
 now? I tried to figure it out these days, but didn't found where to
 clone the repository from.

 Thanks,
 Matthias


 Hi Matthias,

 OMAP DT tree is:
 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git


 Hi all,

 unfortunately I can't find the patch in this tree.


 Sorry about that. I've never pushed the latest branch, and was busy the past
 month. I'll refresh the branch with all the pending patches.

 Regards,
 Benoit


 Hi Benoit,

 I realized that your for_3.9/dts branch has not landed in mainline yet
 and we are near to the end of the merge window.

 Are you still planing to include those changes for 3.9 or are you
 going to wait until the next release?

 I'm really sorry about that. I was not available to push it at the proper 
 time.


No worries, it was just a gentle remainder :-)

 I've just rebased it on 3.9-rc2 and pushed it to a new branch.
 git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
 for_3.10/dts

 It includes the one from Matthias and yours as well. I'm still checking my 
 inbox to catch up on the new ones I missed.

 I'm planning to push this ASAP to avoid missing the deadline again.


Great, thanks a lot for the information


 Regards,
 Benoit

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: [PATCHv3 03/14] mailbox: OMAP: introduce mailbox framework

2013-03-13 Thread Linus Walleij

On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna s-a...@ti.com wrote:

 From: Omar Ramirez Luna omar.l...@linaro.org
(...)

 Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
 [s-a...@ti.com: Kconfig fixes for build errors]
 Signed-off-by: Suman Anna s-a...@ti.com
 Acked-by: Tony Lindgren t...@atomide.com
 Signed-off-by: Linus Walleij linus.wall...@linaro.org

It's not like I care super-much, but I think your SoB should
be at the bottom.

It's a simple git rebase -i anyway...

Yours,
Linus Walleij
--
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: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data

2013-03-13 Thread Sourav Poddar



On Wednesday 13 March 2013 10:16 PM, Benoit Cousson wrote:

Hi Sourav,

I've just applied your branch after a minor subject cleanup for consistency.

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts


Thanks Benoit!

Regards,
Benoit


On 03/11/2013 04:42 PM, Sourav Poddar wrote:

On Monday 11 March 2013 08:02 PM, Benoit Cousson wrote:

Hi Sourav,

On 03/11/2013 02:44 PM, Sourav Poddar wrote:

Hi Tony/Benoit,

These patches had been sent couple of times before, but there were no
comments on it.

Sorry for that. I got a big flu in Jan and was in Linaro Connect last
week.
Patches look good, I just have to check that they apply nicely to the
dts/for_3.9 I already prepared.


Ok. Thanks!!

I still have to rebase that branch on top of a recent master branch and
then check your branch.


If there are no comments, Can these be picked ?
Cc: Andrew Mortona...@osdl.org

The following changes since commit
f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:
g...@gitorious.org:linux-connectivity/linux-connectivity.git
omap_i2c_spi_dts_data

Felipe Balbi (1):
arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file

Sourav Poddar (4):
arm: dts: omap4-sdp: Add I2c pinctrl data
arm: dts: omap5-evm: Add I2c pinctrl data
arm: dts: omap4-panda: Add I2c pinctrl data
arm: dts: omap5-evm: Add mcspi data

Thanks,
Benoit



--
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: smp: Allow real broadcast device selection instead of always dummy

2013-03-13 Thread Thomas Gleixner

On Wed, 13 Mar 2013, Santosh Shilimkar wrote:
 On Wednesday 13 March 2013 07:49 PM, Thomas Gleixner wrote:
  Though making the rating of the dummy lower is definitely a good
  thing, so a real hardware device which is detected later can replace
  the dummy device. So yes, the rating should be low for the dummy
  timer.
  
 Exactly. As Mark pointed out, you have already applied Mark's patch.
 I was just wondering whether you can take the $subject patch as well
 with ack from Russell, Mark.

It can go through the ARM tree as well, no dependencies on my stuff.

Thanks,

tglx
--
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 1/2] ARM: OMAP1: Remove unused DMA channel definitions

2013-03-13 Thread Jarkko Nikula

Many of these channel definitions have became unused or were never used
so remove unused definitions from arch/arm/mach-omap1/dma.h using a script
below. See also notes in commit 8c4cc00
(ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions to mach-omap1)
for removing remaining ones.

egrep '#define OMAP.*DMA' arch/arm/mach-omap1/dma.h \
|cut -f 1 |cut -d ' ' -f 2 | while read -r i; do \
if [ `git grep -c $i | wc -l` -eq 1 ]; then \
echo removing $i; \
sed -i /${i}/d arch/arm/mach-omap1/dma.h; \
fi; \
done

Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
 arch/arm/mach-omap1/dma.h |   41 -
 1 file changed, 41 deletions(-)

diff --git a/arch/arm/mach-omap1/dma.h b/arch/arm/mach-omap1/dma.h
index da6345d..d05909c 100644
--- a/arch/arm/mach-omap1/dma.h
+++ b/arch/arm/mach-omap1/dma.h
@@ -21,21 +21,10 @@
 
 /* DMA channels for omap1 */
 #define OMAP_DMA_NO_DEVICE 0
-#define OMAP_DMA_MCSI1_TX  1
-#define OMAP_DMA_MCSI1_RX  2
-#define OMAP_DMA_I2C_RX3
-#define OMAP_DMA_I2C_TX4
-#define OMAP_DMA_EXT_NDMA_REQ  5
-#define OMAP_DMA_EXT_NDMA_REQ2 6
-#define OMAP_DMA_UWIRE_TX  7
 #define OMAP_DMA_MCBSP1_TX 8
 #define OMAP_DMA_MCBSP1_RX 9
 #define OMAP_DMA_MCBSP3_TX 10
 #define OMAP_DMA_MCBSP3_RX 11
-#define OMAP_DMA_UART1_TX  12
-#define OMAP_DMA_UART1_RX  13
-#define OMAP_DMA_UART2_TX  14
-#define OMAP_DMA_UART2_RX  15
 #define OMAP_DMA_MCBSP2_TX 16
 #define OMAP_DMA_MCBSP2_RX 17
 #define OMAP_DMA_UART3_TX  18
@@ -43,41 +32,11 @@
 #define OMAP_DMA_CAMERA_IF_RX  20
 #define OMAP_DMA_MMC_TX21
 #define OMAP_DMA_MMC_RX22
-#define OMAP_DMA_NAND  23
-#define OMAP_DMA_IRQ_LCD_LINE  24
-#define OMAP_DMA_MEMORY_STICK  25
 #define OMAP_DMA_USB_W2FC_RX0  26
-#define OMAP_DMA_USB_W2FC_RX1  27
-#define OMAP_DMA_USB_W2FC_RX2  28
 #define OMAP_DMA_USB_W2FC_TX0  29
-#define OMAP_DMA_USB_W2FC_TX1  30
-#define OMAP_DMA_USB_W2FC_TX2  31
 
 /* These are only for 1610 */
-#define OMAP_DMA_CRYPTO_DES_IN 32
-#define OMAP_DMA_SPI_TX33
-#define OMAP_DMA_SPI_RX34
-#define OMAP_DMA_CRYPTO_HASH   35
-#define OMAP_DMA_CCP_ATTN  36
-#define OMAP_DMA_CCP_FIFO_NOT_EMPTY37
-#define OMAP_DMA_CMT_APE_TX_CHAN_0 38
-#define OMAP_DMA_CMT_APE_RV_CHAN_0 39
-#define OMAP_DMA_CMT_APE_TX_CHAN_1 40
-#define OMAP_DMA_CMT_APE_RV_CHAN_1 41
-#define OMAP_DMA_CMT_APE_TX_CHAN_2 42
-#define OMAP_DMA_CMT_APE_RV_CHAN_2 43
-#define OMAP_DMA_CMT_APE_TX_CHAN_3 44
-#define OMAP_DMA_CMT_APE_RV_CHAN_3 45
-#define OMAP_DMA_CMT_APE_TX_CHAN_4 46
-#define OMAP_DMA_CMT_APE_RV_CHAN_4 47
-#define OMAP_DMA_CMT_APE_TX_CHAN_5 48
-#define OMAP_DMA_CMT_APE_RV_CHAN_5 49
-#define OMAP_DMA_CMT_APE_TX_CHAN_6 50
-#define OMAP_DMA_CMT_APE_RV_CHAN_6 51
-#define OMAP_DMA_CMT_APE_TX_CHAN_7 52
-#define OMAP_DMA_CMT_APE_RV_CHAN_7 53
 #define OMAP_DMA_MMC2_TX   54
 #define OMAP_DMA_MMC2_RX   55
-#define OMAP_DMA_CRYPTO_DES_OUT56
 
 #endif /* __OMAP1_DMA_CHANNEL_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 2/2] ARM: OMAP2+: Remove unused DMA channel definitions

2013-03-13 Thread Jarkko Nikula

Many of these channel definitions have became unused or were never used
so remove unused definitions from arch/arm/mach-omap2/dma.h using a script
below. See also notes in commit d5e7c86
(ARM: OMAP2+: DMA: Moving OMAP2+ DMA channel definitions to mach-omap2)
for removing remaining ones.

egrep '#define OMAP.*DMA' arch/arm/mach-omap2/dma.h \
|cut -f 1 |cut -d ' ' -f 2 | while read -r i; do \
if [ `git grep -c $i | wc -l` -eq 1 ]; then \
echo removing $i; \
sed -i /${i}/d arch/arm/mach-omap2/dma.h; \
fi; \
done

Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
 arch/arm/mach-omap2/dma.h |   70 -
 1 file changed, 70 deletions(-)

diff --git a/arch/arm/mach-omap2/dma.h b/arch/arm/mach-omap2/dma.h
index eba80db..65f80ca 100644
--- a/arch/arm/mach-omap2/dma.h
+++ b/arch/arm/mach-omap2/dma.h
@@ -22,69 +22,20 @@
 
 /* DMA channels for 24xx */
 #define OMAP24XX_DMA_NO_DEVICE 0
-#define OMAP24XX_DMA_XTI_DMA   1   /* S_DMA_0 */
 #define OMAP24XX_DMA_EXT_DMAREQ0   2   /* S_DMA_1 */
 #define OMAP24XX_DMA_EXT_DMAREQ1   3   /* S_DMA_2 */
 #define OMAP24XX_DMA_GPMC  4   /* S_DMA_3 */
-#define OMAP24XX_DMA_GFX   5   /* S_DMA_4 */
-#define OMAP24XX_DMA_DSS   6   /* S_DMA_5 */
-#define OMAP242X_DMA_VLYNQ_TX  7   /* S_DMA_6 */
-#define OMAP24XX_DMA_EXT_DMAREQ2   7   /* S_DMA_6 */
-#define OMAP24XX_DMA_CWT   8   /* S_DMA_7 */
 #define OMAP24XX_DMA_AES_TX9   /* S_DMA_8 */
 #define OMAP24XX_DMA_AES_RX10  /* S_DMA_9 */
-#define OMAP24XX_DMA_DES_TX11  /* S_DMA_10 */
-#define OMAP24XX_DMA_DES_RX12  /* S_DMA_11 */
-#define OMAP24XX_DMA_SHA1MD5_RX13  /* S_DMA_12 */
-#define OMAP34XX_DMA_SHA2MD5_RX13  /* S_DMA_12 */
 #define OMAP242X_DMA_EXT_DMAREQ2   14  /* S_DMA_13 */
 #define OMAP242X_DMA_EXT_DMAREQ3   15  /* S_DMA_14 */
 #define OMAP242X_DMA_EXT_DMAREQ4   16  /* S_DMA_15 */
-#define OMAP242X_DMA_EAC_AC_RD 17  /* S_DMA_16 */
-#define OMAP242X_DMA_EAC_AC_WR 18  /* S_DMA_17 */
-#define OMAP242X_DMA_EAC_MD_UL_RD  19  /* S_DMA_18 */
-#define OMAP242X_DMA_EAC_MD_UL_WR  20  /* S_DMA_19 */
-#define OMAP242X_DMA_EAC_MD_DL_RD  21  /* S_DMA_20 */
-#define OMAP242X_DMA_EAC_MD_DL_WR  22  /* S_DMA_21 */
-#define OMAP242X_DMA_EAC_BT_UL_RD  23  /* S_DMA_22 */
-#define OMAP242X_DMA_EAC_BT_UL_WR  24  /* S_DMA_23 */
-#define OMAP242X_DMA_EAC_BT_DL_RD  25  /* S_DMA_24 */
-#define OMAP242X_DMA_EAC_BT_DL_WR  26  /* S_DMA_25 */
-#define OMAP243X_DMA_EXT_DMAREQ3   14  /* S_DMA_13 */
-#define OMAP24XX_DMA_SPI3_TX0  15  /* S_DMA_14 */
-#define OMAP24XX_DMA_SPI3_RX0  16  /* S_DMA_15 */
-#define OMAP24XX_DMA_MCBSP3_TX 17  /* S_DMA_16 */
-#define OMAP24XX_DMA_MCBSP3_RX 18  /* S_DMA_17 */
-#define OMAP24XX_DMA_MCBSP4_TX 19  /* S_DMA_18 */
-#define OMAP24XX_DMA_MCBSP4_RX 20  /* S_DMA_19 */
-#define OMAP24XX_DMA_MCBSP5_TX 21  /* S_DMA_20 */
-#define OMAP24XX_DMA_MCBSP5_RX 22  /* S_DMA_21 */
-#define OMAP24XX_DMA_SPI3_TX1  23  /* S_DMA_22 */
-#define OMAP24XX_DMA_SPI3_RX1  24  /* S_DMA_23 */
-#define OMAP243X_DMA_EXT_DMAREQ4   25  /* S_DMA_24 */
-#define OMAP243X_DMA_EXT_DMAREQ5   26  /* S_DMA_25 */
 #define OMAP34XX_DMA_I2C3_TX   25  /* S_DMA_24 */
 #define OMAP34XX_DMA_I2C3_RX   26  /* S_DMA_25 */
 #define OMAP24XX_DMA_I2C1_TX   27  /* S_DMA_26 */
 #define OMAP24XX_DMA_I2C1_RX   28  /* S_DMA_27 */
 #define OMAP24XX_DMA_I2C2_TX   29  /* S_DMA_28 */
 #define OMAP24XX_DMA_I2C2_RX   30  /* S_DMA_29 */
-#define OMAP24XX_DMA_MCBSP1_TX 31  /* S_DMA_30 */
-#define OMAP24XX_DMA_MCBSP1_RX 32  /* S_DMA_31 */
-#define OMAP24XX_DMA_MCBSP2_TX 33  /* S_DMA_32 */
-#define OMAP24XX_DMA_MCBSP2_RX 34  /* S_DMA_33 */
-#define OMAP24XX_DMA_SPI1_TX0  35  /* S_DMA_34 */
-#define OMAP24XX_DMA_SPI1_RX0  36  /* S_DMA_35 */
-#define OMAP24XX_DMA_SPI1_TX1  37  /* S_DMA_36 */
-#define OMAP24XX_DMA_SPI1_RX1  38  /* S_DMA_37 */
-#define OMAP24XX_DMA_SPI1_TX2  39  /* S_DMA_38 */
-#define OMAP24XX_DMA_SPI1_RX2  40  /* S_DMA_39 */
-#define OMAP24XX_DMA_SPI1_TX3  41  /* S_DMA_40 */
-#define OMAP24XX_DMA_SPI1_RX3  42  /* S_DMA_41 */
-#define OMAP24XX_DMA_SPI2_TX0  43  /* S_DMA_42 */
-#define OMAP24XX_DMA_SPI2_RX0  44  /* S_DMA_43 */
-#define OMAP24XX_DMA_SPI2_TX1  45  /* S_DMA_44 */
-#define OMAP24XX_DMA_SPI2_RX1  46

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

  +/* Dummy regulator for pwm-backlight driver */ static struct
  +regulator_consumer_supply backlight_supply =
  +   REGULATOR_SUPPLY(enable, NULL);
 
 'enable' is just too generic, the device name should be also provided:
   REGULATOR_SUPPLY(enable, pwm-backlight);

You're right.  I don't like how generic it is as well.  But I don't think
pwm-backlight works...at least, not for me when I test it.  What
does work is backlight.x where x is some number (for me, it's 1).
Problem is, I don't know what it would be for you.  If only there
was a way to wildcard that...

Would it be better if we called the regulator something other than
enable?  Maybe backlight-enable, or bl-enable for brevity?
--
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/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

On Wed, Mar 13, 2013 at 01:38:31PM -0700, Andrew Chew wrote:
   +/* Dummy regulator for pwm-backlight driver */ static struct
   +regulator_consumer_supply backlight_supply =
   + REGULATOR_SUPPLY(enable, NULL);
  
  'enable' is just too generic, the device name should be also provided:
  REGULATOR_SUPPLY(enable, pwm-backlight);
 
 You're right.  I don't like how generic it is as well.  But I don't think
 pwm-backlight works...at least, not for me when I test it.  What
 does work is backlight.x where x is some number (for me, it's 1).
 Problem is, I don't know what it would be for you.  If only there
 was a way to wildcard that...
 
 Would it be better if we called the regulator something other than
 enable?  Maybe backlight-enable, or bl-enable for brevity?

The second parameter needs to match the device name. For the 4430sdp
board this should be pwm-backlight since the name will be generated
from the .name and .id fields of the struct platform_device. .id = -1
will result in no .id suffix being attached, so the device should be
named pwm-backlight. The first parameter needs to match the name of
the supply that the driver requests, so enable is correct since the
call to regulator_get() uses that.

Thierry


pgp_6Rdqha4r3.pgp
Description: PGP signature

RE: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator

  +static void pwm_backlight_enable(struct backlight_device *bl) {
  +   struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
  +
  +   /* Bail if we are already enabled. */
  +   if (pb-enabled)
  +   return;
  +
  +   pwm_enable(pb-pwm);
  +
  +   if (regulator_enable(pb-enable_supply) != 0)
 
 I would loose the '!= 0'

I think I prefer the '!= 0'.  Without it, it looks at first glance
like regulator_enable() is following boolean semantics,
so it reads kind of weird.  But I'll defer to Thierry on this
one.  Thierry, what's your preference?
--
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/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight

 From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
 Sent: Wednesday, March 13, 2013 1:59 PM
 To: Andrew Chew
 Cc: Peter Ujfalusi; Alex Courbot; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator
 to pwm-backlight

 * PGP Signed by an unknown key

 On Wed, Mar 13, 2013 at 01:38:31PM -0700, Andrew Chew wrote:
+/* Dummy regulator for pwm-backlight driver */ static struct
+regulator_consumer_supply backlight_supply =
+   REGULATOR_SUPPLY(enable, NULL);

   'enable' is just too generic, the device name should be also provided:
 REGULATOR_SUPPLY(enable, pwm-backlight);

  You're right.  I don't like how generic it is as well.  But I don't
  think pwm-backlight works...at least, not for me when I test it.
  What does work is backlight.x where x is some number (for me, it's 1).
  Problem is, I don't know what it would be for you.  If only there was
  a way to wildcard that...

  Would it be better if we called the regulator something other than
  enable?  Maybe backlight-enable, or bl-enable for brevity?

 The second parameter needs to match the device name. For the 4430sdp
 board this should be pwm-backlight since the name will be generated from
 the .name and .id fields of the struct platform_device. .id = -1 will result 
 in no
 .id suffix being attached, so the device should be named pwm-backlight.
 The first parameter needs to match the name of the supply that the driver
 requests, so enable is correct since the call to regulator_get() uses that.

Ah, I see.  That makes sense.  Thanks, Thierry!  pwm-backlight it is, then,
and I'll make sure to check for this for the other boards.
--
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 03/14] mailbox: OMAP: introduce mailbox framework

2013-03-13 Thread Anna, Suman

 On Wed, Mar 13, 2013 at 4:24 AM, Suman Anna s-a...@ti.com wrote:
 
  From: Omar Ramirez Luna omar.l...@linaro.org
 (...)
 
  Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
  [s-a...@ti.com: Kconfig fixes for build errors]
  Signed-off-by: Suman Anna s-a...@ti.com
  Acked-by: Tony Lindgren t...@atomide.com
  Signed-off-by: Linus Walleij linus.wall...@linaro.org
 
 It's not like I care super-much, but I think your SoB should be at the bottom.
 
 It's a simple git rebase -i anyway...

Sure, will do. Only this patch, right? I have my SoB only on one another 
original patch, will adjust on that as well, but all the remaining ones will 
have yours at the bottom.

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 2/2 v2] pwm_bl: Add mandatory backlight enable regulator

On Wed, Mar 13, 2013 at 02:10:16PM -0700, Andrew Chew wrote:
   +static void pwm_backlight_enable(struct backlight_device *bl) {
   + struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
   +
   + /* Bail if we are already enabled. */
   + if (pb-enabled)
   + return;
   +
   + pwm_enable(pb-pwm);
   +
   + if (regulator_enable(pb-enable_supply) != 0)
  
  I would loose the '!= 0'
 
 I think I prefer the '!= 0'.  Without it, it looks at first glance
 like regulator_enable() is following boolean semantics,
 so it reads kind of weird.  But I'll defer to Thierry on this
 one.  Thierry, what's your preference?

Why not assign the return value of regulator_enable() to a variable, for
instance err, and make that part of the warning message so that people
will have a better chance to diagnose what's going wrong?

Thierry


pgpKB6UF_rada.pgp
Description: PGP signature

RE: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator

 On Wed, Mar 13, 2013 at 02:10:16PM -0700, Andrew Chew wrote:
+static void pwm_backlight_enable(struct backlight_device *bl) {
+   struct pwm_bl_data *pb = dev_get_drvdata(bl-dev);
+
+   /* Bail if we are already enabled. */
+   if (pb-enabled)
+   return;
+
+   pwm_enable(pb-pwm);
+
+   if (regulator_enable(pb-enable_supply) != 0)
  
   I would loose the '!= 0'
 
  I think I prefer the '!= 0'.  Without it, it looks at first glance
  like regulator_enable() is following boolean semantics, so it reads
  kind of weird.  But I'll defer to Thierry on this one.  Thierry,
  what's your preference?
 
 Why not assign the return value of regulator_enable() to a variable, for
 instance err, and make that part of the warning message so that people will
 have a better chance to diagnose what's going wrong?

That's a good idea.  I'll have that modification in the next patch series that I
post.
--
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 2/5] usb: musb: omap: always glue have the correct vbus/id status

2013-03-13 Thread Grazvydas Ignotas

On Wed, Mar 13, 2013 at 10:47 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
 In the case where omap glue is loaded and musb core is not, glue-status
 wont have a valid status if the phy drivers call omap_musb_mailbox. So
 fixed the conditions here.

There already seems to be another patch named usb: musb: omap2430:
fix omap_musb_mailbox glue check again on it's way to mainline that
does mostly the same as first part of this patch.


 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  drivers/usb/musb/omap2430.c |   11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

 diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
 index 78bfc50..28a0220 100644
 --- a/drivers/usb/musb/omap2430.c
 +++ b/drivers/usb/musb/omap2430.c
 @@ -236,13 +236,10 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status 
 status)
  {
 struct omap2430_glue*glue = _glue;

 -   if (glue  glue_to_musb(glue)) {
 -   glue-status = status;
 -   } else {
 -   pr_err(%s: musb core is not yet ready\n, __func__);
 +   if (!glue)
 return;
 -   }

 +   glue-status = status;
 schedule_work(glue-omap_musb_mailbox_work);
  }
  EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 @@ -307,7 +304,9 @@ static void omap_musb_mailbox_work(struct work_struct 
 *mailbox_work)
  {
 struct omap2430_glue *glue = container_of(mailbox_work,
 struct omap2430_glue, omap_musb_mailbox_work);
 -   omap_musb_set_mailbox(glue);
 +
 +   if (glue_to_musb(glue))
 +   omap_musb_set_mailbox(glue);
  }

  static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
 --
 1.7.10.4


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

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.

 arch/arm/mach-omap2/board-4430sdp.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..a01a39a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
},
 };
 
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+   REGULATOR_SUPPLY(enable, pwm-backlight);
+
 static struct platform_pwm_backlight_data sdp4430_backlight_data = {
.max_brightness = 127,
.dft_brightness = 127,
@@ -718,6 +722,8 @@ static void __init omap_4430sdp_init(void)
 
omap4_i2c_init();
omap_sfh7741prox_init();
+   regulator_register_always_on(-1, backlight-enable,
+backlight_supply, 1, 0);
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
-- 
1.7.9.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

[PATCH V3 2/2] pwm_bl: Add mandatory backlight enable regulator