date:20101012

Re: [PATCH v7] power: introduce library for device-specific OPPs

2010-10-12 Thread Nishanth Menon


Rafael J. Wysocki had written, on 10/12/2010 06:25 PM, the following:

On Tuesday, October 12, 2010, Rafael J. Wysocki wrote:

On Monday, October 11, 2010, Nishanth Menon wrote:

Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
[...]

Signed-off-by: Nishanth Menon 

OK

Your error messages are a bit inconsistent (e.g. some of them print the
error code while others don't), but I guess I can fix that up.

Thanks a bunch.

Still, to apply the patch I need a copyright notice for the doc too.

oops..
(C) 2009-2010 Nishanth Menon , Texas Instruments Incorporated
Does this help?

Yes, it does.


or would you like me to post a v8 as well?

That shouldn't be necessary.


The patch has been applied to suspend-2.6/linux-next at:

http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=commit;h=56149b574181d98aedf97f1f2d91d05ab261db41

with minor changes around the error messages.  Please double check if everything
is correct.

Thanks Rafael. I confirm changes are correct.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7] power: introduce library for device-specific OPPs

2010-10-12 Thread Rafael J. Wysocki

On Tuesday, October 12, 2010, Rafael J. Wysocki wrote:
> On Monday, October 11, 2010, Nishanth Menon wrote:
> > Rafael J. Wysocki had written, on 10/09/2010 05:59 PM, the following:
> > [...]
> > >>
> > >> Signed-off-by: Nishanth Menon 
> > > 
> > > OK
> > > 
> > > Your error messages are a bit inconsistent (e.g. some of them print the
> > > error code while others don't), but I guess I can fix that up.
> > Thanks a bunch.
> > > 
> > > Still, to apply the patch I need a copyright notice for the doc too.
> > oops..
> > (C) 2009-2010 Nishanth Menon , Texas Instruments Incorporated
> > Does this help?
> 
> Yes, it does.
> 
> > or would you like me to post a v8 as well?
> 
> That shouldn't be necessary.

The patch has been applied to suspend-2.6/linux-next at:

http://git.kernel.org/?p=linux/kernel/git/rafael/suspend-2.6.git;a=commit;h=56149b574181d98aedf97f1f2d91d05ab261db41

with minor changes around the error messages.  Please double check if everything
is correct.

Thanks,
Rafael
--
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 PATCHv3 2/7] OMAP SSI: Introducing OMAP SSI driver

2010-10-12 Thread Tony Lindgren

* Carlos Chinea  [101011 01:58]:
> Introduces the OMAP SSI driver in the kernel.
> 
> The Synchronous Serial Interface (SSI) is a legacy version
> of HSI. As in the case of HSI, it is mainly used to connect
> Application engines (APE) with cellular modem engines (CMT)
> in cellular handsets.
> 
> It provides a multichannel, full-duplex, multi-core communication
> with no reference clock. The OMAP SSI block is capable of reaching
> speeds of 110 Mbit/s.
> 
> Signed-off-by: Carlos Chinea 

> --- /dev/null
> +++ b/arch/arm/mach-omap2/ssi.c

> +static struct resource ssi_resources[] = {
> + /* SSI controller */
> + [0] = {
> + .start  = 0x48058000,
> + .end= 0x48058fff,
> + .name   = "omap_ssi_sys",
> + .flags  = IORESOURCE_MEM,
> + },
> + /* GDD */
> + [1] = {
> + .start  = 0x48059000,
> + .end= 0x48059fff,
> + .name   = "omap_ssi_gdd",
> + .flags  = IORESOURCE_MEM,
> + },
> + [2] = {
> + .start  = 71,
> + .end= 71,
> + .name   = "ssi_gdd",
> + .flags  = IORESOURCE_IRQ,
> + },
> + /* SSI port 1 */
> + [3] = {
> + .start  = 0x4805a000,
> + .end= 0x4805a7ff,
> + .name   = "omap_ssi_sst1",
> + .flags  = IORESOURCE_MEM,
> + },
> + [4] = {
> + .start  = 0x4805a800,
> + .end= 0x4805afff,
> + .name   = "omap_ssi_ssr1",
> + .flags  = IORESOURCE_MEM,
> + },
> + [5] = {
> + .start  = 67,
> + .end= 67,
> + .name   = "ssi_p1_mpu_irq0",
> + .flags  = IORESOURCE_IRQ,
> + },
> + [6] = {
> + .start  = 69,
> + .end= 69,
> + .name   = "ssi_p1_mpu_irq1",
> + .flags  = IORESOURCE_IRQ,
> + },
> + [7] = {
> + .start  = 0,
> + .end= 0,
> + .name   = "ssi_p1_cawake",
> + .flags  = IORESOURCE_IRQ | IORESOURCE_UNSET,
> + },
> +};

Are these resources the same for omap2, 3 & 4?

> +static void ssi_pdev_release(struct device *dev)
> +{
> +}

Not needed.

> +static struct platform_device ssi_pdev = {
> + .name   = "omap_ssi",
> + .id = 0,
> + .num_resources  = ARRAY_SIZE(ssi_resources),
> + .resource   = ssi_resources,
> + .dev= {
> + .release= ssi_pdev_release,
> + .platform_data  = &ssi_pdata,
> + },
> +};

Dummy release not needed here either.

> +static int __init ssi_init(void)
> +{
> + return platform_device_register(&ssi_pdev);
> +}
> +subsys_initcall(ssi_init);

This will probably cause trouble on omap2 and 4?

To me it seems that you should at least return early on the unsupported
platforms.

You might want to consider updating this for omap hwmod as it will
automate the platform_device and PM related issues to some extent.

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 v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo

2010-10-12 Thread Tony Lindgren

* Stephan Linz  [101012 12:11]:
> Am Montag, 11. Oktober 2010, um 20:40:51 schrieb Ashwin Bihari:
> > On Mon, Oct 11, 2010 at 1:45 PM, Tim Nordell  
> wrote:
> > >  On 10/11/10 12:30, Tony Lindgren wrote:
> > >> Uhh, so whose patches are these originally?
> > >>
> > >> We have them now queued with Tim Nordell as the author. Please let me
> > >> know ASAP if you want me to change that.
> 
> Hi Tony,
> 
> No, I don't want to change anything. Only the LogicPD employees should be 
> named inside the pathes as far as the patches are not a direct pull from my 
> own devel tree on Gitorious. Ashwin has done a good explanation of the 
> situation.

OK, thanks everybody, keeping the commits as they are.

Regards,

Tony

> 
> 
> - Stephan
> 
> 
> > >>
> > >> Regards,
> > >>
> > >> Tony
> > >
> > > The history for those patches, for me, originated with Jacob Tanenbaum's
> > > patchset.  I was taking over for him as he was going back to school.  I
> > > did some misc. changes for further submission, but I was not the
> > > original author.  I don't know Stephan's involvement - however, in the
> > > source files he's attributed credit in the header, as well as one of my
> > > coworkers so presumably there was some involvement on both ends.  I
> > > recognize some of the code as coming from our kernel release, so likely
> > > it was a hybrid originally between Stephan, Peter, and Jacob.
> > >
> > > That's about the extent that I know.
> > >
> > > - Tim
> >
> > Tony,
> >
> > LogicPD engineers did the initial porting and then Stephan Linz
> > re-started the work on the, then recent, 2.6.32 Kernel using our BSP
> > as a starting point. He was kind enough to send those LogicPD and we
> > began putting it together against the latest Linux Kernel for
> > inclusion and that was done by Jacob over the summer and finished off
> > by Tim.
> >
> > Stephan Linz is credited in the patch and Peter Barada (another
> > LogicPD employee) is listed as the maintainer though his part (along
> > with me) in getting these specific patches out have been more behind
> > the scenes. So having the names listed as they are now is OK.
> >
> > In the upcoming months we will be pushing out additional support for
> > the LogicPD's boards and it will most likely come up a variety of
> > LogicPD engineers depending on our workload..
> >
> > Thanks
> > -- Ashwin
> 
> 
> -- 
> Viele Grüße,
> Stephan Linz
> __
> OpenDCC: http://www.li-pro.net/opendcc.phtml
> PC/M: http://www.li-pro.net/pcm.phtml
> CDK4AVR: http://cdk4avr.sourceforge.net/
> CDK4NIOS: http://cdk4nios.sourceforge.net/
> CDK4MSP: http://cdk4msp.sourceforge.net/
> CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control

2010-10-12 Thread Tony Lindgren

* Felipe Contreras  [101012 03:52]:
> On Tue, Oct 12, 2010 at 12:35 AM, Paul Walmsley  wrote:
> > On Mon, 11 Oct 2010, Tony Lindgren wrote:
> >> Would be nice to get the dspbridge into working shape. Sounds we still
> >> need the following:
> >>
> >> - memblock fixes
> >> - this series to fix the control module related issues
> >> - platform data for the boards
> >>
> >> Is that all, or are we also missing something else?
> >
> > A few other things should be done also.
> >
> > 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in
> > the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should
> > be moved into a file in arch/arm/mach-omap2.  The DSPBridge driver should
> > call those functions (to reset the DSP, start it, etc.) through
> > platform_data function pointers.  Once that happens, patch 3 of the
> > control module-related series would not be needed, since that code would
> > be in arch/arm/mach-omap2 anyway.
> >
> > 2. The direct CM/PRM/RM register access should be removed from that
> > arch/arm/mach-omap2 code.  That should be handled directly by the
> > clock/hwmod/whatever code.
> >
> > 3. DSPBridge should be converted to use PM runtime, and the
> > arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc.
> 
> Before starting to clean things up, I would rather have something that
> works, which AFAIK includes:
> 
>  1) revert or fix iommu migration
>  2) fix ioremap() usage on RAM
> 
> Only then we can have some minimal confidence that the cleaning up is
> not introducing further breakage.

Well we should get it working, but we should also do it in a sane way :)

I guess you're now looking into this patch from Russell?

https://patchwork.kernel.org/patch/245631/

Regards,

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

[GIT PULL] one omap fix for 2.6.36

2010-10-12 Thread Tony Lindgren

Hi Linus,

Please pull a one-liner from:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-fixes-for-linus

Regards,

Tony


The following changes since commit cb655d0f3d57c23db51b981648e452988c0223f9:

  Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git 
