date:20121103

RE: [PATCH 0/5] usb: musb: am335x support

2012-11-03 Thread Mohammed, Afzal

Hi Daniel,

* Daniel Mack, November 03, 2012 1:06 AM:

 I'm testing these patches with an AM33xx board that has the first musb
 port wired to an USB type A plug, but it doesn't yet work for me.

 So there is no host interface registered. I'm unsure on how to fix this,
 and I didn't get an answer yet to that question when I asked Felipe
 about how interface drivers like dsps are supposed to act in order to
 get host mode back after the recent musb cleanups.

 What type of hardware do you test this with? Does host mode work for you?

To add to those details mentioned by Ravi,

This was tested on Beagle Bone with USB0 as usb-ethernet.

For purely Kernel part, this series is sufficient (along with
dependency mentioned in cover letter), considering
the fact that dt node is strictly not a part of Kernel.

To test this series, node for usbss should be present in dt.
Example in dt documentation can be pasted onto dtsi file
to get USB0 working.

Alternatively, you can fetch from,

git://gitorious.org/x0148406-public/linux-kernel.git usb

it has dt updated with usbss node.

Regards
Afzal--
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 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO

2012-11-03 Thread Bedia, Vaibhav

Hi Tony,

On Sat, Nov 03, 2012 at 00:30:04, Tony Lindgren wrote:
[...]
 
 Patches have been posted to move the mailbox related
 files out of arch/arm, so you'll have to update those
 for that. Please see thread [PATCH 0/2] ARM: OMAP:
 mailbox out of plat code for more information.
 

Thanks for pointing this out. I'll update the patches for these.

I had used your master branch as the baseline. Some of the patches
also need rework to account the header file and timer code changes.
Is there some other branch of yours that I could use or should I
just mention the dependencies in the next version of patches?

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

RE: [PATCH 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX

2012-11-03 Thread Bedia, Vaibhav

Hi Russ,

On Sat, Nov 03, 2012 at 05:44:21, Russ Dill wrote:
[...]
  -   if (!cpu_is_omap44xx())
  +   if (!cpu_is_omap44xx() || !soc_is_am33xx())
  bit = mbox_read_reg(p-irqdisable)  ~bit;
 
 Do you mean ?
 

I didn't change that line but it looks ok to me :)

Regards,
Vaibhav

RE: [RFC 00/15] Add basic suspend-resume support for AM33XX

2012-11-03 Thread Bedia, Vaibhav

Hi Daniel,

On Sat, Nov 03, 2012 at 03:46:53, Daniel Mack wrote:
[...]
 
 What event did you use to bring the system back to life? I tried a GPIO
 button which has linux,wakeup set and is connected to GPIO bank 0, but
 without success.

I used uart wakeup in my testing. I see that you have CPSW driver also
in your kernel. Can you try with a minimal set of drivers, similar to what
BeagleBone has on Tony's master branch right now.
 
Mugunthan mentioned he has a fix of the WARN_ON from CPSW driver that you
see in the logs and that will be posted shortly. Can you mention what other
patches you have pulled in?

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

Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

2012-11-03 Thread Kevin Hilman


On 11/02/2012 09:43 AM, Pantelis Antoniou wrote:
[...]



And then use the standard DT support to create later the platform_device that 
does represent the new super-cape devices.



We know this is the ideal case. In fact that's the long term goal and we had 
internal discussions about it.


Since you already had internal discussions about this, it would have 
been a great help in avoiding lots of this discussion if you would've 
summarized this ideal case from the beginning, then describe the 
weaknesses and limitations of DT for handling hotplug/dynamic devices 
and thus the reasoning behind creating capebus.  Now it's taken this 
long thread for others to try to convince you about something you 
already knew to be the ideal case.  Seems a bit wasteful.


Kernel development typically works by building/extending infrastructure 
that is already there.  Only when it's obvious that the current 
infrastructure cannot be extended for a new kind of usage do we build 
new infrastruture.


In this case, DT is the obvious infrastructure that needs extending.  At 
least we can all agree on that, for starters.



DT is nowhere near being able to do it.

That would require the introduction of a DT object file format with aliases 
being capable to be
resolved dynamically. We're talking about major changes here in the way DT 
files are being compiled and
used in practice.

So yes, in an ideal world that would be great. We're nowhere near close today 
unfortunately.

Assuming that we do work on a DT object format, and that the runtime resolution 
mechanism is approved,
then I agree that this part of the capebus patches can be dropped and the 
functionality assumed by generic
DT core.

The question is that this will take time, with no guarantees that this would be 
acceptable from
the device tree maintainers. So I am putting them in the CC list, to see what 
they think about it.


Since this thread has already ventured into the weeds a few times, I 
would suggest that you summarize the DT limitations (focusing on they 
dynamic/hotplug needs) and start a thread on devicetree-discuss, so that 
the DT maintainers can be helpful without having to follow this thread.


IMO, the path forward is clear (though probably longer than you would 
like):  Let's first try and extend DT infrastructure.  If that is 
obviously going nowhere, and DT maintainers are against it.  Then, let's 
revisit capebus.


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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

2012-11-03 Thread Kevin Hilman


On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

AM33XX has only one usable timer in the WKUP domain.
Currently the timer instance in WKUP domain is used
as the clockevent and the timer in non-WKUP domain
as the clocksource. The timer in WKUP domain can keep
running in suspend from a 32K clock and hence serve
as the persistent clock. To enable this, interchange
the timers used as clocksource and clockevent for
AM33XX.


Doesn't this also mean that you won't get timer wakeups
in idle?  Or are you keeping the domain where the clockevent is
on during idle?

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 v2 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot

2012-11-03 Thread Kevin Hilman


On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:

When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).

To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.

In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.comke


Acked-by: Kevin Hilman khil...@ti.com

Benoit, feel free to take this one as well.

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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

2012-11-03 Thread Kevin Hilman


On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

From: Vaibhav Hiremath hvaib...@ti.com

The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.


The changelog describes what, but doesn't answer why?


commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.


You say it behaves properly without describing what improper
behavior is happening.


Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/timer.c |   31 +++
  1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 6584ee0..e8781fd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode 
