date:20100727

 -Original Message-
 From: Mankad, Maulik Ojas
 Sent: Tuesday, July 27, 2010 12:05 PM
 To: linux-...@vger.kernel.org
 Cc: Shilimkar, Santosh; linux-arm-ker...@lists.infradead.org; linux-
 o...@vger.kernel.org
 Subject: Issue with file transfers to a mass storage device on SMP system

 Hello,

 I am working on OMAP4 which has two ARM Cortex A9 microprocessors (SMP
 system) with 2.6.35-rc5 kernel.

 I have an issue whereby transferring a large file (20MB) over USB (OMAP
 Mentor USB controller acts as USB host) to an attached USB thumb drive
 fails.

 The USB analyzer trace shows that the 31 bytes CBW packet is corrupted and
 device responds with a STALL when this issue occurs.

 Further it was found that the CBWCB field (the last 16 bytes which
 contains
 the command to be executed by the device) of the CBW packet was Zero in
 the
 failure case. Also the first 15 bytes of the CBW packet contained valid
 data.

 The code snippet below from usb_stor_Bulk_transport () in
 drivers/usb/storage/transport.c looks to be a problem area.

 /* copy the command payload */

  memset(bcb-CDB, 0, sizeof(bcb-CDB));
  memcpy(bcb-CDB, srb-cmnd, bcb-Length);

 Looks like when the issue occurs the memory (bcb-CDB) is not yet updated
 due to likely out of order execution due to SMP.

As discussed, the main reason is the cache maintenance isn't done on
 bcb-CDB  buffers and hence the data remains in CPU write buffer instead of 
the physical memory on which DMA operates. 
In working scenario's, there might be a barrier in the path which is helping
you.

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: Issue with file transfers to a mass storage device on SMP system

On Tue, Jul 27, 2010 at 03:08:54PM +0530, Shilimkar, Santosh wrote:
 As discussed, the main reason is the cache maintenance isn't done on
  bcb-CDB  buffers and hence the data remains in CPU write buffer
 instead of the physical memory on which DMA operates. 

struct bulk_cb_wrap {
__le32  Signature;  /* contains 'USBC' */
__u32   Tag;/* unique per command id */
__le32  DataTransferLength; /* size of data */
__u8Flags;  /* direction in bit 0 */
__u8Lun;/* LUN normally 0 */
__u8Length; /* of of the CDB */
__u8CDB[16];/* max command */
};

So, CDB is contained within bcb...bcb+sizeof(*bcb).

The bcb is passed to usb_stor_bulk_transfer_buf:

result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
bcb, cbwlen, NULL);

which fills it into a URB:

usb_fill_bulk_urb(us-current_urb, us-pusb_dev, pipe, buf, length,
  usb_stor_blocking_completion, NULL);

This sets the URB buffer pointers:

urb-transfer_buffer = transfer_buffer;
urb-transfer_buffer_length = buffer_length;

And this buffer should be dma-mapped and dma-unmapped as appropriate.

Wasn't there an issue with the DMA mapping being used with a PIO USB
host recently?  Is that the problem here?
--
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: Issue with file transfers to a mass storage device on SMP system

 -Original Message-
 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
 Sent: Tuesday, July 27, 2010 3:31 PM
 To: Shilimkar, Santosh
 Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: Re: Issue with file transfers to a mass storage device on SMP
 system

 On Tue, Jul 27, 2010 at 03:08:54PM +0530, Shilimkar, Santosh wrote:
  As discussed, the main reason is the cache maintenance isn't done on
   bcb-CDB  buffers and hence the data remains in CPU write buffer
  instead of the physical memory on which DMA operates.

 struct bulk_cb_wrap {
 __le32  Signature;  /* contains 'USBC' */
 __u32   Tag;/* unique per command id */
 __le32  DataTransferLength; /* size of data */
 __u8Flags;  /* direction in bit 0 */
 __u8Lun;/* LUN normally 0 */
 __u8Length; /* of of the CDB */
 __u8CDB[16];/* max command */
 };

 So, CDB is contained within bcb...bcb+sizeof(*bcb).

 The bcb is passed to usb_stor_bulk_transfer_buf:

 result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
 bcb, cbwlen, NULL);

 which fills it into a URB:

 usb_fill_bulk_urb(us-current_urb, us-pusb_dev, pipe, buf,
 length,
   usb_stor_blocking_completion, NULL);

 This sets the URB buffer pointers:

 urb-transfer_buffer = transfer_buffer;
 urb-transfer_buffer_length = buffer_length;

 And this buffer should be dma-mapped and dma-unmapped as appropriate.

 Wasn't there an issue with the DMA mapping being used with a PIO USB
 host recently?  Is that the problem here?
That's correct.
The last issue was otherway round where we were doing map/unmpap on PIO buffer.
This issue is because CDB[16], is not cleaned up before merging it into CBW.

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: Issue with file transfers to a mass storage device on SMP system

On Tue, Jul 27, 2010 at 03:49:29PM +0530, Shilimkar, Santosh wrote:
  On Tue, Jul 27, 2010 at 03:08:54PM +0530, Shilimkar, Santosh wrote:
   As discussed, the main reason is the cache maintenance isn't done on
bcb-CDB  buffers and hence the data remains in CPU write buffer
   instead of the physical memory on which DMA operates.
  
  struct bulk_cb_wrap {
  __le32  Signature;  /* contains 'USBC' */
  __u32   Tag;/* unique per command id */
  __le32  DataTransferLength; /* size of data */
  __u8Flags;  /* direction in bit 0 */
  __u8Lun;/* LUN normally 0 */
  __u8Length; /* of of the CDB */
  __u8CDB[16];/* max command */
  };
  
  So, CDB is contained within bcb...bcb+sizeof(*bcb).
  
  The bcb is passed to usb_stor_bulk_transfer_buf:
  
  result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
  bcb, cbwlen, NULL);
  
  which fills it into a URB:
  
  usb_fill_bulk_urb(us-current_urb, us-pusb_dev, pipe, buf,
  length,
usb_stor_blocking_completion, NULL);
  
  This sets the URB buffer pointers:
  
  urb-transfer_buffer = transfer_buffer;
  urb-transfer_buffer_length = buffer_length;
  
  And this buffer should be dma-mapped and dma-unmapped as appropriate.
  
  Wasn't there an issue with the DMA mapping being used with a PIO USB
  host recently?  Is that the problem here?
 That's correct.
 The last issue was otherway round where we were doing map/unmpap on PIO 
 buffer.

That's exactly what I said.

 This issue is because CDB[16], is not cleaned up before merging it into CBW.

The CDB array is part of the CBW (struct bulk_cb_wrap).  When the
struct bulk_cb_wrap is mapped for DMA, the CDB will also be as it
is contained entirely within the CBW structure.

As USB deals with the whole of the CBW as one block, it can't be that
half of it is being DMA-mapped and the other half isn't - something
else must be going on.  If the CDB was a separate chunk of memory, I
could believe what you're suggesting.

What we _do_ know is that 2.6.35-rc5 misses Catalin's barrier patches
for readl+writel, which means that there are ordering issues between
writing to memory and writing to devices.  This is what is going on
here, and it is confirmed by this:

| (3)Using wmb() (Write memory barrier) before starting DMA transfer in MUSB
| driver fixes the issue.

from Maulik.  The fix is to have Catalin's ordered IO accessors which
add the wmb() internally to writel() to ensure that memory accesses
are visible.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH:v4 00/13] OMAP: GPIO: Implement GPIO in HWMOD way

2010-07-27 Thread Cousson, Benoit


Hi Tony

On 7/6/2010 3:17 PM, Tony Lindgren wrote:

* Charulatha Vch...@ti.com  [100622 17:55]:

This patch series makes OMAP2PLUS specific GPIO implemented in HWMOD
FW way. This is done by implementing GPIO module in platform device model.

This patch series is generated on origin/pm-wip/hwmods-omap4.


Do we still have a dependency on this series to pm-wip?


Yep, I think we still need the runtime PM support and the OMAP4 hwmod 
data that are located only in pm-wip for the moment.


Regards,
Benoit


Can you please try to rebase this on top of linux-omap for-next
branch?

Let's see if we can merge this into linux-omap master
branch for some testing before we merge it.

Regards,

Tony


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

RE: [RFC 0/6] Introducing OMAP Remote Processor module

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 0/6] Introducing OMAP Remote Processor module

 From: Ohad Ben-Cohen oh...@ti.com

 This is a preliminary version of OMAP's remoteproc module,
 submitted for RFC purposes.

 The purpose of the remoteproc module is to decouple
 hw-specific code from generic IPC drivers (such as
 dspbridge and syslink), in order to eventually make
 those IPC drivers platform-independent.

 Currently the supported operations are starting and stopping
 the remote processor, but in the future additional functionality
 might be added.

 Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp
 remote processor, and OMAP4 supports ducati (tesla support
 is planned as well).

 The code was tested on both OMAP3 (using dspbridge) and OMAP4
 (using syslink).

 The code is preliminary: we plan to add much more extensive
 hwmod support, ideally squashing as much hw-specific code
 as possible (including RST and PRCM manipulations).
 In addition, a rebase to recent code bases is needed.

 While dspbridge accesses remoteproc's interface via pdata
 pointers, syslink accesses it from user space, via character
 device interface, so both kernel and user space interfaces
 are supported.

 A few words on the char device interface:

 * Each remote processor is represented by a different
   character device: /dev/omap-rproc0, /dev/omap-rproc1, ...