omap-fixes-for-linus

Hari Kanigeri (1):
  omap: iommu-load cam register before flushing the entry

 arch/arm/plat-omap/iommu.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

2010-10-12 Thread Tony Lindgren

* Jarkko Nikula  [101012 06:42]:
> On Tue, 12 Oct 2010 14:29:48 +0100
> Mark Brown  wrote:
> 
> > On Tue, Oct 12, 2010 at 06:57:58PM +0530, Anand Gadiyar wrote:
> > > Commit 346a5c890 (OMAP: control: move plat-omap/control.h
> > > to mach-omap2/control.h) in the linux-omap tree removed
> > > plat/control.h and most of its callers. This one slipped
> > > through - breaking the build as below when
> > > CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.
> > 
> > Acked-by: Mark Brown 
> 
> Tony, Liam: This must come via linux-omap together with other Paul's
> patches. Does not conflict with ASoC multi-component change.
> 
> Acked-by: Jarkko Nikula 

Thanks, adding into omap-for-linus.

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] serial: omap-serial: fix signess error

2010-10-12 Thread Tony Lindgren

* Kevin Hilman  [101012 11:30]:
> [adding linux-omap list]
> 
> Vasiliy Kulikov  writes:
> 
> > "ret" is unsigned, so check for (ret < 0) made no sense.
> > Made it signed.
> >
> > Signed-off-by: Vasiliy Kulikov 
> > ---
> >  I cannot compile this driver, so it is not tested.
> 
> Acked-by: Kevin Hilman 
> 
> Since the original driver is being queued via the omap tree, we can
> queue this one as well.
> 
> Tony, can you add this one to the 2.6.37 queue?

Thanks, adding into omap-for-linus.

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 v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo

2010-10-12 Thread Stephan Linz

Am Montag, 11. Oktober 2010, um 20:40:51 schrieb Ashwin Bihari:
> On Mon, Oct 11, 2010 at 1:45 PM, Tim Nordell  
wrote:
> >  On 10/11/10 12:30, Tony Lindgren wrote:
> >> Uhh, so whose patches are these originally?
> >>
> >> We have them now queued with Tim Nordell as the author. Please let me
> >> know ASAP if you want me to change that.

Hi Tony,

No, I don't want to change anything. Only the LogicPD employees should be 
named inside the pathes as far as the patches are not a direct pull from my 
own devel tree on Gitorious. Ashwin has done a good explanation of the 
situation.


- Stephan


> >>
> >> Regards,
> >>
> >> Tony
> >
> > The history for those patches, for me, originated with Jacob Tanenbaum's
> > patchset.  I was taking over for him as he was going back to school.  I
> > did some misc. changes for further submission, but I was not the
> > original author.  I don't know Stephan's involvement - however, in the
> > source files he's attributed credit in the header, as well as one of my
> > coworkers so presumably there was some involvement on both ends.  I
> > recognize some of the code as coming from our kernel release, so likely
> > it was a hybrid originally between Stephan, Peter, and Jacob.
> >
> > That's about the extent that I know.
> >
> > - Tim
>
> Tony,
>
> LogicPD engineers did the initial porting and then Stephan Linz
> re-started the work on the, then recent, 2.6.32 Kernel using our BSP
> as a starting point. He was kind enough to send those LogicPD and we
> began putting it together against the latest Linux Kernel for
> inclusion and that was done by Jacob over the summer and finished off
> by Tim.
>
> Stephan Linz is credited in the patch and Peter Barada (another
> LogicPD employee) is listed as the maintainer though his part (along
> with me) in getting these specific patches out have been more behind
> the scenes. So having the names listed as they are now is OK.
>
> In the upcoming months we will be pushing out additional support for
> the LogicPD's boards and it will most likely come up a variety of
> LogicPD engineers depending on our workload..
>
> Thanks
> -- Ashwin


-- 
Viele Grüße,
Stephan Linz
__
OpenDCC: http://www.li-pro.net/opendcc.phtml
PC/M: http://www.li-pro.net/pcm.phtml
CDK4AVR: http://cdk4avr.sourceforge.net/
CDK4NIOS: http://cdk4nios.sourceforge.net/
CDK4MSP: http://cdk4msp.sourceforge.net/
CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L
--
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] serial: omap-serial: fix signess error

2010-10-12 Thread Kevin Hilman

[adding linux-omap list]

Vasiliy Kulikov  writes:

> "ret" is unsigned, so check for (ret < 0) made no sense.
> Made it signed.
>
> Signed-off-by: Vasiliy Kulikov 
> ---
>  I cannot compile this driver, so it is not tested.

Acked-by: Kevin Hilman 

Since the original driver is being queued via the omap tree, we can
queue this one as well.

Tony, can you add this one to the 2.6.37 queue?

Thanks,

Kevin

