Re: Timekeeping issue on aggressive suspend/resume

[Thomas Petazzoni]

Hello Suresh,

On Wed, 9 Jun 2010 12:50:39 -0700
Suresh Rajashekara suresh.raj+linuxo...@gmail.com wrote:

 I have an application (running on 2.6.29-omap1) which puts an OMAP1
 system to suspend aggressively. The system wakes up every 4 seconds
 and stays awake for about 35 milliseconds and sleeps again for another
 4 seconds. This design is to save power on a battery operated device.
 
 This aggressive suspend resume action seems like creating an issue to
 other applications in the system waiting for some timeout to happen
 (especially an application which is waiting using the mq_timedreceive
 and is supposed to timeout every 30 seconds. It seems to wake up every
 90 seconds). Seems like the timekeeping is not happening properly in
 side the kernel.
 
 If the suspend duration is changed from 4 second to 1 second, then
 things work somewhat better. On reducing it to 0.5 second (which was
 our earlier design on 2.6.16-rc3), the problem seems to disappear.

I've done a relatively similar thing on different CPU architecture: in
the idle loop, when the CPU is going to be idle for a sufficiently long
period of time, I power down the CPU completely. Before that, I've
programmed a RTC (clocked at 32 khz) to wake-up the CPU a little bit
*before* the expiration of the next timer. When the CPU wakes-up, I
adjust the clocksource (in this case the CPU cycle counter) to
compensate the time spent while the CPU was off, and I reprogram the
clockevents to make sure that the timer will actually expire at the
correct time, also by compensating the time during which the CPU was
off (note: when the CPU is off, the cycle counter stops incrementing,
and the timer used as clockevents stops decrementing). This way, the
CLOCK_MONOTONIC time continues to go forward even when the CPU is off.
The goal was to make the CPU is off case just another idle state of
the system, which should just be as transparent to the life of the
system as other idle states. So an application that uses a periodic
timer of say, 30 milliseconds, will see its timer actually fired every
30 milliseconds even though the CPU goes off between each timer
expiration (we've done measurements with a scope, and the timer rely
expires every 30 milliseconds as expected).

FWIW, we do not use the normal suspend/resume infrastructure for this,
because it was way too slow (in the order of ~100ms). On the particular
hardware we're using, it takes roughly ~1ms to go OFF, and ~2ms to
completely wake-up, so we can very aggressively put the CPU in the OFF
state.

However, the way we're doing the time compensation is quite hackish,
and it would be great to hear Thomas Gleixner's ideas on how this
should be implemented properly at the clocksource/clock_event_device
level.

Sincerely,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] [PATCH v3 2/4] OMAP4: Keyboard device registration

[Tony Lindgren]

* Dmitry Torokhov dmitry.torok...@gmail.com [100601 23:07]:
 On Tue, Jun 01, 2010 at 09:53:58PM +0300, Felipe Balbi wrote:
  On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote:
  I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what
  you are suggesting is to check at runtime?
  
  you need to add both checks. If you build omap3-only or omap2-only
  you don't want that code to be compiled, but if you build
  omap1-2-3-4 kernel, you want it to work correctly on all cases.
  
 
 It sould be nice if cpu_is_xxx were stubbed out for wrong arches
 withing the same group (like omap, etc) so we could reduce the #ifdef
 clutter.

They are defined as stubs for for non-selected omaps. So in general a
function doing this in the beginning of the function:

if (!cpu_is_omap44xx())
return -ENODEV;

Should already get optimized out if 44xx is not selected in Kconfig.

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

Alternative for defconfig

[Nagarajan, Rajkumar]

Hi,

1. What is the alternative way of submitting defconfig changes/files to LO? 

2. Can any of you give me examples? 

Regards,
Rajkumar N.

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] 
 Sent: Wednesday, June 09, 2010 3:57 PM
 To: Nagarajan, Rajkumar
 Cc: linux-me...@vger.kernel.org
 Subject: Re: [PATCH] OMAP: V4L2: Enable V4L2 on ZOOM2/3  3630SDP
 
 Hi Rajkumar,
 
 On Wednesday 09 June 2010 11:51:45 Nagarajan, Rajkumar wrote:
  Defconfig changes to enable V4L2 on zoom2, zoom3 and 3630sdp boards.
 
 Defconfigs on ARM are going away. See the 
 http://lkml.org/lkml/2010/6/2/472 
 thread on LKML. There's also a lengthy discussion about that 
 on LAKML. Linus 
 will not accept any change to the defconfig files anymore and 
 currently plans 
 to remove them completely for 2.6.36.
 
 -- 
 Regards,
 
 Laurent Pinchart
 --
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: Alternative for defconfig

[Felipe Contreras]

On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com wrote:
 1. What is the alternative way of submitting defconfig changes/files to LO?

I don't think we have any alternative yet.

-- 
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: [linux-pm] suspend blockers Android integration

[James Bottomley]

On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
 Do we at least have a clean way that a driver can
 reject a system suspend?  I've lost track of many
 issues, but maybe this could be phrased as a QOS
 constraint:  the current config of driver X needs
 clock Y active to enter the  target system suspend
 state, driver's suspend() method reports as much.  Then the entry to
 that system state gets blocked
 if the clock isn't enabled.

So in QoS modifications to android patches, the answer is yes ...
except that the current android patch set didn't actually have this type
of wakelock in it.

Android wants an idleness suspend block (or pm qos constraint) that a
driver can set to prevent the system idleness power govenor from
dropping into a power state too low for the driver, so in USB terms this
would prevent the states that shut down the clock.  For android, it
prevented shutdown of an internal i2c bus.

The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific.  Expressing them in a generic
way for the cpu govenors to make sense of might be hard.

 (That QOS constraint should be removed when that
 driver no longer needs to issue wakeups; that's
 not quite the same as removed by driver.resume().

The USB one needs user input, doesn't it, since user hot plug might (or
might not) be one of the wakeup sources.

James


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

Re: [linux-pm] suspend blockers Android integration

[Alan Stern]

On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:

  You've lost me.  If the power manager is sitting inside a select/poll,
  how can it miss the event (given that the event will make data
  available to be read on one of the descriptors being polled)?
 
 
 It cannot sit inside of select/poll all the time.
 
  Or put it another way: With wakelocks, if the app doesn't use a suspend
  blocker then once it reads the event data and the timed wakelock is
  deactivated, there is nothing to prevent the system from immediately
  going into opportunistic suspend.  My scheme can fail in the same way.
  Is that what you meant?
 
 
 No, if an app reads from a file descriptor and block suspend when the
 read call returns, then suspend is blocked while processing the data.
 If the driver uses a wakelock with a timeout this will fail if the
 thread does not get to the suspend block call before the timeout
 expires, but unrelated events that don't prevent the app from running
 will not cause any problems.

Wait a second.  Maybe I have misunderstood how timeouts are supposed to
work with wakelocks.  I thought the idea was that the wakelock would be
released when the timeout expires or the event queue is emptied,
whichever comes first.  Now it sounds like you're saying that the
wakelock doesn't get released until the timeout expires, even if
userspace finishes processing all pending events before then.

 In your scheme the user-space power
 manager may miss events on this file descriptor since select/poll will
 not see an event if the app read that event right before the power
 manager called select/poll.

If the wakelock is supposed to remain active until the timeout expires 
then you are right.  On the other hand, this seems like a rather 
strange and suspicious way of handling wakelocks.  Why would you want 
to do it that way?

  There's one question that I don't remember ever seeing answered.  To
  which kernel drivers do you intend to add suspend blockers?
 
 
 All drivers that generate wakeup events need to either use suspend
 blockers directly or call into something else that does. For instance,
 with the patch to block suspend while input events are queued to
 user-space, an input driver that fully handles its events in its
 interrupt handler does not need any additional suspend blockers, but
 if the driver needs a work function or a timer to run before it
 reports the event it needs to block suspend until it has reported the
 event.

Sure.  But specifically, which drivers on Android generate wakeup
events?  And which of them don't fully handle their events in their
interrupt handlers?

Maybe another way to put this is: Where in the kernel do you intend to 
add suspend blockers?

Alan Stern

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

asoc beagle audio capture fails in 2.6.33 dspbridge kernel

[Tom Briggs]

I have spent the past few weeks whacking at a problem with the 2.6.33
dspbridge kernel, and I'm hoping someone can help me out.

With a straight-up build of the head of the dspbridge kernel
(currently 2.6.33), doing an arecord fails to capture data.  Using
JTAG, I was able to trace through the kernel calls, and found that
registers on the McBSP were being set, the DMA request was being added
to the request chain, the TWL4030 register is set to begin
transferring data.  Comparing these to TRM, they seem to be
appropriate settings.  The DMA interrupt does not seem to be generated
by the audio capture (setting JTAG breakpoint at handle_level_irq I
see many other interrupts come in, but not int 12 for DMA, or 32/33
for McBSP framing errors).

Audio capture works fine in the 2.6.35 and 2.6.29 kernel (but
DSPBRIDGE doesn't).  So, I added the same printk's on the registers,
and where there were differences, they were negligible, e.g. in
2.6.35, the TWL4030 register 3A was set to 16, which was a higher gain
on an audio channel.

I've done a number of Google searches, and either I'm enough of a newb
that I'm not using the correct terms to bring up meaningful results,
or, noone else is reporting the same types of problems.  Is there a
patch that addresses this?

-tom


-
Tom Briggs, PhD
Associate Professor, Department of Computer Science
Shippensburg University of Pennsylvania
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] suspend blockers Android integration

[Alan Stern]

On Thu, 10 Jun 2010, David Brownell wrote:

 This is a bit off the topic of Android
 flamage, but I thought it would be worth
 highlighting an example where the current
 frameworks may still have a deficiency...
 one that likewise relates to needing to
 block entry ot a system suspend state, but
 in this case user-space isn't very involved
 (just drivers coping with hardware).
 
 The example I wanted to re-post (I've done so
 in the past) is one where drivers ouldn't really
 do the right thing, since driver.suspend() wasn't
 quite powerful enough as a programming interface.
 
 The example works with USB on many ARM SoCs,
 and similar non-USB examples aren't rare.
 
  - Want to enter a system suspend state, with
some USB wakeup sources.  USB peripheral
waken up by the host, or vice versa.
 