[sp] Concept of remote processor is not really tied to omap.
 Though the implementation is being done in context of
 OMAP, I would suggest removing the prefix omap- from
 the device name.

 * A rproc character device can only be opened by a single user
   (e.g. the syslink daemon)
 * The start/stop/get_state functionality is exposed via ioctl's
 * We plan to add automatic stop() invokation in case the user
   closes the device after starting a remote processor (for
   resource cleanup purposes. Thus the user will be required
   to hold the device open as long as it lives).

 Thanks,

 Hari Kanigeri (1):
   omap: introduce OMAP4 remoteproc module

 Ohad Ben-Cohen (5):
   omap: add iva2 hwmod support to omap3
   omap: introduce OMAP3 remoteproc module
   omap: introduce common remoteproc module
   omap: add remoteproc device(s)
   omap: enable remoteproc building

  arch/arm/mach-omap2/Makefile |6 +
  arch/arm/mach-omap2/devices.c|   86 +++
  arch/arm/mach-omap2/omap_hwmod_34xx.h|   23 ++
  arch/arm/mach-omap2/remoteproc3xxx.c |  226 
 ++
  arch/arm/mach-omap2/remoteproc44xx.c |  196 
  arch/arm/plat-omap/Kconfig   |7 +
  arch/arm/plat-omap/Makefile  |1 +
  arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
  arch/arm/plat-omap/include/plat/remoteproc.h |   75 ++
  arch/arm/plat-omap/remoteproc.c  |  316 
 ++
  10 files changed, 937 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c
  create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c
  create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
  create mode 100644 arch/arm/plat-omap/remoteproc.c

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

RE: Issue with file transfers to a mass storage device on SMP system

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
 Sent: Tuesday, July 27, 2010 5:31 PM
 To: Russell King - ARM Linux
 Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: RE: Issue with file transfers to a mass storage device on SMP
 system

  -Original Message-
  From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
  Sent: Tuesday, July 27, 2010 4:12 PM
  To: Shilimkar, Santosh
  Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
  o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
  Subject: Re: Issue with file transfers to a mass storage device on SMP
  system

  On Tue, Jul 27, 2010 at 03:49:29PM +0530, Shilimkar, Santosh wrote:
On Tue, Jul 27, 2010 at 03:08:54PM +0530, Shilimkar, Santosh wrote:
 As discussed, the main reason is the cache maintenance isn't done
 on
  bcb-CDB  buffers and hence the data remains in CPU write
 buffer
 instead of the physical memory on which DMA operates.

struct bulk_cb_wrap {
__le32  Signature;  /* contains 'USBC' */
__u32   Tag;/* unique per command id */
__le32  DataTransferLength; /* size of data */
__u8Flags;  /* direction in bit 0 */
__u8Lun;/* LUN normally 0 */
__u8Length; /* of of the CDB */
__u8CDB[16];/* max command */
};

So, CDB is contained within bcb...bcb+sizeof(*bcb).

The bcb is passed to usb_stor_bulk_transfer_buf:

result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
bcb, cbwlen, NULL);

which fills it into a URB:

usb_fill_bulk_urb(us-current_urb, us-pusb_dev, pipe, buf,
length,
  usb_stor_blocking_completion, NULL);

This sets the URB buffer pointers:

urb-transfer_buffer = transfer_buffer;
urb-transfer_buffer_length = buffer_length;

And this buffer should be dma-mapped and dma-unmapped as
 appropriate.

Wasn't there an issue with the DMA mapping being used with a PIO USB
host recently?  Is that the problem here?
   That's correct.
   The last issue was otherway round where we were doing map/unmpap on
 PIO
  buffer.

  That's exactly what I said.

   This issue is because CDB[16], is not cleaned up before merging it
  into CBW.

  The CDB array is part of the CBW (struct bulk_cb_wrap).  When the
  struct bulk_cb_wrap is mapped for DMA, the CDB will also be as it
  is contained entirely within the CBW structure.

  As USB deals with the whole of the CBW as one block, it can't be that
  half of it is being DMA-mapped and the other half isn't - something
  else must be going on.  If the CDB was a separate chunk of memory, I
  could believe what you're suggesting.

  What we _do_ know is that 2.6.35-rc5 misses Catalin's barrier patches
  for readl+writel, which means that there are ordering issues between
  writing to memory and writing to devices.  This is what is going on
  here, and it is confirmed by this:

  | (3)Using wmb() (Write memory barrier) before starting DMA transfer in
  MUSB
  | driver fixes the issue.

  from Maulik.  The fix is to have Catalin's ordered IO accessors which
  add the wmb() internally to writel() to ensure that memory accesses
  are visible.
 We have already those patches Russell and still see the issue. I think WMB
 is helping because data is just 16 bytes which can reside in WB. Had it
 been a bigger buffer this wouldn't have worked.

 Will get back to you with more data on this.

Maulik and I looked at the code and below is what seems to be an issue.
The mass storage USB layer is not respecting the DMA/CPU buffer ownership.

usb_stor_Bulk_transport gets us-iobuf which is already mapped for DMA.
But inside this function the buffers is updated by the CPU which should not
be done as per rule. Same buffer passed down for DMA to transfer where the 
data might remain in CPU cache/WB. The dma map is not done on this buffer 
because it's being done already before passing it to 'usb_stor_Bulk_transport'

Some USB expert can comment if this is indeed the case !!

Regards,
Santosh

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

Re: [PATCH 1/2] OMAP: DSS2: enable generic panel configuration modification

2010-07-27 Thread Igor Grinberg

On 07/27/10 11:00, Tomi Valkeinen wrote:
 On Mon, 2010-07-26 at 12:34 +0200, ext Igor Grinberg wrote:
   
 This patch enables platforms to modify the dss device configuration
 of the generic panel.

 Signed-off-by: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Mike Rapoport m...@compulab.co.il
 ---
  drivers/video/omap2/displays/panel-generic.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/video/omap2/displays/panel-generic.c 
 b/drivers/video/omap2/displays/panel-generic.c
 index 300eff5..ad80dd0 100644
 --- a/drivers/video/omap2/displays/panel-generic.c
 +++ b/drivers/video/omap2/displays/panel-generic.c
 @@ -66,7 +66,7 @@ static void generic_panel_power_off(struct omap_dss_device 
 *dssdev)
  
  static int generic_panel_probe(struct omap_dss_device *dssdev)
  {
 -dssdev-panel.config = OMAP_DSS_LCD_TFT;
 +dssdev-panel.config |= OMAP_DSS_LCD_TFT;
  dssdev-panel.timings = generic_panel_timings;
  
  return 0;
 

 I don't like this. Panel driver should be the one which decides the
 config.
   

I agree with this in most cases, but not always.
There are certain transmitters (like TI TFP410 dvi transmitter found
on cm-t35 and other boards) that can have some of their parameters
defined by hardware (strapped), so only the platform knows the correct
values for them.
One of such parameters is the edge of the clock sampling.

 I think a better solution is to make panel-generic configurable, which
 has been discussed a bit some time ago on l-o.
   

No doubt about that :)

 Briefly:

 - Add a struct for the configuration variables (a bit like
 arch/arm/plat-omap/include/plat/nokia-dsi-panel.h).

 - Fill the struct in the board file, and pass it to the panel driver via
 omap_dss_device-data pointer.

 - The panel driver get the struct and uses it to do whatever
 configuration it needs.
   

This is more or less what I've been thinking of, but with slight addition:
the panel driver should have a defaults for all the parameters,
so there will be no need to provide the whole parameters list,
just the ones that are different.

 I think there are two ways to implement this:

 1) Have lots of fields in the struct, including video timings and video
 signaling information, and the driver uses these directly.
   