>  drivers/serial/omap-serial.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
> index 2ee1d32..14365f7 100644
> --- a/drivers/serial/omap-serial.c
> +++ b/drivers/serial/omap-serial.c
> @@ -1055,7 +1055,7 @@ static void serial_omap_rx_timeout(unsigned long 
> uart_no)
>  {
>   struct uart_omap_port *up = ui[uart_no];
>   unsigned int curr_dma_pos, curr_transmitted_size;
> - unsigned int ret = 0;
> + int ret = 0;
>  
>   curr_dma_pos = omap_get_dma_dst_pos(up->uart_dma.rx_dma_channel);
>   if ((curr_dma_pos == up->uart_dma.prev_rx_dma_pos) ||
--
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] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n

2010-10-12 Thread Kevin Hilman

"Cousson, Benoit"  writes:

> Adding more folks to the discussion.
>
> On 10/12/2010 9:30 AM, Varadarajan, Charulatha wrote:
>>
>>> From: Cousson, Benoit
>>> Sent: Tuesday, October 12, 2010 12:45 PM
>>> To: Varadarajan, Charulatha
>>>
>>> Hi Charu,
>>>
>>> On 10/11/2010 2:02 PM, Varadarajan, Charulatha wrote:
 Fix the below warning during boot

 [0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185
>>> _omap_hwmod_enable+0x34/0x150()
 [0.00] omap_hwmod: wd_timer2: enabled state can only be entered
>>> from initialized, idle, or disabled state
 [0.00] Modules linked in:
 [0.00] [] (unwind_backtrace+0x0/0xe4) from
>>> [] (warn_slowpath_common+0x4c/0x64)
 [0.00] [] (warn_slowpath_common+0x4c/0x64) from
>>> [] (warn_slowpath_fmt+0x2c/0x3c)
 [0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from
>>> [] (_omap_hwmod_enable+0x34/0x150)
 [0.00] [] (_omap_hwmod_enable+0x34/0x150) from
>>> [] (omap_hwmod_enable+0x28/0x3c)
 [0.00] [] (omap_hwmod_enable+0x28/0x3c) from
>>> [] (omap2_disable_wdt+0x48/0xdc)
 [0.00] [] (omap2_disable_wdt+0x48/0xdc) from
>>> [] (omap_hwmod_for_each_by_class+0x60/0xa4)
 [0.00] [] (omap_hwmod_for_each_by_class+0x60/0xa4)
>>> from [] (omap2_init_devices+0x44/0x330)
 [0.00] [] (omap2_init_devices+0x44/0x330) from
>>> [] (do_one_initcall+0xcc/0x1a4)
 [0.00] [] (do_one_initcall+0xcc/0x1a4) from
>>> [] (kernel_init+0x148/0x210)
 [0.00] [] (kernel_init+0x148/0x210) from []
>>> (kernel_thread_exit+0x0/0x8)
 [0.00] ---[ end trace 1b75b31a2719ed1f ]---
 [0.00] wd_timer2: Could not enable clocks for omap2_disable_wdt

 When CONFIG_PM_RUNTIME is not defined, watchdog timer clocks are not
 disabled after a watchdog reset. Hence in omap2_disable_wdt(), it is
 not required to enable clocks before accessing the watchdog timer
 registers if CONFIG_PM_RUNTIME is not defined.
>>>
>>> I'm not a big fan of adding some dependencies with CONFIG_PM_RUNTIME
>>> inside this code.
>>>
>>> The real root cause is not CONFIG_PM_RUNTIME, but mostly the
>>> skip_setup_idle variable added in arch/arm/mach-omap2/io.c by Paul.
>>
>> Yes.
>>
>>>
>>> So I'd rather use that parameter as an input for the omap2_disable_wdt.
>>
>> I also thought about this, but we need to
>>
>> 1. call omap2_disable_wdt() in omap2_init_common_hw() rather than
>> omap2_init_devices(). That would involve movement of
>> omap2_disable_wdt() from devices.c to io.c.
>> (or)
>> 2. make skip_setup_idle global
>> (or)
>> 3. make omap2_disable_wdt() global and call it from
>> omap2_init_common_hw() and pass skip_setup_idle as parameter.
>>
>> I felt that the usage of CONFIG_PM_RUNTIME is better than the above.
>> But still we may consider any of the above options or any other
>> option. Please suggest.
>
> It is maybe easier, but I don't think it is better...
>
> As I said, CONFIG_PM_RUNTIME is not the root cause of your issue, just
> an indirect cause. OK, maybe strictly speaking, it is the root cause,
> since it started for that... but that not the cause that we should
> consider in your case.
>
> If we decide to remove that CONFIG_PM_RUNTIME dependency in the io /
> hwmod code, nobody will be able to find the relation with your code in
> WDT.
>
> That's why you should not do that, for my point of view.
>
> Paul, Kevin,
> Any thoughts on that point?

I agree that this is not strictly a dependency on PM_RUNTIME.

What's really needed is a way for low-level hwmod users like this to be
able to check whether the hwmod is already enabled.  Something like this
(completely untested):

bool omap_hwmod_is_enabled(struct omap_hwmod *oh)
{
return (oh->_state == _HWMOD_STATE_ENABLED);
}

Alternatively, maybe calling omap_hwmod_enable() when the state is
already enabled should not be so verbose, and it should just return
success, but that option needs a little more thought...

Kevin

>>
>>>
>>> Regards,
>>> Benoit
>>>
>>>
>>>

 Tested on OMAP3430 SDP and OMAP4430 SDP.

 Signed-off-by: Charulatha V
 ---
arch/arm/mach-omap2/devices.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
>>> omap2/devices.c
 index eaf3799..b592952 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -926,7 +926,7 @@ static inline void omap_init_vout(void) {}
static int omap2_disable_wdt(struct omap_hwmod *oh, void *unused)
{
void __iomem *base;
 -  int ret;
 +  int ret = 0;

if (!oh) {
pr_err("%s: Could not look up wdtimer_hwmod\n", 
 __func__);
 @@ -940,6 +940,7 @@ static int omap2_disable_wdt(struct omap_hwmod *oh,
>>> void *unused)
return -EINVAL;
}

 +#ifdef CONFIG_PM_RUNTIME

Re: [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

2010-10-12 Thread Paul Walmsley

On Tue, 12 Oct 2010, Anand Gadiyar wrote:

> Commit 346a5c890 (OMAP: control: move plat-omap/control.h
> to mach-omap2/control.h) in the linux-omap tree removed
> plat/control.h and most of its callers. This one slipped
> through - breaking the build as below when
> CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.
> 
>   CC  sound/soc/omap/omap-mcpdm.o
> sound/soc/omap/omap-mcpdm.c:35: fatal error: plat/control.h: No such file or 
> directory
> compilation terminated.
> make[3]: *** [sound/soc/omap/omap-mcpdm.o] Error 1
> make[2]: *** [sound/soc/omap] Error 2
> make[1]: *** [sound/soc] Error 2
> make: *** [sound] Error 2
> 
> Signed-off-by: Anand Gadiyar 
> Cc: Misael Lopez Cruz 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Paul Walmsley 
> Cc: Tony Lindgren 
> ---
> This break is reproducible on linux-next as of 20101011;
> I think it also exists in mainline, but I did not check.
> 
> Probably worth taking this through the ALSA tree with Tony
> or Paul's ack. 

Acked-by: Paul Walmsley 

thanks Anand,


- 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: [PATCHv3 00/11] staging tidspbridge: iommu migration

2010-10-12 Thread Guzman Lugo, Fernando

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] 
> Sent: Tuesday, October 12, 2010 6:21 AM
> To: Guzman Lugo, Fernando
> Cc: gre...@suse.de; felipe.contre...@nokia.com; 
> ameya.pala...@nokia.com; Menon, Nishanth; 
> hiroshi.d...@nokia.com; o...@wizery.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org
> Subject: Re: [PATCHv3 00/11] staging tidspbridge: iommu migration
> 
> On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando 
>  wrote:
> >> On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo 
> >>  wrote:
> >> > This set of patches remove the dspbridge custom mmu
> >> implementation and
> >> > use iommu module instead.
> >>
> >> I have tried this, it works for simple tests, but not real 
> use-cases.
> >> I applied all your iommu patches. How did you test this?
> >
> > Have you applied:
> >
> > - "scatterlist: define SG chain for arm architecture"
> > - "iovmm: replace __iounmap with omap_iounmap"
> > - "iovmm: add superpages support to fixed da address"
> > - "iovmm: IVA2 MMU range is from 0x1100 to 0x"
> > - "iovmm: no gap checking for fixed address"
> 
> Yes.
> 
> > Also make sure your baseline have this patch:
> >
> > - "omap:iommu-load cam register before flushing the entry"
> 
> Huh? That's not even in v2.6.36-rc7, in which baseline is 
> this supposed to be in? Anyway, I'll try adding that.

That's is in latest Hiroshi's tree and it is really needed, Otherwise
You will have wrong traslations which can cause unexpected behavior.


> 
> > What kind of error are you getting?
> 
> Node allocation failing IIRC.

Is it falling to map the Heap??
I mean you see this trace?

if (status)
pr_err("%s: Failed to map memory for Heap: 0x%x\n",
   __func__, status);

Otherwise, I don't see how that fail is related with iommu changes.

> 
> > I don't have a complete framework to test MM testcases at 
> this moment
> 
> See:
> http://felipec.wordpress.com/2010/10/08/my-arm-development-notes/
> 
> I even prepared a tarball so you just need to extract it on 
> your device. It's not difficult to test this with GStreamer, 
> and I don't see how you can be confident that they indeed 
> work without testing some real use-cases. Anyway, I'll try 
> that missing patch.

Most of time real use-cases are not so stressing like testcases
We can make to test under real stress in order to find out corner cases.
However when I test it was pretty stable and just few erros because staging
Does not have latest mailbox patches. Also I test in a .35 version of staging.
So now I am using a branch with all new patches and I will recheck and test
Again any possible issue. Also I will look at your gstreamer fail too.


Regards,
Fernando.

> 
> Cheers.
> 
> --
> Felipe Contreras
> --
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: [PATCHv2 2/3] iovmm: add superpages support to fixed da address

2010-10-12 Thread Guzman Lugo, Fernando

 

> -Original Message-
> From: Felipe Contreras [mailto:felipe.contre...@gmail.com] 
> Sent: Tuesday, October 12, 2010 6:09 AM
> To: Guzman Lugo, Fernando
> Cc: hiroshi.d...@nokia.com; david.co...@nokia.com; 
> felipe.contre...@nokia.com; ameya.pala...@nokia.com; 
> linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; 
> linux-omap@vger.kernel.org
> Subject: Re: [PATCHv2 2/3] iovmm: add superpages support to 
> fixed da address
> 
> On Mon, Oct 11, 2010 at 6:33 PM, Guzman Lugo, Fernando 
>  wrote:
> >> > @@ -420,7 +431,8 @@ static void sgtable_fill_kmalloc(struct
> >> sg_table
> >> > *sgt, u32 pa, size_t len)
> >> >        for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> >> >                size_t bytes;
> >> >
> >> > -               bytes = iopgsz_max(len);
> >> > +               bytes = max_alignment(da | pa);
> >> > +               bytes = min(bytes, (size_t)iopgsz_max(len));
> >>
> >> Why the size_t casting?
> >
> > To void this warning:
> > arch/arm/plat-omap/iovmm.c:440: warning: comparison of distinct 
> > pointer types lacks a cast
> 
> But how is that possible? iopgsz_max is returning constants, 
> like SZ_1M, so they should not need casts, if anything, the 
> cast should be done in iopgsz_max itself.

The min macro make a "typeof" of the parameter, so the typeof of a 
Constants should be int I think and that's the reason of the warning.

I can use min_t instead to avoid the warning, something like this:

bytes = min_t(size_t, bytes, iopgsz_max(len));

What do you think?

Regards,
Fernando.

> 
> --
> Felipe Contreras
> --
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: [alsa-devel] [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

2010-10-12 Thread Jarkko Nikula

On Tue, 12 Oct 2010 14:29:48 +0100
Mark Brown  wrote:

> On Tue, Oct 12, 2010 at 06:57:58PM +0530, Anand Gadiyar wrote:
> > Commit 346a5c890 (OMAP: control: move plat-omap/control.h
> > to mach-omap2/control.h) in the linux-omap tree removed
> > plat/control.h and most of its callers. This one slipped
> > through - breaking the build as below when
> > CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.
> 
> Acked-by: Mark Brown 

Tony, Liam: This must come via linux-omap together with other Paul's
patches. Does not conflict with ASoC multi-component change.

Acked-by: Jarkko Nikula 
--
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] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

2010-10-12 Thread Mark Brown

On Tue, Oct 12, 2010 at 06:57:58PM +0530, Anand Gadiyar wrote:
> Commit 346a5c890 (OMAP: control: move plat-omap/control.h
> to mach-omap2/control.h) in the linux-omap tree removed
> plat/control.h and most of its callers. This one slipped
> through - breaking the build as below when
> CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.

Acked-by: Mark Brown 
--
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] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

2010-10-12 Thread Anand Gadiyar

Commit 346a5c890 (OMAP: control: move plat-omap/control.h
to mach-omap2/control.h) in the linux-omap tree removed
plat/control.h and most of its callers. This one slipped
through - breaking the build as below when
CONFIG_SND_OMAP_SOC_MCPDM is defined. Fix this.

  CC  sound/soc/omap/omap-mcpdm.o
sound/soc/omap/omap-mcpdm.c:35: fatal error: plat/control.h: No such file or 
directory
compilation terminated.
make[3]: *** [sound/soc/omap/omap-mcpdm.o] Error 1
make[2]: *** [sound/soc/omap] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2

Signed-off-by: Anand Gadiyar 
Cc: Misael Lopez Cruz 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Paul Walmsley 
Cc: Tony Lindgren 
---
This break is reproducible on linux-next as of 20101011;
I think it also exists in mainline, but I did not check.

Probably worth taking this through the ALSA tree with Tony
or Paul's ack. 

I'm not subscribed to the alsa list. Please CC me on replies.

 sound/soc/omap/omap-mcpdm.c |1 -
 1 file changed, 1 deletion(-)

Index: mainline/sound/soc/omap/omap-mcpdm.c
===
--- mainline.orig/sound/soc/omap/omap-mcpdm.c
+++ mainline/sound/soc/omap/omap-mcpdm.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include "mcpdm.h"
--
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] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n

2010-10-12 Thread Cousson, Benoit

Adding more folks to the discussion.

On 10/12/2010 9:30 AM, Varadarajan, Charulatha wrote:

From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 12:45 PM
To: Varadarajan, Charulatha

Hi Charu,

On 10/11/2010 2:02 PM, Varadarajan, Charulatha wrote:

Fix the below warning during boot

[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185

_omap_hwmod_enable+0x34/0x150()

[0.00] omap_hwmod: wd_timer2: enabled state can only be entered

from initialized, idle, or disabled state

[0.00] Modules linked in:
[0.00] [] (unwind_backtrace+0x0/0xe4) from

[] (warn_slowpath_common+0x4c/0x64)

[0.00] [] (warn_slowpath_common+0x4c/0x64) from

[] (warn_slowpath_fmt+0x2c/0x3c)

[0.00] [] (warn_slowpath_fmt+0x2c/0x3c) from

[] (_omap_hwmod_enable+0x34/0x150)

[0.00] [] (_omap_hwmod_enable+0x34/0x150) from

[] (omap_hwmod_enable+0x28/0x3c)

[0.00] [] (omap_hwmod_enable+0x28/0x3c) from

[] (omap2_disable_wdt+0x48/0xdc)

[0.00] [] (omap2_disable_wdt+0x48/0xdc) from

[] (omap_hwmod_for_each_by_class+0x60/0xa4)

[0.00] [] (omap_hwmod_for_each_by_class+0x60/0xa4)

from [] (omap2_init_devices+0x44/0x330)

[0.00] [] (omap2_init_devices+0x44/0x330) from

[] (do_one_initcall+0xcc/0x1a4)

[0.00] [] (do_one_initcall+0xcc/0x1a4) from

[] (kernel_init+0x148/0x210)

[0.00] [] (kernel_init+0x148/0x210) from []

(kernel_thread_exit+0x0/0x8)

[0.00] ---[ end trace 1b75b31a2719ed1f ]---
[0.00] wd_timer2: Could not enable clocks for omap2_disable_wdt

When CONFIG_PM_RUNTIME is not defined, watchdog timer clocks are not
disabled after a watchdog reset. Hence in omap2_disable_wdt(), it is
not required to enable clocks before accessing the watchdog timer
registers if CONFIG_PM_RUNTIME is not defined.

I'm not a big fan of adding some dependencies with CONFIG_PM_RUNTIME
inside this code.

The real root cause is not CONFIG_PM_RUNTIME, but mostly the
skip_setup_idle variable added in arch/arm/mach-omap2/io.c by Paul.

Yes.

So I'd rather use that parameter as an input for the omap2_disable_wdt.

I also thought about this, but we need to

1. call omap2_disable_wdt() in omap2_init_common_hw() rather than
omap2_init_devices(). That would involve movement of
omap2_disable_wdt() from devices.c to io.c.
(or)
2. make skip_setup_idle global
(or)
3. make omap2_disable_wdt() global and call it from
omap2_init_common_hw() and pass skip_setup_idle as parameter.

I felt that the usage of CONFIG_PM_RUNTIME is better than the above.
But still we may consider any of the above options or any other
option. Please suggest.

It is maybe easier, but I don't think it is better...

As I said, CONFIG_PM_RUNTIME is not the root cause of your issue, just 
an indirect cause. OK, maybe strictly speaking, it is the root cause, 
since it started for that... but that not the cause that we should 
consider in your case.

If we decide to remove that CONFIG_PM_RUNTIME dependency in the io / 
hwmod code, nobody will be able to find the relation with your code in WDT.

That's why you should not do that, for my point of view.

Paul, Kevin,
Any thoughts on that point?

Thanks,
Benoit

Regards,
Benoit

Tested on OMAP3430 SDP and OMAP4430 SDP.

Signed-off-by: Charulatha V
---
   arch/arm/mach-omap2/devices.c |6 +-
   1 files changed, 5 insertions(+), 1 deletions(-)

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

omap2/devices.c

index eaf3799..b592952 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -926,7 +926,7 @@ static inline void omap_init_vout(void) {}
   static int omap2_disable_wdt(struct omap_hwmod *oh, void *unused)
   {
void __iomem *base;
-   int ret;
+   int ret = 0;

if (!oh) {
pr_err("%s: Could not look up wdtimer_hwmod\n", __func__);
@@ -940,6 +940,7 @@ static int omap2_disable_wdt(struct omap_hwmod *oh,

void *unused)

return -EINVAL;
}

+#ifdef CONFIG_PM_RUNTIME
/* Enable the clocks before accessing the WDT registers */
ret = omap_hwmod_enable(oh);
if (ret) {
@@ -947,6 +948,7 @@ static int omap2_disable_wdt(struct omap_hwmod *oh,

void *unused)

oh->name, __func__);
return ret;
}
+#endif

/* sequence required to disable watchdog */
__raw_writel(0x, base + OMAP_WDT_SPR);
@@ -957,10 +959,12 @@ static int omap2_disable_wdt(struct omap_hwmod *oh,

void *unused)

while (__raw_readl(base + OMAP_WDT_WPS)&   0x10)
cpu_relax();

+#ifdef CONFIG_PM_RUNTIME
ret = omap_hwmod_idle(oh);
if (ret)
pr_err("%s: Could not disable clocks for %s\n",
oh->name, __func__);
+#endif

return ret;
   }

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo inf

Re: [PATCH] omap3: various code improvements for IGEP v2 board.

2010-10-12 Thread Felipe Balbi


On Tue, Oct 12, 2010 at 05:16:10AM -0500, Enric Balletbo i Serra wrote:

The comments of this post also apply to IGEP v2 board (thanks Laurent)

 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36402.html

Changes are:

 - Set onenand_setup to NULL instead of adding a no-op function.
 - On igep2_flash_init() function:
   - Use 'for' loop instead 'while' loop.
   - No need to initialize ret to 0, we're assigning it right after.
   - No need to check for onenandcs < GPMC_CS_NUM here, it will always be true.
 - omap_board_config_size is implicitly initialized to 0 in
   plat-omap/common.c, get_config() won't dereference omap_board_config,
   so we can remove the empty igep2_config array.


you should probably split this patch in a series.


Signed-off-by: Enric Balletbo i Serra 
---
arch/arm/mach-omap2/board-igep0020.c |   39 -
1 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 152f757..ddcfd06 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -136,16 +136,10 @@ static struct mtd_partition igep2_onenand_partitions[] = {
},
};

-static int igep2_onenand_setup(void __iomem *onenand_base, int freq)
-{
-   /* nothing is required to be setup for onenand as of now */
-   return 0;
-}
-
static struct omap_onenand_platform_data igep2_onenand_data = {
.parts = igep2_onenand_partitions,
.nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
-   .onenand_setup = igep2_onenand_setup,
+   .onenand_setup = NULL,


static variable. Just remove the line ;-)

--
balbi
--
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 00/11] staging tidspbridge: iommu migration