NOTE ASSUMPTION:  there are multiple suspend
states supported by the hardware, significantly
different in hardware configuration Linux should
be able to use more than one such state... (if
only because their power savings differ.)  This
 can mean driver-specific knowledge about those
 various states.
 
  - The wakeup requires a particular clock to be active, so the USB controller 
 can detect that the
 wakeup should trigger,  then issue the right signals
 triggering the non-USB parts of the system.
 
 Problem:  how does the device driver suspend()
   method block entry to a suspend state
   when it can't ensure that clock is
   going to be active.  Magic return code?

At the moment, drivers aren't told what suspend state the system is
going into.  They know the difference between suspend and hibernate,
but the PM core doesn't tell drivers whether it's going into standby
vs. suspend.  (Strictly speaking, those terms apply mostly to ACPI
systems and not so much elsewhere.  What I'm talking about is the
/sys/power/state interface, where the user can write either standby
or mem.  Drivers aren't told which was written.)

  There are other issues here too.  (Is the target
  system suspend state one of the ones which doesn't
 allow that clock to be active?  SoC-specific calls
 might suffice for this issue.

I imagine platforms have to answer all such questions when they decide 
exactly how they will implement standby and mem.

 A number of years ago, this problem was insoluble
 with the then-current Linux PM and clock frameworks.
 I've been away from this issue for quite a while
 now, but don't recall seeing its sub-problems get
 solved ... If they're now solved, I'll be glad.
 (I know Kevin's recent OMAP stuff addresses similar
 issues, but It's OMAP-specific...) 
 
 After all these thousands and thousands of emails...
 I'm not sure how much forward motion has happened.

I'm not aware of any progress.

Alan Stern

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

Re: [linux-pm] suspend blockers Android integration

[Alan Stern]

On Fri, 11 Jun 2010, James Bottomley wrote:

 On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
  Do we at least have a clean way that a driver can
  reject a system suspend?  I've lost track of many
  issues, but maybe this could be phrased as a QOS
  constraint:  the current config of driver X needs
  clock Y active to enter the  target system suspend
  state, driver's suspend() method reports as much.  Then the entry to
  that system state gets blocked
  if the clock isn't enabled.
 
 So in QoS modifications to android patches, the answer is yes ...
 except that the current android patch set didn't actually have this type
 of wakelock in it.
 
 Android wants an idleness suspend block (or pm qos constraint) that a
 driver can set to prevent the system idleness power govenor from
 dropping into a power state too low for the driver, so in USB terms this
 would prevent the states that shut down the clock.  For android, it
 prevented shutdown of an internal i2c bus.
 
 The one thing that does look difficult is that these power constraints
 are device (and sometimes SoC) specific.  Expressing them in a generic
 way for the cpu govenors to make sense of might be hard.

Doesn't the clock framework already handle this sort of thing?

Alan Stern

--
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: Alternative for defconfig

[Aguirre, Sergio]

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Felipe Contreras
 Sent: Friday, June 11, 2010 8:43 AM
 To: Nagarajan, Rajkumar
 Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav;
 linux-omap@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar x0133...@ti.com
 wrote:
  1. What is the alternative way of submitting defconfig changes/files to
 LO?

I don't think defconfig changes are prohibited now. If I understand
correctly, Linus just hates the fact that there is a big percentage of
patches for defconfigs. Maybe he wants us to hold these, and better
provide higher percentage of actual code changes.

What about holding defconfig changes in a separate branch, and just send
them for upstream once in a while, specially if there's a big quantity of
them in the queue?

IMHO, defconfigs are just meant to make us life easier, but changes to them
should _never_ be a fix/solution to any problem, and therefore I understand
that those aren't a priority over regressions.

Regards,
Sergio

 
 I don't think we have any alternative yet.
 
 --
 Felipe Contreras
 --
 To unsubscribe from this list: send the line unsubscribe linux-media 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: [linux-pm] suspend blockers Android integration

[Mark Brown]

On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
 On Fri, 11 Jun 2010, James Bottomley wrote:

  The one thing that does look difficult is that these power constraints
  are device (and sometimes SoC) specific.  Expressing them in a generic
  way for the cpu govenors to make sense of might be hard.

 Doesn't the clock framework already handle this sort of thing?

The clock framework is implemented independantly for each CPU.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] suspend blockers Android integration

[James Bottomley]

On Fri, 2010-06-11 at 10:46 -0400, Alan Stern wrote:
 On Fri, 11 Jun 2010, James Bottomley wrote:
 
  On Thu, 2010-06-10 at 21:21 -0700, David Brownell wrote:
   Do we at least have a clean way that a driver can
   reject a system suspend?  I've lost track of many
   issues, but maybe this could be phrased as a QOS
   constraint:  the current config of driver X needs
   clock Y active to enter the  target system suspend
   state, driver's suspend() method reports as much.  Then the entry to
   that system state gets blocked
   if the clock isn't enabled.
  
  So in QoS modifications to android patches, the answer is yes ...
  except that the current android patch set didn't actually have this type
  of wakelock in it.
  
  Android wants an idleness suspend block (or pm qos constraint) that a
  driver can set to prevent the system idleness power govenor from
  dropping into a power state too low for the driver, so in USB terms this
  would prevent the states that shut down the clock.  For android, it
  prevented shutdown of an internal i2c bus.
  
  The one thing that does look difficult is that these power constraints
  are device (and sometimes SoC) specific.  Expressing them in a generic
  way for the cpu govenors to make sense of might be hard.
 
 Doesn't the clock framework already handle this sort of thing?

Well, there are two elements to this sort of thing:

 1. Allow a driver to request that a given clock not be turned off.
 2. Make the cpuidle governors aware of a pending don't turn off X
clock source so they can keep the system in a state where the
clock doesn't get powered down.

As far as I can tell from the code, neither currently exists at the
moment.

James


--
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: Alternative for defconfig

[Laurent Pinchart]

Hi Sergio,

On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Felipe Contreras
  Sent: Friday, June 11, 2010 8:43 AM
  To: Nagarajan, Rajkumar
  Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav;
  linux-omap@vger.kernel.org
  Subject: Re: Alternative for defconfig
  
  On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
   1. What is the alternative way of submitting defconfig changes/files to
  
  LO?
 
 I don't think defconfig changes are prohibited now. If I understand
 correctly, Linus just hates the fact that there is a big percentage of
 patches for defconfigs. Maybe he wants us to hold these, and better
 provide higher percentage of actual code changes.
 
 What about holding defconfig changes in a separate branch, and just send
 them for upstream once in a while, specially if there's a big quantity of
 them in the queue?
 
 IMHO, defconfigs are just meant to make us life easier, but changes to them
 should _never_ be a fix/solution to any problem, and therefore I understand
 that those aren't a priority over regressions.

My understanding is that Linus will remove all ARM defconfigs in 2.6.36, 
unless someone can convince him not to. Board-specific defconfigs won't be 
allowed anymore, the number of defconfigs needs to be reduced drastically 
(ideally to one or two only).

-- 
Regards,

Laurent Pinchart
--
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: Alternative for defconfig

[Aguirre, Sergio]

Hi Laurent,

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, June 11, 2010 10:08 AM
 To: Aguirre, Sergio
 Cc: Felipe Contreras; Nagarajan, Rajkumar; linux-me...@vger.kernel.org;
 Hiremath, Vaibhav; linux-omap@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 Hi Sergio,
 
 On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
   -Original Message-
   From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
   ow...@vger.kernel.org] On Behalf Of Felipe Contreras
   Sent: Friday, June 11, 2010 8:43 AM
   To: Nagarajan, Rajkumar
   Cc: Laurent Pinchart; linux-me...@vger.kernel.org; Hiremath, Vaibhav;
   linux-omap@vger.kernel.org
   Subject: Re: Alternative for defconfig
  
   On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
1. What is the alternative way of submitting defconfig changes/files
 to
  
   LO?
 
  I don't think defconfig changes are prohibited now. If I understand
  correctly, Linus just hates the fact that there is a big percentage of
  patches for defconfigs. Maybe he wants us to hold these, and better
  provide higher percentage of actual code changes.
 
  What about holding defconfig changes in a separate branch, and just send
  them for upstream once in a while, specially if there's a big quantity
 of
  them in the queue?
 
  IMHO, defconfigs are just meant to make us life easier, but changes to
 them
  should _never_ be a fix/solution to any problem, and therefore I
 understand
  that those aren't a priority over regressions.
 
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
 unless someone can convince him not to. Board-specific defconfigs won't be
 allowed anymore, the number of defconfigs needs to be reduced drastically
 (ideally to one or two only).

Hmm, Interesting...

We will be now forced to resolve some potential hidden issues with
ARM multibuilds (like the ones showing up when creating the
omap3_defconfig), and that's a great motivation to nail down all possible
portability problems.

/me likes that :)

Regards,
Sergio

 
 --
 Regards,
 
 Laurent Pinchart
--
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: Alternative for defconfig

[Gadiyar, Anand]

Laurent Pinchart wrote:
 On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
   On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
1. What is the alternative way of submitting defconfig changes/files to
   
   LO?
  
  I don't think defconfig changes are prohibited now. If I understand
  correctly, Linus just hates the fact that there is a big percentage of
  patches for defconfigs. Maybe he wants us to hold these, and better
  provide higher percentage of actual code changes.
  
  What about holding defconfig changes in a separate branch, and just send
  them for upstream once in a while, specially if there's a big quantity of
  them in the queue?
  
  IMHO, defconfigs are just meant to make us life easier, but changes to them
  should _never_ be a fix/solution to any problem, and therefore I understand
  that those aren't a priority over regressions.
 
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36, 
 unless someone can convince him not to. Board-specific defconfigs won't be 
 allowed anymore, the number of defconfigs needs to be reduced drastically 
 (ideally to one or two only).
 

There is some good work going on on the linux-arm-kernel mailing list to
cut down heavily the ARM defconfigs. Would be good to join that discussion.

For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would
suffice to cover all OMAPs?

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

Re: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()

[Felipe Contreras]

On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
 From: ext Felipe Contreras felipe.contre...@gmail.com
 Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
 Date: Sat, 22 May 2010 19:14:24 +0200

 No need to dynamically register mailboxes one by one.

 Can you squash this into [PATCH 10/14]?

 I think that the struct omap_mbox **list would make more sense
 without those reworking of modifications in this patch.

I don't know, I'm looking at the patch and I think it's much more
difficult to figure out what's happening.

See:

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 590ac66..3df1c28 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -142,44 +142,35 @@ struct omap_mbox mbox_dsp_info = {
.priv   = omap1_mbox_dsp_priv,
 };

+struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
+
 static int __devinit omap1_mbox_probe(struct platform_device *pdev)
 {
struct resource *res;
int ret;
+   int i;
+   struct omap_mbox **list;

-   /* MBOX base */
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid mem resource\n);
-   return -ENODEV;
-   }
+   list = omap1_mboxes;
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);

-   mbox_base = ioremap(res-start, resource_size(res));
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mbox_base = ioremap(res[0].start, resource_size(res[0]));
if (!mbox_base)
return -ENOMEM;

-   /* DSP IRQ */
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid irq resource\n);
-   ret = -ENODEV;
-   goto err_out;
+   ret = omap_mbox_register(pdev-dev, list);
+   if (ret) {
+   iounmap(mbox_base);
+   return ret;
}
-   mbox_dsp_info.irq = res-start;

-   ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
-   if (ret)
-   goto err_out;
return 0;
-
-err_out:
-   iounmap(mbox_base);
-   return ret;
 }

 static int __devexit omap1_mbox_remove(struct platform_device *pdev)
 {
-   omap_mbox_unregister(mbox_dsp_info);
+   omap_mbox_unregister();
iounmap(mbox_base);
return 0;
 }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 3ff1ad5..f336515 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -307,6 +307,8 @@ struct omap_mbox mbox_dsp_info = {
.priv   = omap2_mbox_dsp_priv,
 };

+struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
+
 #if defined(CONFIG_ARCH_OMAP2420)

 /* IVA */
@@ -331,6 +333,8 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_iva_priv,
 };
+
+struct omap_mbox *omap2_mboxes[] = { mbox_iva_info, mbox_dsp_info, NULL };
 #endif

 /* OMAP4 */
@@ -378,89 +382,56 @@ struct omap_mbox mbox_2_info = {
.priv   = omap2_mbox_2_priv,
 };

+struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
+
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
struct resource *res;
int ret;
+   struct omap_mbox **list;

-   /* MBOX base */
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid mem resource\n);
-   return -ENODEV;
+   if (cpu_is_omap3430()) {
+   list = omap3_mboxes;
+
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
-   mbox_base = ioremap(res-start, resource_size(res));
-   if (!mbox_base)
-   return -ENOMEM;
+#if defined(CONFIG_ARCH_OMAP2420)
+   else if (cpu_is_omap2420()) {
+   list = omap2_mboxes;

-   /* DSP or IVA2 IRQ */
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);
+   list[1]-irq = platform_get_irq_byname(pdev, iva);
+   }
+#endif
+   else if (cpu_is_omap44xx()) {
+   list = omap4_mboxes;

-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid irq resource\n);
-   ret = -ENODEV;
-   goto err_dsp;
+   list[0]-irq = list[1]-irq =
+   platform_get_irq_byname(pdev, mbox);
}
-   if (cpu_is_omap44xx()) {
-   mbox_1_info.irq = res-start;
-   ret = omap_mbox_register(pdev-dev, mbox_1_info);
-   } else {
-   mbox_dsp_info.irq = res-start;
-   ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
+   else {
+   pr_err(%s: platform not supported\n, __func__);
+   return -ENODEV;
}
-   if (ret)
-   goto err_dsp;

Re: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()

[Felipe Contreras]

On Fri, Jun 11, 2010 at 6:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU hiroshi.d...@nokia.com wrote:
 From: ext Felipe Contreras felipe.contre...@gmail.com
 Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
 Date: Sat, 22 May 2010 19:14:24 +0200

 No need to dynamically register mailboxes one by one.

 Can you squash this into [PATCH 10/14]?

 I think that the struct omap_mbox **list would make more sense
 without those reworking of modifications in this patch.

 I don't know, I'm looking at the patch and I think it's much more
 difficult to figure out what's happening.

I forgot to mention: what I will do is put one patch after the other.

-- 
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: Alternative for defconfig

[Laurent Pinchart]

Hi Anand,

On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote:
 Laurent Pinchart wrote:
  On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
 1. What is the alternative way of submitting defconfig
 changes/files to

LO?
   
   I don't think defconfig changes are prohibited now. If I understand
   correctly, Linus just hates the fact that there is a big percentage of
   patches for defconfigs. Maybe he wants us to hold these, and better
   provide higher percentage of actual code changes.
   
   What about holding defconfig changes in a separate branch, and just
   send them for upstream once in a while, specially if there's a big
   quantity of them in the queue?
   
   IMHO, defconfigs are just meant to make us life easier, but changes to
   them should _never_ be a fix/solution to any problem, and therefore I
   understand that those aren't a priority over regressions.
  
  My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
  unless someone can convince him not to. Board-specific defconfigs won't
  be allowed anymore, the number of defconfigs needs to be reduced
  drastically (ideally to one or two only).
 
 There is some good work going on on the linux-arm-kernel mailing list to
 cut down heavily the ARM defconfigs. Would be good to join that discussion.
 
 For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would
 suffice to cover all OMAPs?

I'm not sure what the exact roadmap will be. Linus is complaining about the 
defconfig changes taking up too much of the diffstat. I don't know if he will 
accept patches to solve the problem gradually, or if he will just remove all 
defconfig files in 2.6.36.

In any case, all changes that make it possible to built more machine types and 
platform types in the same kernel are a step in the right direction.

-- 
Regards,

Laurent Pinchart
--
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 3/3] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver

[Shilimkar, Santosh]

Felipe,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe
 Balbi
 Sent: Wednesday, April 07, 2010 11:04 PM
 To: ext Kevin Hilman
 Cc: Balbi Felipe (Nokia-D/Helsinki); Linux OMAP Mailing List
 Subject: Re: [PATCH 3/3] arm: omap1/2/3/4: convert 32k-sync driver to a 
 platform_driver
 
 On Wed, Apr 07, 2010 at 06:08:13PM +0200, ext Kevin Hilman wrote:
 felipe.ba...@nokia.com writes:
 
  From: Felipe Balbi felipe.ba...@nokia.com
 
  Convert the omap32k clocksource driver into a platform_driver
  and while at that, also remove the ifdeferry around the code.
 
  Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
 
 I'm OK with this for now.  Ideally, this would be further converted to
 use hwmod + omap_device to automatcially created the platform_devices
 for you.
 
 Yeah. I was asking Paul about it today. I can send as a follow up patch
 on next week.
 
Is there a newer version of this series already available/posted??
Sorry I missed it.

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: Alternative for defconfig

[Aguirre, Sergio]

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, June 11, 2010 10:26 AM
 To: Gadiyar, Anand
 Cc: Aguirre, Sergio; Felipe Contreras; Nagarajan, Rajkumar; linux-
 me...@vger.kernel.org; Hiremath, Vaibhav; linux-omap@vger.kernel.org
 Subject: Re: Alternative for defconfig
 
 Hi Anand,
 
 On Friday 11 June 2010 17:14:19 Gadiyar, Anand wrote:
  Laurent Pinchart wrote:
   On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
 On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
  1. What is the alternative way of submitting defconfig
  changes/files to

 LO?
   
I don't think defconfig changes are prohibited now. If I understand
correctly, Linus just hates the fact that there is a big percentage
 of
patches for defconfigs. Maybe he wants us to hold these, and better
provide higher percentage of actual code changes.
   
What about holding defconfig changes in a separate branch, and just
send them for upstream once in a while, specially if there's a big
quantity of them in the queue?
   
IMHO, defconfigs are just meant to make us life easier, but changes
 to
them should _never_ be a fix/solution to any problem, and therefore
 I
understand that those aren't a priority over regressions.
  
   My understanding is that Linus will remove all ARM defconfigs in
 2.6.36,
   unless someone can convince him not to. Board-specific defconfigs
 won't
   be allowed anymore, the number of defconfigs needs to be reduced
   drastically (ideally to one or two only).
 
  There is some good work going on on the linux-arm-kernel mailing list to
  cut down heavily the ARM defconfigs. Would be good to join that
 discussion.
 
  For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig
 would
  suffice to cover all OMAPs?
 
 I'm not sure what the exact roadmap will be. Linus is complaining about
 the
 defconfig changes taking up too much of the diffstat. I don't know if he
 will
 accept patches to solve the problem gradually, or if he will just remove
 all
 defconfig files in 2.6.36.
 
 In any case, all changes that make it possible to built more machine types
 and
 platform types in the same kernel are a step in the right direction.

I definitely think that one important step to achieve a multi platform build
is to detect the minimal arm_defconfig first, and then (most importantly
IMHO) proceed with trying to generate kernel modules of almost all
peripherals.

Many boards tend to be tested with just monolithic single-platform kernels,
and making things modular hasn't been addressed at all in some drivers (old
OMAP DSS code, for example).

Regards,
Sergio

 
 --
 Regards,
 
 Laurent Pinchart
--
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: Alternative for defconfig

[Sid Boyce]

On 11/06/10 16:14, Gadiyar, Anand wrote:
 Laurent Pinchart wrote:
 On Friday 11 June 2010 16:55:07 Aguirre, Sergio wrote:
 On Fri, Jun 11, 2010 at 3:19 PM, Nagarajan, Rajkumar wrote:
 1. What is the alternative way of submitting defconfig changes/files to

 LO?

 I don't think defconfig changes are prohibited now. If I understand
 correctly, Linus just hates the fact that there is a big percentage of
 patches for defconfigs. Maybe he wants us to hold these, and better
 provide higher percentage of actual code changes.

 What about holding defconfig changes in a separate branch, and just send
 them for upstream once in a while, specially if there's a big quantity of
 them in the queue?

 IMHO, defconfigs are just meant to make us life easier, but changes to them
 should _never_ be a fix/solution to any problem, and therefore I understand
 that those aren't a priority over regressions.

 My understanding is that Linus will remove all ARM defconfigs in 2.6.36, 
 unless someone can convince him not to. Board-specific defconfigs won't be 
 allowed anymore, the number of defconfigs needs to be reduced drastically 
 (ideally to one or two only).

 
 There is some good work going on on the linux-arm-kernel mailing list to
 cut down heavily the ARM defconfigs. Would be good to join that discussion.
 
 For OMAP, I suppose maintaining omap1_defconfig and omap3_defconfig would
 suffice to cover all OMAPs?
 
 - Anand