This seems like a good choice for better flexibility and
provides an easy way of dealing with the issues, I've described above.

 2) Have a panel name in the struct, and the panel driver contains a
 static list of panels, including configurations for those panels, and
 the driver selects the configuration based on the panel name given from
 the board file. (like drivers/video/omap2/displays/panel-taal.c does,
 except there's currently only one panel defined).
   

This approach does not deal with the dvi transmitters issue above,
unless there will be possibility to define some kind of platform data.
Also, if we have a static list of panels with their configurations,
there could be panels with (almost) the same parameters defined
for a couple of times.

 While 1. gives perhaps slightly easier configuration, as you just edit
 the board file, I'd go for 2. because the required configuration is
 really defined by the panel/chip being used, and so the board file
 should just state which panel/chip we have, and the driver handles the
 rest.

Well, unfortunately, it is not :(

  And 2. makes it also easier to use the same panel/chip on multiple
 boards.

 Implementing this would allow us to remove some panel drivers which
 currently are 99% copies of each other.

  Tomi

   

My idea is:
generic driver will have built-in defaults, that can
(but not necessarily will) be overridden by platform (or other) code
on a parameter basis.
This will allow other panels (like tdo35s) reuse the generic driver
without the need for their special driver.

What do you think of it?

-- 
Regards,
Igor.

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

Re: Issue with file transfers to a mass storage device on SMP system

On Tue, Jul 27, 2010 at 07:15:25PM +0530, Shilimkar, Santosh wrote:
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
  Sent: Tuesday, July 27, 2010 5:31 PM
  To: Russell King - ARM Linux
  Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
  o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
  Subject: RE: Issue with file transfers to a mass storage device on SMP
  system

  We have already those patches Russell and still see the issue. I think WMB
  is helping because data is just 16 bytes which can reside in WB. Had it
  been a bigger buffer this wouldn't have worked.

  Will get back to you with more data on this.

 Maulik and I looked at the code and below is what seems to be an issue.
 The mass storage USB layer is not respecting the DMA/CPU buffer ownership.

 usb_stor_Bulk_transport gets us-iobuf which is already mapped for DMA.
 But inside this function the buffers is updated by the CPU which should not
 be done as per rule. Same buffer passed down for DMA to transfer where the 
 data might remain in CPU cache/WB. The dma map is not done on this buffer
 because it's being done already before passing it to 'usb_stor_Bulk_transport'

Hang on.

us-iobuf is a DMA coherent buffer, allocated by usb_alloc_coherent(),
in turn hcd_buffer_alloc().  This comes from either a DMA pool, or
dma_alloc_coherent().  These buffers are simultaneously owned by both
the CPU and the DMA agent.

So to talk about the buffer already being mapped and buffer ownership
is wrong.  It's supposed to be a DMA coherent buffer, and trying to use
dma_map_*() on it definitely won't work.

This memory will be mapped in as 'normal memory, uncached', and with
Catalins IO ordering patches, we rely upon wmb() ensuring that data
written to it becomes visible to the DMA agents.  (wmb() by default
aliases to mb(), which is a dsb() followed by outer_sync().)

I think OMAP overrides the definitions of the mandatory barriers -
the question is whether the OMAP implementation is sufficient to ensure
that data written to a 'normal memory, uncached' mapping makes it out
RAM so that the DMA agents can see it.

As the OMAP mandatory barrier implementation isn't in mainline, I can't
comment on that.  However, I feel certain that this is where the problem
is.
--
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: Issue with file transfers to a mass storage device on SMP system

 -Original Message-
 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
 Sent: Tuesday, July 27, 2010 7:30 PM
 To: Shilimkar, Santosh
 Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: Re: Issue with file transfers to a mass storage device on SMP
 system

 On Tue, Jul 27, 2010 at 07:15:25PM +0530, Shilimkar, Santosh wrote:
   -Original Message-
   From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
   ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh
   Sent: Tuesday, July 27, 2010 5:31 PM
   To: Russell King - ARM Linux
   Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
   o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
   Subject: RE: Issue with file transfers to a mass storage device on SMP
   system

   We have already those patches Russell and still see the issue. I think
 WMB
   is helping because data is just 16 bytes which can reside in WB. Had
 it
   been a bigger buffer this wouldn't have worked.

   Will get back to you with more data on this.

  Maulik and I looked at the code and below is what seems to be an issue.
  The mass storage USB layer is not respecting the DMA/CPU buffer
 ownership.

  usb_stor_Bulk_transport gets us-iobuf which is already mapped for
 DMA.
  But inside this function the buffers is updated by the CPU which should
 not
  be done as per rule. Same buffer passed down for DMA to transfer where
 the
  data might remain in CPU cache/WB. The dma map is not done on this
 buffer
  because it's being done already before passing it to
 'usb_stor_Bulk_transport'

 Hang on.

 us-iobuf is a DMA coherent buffer, allocated by usb_alloc_coherent(),
 in turn hcd_buffer_alloc().  This comes from either a DMA pool, or
 dma_alloc_coherent().  These buffers are simultaneously owned by both
 the CPU and the DMA agent.

Good point. We thought it's a kmalloc. Now it makes complete sense about the 
barrier effectiveness

 So to talk about the buffer already being mapped and buffer ownership
 is wrong.  It's supposed to be a DMA coherent buffer, and trying to use
 dma_map_*() on it definitely won't work.

Fully agree 
 This memory will be mapped in as 'normal memory, uncached', and with
 Catalins IO ordering patches, we rely upon wmb() ensuring that data
 written to it becomes visible to the DMA agents.  (wmb() by default
 aliases to mb(), which is a dsb() followed by outer_sync().)

 I think OMAP overrides the definitions of the mandatory barriers -
 the question is whether the OMAP implementation is sufficient to ensure
 that data written to a 'normal memory, uncached' mapping makes it out
 RAM so that the DMA agents can see it.

OMAP doesn't override because the default definition is good enough now.
Shouldn't below work ?
#elif __LINUX_ARM_ARCH__ = 7 || defined(CONFIG_SMP)
#define mb()do { dsb(); outer_sync(); } while (0)
#define rmb()   dmb()
#define wmb()   mb()

 As the OMAP mandatory barrier implementation isn't in mainline, I can't
 comment on that.  However, I feel certain that this is where the problem
 is.

Do you think with above setting it should be still a problem ? I mean
with  CONFIG_ARCH_HAS_BARRIERS not enabled

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: Issue with file transfers to a mass storage device on SMP system

On Tue, Jul 27, 2010 at 07:44:20PM +0530, Shilimkar, Santosh wrote:
 OMAP doesn't override because the default definition is good enough now.

Ah, good to know.

 Shouldn't below work ?
 #elif __LINUX_ARM_ARCH__ = 7 || defined(CONFIG_SMP)
 #define mb()do { dsb(); outer_sync(); } while (0)
 #define rmb()   dmb()
 #define wmb()   mb()

Yes, that should get it out of the CPU and caches, and onto the bus.
However, I need to check up exactly what a write to the L2x0 SYNC
register gives us...

  As the OMAP mandatory barrier implementation isn't in mainline, I can't
  comment on that.  However, I feel certain that this is where the problem
  is.
 
 Do you think with above setting it should be still a problem ? I mean
 with  CONFIG_ARCH_HAS_BARRIERS not enabled

Well, the question is whether getting it out of the outer cache (and
performing an effective memory barrier to the outer cache) is sufficient
for the DMA agent to see the data.

Could the data be sitting somewhere in the interconnect between the
CPU pushing it out of the outer cache and the DMA agent trying to read
from memory?
--
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 4/6] omap: introduce common remoteproc module

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 4/6] omap: introduce common remoteproc module

 From: Ohad Ben-Cohen oh...@ti.com

 The OMAP remote processor module decouples
 machine-specific code from TI's IPC
 drivers (e.g. dspbridge and syslink).

 While dspbridge calls the remoteproc handlers
 from the kernel, syslink calls them from
 user space. Hence remoteproc supports both
 interfaces.

 Signed-off-by: Ohad Ben-Cohen oh...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/plat-omap/include/plat/remoteproc.h |   75 ++
  arch/arm/plat-omap/remoteproc.c  |  316
 ++
  2 files changed, 391 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
  create mode 100644 arch/arm/plat-omap/remoteproc.c

 diff --git a/arch/arm/plat-omap/include/plat/remoteproc.h
 b/arch/arm/plat-omap/include/plat/remoteproc.h
 new file mode 100644
 index 000..1cedd08
 --- /dev/null
 +++ b/arch/arm/plat-omap/include/plat/remoteproc.h
 @@ -0,0 +1,75 @@
 +/*
 + * OMAP Remote Processor driver
 + *
 + * Copyright (C) 2010 Texas Instruments Inc.
 + *
 + * Written by Ohad Ben-Cohen o...@wizery.com
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be
 useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +#ifndef REMOTEPROC_H
 +#define REMOTEPROC_H
 +
 +#include linux/ioctl.h
 +#include linux/cdev.h
 +
 +#define RPROC_IOC_MAGIC  'P'

[sp] I notice that there is already a conflict with this magic number in
 Documentation/ioctl/ioctl-number.txt.

 Suggest reserving a different code as per the steps mentioned in the
 same file.

 +
 +#define RPROC_IOCSTART   _IOW(RPROC_IOC_MAGIC, 1, int)
 +#define RPROC_IOCSTOP_IO(RPROC_IOC_MAGIC, 2)
 +#define RPROC_IOCGETSTATE_IOR(RPROC_IOC_MAGIC, 3, int)
 +
 +#define RPROC_IOC_MAXNR  (3)
 +
 +struct omap_rproc;
 +
 +struct omap_rproc_ops {
 + int (*start)(struct device *dev, u32 start_addr);
 + int (*stop)(struct device *dev);
 + int (*get_state)(struct device *dev);
 +};
 +
 +struct omap_rproc_clk_t {
 + void *clk_handle;
 + const char *dev_id;
 + const char *con_id;
 +};
 +

[sp] Small description of the fields in the structure will help understand the 
code better.
 I couldn't locate usage of con_id in this patch; not sure what it 
signifies.
 ...hope it becomes clear in one of the other patches in the series.
 (after one review) The structure is not used anywhere in this file.

 +struct omap_rproc_platform_data {
 + struct omap_rproc_ops *ops;
 + char *name;
 + char *oh_name;
 +};

[sp] same comment here.

 +
 +struct omap_rproc {
 + struct device *dev;
 + struct cdev cdev;
 + atomic_t count;

[sp] I believe this field is for use-counts. If so, suggest renaming to
 usecount.

 + int minor;
 +};
 +
 +struct omap_rproc_start_args {
 + u32 start_addr;
 +};
 +
 +struct omap_rproc_platform_data *omap3_get_rproc_data(void);
 +int omap3_get_rproc_data_size(void);
 +struct omap_rproc_platform_data *omap4_get_rproc_data(void);
 +int omap4_get_rproc_data_size(void);
[sp] The forward declaration seems to be used for plugging
 device specific data (haven't looked at complet code, so
 it is currently a speculation).

 The contents of this header have so far been device independent.
 Can we look to reorganiza this code such that this header remains
 generic?

 +int omap_get_num_of_remoteproc(void);

[sp] Don't see this being implemented in the C file below.
 If this function is expected to be implemented in the omap3/4
 specific file, then I suspect multi-omap will break for compilation.
 Same function will be defined multiple times.

 +
 +#endif /* REMOTEPROC_H */
 diff --git a/arch/arm/plat-omap/remoteproc.c
 b/arch/arm/plat-omap/remoteproc.c
 new file mode 100644
 index 000..7a9862e
 --- /dev/null
 +++ b/arch/arm/plat-omap/remoteproc.c
 @@ -0,0 +1,316 @@
 +/*
 + * OMAP Remote Processor driver
 + *
 + * Copyright (C) 2010 Texas Instruments Inc.
 + *
 + * Authors:
 + * Ohad Ben-Cohen o...@wizery.com
 + * Hari Kanigeri h-kanige...@ti.com
 + *
 + *

RE: [RFC 2/6] omap: introduce OMAP3 remoteproc module

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 2/6] omap: introduce OMAP3 remoteproc module
 
 From: Ohad Ben-Cohen oh...@ti.com
 
 Introduce OMAP3 remoteproc module which takes care of
 machine-specific code required to start and stop
 the DSP remote processor.
 
 Signed-off-by: Ohad Ben-Cohen oh...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/remoteproc3xxx.c |  226 
 ++
  1 files changed, 226 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c
 
 diff --git a/arch/arm/mach-omap2/remoteproc3xxx.c 
 b/arch/arm/mach-omap2/remoteproc3xxx.c
 new file mode 100644
 index 000..f86a333
 --- /dev/null
 +++ b/arch/arm/mach-omap2/remoteproc3xxx.c
 @@ -0,0 +1,226 @@
 +/*
 + * Remote Processor machine-specific module for OMAP3
 + *
 + * Copyright (C) 2010 Texas Instruments Inc.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be 
 useful, but
 + * WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +/* this is needed for multi-omap support */
 +#ifdef CONFIG_ARCH_OMAP3