mode,
}
  }

+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+   char name[10];
+   struct omap_hwmod *oh;
+
+   sprintf(name, timer%d, 2);


hard-coded timer ID?  the rest of the code is using timer_id


+   oh = omap_hwmod_lookup(name);
+   if (!oh)
+   return;
+
+   omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+   char name[10];
+   struct omap_hwmod *oh;
+
+   sprintf(name, timer%d, 2);
+   oh = omap_hwmod_lookup(name);
+   if (!oh)
+   return;
+
+   omap_hwmod_enable(oh);
+   __omap_dm_timer_load_start(clkev,
+   OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+   __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}


I don't like the sprintf/hwmod_lookup for every suspend/resume.  Just add a
new file-global static 'struct omap_hwmod clockevt_oh' along side 
clockevent_gpt,
and assign it at init time in dmtimer_init_one.  Then you don't have to 
do this

sprintf/lookup on every suspend/resume.

Kevin


  static struct clock_event_device clockevent_gpt = {
.name   = gp_timer,
.features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode   = omap2_gp_timer_set_mode,
+   .suspend= omap_clkevt_suspend,
+   .resume = omap_clkevt_resume,
  };

  static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,


--
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/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox

2012-11-03 Thread Kevin Hilman


On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com


Even simple patches need a simple changelog.

Kevin


  arch/arm/boot/dts/am33xx.dtsi |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..e2cbf24 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,16 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+   ocmcram: ocmcram@4030 {
+   compatible = ti,ocmcram;
+   ti,hwmods = ocmcram;
+   ti,no_idle_on_suspend;
+   };
+
+   wkup_m3: wkup_m3@44d0 {
+   compatible = ti,wkup_m3;
+   ti,hwmods = wkup_m3;
+   };
};
  };


--
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 14/15] ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox

2012-11-03 Thread Kevin Hilman


On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

AM33XX PM code depends on Mailbox module for IPC
between MPU and WKUP_M3.


OK, but what if I try to build for AM33xx without starting from 
omap2plus_defconfig?


IOW, instead of changing the default defconfig, AM33xx should select 
this when PM

is enabled.   Something like the (untested) change below.

Kevin


diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d669e22..93c1a37 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -109,6 +109,7 @@ config SOC_AM33XX
bool AM33XX support
default y
select ARM_CPU_SUSPEND if PM
+select OMAP_MBOX_FWK if PM
select CPU_V7
select MULTI_IRQ_HANDLER



--
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 0/2] USB: dwc3-exynos: Adding device tree support

2012-11-03 Thread Vivek Gautam

Changes from v2:
 - Respined for 'dwc3' branch on Felipe's usb tree.

Changes from v1:
 - Removed setting-up of dev.coherent_dma_mask, since of/platform.c
   itself takes care of it.

Vivek Gautam (2):
  USB: dwc3-exynos: Add support for device tree
  USB: DWC3: EXYNOS: Remove platform data for dwc3-exynos

 drivers/usb/dwc3/dwc3-exynos.c |   36 
 1 files changed, 20 insertions(+), 16 deletions(-)

-- 
1.7.6.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 1/2] USB: dwc3-exynos: Add support for device tree

2012-11-03 Thread Vivek Gautam

This patch adds support to parse probe data for
dwc3-exynos driver using device tree.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/dwc3/dwc3-exynos.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 586f105..6471d78 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -21,6 +21,7 @@
 #include linux/clk.h
 #include linux/usb/otg.h
 #include linux/usb/nop-usb-xceiv.h
+#include linux/of.h
 
 #include core.h
 
@@ -87,6 +88,8 @@ err1:
return ret;
 }
 
+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
+
 static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
 {
struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
@@ -102,6 +105,14 @@ static int __devinit dwc3_exynos_probe(struct 
platform_device *pdev)
goto err0;
}
 
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we move to full device tree support this will vanish off.
+*/
+   if (!pdev-dev.dma_mask)
+   pdev-dev.dma_mask = dwc3_exynos_dma_mask;
+
platform_set_drvdata(pdev, exynos);
 
ret = dwc3_exynos_register_phys(exynos);
@@ -191,11 +202,20 @@ static int __devexit dwc3_exynos_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_dwc3_match[] = {
+   { .compatible = samsung,exynos-dwc3 },
+   {},
+};
+MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
+#endif
+
 static struct platform_driver dwc3_exynos_driver = {
.probe  = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name   = exynos-dwc3,
+   .of_match_table = of_match_ptr(exynos_dwc3_match),
},
 };
 
-- 
1.7.6.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] USB: DWC3: EXYNOS: Remove platform data for dwc3-exynos

2012-11-03 Thread Vivek Gautam