If I use omap3_beagle_defconfig instead of omap3_defconfig HID is
missing from the .config and doesn't show up for selection in make
config.
Is this an oversight or is omap3_defconfig the proper one to use.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
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 v4 00/14] omap: mailbox: bunch of cleanups

[Felipe Contreras]

From: Felipe Contreras --global

Hi,

These are hopefully non-functional changes. Just shuffling code around, and
removing unecessary stuff.

This v4 includes minor changes suggested by Felipe Balbi, Hiroshi, and Russell.

Comments from Felipe Balbi, Tony Lindgren, Hiroshi DOYU, and Russell King.

Felipe Contreras (14):
  omap: mailbox: trivial whitespace cleanups
  omap: mailbox: trivial cleanups
  omap: mailbox: reorganize structures
  omap: mailbox: 2420 should be detected at run-time
  omap: mailbox: use correct config for omap1
  omap: mailbox: update omap1 probing
  omap: mailbox: don't export unecessary symbols
  omap: mailbox: remove unecessary fields
  omap: mailbox: add IRQ names
  omap: mailbox: reorganize registering
  omap: mailbox: simplify omap_mbox_register()
  omap: mailbox: only compile for configured archs
  omap: mailbox: standarize on 'omap-mailbox'
  omap: mailbox: reorganize headers

 arch/arm/mach-omap1/devices.c |   11 +-
 arch/arm/mach-omap1/mailbox.c |   55 --
 arch/arm/mach-omap2/devices.c |6 +-
 arch/arm/mach-omap2/mailbox.c |  179 +
 arch/arm/plat-omap/include/plat/mailbox.h |   16 +--
 arch/arm/plat-omap/mailbox.c  |  136 +-
 6 files changed, 170 insertions(+), 233 deletions(-)

Here's the interdiff with v3:

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index fdd6cc9..1a85a42 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -143,17 +143,16 @@ struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL 
};
 
 static int __devinit omap1_mbox_probe(struct platform_device *pdev)
 {
-   struct resource *res;
+   struct resource *mem;
int ret;
int i;
struct omap_mbox **list;
 
-   res = pdev-resource;
-
list = omap1_mboxes;
list[0]-irq = platform_get_irq_byname(pdev, dsp);
 
-   mbox_base = ioremap(res[0].start, resource_size(res[0]));
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mbox_base = ioremap(mem-start, resource_size(mem));
if (!mbox_base)
return -ENOMEM;
 
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index d46e439..42dbfa4 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -388,13 +388,12 @@ struct omap_mbox *omap4_mboxes[] = { mbox_1_info, 
mbox_2_info, NULL };
 
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
-   struct resource *res;
+   struct resource *mem;
int ret;
struct omap_mbox **list;
 
-   res = pdev-resource;
-
-   if (false);
+   if (false)
+   ;
 #if defined(CONFIG_ARCH_OMAP3430)
else if (cpu_is_omap3430()) {
list = omap3_mboxes;
@@ -423,7 +422,8 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
return -ENODEV;
}
 
-   mbox_base = ioremap(res[0].start, resource_size(res[0]));
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mbox_base = ioremap(mem-start, resource_size(mem));
if (!mbox_base)
return -ENOMEM;
 

--
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 v4 01/14] omap: mailbox: trivial whitespace cleanups

[Felipe Contreras]

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/plat-omap/mailbox.c |   44 +-
 1 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 36b3aa2..38a6cb1 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -142,14 +142,14 @@ static void mbox_rx_work(struct work_struct *work)
struct omap_mbox_queue *mq =
container_of(work, struct omap_mbox_queue, work);
mbox_msg_t msg;
-   int len;
-  
-   while (kfifo_len(mq-fifo) = sizeof(msg)) {
-   len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
-   WARN_ON(len != sizeof(msg));
-
-   if (mq-callback)
-   mq-callback((void *)msg);
+   int len;
+
+   while (kfifo_len(mq-fifo) = sizeof(msg)) {
+   len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
+   WARN_ON(len != sizeof(msg));
+
+   if (mq-callback)
+   mq-callback((void *)msg);
}
 }
 