[sp] If ARCH_OMAP3 is not defined this file shouldn't be compiled.
 I do see that we are achieving the multi-omap support - a
 concern I had in my comment on another patch in the series -
 but this appears to be a hack.

 +#include linux/kernel.h
 +#include linux/delay.h
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/platform_device.h
 +#include linux/io.h
 +#include linux/pm_runtime.h
 +#include plat/remoteproc.h
 +#include mach/irqs.h
 +#include plat/omap_device.h
 +#include plat/control.h
 +#include plat/common.h
 +#include plat/powerdomain.h
 +#include plat/clockdomain.h
 +#include asm/uaccess.h
 +
 +#include cm-regbits-34xx.h
 +#include prm-regbits-34xx.h
 +
 +#define OMAP3_IVA2_BOOTADDR_MASK 0xFC00
 +
 +#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_MASK   (u32)(3)
 +#define PRCM_PM_PWSTCTRL_IVA2_POWER_STATE_OFFSET (u32)(0)

[sp] We should either use the definitions in prm-regbits-34xx.h/prm.h
 or make sure appropriate headers are updated with these definitions.

 The naming conventions here seem to be very differen from the ones
 used in prm-regbits-34xx.h and prm.h

 +
 +#define PRCM_PM_PWSTST_IVA2_InTransition_MASK
 (u32)(0x10)
 +#define PRCM_PM_PWSTST_IVA2_InTransition_OFFSET  
 (u32)(20)

[sp] Is InTransition delibrately put in CamelCase?

 +
 +#define CM_CLKSTCTRL_IVA2_OFFSET (0)
 +#define CM_CLKSTCTRL_IVA2_MASK   (3)

[sp] Same somment as before. See corresponding definition(s) in
 cm-regbits-34xx.h for existing definitions, instead of
 defining new ones.

 +
 +#define DSP_SYSC_DIRECTBOOT  (0)
 +#define DSP_SYSC_IDLEBOOT(1)
 +#define DSP_SYSC_SELFLOOPBOOT(2)
 +#define DSP_SYSC_USRBOOTSTRAP(3)
 +#define DSP_SYSC_DEFAULTRESTORE  (4)
 +
 +#ifdef CONFIG_BRIDGE_DEBUG
 +static void omap3_rproc_dump_regs(struct device *dev)
 +{
 + u32 temp;
 +
 + temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_FCLKEN);
 + dev_info(dev, CM_FCLKEN_IVA2 = 0x%x \n, temp);

[sp] Shouldn't we be using dev_dbg() here?
 Also, same information is available in debugfs in base linux.
 Is this function really needed here?

 + temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_ICLKEN1);
 + dev_info(dev, CM_ICLKEN1_IVA2 = 0x%x \n, temp);
 + temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_IDLEST);
 + dev_info(dev, CM_IDLEST_IVA2 = 0x%x \n, temp);
 + temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
 + dev_info(dev, CM_CLKSTCTRL_IVA2 = 0x%x \n, temp);
 + temp = cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST);
 + dev_info(dev, CM_CLKSTST_IVA2 = 0x%x \n, temp);
 + temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTCTRL);
 + dev_info(dev, RM_RSTCTRL_IVA2 = 0x%x \n, temp);
 + temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, RM_RSTST);
 + dev_info(dev, RM_RSTST_IVA2 = 0x%x \n, temp);
 + temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTCTRL);
 + dev_info(dev, PM_PWSTCTRL_IVA2 = 0x%x \n, temp);
 + temp = prm_read_mod_reg(OMAP3430_IVA2_MOD, PM_PWSTST);

RE: [RFC 5/6] omap: add remoteproc device(s)

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 5/6] omap: add remoteproc device(s)
 
 From: Ohad Ben-Cohen oh...@ti.com
 
 Add an omap_device for each remote processor on the system
 
 Signed-off-by: Ohad Ben-Cohen oh...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/devices.c |   86 
 +
  1 files changed, 86 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/devices.c 
 b/arch/arm/mach-omap2/devices.c
 index 18ad931..d365db6 100644
 --- a/arch/arm/mach-omap2/devices.c
 +++ b/arch/arm/mach-omap2/devices.c
 @@ -15,6 +15,7 @@
  #include linux/platform_device.h
  #include linux/io.h
  #include linux/clk.h
 +#include linux/err.h
  
  #include mach/hardware.h
  #include asm/mach-types.h
 @@ -26,9 +27,13 @@
  #include plat/mux.h
  #include mach/gpio.h
  #include plat/mmc.h
 +#include plat/remoteproc.h
  
  #include mux.h
  
 +#include plat/omap_device.h
 +#include plat/omap_hwmod.h
 +
  #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
  
  static struct resource cam_resources[] = {
 @@ -136,6 +141,86 @@ static inline void omap_init_camera(void)
  }
  #endif
  
 +#if defined(CONFIG_OMAP_REMOTE_PROC) || 
 defined(CONFIG_OMAP_REMOTE_PROC_MODULE)
 +static struct omap_device_pm_latency omap_rproc_latency[] = {
 + {
 + .deactivate_func = omap_device_idle_hwmods,
 + .activate_func = omap_device_enable_hwmods,
 + .deactivate_lat = 1,
 + .activate_lat = 1,
 + },
 +};
 +
 +static struct omap_rproc_platform_data 
 *omap_get_remoteproc_data(void)
 +{
 + struct omap_rproc_platform_data *rproc_data = NULL;
 +
 + if (cpu_is_omap3430() || cpu_is_omap3630())
 + rproc_data = omap3_get_rproc_data();
 + else if (cpu_is_omap44xx())
 + rproc_data = omap4_get_rproc_data();
 + else
 + pr_err(%s: platform not supported\n, __func__);
 +
 + return rproc_data;
 +}
 +
 +int omap_get_num_of_remoteproc(void)
 +{
 + int num = -1;
 +
 + if (cpu_is_omap3430() || cpu_is_omap3630())
 + num = omap3_get_rproc_data_size();
 + else if (cpu_is_omap44xx())
 + num = omap4_get_rproc_data_size();
 + else
 + pr_err(%s: platform not supported\n, __func__);
 +
 + return num;
 +}

[sp] I realise that I commented on this function in earlier patch
 without reading this one. While my comment on breaking the
 multi_omap support due to this function my not be true, but,
 I didn't expect function declared in include/plat/remoteproc.h
 to be implemented in mach-omap2/devices.c.

 I was, possibly, deceived by presence of plat-omap/remoteproc.c
 and device specific implementations in the patch series.

 Is there any specific reason why remoteproc is being implemented
 quite different that other devices in the same file. See, for
 example, omap_init_mbox(), omap3_mbox_resources and 
omap3_mbox_resources_sz.

 Following the same scheme, this function is not required.

 +EXPORT_SYMBOL(omap_get_num_of_remoteproc);
 +
 +static inline void omap_init_rproc(void)
 +{
 + struct omap_hwmod *oh;
 + struct omap_device *od;
 + struct omap_device_pm_latency *ohl;
 + char *oh_name, *pdev_name;
 + int ohl_cnt = 0, i;
 + int rproc_data_size;
 + struct omap_rproc_platform_data *rproc_data;
 +
 + pdev_name = omap-rproc;
 + ohl = omap_rproc_latency;
 + ohl_cnt = ARRAY_SIZE(omap_rproc_latency);
 +
 + rproc_data = omap_get_remoteproc_data();
 + rproc_data_size = omap_get_num_of_remoteproc();
 + if (rproc_data == NULL || rproc_data_size = 0) {
 + pr_err(%s: platform not supported\n, __func__);
 + return;
 + }
 +
 + for (i = 0; i  rproc_data_size; i++) {
 + oh_name = rproc_data[i].oh_name;
 + oh = omap_hwmod_lookup(oh_name);
 + if (!oh) {
 + pr_err(%s: could not look up %s\n, 
 __func__, oh_name);
 + continue;
 + }
 +
 + od = omap_device_build(pdev_name, i, oh,
 + rproc_data[i],
 + sizeof(struct 
 omap_rproc_platform_data),
 + ohl, ohl_cnt);
 + WARN(IS_ERR(od), Could not build omap_device 
 for %s %s\n,
 + pdev_name, oh_name);
 + }
 +}
 +#else
 +static inline void omap_init_rproc(void) { }
 +#endif /* CONFIG_OMAP_REMOTE_PROC */
 +
  #if defined(CONFIG_OMAP_MBOX_FWK) || 
 defined(CONFIG_OMAP_MBOX_FWK_MODULE)
  
  #define MBOX_REG_SIZE   0x120
 @@ -773,6 +858,7 @@ static int __init omap2_init_devices(void)
   omap_hsmmc_reset();