We are removing plat data which was used till now to init and
exit phy. We no longer need this since dwc3-core takes care of
initializing and shutting-down the phy using usb_phy_init()
and usb_phy_shutdown().

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 drivers/usb/dwc3/dwc3-exynos.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 6471d78..dc35c54 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -92,7 +92,6 @@ static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
 
 static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
 {
-   struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
struct platform_device  *dwc3;
struct dwc3_exynos  *exynos;
struct clk  *clk;
@@ -145,14 +144,6 @@ static int __devinit dwc3_exynos_probe(struct 
platform_device *pdev)
 
clk_enable(exynos-clk);
 
-   /* PHY initialization */
-   if (!pdata) {
-   dev_dbg(pdev-dev, missing platform data\n);
-   } else {
-   if (pdata-phy_init)
-   pdata-phy_init(pdev, pdata-phy_type);
-   }
-
ret = platform_device_add_resources(dwc3, pdev-resource,
pdev-num_resources);
if (ret) {
@@ -169,9 +160,6 @@ static int __devinit dwc3_exynos_probe(struct 
platform_device *pdev)
return 0;
 
 err4:
-   if (pdata  pdata-phy_exit)
-   pdata-phy_exit(pdev, pdata-phy_type);
-
clk_disable(clk);
clk_put(clk);
 err3:
@@ -185,15 +173,11 @@ err0:
 static int __devexit dwc3_exynos_remove(struct platform_device *pdev)
 {
struct dwc3_exynos  *exynos = platform_get_drvdata(pdev);
-   struct dwc3_exynos_data *pdata = pdev-dev.platform_data;
 
platform_device_unregister(exynos-dwc3);
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
 
-   if (pdata  pdata-phy_exit)
-   pdata-phy_exit(pdev, pdata-phy_type);
-
clk_disable(exynos-clk);
clk_put(exynos-clk);
 
-- 
1.7.6.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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

2012-11-03 Thread Bedia, Vaibhav

Hi Kevin,

On Sat, Nov 03, 2012 at 17:13:54, Kevin Hilman wrote:
 On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
  AM33XX has only one usable timer in the WKUP domain.
  Currently the timer instance in WKUP domain is used
  as the clockevent and the timer in non-WKUP domain
  as the clocksource. The timer in WKUP domain can keep
  running in suspend from a 32K clock and hence serve
  as the persistent clock. To enable this, interchange
  the timers used as clocksource and clockevent for
  AM33XX.
 
 Doesn't this also mean that you won't get timer wakeups
 in idle?  Or are you keeping the domain where the clockevent is
 on during idle?
 

The lowest idle state that we are targeting will have MPU powered
off with external memory in self-refresh mode. Peripheral domain
with the clockevent will be kept on.

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

Re: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

2012-11-03 Thread Kevin Hilman


T
On 11/03/2012 12:47 PM, Bedia, Vaibhav wrote:

Hi Kevin,

On Sat, Nov 03, 2012 at 17:13:54, Kevin Hilman wrote:

On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

AM33XX has only one usable timer in the WKUP domain.
Currently the timer instance in WKUP domain is used
as the clockevent and the timer in non-WKUP domain
as the clocksource. The timer in WKUP domain can keep
running in suspend from a 32K clock and hence serve
as the persistent clock. To enable this, interchange
the timers used as clocksource and clockevent for
AM33XX.


Doesn't this also mean that you won't get timer wakeups
in idle?  Or are you keeping the domain where the clockevent is
on during idle?



The lowest idle state that we are targeting will have MPU powered
off with external memory in self-refresh mode. Peripheral domain
with the clockevent will be kept on.


Is this a limitation of the hardware?  or the software?

Kevin

P.S.  I haven't yet made my way through the TRM, so I'll probably figure
this out when I read it, but having this summarized in the changelog would
be helpful since even after I read the TRM, I'll forget.  I'm saving the 
TRM

reading for entertainment on upcoming flight home from Linaro Connect.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 4/6] ARM: OMAP: SmartReflex: provide SoC integration API for VP

2012-11-03 Thread Kevin Hilman


On 10/23/2012 10:43 PM, Nishanth Menon wrote:

SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor API
to allow for SmartReflex class drivers to use the same.

NOTE: SmartReflex class 3 mode of operation mandates VP APIs
so, refuse to enable AVS driver if corresponding APIs are
not available.

As part of this change, remove the inclusion of voltage.h
which is no longer needed as smartreflex.h includes
linux/platform_data/voltage-omap.h which contain relevant
definitions used here.

Signed-off-by: Nishanth Menon n...@ti.com


[...]


@@ -23,15 +22,26 @@ static int sr_class3_enable(struct omap_sr *sr)
__func__, sr-name);
return -ENODATA;
}
+   if (!sr-soc_ops.vp_enable) {
+   pr_warn(%s: no VP enable available.Cannot enable %s!!\n,


nit: add space after '.'

There's a couple of these in the patch.

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: [RFC PATCH 0/6] ARM: OMAP3+: move smartreflex-class3.c to drivers/power/avs

2012-11-03 Thread Kevin Hilman


Hi Nishanth,

On 10/25/2012 09:21 AM, Jean Pihet wrote:

Hi Nishant,

On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote:

smartreflex.c now resides in drivers/power/avs directory, but class driver
is in mach-omap2. High time we move it off to drivers/power/avs.

Great to see the SR fully moved to drivers/.

After review of the code I am OK with the changes besides remarks sent
on the patches:
Acked-by: Jean Pihet j-pi...@ti.com

I let Kevin comment on the VC/VP aspect though.



This move looks good to me.  Thanks!

Just had one nit, but after that.  Feel free to post without the RFC, 
and be sure to
include Rafael and linux-pm since it's moving to drivers/power.  I'll 
then queue it

up for Rafael for v3.8.

Thanks,

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

RE: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 17:45:03, Kevin Hilman wrote:
 On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
  From: Vaibhav Hiremath hvaib...@ti.com
 
  The current OMAP timer code registers two timers -
  one as clocksource and one as clockevent.
  AM33XX has only one usable timer in the WKUP domain
  so one of the timers needs suspend-resume support
  to restore the configuration to pre-suspend state.
 
 The changelog describes what, but doesn't answer why?
 

Sorry I'll try to take of this in the future.

  commit adc78e6 (timekeeping: Add suspend and resume
  of clock event devices) introduced .suspend and .resume
  callbacks for clock event devices. Leverages these
  callbacks to have AM33XX clockevent timer which is
  in not in WKUP domain to behave properly across system
  suspend.
 
 You say it behaves properly without describing what improper
 behavior is happening.
 

There are two issues. One is that the clockevent timer doesn't
get idled which blocks PER domain transition. The next one is that
the clockevent doesn't generate any further interrupts once the
system resumes. We need to restore the pre-suspend configuration.
I haven't tried but I guess we could have used the save and restore
of timer registers here.

  Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
  Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
  ---
arch/arm/mach-omap2/timer.c |   31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
 
  diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
  index 6584ee0..e8781fd 100644
  --- a/arch/arm/mach-omap2/timer.c
  +++ b/arch/arm/mach-omap2/timer.c
  @@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum 
  clock_event_mode mode,
  }
}
 
  +static void omap_clkevt_suspend(struct clock_event_device *unused)
  +{
  +   char name[10];
  +   struct omap_hwmod *oh;
  +
  +   sprintf(name, timer%d, 2);
 
 hard-coded timer ID?  the rest of the code is using timer_id

Will fix.

 
  +   oh = omap_hwmod_lookup(name);
  +   if (!oh)
  +   return;
  +
  +   omap_hwmod_idle(oh);
  +}
  +
  +static void omap_clkevt_resume(struct clock_event_device *unused)
  +{
  +   char name[10];
  +   struct omap_hwmod *oh;
  +
  +   sprintf(name, timer%d, 2);
  +   oh = omap_hwmod_lookup(name);
  +   if (!oh)
  +   return;
  +
  +   omap_hwmod_enable(oh);
  +   __omap_dm_timer_load_start(clkev,
  +   OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
  +   __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
  +}
 
 I don't like the sprintf/hwmod_lookup for every suspend/resume.  Just add a
 new file-global static 'struct omap_hwmod clockevt_oh' along side 
 clockevent_gpt,
 and assign it at init time in dmtimer_init_one.  Then you don't have to 
 do this
 sprintf/lookup on every suspend/resume.
 

Ok. Will make the changes accordingly.

Regards,
Vaibhav 

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

RE: [PATCH 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 17:46:06, Kevin Hilman wrote:
 On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
  Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
 
 Even simple patches need a simple changelog.

Again, sorry about this. Will take care in the future. 

Regards,
Vaibhav 

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

RE: [PATCH 14/15] ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 17:50:25, Kevin Hilman wrote:
 On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:
  AM33XX PM code depends on Mailbox module for IPC
  between MPU and WKUP_M3.
 
 OK, but what if I try to build for AM33xx without starting from 
 omap2plus_defconfig?

I honestly didn't think about this scenario.

 
 IOW, instead of changing the default defconfig, AM33xx should select 
 this when PM
 is enabled.   Something like the (untested) change below.
 

Will try it out. Thanks for the suggestion.

Regards,
Vaibhav 

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

Re: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

2012-11-03 Thread Kevin Hilman


On 11/03/2012 01:17 PM, Bedia, Vaibhav wrote:

On Sat, Nov 03, 2012 at 17:45:03, Kevin Hilman wrote:

On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

From: Vaibhav Hiremath hvaib...@ti.com

The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.


The changelog describes what, but doesn't answer why?



Sorry I'll try to take of this in the future.


Thanks.  Here's a general rule.  Assume you (or I) will be reading this
a year from now and will have forgotten the details.  The changelog then
serves as our long-term memory. :)


commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.


You say it behaves properly without describing what improper
behavior is happening.



There are two issues. One is that the clockevent timer doesn't
get idled which blocks PER domain transition. The next one is that
the clockevent doesn't generate any further interrupts once the
system resumes.


Please include both in the next rev of the changelog.


We need to restore the pre-suspend configuration.
I haven't tried but I guess we could have used the save and restore
c timer registers here.


Yes, please try with that.  Won't that be necessary anyways for situations
where the powerdomain goes off?

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 14/15] ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox

2012-11-03 Thread Kevin Hilman


On 11/03/2012 01:17 PM, Bedia, Vaibhav wrote:

On Sat, Nov 03, 2012 at 17:50:25, Kevin Hilman wrote:

On 11/02/2012 01:32 PM, Vaibhav Bedia wrote:

AM33XX PM code depends on Mailbox module for IPC
between MPU and WKUP_M3.


OK, but what if I try to build for AM33xx without starting from
omap2plus_defconfig?


I honestly didn't think about this scenario.



IOW, instead of changing the default defconfig, AM33xx should select
this when PM
is enabled.   Something like the (untested) change below.



Will try it out. Thanks for the suggestion.


You're welcome.

See... sometimes maintainers can be useful for something other than 
complaining.  ;)


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 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 14:06:38, Bedia, Vaibhav wrote:
 Hi Russ,
 
 On Sat, Nov 03, 2012 at 05:44:21, Russ Dill wrote:
 [...]
   -   if (!cpu_is_omap44xx())
   +   if (!cpu_is_omap44xx() || !soc_is_am33xx())
   bit = mbox_read_reg(p-irqdisable)  ~bit;
  
  Do you mean ?
  
 

Ok I understood what you meant. Will fix it in next rev.

Regards,
Vaibhav

RE: [PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote:
[...]
 
  Doesn't this also mean that you won't get timer wakeups
  in idle?  Or are you keeping the domain where the clockevent is
  on during idle?
 
 
  The lowest idle state that we are targeting will have MPU powered
  off with external memory in self-refresh mode. Peripheral domain
  with the clockevent will be kept on.
 
 Is this a limitation of the hardware?  or the software?
 

Well, making the lowest idle state same as the suspend state will require
us to involve WKUP_M3 in the idle path and wakeup sources get limited to
the IPs in the WKUP domain alone. There's no IO daisy chaining in AM33XX
so that's one big difference compared to OMAP. 

The other potential problem is that the IPC mechanism that we have
uses interrupts. Assuming that the lowest idle state, say Cx, is the same
as the suspend state, we'll need to communicate with the WKUP_M3 using
interrupts once we decide to enter Cx. I am not sure if we can do something
in the cpuidle implementation to work around the interrupt for idle
problem. We could probably not wait for an ACK when we want to enter Cx,
but the problem of limited wakeup sources remains. If we let the various
drivers block the entry to Cx, since almost all the IPs are in the
peripheral domain a system which uses anything other than UART and Timer
in WKUP domain will probably never be able enter Cx.

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

RE: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

2012-11-03 Thread Bedia, Vaibhav

On Sat, Nov 03, 2012 at 19:11:54, Kevin Hilman wrote:
[...]
 
 Yes, please try with that.  Won't that be necessary anyways for situations
 where the powerdomain goes off?
 

Yes, we probably got lucky with the minimal resume routine.

Regards,
Vaibhav 

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

Re: [RFC PATCH 0/6] ARM: OMAP3+: move smartreflex-class3.c to drivers/power/avs

2012-11-03 Thread Jean Pihet

Hi Nishant,

On Sat, Nov 3, 2012 at 2:14 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Hi Nishanth,


 On 10/25/2012 09:21 AM, Jean Pihet wrote:

 Hi Nishant,

 On Tue, Oct 23, 2012 at 11:43 PM, Nishanth Menon n...@ti.com wrote:

 smartreflex.c now resides in drivers/power/avs directory, but class
 driver
 is in mach-omap2. High time we move it off to drivers/power/avs.

 Great to see the SR fully moved to drivers/.

 After review of the code I am OK with the changes besides remarks sent
 on the patches:
 Acked-by: Jean Pihet j-pi...@ti.com

 I let Kevin comment on the VC/VP aspect though.


 This move looks good to me.  Thanks!

 Just had one nit, but after that.  Feel free to post without the RFC, and be
 sure to
 include Rafael and linux-pm since it's moving to drivers/power.
Please also include Anton, cf.
http://marc.info/?l=linux-pmm=134424298230568w=2

Regards,
Jean

 I'll then
 queue it
 up for Rafael for v3.8.

 Thanks,

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

Re: [PATCH 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

From: Vaibhav Hiremath hvaib...@ti.com

The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.

Actually OMAP also uses only one timer. The clocksource
is taken care by 32K syntimer till OMAP4 and by realtime
counter on OMAP5. There is a clocksource registration of
timer is available but that is not being used in systems.


AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.

commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.


So you use WKUP domain timer for clocksource and PER
domain one for clock-event ?



Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/timer.c |   31 +++
  1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 6584ee0..e8781fd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,35 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode 
mode,
}
  }