2010-10-12 Thread Felipe Contreras

On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando
 wrote:
>> On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo
>>  wrote:
>> > This set of patches remove the dspbridge custom mmu
>> implementation and
>> > use iommu module instead.
>>
>> I have tried this, it works for simple tests, but not real use-cases.
>> I applied all your iommu patches. How did you test this?
>
> Have you applied:
>
> - "scatterlist: define SG chain for arm architecture"
> - "iovmm: replace __iounmap with omap_iounmap"
> - "iovmm: add superpages support to fixed da address"
> - "iovmm: IVA2 MMU range is from 0x1100 to 0x"
> - "iovmm: no gap checking for fixed address"

Yes.

> Also make sure your baseline have this patch:
>
> - "omap:iommu-load cam register before flushing the entry"

Huh? That's not even in v2.6.36-rc7, in which baseline is this
supposed to be in? Anyway, I'll try adding that.

> What kind of error are you getting?

Node allocation failing IIRC.

> I don't have a complete framework to test MM testcases at this moment

See:
http://felipec.wordpress.com/2010/10/08/my-arm-development-notes/

I even prepared a tarball so you just need to extract it on your
device. It's not difficult to test this with GStreamer, and I don't
see how you can be confident that they indeed work without testing
some real use-cases. Anyway, I'll try that missing patch.

Cheers.

-- 
Felipe Contreras
--
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 8/17] dmtimer: register mappings moved to hwmod database

2010-10-12 Thread Cousson, Benoit

On 10/12/2010 11:35 AM, Basak, Partha wrote:

From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 1:32 PM
To: Basak, Partha
Cc: DebBarma, Tarun Kanti; Kevin Hilman; G, Manjunath
Kondaiah; linux-omap@vger.kernel.org; Shilimkar, Santosh;
Paul Walmsley; Tony Lindgren
Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved
to hwmod database

On 10/12/2010 9:22 AM, Basak, Partha wrote:

From: DebBarma, Tarun Kanti
Sent: Tuesday, October 12, 2010 11:19 AM
To: Cousson, Benoit

Benoit,

From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 4:42 AM
To: DebBarma, Tarun Kanti

Hi Tarun,

On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:

Benoit,

From: Cousson, Benoit
Sent: Thursday, September 23, 2010 10:15 PM
To: Basak, Partha

On 9/23/2010 11:34 AM, Basak, Partha wrote:

From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM

"G, Manjunath Kondaiah" writes:

Hi Tarun,

From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti

<...>

Also, I'm not sure that you have to handle each register

separately

considering that you have one offset to handle for the

functional

register.
The change in sysconfig and interrupt register are all

standard mapping

that stick to TI highlander standard.
Meaning, as soon as an IP is a v2 (highlander version) all these
registers will be at the same place... at least in theory :-)

Here are the deltas between the legacy and the new one:

[OMAP_TIMER_ID_REG] 0x00,
[OMAP_TIMER_OCP_CFG_REG]0x10, same
[OMAP_TIMER_SYS_STAT_REG]   0x14, (not used anymore)

You should not care about these ones, because hwmod will

handle them.

[OMAP_TIMER_STAT_REG]   0x28, +10
[OMAP_TIMER_INT_EN_REG] 0x2c, +10
[OMAP_TIMER_INT_CLR_REG]0x30, (new)

These ones are standard registers

[OMAP_TIMER_WAKEUP_EN_REG]  0x34, +14
[OMAP_TIMER_CTRL_REG]   0x38, +14
[OMAP_TIMER_COUNTER_REG]0x3c, +14
[OMAP_TIMER_LOAD_REG]   0x40, +14
[OMAP_TIMER_TRIGGER_REG]0x44, +14
[OMAP_TIMER_WRITE_PEND_REG] 0x48, +14
[OMAP_TIMER_MATCH_REG]  0x4c, +14
[OMAP_TIMER_CAPTURE_REG]0x50, +14
[OMAP_TIMER_IF_CTRL_REG]0x54, +14
[OMAP_TIMER_CAPTURE2_REG]   0x58, +14

You can probably handle that with only 2 offsets instead

of having one

address per registers.

To keep aligned with other driver implementations, I

would like to

follow this:

1) move the table in mach-omap1/2 since
2) remove entries which are handled by hwmod.
However, I am not sure if there is any issue in keeping

them in the

table.

I don't think you need a table for that. All the functional

registers

are using a constant offset. IRQ is then the only exception.

Other than the offsets 0x14 for the Timer functional registers
and 0x10 for the IRQ registers, following differences exist
between the two versions:
1. OMAP_TIMER_SYS_STAT_REG is used only for v1, missing for v2.

This is handled by hwmod anyway.