RE: [RFC 6/6] omap: enable remoteproc building

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 6/6] omap: enable remoteproc building
 
 From: Ohad Ben-Cohen oh...@ti.com
 
 Make it possible to build omap's remoteproc module
 
 Signed-off-by: Ohad Ben-Cohen oh...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/Makefile |6 ++
  arch/arm/plat-omap/Kconfig   |7 +++
  arch/arm/plat-omap/Makefile  |1 +
  3 files changed, 14 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/Makefile 
 b/arch/arm/mach-omap2/Makefile
 index 307f8b0..edb65b3 100644
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -59,6 +59,12 @@ obj-$(CONFIG_OMAP3_EMU)+= emu.o
  obj-$(CONFIG_OMAP_MBOX_FWK)  += mailbox_mach.o
  mailbox_mach-objs:= mailbox.o
  
 +ifneq ($(CONFIG_OMAP_REMOTE_PROC),)
 +obj-$(CONFIG_ARCH_OMAP2) += remoteproc24xx.o
 +obj-$(CONFIG_ARCH_OMAP3) += remoteproc3xxx.o

[sp] Since the compilation of this file depends upon CONFIG_ARCH_OMAP3,
 the big ifdef CONFIG_ARCH_OMAP3 in the file remoteproc3xxx.c
 is not useful at all.

 +obj-$(CONFIG_ARCH_OMAP4) += remoteproc44xx.o
 +endif
 +
  iommu-y  += iommu2.o
  iommu-$(CONFIG_ARCH_OMAP3)   += omap3-iommu.o
  
 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
 index e2ea04a..e7d7372 100644
 --- a/arch/arm/plat-omap/Kconfig
 +++ b/arch/arm/plat-omap/Kconfig
 @@ -96,6 +96,13 @@ config OMAP_MBOX_FWK
 Say Y here if you want to use OMAP Mailbox framework 
 support for
 DSP, IVA1.0 and IVA2 in OMAP1/2/3.
  
 +config OMAP_REMOTE_PROC
 + bool Remote Processor framework support
 + depends on ARCH_OMAP
 + help
 +   Say Y here if you want to use OMAP Remote Processor framework
 +   support for DSP, Tesla and/or Ducati (OMAP3/4).
 +
  config OMAP_IOMMU
   tristate
  
 diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
 index 98f0191..bacb5c3 100644
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -29,5 +29,6 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
  
  # OMAP mailbox framework
  obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
 +obj-$(CONFIG_OMAP_REMOTE_PROC) += remoteproc.o
  
  obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
 \ No newline at end of file

[sp] You need to fix this as well.

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

RE: [PATCH 1/5] omap:hwmod-hwspinlock-enable

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
 Sent: Monday, July 19, 2010 10:20 PM
 To: Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
 Subject: [PATCH 1/5] omap:hwmod-hwspinlock-enable
 
 From: Simon Que s...@ti.com
 
 uncomment the hwmod part for hwspinlock
 
 Signed-off-by: Simon Que s...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

[sp] Does this patch depend upon any other patch waiting in the queue?
 I don't see omap_hwmod_44xx_data.c on the master branch.

~sanjeev

 
 diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 index 03bb3db..41dc77d 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
 @@ -4966,7 +4966,7 @@ static __initdata struct omap_hwmod 
 *omap44xx_hwmods[] = {
  /*   omap44xx_smartreflex_iva_hwmod, */
  /*   omap44xx_smartreflex_mpu_hwmod, */
   /* spinlock class */
 -/*   omap44xx_spinlock_hwmod, */
 + omap44xx_spinlock_hwmod,
   /* timer class */
   omap44xx_timer1_hwmod,
   omap44xx_timer2_hwmod,
 -- 
 1.7.0
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK base address

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
 Sent: Monday, July 19, 2010 10:20 PM
 To: Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
 Subject: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK base address
 
 From: Simon Que s...@ti.com
 
 Add HWSPINLCOK base address information in omap44xx.h
 
 Signed-off-by: Simon Que s...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/plat-omap/include/plat/omap44xx.h |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/plat-omap/include/plat/omap44xx.h 
 b/arch/arm/plat-omap/include/plat/omap44xx.h
 index 76832d3..8016508 100644
 --- a/arch/arm/plat-omap/include/plat/omap44xx.h
 +++ b/arch/arm/plat-omap/include/plat/omap44xx.h
 @@ -49,5 +49,10 @@
  #define OMAP44XX_MAILBOX_BASE(L4_44XX_BASE + 0xF4000)
  #define OMAP44XX_HSUSB_OTG_BASE  (L4_44XX_BASE + 0xAB000)
  
 +#define OMAP4_MMU1_BASE  0x55082000
 +#define OMAP4_MMU2_BASE  0x4A066000

[sp] Are these 2 base addresses related to this patch?

~sanjeev

 +
 +#define OMAP44XX_SPINLOCK_BASE   (L4_44XX_BASE + 0xF6000)
 +
  #endif /* __ASM_ARCH_OMAP44XX_H */
  
 -- 
 1.7.0
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Input: OMAP: RX51: fix 'KEY_10' compile breakage

2010-07-27 Thread Dmitry Torokhov

Hi Paul,

On Mon, Jul 26, 2010 at 04:28:12PM -0600, Paul Walmsley wrote:
 
 Commit 3fea60261e73dbf4a51130d40cafcc8465b0f2c3 replaces KEY_F10 and 
 KEY_F11 macro references with 'KEY_10' and 'KEY_11'.  This breaks 
 v2.6.35-rc6 compiles with omap3_defconfig:
 
   CC  arch/arm/mach-omap2/board-rx51-peripherals.o
 arch/arm/mach-omap2/board-rx51-peripherals.c:223: error: 'KEY_10' undeclared 
 here (not in a function)
 arch/arm/mach-omap2/board-rx51-peripherals.c:226: error: 'KEY_11' undeclared 
 here (not in a function)
 
 Fix by renaming the macro references back to KEY_F10 and KEY_F11.
 
 Compile-tested only.
 

Thank you for the patch however Linus managed to fish off LKML and apply
another version that I posted earlier.

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

RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK base address

2010-07-27 Thread Kanigeri, Hari

Sanjeev,

  @@ -49,5 +49,10 @@
   #define OMAP44XX_MAILBOX_BASE  (L4_44XX_BASE + 0xF4000)
   #define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000)
 
  +#define OMAP4_MMU1_BASE0x55082000
  +#define OMAP4_MMU2_BASE0x4A066000
 
 [sp] Are these 2 base addresses related to this patch?

Nope. Thanks for finding this. I will update the patch.

 
 ~sanjeev
 
  +
  +#define OMAP44XX_SPINLOCK_BASE (L4_44XX_BASE + 0xF6000)
  +
   #endif /* __ASM_ARCH_OMAP44XX_H */
 
  --
  1.7.0
 
 

Best regards,
Hari
--
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 0/6] Introducing OMAP Remote Processor module

2010-07-27 Thread Ohad Ben-Cohen

Hi Sanjeev,

Thanks for your comments.

As we plan to move remoteproc to hwmod, the code will be substantially changed.

We will keep your comments in mind, and also keep in mind other TI
platforms (like davinci).

Thanks,
Ohad.

On Tue, Jul 27, 2010 at 3:27 PM, Premi, Sanjeev pr...@ti.com wrote:
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
 Sent: Friday, July 02, 2010 3:53 AM
 To: linux-omap@vger.kernel.org
 Cc: Kanigeri, Hari; Ben-cohen, Ohad
 Subject: [RFC 0/6] Introducing OMAP Remote Processor module

 From: Ohad Ben-Cohen oh...@ti.com

 This is a preliminary version of OMAP's remoteproc module,
 submitted for RFC purposes.

 The purpose of the remoteproc module is to decouple
 hw-specific code from generic IPC drivers (such as
 dspbridge and syslink), in order to eventually make
 those IPC drivers platform-independent.

 Currently the supported operations are starting and stopping
 the remote processor, but in the future additional functionality
 might be added.

 Both OMAP3 and OMAP4 are supported; OMAP3 supports the dsp
 remote processor, and OMAP4 supports ducati (tesla support
 is planned as well).

 The code was tested on both OMAP3 (using dspbridge) and OMAP4
 (using syslink).

 The code is preliminary: we plan to add much more extensive
 hwmod support, ideally squashing as much hw-specific code
 as possible (including RST and PRCM manipulations).
 In addition, a rebase to recent code bases is needed.

 While dspbridge accesses remoteproc's interface via pdata
 pointers, syslink accesses it from user space, via character
 device interface, so both kernel and user space interfaces
 are supported.

 A few words on the char device interface:

 * Each remote processor is represented by a different
   character device: /dev/omap-rproc0, /dev/omap-rproc1, ...

 [sp] Concept of remote processor is not really tied to omap.
     Though the implementation is being done in context of
     OMAP, I would suggest removing the prefix omap- from
     the device name.

 * A rproc character device can only be opened by a single user
   (e.g. the syslink daemon)
 * The start/stop/get_state functionality is exposed via ioctl's
 * We plan to add automatic stop() invokation in case the user
   closes the device after starting a remote processor (for
   resource cleanup purposes. Thus the user will be required
   to hold the device open as long as it lives).

 Thanks,

 Hari Kanigeri (1):
   omap: introduce OMAP4 remoteproc module

 Ohad Ben-Cohen (5):
   omap: add iva2 hwmod support to omap3
   omap: introduce OMAP3 remoteproc module
   omap: introduce common remoteproc module
   omap: add remoteproc device(s)
   omap: enable remoteproc building

  arch/arm/mach-omap2/Makefile                 |    6 +
  arch/arm/mach-omap2/devices.c                |   86 +++
  arch/arm/mach-omap2/omap_hwmod_34xx.h        |   23 ++
  arch/arm/mach-omap2/remoteproc3xxx.c         |  226
 ++
  arch/arm/mach-omap2/remoteproc44xx.c         |  196 
  arch/arm/plat-omap/Kconfig                   |    7 +
  arch/arm/plat-omap/Makefile                  |    1 +
  arch/arm/plat-omap/include/plat/omap_hwmod.h |    1 +
  arch/arm/plat-omap/include/plat/remoteproc.h |   75 ++
  arch/arm/plat-omap/remoteproc.c              |  316
 ++
  10 files changed, 937 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/remoteproc3xxx.c
  create mode 100644 arch/arm/mach-omap2/remoteproc44xx.c
  create mode 100644 arch/arm/plat-omap/include/plat/remoteproc.h
  create mode 100644 arch/arm/plat-omap/remoteproc.c

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