+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+   char name[10];
+   struct omap_hwmod *oh;
+
+   sprintf(name, timer%d, 2);
+   oh = omap_hwmod_lookup(name);
+   if (!oh)
+   return;


You can move all the look up stuff in init code and then
suspend resume hooks will be cleaner.

+
+   omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+   char name[10];
+   struct omap_hwmod *oh;
+
+   sprintf(name, timer%d, 2);
+   oh = omap_hwmod_lookup(name);
+   if (!oh)
+   return;
+
+   omap_hwmod_enable(oh);
+   __omap_dm_timer_load_start(clkev,
+   OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+   __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+

OK. So since your clk_event stops when PER idles, how do you plan
to support the SOC idle. For CPUIDLE path, you need your clock-event
to wakeup the system based on next timer expiry. So you need your
clock event to be active. Indirectly, you can't let PER idle which
leads npo CORE idle-SOC idle.

How do you plan to address this ? Os is SOC idle is not suppose
to be added for AMXXX ?

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 13/15] ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/boot/dts/am33xx.dtsi |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..e2cbf24 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,16 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+   ocmcram: ocmcram@4030 {
+   compatible = ti,ocmcram;
+   ti,hwmods = ocmcram;
+   ti,no_idle_on_suspend;
+   };

Whats the intention behind adding OCMRAM ?
Sorry if I missed any comments from the cover letter ?

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 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

On AM33XX, the mailbox module between the MPU and the
WKUP-M3 co-processor facilitates a one-way communication.
MPU uses the assigned mailbox sub-module to issue the
interrupt to the WKUP-M3 co-processor which then goes
and reads the the IPC data from registers in the control
module.

WKUP-M3 is in the L4_WKUP and does not have any access to
the Mailbox module. Due to this limitation, the MPU is
completely responsible for FIFO maintenance and interrupt
generation. MPU needs to ensure that the FIFO does not
overflow by reading by the assigned mailbox sub-module.

This patch adds an API in the mailbox code which the MPU
can use to empty the FIFO by issuing a readback command.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/mailbox.c |   42 -
  arch/arm/plat-omap/include/plat/mailbox.h |3 ++
  arch/arm/plat-omap/mailbox.c  |   35 
  3 files changed, 67 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f38b4fa 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -123,6 +123,20 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
return mbox_read_reg(fifo-fifo_stat);
  }

+static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
+{
+   struct omap_mbox2_fifo *fifo =
+   ((struct omap_mbox2_priv *)mbox-priv)-tx_fifo;

type casting is generally avoided in linux code.

+   return mbox_read_reg(fifo-msg_stat);
+}
+
+static mbox_msg_t omap2_mbox_fifo_readback(struct omap_mbox *mbox)
+{
+   struct omap_mbox2_fifo *fifo =
+   ((struct omap_mbox2_priv *)mbox-priv)-tx_fifo;
+   return (mbox_msg_t) mbox_read_reg(fifo-msg);

same here.

+}
+
  /* Mailbox IRQ handle functions */
  static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