2. OMAP_TIMER_INT_CLR_REG is new for v2, not used for v1.

Follow regular IRQ management for highlander IP. Should be
some generic
code in order to allow reuse.

3. Following registers are applicable only for v1.
[OMAP_TIMER_TICK_POS_REG]   0x48
[OMAP_TIMER_TICK_NEG_REG]   0x4c
[OMAP_TIMER_TICK_COUNT_REG] 0x50
[OMAP_TIMER_TICK_INT_MASK_SET_REG]  0x54
[OMAP_TIMER_TICK_INT_MASK_COUNT_REG]0x58

These are only there in the 1ms version of this IP.

In the end, having separate tables is neater and consistent
with other drivers.

I don't see why? And what other driver are you referring too?

I2c driver uses reg_map tables. Initially McSPI and MMC were using
similar reg_map tables which were later removed based on review comments.

However, the delta were minimal in this case.
e.g. MCSPI_HL_REV, MCSPI_HL_HWINFO, MCSPI_HL_SYSCONFIG were the only
difference for McSPI, all the other functional registers
were moved forward by 0x100.

Maybe, it is relevant for I2C as the amount of delta is more.

I also observed your comments on MMC. Now that both McSPI&  MMC are
not having table based approach, my argument of consistency across drivers
does not hold good. It depends upon the IPs really.

Yep, I do agree, for both SPI and MMC, it was really over-designed 
because the offset was constant.
For the timer, it is a little bit more complex, but still can be handled 
easily. At some point, the table approach can clearly make sense.

For for the timer, I still think it is a little bit over-designed.

What the point of adding a table and an extra level of
indirection, when
a simple addition will do it?

But instead of duplicating for each mach,
keeping them in plat should be OK.

Additionally, the implementation should take care to prevent access
of non-existing registers for a particular version.

You just need the IP version to do that.

We have 3 timer variants to handle to

Re: [PATCHv2 2/3] iovmm: add superpages support to fixed da address

2010-10-12 Thread Felipe Contreras

On Mon, Oct 11, 2010 at 6:33 PM, Guzman Lugo, Fernando
 wrote:
>> > @@ -420,7 +431,8 @@ static void sgtable_fill_kmalloc(struct
>> sg_table
>> > *sgt, u32 pa, size_t len)
>> >        for_each_sg(sgt->sgl, sg, sgt->nents, i) {
>> >                size_t bytes;
>> >
>> > -               bytes = iopgsz_max(len);
>> > +               bytes = max_alignment(da | pa);
>> > +               bytes = min(bytes, (size_t)iopgsz_max(len));
>>
>> Why the size_t casting?
>
> To void this warning:
> arch/arm/plat-omap/iovmm.c:440: warning: comparison of distinct pointer types 
> lacks a cast

But how is that possible? iopgsz_max is returning constants, like
SZ_1M, so they should not need casts, if anything, the cast should be
done in iopgsz_max itself.

-- 
Felipe Contreras
--
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/3] OMAP: control: add functions for DSP boot address/mode control

2010-10-12 Thread Felipe Contreras

On Tue, Oct 12, 2010 at 12:35 AM, Paul Walmsley  wrote:
> On Mon, 11 Oct 2010, Tony Lindgren wrote:
>> Would be nice to get the dspbridge into working shape. Sounds we still
>> need the following:
>>
>> - memblock fixes
>> - this series to fix the control module related issues
>> - platform data for the boards
>>
>> Is that all, or are we also missing something else?
>
> A few other things should be done also.
>
> 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in
> the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should
> be moved into a file in arch/arm/mach-omap2.  The DSPBridge driver should
> call those functions (to reset the DSP, start it, etc.) through
> platform_data function pointers.  Once that happens, patch 3 of the
> control module-related series would not be needed, since that code would
> be in arch/arm/mach-omap2 anyway.
>
> 2. The direct CM/PRM/RM register access should be removed from that
> arch/arm/mach-omap2 code.  That should be handled directly by the
> clock/hwmod/whatever code.
>
> 3. DSPBridge should be converted to use PM runtime, and the
> arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc.

Before starting to clean things up, I would rather have something that
works, which AFAIK includes:

 1) revert or fix iommu migration
 2) fix ioremap() usage on RAM

Only then we can have some minimal confidence that the cleaning up is
not introducing further breakage.

-- 
Felipe Contreras
--
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] omap3: various code improvements for IGEP v2 board.

2010-10-12 Thread Enric Balletbo i Serra

The comments of this post also apply to IGEP v2 board (thanks Laurent)

  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36402.html

Changes are:

  - Set onenand_setup to NULL instead of adding a no-op function.
  - On igep2_flash_init() function:
- Use 'for' loop instead 'while' loop.
- No need to initialize ret to 0, we're assigning it right after.
- No need to check for onenandcs < GPMC_CS_NUM here, it will always be true.
  - omap_board_config_size is implicitly initialized to 0 in
plat-omap/common.c, get_config() won't dereference omap_board_config,
so we can remove the empty igep2_config array.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/mach-omap2/board-igep0020.c |   39 -
 1 files changed, 14 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 152f757..ddcfd06 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -136,16 +136,10 @@ static struct mtd_partition igep2_onenand_partitions[] = {
},
 };
 
-static int igep2_onenand_setup(void __iomem *onenand_base, int freq)
-{
-   /* nothing is required to be setup for onenand as of now */
-   return 0;
-}
-
 static struct omap_onenand_platform_data igep2_onenand_data = {
.parts = igep2_onenand_partitions,
.nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
-   .onenand_setup = igep2_onenand_setup,
+   .onenand_setup = NULL,
.dma_channel= -1,   /* disable DMA in OMAP OneNAND driver */
 };
 
@@ -159,35 +153,35 @@ static struct platform_device igep2_onenand_device = {
 
 static void __init igep2_flash_init(void)
 {
-   u8  cs = 0;
-   u8  onenandcs = GPMC_CS_NUM + 1;
+   u8 cs = 0;
+   u8 onenandcs = GPMC_CS_NUM + 1;
 
-   while (cs < GPMC_CS_NUM) {
-   u32 ret = 0;
+   for (cs = 0; cs < GPMC_CS_NUM; cs++) {
+   u32 ret;
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
 
/* Check if NAND/oneNAND is configured */
if ((ret & 0xC00) == 0x800)
/* NAND found */
-   pr_err("IGEP v2: Unsupported NAND found\n");
+   pr_err("IGEP2: Unsupported NAND found\n");
else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
+
if ((ret & 0x3F) == (ONENAND_MAP >> 24))
-   /* ONENAND found */
+   /* OneNAND found */
onenandcs = cs;
}
-   cs++;
}
+
if (onenandcs > GPMC_CS_NUM) {
-   pr_err("IGEP v2: Unable to find configuration in GPMC\n");
+   pr_err("IGEP2: Unable to find configuration in GPMC\n");
return;
}
 
-   if (onenandcs < GPMC_CS_NUM) {
-   igep2_onenand_data.cs = onenandcs;
-   if (platform_device_register(&igep2_onenand_device) < 0)
-   pr_err("IGEP v2: Unable to register OneNAND device\n");
-   }
+   igep2_onenand_data.cs = onenandcs;
+
+   if (platform_device_register(&igep2_onenand_device) < 0)
+   pr_err("IGEP2: Unable to register OneNAND device\n");
 }
 
 #else
@@ -254,9 +248,6 @@ static inline void __init igep2_init_smsc911x(void)
 static inline void __init igep2_init_smsc911x(void) { }
 #endif
 
-static struct omap_board_config_kernel igep2_config[] __initdata = {
-};
-
 static struct regulator_consumer_supply igep2_vmmc1_supply = {
.supply = "vmmc",
 };
@@ -493,8 +484,6 @@ static struct platform_device *igep2_devices[] __initdata = 
{
 
 static void __init igep2_init_irq(void)
 {
-   omap_board_config = igep2_config;
-   omap_board_config_size = ARRAY_SIZE(igep2_config);
omap2_init_common_hw(m65kam_sdrc_params, m65kam_sdrc_params);
omap_init_irq();
omap_gpio_init();
-- 
1.7.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 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

2010-10-12 Thread kishon


ping..

On Friday 08 October 2010 11:50 AM, Varadarajan, Charulatha wrote:




-Original Message-
From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com]
Sent: Wednesday, October 06, 2010 12:47 PM
To: Varadarajan, Charulatha
Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org; Kamat,
Nishant; Datta, Shubhrajyoti; Basak, Partha; Girdwood, Liam;
jhnik...@gmail.com; broo...@opensource.wolfsonmicro.com; ABRAHAM, KISHON
VIJAY
Subject: Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx
devices

Hello,


Thanks for the quick response.



On Wednesday 06 October 2010 10:01:28 ext Varadarajan, Charulatha wrote:

This patch series is targeted to implement mcbsp driver in
hwmod way and to make use of pm_runtime APIs.

This patch series is tested on OMAP3&  4 and yet to be tested
on OMAP2.

There are few clarifications required so that the next patch series
can be implemented after aligning.

1. Audio layer is making use of mcbsp and it's dma base addresses and
is closely coupled with omap-mcbsp.
This can be handled either by
a. providing an API with which Audio layer can get these addresses.
(or)
b. move the plat-omap/mcbsp.c and mach-omap2/mcbsp.c to sound/soc/omap/
[1]

Option (a) would only be a workaround to handle the situation. As
audio is the only user for mcbsp, option (b) is better. If option(b)
is agreed upon, the same can be addressed on top of the mcbsp hwmod
series.


it is true that at the moment only audio is using the McBSP ports, but
McBSP is
really flexible, it can run for example in SPI mode, and it can be
configured to
use other serial protocols.


Yes.


I would go with option c.
Since ASoC is moving to multi-component (the conversion is already in
linux-
next), this means that the sound/soc/omap/omap-mcbsp, omap-pcm drivers are
platform drivers.
So if the plat-omap/mcbsp would register the platform device for McBSP
clients
(we have only ASoC client at the moment), and use platform data to pass
the
needed information to the McBSP client driver, than we do not need new API.


Sorry I am confused.

With hwmod implementation, there is a device register code for mcbsp
devices in mach-omap2/mcbsp.c and a probe in plat-omap/mcbsp.c. The base
address, dma info are not part of pdata and are available to the driver
only after probe. I do not understand how the multi-component design in
ASOC can avoid the new API.

Also with this multi-component approach in ASOC, two device
registrations happens for a single mcbsp device with two different
rames ("omap-mcbsp-dai.id"&  "omap-mcbsp.id"). Please explain if this
what is expected?


We still need to modify the ASoC drivers to make use of this platform data,
but
at least we are going to keep the door open for others to use the McBSP
ports
for other than audio.


Agreed. But the current omap-mcbsp driver cannot work standalone for
OMAP3/4 due to the issues stated below:
1. omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access McBSP
registers as 16-bit. But in OMAP3/4, McBSP registers (DRR_REG and DXR_REG)
are limited to 32-bit data accesses and hence poll mode would not work [x].
2. DMA transfers would also not work as it requires a patch similar to [y].

Patches [x]&  [y] were rejected as there are no users other than asoc.
If it is not agreed to move omap-mcbsp driver to asoc layer, we need to
get the omap-mcbsp driver working as a standalone driver. Otherwise it
is of no use keeping the mcbsp driver in plat-omap.

Once [x]&  [y] patches are upstreamed, audio layer needs to be modified
to make use of omap-mcbsp APIs rather than Audio layer calling dma
APIs directly to transfer data.

Coming back to the original question. Either we need to fix the broken
legacy mcbsp driver or move the omap-mcbsp driver completely to asoc
layer. What do you say?

[x] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19531.html
[y] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg04085.html



2. Sidetone feature is available only in OMAP3 (McBSP2&3) which has
different base address and sys configs compared to it's mcbsp port.
Hence the mcbsp is considered as a single device with two hwmods
for McBSP2&3 devices in OMAP3.


Sounds fair enough.


Thanks.




3. Autoidle needs to be disabled for sidetone before enabling the

sidetone

feature. There was a design proposed by Kishon [2] to add an API in

hwmod

to modify the autoidle bit but was not agreed upon. How do we handle

this

situation where the device has to disable or enable the autoidle bit at
runtime?


Yeah, this is really annoying problem. The McBSP ST should block autoidle
from
McBSP side, but it does not.
If you can not get through the proposed API, we should consider to switch
the
corresponding McBSP port to NoIdle, when the ST is in use (and restore the
idle
mode, when the ST has been disabled).
When McBSP is in NoIdle the interface clock is not going to be gated, so
ST
block will be running without a problem (ST needs the iface clock for
operation)

What do you thin

RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

2010-10-12 Thread Basak, Partha

 

> -Original Message-
> From: Cousson, Benoit 
> Sent: Tuesday, October 12, 2010 1:32 PM
> To: Basak, Partha
> Cc: DebBarma, Tarun Kanti; Kevin Hilman; G, Manjunath 
> Kondaiah; linux-omap@vger.kernel.org; Shilimkar, Santosh; 
> Paul Walmsley; Tony Lindgren
> Subject: Re: [PATCHv3 8/17] dmtimer: register mappings moved 
> to hwmod database
> 
> On 10/12/2010 9:22 AM, Basak, Partha wrote:
> >
> >> From: DebBarma, Tarun Kanti
> >> Sent: Tuesday, October 12, 2010 11:19 AM
> >> To: Cousson, Benoit
> >>
> >> Benoit,
> >>> From: Cousson, Benoit
> >>> Sent: Tuesday, October 12, 2010 4:42 AM
> >>> To: DebBarma, Tarun Kanti
> >>>
> >>> Hi Tarun,
> >>>
> >>> On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:
>  Benoit,
> 
> > From: Cousson, Benoit
> > Sent: Thursday, September 23, 2010 10:15 PM
> > To: Basak, Partha
> >
> > On 9/23/2010 11:34 AM, Basak, Partha wrote:
> >>
> >>> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >>> Sent: Thursday, September 23, 2010 3:10 AM
> >>>
> >>> "G, Manjunath Kondaiah"writes:
> >>>
>  Hi Tarun,
> 
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> > DebBarma, Tarun Kanti
> 
> <...>
> 
> >
> > Also, I'm not sure that you have to handle each register
> >> separately
> > considering that you have one offset to handle for the 
> functional
> > register.
> > The change in sysconfig and interrupt register are all
> >> standard mapping
> > that stick to TI highlander standard.
> > Meaning, as soon as an IP is a v2 (highlander version) all these
> > registers will be at the same place... at least in theory :-)
> >
> > Here are the deltas between the legacy and the new one:
> >
> > [OMAP_TIMER_ID_REG] 0x00,
> > [OMAP_TIMER_OCP_CFG_REG]0x10, same
> > [OMAP_TIMER_SYS_STAT_REG]   0x14, (not used anymore)
> >
> > You should not care about these ones, because hwmod will
> >> handle them.
> >
> > [OMAP_TIMER_STAT_REG]   0x28, +10
> > [OMAP_TIMER_INT_EN_REG] 0x2c, +10
> > [OMAP_TIMER_INT_CLR_REG]0x30, (new)
> >
> > These ones are standard registers
> >
> > [OMAP_TIMER_WAKEUP_EN_REG]  0x34, +14
> > [OMAP_TIMER_CTRL_REG]   0x38, +14
> > [OMAP_TIMER_COUNTER_REG]0x3c, +14
> > [OMAP_TIMER_LOAD_REG]   0x40, +14
> > [OMAP_TIMER_TRIGGER_REG]0x44, +14
> > [OMAP_TIMER_WRITE_PEND_REG] 0x48, +14
> > [OMAP_TIMER_MATCH_REG]  0x4c, +14
> > [OMAP_TIMER_CAPTURE_REG]0x50, +14
> > [OMAP_TIMER_IF_CTRL_REG]0x54, +14
> > [OMAP_TIMER_CAPTURE2_REG]   0x58, +14
> >
> > You can probably handle that with only 2 offsets instead
> >> of having one
> > address per registers.
> >
>  To keep aligned with other driver implementations, I 
> would like to
> >>> follow this:
> 
>  1) move the table in mach-omap1/2 since
>  2) remove entries which are handled by hwmod.
>  However, I am not sure if there is any issue in keeping
> >> them in the
> >>> table.
> >>>
> >>> I don't think you need a table for that. All the functional
> >> registers
> >>> are using a constant offset. IRQ is then the only exception.
> >
> > Other than the offsets 0x14 for the Timer functional registers
> > and 0x10 for the IRQ registers, following differences exist
> > between the two versions:
> > 1. OMAP_TIMER_SYS_STAT_REG is used only for v1, missing for v2.
> 
> This is handled by hwmod anyway.
> 
> 
> > 2. OMAP_TIMER_INT_CLR_REG is new for v2, not used for v1.
> 
> Follow regular IRQ management for highlander IP. Should be 
> some generic 
> code in order to allow reuse.
> 
> > 3. Following registers are applicable only for v1.
> > [OMAP_TIMER_TICK_POS_REG]   0x48
> > [OMAP_TIMER_TICK_NEG_REG]   0x4c
> > [OMAP_TIMER_TICK_COUNT_REG] 0x50
> > [OMAP_TIMER_TICK_INT_MASK_SET_REG]  0x54
> > [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]0x58
> 
> These are only there in the 1ms version of this IP.
> 
> > In the end, having separate tables is neater and consistent
> > with other drivers.
> 
> I don't see why? And what other driver are you referring too?

I2c driver uses reg_map tables. Initially McSPI and MMC were using
similar reg_map tables which were later removed based on review comments.

However, the delta were minimal in this case.
e.g. MCSPI_HL_REV, MCSPI_HL_HWINFO, MCSPI_HL_SYSCONFIG were the only 
difference for McSPI, all the other functional registers
were moved forward by 0x100.

Maybe, it is relevant for I2C as the amount of delta is more. 

I also observed your comments on MMC. Now that both McSPI & MMC are
not having table based approach, my argument of consistency across drivers
does not hold good. It depends upon the IPs really.
> 
> What the p

Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

2010-10-12 Thread Cousson, Benoit

On 10/12/2010 9:22 AM, Basak, Partha wrote:

From: DebBarma, Tarun Kanti
Sent: Tuesday, October 12, 2010 11:19 AM
To: Cousson, Benoit

Benoit,

From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 4:42 AM
To: DebBarma, Tarun Kanti

Hi Tarun,

On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:

Benoit,

From: Cousson, Benoit
Sent: Thursday, September 23, 2010 10:15 PM
To: Basak, Partha

On 9/23/2010 11:34 AM, Basak, Partha wrote:

From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 23, 2010 3:10 AM

"G, Manjunath Kondaiah"writes:

Hi Tarun,

From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti

<...>

Also, I'm not sure that you have to handle each register

separately

considering that you have one offset to handle for the functional
register.
The change in sysconfig and interrupt register are all

standard mapping

that stick to TI highlander standard.
Meaning, as soon as an IP is a v2 (highlander version) all these
registers will be at the same place... at least in theory :-)

Here are the deltas between the legacy and the new one:

[OMAP_TIMER_ID_REG] 0x00,
[OMAP_TIMER_OCP_CFG_REG]0x10, same
[OMAP_TIMER_SYS_STAT_REG]   0x14, (not used anymore)

You should not care about these ones, because hwmod will

handle them.

[OMAP_TIMER_STAT_REG]   0x28, +10
[OMAP_TIMER_INT_EN_REG] 0x2c, +10
[OMAP_TIMER_INT_CLR_REG]0x30, (new)

These ones are standard registers

[OMAP_TIMER_WAKEUP_EN_REG]  0x34, +14
[OMAP_TIMER_CTRL_REG]   0x38, +14
[OMAP_TIMER_COUNTER_REG]0x3c, +14
[OMAP_TIMER_LOAD_REG]   0x40, +14
[OMAP_TIMER_TRIGGER_REG]0x44, +14
[OMAP_TIMER_WRITE_PEND_REG] 0x48, +14
[OMAP_TIMER_MATCH_REG]  0x4c, +14
[OMAP_TIMER_CAPTURE_REG]0x50, +14
[OMAP_TIMER_IF_CTRL_REG]0x54, +14
[OMAP_TIMER_CAPTURE2_REG]   0x58, +14

You can probably handle that with only 2 offsets instead

of having one

address per registers.

To keep aligned with other driver implementations, I would like to

follow this:

1) move the table in mach-omap1/2 since
2) remove entries which are handled by hwmod.
However, I am not sure if there is any issue in keeping

them in the

table.

I don't think you need a table for that. All the functional

registers

are using a constant offset. IRQ is then the only exception.

Other than the offsets 0x14 for the Timer functional registers
and 0x10 for the IRQ registers, following differences exist
between the two versions:
1. OMAP_TIMER_SYS_STAT_REG is used only for v1, missing for v2.

This is handled by hwmod anyway.

2. OMAP_TIMER_INT_CLR_REG is new for v2, not used for v1.

Follow regular IRQ management for highlander IP. Should be some generic 
code in order to allow reuse.

3. Following registers are applicable only for v1.
[OMAP_TIMER_TICK_POS_REG]   0x48
[OMAP_TIMER_TICK_NEG_REG]   0x4c
[OMAP_TIMER_TICK_COUNT_REG] 0x50
[OMAP_TIMER_TICK_INT_MASK_SET_REG]  0x54
[OMAP_TIMER_TICK_INT_MASK_COUNT_REG]0x58

These are only there in the 1ms version of this IP.

In the end, having separate tables is neater and consistent
with other drivers.

I don't see why? And what other driver are you referring too?

What the point of adding a table and an extra level of indirection, when 
a simple addition will do it?

But instead of duplicating for each mach,
keeping them in plat should be OK.

Additionally, the implementation should take care to prevent access
of non-existing registers for a particular version.

You just need the IP version to do that.

We have 3 timer variants to handle today:
Legacy timer, legacy 1ms timer and highlander timer. You can handle that 
with 2 flags and 2 offsets.

Benoit

Agreed!! But we have to have a check in the read/write
routine to add this offset. This is an overhead I thought.
Also, tomorrow when we have new silicon with further offset
difference we would have to keep on adding additional checks.
This would end up making the read/write routine (which is
called frequently) bulky and inefficient.
So, my thinking was to keep the read/write routine generic.
Also, keeping separate table makes it extensible easily.
At the end I am OK both ways so long as community feels ok
with whichever approach.
-tarun

--
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 3/8] OMAP: powerdomain: Arch specific funcs for state control

2010-10-12 Thread Paul Walmsley

On Thu, 23 Sep 2010, Rajendra Nayak wrote:

> Define the following architecture specific funtions for omap2/3/4
> .pwrdm_set_next_pwrst
> .pwrdm_read_next_pwrst
> .pwrdm_read_pwrst
> .pwrdm_read_prev_pwrst
> 
> Convert the platform-independent framework to call these functions.
> 
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm/mach-omap2/Makefile   |5 +++
>  arch/arm/mach-omap2/io.c   |5 ++-
>  arch/arm/mach-omap2/powerdomains.h |8 
>  arch/arm/mach-omap2/powerdomains2xxx.c |   58 +++
>  arch/arm/mach-omap2/powerdomains44xx.c |   59 
> 
>  arch/arm/plat-omap/powerdomain.c   |   45 
>  6 files changed, 157 insertions(+), 23 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/powerdomains2xxx.c
>  create mode 100644 arch/arm/mach-omap2/powerdomains44xx.c
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 42209b5..a3ced1d 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -88,6 +88,11 @@ obj-$(CONFIG_ARCH_OMAP2420)+= 
> omap_hwmod_2420_data.o
>  obj-$(CONFIG_ARCH_OMAP2430)  += omap_hwmod_2430_data.o
>  obj-$(CONFIG_ARCH_OMAP3) += omap_hwmod_3xxx_data.o
>  
> +#powerdomain framework
> +obj-$(CONFIG_ARCH_OMAP2) += powerdomains2xxx.o
> +obj-$(CONFIG_ARCH_OMAP3) += powerdomains2xxx.o
> +obj-$(CONFIG_ARCH_OMAP4) += powerdomains44xx.o
> +
>  # EMU peripherals
>  obj-$(CONFIG_OMAP3_EMU)  += emu.o
>  
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 6cb5a39..b7c1ca1 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -315,7 +315,10 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
> *sdrc_cs0,
>  {
>   u8 skip_setup_idle = 0;
>  
> - pwrdm_init(powerdomains_omap, NULL);
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + pwrdm_init(powerdomains_omap, &omap2_pwrdm_functions);
> + else if (cpu_is_omap44xx())
> + pwrdm_init(powerdomains_omap, &omap4_pwrdm_functions);
>   clkdm_init(clockdomains_omap, clkdm_autodeps);
>   if (cpu_is_omap242x())
>   omap2420_hwmod_init();
> diff --git a/arch/arm/mach-omap2/powerdomains.h 
> b/arch/arm/mach-omap2/powerdomains.h
> index 105cbca..b25b989 100644
> --- a/arch/arm/mach-omap2/powerdomains.h
> +++ b/arch/arm/mach-omap2/powerdomains.h
> @@ -88,8 +88,16 @@ static struct powerdomain wkup_omap2_pwrdm = {
>   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP24XX | CHIP_IS_OMAP3430),
>  };
>  
> +extern struct pwrdm_functions omap2_pwrdm_functions;
> +#else
> +static struct pwrdm_functions omap2_pwrdm_functions;
>  #endif
>  
> +#ifdef CONFIG_ARCH_OMAP4
> +extern struct pwrdm_functions omap4_pwrdm_functions;
> +#else
> +static struct pwrdm_functions omap4_pwrdm_functions;
> +#endif
>  
>  /* As powerdomains are added or removed above, this list must also be 
> changed */
>  static struct powerdomain *powerdomains_omap[] __initdata = {
> diff --git a/arch/arm/mach-omap2/powerdomains2xxx.c 
> b/arch/arm/mach-omap2/powerdomains2xxx.c
> new file mode 100644
> index 000..b0c4550
> --- /dev/null
> +++ b/arch/arm/mach-omap2/powerdomains2xxx.c
> @@ -0,0 +1,58 @@
> +/*
> + * OMAP2 and OMAP3 powerdomain control
> + *
> + * Copyright (C) 2009-2010 Texas Instruments, Inc.
> + * Copyright (C) 2007-2009 Nokia Corporation

Don't forget your name.

> + *
> + * Derived from mach-omap2/powerdomain.c written by Paul Walmsley
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pm.h"
> +#include "cm.h"
> +#include "cm-regbits-34xx.h"
> +#include "cm-regbits-44xx.h"
> +#include "prm.h"
> +#include "prm-regbits-34xx.h"
> +#include "prm-regbits-44xx.h"
> +
> +int omap2_pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)

seems like this should be static?

> +{
> + return prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
> + (pwrst << OMAP_POWERSTATE_SHIFT),
> + pwrdm->prcm_offs, OMAP2_PM_PWSTCTRL);
> +}
> +
> +int omap2_pwrdm_read_next_pwrst(struct powerdomain *pwrdm)

as above

> +{
> + return prm_read_mod_bits_shift(pwrdm->prcm_offs,
> + OMAP2_PM_PWSTCTRL, OMAP_POWERSTATE_MASK);
> +}
> +
> +int omap2_pwrdm_read_pwrst(struct powerdomain *pwrdm)

as above

> +{
> + return prm_read_mod_bits_shift(pwrdm->prcm_offs,
> + OMAP2_PM_PWSTST, OMAP_POWERSTATEST_MASK);
> +}
> +
> +int omap2_pwrdm_read_prev_pwrst(struct powerdomain *pwrdm)

as above

> +{
> + return prm_read_mod_bits_shift(pwrdm->prcm_offs, OMAP3430_PM_PREPWSTST,
> +

Re: [RFC 2/8] OMAP: powerdomain: Infrastructure to put arch specific code

2010-10-12 Thread Paul Walmsley

On Thu, 23 Sep 2010, Rajendra Nayak wrote:

> Put infrastructure in place, so arch specific func pointers
> can be hooked up to the platform-independent part of the
> framework.

Hmm.  So if simply patches 1 and 2 of 8 are applied, I guess the system 
will panic on boot, now?  We should avoid that sort of thing, if possible.  
Ideally, the kernel should work correctly after each patch in a series is 
applied -- this makes it possible for 'git bisect' to work.

> ---
>  arch/arm/mach-omap2/io.c  |2 +-
>  arch/arm/plat-omap/include/plat/powerdomain.h |   22 +-
>  arch/arm/plat-omap/powerdomain.c  |   12 ++--
>  3 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index b9ea70b..6cb5a39 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -315,7 +315,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
> *sdrc_cs0,
>  {
>   u8 skip_setup_idle = 0;
>  
> - pwrdm_init(powerdomains_omap);
> + pwrdm_init(powerdomains_omap, NULL);
>   clkdm_init(clockdomains_omap, clkdm_autodeps);
>   if (cpu_is_omap242x())
>   omap2420_hwmod_init();
> diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h 
> b/arch/arm/plat-omap/include/plat/powerdomain.h
> index 3ea7220..18b722d 100644
> --- a/arch/arm/plat-omap/include/plat/powerdomain.h
> +++ b/arch/arm/plat-omap/include/plat/powerdomain.h
> @@ -117,8 +117,28 @@ struct powerdomain {
>  #endif
>  };
>  
> +struct pwrdm_functions {
> + int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst);
> + int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_read_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_read_prev_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_set_logic_retst)(struct powerdomain *pwrdm, u8 pwrst);
> + int (*pwrdm_set_mem_onst)(struct powerdomain *pwrdm, u8 bank, u8 
> pwrst);
> + int (*pwrdm_set_mem_retst)(struct powerdomain *pwrdm, u8 bank, u8 
> pwrst);
> + int (*pwrdm_read_logic_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_read_prev_logic_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_read_logic_retst)(struct powerdomain *pwrdm);
> + int (*pwrdm_read_mem_pwrst)(struct powerdomain *pwrdm, u8 bank);
> + int (*pwrdm_read_prev_mem_pwrst)(struct powerdomain *pwrdm, u8 
> bank);
> + int (*pwrdm_read_mem_retst)(struct powerdomain *pwrdm, u8 bank);
> + int (*pwrdm_clear_all_prev_pwrst)(struct powerdomain *pwrdm);
> + int (*pwrdm_enable_hdwr_sar)(struct powerdomain *pwrdm);
> + int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
> + int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
> + int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
> +};
>  
> -void pwrdm_init(struct powerdomain **pwrdm_list);
> +void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions 
> *custom_funcs);
>  
>  struct powerdomain *pwrdm_lookup(const char *name);
>  
> diff --git a/arch/arm/plat-omap/powerdomain.c 
> b/arch/arm/plat-omap/powerdomain.c
> index 9204799..f90bfd3 100644
> --- a/arch/arm/plat-omap/powerdomain.c
> +++ b/arch/arm/plat-omap/powerdomain.c
> @@ -80,6 +80,8 @@ static u16 pwrstst_reg_offs;
>  /* pwrdm_list contains all registered struct powerdomains */
>  static LIST_HEAD(pwrdm_list);
>  
> +static struct pwrdm_functions *arch_pwrdm;
> +
>  /* Private functions */
>  
>  static struct powerdomain *_pwrdm_lookup(const char *name)
> @@ -218,7 +220,7 @@ static int _pwrdm_post_transition_cb(struct powerdomain 
> *pwrdm, void *unused)
>   * registered.  No return value.  XXX pwrdm_list is not really a
>   * "list"; it is an array.  Rename appropriately.
>   */
> -void pwrdm_init(struct powerdomain **pwrdm_list)
> +void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_functions * 
> custom_funcs)

There is a superfluous space here between the * and the variable 
name.

>  {
>   struct powerdomain **p = NULL;
>  
> @@ -234,6 +236,13 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
>   return;
>   }
>  
> + if (!custom_funcs) {
> + printk(KERN_ERR "No custom pwrdm functions registered\n");
> + BUG();
> + }

Plesae convert this to be a WARN() + return, or something similar.  It 
doesn't seem necessary to crash the system here.

Also, just FYI, I've been trying to convert code in the style of

printk(KERN_ERR ...

into

pr_err(...

so it is best to use the shorter form initially.

> +
> + arch_pwrdm = custom_funcs;
> +
>   if (pwrdm_list) {
>   for (p = pwrdm_list; *p; p++)
>   _pwrdm_register(*p);
> @@ -1074,4 +1083,3 @@ int pwrdm_post_transition(void)
>   pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
>   return 0;
>  }
> -
> -- 
> 1.7.0.4
> 


- Paul
--
T

Re: [RFC 1/8] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap

2010-10-12 Thread Paul Walmsley

Hi Rajendra,

some brief comments -

On Thu, 23 Sep 2010, Rajendra Nayak wrote:

> This is in preparation of splitting the powerdomain framework into
> platform-independent part (for all omaps) and platform-specific
> parts.
> The platform-independent code would reside in plat-omap/powerdomain.c
> and the platform-specific code will resides in
> mach-omap2/powerdomain-.c files.

Unless you are planning to add powerdomain support for OMAP1, it seems 
best to keep the powerdomain code in mach-omap2/.  That will also avoid 
sideways includes like these:

> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/plat-omap/powerdomain.c
> @@ -26,19 +26,19 @@
>  
>  #include 
>  
> -#include "cm.h"
> -#include "cm-regbits-34xx.h"
> -#include "cm-regbits-44xx.h"
> -#include "prm.h"
> -#include "prm-regbits-34xx.h"
> -#include "prm-regbits-44xx.h"
> +#include "../mach-omap2/cm.h"
> +#include "../mach-omap2/cm-regbits-34xx.h"
> +#include "../mach-omap2/cm-regbits-44xx.h"
> +#include "../mach-omap2/prm.h"
> +#include "../mach-omap2/prm-regbits-34xx.h"
> +#include "../mach-omap2/prm-regbits-44xx.h"
>  
>  #include 
>  #include 
>  #include 
>  #include 
>  
> -#include "pm.h"
> +#include "../mach-omap2/pm.h"
>  
>  enum {
>   PWRDM_STATE_NOW = 0,
> -- 
> 1.7.0.4
> 


- 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: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

2010-10-12 Thread Basak, Partha

 

> -Original Message-
> From: DebBarma, Tarun Kanti 
> Sent: Tuesday, October 12, 2010 11:19 AM
> To: Cousson, Benoit
> Cc: Basak, Partha; Kevin Hilman; G, Manjunath Kondaiah; 
> linux-omap@vger.kernel.org; Shilimkar, Santosh; Paul 
> Walmsley; Tony Lindgren
> Subject: RE: [PATCHv3 8/17] dmtimer: register mappings moved 
> to hwmod database
> 
> Benoit,
> > -Original Message-
> > From: Cousson, Benoit
> > Sent: Tuesday, October 12, 2010 4:42 AM
> > To: DebBarma, Tarun Kanti
> > Cc: Basak, Partha; Kevin Hilman; G, Manjunath Kondaiah; linux-
> > o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; 
> Tony Lindgren
> > Subject: Re: [PATCHv3 8/17] dmtimer: register mappings 
> moved to hwmod
> > database
> > 
> > Hi Tarun,
> > 
> > On 10/9/2010 5:40 PM, DebBarma, Tarun Kanti wrote:
> > > Benoit,
> > >
> > >> From: Cousson, Benoit
> > >> Sent: Thursday, September 23, 2010 10:15 PM
> > >> To: Basak, Partha
> > >> Cc: Kevin Hilman; G, Manjunath Kondaiah; DebBarma, Tarun 
> Kanti; linux-
> > >> o...@vger.kernel.org; Shilimkar, Santosh; Paul Walmsley; 
> Tony Lindgren
> > >> Subject: Re: [PATCHv3 8/17] dmtimer: register mappings 
> moved to hwmod
> > >> database
> > >>
> > >> On 9/23/2010 11:34 AM, Basak, Partha wrote:
> > >>>
> > >>>
> >  From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> >  Sent: Thursday, September 23, 2010 3:10 AM
> > 
> >  "G, Manjunath Kondaiah"   writes:
> > 
> > > Hi Tarun,
> > >
> > >> From: linux-omap-ow...@vger.kernel.org
> > >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> > >> DebBarma, Tarun Kanti
> > >>
> > >>
> > >> <...>
> > >>
> > >> +static u32 omap_timer_reg_map_v1[] = {
> > >> +  [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_SYS_STAT_REG]   = (0x14 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_STAT_REG]   = (0x18 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_INT_EN_REG] = (0x1c | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_WAKEUP_EN_REG]  = (0x20 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CTRL_REG]   = (0x24 | (WP_TCLR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_COUNTER_REG]= (0x28 | (WP_TCRR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_LOAD_REG]   = (0x2c | (WP_TLDR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TRIGGER_REG]= (0x30 | (WP_TTGR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_WRITE_PEND_REG] = (0x34 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_MATCH_REG]  = (0x38 | (WP_TMAR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CAPTURE_REG]= (0x3c | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_IF_CTRL_REG]= (0x40 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CAPTURE2_REG]   = (0x44 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TICK_POS_REG]   = (0x48 | (WP_TPIR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TICK_NEG_REG]   = (0x4c | (WP_TNIR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TICK_COUNT_REG] = (0x50 | (WP_TCVR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TICK_INT_MASK_SET_REG]  = (0x54 |
> > >> (WP_TOCR<<   WPSHIFT)),
> > >> +  [OMAP_TIMER_TICK_INT_MASK_COUNT_REG]= (0x58 |
> > >> (WP_TOWR<<   WPSHIFT)),
> > >> +};
> > >> +
> > >> +/* OMAP4 timers register map */
> > >> +static u32 omap_timer_reg_map_v2[] = {
> > >> +  [OMAP_TIMER_ID_REG] = (0x00 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_OCP_CFG_REG]= (0x10 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_SYS_STAT_REG]   = (0x14 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_STAT_REG]   = (0x28 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_INT_EN_REG] = (0x2c | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_WAKEUP_EN_REG]  = (0x34 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CTRL_REG]   = (0x38 | (WP_TCLR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_COUNTER_REG]= (0x3c | (WP_TCRR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_LOAD_REG]   = (0x40 | (WP_TLDR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_TRIGGER_REG]= (0x44 | (WP_TTGR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_WRITE_PEND_REG] = (0x48 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_MATCH_REG]  = (0x4c | (WP_TMAR<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CAPTURE_REG]= (0x50 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_IF_CTRL_REG]= (0x54 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_CAPTURE2_REG]   = (0x58 | (WP_NONE<<
> > WPSHIFT)),
> > >> +  [OMAP_TIMER_INT_CLR_REG]= (0x30 | (WP_NONE<<
> > WPSHIFT)),
> > >> +};
> > >> +
> > >
> > > Why not these defines in mach-omap2/dmtimer.c? since
> >  register offsets are
> > > same for omap2plus except omap4 whi

Re: [PATCH v7] power: introduce library for device-specific OPPs

Re: [PATCH v7] power: introduce library for device-specific OPPs

Re: [RFC PATCHv3 2/7] OMAP SSI: Introducing OMAP SSI driver

Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo

Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control

[GIT PULL] one omap fix for 2.6.36

Re: [alsa-devel] [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

Re: [PATCH] serial: omap-serial: fix signess error

Re: [PATCH v4 0/4] LogicPD minimal board support for LV_SOM and Torpedo

Re: [PATCH] serial: omap-serial: fix signess error

Re: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n

Re: [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

RE: [PATCHv3 00/11] staging tidspbridge: iommu migration

RE: [PATCHv2 2/3] iovmm: add superpages support to fixed da address

Re: [alsa-devel] [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

Re: [PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

[PATCH] ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h

Re: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n

Re: [PATCH] omap3: various code improvements for IGEP v2 board.

Re: [PATCHv3 00/11] staging tidspbridge: iommu migration

Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

Re: [PATCHv2 2/3] iovmm: add superpages support to fixed da address

Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control

[PATCH] omap3: various code improvements for IGEP v2 board.

Re: [PATCH 1/7] [RFC] OMAP: MCBSP: hwmod database for 2xxx devices

RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

Re: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

Re: [RFC 3/8] OMAP: powerdomain: Arch specific funcs for state control

Re: [RFC 2/8] OMAP: powerdomain: Infrastructure to put arch specific code

Re: [RFC 1/8] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap

RE: [PATCHv3 8/17] dmtimer: register mappings moved to hwmod database

31 matches

Site Navigation

Mail list logo

Footer information