--
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 1/8] TILER-DMM: DMM-PAT driver for TI TILER

 -Original Message-
 From: Sin, David
 Sent: Saturday, July 24, 2010 4:52 AM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
 Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
 Sin, David; Molnar, Lajos
 Subject: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER
 
 This patch adds support for DMM-PAT initialization and programming.
 
[Hiremath, Vaibhav] Sorry for delayed response, always better late than never.


 Signed-off-by: David Sin david...@ti.com
 Signed-off-by: Lajos Molnar mol...@ti.com
 ---
  arch/arm/mach-omap2/include/mach/dmm.h |  128 
  drivers/media/video/tiler/dmm.c|  200
 
  2 files changed, 328 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/include/mach/dmm.h
  create mode 100644 drivers/media/video/tiler/dmm.c
 
[Hiremath, Vaibhav] If I understand correctly, DMM stands for dynamic memory 
manager. Is it something which can only be used with Video devices? Any 
specific reason why this is part of drivers/media/video/ directory,


 diff --git a/arch/arm/mach-omap2/include/mach/dmm.h b/arch/arm/mach-
 omap2/include/mach/dmm.h
 new file mode 100644
 index 000..68b798a
 --- /dev/null
 +++ b/arch/arm/mach-omap2/include/mach/dmm.h
 @@ -0,0 +1,128 @@
 +/*
 + * dmm.h
 + *
 + * DMM driver support functions for TI DMM-TILER hardware block.
 + *
 + * Author: David Sin david...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + */
 +
 +#ifndef DMM_H
 +#define DMM_H
 +
 +#define DMM_BASE 0x4E00
 +#define DMM_SIZE 0x800
[Hiremath, Vaibhav] Unused definition (DMM_SIZE), do we required it?

 +
 +#define DMM_REVISION  0x000
 +#define DMM_HWINFO0x004
 +#define DMM_LISA_HWINFO   0x008
 +#define DMM_DMM_SYSCONFIG 0x010
 +#define DMM_LISA_LOCK 0x01C
 +#define DMM_LISA_MAP__0   0x040
 +#define DMM_LISA_MAP__1   0x044
 +#define DMM_TILER_HWINFO  0x208
 +#define DMM_TILER_OR__0   0x220
 +#define DMM_TILER_OR__1   0x224
 +#define DMM_PAT_HWINFO0x408
 +#define DMM_PAT_GEOMETRY  0x40C
 +#define DMM_PAT_CONFIG0x410
 +#define DMM_PAT_VIEW__0   0x420
 +#define DMM_PAT_VIEW__1   0x424
 +#define DMM_PAT_VIEW_MAP__0   0x440
 +#define DMM_PAT_VIEW_MAP_BASE 0x460
 +#define DMM_PAT_IRQ_EOI   0x478
 +#define DMM_PAT_IRQSTATUS_RAW 0x480
 +#define DMM_PAT_IRQSTATUS 0x490
 +#define DMM_PAT_IRQENABLE_SET 0x4A0
 +#define DMM_PAT_IRQENABLE_CLR 0x4B0
 +#define DMM_PAT_STATUS__0 0x4C0
 +#define DMM_PAT_STATUS__1 0x4C4
 +#define DMM_PAT_STATUS__2 0x4C8
 +#define DMM_PAT_STATUS__3 0x4CC
 +#define DMM_PAT_DESCR__0  0x500
 +#define DMM_PAT_AREA__0   0x504
 +#define DMM_PAT_CTRL__0   0x508
 +#define DMM_PAT_DATA__0   0x50C
[Hiremath, Vaibhav] Not sure whether somebody has given same comment or not, 
any specific reason behind double _ here?

 +#define DMM_PEG_HWINFO0x608
 +#define DMM_PEG_PRIO  0x620
 +#define DMM_PEG_PRIO_PAT  0x640
 +
 +/**
 + * PAT refill programming mode.
 + */
 +enum pat_mode {
 + MANUAL,
 + AUTO
 +};
 +
 +/**
 + * Area definition for DMM physical address translator.
 + */
 +struct pat_area {
 + s32 x0:8;
 + s32 y0:8;
 + s32 x1:8;
 + s32 y1:8;
 +};
 +
 +/**
 + * DMM physical address translator control.
 + */
 +struct pat_ctrl {
 + s32 start:4;
 + s32 dir:4;
 + s32 lut_id:8;
 + s32 sync:12;
 + s32 ini:4;
 +};
 +
 +/**
 + * PAT descriptor.
 + */
 +struct pat {
 + struct pat *next;
 + struct pat_area area;
 + struct pat_ctrl ctrl;
 + u32 data;
 +};
 +
 +/**
 + * DMM device data
 + */
 +struct dmm {
 + void __iomem *base;
 +};
 +
 +/**
 + * Create and initialize the physical address translator.
 + * @param idPAT id
 + * @return pointer to device data
 + */
 +struct dmm *dmm_pat_init(u32 id);
 +
 +/**
 + * Program the physical address translator.
 + * @param dmm   Device data
 + * @param desc  PAT descriptor
 + * @param mode  programming mode
 + * @return an error status.
 + */
 +s32 dmm_pat_refill(struct dmm *dmm, struct pat *desc, enum pat_mode mode);
 +
 +/**
 + * Clean up the physical address translator.
 + * @param dmmDevice data
 + * @return an error status.
 + */
 +void dmm_pat_release(struct dmm *dmm);
 +
 +#endif
 diff --git a/drivers/media/video/tiler/dmm.c
 b/drivers/media/video/tiler/dmm.c
 new file mode 100644
 index 000..e715936
 --- /dev/null
 +++ b/drivers/media/video/tiler/dmm.c
 @@ -0,0

RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

 -Original Message-
 From: Sin, David
 Sent: Wednesday, July 28, 2010 12:35 AM
 To: Hiremath, Vaibhav; linux-arm-ker...@lists.infradead.org; linux-
 o...@vger.kernel.org; Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Shilimkar, Santosh; Molnar, Lajos
 Subject: RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

  -Original Message-
  From: Hiremath, Vaibhav
  Sent: Tuesday, July 27, 2010 1:38 PM
  To: Sin, David; linux-arm-ker...@lists.arm.linux.org.uk;
  linux-omap@vger.kernel.org; Tony Lindgren; Russell King
  Cc: Kanigeri, Hari; Ohad Ben-Cohen; Shilimkar, Santosh; Molnar, Lajos
  Subject: RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

   -Original Message-
   From: Sin, David
   Sent: Saturday, July 24, 2010 4:52 AM
   To: linux-arm-ker...@lists.arm.linux.org.uk;
  linux-omap@vger.kernel.org;
   Tony Lindgren; Russell King
   Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav;
  Shilimkar, Santosh;
   Sin, David; Molnar, Lajos
   Subject: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

   This patch adds support for DMM-PAT initialization and programming.

  [Hiremath, Vaibhav] Sorry for delayed response, always better
  late than never.

 [dhs] Thanks for your comments, Vaibhav.  I'll pull them in for RFC v2.

   Signed-off-by: David Sin david...@ti.com
   Signed-off-by: Lajos Molnar mol...@ti.com
   ---
arch/arm/mach-omap2/include/mach/dmm.h |  128 
drivers/media/video/tiler/dmm.c|  200

2 files changed, 328 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/dmm.h
create mode 100644 drivers/media/video/tiler/dmm.c

  [Hiremath, Vaibhav] If I understand correctly, DMM stands for
  dynamic memory manager. Is it something which can only be
  used with Video devices? Any specific reason why this is part
  of drivers/media/video/ directory,
 [dhs] Any device can use TILER memory, but there is a big advantage,
 performance-wise, for 2-Dimensional macro block based buffers.  This HW is
 intended for image/video hardware accelerators (e.g. OMAP4 IVA-HD).  Plus
 there's the added advantage of doing zero-copy flips and rotations for the
 OMAP display and image sub-systems.

[Hiremath, Vaibhav] When you mention Tiler memory, you meant Tiler Virtual 
memory which is independent of physical memory. Driver requesting/using Tiler 
is responsible for allocating physical memory. Is that understanding correct?

If yes, then feature wise it is same as VRFB in OMAP3, where it provides 
virtual address space and driver requesting VRFB is responsible for physical 
memory allocation. There could be additional features, enhancement and stuff 
but zero-copy rotation for DSS, then its same as VRFB.