@@ -205,19 +219,21 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
  }

  static struct omap_mbox_ops omap2_mbox_ops = {
-   .type   = OMAP_MBOX_TYPE2,
-   .startup= omap2_mbox_startup,
-   .shutdown   = omap2_mbox_shutdown,
-   .fifo_read  = omap2_mbox_fifo_read,
-   .fifo_write = omap2_mbox_fifo_write,
-   .fifo_empty = omap2_mbox_fifo_empty,
-   .fifo_full  = omap2_mbox_fifo_full,
-   .enable_irq = omap2_mbox_enable_irq,
-   .disable_irq= omap2_mbox_disable_irq,
-   .ack_irq= omap2_mbox_ack_irq,
-   .is_irq = omap2_mbox_is_irq,
-   .save_ctx   = omap2_mbox_save_ctx,
-   .restore_ctx= omap2_mbox_restore_ctx,
+   .type   = OMAP_MBOX_TYPE2,
+   .startup= omap2_mbox_startup,
+   .shutdown   = omap2_mbox_shutdown,
+   .fifo_read  = omap2_mbox_fifo_read,
+   .fifo_write = omap2_mbox_fifo_write,
+   .fifo_empty = omap2_mbox_fifo_empty,
+   .fifo_full  = omap2_mbox_fifo_full,
+   .fifo_needs_flush   = omap2_mbox_fifo_needs_flush,
+   .fifo_readback  = omap2_mbox_fifo_readback,
+   .enable_irq = omap2_mbox_enable_irq,
+   .disable_irq= omap2_mbox_disable_irq,
+   .ack_irq= omap2_mbox_ack_irq,
+   .is_irq = omap2_mbox_is_irq,
+   .save_ctx   = omap2_mbox_save_ctx,
+   .restore_ctx= omap2_mbox_restore_ctx,

You should do the indentation fix in another patch.


  };

  /*
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index cc3921e..e136529 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -29,6 +29,8 @@ struct omap_mbox_ops {
void(*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
int (*fifo_empty)(struct omap_mbox *mbox);
int (*fifo_full)(struct omap_mbox *mbox);
+   int (*fifo_needs_flush)(struct omap_mbox *mbox);
+   mbox_msg_t  (*fifo_readback)(struct omap_mbox *mbox);

Do you think passing the msg structure as an argument and letting the
function populate it will be better instead of returning the msg
structure ? No strong opinion since from read_foo() point of view
what you have done might be right thing. In either case, please
get rid of typecasting.

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 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

Mailbox IP on AM33XX, is the same as that present
in OMAP4. The single instance of Mailbox module
contains 8 sub-modules and facilitates communication
between MPU, PRUs and WKUP_M3.

The first mailbox sub-module is assigned for
communication between MPU and WKUP-M3.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/mailbox.c |   35 ++-
  1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index f38b4fa..7a343aa 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -155,7 +155,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;

-   if (!cpu_is_omap44xx())
+   if (!cpu_is_omap44xx() || !soc_is_am33xx())
bit = mbox_read_reg(p-irqdisable)  ~bit;

mbox_write_reg(bit, p-irqdisable);
@@ -358,6 +358,32 @@ struct omap_mbox mbox_2_info = {
  struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
  #endif

+#if defined(CONFIG_SOC_AM33XX)
+static struct omap_mbox2_priv omap2_mbox_wkup_m3_priv = {
+   .tx_fifo = {
+   .msg= MAILBOX_MESSAGE(0),
+   .fifo_stat  = MAILBOX_FIFOSTATUS(0),
+   .msg_stat   = MAILBOX_MSGSTATUS(0),
+   },
+   .rx_fifo = {
+   .msg= MAILBOX_MESSAGE(1),
+   .msg_stat   = MAILBOX_MSGSTATUS(1),
+   },
+   .irqenable  = OMAP4_MAILBOX_IRQENABLE(3),
+   .irqstatus  = OMAP4_MAILBOX_IRQSTATUS(3),
+   .irqdisable = OMAP4_MAILBOX_IRQENABLE_CLR(3),
+   .notfull_bit= MAILBOX_IRQ_NOTFULL(0),
+   .newmsg_bit = MAILBOX_IRQ_NEWMSG(0),
+};
+
+struct omap_mbox mbox_wkup_m3_info = {
+   .name   = wkup_m3,
+   .ops= omap2_mbox_ops,
+   .priv   = omap2_mbox_wkup_m3_priv,
+};
+struct omap_mbox *am33xx_mboxes[] = { mbox_wkup_m3_info, NULL };
+#endif
+
  static int __devinit omap2_mbox_probe(struct platform_device *pdev)
  {
struct resource *mem;
@@ -392,6 +418,13 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
list[0]-irq = list[1]-irq = platform_get_irq(pdev, 0);
}
  #endif
+#if defined(CONFIG_SOC_AM33XX)
+   else if (soc_is_am33xx()) {
+   list = am33xx_mboxes;
+
+   list[0]-irq = platform_get_irq(pdev, 0);
+   }
+#endif

#ifdef in middle of the function looks really ugly. But I can't complain
just for your patch because looks like rest of the mailbox code is
flooded with #ifdeffery.

Mailbox needs cleanup. and probably can be moved out of
arch/arm/*omap*/ to some driver directory.

Regards
santosh


inside arch/arm/mach-omap2/* directory.




--
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 03/15] ARM: OMAP: mailbox: Convert to device_initcall

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

The power management code for AM33XX is a late_initcall
and the PM features depend on the mailbox for IPC.
In preparation for this, convert the mailbox init to
a device_initcall.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---

Looks fine
--
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 05/15] ARM: OMAP2+: AM33XX: Update WKUP_M3 hwmod entry for reset status

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

Add the reset status offset for WKUP_M3 in the hwmod data

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 3c235d8..2e470ce 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -269,6 +269,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.omap4  = {
.clkctrl_offs   = AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
.rstctrl_offs   = AM33XX_RM_WKUP_RSTCTRL_OFFSET,
+   .rstst_offs = AM33XX_RM_WKUP_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},


You are adding reset bit in this patch but using it in 4/15. Probably
you can re-order it to keep git bisect happy.

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 06/15] ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

The hwmod data for OCMCRAM in AM33XX was commented out.
This data is needed by the power management code, hence
uncomment the same and register the OCP interface for it.


Why this data is needed by PM code ?

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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT
instead of ADDR_TYPE_RT to ensure the omap hwmod code
maps the memory space at init and writes to the SYSCONFIG
registers.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---

Sorry again similar question.

Why CPGMAC0 should be mapped and sysconfig updated early ?

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 09/15] ARM: OMAP: AM33XX: Remove unnecessary include and use ASSEMBLER macros

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

Get rid of some unnecessary header file inclusions
and also use __ASSEMBLER__ macros to allow the
various register offsets from PM assembly code
which be added in a subsequent patch.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com


Ideally you should split header clean-up and assembler
fix in seperate patches.

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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

AM33XX has only one usable timer in the WKUP domain.
Currently the timer instance in WKUP domain is used
as the clockevent and the timer in non-WKUP domain
as the clocksource. The timer in WKUP domain can keep
running in suspend from a 32K clock and hence serve
as the persistent clock. To enable this, interchange
the timers used as clocksource and clockevent for
AM33XX. A subsequent patch will add suspend-resume
support for the clockevent to ensure that there are
no issues with timekeeping.

Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/timer.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 565e575..6584ee0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -460,7 +460,7 @@ OMAP_SYS_TIMER(3_secure)
  #endif

  #ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER_INIT(3_am33xx, 2, OMAP4_MPU_SOURCE, 1, OMAP4_MPU_SOURCE)
  OMAP_SYS_TIMER(3_am33xx)
  #endif


As mentioned on other patch comment, I think this might break your
SOC idle.

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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support

2012-11-03 Thread Santosh Shilimkar


On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote:

AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f

DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In this state, MPU and
PER domains are turned off with the internal RAM held in
retention to facilitate resume process. As part of the boot
process, the assembly code is copied over to OCMCRAM using
the OMAP SRAM code.

AM335x has a Cortex-M3 (WKUP_M3) which assists the MPU
in DeepSleep0 entry and exit. WKUP_M3 takes care of the
clockdomain and powerdomain transitions based on the
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features like DeepSleep.

The IPC mechanism between MPU and WKUP_M3 uses a mailbox
sub-module and 8 IPC registers in the Control module. MPU
uses the assigned Mailbox for issuing an interrupt to
WKUP_M3 which then goes and checks the IPC registers for
the payload. WKUP_M3 has the ability to trigger on interrupt
to MPU by executing the sev instruction.

In the current implementation when the suspend process
is initiated MPU interrupts the WKUP_M3 to let about the
intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received, MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly in
OCMC RAM to put the PLLs in bypass, put the external RAM in
self-refresh mode and then finally execute the WFI instruction.
The WFI instruction triggers another interrupt to the WKUP_M3
which then continues wiht the power down sequence wherein the
clockdomain and powerdomain transition takes place. As part of
the sleep sequence, WKUP_M3 unmasks the interrupt lines for
the wakeup sources. When WKUP_M3 executes WFI, the hardware
disables the main oscillator.

When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence, in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.

The low level code in OCMC relocks the PLLs, enables access
to external RAM and then jumps to the cpu_resume code of
the kernel to finish the resume process.


Nice descriptive change log Vaibhav.



Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
---
  arch/arm/mach-omap2/Makefile|2 +
  arch/arm/mach-omap2/board-generic.c |1 +
  arch/arm/mach-omap2/common.h|   10 +
  arch/arm/mach-omap2/io.c|7 +
  arch/arm/mach-omap2/pm.h|7 +
  arch/arm/mach-omap2/pm33xx.c|  429 ++
  arch/arm/mach-omap2/pm33xx.h|  100 ++
  arch/arm/mach-omap2/sleep33xx.S |  571 +++
  arch/arm/plat-omap/sram.c   |   10 +-
  arch/arm/plat-omap/sram.h   |2 +
  10 files changed, 1138 insertions(+), 1 deletions(-)
  create mode 100644 arch/arm/mach-omap2/pm33xx.c
  create mode 100644 arch/arm/mach-omap2/pm33xx.h
  create mode 100644 arch/arm/mach-omap2/sleep33xx.S

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ae87a3e..80736aa 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -71,6 +71,7 @@ endif
  ifeq ($(CONFIG_PM),y)
  obj-$(CONFIG_ARCH_OMAP2)  += pm24xx.o
  obj-$(CONFIG_ARCH_OMAP2)  += sleep24xx.o
+obj-$(CONFIG_SOC_AM33XX)   += pm33xx.o sleep33xx.o
  obj-$(CONFIG_ARCH_OMAP3)  += pm34xx.o sleep34xx.o
  obj-$(CONFIG_ARCH_OMAP4)  += pm44xx.o omap-mpuss-lowpower.o
  obj-$(CONFIG_SOC_OMAP5)   += omap-mpuss-lowpower.o
@@ -80,6 +81,7 @@ obj-$(CONFIG_POWER_AVS_OMAP)  += sr_device.o
  obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o

  AFLAGS_sleep24xx.o:=-Wa,-march=armv6
+AFLAGS_sleep33xx.o :=-Wa,-march=armv7-a$(plus_sec)
  AFLAGS_sleep34xx.o:=-Wa,-march=armv7-a$(plus_sec)

  ifeq ($(CONFIG_PM_VERBOSE),y)
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..23894df 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -109,6 +109,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened Device 
Tree))
.reserve= omap_reserve,
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
+   .init_late  = am33xx_init_late,
.init_irq   = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine   = omap_generic_init,
diff --git

[PATCH RFC net-next 0/1] Simplify the CPSW DT

2012-11-03 Thread Richard Cochran

This patch is a follow up to show how to remove all the various
register offsets from the DT for the CPSW driver. This applies on top
of the bug fix I posted earlier for IO mapping leak.

Since I am currently awaiting a replacement for my defective
BeagleBone, this patch is compile tested only.

Thanks,
Richard


Richard Cochran (1):
  cpsw: simplify the setup of the register pointers

 Documentation/devicetree/bindings/net/cpsw.txt |   34 
 drivers/net/ethernet/ti/cpsw.c |  209 +--
 include/linux/platform_data/cpsw.h |   19 --
 3 files changed, 82 insertions(+), 180 deletions(-)

-- 
1.7.2.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] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries

2012-11-03 Thread Joel A Fernandes

Hi Gururaja,


On Wed, Oct 31, 2012 at 12:39 AM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
 On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote:
 Hi Gururaja,

 On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
 gururaja.heb...@ti.com wrote:
  Matt,
 
  On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
  6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
  exposes a bug in the AM33XX clock data for mcasp. After moving to
  clk_get() usage, the _init() of all registered hwmods fails on mcasp0
  due to incorrect clock data causing clk_get() to fail. This causes all
  successive hwmods to fail to _init() leaving them in a bad state.
 
  This patch updates the mcasp clock entries so clk_get() will succeed.
  It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
  boot.
 
 
  I want to test Audio on AM335x Evm with your EDMA patches. I have few
  patches for AM335x.
  Can you share the link to the repo  branch on which I need to rebase?
  The patches are related to mcasp dt node, mcasp pinmux in dt, etc...
 

 I was wondering about the status of following patches you wrote, not
 added to mainline yet:

 (1)
  ASoC: Davinci: machine: Add device tree binding
 https://patchwork.kernel.org/patch/1380511/  - will this be resubmitted?

 There was no review comments for V3 I submitted.


 (2)
 ASoC: AM33XX: Add support for AM33xx SoC Audio
 https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d

 I want to re-submit both the patches along with 2 more patch-set [1]. I am
 waiting for Matt Porters to reply with his recent branch, so that I can do
 a final test and re-submit.

 [1].
 arm/dts: Add tlv320aic3x codec DT data to am335x-evm.dts
 arm/dts: add mcasp1 dt node to am335x-evm.dt
 ASoC: davinci-mcasp: Add pinctrl support
 arm/dts: AM33XX: setup pinctrl for mcasp1 on am335x-evm


Thanks, I think I have all of your patches now in my tree, I made a
few more changes to make it compile and run for me on 3.7-rc2

beaglebone_defconfig: Add dummy regulator to init tlv320aic3x
https://github.com/joelagnel/linux-kernel/commit/db5672dfe548d82625cf40ed688d05ba7cee5c93

ASoC: davinci-evm: cpu_dai_of_node has changed to cpu_of_node
https://github.com/joelagnel/linux-kernel/commit/8781c69553d0faf7cec0119e593447f27fdc07e9

I don't get a crash anymore (after correcting mcasp0 base address in
dts), but I still don't get any audio output from the codec. I will
probe the audio signals next week to make sure the I2S output is
correct.

Regards,
Joel
--
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 6/8] arch/arm/mach-omap2/dpll3xxx.c: drop if around WARN_ON

2012-11-03 Thread Julia Lawall

From: Julia Lawall julia.law...@lip6.fr

Just use WARN_ON rather than an if containing only WARN_ON(1).

A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)

// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl

Signed-off-by: Julia Lawall julia.law...@lip6.fr

---
 arch/arm/mach-omap2/dpll3xxx.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index eacf51f..ed855b0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -478,8 +478,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned 
long rate)
if (!soc_is_am33xx()  !cpu_is_omap44xx()  
!cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd-last_rounded_n);
-   if (!freqsel)
-   WARN_ON(1);
+   WARN_ON(!freqsel);
}
 
pr_debug(clock: %s: set rate: locking rate to %lu.\n,

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

2012-11-03 Thread Jean Pihet

Hi Paul,

On Thu, Nov 1, 2012 at 8:51 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
 Hi Paul,

 On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi

 On Wed, 31 Oct 2012, Jean Pihet wrote:

 Paul,
 Could you please check with the 2 calls to PM QoS from the I2C code
 commented out? This will rule out the PM QoS impact.

 Will be happy to do a test run for you, after the boot log from your local
 test run is posted:

 http://marc.info/?l=linux-arm-kernelm=135167153510814w=2

Here are some more details after investigation.

The setup is as identical as possible to yours:
- U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58) from
http://www.pwsan.com/tmp/3530es3beagle-MLO-u-boot-20121023.tar.bz2.
  Please note that the MLO image does not run on my board and so I had
to use my known-to-work image.
- 3.7.0-rc1 kernel, omap2plus_defconfig,
- same kernel parameters,
- Angstrom rootfs from
http://www.pwsan.com/tmp/20121023-beagleboard-angstrom-userspace.tar.bz2

The differences are:
- OMAP revision (ES2.1 vs ES3.0),
- Beagleboard revision (B5 vs Cx),
- RAM amount (128 vs 256MB),
- compiler: gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) vs 4.5.2
(Sourcery G++ Lite 2011.03-41)

The result is that I could reproduce the issue but it happens much
more rarely on my side (only once vs quasi 100% on ~50 boot cycles).
The issue is triggered by running 'hwclock --systohc'  while the
system is heavily loaded (running depmod etc.). The system recovers
nicely after the issue, the RTC can be used correctly later on.

Here is the log:

U-Boot 2011.06-dirty (Sep 04 2012 - 17:06:58)

OMAP3530-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  128 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
In:serial
Out:   serial
Err:   serial
Beagle Rev Ax/Bx
timed out in wait_for_pin: I2C_STAT=0
I2C read: I/O error
Unrecognized expansion board: 0
Die ID #0f6204013ef109008009
Hit any key to stop autoboot:  0
reading uimage

4148008 bytes read
## Booting kernel from Legacy Image at 8030 ...
   Image Name:   Linux-3.7.0-rc1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4147944 Bytes = 4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.7.0-rc1 (def@rachael) (gcc version
4.5.2 (Sourcery G++ Lite 2011.03-41) ) #2 SMP Sat Nov 3 21:56:11 CET
2012
[0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT
nonaliasing instruction cache
[0.00] Machine: OMAP3 Beagle Board
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[0.00] PERCPU: Embedded 9 pages/cpu @c0e4 s12928 r8192 d15744 u36864
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 32256
[0.00] Kernel command line: console=ttyO2,230400n8
root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 127MB = 127MB total
[0.00] Memory: 115316k/115316k available, 15756k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xc880 - 0xff00   ( 872 MB)
[0.00] lowmem  : 0xc000 - 0xc800   ( 128 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc07037dc   (7150 kB)
[0.00]   .init : 0xc0704000 - 0xc0754280   ( 321 kB)
[0.00]   .data : 0xc0756000 - 0xc07e15a0   ( 558 kB)
[0.00].bss : 0xc07e15c4 - 0xc0d3bfac   (5483 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96
interrupts
[0.00] Total of 96 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER12 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns,
wraps every 131071999ms
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES:  8
[

[매일경제신문사] 바이러스- 발견 경고

2012-11-03 Thread Administrator

발신자 : linux-omap@vger.kernel.org
수신자 : PSYON
제목 : Returned mail: Data format error
첨부 파일명 : mail.zip(mail.doc  

.com)
검사 결과 : mail.zip/mail.doc   

   .com ( Win32/MyDoom.worm.M ) - 압축 파일(압축을 푼 후 다시 검사하십시오.)
mail.zip - 삭제


안녕하세요. 
매일경제신문사 메일서버 관리자입니다.
보내주신 메일에서 바이러스가 발견되었습니다.
치료가 가능하면 치료를 시도하고 불가능하면 삭제됩니다.
본 메일은 자동으로 보내지며 반송이 불가능합니다.

42 matches

Mail list logo