@@ -165,12 +165,12 @@ static void __mbox_tx_interrupt(struct omap_mbox *mbox)
 
 static void __mbox_rx_interrupt(struct omap_mbox *mbox)
 {
-   struct omap_mbox_queue *mq = mbox-rxq;
+   struct omap_mbox_queue *mq = mbox-rxq;
mbox_msg_t msg;
-   int len;
+   int len;
 
while (!mbox_fifo_empty(mbox)) {
-   if (unlikely(kfifo_avail(mq-fifo)  sizeof(msg))) {
+   if (unlikely(kfifo_avail(mq-fifo)  sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
rq_full = true;
goto nomem;
@@ -178,8 +178,8 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
 
msg = mbox_fifo_read(mbox);
 
-   len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
-   WARN_ON(len != sizeof(msg));
+   len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
+   WARN_ON(len != sizeof(msg));
 
if (mbox-ops-type == OMAP_MBOX_TYPE1)
break;
@@ -278,11 +278,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
 
return 0;
 
- fail_alloc_rxq:
+fail_alloc_rxq:
mbox_queue_free(mbox-txq);
- fail_alloc_txq:
+fail_alloc_txq:
free_irq(mbox-irq, mbox);
- fail_request_irq:
+fail_request_irq:
if (mbox-ops-shutdown)
mbox-ops-shutdown(mbox);
 
@@ -359,10 +359,10 @@ int omap_mbox_register(struct device *parent, struct 
omap_mbox *mbox)
if (mbox-next)
return -EBUSY;
 
-   mbox-dev = device_create(omap_mbox_class,
- parent, 0, mbox, %s, mbox-name);
-   if (IS_ERR(mbox-dev))
-   return PTR_ERR(mbox-dev);
+   mbox-dev = device_create(omap_mbox_class,
+ parent, 0, mbox, %s, mbox-name);
+   if (IS_ERR(mbox-dev))
+   return PTR_ERR(mbox-dev);
 
spin_lock(mboxes_lock);
tmp = find_mboxes(mbox-name);
@@ -405,7 +405,7 @@ EXPORT_SYMBOL(omap_mbox_unregister);
 
 static int __init omap_mbox_init(void)
 {
-   int err;
+   int err;
 
err = class_register(omap_mbox_class);
if (err)
@@ -426,7 +426,7 @@ subsys_initcall(omap_mbox_init);
 static void __exit omap_mbox_exit(void)
 {
destroy_workqueue(mboxd);
-   class_unregister(omap_mbox_class);
+   class_unregister(omap_mbox_class);
 }
 module_exit(omap_mbox_exit);
 
-- 
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

[PATCH v4 02/14] omap: mailbox: trivial cleanups

[Felipe Contreras]

And fix a few compilation warnings.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/devices.c |6 ++
 arch/arm/mach-omap1/mailbox.c |2 +-
 arch/arm/mach-omap2/mailbox.c |   10 ++
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 379100c..462b59c 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -73,12 +73,10 @@ static inline void omap_init_rtc(void) {}
 #  define INT_DSP_MAILBOX1 INT_1610_DSP_MAILBOX1
 #endif
 
-#define OMAP1_MBOX_BASEOMAP16XX_MAILBOX_BASE
-
 static struct resource mbox_resources[] = {
{
-   .start  = OMAP1_MBOX_BASE,
-   .end= OMAP1_MBOX_BASE + OMAP1_MBOX_SIZE,
+   .start  = OMAP16XX_MAILBOX_BASE,
+   .end= OMAP16XX_MAILBOX_BASE + OMAP1_MBOX_SIZE,
.flags  = IORESOURCE_MEM,
},
{
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 4f5b3da..15bf2a2 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -83,7 +83,7 @@ static int omap1_mbox_fifo_full(struct omap_mbox *mbox)
struct omap_mbox1_fifo *fifo =
((struct omap_mbox1_priv *)mbox-priv)-rx_fifo;
 
-   return (mbox_read_reg(fifo-flag));
+   return mbox_read_reg(fifo-flag);
 }
 
 /* irq */
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 763272c..8c1070c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -131,7 +131,7 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
}
 
l = mbox_read_reg(MAILBOX_REVISION);
-   pr_info(omap mailbox rev %d.%d\n, (l  0xf0)  4, (l  0x0f));
+   pr_debug(omap mailbox rev %d.%d\n, (l  0xf0)  4, (l  0x0f));
 
if (cpu_is_omap44xx())
l = OMAP4_SMARTIDLE;
@@ -300,8 +300,6 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
 };
 
-
-
 /* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
 to use this*/
 static struct omap_mbox2_priv omap2_mbox_1_priv = {
@@ -357,7 +355,6 @@ struct omap_mbox mbox_2_info = {
 };
 EXPORT_SYMBOL(mbox_2_info);
 
-
 #if defined(CONFIG_ARCH_OMAP2420) /* IVA */
 static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -443,6 +440,11 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
 #endif
return 0;
 
+#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
+err_iva1:
+   omap_mbox_unregister(mbox_dsp_info);
+#endif
+
 err_dsp:
iounmap(mbox_base);
return ret;
-- 
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

[PATCH v4 03/14] omap: mailbox: reorganize structures

[Felipe Contreras]

OMAP4 ones messed up the organization.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap2/mailbox.c |   68 +
 1 files changed, 35 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 8c1070c..edcfec6 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -283,6 +283,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
  */
 
 /* FIXME: the following structs should be filled automatically by the user id 
*/
+
 /* DSP */
 static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -300,8 +301,40 @@ static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.irqdisable = MAILBOX_IRQENABLE(0),
 };
 
-/* OMAP4 specific data structure. Use the cpu_is_omap4xxx()
-to use this*/
+struct omap_mbox mbox_dsp_info = {
+   .name   = dsp,
+   .ops= omap2_mbox_ops,
+   .priv   = omap2_mbox_dsp_priv,
+};
+EXPORT_SYMBOL(mbox_dsp_info);
+
+#if defined(CONFIG_ARCH_OMAP2420)
+
+/* IVA */
+static struct omap_mbox2_priv omap2_mbox_iva_priv = {
+   .tx_fifo = {
+   .msg= MAILBOX_MESSAGE(2),
+   .fifo_stat  = MAILBOX_FIFOSTATUS(2),
+   },
+   .rx_fifo = {
+   .msg= MAILBOX_MESSAGE(3),
+   .msg_stat   = MAILBOX_MSGSTATUS(3),
+   },
+   .irqenable  = MAILBOX_IRQENABLE(3),
+   .irqstatus  = MAILBOX_IRQSTATUS(3),
+   .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
+   .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
+   .irqdisable = MAILBOX_IRQENABLE(3),
+};
+
+static struct omap_mbox mbox_iva_info = {
+   .name   = iva,
+   .ops= omap2_mbox_ops,
+   .priv   = omap2_mbox_iva_priv,
+};
+#endif
+
+/* OMAP4 */
 static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(0),
@@ -325,13 +358,6 @@ struct omap_mbox mbox_1_info = {
 };
 EXPORT_SYMBOL(mbox_1_info);
 
-struct omap_mbox mbox_dsp_info = {
-   .name   = dsp,
-   .ops= omap2_mbox_ops,
-   .priv   = omap2_mbox_dsp_priv,
-};
-EXPORT_SYMBOL(mbox_dsp_info);
-
 static struct omap_mbox2_priv omap2_mbox_2_priv = {
.tx_fifo = {
.msg= MAILBOX_MESSAGE(3),
@@ -355,30 +381,6 @@ struct omap_mbox mbox_2_info = {
 };
 EXPORT_SYMBOL(mbox_2_info);
 
-#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
-static struct omap_mbox2_priv omap2_mbox_iva_priv = {
-   .tx_fifo = {
-   .msg= MAILBOX_MESSAGE(2),
-   .fifo_stat  = MAILBOX_FIFOSTATUS(2),
-   },
-   .rx_fifo = {
-   .msg= MAILBOX_MESSAGE(3),
-   .msg_stat   = MAILBOX_MSGSTATUS(3),
-   },
-   .irqenable  = MAILBOX_IRQENABLE(3),
-   .irqstatus  = MAILBOX_IRQSTATUS(3),
-   .notfull_bit= MAILBOX_IRQ_NOTFULL(2),
-   .newmsg_bit = MAILBOX_IRQ_NEWMSG(3),
-   .irqdisable = MAILBOX_IRQENABLE(3),
-};
-
-static struct omap_mbox mbox_iva_info = {
-   .name   = iva,
-   .ops= omap2_mbox_ops,
-   .priv   = omap2_mbox_iva_priv,
-};
-#endif
-
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
struct resource *res;
-- 
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

[PATCH v4 05/14] omap: mailbox: use correct config for omap1

[Felipe Contreras]

CONFIG_OMAP_DSP is not in mainline, CONFIG_OMAP_MBOX_FWK is.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/devices.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 462b59c..da796f2 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -63,7 +63,7 @@ static void omap_init_rtc(void)
 static inline void omap_init_rtc(void) {}
 #endif
 
-#if defined(CONFIG_OMAP_DSP) || defined(CONFIG_OMAP_DSP_MODULE)
+#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
 
 #if defined(CONFIG_ARCH_OMAP15XX)
 #  define OMAP1_MBOX_SIZE  0x23
-- 
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

[PATCH v4 06/14] omap: mailbox: update omap1 probing

[Felipe Contreras]

Based on omap2 code.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/mailbox.c |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 15bf2a2..211b9fc 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -146,12 +146,7 @@ EXPORT_SYMBOL(mbox_dsp_info);
 static int __devinit omap1_mbox_probe(struct platform_device *pdev)
 {
struct resource *res;
-
-   if (pdev-num_resources != 2) {
-   dev_err(pdev-dev, invalid number of resources: %d\n,
-   pdev-num_resources);
-   return -ENODEV;
-   }
+   int ret;
 
/* MBOX base */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -161,27 +156,32 @@ static int __devinit omap1_mbox_probe(struct 
platform_device *pdev)
}
 
mbox_base = ioremap(res-start, resource_size(res));
-   if (!mbox_base) {
-   dev_err(pdev-dev, ioremap failed\n);
-   return -ENODEV;
-   }
+   if (!mbox_base)
+   return -ENOMEM;
 
/* DSP IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!res)) {
dev_err(pdev-dev, invalid irq resource\n);
-   iounmap(mbox_base);
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_out;
}
mbox_dsp_info.irq = res-start;
 
-   return omap_mbox_register(pdev-dev, mbox_dsp_info);
+   ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
+   if (ret)
+   goto err_out;
+   return 0;
+
+err_out:
+   iounmap(mbox_base);
+   return ret;
 }
 
 static int __devexit omap1_mbox_remove(struct platform_device *pdev)
 {
omap_mbox_unregister(mbox_dsp_info);
-
+   iounmap(mbox_base);
return 0;
 }
 
-- 
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

[PATCH v4 04/14] omap: mailbox: 2420 should be detected at run-time

[Felipe Contreras]

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap2/mailbox.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index edcfec6..f67cb2c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -455,7 +455,8 @@ err_dsp:
 static int __devexit omap2_mbox_remove(struct platform_device *pdev)
 {
 #if defined(CONFIG_ARCH_OMAP2420)
-   omap_mbox_unregister(mbox_iva_info);
+   if (cpu_is_omap2420())
+   omap_mbox_unregister(mbox_iva_info);
 #endif
 
if (cpu_is_omap44xx()) {
-- 
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

[PATCH v4 07/14] omap: mailbox: don't export unecessary symbols

[Felipe Contreras]

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/mailbox.c |1 -
 arch/arm/mach-omap2/mailbox.c |3 ---
 2 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 211b9fc..590ac66 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -141,7 +141,6 @@ struct omap_mbox mbox_dsp_info = {
.ops= omap1_mbox_ops,
.priv   = omap1_mbox_dsp_priv,
 };
-EXPORT_SYMBOL(mbox_dsp_info);
 
 static int __devinit omap1_mbox_probe(struct platform_device *pdev)
 {
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index f67cb2c..3ff1ad5 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -306,7 +306,6 @@ struct omap_mbox mbox_dsp_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_dsp_priv,
 };
-EXPORT_SYMBOL(mbox_dsp_info);
 
 #if defined(CONFIG_ARCH_OMAP2420)
 
@@ -356,7 +355,6 @@ struct omap_mbox mbox_1_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_1_priv,
 };
-EXPORT_SYMBOL(mbox_1_info);
 
 static struct omap_mbox2_priv omap2_mbox_2_priv = {
.tx_fifo = {
@@ -379,7 +377,6 @@ struct omap_mbox mbox_2_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_2_priv,
 };
-EXPORT_SYMBOL(mbox_2_info);
 
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
-- 
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

[PATCH v4 08/14] omap: mailbox: remove unecessary fields

[Felipe Contreras]

Nobody is using them.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/plat-omap/include/plat/mailbox.h |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index 0c3c4a5..aad8bf8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -52,19 +52,11 @@ struct omap_mbox_queue {
 struct omap_mbox {
char*name;
unsigned intirq;
-
struct omap_mbox_queue  *txq, *rxq;
-
struct omap_mbox_ops*ops;
-
-   mbox_msg_t  seq_snd, seq_rcv;
-
struct device   *dev;
-
struct omap_mbox*next;
void*priv;
-
-   void(*err_notify)(void);
 };
 
 int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
-- 
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

[PATCH v4 09/14] omap: mailbox: add IRQ names

[Felipe Contreras]

Will be useful to identify them later.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/devices.c |1 +
 arch/arm/mach-omap2/devices.c |4 
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index da796f2..314fea3 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -82,6 +82,7 @@ static struct resource mbox_resources[] = {
{
.start  = INT_DSP_MAILBOX1,
.flags  = IORESOURCE_IRQ,
+   .name   = dsp,
},
 };
 
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..b621476 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -150,10 +150,12 @@ static struct resource omap2_mbox_resources[] = {
{
.start  = INT_24XX_MAIL_U0_MPU,
.flags  = IORESOURCE_IRQ,
+   .name   = dsp,
},
{
.start  = INT_24XX_MAIL_U3_MPU,
.flags  = IORESOURCE_IRQ,
+   .name   = iva,
},
 };
 static int omap2_mbox_resources_sz = ARRAY_SIZE(omap2_mbox_resources);
@@ -172,6 +174,7 @@ static struct resource omap3_mbox_resources[] = {
{
.start  = INT_24XX_MAIL_U0_MPU,
.flags  = IORESOURCE_IRQ,
+   .name   = dsp,
},
 };
 static int omap3_mbox_resources_sz = ARRAY_SIZE(omap3_mbox_resources);
@@ -193,6 +196,7 @@ static struct resource omap4_mbox_resources[] = {
{
.start  = OMAP44XX_IRQ_MAIL_U0,
.flags  = IORESOURCE_IRQ,
+   .name   = mbox,
},
 };
 static int omap4_mbox_resources_sz = ARRAY_SIZE(omap4_mbox_resources);
-- 
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

[PATCH v4 10/14] omap: mailbox: reorganize registering

[Felipe Contreras]

It's more extensible this way.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/mailbox.c |   42 
 arch/arm/mach-omap2/mailbox.c |  107 +
 2 files changed, 66 insertions(+), 83 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 590ac66..0318754 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -29,6 +29,8 @@
 
 static void __iomem *mbox_base;
 
+static struct omap_mbox **list;
+
 struct omap_mbox1_fifo {
unsigned long cmd;
unsigned long data;
@@ -142,44 +144,44 @@ struct omap_mbox mbox_dsp_info = {
.priv   = omap1_mbox_dsp_priv,
 };
 
+struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
+
 static int __devinit omap1_mbox_probe(struct platform_device *pdev)
 {
-   struct resource *res;
+   struct resource *mem;
int ret;
+   int i;
 
-   /* MBOX base */
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid mem resource\n);
-   return -ENODEV;
-   }
+   list = omap1_mboxes;
+
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);
 
-   mbox_base = ioremap(res-start, resource_size(res));
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mbox_base = ioremap(mem-start, resource_size(mem));
if (!mbox_base)
return -ENOMEM;
 
-   /* DSP IRQ */
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid irq resource\n);
-   ret = -ENODEV;
-   goto err_out;
+   for (i = 0; list[i]; i++) {
+   ret = omap_mbox_register(pdev-dev, list[i]);
+   if (ret)
+   goto err_out;
}
-   mbox_dsp_info.irq = res-start;
-
-   ret = omap_mbox_register(pdev-dev, mbox_dsp_info);
-   if (ret)
-   goto err_out;
return 0;
 
 err_out:
+   while (i--)
+   omap_mbox_unregister(list[i]);
iounmap(mbox_base);
return ret;
 }
 
 static int __devexit omap1_mbox_remove(struct platform_device *pdev)
 {
-   omap_mbox_unregister(mbox_dsp_info);
+   int i;
+
+   for (i = 0; list[i]; i++)
+   omap_mbox_unregister(list[i]);
+
iounmap(mbox_base);
return 0;
 }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 3ff1ad5..e5abc8e 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -56,6 +56,8 @@
 
 static void __iomem *mbox_base;
 
+static struct omap_mbox **list;
+
 struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
@@ -307,6 +309,8 @@ struct omap_mbox mbox_dsp_info = {
.priv   = omap2_mbox_dsp_priv,
 };
 
+struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
+
 #if defined(CONFIG_ARCH_OMAP2420)
 
 /* IVA */
@@ -331,6 +335,8 @@ static struct omap_mbox mbox_iva_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_iva_priv,
 };
+
+struct omap_mbox *omap2_mboxes[] = { mbox_iva_info, mbox_dsp_info, NULL };
 #endif
 
 /* OMAP4 */
@@ -378,89 +384,64 @@ struct omap_mbox mbox_2_info = {
.priv   = omap2_mbox_2_priv,
 };
 
+struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
+
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
-   struct resource *res;
+   struct resource *mem;
int ret;
+   int i;
 
-   /* MBOX base */
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid mem resource\n);
-   return -ENODEV;
+   if (cpu_is_omap3430()) {
+   list = omap3_mboxes;
+
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
-   mbox_base = ioremap(res-start, resource_size(res));
-   if (!mbox_base)
-   return -ENOMEM;
+#if defined(CONFIG_ARCH_OMAP2420)
+   else if (cpu_is_omap2420()) {
+   list = omap2_mboxes;
 
-   /* DSP or IVA2 IRQ */
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   list[0]-irq = platform_get_irq_byname(pdev, dsp);
+   list[1]-irq = platform_get_irq_byname(pdev, iva);
+   }
+#endif
+   else if (cpu_is_omap44xx()) {
+   list = omap4_mboxes;
 
-   if (unlikely(!res)) {
-   dev_err(pdev-dev, invalid irq resource\n);
-   ret = -ENODEV;
-   goto err_dsp;
+   list[0]-irq = list[1]-irq =
+   platform_get_irq_byname(pdev, mbox);
}
-   if (cpu_is_omap44xx()) {
-   mbox_1_info.irq = res-start;
-   ret = omap_mbox_register(pdev-dev, mbox_1_info);
-   } else {
-   mbox_dsp_info.irq = res-start;
-

[PATCH v4 11/14] omap: mailbox: simplify omap_mbox_register()

[Felipe Contreras]

No need to dynamically register mailboxes one by one.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/mailbox.c |   25 ++--
 arch/arm/mach-omap2/mailbox.c |   22 ++-
 arch/arm/plat-omap/include/plat/mailbox.h |5 +-
 arch/arm/plat-omap/mailbox.c  |   95 +++--
 4 files changed, 50 insertions(+), 97 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 0318754..9ca0d58 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -29,8 +29,6 @@
 
 static void __iomem *mbox_base;
 
-static struct omap_mbox **list;
-
 struct omap_mbox1_fifo {
unsigned long cmd;
unsigned long data;
@@ -151,9 +149,9 @@ static int __devinit omap1_mbox_probe(struct 
platform_device *pdev)
struct resource *mem;
int ret;
int i;
+   struct omap_mbox **list;
 
list = omap1_mboxes;
-
list[0]-irq = platform_get_irq_byname(pdev, dsp);
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -161,27 +159,18 @@ static int __devinit omap1_mbox_probe(struct 
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
 
-   for (i = 0; list[i]; i++) {
-   ret = omap_mbox_register(pdev-dev, list[i]);
-   if (ret)
-   goto err_out;
+   ret = omap_mbox_register(pdev-dev, list);
+   if (ret) {
+   iounmap(mbox_base);
+   return ret;
}
-   return 0;
 
-err_out:
-   while (i--)
-   omap_mbox_unregister(list[i]);
-   iounmap(mbox_base);
-   return ret;
+   return 0;
 }
 
 static int __devexit omap1_mbox_remove(struct platform_device *pdev)
 {
-   int i;
-
-   for (i = 0; list[i]; i++)
-   omap_mbox_unregister(list[i]);
-
+   omap_mbox_unregister();
iounmap(mbox_base);
return 0;
 }
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index e5abc8e..55d8b77 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -56,8 +56,6 @@
 
 static void __iomem *mbox_base;
 
-static struct omap_mbox **list;
-
 struct omap_mbox2_fifo {
unsigned long msg;
unsigned long fifo_stat;
@@ -390,7 +388,7 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
 {
struct resource *mem;
int ret;
-   int i;
+   struct omap_mbox **list;
 
if (cpu_is_omap3430()) {
list = omap3_mboxes;
@@ -421,27 +419,19 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
if (!mbox_base)
return -ENOMEM;
 
-   for (i = 0; list[i]; i++) {
-   ret = omap_mbox_register(pdev-dev, list[i]);
-   if (ret)
-   goto err_out;
+   ret = omap_mbox_register(pdev-dev, list);
+   if (ret) {
+   iounmap(mbox_base);
+   return ret;
}
return 0;
 
-err_out:
-   while (i--)
-   omap_mbox_unregister(list[i]);
-   iounmap(mbox_base);
return ret;
 }
 
 static int __devexit omap2_mbox_remove(struct platform_device *pdev)
 {
-   int i;
-
-   for (i = 0; list[i]; i++)
-   omap_mbox_unregister(list[i]);
-
+   omap_mbox_unregister();
iounmap(mbox_base);
return 0;
 }
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index aad8bf8..c44fde3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -55,7 +55,6 @@ struct omap_mbox {
struct omap_mbox_queue  *txq, *rxq;
struct omap_mbox_ops*ops;
struct device   *dev;
-   struct omap_mbox*next;
void*priv;
 };
 
@@ -65,8 +64,8 @@ void omap_mbox_init_seq(struct omap_mbox *);
 struct omap_mbox *omap_mbox_get(const char *);
 void omap_mbox_put(struct omap_mbox *);
 
-int omap_mbox_register(struct device *parent, struct omap_mbox *);
-int omap_mbox_unregister(struct omap_mbox *);
+int omap_mbox_register(struct device *parent, struct omap_mbox **);
+int omap_mbox_unregister(void);
 
 static inline void omap_mbox_save_ctx(struct omap_mbox *mbox)
 {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 38a6cb1..a8e22e1 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,8 +33,7 @@
 #include plat/mailbox.h
 
 static struct workqueue_struct *mboxd;
-static struct omap_mbox *mboxes;
-static DEFINE_SPINLOCK(mboxes_lock);
+static struct omap_mbox **mboxes;
 static bool rq_full;
 
 static int mbox_configured;
@@ -307,31 +306,20 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
}
 }
 
-static struct omap_mbox **find_mboxes(const char *name)
-{
-   struct omap_mbox **p;
-
-   for (p = mboxes; *p; p = (*p)-next) 

[PATCH v4 12/14] omap: mailbox: only compile for configured archs

[Felipe Contreras]

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap2/mailbox.c |   15 +--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 55d8b77..4c0c112 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -284,6 +284,7 @@ static struct omap_mbox_ops omap2_mbox_ops = {
 
 /* FIXME: the following structs should be filled automatically by the user id 
*/
 
+#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP2420)
 /* DSP */
 static struct omap_mbox2_priv omap2_mbox_dsp_priv = {
.tx_fifo = {
@@ -306,11 +307,13 @@ struct omap_mbox mbox_dsp_info = {
.ops= omap2_mbox_ops,
.priv   = omap2_mbox_dsp_priv,
 };
+#endif
 
+#if defined(CONFIG_ARCH_OMAP3430)
 struct omap_mbox *omap3_mboxes[] = { mbox_dsp_info, NULL };
+#endif
 
 #if defined(CONFIG_ARCH_OMAP2420)
-
 /* IVA */
 static struct omap_mbox2_priv omap2_mbox_iva_priv = {
.tx_fifo = {
@@ -337,6 +340,7 @@ static struct omap_mbox mbox_iva_info = {
 struct omap_mbox *omap2_mboxes[] = { mbox_iva_info, mbox_dsp_info, NULL };
 #endif
 
+#if defined(CONFIG_ARCH_OMAP4)
 /* OMAP4 */
 static struct omap_mbox2_priv omap2_mbox_1_priv = {
.tx_fifo = {
@@ -383,6 +387,7 @@ struct omap_mbox mbox_2_info = {
 };
 
 struct omap_mbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
+#endif
 
 static int __devinit omap2_mbox_probe(struct platform_device *pdev)
 {
@@ -390,11 +395,15 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
int ret;
struct omap_mbox **list;
 
-   if (cpu_is_omap3430()) {
+   if (false)
+   ;
+#if defined(CONFIG_ARCH_OMAP3430)
+   else if (cpu_is_omap3430()) {
list = omap3_mboxes;
 
list[0]-irq = platform_get_irq_byname(pdev, dsp);
}
+#endif
 #if defined(CONFIG_ARCH_OMAP2420)
else if (cpu_is_omap2420()) {
list = omap2_mboxes;
@@ -403,12 +412,14 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
list[1]-irq = platform_get_irq_byname(pdev, iva);
}
 #endif
+#if defined(CONFIG_ARCH_OMAP4)
else if (cpu_is_omap44xx()) {
list = omap4_mboxes;
 
list[0]-irq = list[1]-irq =
platform_get_irq_byname(pdev, mbox);
}
+#endif
else {
pr_err(%s: platform not supported\n, __func__);
return -ENODEV;
-- 
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

[PATCH v4 13/14] omap: mailbox: standarize on 'omap-mailbox'

[Felipe Contreras]

omap{1,2}-mailbox are modules that provide the 'omap-mailbox' driver.

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/devices.c |2 +-
 arch/arm/mach-omap1/mailbox.c |4 ++--
 arch/arm/mach-omap2/devices.c |2 +-
 arch/arm/mach-omap2/mailbox.c |6 ++
 4 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 314fea3..16e43e5 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -87,7 +87,7 @@ static struct resource mbox_resources[] = {
 };
 
 static struct platform_device mbox_device = {
-   .name   = omap1-mailbox,
+   .name   = omap-mailbox,
.id = -1,
.num_resources  = ARRAY_SIZE(mbox_resources),
.resource   = mbox_resources,
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 9ca0d58..afc3963 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -1,5 +1,5 @@
 /*
- * Mailbox reservation modules for DSP
+ * Mailbox reservation modules for OMAP1
  *
  * Copyright (C) 2006-2009 Nokia Corporation
  * Written by: Hiroshi DOYU hiroshi.d...@nokia.com
@@ -179,7 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
.probe  = omap1_mbox_probe,
.remove = __devexit_p(omap1_mbox_remove),
.driver = {
-   .name   = omap1-mailbox,
+   .name   = omap-mailbox,
},
 };
 
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index b621476..d9ac853 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -206,7 +206,7 @@ static int omap4_mbox_resources_sz = 
ARRAY_SIZE(omap4_mbox_resources);
 #endif
 
 static struct platform_device mbox_device = {
-   .name   = omap2-mailbox,
+   .name   = omap-mailbox,
.id = -1,
 };
 
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 4c0c112..62d5ffe 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -18,8 +18,6 @@
 #include plat/mailbox.h
 #include mach/irqs.h
 
-#define DRV_NAME omap2-mailbox
-
 #define MAILBOX_REVISION   0x000
 #define MAILBOX_SYSCONFIG  0x010
 #define MAILBOX_SYSSTATUS  0x014
@@ -451,7 +449,7 @@ static struct platform_driver omap2_mbox_driver = {
.probe = omap2_mbox_probe,
.remove = __devexit_p(omap2_mbox_remove),
.driver = {
-   .name = DRV_NAME,
+   .name = omap-mailbox,
},
 };
 
@@ -472,4 +470,4 @@ MODULE_LICENSE(GPL v2);
 MODULE_DESCRIPTION(omap mailbox: omap2/3/4 architecture specific functions);
 MODULE_AUTHOR(Hiroshi DOYU hiroshi.d...@nokia.com);
 MODULE_AUTHOR(Paul Mundt);
-MODULE_ALIAS(platform:DRV_NAME);
+MODULE_ALIAS(platform:omap2-mailbox);
-- 
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

[PATCH v4 14/14] omap: mailbox: reorganize headers

[Felipe Contreras]

Remove kernel.h and module.h since they are not used correctly anyway.

Also, remove device.h since it comes along with platform_device.h
(always will I guess).

Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
 arch/arm/mach-omap1/mailbox.c |3 ---
 arch/arm/mach-omap2/mailbox.c |1 -
 arch/arm/plat-omap/include/plat/mailbox.h |3 ++-
 arch/arm/plat-omap/mailbox.c  |5 ++---
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index afc3963..1a85a42 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -9,13 +9,10 @@
  * for more details.
  */
 
-#include linux/kernel.h
-#include linux/resource.h
 #include linux/interrupt.h
 #include linux/platform_device.h
 #include linux/io.h
 #include plat/mailbox.h
-#include mach/irqs.h
 
 #define MAILBOX_ARM2DSP1   0x00
 #define MAILBOX_ARM2DSP1b  0x04
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 62d5ffe..42dbfa4 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -10,7 +10,6 @@
  * for more details.
  */
 
-#include linux/kernel.h
 #include linux/clk.h
 #include linux/err.h
 #include linux/platform_device.h
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index c44fde3..9976565 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -3,9 +3,10 @@
 #ifndef MAILBOX_H
 #define MAILBOX_H
 
-#include linux/wait.h
+#include linux/spinlock.h
 #include linux/workqueue.h
 #include linux/interrupt.h
+#include linux/device.h
 #include linux/kfifo.h
 
 typedef u32 mbox_msg_t;
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index a8e22e1..8d4c7be 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -21,10 +21,9 @@
  *
  */
 
-#include linux/kernel.h
-#include linux/module.h
 #include linux/interrupt.h
-#include linux/device.h
+#include linux/spinlock.h
+#include linux/mutex.h
 #include linux/delay.h
 #include linux/slab.h
 #include linux/kfifo.h
-- 
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: Alternative for defconfig

[Felipe Contreras]

On Fri, Jun 11, 2010 at 6:07 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 My understanding is that Linus will remove all ARM defconfigs in 2.6.36,
 unless someone can convince him not to.

Huh? I thought he was only threatening to remove them[1]. I don't
think he said he was going to do that without any alternative in
place.

My suggestion[2] was to have minimal defconfigs so that we could do
$ cp arch/arm/configs/omap3_beagle_baseconfig .config
$ echo  | make ARCH=arm oldconfig

[1] http://article.gmane.org/gmane.linux.kernel/994194
[2] http://article.gmane.org/gmane.linux.kernel/995412

-- 
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: [linux-pm] suspend blockers Android integration

[Alan Stern]

On Fri, 11 Jun 2010, Mark Brown wrote:

 On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
  On Fri, 11 Jun 2010, James Bottomley wrote:
 
   The one thing that does look difficult is that these power constraints
   are device (and sometimes SoC) specific.  Expressing them in a generic
   way for the cpu govenors to make sense of might be hard.
 
  Doesn't the clock framework already handle this sort of thing?
 
 The clock framework is implemented independantly for each CPU.

That's not an impediment, since drivers' requirements regarding which 
clocks remain running in which power states are necessarily 
platform-dependent also.


On Fri, 11 Jun 2010, James Bottomley wrote:

 Well, there are two elements to this sort of thing:
 
  1. Allow a driver to request that a given clock not be turned off.
  2. Make the cpuidle governors aware of a pending don't turn off X
 clock source so they can keep the system in a state where the
 clock doesn't get powered down.
 
 As far as I can tell from the code, neither currently exists at the
 moment.

Well then, can (or should) the clock framework interact with the
pm-qos subsystem so that drivers don't have to worry about it?

Alan Stern

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

Re: [linux-pm] suspend blockers Android integration

[James Bottomley]

On Fri, 2010-06-11 at 16:48 -0400, Alan Stern wrote:
 On Fri, 11 Jun 2010, Mark Brown wrote:
 
  On Fri, Jun 11, 2010 at 10:46:27AM -0400, Alan Stern wrote:
   On Fri, 11 Jun 2010, James Bottomley wrote:
  
The one thing that does look difficult is that these power constraints
are device (and sometimes SoC) specific.  Expressing them in a generic
way for the cpu govenors to make sense of might be hard.
  
   Doesn't the clock framework already handle this sort of thing?
  
  The clock framework is implemented independantly for each CPU.
 
 That's not an impediment, since drivers' requirements regarding which 
 clocks remain running in which power states are necessarily 
 platform-dependent also.
 
 
 On Fri, 11 Jun 2010, James Bottomley wrote:
 
  Well, there are two elements to this sort of thing:
  
   1. Allow a driver to request that a given clock not be turned off.
   2. Make the cpuidle governors aware of a pending don't turn off X
  clock source so they can keep the system in a state where the
  clock doesn't get powered down.
  
  As far as I can tell from the code, neither currently exists at the
  moment.
 
 Well then, can (or should) the clock framework interact with the
 pm-qos subsystem so that drivers don't have to worry about it?

So the implementation of this seems to be a bit complex:  We could have
clockevents_register() do a per clock pm_qos variable but then the
cpuidle governors need to know which to listen for so they don't
transition to a state too low for them to be active if pm_qos says keep
them running.  Even if that gets sorted out, how would USB know which
platform specific clock source is driving the wakeup events on its bus?

How complex can SoC clocksources be?  If it's just a simple binary
do/don't potentially stop all clocks, I think it's easy.  If SoC's have
a hierarchical shutdown sequence, and they really need this to save
power, then expressing that generically becomes rather problematic.

James




--
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] mailbox: change full flag per mailbox queue instead of global

[Fernando Guzman Lugo]

As pointer by Ben Ohand, the variable rq_full flag is a global
variable, so if there are multiple mailbox user there will be
conflics. Now there is a full flag per mailbox queue.

Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
 arch/arm/plat-omap/include/plat/mailbox.h |1 +
 arch/arm/plat-omap/mailbox.c  |7 +++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
b/arch/arm/plat-omap/include/plat/mailbox.h
index 729166b..a6144b8 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -47,6 +47,7 @@ struct omap_mbox_queue {
struct tasklet_struct   tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+   boolfull;
 };
 
 struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 8d86b0b..a1e274e 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -30,7 +30,6 @@
 
 static struct omap_mbox *mboxes;
 static DEFINE_RWLOCK(mboxes_lock);
-static bool rq_full;
 
 static int mbox_configured;
 static DEFINE_MUTEX(mbox_configured_lock);
@@ -140,9 +139,9 @@ static void mbox_rx_work(struct work_struct *work)
while (1) {
spin_lock_irqsave(q-queue_lock, flags);
rq = blk_fetch_request(q);
-   if (rq_full) {
+   if (mbox-rxq-full) {
omap_mbox_enable_irq(mbox, IRQ_RX);
-   rq_full = false;
+   mbox-rxq-full = false;
}
spin_unlock_irqrestore(q-queue_lock, flags);
if (!rq)
@@ -183,7 +182,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
rq = blk_get_request(q, WRITE, GFP_ATOMIC);
if (unlikely(!rq)) {
omap_mbox_disable_irq(mbox, IRQ_RX);
-   rq_full = true;
+   mbox-rxq-full = true;
goto nomem;
}
 
-- 
1.6.3.3

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

Re: [linux-pm] suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/11 Alan Stern st...@rowland.harvard.edu:
 On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:

  You've lost me.  If the power manager is sitting inside a select/poll,
  how can it miss the event (given that the event will make data
  available to be read on one of the descriptors being polled)?
 

 It cannot sit inside of select/poll all the time.

  Or put it another way: With wakelocks, if the app doesn't use a suspend
  blocker then once it reads the event data and the timed wakelock is
  deactivated, there is nothing to prevent the system from immediately
  going into opportunistic suspend.  My scheme can fail in the same way.
  Is that what you meant?
 

 No, if an app reads from a file descriptor and block suspend when the
 read call returns, then suspend is blocked while processing the data.
 If the driver uses a wakelock with a timeout this will fail if the
 thread does not get to the suspend block call before the timeout
 expires, but unrelated events that don't prevent the app from running
 will not cause any problems.

 Wait a second.  Maybe I have misunderstood how timeouts are supposed to
 work with wakelocks.  I thought the idea was that the wakelock would be
 released when the timeout expires or the event queue is emptied,

That is one way to use it, and I did this so code that opened an input
device without reading from it would not prevent suspend forever. In
the last patchset I posted, I instead used an ioctl to enable the
suspend blocker.

 whichever comes first.  Now it sounds like you're saying that the
 wakelock doesn't get released until the timeout expires, even if
 userspace finishes processing all pending events before then.


For incoming network traffic we use a wakelock with a timeout to
prevent suspend long enough for the data to make it to user-space
since we have not added wakelocks to the network stack.

 In your scheme the user-space power
 manager may miss events on this file descriptor since select/poll will
 not see an event if the app read that event right before the power
 manager called select/poll.

 If the wakelock is supposed to remain active until the timeout expires
 then you are right.  On the other hand, this seems like a rather
 strange and suspicious way of handling wakelocks.  Why would you want
 to do it that way?


We did this to avoid changing to the network stack, tty layer, etc.

  There's one question that I don't remember ever seeing answered.  To
  which kernel drivers do you intend to add suspend blockers?
 

 All drivers that generate wakeup events need to either use suspend
 blockers directly or call into something else that does. For instance,
 with the patch to block suspend while input events are queued to
 user-space, an input driver that fully handles its events in its
 interrupt handler does not need any additional suspend blockers, but
 if the driver needs a work function or a timer to run before it
 reports the event it needs to block suspend until it has reported the
 event.

 Sure.  But specifically, which drivers on Android generate wakeup
 events?  And which of them don't fully handle their events in their
 interrupt handlers?


Keypad, network, charger, rtc, but I'm sure I forgot some.

 Maybe another way to put this is: Where in the kernel do you intend to
 add suspend blockers?


In addition to the drivers that enable the wakeup events, we have
added suspend blockers to the input event code and power supply
framework. The tty layer and network stack would also need suspend
blockers to avoid using timeouts.

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

RE: [PATCH 00/40] dspbridge: trivial error code cleanup

[Ramirez Luna, Omar]

From: Ramirez Luna, Omar

These set of patches gets rid of the custom error codes still present.

Although there are a lot of patches most of them are just replacements
which were broken into single patches to avoid big patch files.

One of the patches creates a help file with the matching linux
error codes just in case the error is not descriptive enough, and
it also lists a common scenario where the error might be seen.

Finally, the last patch replaces a custom typedef (dsp_status)
with an int type as now those errors can have a negative value.

Omar Ramirez Luna (40):
  DSPBRIDGE: Remove success codes
  DSPBRIDGE: change DSP_SENUMCOMPLETE for ENODATA
  DSPBRIDGE: err code replace CHNL_E_WAITTIMEOUT with ETIMEDOUT
  DSPBRIDGE: err code replace CHNL_E_NOEOS with EPERM
  DSPBRIDGE: err code replace CHNL_E_BUFSIZE with EINVAL
  DSPBRIDGE: err code replace CHNL_E_NOIORPS with EIO
  DSPBRIDGE: err code replace CHNL_E_ISR with EIO
  DSPBRIDGE: err code replace CHNL_E_MGREXISTS with EEXIST
  DSPBRIDGE: err code replace CHNL_E_NOMEMMAP with EFAULT
  DSPBRIDGE: err code replace CHNL_E_INVALIDMEMBASE with EINVAL
  DSPBRIDGE: err code replace CHNL_E_INVALIDWORDSIZE with EINVAL
  DSPBRIDGE: err code replace CHNL_E_EOS with EPIPE
  DSPBRIDGE: err code replace CHNL_E_NOIOC with EREMOTEIO
  DSPBRIDGE: err code replace CHNL_E_BADCHANID with ECHRNG
  DSPBRIDGE: err code replace CHNL_E_OUTOFSTREAMS with ENOSR
  DSPBRIDGE: err code replace CHNL_E_MAXCHANNELS with ECHRNG
  DSPBRIDGE: err code replace COD_E_ZLCREATEFAILED with ESPIPE
  DSPBRIDGE: err code replace COD_E_SYMBOLNOTFOUND with ESPIPE
  DSPBRIDGE: err code replace COD_E_NOSYMBOLSLOADED with ESPIPE
  DSPBRIDGE: err code replace DSP_EDPMSUSPEND with EPERM
  DSPBRIDGE: err code replace DSP_EDYNLOAD with EILSEQ
  DSPBRIDGE: err code replace DSP_EBADSEGID with EBADR
  DSPBRIDGE: err code replace DSP_EOVERLAYMEMORY with ENXIO
  DSPBRIDGE: err code replace DSP_ENOSECT with ENXIO
  DSPBRIDGE: err code replace DSP_ETRANSLATE with ESRCH
  DSPBRIDGE: err code replace DSP_ENOTFOUND with ENOENT
  DSPBRIDGE: err code replace DSP_EDCDNOAUTOREGISTER with EACCES
  DSPBRIDGE: err code replace DSP_EDCDLOADBASE with EACCES
  DSPBRIDGE: err code replace DSP_EDCDGETSECT with EACCES
  DSPBRIDGE: err code replace DSP_EDCDPARSESECT with EACCES
  DSPBRIDGE: err code replace DSP_EDCDREADSECT with EACCES
  DSPBRIDGE: err code replace DSP_ESYMBOL with ESPIPE
  DSPBRIDGE: err code replace DSP_EWRONGSTATE with EBADR
  DSPBRIDGE: err code replace DSP_EPENDING with EPIPE
  DSPBRIDGE: err code replace DSP_ECHANGEDURINGENUM with EIDRM
  DSPBRIDGE: remove custom errbase definitions
  DSPBRIDGE: cleanup for duplicated error codes
  DSPBRIDGE: removed unused error codes from comments
  DSPBRIDGE: error code guide
  DSPBRIDGE: remove dsp_status typedef

 Documentation/tidspbridge/error-codes  |  157 ++
 arch/arm/plat-omap/include/dspbridge/_chnl_sm.h|2 +-
 arch/arm/plat-omap/include/dspbridge/cfg.h |   57 +++---
 arch/arm/plat-omap/include/dspbridge/chnl.h|   31 ++--
 arch/arm/plat-omap/include/dspbridge/clk.h |8 +-
 arch/arm/plat-omap/include/dspbridge/cmm.h |   44 ++--
 arch/arm/plat-omap/include/dspbridge/cod.h |   61 +++---
 arch/arm/plat-omap/include/dspbridge/dbdcd.h   |   73 +++
 arch/arm/plat-omap/include/dspbridge/dbdcddef.h|2 +-
 arch/arm/plat-omap/include/dspbridge/dbdefs.h  |5 +-
 arch/arm/plat-omap/include/dspbridge/dbldefs.h |2 +-
 arch/arm/plat-omap/include/dspbridge/dbll.h|   14 +-
 arch/arm/plat-omap/include/dspbridge/dblldefs.h|   47 ++---
 arch/arm/plat-omap/include/dspbridge/dev.h |  156 ++
 arch/arm/plat-omap/include/dspbridge/disp.h|   25 +--
 arch/arm/plat-omap/include/dspbridge/dmm.h |   18 +-
 arch/arm/plat-omap/include/dspbridge/drv.h |   38 ++--
 .../arm/plat-omap/include/dspbridge/dspapi-ioctl.h |2 +-
 arch/arm/plat-omap/include/dspbridge/dspapi.h  |8 +-
 arch/arm/plat-omap/include/dspbridge/dspchnl.h |   24 +-
 arch/arm/plat-omap/include/dspbridge/dspdefs.h |  226 ++--
 arch/arm/plat-omap/include/dspbridge/dspdeh.h  |8 +-
 arch/arm/plat-omap/include/dspbridge/dspio.h   |   10 +-
 arch/arm/plat-omap/include/dspbridge/dspmsg.h  |   10 +-
 arch/arm/plat-omap/include/dspbridge/errbase.h |  177 ---
 arch/arm/plat-omap/include/dspbridge/io.h  |   19 +-
 arch/arm/plat-omap/include/dspbridge/io_sm.h   |6 +-
 arch/arm/plat-omap/include/dspbridge/mgr.h |   34 ++--
 arch/arm/plat-omap/include/dspbridge/msg.h |2 +-
 arch/arm/plat-omap/include/dspbridge/nldr.h|   14 +-
 arch/arm/plat-omap/include/dspbridge/nldrdefs.h|   31 ++--
 arch/arm/plat-omap/include/dspbridge/node.h|  148 ++---
 arch/arm/plat-omap/include/dspbridge/nodepriv.h|8 +-
 arch/arm/plat-omap/include/dspbridge/ntfy.h   

Re: [linux-pm] suspend blockers Android integration

[David Brownell]

--- On Fri, 6/11/10, James Bottomley james.bottom...@suse.de wrote:

  Do we at least have a clean way that a driver can
  reject a system suspend?  I've lost track of
 many
  issues, but maybe this could be phrased as a QOS
  constraint:  the current config of driver X
 needs
  clock Y active to enter the  target system
 suspend
  state, driver's suspend() method reports as
 much.  Then the entry to
  that system state gets blocked
  if the clock isn't enabled.
 
 So in QoS modifications to android patches, the answer is yes ...
 except that the current android patch set didn't actually
 have this type
 of wakelock in it.

Except, we're not talking wakelock ... :)

So ... no, these cases still have no solution.
(I think  that's at least five years now.)


 The one thing that does look difficult is that these power
 constraints
 are device (and sometimes SoC) specific.

Exactly why they make good examples  for
turning up framework limitations... like
having overlooked constraints coming from
various SoC peripherals.

 Expressing them in a generic way
 for the cpu govenors to make sense of might be hard.

Requiring CPU governors to be involved in such
stuff feels a bit off-course to me.  At least, if
the involvement is very deep. The constraints are
from the integrated peripherals, not (usually)
from the CPU

There are plent of places to hang SoC or
device specific data, once there's awareness
that without such data, (which PCs hide behind
ACPI bytecode) the PM framework is missing out
on support for some desirable low power modes.


 
  (That QOS constraint should be removed when that
  driver no longer needs to issue wakeups; that's
  not quite the same as removed by driver.resume().
 
 The USB one needs user input, doesn't it,

I don't quite see that.  The drivers get called
in enough places, and they'll know if the system
is going to be in a suspend state where they need
to be partially 
aactive (with various QOS constraints, or they
can't work.

 since user hotplug might (or
 might not) be one of the wakeup sources.

If it wakes via hotplug, then the driver must
already Do The Right Thing; what input would
be needed  (Beyond changing the cable config)?

 
 James
 
 
 --

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