Don't you think is would be very difficult to use for drivers with such 
proposals, I can comment from DSS point of view,

In case of OMAP4 80% of code is being re-used from OMAP3 (located under 
drivers/video/omap2/), which is currently supported hardware rotation/mirroring 
and hardly tied to VRFB API's.

Now with this driver we have to do something,

cpu_is_omap34xx()
VRFB
else if cpu_is_omap44xx()
Tiler

I am not sure about further OMAP series of devices, where we might have 
something else with DSS IP reuse (along with software). And I believe Tiler is 
not part of DSS at all.
Again if some other devices are using Tiler API's it would become more 
difficult to re-use the code when same IP is being used in multiple SoC's.

Does it make sense to you to have registration based mechanism (function 
pointer) where you register your hardware capabilities/API's, driver don't have 
to dependent on underneath hardware block. Ofcource if driver intend to use 
some specific/custom feature supported by some hardware block then he has to 
call that API under cpu_is_

   diff --git a/arch/arm/mach-omap2/include/mach/dmm.h b/arch/arm/mach-
   omap2/include/mach/dmm.h
   new file mode 100644
   index 000..68b798a
   --- /dev/null
   +++ b/arch/arm/mach-omap2/include/mach/dmm.h
   @@ -0,0 +1,128 @@
   +/*
   + * dmm.h
   + *
   + * DMM driver support functions for TI DMM-TILER hardware block.
   + *
   + * Author: David Sin david...@ti.com
   + *
   + * Copyright (C) 2009-2010 Texas Instruments, Inc.
   + *
   + * This package is free software; you can redistribute it
  and/or modify
   + * it under the terms of the GNU General Public License
  version 2 as
   + * published by the Free Software Foundation.
   + *
   + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
   + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
   + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A
  PARTICULAR PURPOSE.
   + */
   +
   +#ifndef DMM_H
   +#define DMM_H
   +
   +#define DMM_BASE 0x4E00
   +#define DMM_SIZE 0x800
  [Hiremath, Vaibhav] Unused definition (DMM_SIZE), do we required it?
 [dhs] It's currently being used

RE: [RFC 2/8] TILER-DMM: Container manager interface and utility definitons


 -Original Message-
 From: Sin, David
 Sent: Saturday, July 24, 2010 4:52 AM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
 Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
 Molnar, Lajos; Sin, David; Ramachandra, Ravikiran
 Subject: [RFC 2/8] TILER-DMM: Container manager interface and utility
 definitons
 
 From: Lajos Molnar mol...@ti.com
 
 This patch defined the TILER Container Manager (TCM) interface and
 provides utility methods for implementing a TCM.
 
 Signed-off-by: Lajos Molnar mol...@ti.com
 Signed-off-by: David Sin david...@ti.com
 Signed-off-by: Ravi Ramachandra r.ramachan...@ti.com
 ---
  drivers/media/video/tiler/tcm.h   |  209
 +
  drivers/media/video/tiler/tcm/tcm-utils.h |   54 
  2 files changed, 263 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tiler/tcm.h
  create mode 100644 drivers/media/video/tiler/tcm/tcm-utils.h
 
 diff --git a/drivers/media/video/tiler/tcm.h
 b/drivers/media/video/tiler/tcm.h
 new file mode 100644
 index 000..52a022a
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm.h
 @@ -0,0 +1,209 @@
 +/*
 + * tcm.h
 + *
 + * TILER container manager specification and support functions for TI
 + * TILER driver.
 + *
 + * Author: Lajos Molnar mol...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + */
 +
 +#ifndef TCM_H
 +#define TCM_H
 +
 +struct tcm;
 +
 +/* point */
 +struct tcm_pt {
 + u16 x;
 + u16 y;
 +};
 +
 +/* 2d area */
 +struct tcm_area {
 + struct tcm*tcm; /* parent */
 + struct tcm_pt  p0;
 + struct tcm_pt  p1;
 +};
 +
 +struct tcm {
 + u16 width, height;  /* container dimensions */
 +
 + /* 'pvt' structure shall contain any tcm details (attr) along with
 + linked list of allocated areas and mutex for mutually exclusive access
 + to the list.  It may also contain copies of width and height to notice
 + any changes to the publicly available width and height fields. */
 + void *pvt;
 +
 + /* function table */
 + s32 (*reserve_2d)(struct tcm *tcm, u16 height, u16 width, u8 align,
 +   struct tcm_area *area);
 + s32 (*free)  (struct tcm *tcm, struct tcm_area *area);
 + void (*deinit)   (struct tcm *tcm);
 +};
 +
 +/*=
 
 +BASIC TILER CONTAINER MANAGER INTERFACE
 +===
 ==*/
 +
 +/*
 + * NOTE:
 + *
 + * Since some basic parameter checking is done outside the TCM algorithms,
 + * TCM implementation do NOT have to check the following:
 + *
 + *   area pointer is NULL
 + *   width and height fits within container
 + *   number of pages is more than the size of the container
 + *
 + */
 +
 +/**
 + * Template for ALGO_NAME_tcm_init method.  Define as:
 + * TCM_INIT(ALGO_NAME_tcm_init)
 + *
 + * Allocates and initializes a tiler container manager.
 + *
 + * @param width  Width of container
 + * @param height Height of container
 + * @param attr   Container manager specific configuration
 + *   arguments.  Please describe these in
 + *   your header file.
 + *
 + * @return Pointer to the allocated and initialized container
 + *  manager.  NULL on failure.  DO NOT leak any memory on
 + *  failure!
 + */
 +#define TCM_INIT(name, attr_t) \
 +struct tcm *name(u16 width, u16 height, typeof(attr_t) *attr);
 +
 +/**
 + * Deinitialize tiler container manager.
 + *
 + * @param tcmPointer to container manager.
 + *
 + * @return 0 on success, non-0 error value on error.  The call
 + *  should free as much memory as possible and meaningful
 + *  even on failure.  Some error codes: -ENODEV: invalid
 + *  manager.
 + */
 +static inline void tcm_deinit(struct tcm *tcm)
 +{
 + if (tcm)
 + tcm-deinit(tcm);
[Hiremath, Vaibhav] you may want to check for tcm-deinit also before calling.

 +}
 +
 +/**
 + * Reserves a 2D area in the container.
 + *
 + * @param tcmPointer to container manager.
 + * @param height Height(in pages) of area to be reserved.
 + * @param width  Width(in pages) of area to be reserved.
 + * @param align  Alignment requirement for top-left corner of 
 area.
 Not
 + *   all values may be supported by the container manager,
 + *   but it must support 0 (1), 32 and 64.
 + *

RE: [RFC 3/8] TILER-DMM: Sample TCM implementation: Simple TILER Allocator

 -Original Message-
 From: Sin, David
 Sent: Saturday, July 24, 2010 4:52 AM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
 Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
 Ramachandra, Ravikiran; Molnar, Lajos; Sin, David
 Subject: [RFC 3/8] TILER-DMM: Sample TCM implementation: Simple TILER
 Allocator

 From: Ravi Ramachandra r.ramachan...@ti.com

 This patch implements a simple TILER Container Manager.

 Signed-off-by: Ravi Ramachandra r.ramachan...@ti.com
 Signed-off-by: Lajos Molnar mol...@ti.com
 Signed-off-by: David Sin david...@ti.com
 ---
  drivers/media/video/tiler/tcm/Makefile|1 +
  drivers/media/video/tiler/tcm/_tcm-sita.h |   64 
  drivers/media/video/tiler/tcm/tcm-sita.c  |  459
 +
  drivers/media/video/tiler/tcm/tcm-sita.h  |   37 +++
  4 files changed, 561 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tiler/tcm/Makefile
  create mode 100644 drivers/media/video/tiler/tcm/_tcm-sita.h
  create mode 100644 drivers/media/video/tiler/tcm/tcm-sita.c
  create mode 100644 drivers/media/video/tiler/tcm/tcm-sita.h

 diff --git a/drivers/media/video/tiler/tcm/Makefile
 b/drivers/media/video/tiler/tcm/Makefile
 new file mode 100644
 index 000..8434607
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/Makefile
 @@ -0,0 +1 @@
 +obj-$(CONFIG_TI_TILER) += tcm-sita.o
 diff --git a/drivers/media/video/tiler/tcm/_tcm-sita.h
 b/drivers/media/video/tiler/tcm/_tcm-sita.h
 new file mode 100644
 index 000..4ede1ab
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/_tcm-sita.h
 @@ -0,0 +1,64 @@
 +/*
 + * _tcm_sita.h
 + *
 + * SImple Tiler Allocator (SiTA) private structures.
 + *
 + * Author: Ravi Ramachandra r.ramachan...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + */
 +
 +#ifndef _TCM_SITA_H
 +#define _TCM_SITA_H
 +
 +#include ../tcm.h
 +
 +/* length between two coordinates */
 +#define LEN(a, b) ((a)  (b) ? (a) - (b) + 1 : (b) - (a) + 1)
 +
 +enum criteria {
 + CR_MAX_NEIGHS   = 0x01,
 + CR_FIRST_FOUND  = 0x10,
 + CR_BIAS_HORIZONTAL  = 0x20,
 + CR_BIAS_VERTICAL= 0x40,
 + CR_DIAGONAL_BALANCE = 0x80
 +};
 +
 +/* nearness to the beginning of the search field from 0 to 1000 */
 +struct nearness_factor {
 + s32 x;
 + s32 y;
 +};
 +
 +/*
 + * Statistics on immediately neighboring slots.  Edge is the number of
 + * border segments that are also border segments of the scan field.  Busy
 + * refers to the number of neighbors that are occupied.
 + */
 +struct neighbor_stats {
 + u16 edge;
 + u16 busy;
 +};
 +
 +/* structure to keep the score of a potential allocation */
 +struct score {
 + struct nearness_factor  f;
 + struct neighbor_stats   n;
 + struct tcm_area a;
 + u16neighs;  /* number of busy neighbors */
 +};
 +
 +struct sita_pvt {
 + struct mutex mtx;
 + struct tcm_area ***map; /* pointers to the parent area for each slot
 */
 +};
 +
 +#endif
 diff --git a/drivers/media/video/tiler/tcm/tcm-sita.c
 b/drivers/media/video/tiler/tcm/tcm-sita.c
 new file mode 100644
 index 000..93be3e6
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/tcm-sita.c
 @@ -0,0 +1,459 @@
 +/*
 + * tcm-sita.c
 + *
 + * SImple Tiler Allocator (SiTA): 2D and 1D allocation(reservation)
 algorithm
 + *
 + * Authors: Ravi Ramachandra r.ramachan...@ti.com,
 + *  Lajos Molnar mol...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + *
 + */
 +#include linux/slab.h
 +
 +#include _tcm-sita.h
 +#include tcm-sita.h
 +
 +#define TCM_ALG_NAME tcm_sita
[Hiremath, Vaibhav] Move this after include statement.

 +#include tcm-utils.h
 +
 +#define ALIGN_DOWN(value, align) ((value)  ~((align) - 1))
 +
 +/* Individual selection criteria for different scan areas */
 +static s32 CR_L2R_T2B = CR_BIAS_HORIZONTAL;
 +
[Hiremath, Vaibhav] Not good practice to define variable in caps.
Also why do we need this variable which is not getting modified and used as 
constant only?

 +/*
 + *   TCM

TWL scripts, and booting pm-2.6.29 on Beagleboard

2010-07-27 Thread Peter Tseng

Hello everyone.

I am attempting to get the branch named pm-2.6.29 of Kevin Hilman's
linux-omap-pm repo to boot on a Beagleboard revision B5.

The purpose of this is to apply some patches made by Russ Dill about a
year ago [1] that allow a low-power sleep by adding some TWL scripts. I
have been unable to determine whether these are working with the branch
named pm (I am aware that the second and fourth patch are already
applied, so I only need the first and third), so I figured it was best
to start from the same point that Russ Dill started at, which he reports
is pm-2.6.29

The trouble is that pm-2.6.29 does not boot (I boot from an SD card, use
the config file named omap3_beagle_pm_defconfig, and use u-boot 2009.11)
-- no output is printed after Uncompressing Linux... done, booting the
kernel.
Normally, I would enable CONFIG_EARLY_PRINTK and provide some resulting
output, but this option seems to be missing from the branch in question.

I asking for help in one of the following:
1) Whether there is any alternative way to get useful output to diagnose
why pm-2.6.29 is not booting.
2) How to apply the patch similarly to the current pm branch. (Have the
relevant sections been moved to a generic file at board-3430sdp.c ? Is
there anything else I need to know? Is there documentation on what
exactly these scripts are doing?)
3) Whether there's any alternative way to achieve the same objectives of
power savings.

I appreciate your support in this.

Peter Tseng

[1]
http://groups.google.com/group/beagleboard/browse_thread/thread/197a8ef6b46cc828/6e98db4cbe2cebaa
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] omap:mailbox-provide multiple reader support

2010-07-27 Thread Ohad Ben-Cohen

Hi Hari,

On Wed, Jul 21, 2010 at 12:41 AM, Hari Kanigeri h-kanige...@ti.com wrote:
 This patch provides mutiple readers support for a mailbox
 instance.

 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/plat-omap/include/plat/mailbox.h |    6 ++-
  arch/arm/plat-omap/mailbox.c              |   63 
  2 files changed, 40 insertions(+), 29 deletions(-)

 diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
 b/arch/arm/plat-omap/include/plat/mailbox.h
 index 0486d64..c8e47d8 100644
 --- a/arch/arm/plat-omap/include/plat/mailbox.h
 +++ b/arch/arm/plat-omap/include/plat/mailbox.h
 @@ -68,13 +68,15 @@ struct omap_mbox {
        void                    *priv;

        void                    (*err_notify)(void);
 +       atomic_t                use_count;
 +       struct blocking_notifier_head   notifier;
  };

  int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
  void omap_mbox_init_seq(struct omap_mbox *);

 -struct omap_mbox *omap_mbox_get(const char *);
 -void omap_mbox_put(struct omap_mbox *);
 +struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);

In this context, I'd like to change notifier to support adding a
cookie which will be passed back to the handler function (unmodified,
in a similar manner to request_irq's void *dev param).

This cookie param will be passed to the mailbox callback whenever a
mailbox event is triggered, and will allow drivers to have multiple
instances: instead of maintaining their state in a global variable
(like bridge is doing today), it will be given back every time a
mailbox event is delivered. For syslink it will also help using the
same mbox callback for different devices (e.g. sysm3, appm3).

The changes should be minor, and shouldn't affect existing notifier
users, here's the diff (untested):

diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 540703b..e740aea 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -51,6 +51,7 @@ struct notifier_block {
int (*notifier_call)(struct notifier_block *, unsigned long, void *);
struct notifier_block *next;
int priority;
+   void *dev_id;
 };

 struct atomic_notifier_head {
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 2488ba7..050fd9b 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -64,6 +64,7 @@ static int notifier_chain_unregister(struct notifier_block **n
  * @nl:Pointer to head of the blocking notifier chain
  * @val:   Value passed unmodified to notifier function
  * @v: Pointer passed unmodified to notifier function
+ * If pointer is NULL, the notifier block's
cookie is passed
  * @nr_to_call:Number of notifier functions to be called. Don't care
  * value of this parameter is -1.
  * @nr_calls:  Records the number of notifications sent. Don't care
@@ -90,6 +91,7 @@ static int __kprobes notifier_call_chain(struct notifier_block
continue;
}
 #endif
+   v = v ? v : nb-dev_id;
ret = nb-notifier_call(nb, val, v);

if (nr_calls)


And the only change in your mbox patch should be:

@@ -149,8 +149,8 @@ static void mbox_rx_work(struct work_struct *work)
   if (unlikely(len != sizeof(msg)))
   pr_err(%s: kfifo_out anomaly detected\n, __func__);

-   blocking_notifier_call_chain(mq-mbox-notifier, len,
-   (void *)msg);
+               blocking_notifier_call_chain(mq-mbox-notifier, msg, NULL);
   }
 }

The result should be us getting both the mailbox msg and the original
cookie, which will, in our case, be the context of the relevant
dspbridge or syslink driver.

What do you think ?

Thanks,
Ohad.
--
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: Issue with file transfers to a mass storage device on SMP system

 -Original Message-
 From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
 Sent: Tuesday, July 27, 2010 9:37 PM
 To: Shilimkar, Santosh
 Cc: Mankad, Maulik Ojas; linux-...@vger.kernel.org; linux-
 o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: Re: Issue with file transfers to a mass storage device on SMP
 system

 On Tue, Jul 27, 2010 at 07:59:17PM +0530, Shilimkar, Santosh wrote:
  Once it's pushed out of L2X WB, it will hit the memory. Just to give an
 additional data point, with CATC analyzer what we see that only those
  16 bytes CDB are 0x0. This buffer was memset to 0x0 just before the
  memcpy.

  I am just wondering who will issue a barrier(wmb) on this buffer before
 DMA
  start if we don't use dma-mapping APIs? May be for dma_alloc_coherent
  buffers, we need to explicitly issue the barrier.

 wmb's don't take addresses - they're a global thing.  All stores before
 the wmb() take effect before stores after the wmb().

 The wmb() is issued by Catalin's IO ordering patches:

 +#define writeb(v,c)({ wmb(); writeb_relaxed(v,c); })
 +#define writew(v,c)({ wmb(); writew_relaxed(v,c); })
 +#define writel(v,c)({ wmb(); writel_relaxed(v,c); })

 So, the wmb() is issued to ensure that all stores to (eg) buffers
 allocated by dma_alloc_coherent() hit memory prior to the store to
 the device.

 Now, if you're writing to registers using something other than
 write[bwl](),
 you'll miss the wmb(), and therefore your DMA buffer won't be up to date.

Yep. 
 And this _is_ the problem:

 drivers/usb/musb/musb_io.h:static inline void musb_writew(void __iomem
 *addr, unsigned offset, u16 data)
 drivers/usb/musb/musb_io.h: { __raw_writew(data, addr + offset); }
 drivers/usb/musb/musb_io.h:static inline void musb_writel(void __iomem
 *addr, unsigned offset, u32 data)
 drivers/usb/musb/musb_io.h: { __raw_writel(data, addr + offset); }
 drivers/usb/musb/musb_io.h:static inline void musb_writeb(void __iomem
 *addr, unsigned offset, u8 data)
 drivers/usb/musb/musb_io.h: __raw_writew(tmp, addr + (offset  ~1));
 drivers/usb/musb/musb_io.h:static inline void musb_writeb(void __iomem
 *addr, unsigned offset, u8 data)
 drivers/usb/musb/musb_io.h: { __raw_writeb(data, addr + offset); }

 All IO performed by musb misses out on the barriers - so what you
 need to do is either add wmb()s to these, or you need to ensure
 that the driver has the various necessary memory barriers in place.
 The latter solution will be more efficient.

I also agree that patching driver is less impacting and non-intrusive. We will 
go ahead with the original work-around which adds barrier in the driver.

Thanks for the good discussion on this.

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: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation