date:20100915


On Tue, Sep 14, 2010 at 12:51:09PM -0500, Sergei Shtylyov wrote:

Hello.

Felipe Balbi wrote:


   If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),


   Oh, here I mixed some other patch with Ming Lei's ones...


it will pass due to the



than this is the actual problem, no ? If we're using mode1 dma (as we
are on tx path), we should only get dma interrupt when the whole
transfer has been completed.


   The Inventra DMA controller has serious DMA length limitation, so the whole
transfer may take more than one DMA.


When I said 'whole transfer' I meant the transfer size you programmed
dma to transfer, see that we have (not actual code):

if (transfer_size  dma-max_len)
transfer_size = dma-max_len;

dma-channel_program(...,..., transfer_size,...);

with mode1, we will only get irq when dma has transferred transfer_size
bytes.


likewise, this was there before the patch. I don't think the real
problem lies with this patch, it's been there for a while, don't you
agree ?


   Then what problem this patch fixes, if not this one?


if request-length == 1MB and dma-max_len = 128KB, when is_dma is true,
request-actual will be different from request-length for 7
'iterations', then only on the 8th it will be the same. I believe that's
what Ming is trying to fix.

Ming, am I correct ?


   Let me repeat: in the PIO mode the added check is just duplicate, in the DMA


it is duplicate for PIO, but not for DMA.

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

Re: [RESEND/PATCH 6/6] USB: musb-gadget: fix dma length in txstate


On Tue, Sep 14, 2010 at 12:43:25PM -0500, Sergei Shtylyov wrote:

Hello.

tom.leim...@gmail.com wrote:


From: Ming Lei tom.leim...@gmail.com



DMA length should not go beyond the availabe space of request buffer,
so fix it.



Signed-off-by: Ming Lei tom.leim...@gmail.com
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Felipe Balbi m...@felipebalbi.com
Cc: Anand Gadiyar gadi...@ti.com
Cc: Mike Frysinger vap...@gentoo.org
Cc: Sergei Shtylyov sshtyl...@ru.mvista.com


[...]


diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fa826f9..cacae96 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -300,6 +300,11 @@ static void txstate(struct musb *musb, struct musb_request 
*req)
 #ifndefCONFIG_MUSB_PIO_ONLY
if (is_dma_capable()  musb_ep-dma) {
struct dma_controller   *c = musb-dma_controller;
+   size_t request_size;
+
+   /* setup DMA, then program endpoint CSR */
+   request_size = min_t(size_t, request-length - request-actual,
+   musb_ep-dma-max_len);


   Er, you're moving this from under #ifdef CONFIG_USB_INVENTRA_DMA to the
common code, right? Do you know that not all DMA drivers initialize max_len? For
example CPPI driver doesn't, so it's left at zero. You're going to break DMA for
CPPI. Please extend your patch, adding cppi_dma.c to it.


yes, please set some value on cppi_dma.c max_len field.

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

Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration


Hi,

On Tue, Sep 14, 2010 at 09:11:26AM -0500, G, Manjunath Kondaiah wrote:

There are several places in kernel code (ex:
tools/perf/util/include/linux/bitops.h:static __always_inline int
test_bit(unsigned int nr, const unsigned long *addr)) which are using
__always_inline attribute to make sure functions are inlined.


those are special cases. Generally, compiler is much better than humans
for choosing what should be inlined or not.


Ok, Agreed.  We can have inline functions and expanding all macros in mach-omap
dma driver code.
However, there is common dma driver(in plat-omap) which has code for both omap1
and omap2plus which uses this macro.


well, that can be patched, right ?

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

Re: [PATCH v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-15 Thread Ohad Ben-Cohen

2010/9/6 Michał Mirosław mir...@gmail.com:
 W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
 li...@arm.linux.org.uk napisał:
 On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
 2010/9/1 Ohad Ben-Cohen o...@wizery.com:
  Add a simple mechanism to pass platform data to the
  SDIO instances of wl12xx.
 [cut patch]
 Why do you need all that copying? Isn't the data constant?

 The first copy is to allow platforms to have their data marked with
 __initdata.  The second copy probably isn't necessary, but avoids
 problems where the driver may decide to modify the platform data.

 Sorry for pushing at this, but why would you mark data that's meant to
 be used after init phase as __initdata?

I can remove the first copying as well if Russell is ok with it.

Both ways work for us.


 Best Regards,
 Michał Mirosław

--
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] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path

2010-09-15 Thread Basak, Partha

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com] 
 Sent: Tuesday, September 14, 2010 10:28 PM
 To: Basak, Partha
 Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; Tero Kristo
 Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of 
 interrupts-disabled idle path

 Basak, Partha p-bas...@ti.com writes:

  From: Kevin Hilman khil...@ti.com

  Currently, we wait until late in the idle path where interrupts are
  disabled to do runtime-PM-like management for certain special-case
  devices like GPIO.

  As a prerequiste to moving GPIO to the new runtime PM 
 framework, move
  this runtime-PM-like code out of the late idle path into new device
  idle and resume functions that can be called before interrupts are
  disabled by CPUidle and/or suspend.

  In addition, move all the GPIO-specific logic into the GPIO core
  instead of keeping GPIO-specific knowledge of power-states, context
  saving etc. in the PM core.

  Also, call the new device-idle and -resume methods from CPUidle and
  static suspend path.

  Signed-off-by: Kevin Hilman khil...@ti.com
  ---
   arch/arm/mach-omap2/cpuidle34xx.c  |4 ++
   arch/arm/mach-omap2/pm.h   |2 +
   arch/arm/mach-omap2/pm24xx.c   |2 +-
   arch/arm/mach-omap2/pm34xx.c   |   38 
 +
   arch/arm/plat-omap/gpio.c  |   57 

   arch/arm/plat-omap/include/plat/gpio.h |4 +--
   6 files changed, 67 insertions(+), 40 deletions(-)

  diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
  b/arch/arm/mach-omap2/cpuidle34xx.c
  index 0923b82..681d823 100644
  --- a/arch/arm/mach-omap2/cpuidle34xx.c
  +++ b/arch/arm/mach-omap2/cpuidle34xx.c
  @@ -274,9 +274,13 @@ static int omap3_enter_idle_bm(struct 
  cpuidle_device *dev,
 pwrdm_set_next_pwrst(per_pd, per_next_state);

   select_state:
  +  omap3_device_idle();
  +
 dev-last_state = new_state;
 ret = omap3_enter_idle(dev, new_state);

  +  omap3_device_resume();
  +
  In the generic cpu_idle() in process.c, interrupts are 
 already disabled
  before control comes to cpuidle_idle_call() via pm_idle()
  local_irq_disable();
  if (hlt_counter) {
  local_irq_enable();
  cpu_relax();
  } else {
  stop_critical_timings();
  pm_idle();
  start_critical_timings();
  /*
   * This will eventually be 
 removed - pm_idle
   * functions should always 
 return with IRQs
   * enabled.
   */
  WARN_ON(irqs_disabled());
  local_irq_enable();
  }

  omap3_enter_idle_bm() will be called from inside 
 cpuidle_idle_call() 
  via target_state-enter(dev, target_state).
  So, interrupts are already disabled here.

  Am I missing something?

 You're right.  

 I knew this was the case for !CPUIDLE setup, but had thought (without
 testing) that the CPUidle core had re-enabled interrupts during the
 governor selection process etc.

 While I investigate ways to manage this in CPUidle, the 
 following should
 be fine for now to include with $SUBJECT patch.

 Kevin

 diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
 b/arch/arm/mach-omap2/cpuidle34xx.c
 index 681d823..c5cb9d0 100644
 --- a/arch/arm/mach-omap2/cpuidle34xx.c
 +++ b/arch/arm/mach-omap2/cpuidle34xx.c
 @@ -245,6 +245,14 @@ static int omap3_enter_idle_bm(struct 
 cpuidle_device *dev,
   goto select_state;
   }

 + /*
 +  * Enable IRQs during the device activity checking and 
 idle management.
 +  * IRQs are later (re)disabled when entering the actual 
 idle function.
 +  * Device idle management that is using runtime PM needs to have
 +  * interrupts enabled when calling into the runtime PM core.
 +  */
 + local_irq_enable();
 +
   cx = cpuidle_get_statedata(state);
   core_next_state = cx-core_state;

OK. We will base on top of this patch.

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

Re: [PATCH v3 1/2] OMAP: DSS2: Introduce dss_features files

2010-09-15 Thread Tomi Valkeinen

Hi,

On Mon, 2010-09-13 at 07:30 +0200, ext Archit Taneja wrote:
 Add dss_features.c and dss_features.h for the dss_features framework
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/Makefile   |2 +-
  drivers/video/omap2/dss/dss_features.c |  191 
 
  drivers/video/omap2/dss/dss_features.h |   50 
  3 files changed, 242 insertions(+), 1 deletions(-)
  create mode 100644 drivers/video/omap2/dss/dss_features.c
  create mode 100644 drivers/video/omap2/dss/dss_features.h
 
 diff --git a/drivers/video/omap2/dss/Makefile 
 b/drivers/video/omap2/dss/Makefile
 index d71b5d9..7db17b5
 --- a/drivers/video/omap2/dss/Makefile
 +++ b/drivers/video/omap2/dss/Makefile
 @@ -1,5 +1,5 @@
  obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 -omapdss-y := core.o dss.o dispc.o display.o manager.o overlay.o
 +omapdss-y := core.o dss.o dss_features.o dispc.o display.o manager.o 
 overlay.o
  omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
  omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
  omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
 diff --git a/drivers/video/omap2/dss/dss_features.c 
 b/drivers/video/omap2/dss/dss_features.c
 new file mode 100644
 index 000..c3e4d4d
 --- /dev/null
 +++ b/drivers/video/omap2/dss/dss_features.c
 @@ -0,0 +1,191 @@
 +/*
 + * linux/drivers/video/omap2/dss/dss_features.c
 + *
 + * Copyright (C) 2010 Texas Instruments
 + * Author: Archit Taneja arc...@ti.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, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/kernel.h
 +#include linux/types.h
 +#include linux/err.h
 +#include linux/slab.h
 +
 +#include plat/display.h
 +#include plat/cpu.h
 +
 +#include dss_features.h
 +
 +/* Defines a generic omap register field */
 +struct dss_reg_field {
 + enum dss_feat_reg_field id;
 + u8 start, end;
 +};
 +
 +struct omap_dss_features {
 + struct dss_reg_field *reg_fields;
 + int num_reg_fields;
 +
 + u32 has_feature;
 +
 + int num_mgrs;
 + int num_ovls;
 + enum omap_display_type *supported_displays;
 + enum omap_color_mode *supported_color_modes;
 +};
 +
 +/* This struct is assigned to one of the below during initialization */
 +static struct omap_dss_features omap_current_dss_features;

Any particular reason this is not a pointer?

Also, I think most (all?) of the structs can be consts, as they are
never changed.

Otherwise I think this looks good.

 Tomi


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

RE: [PATCH v3 1/2] OMAP: DSS2: Introduce dss_features files

2010-09-15 Thread Taneja, Archit

Hi,

Tomi Valkeinen wrote:
 Hi,
 
 On Mon, 2010-09-13 at 07:30 +0200, ext Archit Taneja wrote:
 Add dss_features.c and dss_features.h for the dss_features framework
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/Makefile   |2 +-
  drivers/video/omap2/dss/dss_features.c |  191
 
  drivers/video/omap2/dss/dss_features.h |   50 
  3 files changed, 242 insertions(+), 1 deletions(-)  create mode
 100644 drivers/video/omap2/dss/dss_features.c
  create mode 100644 drivers/video/omap2/dss/dss_features.h
 
 diff --git a/drivers/video/omap2/dss/Makefile
 b/drivers/video/omap2/dss/Makefile
 index d71b5d9..7db17b5
 --- a/drivers/video/omap2/dss/Makefile
 +++ b/drivers/video/omap2/dss/Makefile
 @@ -1,5 +1,5 @@
  obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 -omapdss-y := core.o dss.o dispc.o display.o manager.o overlay.o
 +omapdss-y := core.o dss.o dss_features.o dispc.o display.o manager.o
  +overlay.o omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
  omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
  omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o diff --git
 a/drivers/video/omap2/dss/dss_features.c
 b/drivers/video/omap2/dss/dss_features.c
 new file mode 100644
 index 000..c3e4d4d
 --- /dev/null
 +++ b/drivers/video/omap2/dss/dss_features.c
 @@ -0,0 +1,191 @@
 +/*
 + * linux/drivers/video/omap2/dss/dss_features.c
 + *
 + * Copyright (C) 2010 Texas Instruments
 + * Author: Archit Taneja arc...@ti.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, see http://www.gnu.org/licenses/. + */
 +
 +#include linux/kernel.h
 +#include linux/types.h
 +#include linux/err.h
 +#include linux/slab.h
 +
 +#include plat/display.h
 +#include plat/cpu.h
 +
 +#include dss_features.h
 +
 +/* Defines a generic omap register field */ struct dss_reg_field { +
 enum
 dss_feat_reg_field id; + u8 start, end;
 +};
 +
 +struct omap_dss_features {
 +struct dss_reg_field *reg_fields;
 +int num_reg_fields;
 +
 +u32 has_feature;
 +
 +int num_mgrs;
 +int num_ovls;
 +enum omap_display_type *supported_displays;
 +enum omap_color_mode *supported_color_modes; };
 +
 +/* This struct is assigned to one of the below during initialization
 +*/ static struct omap_dss_features omap_current_dss_features;
 
 Any particular reason this is not a pointer?

Not really, it didn't cross my mind that I could make it a pointer.
I will make these changes..

Do you have comments for the 2nd patch in this series, I wanted to consider
them while making a next series.

 
 Also, I think most (all?) of the structs can be consts, as they are never
 changed. 
 
 Otherwise I think this looks good.
 
  Tomi

Archit--
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 v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-15 Thread Russell King - ARM Linux

On Mon, Sep 06, 2010 at 09:42:41PM +0200, Michał Mirosław wrote:
 W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
 li...@arm.linux.org.uk napisał:
  On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
  2010/9/1 Ohad Ben-Cohen o...@wizery.com:
   Add a simple mechanism to pass platform data to the
   SDIO instances of wl12xx.
 [cut patch]
  Why do you need all that copying? Isn't the data constant?
 
  The first copy is to allow platforms to have their data marked with
  __initdata.  The second copy probably isn't necessary, but avoids
  problems where the driver may decide to modify the platform data.
 
 Sorry for pushing at this, but why would you mark data that's meant to
 be used after init phase as __initdata?

Because you may have many instances of the data (due to multiple platform
support), and only need one of them at run-time.
--
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 v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-15 Thread Vitaly Wool

2010/9/15 Ohad Ben-Cohen o...@wizery.com:
 Sorry for pushing at this, but why would you mark data that's meant to
 be used after init phase as __initdata?

 I can remove the first copying as well if Russell is ok with it.

I personally think it's not worth it. This copying basically happens
only once and this point is s irrelevant. My position therefore
is: let's get the current implementation in, and if Michal is
uncomfortable with that, he can come up with the patch. Let's
concentrate on the real problems.

Thanks,
   Vitaly
--
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 2/2] OMAP: DSS2: Use dss_features framework on DSS2 code

2010-09-15 Thread Tomi Valkeinen

On Mon, 2010-09-13 at 07:30 +0200, ext Archit Taneja wrote:
 Calls init functions of dss_features during dss_probe, and the following
 features are made omap independent:
   - number of managers, overlays
   - supported color modes for each overlay
   - supported displays for each manager
   - global aplha, and restriction of global alpha for video1 pipeline
   - The register field ranges : FIRHINC, FIRVINC, FIFOHIGHTHRESHOLD
 FIFOLOWTHRESHOLD and FIFOSIZE
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  arch/arm/plat-omap/include/plat/display.h |   31 
  drivers/video/omap2/dss/core.c|3 ++
  drivers/video/omap2/dss/dispc.c   |   56 
 -
  drivers/video/omap2/dss/manager.c |   33 -
  drivers/video/omap2/dss/overlay.c |   24 +---
  5 files changed, 60 insertions(+), 87 deletions(-)

snip

  static void _dispc_setup_global_alpha(enum omap_plane plane, u8 global_alpha)
  {
 -
 -   BUG_ON(plane == OMAP_DSS_VIDEO1);
 -
 -   if (cpu_is_omap24xx())
 +   if (!dss_has_feature(FEAT_GLOBAL_ALPHA))
 return;
 
 +   BUG_ON(!dss_has_feature(FEAT_GLOBAL_ALPHA_VID1) 
 +   plane == OMAP_DSS_VIDEO1);
 +
 if (plane == OMAP_DSS_GFX)
 REG_FLD_MOD(DISPC_GLOBAL_ALPHA, global_alpha, 7, 0);
 else if (plane == OMAP_DSS_VIDEO2)
 @@ -949,17 +950,14 @@ static void dispc_read_plane_fifo_sizes(void)
   DISPC_VID_FIFO_SIZE_STATUS(1) };
 u32 size;
 int plane;
 +   u8 size1, size2;

You have a bit inconsistent naming with these. The function is defined
as accepting start and end, here you use size1 and size2, below you have
foo1 and foo2.

Size is not a good name, as it's not size at all. Perhaps foo_start and
foo_end (or just start and end if there's only one feat being used)? Or
foo_msb and foo_lsb (as in most/least significant bit)?

Otherwise looks good.

 Tomi


--
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 v5 0/7] native wl1271 support on ZOOM

2010-09-15 Thread Ohad Ben-Cohen

On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 This patchset adds wl1271 support on ZOOM2/3 boards.

Tony, John, let me please suggest merging this through the wireless tree.

wl1271 is a moving target - it keeps changing in the wireless tree and
merging this patchset there will allow wl1271 developers to have
everything in a single tree (and prevent merge conflicts in
linux-next).

If that's ok with you, I will rebase this on top of wireless-testing
and resubmit.


 Only basic support is included; MMC power manipulation part is submitted 
 separately as Runtime PM migration.

 Changes since v4:
 - Introduce a simple (yet safe) mechanism to pass platform-specific data to 
 the driver, as suggested by Russell King. Currently only a single device is 
 supported; multi-device support will be introduced only when/if required

 Patches are based on 2.6.36-rc3 and tested on ZOOM3.

 Thanks,

 Ohad Ben-Cohen (7):
  wireless: wl1271: make wl12xx.h common to both spi and sdio
  wireless: wl1271: support return value for the set power func
  wireless: wl12xx: add platform data passing support
  wireless: wl1271: take irq info from private board data
  wireless: wl1271: make ref_clock configurable by board
  omap: zoom: add fixed regulator device for wlan
  omap: zoom: add mmc3/wl1271 device support

  arch/arm/mach-omap2/board-zoom-peripherals.c       |   54 
 
  drivers/net/wireless/Makefile                      |    2 +
  drivers/net/wireless/wl12xx/Kconfig                |    5 ++-
  drivers/net/wireless/wl12xx/wl1251_sdio.c          |    2 +-
  drivers/net/wireless/wl12xx/wl1251_spi.c           |    2 +-
  drivers/net/wireless/wl12xx/wl1271.h               |    3 +-
  drivers/net/wireless/wl12xx/wl1271_boot.c          |    9 ++--
  drivers/net/wireless/wl12xx/wl1271_boot.h          |    1 -
  drivers/net/wireless/wl12xx/wl1271_io.h            |    9 ++-
  drivers/net/wireless/wl12xx/wl1271_main.c          |    4 +-
  drivers/net/wireless/wl12xx/wl1271_sdio.c          |   19 ---
  drivers/net/wireless/wl12xx/wl1271_spi.c           |    8 ++-
  drivers/net/wireless/wl12xx/wl12xx_platform_data.c |   31 +++
  include/linux/spi/wl12xx.h                         |   34 
  include/linux/wl12xx.h                             |   38 ++
  15 files changed, 164 insertions(+), 57 deletions(-)
  create mode 100644 drivers/net/wireless/wl12xx/wl12xx_platform_data.c
  delete mode 100644 include/linux/spi/wl12xx.h
  create mode 100644 include/linux/wl12xx.h


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

Re: [PATCH 00/15] change default_llseek action

2010-09-15 Thread Stephen Rothwell

Hi Arnd,

On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann a...@arndb.de wrote:

 Stephen, please add
 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek

Added from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
s...@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.


pgp7dUZvqlaqH.pgp
Description: PGP signature

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over

2010/9/15 Felipe Balbi ba...@ti.com:
 if request-length == 1MB and dma-max_len = 128KB, when is_dma is true,
 request-actual will be different from request-length for 7
 'iterations', then only on the 8th it will be the same. I believe that's
 what Ming is trying to fix.

 Ming, am I correct ?

Yes, it is the initial motivation of the patch.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hello.

On 15-09-2010 10:53, Felipe Balbi wrote:


If a DMA interrupt comes when the whole transfer is not yet
complete (and
other Ming Lei's patches are making this possible),



Oh, here I mixed some other patch with Ming Lei's ones...



it will pass due to the



than this is the actual problem, no ? If we're using mode1 dma (as we
are on tx path), we should only get dma interrupt when the whole
transfer has been completed.



The Inventra DMA controller has serious DMA length limitation, so the whole
transfer may take more than one DMA.



When I said 'whole transfer' I meant the transfer size you programmed
dma to transfer, see that we have (not actual code):



if (transfer_size  dma-max_len)
transfer_size = dma-max_len;



dma-channel_program(...,..., transfer_size,...);


   Ah, I didn't mean the same thing -- I meant the transfer size as specified 
by 'struct usb_request'.



with mode1, we will only get irq when dma has transferred transfer_size
bytes.


   Sure.


likewise, this was there before the patch. I don't think the real
problem lies with this patch, it's been there for a while, don't you
agree ?



Then what problem this patch fixes, if not this one?



if request-length == 1MB and dma-max_len = 128KB, when is_dma is true,
request-actual will be different from request-length for 7
'iterations', then only on the 8th it will be the same. I believe that's
what Ming is trying to fix.


   I repeat once again: it's too late to check this where Ming is inserting 
the check.



Ming, am I correct ?


Let me repeat: in the PIO mode the added check is just duplicate, in the DMA



it is duplicate for PIO, but not for DMA.


   I didn't say it was duplicate for DMA, just too late.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hi,

On Wed, Sep 15, 2010 at 05:01:05AM -0500, Sergei Shtylyov wrote:

   I didn't say it was duplicate for DMA, just too late.


how come ? we need to send ZLP before giving back the request.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hello.

On 15-09-2010 14:05, Felipe Balbi wrote:


I didn't say it was duplicate for DMA, just too late.



how come ? we need to send ZLP before giving back the request.


   Well, look at the code ionce again. We need to send ZLP *after* 
request-actual == request-length, but as the check is inserted after the ZLP 
send, ZLP *may* be sent once the first DMA completes, not the last.


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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over

2010/9/15 Sergei Shtylyov sshtyl...@mvista.com:
 Hello.

 On 15-09-2010 14:05, Felipe Balbi wrote:

 I didn't say it was duplicate for DMA, just too late.

 how come ? we need to send ZLP before giving back the request.

   Well, look at the code ionce again. We need to send ZLP *after*
 request-actual == request-length, but as the check is inserted after the
 ZLP send, ZLP *may* be sent once the first DMA completes, not the last.

Yes, it is really a problem, as said by balbi.  And the problem should be
in the check for zlp or the 'is_dma' condition.

But this patch is not addressed for the zlp problem, and is is only for
completing the request only if the data transfer in usb_request
is over, as explained before, right?

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hello.

On 15-09-2010 14:14, Ming Lei wrote:


I didn't say it was duplicate for DMA, just too late.



how come ? we need to send ZLP before giving back the request.



   Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is inserted after the
ZLP send, ZLP *may* be sent once the first DMA completes, not the last.



Yes, it is really a problem, as said by balbi.  And the problem should be
in the check for zlp or the 'is_dma' condition.



But this patch is not addressed for the zlp problem, and is is only for
completing the request only if the data transfer in usb_request
is over, as explained before, right?


   I don't see why we should fix only this problem, while it's obvious tha 
the fix is incomplete and leaves the other problem exposed. Please recast the 
patch.


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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hi,

On Wed, Sep 15, 2010 at 05:18:47AM -0500, Sergei Shtylyov wrote:

   I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast the
patch.


IMO, the ZLP fix is *another* fix and as such subject to a different
patch.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


On 15.09.2010 14:22, Felipe Balbi wrote:


I don't see why we should fix only this problem, while it's obvious tha
the fix is incomplete and leaves the other problem exposed. Please recast the
patch.



IMO, the ZLP fix is *another* fix and as such subject to a different
patch.


   IMHO, this fix as it is now is quite stupid. It's clear that the check is 
misplaced and will be removed once the ZLP fix is done. So why not do it once 
and for all? Is it so hard to do? FWIW, I NAK this patch as it is now.


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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hi,

On Wed, Sep 15, 2010 at 05:27:37AM -0500, Sergei Shtylyov wrote:

   IMHO, this fix as it is now is quite stupid. It's clear that the check is
misplaced and will be removed once the ZLP fix is done. So why not do it once


your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer, so that check will have to
stay where it is.


and for all? Is it so hard to do? FWIW, I NAK this patch as it is now.


ok, but I don't.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over

2010/9/15 Sergei Shtylyov sshtyl...@mvista.com:
 On 15.09.2010 14:22, Felipe Balbi wrote:

 I don't see why we should fix only this problem, while it's obvious tha
 the fix is incomplete and leaves the other problem exposed. Please recast
 the
 patch.

 IMO, the ZLP fix is *another* fix and as such subject to a different
 patch.

   IMHO, this fix as it is now is quite stupid. It's clear that the check is
 misplaced and will be removed once the ZLP fix is done. So why not do it
 once and for all? Is it so hard to do? FWIW, I NAK this patch as it is now.

Maybe we should open a new thread to discuss the ZLP fix, I'll do it later.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hello.

On 15-09-2010 14:31, Felipe Balbi wrote:


IMHO, this fix as it is now is quite stupid. It's clear that the check is
misplaced and will be removed once the ZLP fix is done. So why not do it once



your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,


   So what?


so that check will have to stay where it is.


   I don't see how these two are connected at all.

 and for all? Is it so hard to do? FWIW, I NAK this patch as it is now.

 ok, but I don't.

   Well, you're the maintainer.

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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Hi,

On Wed, Sep 15, 2010 at 05:41:39AM -0500, Sergei Shtylyov wrote:

your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,


   So what?


what you're saying is that when we change the ZLP handling, the
request-actual == request-lenght check will have to be removed, but
that's not true because ZLP is only needed if request-zero is set.

So the final code would be something like (pseudo-code):

if (request-lenght % musb_ep-packet_sz)
set_last_packet_is_short_flag(musb_request);

if (request-zero || last_packet_is_short(request)) {
set_txpktrdy(musb);
set_musb_request_completed_flag(musb_request);
return;
}

if (request-acual == request-length)
musb_g_giveback(musb, request);

restart_ep_if_more_requests(musb_ep);



 ok, but I don't.

   Well, you're the maintainer.


the thing is that this discussion is preventing me from sending me the
other 10 patches to Greg. So either we drop it now and send the exact
same patch (or a similar version) for next -rc or I send them all now.
Since I'm not seeing the problem you're describing I'm more inclined to
send them all.

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

[Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx

Hi All,

In another thread, Sergei pointed out there is a ZLP issue in musb_g_tx:

Sergei Shtylyov sshtyl...@mvista.com wrote:
 Hello.

 On 15-09-2010 14:05, Felipe Balbi wrote:

  I didn't say it was duplicate for DMA, just too late.

  how come ? we need to send ZLP before giving back the request.

 Well, look at the code ionce again. We need to send ZLP *after*
 request-actual == request-length, but as the check is inserted
 after the ZLP send, ZLP *may* be sent once the first DMA completes,
 not the last.

 WBR, Sergei

balbi also confirmed that is is really a problem.

I also have two related questions below for the problem:

1),  why is the check for is_dma needed here?

  if (is_dma || request-actual == request-length) {
   
  }

2), why is a zlp needed in the case below?

  #ifdef CONFIG_USB_INVENTRA_DMA
  || (is_dma  (!dma-desired_mode ||
 (request-actual  (musb_ep-packet_sz - 1
 #endif

Seems no request-zero is set to ask for zlp explicitly in
the case above.

IMO, it is not difficult to give a good fix for the ZLP problem
if the two questions are clear.

-- 
Lei Ming
--
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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx


Hi,

On Wed, Sep 15, 2010 at 05:53:10AM -0500, Ming Lei wrote:

1),  why is the check for is_dma needed here?

 if (is_dma || request-actual == request-length) {
  
 }


if you programmed dma to request-length (and assuming it worked just
fine) mode1 will only interrupt you when the entire request has been
sent.


2), why is a zlp needed in the case below?

 #ifdef CONFIG_USB_INVENTRA_DMA
 || (is_dma  (!dma-desired_mode ||
(request-actual  (musb_ep-packet_sz - 1
#endif


in that case, it's not a zlp, it's short packet. Inventra will *NOT*
transfer short packets, you need to set txpktrdy by hand to get it
transfered.


IMO, it is not difficult to give a good fix for the ZLP problem
if the two questions are clear.


true, but some re-work needs to be done.

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

Re: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx

2010/9/15 Felipe Balbi ba...@ti.com:
 Hi,

 On Wed, Sep 15, 2010 at 05:53:10AM -0500, Ming Lei wrote:

 1),  why is the check for is_dma needed here?

     if (is_dma || request-actual == request-length) {
          
     }

 if you programmed dma to request-length (and assuming it worked just
 fine) mode1 will only interrupt you when the entire request has been
 sent.

If so, once the dma interrupt comes, will request-actual be same
with request-length in musb_g_tx?  And if it is true, could we remove the
check for 'is_dma'?


 2), why is a zlp needed in the case below?

     #ifdef CONFIG_USB_INVENTRA_DMA
                 || (is_dma  (!dma-desired_mode ||
                    (request-actual  (musb_ep-packet_sz - 1
    #endif

 in that case, it's not a zlp, it's short packet. Inventra will *NOT*
 transfer short packets, you need to set txpktrdy by hand to get it
 transfered.

I see now.


 IMO, it is not difficult to give a good fix for the ZLP problem
 if the two questions are clear.

 true, but some re-work needs to be done.

Thanks for your reply.


-- 
Lei Ming
--
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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx


Hi,

On Wed, Sep 15, 2010 at 06:02:22AM -0500, Ming Lei wrote:

If so, once the dma interrupt comes, will request-actual be same
with request-length in musb_g_tx?  And if it is true, could we remove the
check for 'is_dma'?


see that is_dma is set to true by just checking if dma in enabled in
txcsr, it might be that dma didn't complete everything and you need to
write txpktrdy by hand to send last short packet. So to remove that you
would need to re-work a bit more code.

You need to know when this is a dma IRQ or an endpoint IRQ.

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

Re: [PATCH v5 0/7] native wl1271 support on ZOOM

2010-09-15 Thread Vitaly Wool

On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 This patchset adds wl1271 support on ZOOM2/3 boards.

 Tony, John, let me please suggest merging this through the wireless tree.

 wl1271 is a moving target - it keeps changing in the wireless tree and
 merging this patchset there will allow wl1271 developers to have
 everything in a single tree (and prevent merge conflicts in
 linux-next).

Thanks Ohad, that's what I was about to suggest as well. :)

Thanks,
   Vitaly
--
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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx

2010/9/15 Felipe Balbi ba...@ti.com:


 IMO, it is not difficult to give a good fix for the ZLP problem
 if the two questions are clear.

 true, but some re-work needs to be done.

I suggest we do the fix for ZLP issue in a new patch against the
current patch set to avoid the rework. More importantly, it is one
another fix, we should insist on the rule: do one fix in one commit,
which is very helpful to do version management(regression test,
bisect...).

-- 
Lei Ming
--
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 2/2] OMAP: DSS2: Use dss_features framework on DSS2 code

2010-09-15 Thread Taneja, Archit

Hi,

I was reworking some patches, I saw 2 functions in manager.c:

dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() both
define the var enum omap_channel channel; but don't use it.

Is there any reason this is done, or is it just stray code?

Tomi Valkeinen wrote:
 On Mon, 2010-09-13 at 07:30 +0200, ext Archit Taneja wrote:
 Calls init functions of dss_features during dss_probe, and the
 following features are made omap independent:
   - number of managers, overlays
   - supported color modes for each overlay
   - supported displays for each manager
   - global aplha, and restriction of global alpha for video1 pipeline
   - The register field ranges : FIRHINC, FIRVINC, FIFOHIGHTHRESHOLD
 FIFOLOWTHRESHOLD and FIFOSIZE
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  arch/arm/plat-omap/include/plat/display.h |   31 
  drivers/video/omap2/dss/core.c|3 ++
  drivers/video/omap2/dss/dispc.c   |   56
  - drivers/video/omap2/dss/manager.c |  
  33 - drivers/video/omap2/dss/overlay.c |   24
  +--- 5 files changed, 60 insertions(+), 87 deletions(-)
 
 snip
 
  static void _dispc_setup_global_alpha(enum omap_plane plane, u8
 global_alpha)  { -
 -   BUG_ON(plane == OMAP_DSS_VIDEO1);
 -
 -   if (cpu_is_omap24xx())
 +   if (!dss_has_feature(FEAT_GLOBAL_ALPHA))
 return;
 
 +   BUG_ON(!dss_has_feature(FEAT_GLOBAL_ALPHA_VID1) 
 +   plane == OMAP_DSS_VIDEO1);
 +
 if (plane == OMAP_DSS_GFX)
 REG_FLD_MOD(DISPC_GLOBAL_ALPHA, global_alpha, 7, 0);
 else if (plane == OMAP_DSS_VIDEO2) @@ -949,17 +950,14 @@
 static void dispc_read_plane_fifo_sizes(void)
 
 DISPC_VID_FIFO_SIZE_STATUS(1) };
 u32 size;
 int plane;
 +   u8 size1, size2;
 
 You have a bit inconsistent naming with these. The function
 is defined as accepting start and end, here you use size1 and size2, below
 you have foo1 and foo2.
 
 Size is not a good name, as it's not size at all. Perhaps
 foo_start and foo_end (or just start and end if there's only
 one feat being used)? Or foo_msb and foo_lsb (as in most/least significant
 bit)? 
 
 Otherwise looks good.
 
  Tomi--
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 2/2] OMAP: DSS2: Use dss_features framework on DSS2 code

2010-09-15 Thread Tomi Valkeinen

On Wed, 2010-09-15 at 13:34 +0200, ext Taneja, Archit wrote:
 Hi,
 
 I was reworking some patches, I saw 2 functions in manager.c:
 
 dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() both
 define the var enum omap_channel channel; but don't use it.
 
 Is there any reason this is done, or is it just stray code?

Looks like leftovers from some earlier version...

 Tomi


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

Re: [RESEND/PATCH 5/6] USB: musb-gadget: complete request only if data is transfered over


Felipe Balbi wrote:


your forgetting the fact that not always you need to send ZLP after
completing a packet_size-aligned transfer,



   So what?



what you're saying is that when we change the ZLP handling, the
request-actual == request-lenght check will have to be removed, but
that's not true because ZLP is only needed if request-zero is set.



So the final code would be something like (pseudo-code):



if (request-lenght % musb_ep-packet_sz)
set_last_packet_is_short_flag(musb_request);



if (request-zero || last_packet_is_short(request)) {
set_txpktrdy(musb);
set_musb_request_completed_flag(musb_request);
return;
}



if (request-acual == request-length)
musb_g_giveback(musb, request);



restart_ep_if_more_requests(musb_ep);


   No, this code will still send ZLP before the whole requested transfer is 
done. The (request-actual == request-length) check is needed before we even 
check that request-zero is set (and it is there but not for the DMA case). I 
thought that this was quite obvious, and I was surprised that this caused such a 
lengthy discussion.


WBR, Sergei
--
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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx


Ming Lei wrote:

Hi All,



In another thread, Sergei pointed out there is a ZLP issue in musb_g_tx:



Sergei Shtylyov sshtyl...@mvista.com wrote:

Hello.



On 15-09-2010 14:05, Felipe Balbi wrote:



I didn't say it was duplicate for DMA, just too late.



how come ? we need to send ZLP before giving back the request.



Well, look at the code ionce again. We need to send ZLP *after*
request-actual == request-length, but as the check is inserted
after the ZLP send, ZLP *may* be sent once the first DMA completes,
not the last.



WBR, Sergei



balbi also confirmed that is is really a problem.



I also have two related questions below for the problem:



1),  why is the check for is_dma needed here?



  if (is_dma || request-actual == request-length) {
   
  }


   I'm not sure -- it seems erratic.


2), why is a zlp needed in the case below?

  #ifdef CONFIG_USB_INVENTRA_DMA
  || (is_dma  (!dma-desired_mode ||
 (request-actual  (musb_ep-packet_sz - 1
 #endif



Seems no request-zero is set to ask for zlp explicitly in
the case above.


   This is not for ZLP -- this is here to set TXPktRdy for the last short 
packet in the Inventra DMA mode 0 that doesn't set TXPktRdy in such case.



IMO, it is not difficult to give a good fix for the ZLP problem
if the two questions are clear.


WBR, Sergei

--
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: [Discussion] USB: musb-gadget: how to fix ZLP issue in musb_g_tx


Hello.

Felipe Balbi wrote:


On Wed, Sep 15, 2010 at 06:02:22AM -0500, Ming Lei wrote:

If so, once the dma interrupt comes, will request-actual be same
with request-length in musb_g_tx?  And if it is true, could we remove 
the

check for 'is_dma'?



see that is_dma is set to true by just checking if dma in enabled in
txcsr, it might be that dma didn't complete everything and you need to
write txpktrdy by hand to send last short packet. So to remove that you
would need to re-work a bit more code.


   I don't see what to rework. The last short packet should still satisfy 
(request-actual == request-length) condition, no?



You need to know when this is a dma IRQ or an endpoint IRQ.


   We know that -- but why check it there, before (request-actual == 
request-length)?


WBR, Sergei
--
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 v5 0/7] native wl1271 support on ZOOM

2010-09-15 Thread John W. Linville

On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote:
 On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen o...@wizery.com wrote:
  On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen o...@wizery.com wrote:
  This patchset adds wl1271 support on ZOOM2/3 boards.
 
  Tony, John, let me please suggest merging this through the wireless tree.
 
  wl1271 is a moving target - it keeps changing in the wireless tree and
  merging this patchset there will allow wl1271 developers to have
  everything in a single tree (and prevent merge conflicts in
  linux-next).
 
 Thanks Ohad, that's what I was about to suggest as well. :)

OK, that is fine with me if the omap folks agree?

John
-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
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: OMAP3 DSP MMU fault + off mode issue

2010-09-15 Thread venki kaps

On Tue, Sep 14, 2010 at 8:54 PM, venki kaps venkiece2...@gmail.com wrote:
 On Tue, Sep 14, 2010 at 1:28 AM, venki kaps venkiece2...@gmail.com wrote:
 Dear all,

 I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 2.6.32).

 The issue is describing as below mentioned way,
        1). The Device is getting DSP MMU Fault when playing MP4 video clip.

 The system is not hitting off mode in the below scenario,
        2). System boot -play mp4 clip -DSP MMU Fault - allow off
 mode --- Never hits off mode

 But surprisingly the system is hitting off mode in the below scenario,
       3). System boot -allow off mode -play mp4 clip -DSP MMU
 Fault - allow off mode --- perfectly works


  - Could you please describe the root cause about the above issues 1  2?
  - How could solve the above issues?

 I have found the issue with UART3.
 In System configuration register (SYSC),-
             IDLEMODE  - Smart idle --- working scenario  --
 system hits off mode.
             IDLEMODE  - No idle --- Non working scenario
 -- system never hits off mode.

 Could you please explain why UART3 is not able to hit smart idle after
 DSP MMU fault ( System boot -play mp4 clip -DSP MMU Fault - allow
 off --- Never hits off mode).,

My problem is resolved.GPtimer7 was not reset during the MMU FAULT
occurrence before the first power cycle.
So this pending interrupt is preventing the system sleep entry.
Now it works fine after resetting Gptimer7 in pm suspend path.

 Thanks in advance.

 Best Regards,
 Venkii


--
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 0/2] OMAP: DSS2: Framework to handle omap version specific DSS features

2010-09-15 Thread arc...@ti.com

From: Archit Taneja arc...@ti.com

This is a simple approach to prevent scattered cpu_is_omap checks
in DSS2 by bringing all omap version specific DSS features/values to one
single place, initialize them and expose a set of functions to DSS2 driver
files which return the value/existance of a feature.

This method provides the following:
  -A set of functions which give the value of a feature.
  -Functions which add and return the start and end bits of a register field
   which varies across omaps.
  -A function which checks if a DSS2 feature exists or not on the present
   omap (omap_dss_has_feature)

Whenever a new DSS feature is introduced, its value/existance is specified
for all omaps in omap_dss_feature_init().

This patch also fills up a minimal list of features in omap_dss_features_init().
The second patch in the series makes use of dss_features to remove some of the
existing omap checks.

Archit Taneja (2):
  OMAP: DSS2: Introduce dss_features files
  OMAP: DSS2: Use dss_features framework on DSS2 code

 arch/arm/plat-omap/include/plat/display.h |   31 -
 drivers/video/omap2/dss/Makefile  |2 +-
 drivers/video/omap2/dss/core.c|3 +
 drivers/video/omap2/dss/dispc.c   |   56 +
 drivers/video/omap2/dss/dss_features.c|  191 +
 drivers/video/omap2/dss/dss_features.h|   50 
 drivers/video/omap2/dss/manager.c |   33 +++---
 drivers/video/omap2/dss/overlay.c |   24 ++--
 8 files changed, 302 insertions(+), 88 deletions(-)
 create mode 100644 drivers/video/omap2/dss/dss_features.c
 create mode 100644 drivers/video/omap2/dss/dss_features.h
--
Version 4:
 - all dss_features members are made const, better naming of some
   vaiables
Version 3:
 - Naming of register fields enums is changed, dss_features struct
   has some members changed as pointers to static arrays.
Version 2:
 - Features are initialized statically as opposed to runtime before,
   function naming for dss_features files has changed.
Version 1:
https://patchwork.kernel.org/patch/134431/
--
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 1/2] OMAP: DSS2: Introduce dss_features files

2010-09-15 Thread arc...@ti.com

From: Archit Taneja arc...@ti.com

Add dss_features.c and dss_features.h for the dss_features framework

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/Makefile   |2 +-
 drivers/video/omap2/dss/dss_features.c |  191 
 drivers/video/omap2/dss/dss_features.h |   50 
 3 files changed, 242 insertions(+), 1 deletions(-)
 create mode 100644 drivers/video/omap2/dss/dss_features.c
 create mode 100644 drivers/video/omap2/dss/dss_features.h

diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d71b5d9..7db17b5
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_OMAP2_DSS) += omapdss.o
-omapdss-y := core.o dss.o dispc.o display.o manager.o overlay.o
+omapdss-y := core.o dss.o dss_features.o dispc.o display.o manager.o overlay.o
 omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
 omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
 omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
new file mode 100644
index 000..867f68d
--- /dev/null
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -0,0 +1,191 @@
+/*
+ * linux/drivers/video/omap2/dss/dss_features.c
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Archit Taneja arc...@ti.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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/display.h
+#include plat/cpu.h
+
+#include dss_features.h
+
+/* Defines a generic omap register field */
+struct dss_reg_field {
+   enum dss_feat_reg_field id;
+   u8 start, end;
+};
+
+struct omap_dss_features {
+   const struct dss_reg_field *reg_fields;
+   const int num_reg_fields;
+
+   const u32 has_feature;
+
+   const int num_mgrs;
+   const int num_ovls;
+   const enum omap_display_type *supported_displays;
+   const enum omap_color_mode *supported_color_modes;
+};
+
+/* This struct is assigned to one of the below during initialization */
+static struct omap_dss_features *omap_current_dss_features;
+
+static const struct dss_reg_field omap2_dss_reg_fields[] = {
+   { FEAT_REG_FIRHINC, 11, 0 },
+   { FEAT_REG_FIRVINC, 27, 16 },
+   { FEAT_REG_FIFOLOWTHRESHOLD, 8, 0 },
+   { FEAT_REG_FIFOHIGHTHRESHOLD, 24, 16 },
+   { FEAT_REG_FIFOSIZE, 8, 0 },
+};
+
+static const struct dss_reg_field omap3_dss_reg_fields[] = {
+   { FEAT_REG_FIRHINC, 12, 0 },
+   { FEAT_REG_FIRVINC, 28, 16 },
+   { FEAT_REG_FIFOLOWTHRESHOLD, 11, 0 },
+   { FEAT_REG_FIFOHIGHTHRESHOLD, 27, 16 },
+   { FEAT_REG_FIFOSIZE, 10, 0 },
+};
+
+static const enum omap_display_type omap2_dss_supported_displays[] = {
+   /* OMAP_DSS_CHANNEL_LCD */
+   OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+   OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
+
+   /* OMAP_DSS_CHANNEL_DIGIT */
+   OMAP_DISPLAY_TYPE_VENC,
+};
+
+static const enum omap_display_type omap3_dss_supported_displays[] = {
+   /* OMAP_DSS_CHANNEL_LCD */
+   OMAP_DISPLAY_TYPE_DPI | OMAP_DISPLAY_TYPE_DBI |
+   OMAP_DISPLAY_TYPE_SDI | OMAP_DISPLAY_TYPE_DSI,
+
+   /* OMAP_DSS_CHANNEL_DIGIT */
+   OMAP_DISPLAY_TYPE_VENC,
+};
+
+static const enum omap_color_mode omap2_dss_supported_color_modes[] = {
+   /* OMAP_DSS_GFX */
+   OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
+   OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
+   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
+   OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P,
+
+   /* OMAP_DSS_VIDEO1 */
+   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
+   OMAP_DSS_COLOR_UYVY,
+
+   /* OMAP_DSS_VIDEO2 */
+   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
+   OMAP_DSS_COLOR_UYVY,
+};
+
+static const enum omap_color_mode omap3_dss_supported_color_modes[] = {
+   /* OMAP_DSS_GFX */
+   OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
+   OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
+   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16 |
+   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
+   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_ARGB32 |
+   OMAP_DSS_COLOR_RGBA32 | OMAP_DSS_COLOR_RGBX32,
+
+   /*

[PATCH v4 2/2] OMAP: DSS2: Use dss_features framework on DSS2 code

2010-09-15 Thread arc...@ti.com

From: Archit Taneja arc...@ti.com

Calls init functions of dss_features during dss_probe, and the following
features are made omap independent:
  - number of managers, overlays
  - supported color modes for each overlay
  - supported displays for each manager
  - global aplha, and restriction of global alpha for video1 pipeline
  - The register field ranges : FIRHINC, FIRVINC, FIFOHIGHTHRESHOLD
FIFOLOWTHRESHOLD and FIFOSIZE

Signed-off-by: Archit Taneja arc...@ti.com
---
 arch/arm/plat-omap/include/plat/display.h |   31 
 drivers/video/omap2/dss/core.c|3 ++
 drivers/video/omap2/dss/dispc.c   |   56 -
 drivers/video/omap2/dss/manager.c |   33 -
 drivers/video/omap2/dss/overlay.c |   24 +---
 5 files changed, 60 insertions(+), 87 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/display.h 
b/arch/arm/plat-omap/include/plat/display.h
index 8bd15bd..c915a66
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -81,37 +81,6 @@ enum omap_color_mode {
OMAP_DSS_COLOR_ARGB32   = 1  11, /* ARGB32 */
OMAP_DSS_COLOR_RGBA32   = 1  12, /* RGBA32 */
OMAP_DSS_COLOR_RGBX32   = 1  13, /* RGBx32 */
-
-   OMAP_DSS_COLOR_GFX_OMAP2 =
-   OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
-   OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
-   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
-   OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P,
-
-   OMAP_DSS_COLOR_VID_OMAP2 =
-   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
-   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
-   OMAP_DSS_COLOR_UYVY,
-
-   OMAP_DSS_COLOR_GFX_OMAP3 =
-   OMAP_DSS_COLOR_CLUT1 | OMAP_DSS_COLOR_CLUT2 |
-   OMAP_DSS_COLOR_CLUT4 | OMAP_DSS_COLOR_CLUT8 |
-   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16 |
-   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
-   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_ARGB32 |
-   OMAP_DSS_COLOR_RGBA32 | OMAP_DSS_COLOR_RGBX32,
-
-   OMAP_DSS_COLOR_VID1_OMAP3 =
-   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_RGB16 |
-   OMAP_DSS_COLOR_RGB24U | OMAP_DSS_COLOR_RGB24P |
-   OMAP_DSS_COLOR_YUV2 | OMAP_DSS_COLOR_UYVY,
-
-   OMAP_DSS_COLOR_VID2_OMAP3 =
-   OMAP_DSS_COLOR_RGB12U | OMAP_DSS_COLOR_ARGB16 |
-   OMAP_DSS_COLOR_RGB16 | OMAP_DSS_COLOR_RGB24U |
-   OMAP_DSS_COLOR_RGB24P | OMAP_DSS_COLOR_YUV2 |
-   OMAP_DSS_COLOR_UYVY | OMAP_DSS_COLOR_ARGB32 |
-   OMAP_DSS_COLOR_RGBA32 | OMAP_DSS_COLOR_RGBX32,
 };
 
 enum omap_lcd_display_type {
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b3a498f..8e89f60
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -37,6 +37,7 @@
 #include plat/clock.h
 
 #include dss.h
+#include dss_features.h
 
 static struct {
struct platform_device *pdev;
@@ -502,6 +503,8 @@ static int omap_dss_probe(struct platform_device *pdev)
 
core.pdev = pdev;
 
+   dss_features_init();
+
dss_init_overlay_managers(pdev);
dss_init_overlays(pdev);
 
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 90eb110..fa40fa5
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -39,6 +39,7 @@
 #include plat/display.h
 
 #include dss.h
+#include dss_features.h
 
 /* DISPC */
 #define DISPC_BASE 0x48050400
@@ -774,12 +775,12 @@ static void _dispc_set_vid_size(enum omap_plane plane, 
int width, int height)
 
 static void _dispc_setup_global_alpha(enum omap_plane plane, u8 global_alpha)
 {
-
-   BUG_ON(plane == OMAP_DSS_VIDEO1);
-
-   if (cpu_is_omap24xx())
+   if (!dss_has_feature(FEAT_GLOBAL_ALPHA))
return;
 
+   BUG_ON(!dss_has_feature(FEAT_GLOBAL_ALPHA_VID1) 
+   plane == OMAP_DSS_VIDEO1);
+
if (plane == OMAP_DSS_GFX)
REG_FLD_MOD(DISPC_GLOBAL_ALPHA, global_alpha, 7, 0);
else if (plane == OMAP_DSS_VIDEO2)
@@ -949,17 +950,14 @@ static void dispc_read_plane_fifo_sizes(void)
  DISPC_VID_FIFO_SIZE_STATUS(1) };
u32 size;
int plane;
+   u8 start, end;
 
enable_clocks(1);
 
-   for (plane = 0; plane  ARRAY_SIZE(dispc.fifo_size); ++plane) {
-   if (cpu_is_omap24xx())
-   size = FLD_GET(dispc_read_reg(fsz_reg[plane]), 8, 0);
-   else if (cpu_is_omap34xx())
-   size = FLD_GET(dispc_read_reg(fsz_reg[plane]), 10, 0);
-   else
-   BUG();
+   dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
 
+   for (plane = 0; plane  ARRAY_SIZE(dispc.fifo_size); ++plane) {
+

[PATCH v4 01/10] net: davinci_emac: separate out davinci mdio

Davinci's MDIO controller is present on other TI devices, without an
accompanying EMAC.  For example, on tnetv107x, the same MDIO module is used in
conjunction with a 3-port switch hardware.

By separating the MDIO controller code into its own platform driver, this
patch allows common logic to be reused on such platforms.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/Kconfig  |   10 +
 drivers/net/Makefile |1 +
 drivers/net/davinci_mdio.c   |  475 ++
 include/linux/davinci_emac.h |4 +
 4 files changed, 490 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/davinci_mdio.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2cc81a5..c5c86e0 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -958,6 +958,16 @@ config TI_DAVINCI_EMAC
  To compile this driver as a module, choose M here: the module
  will be called davinci_emac_driver.  This is recommended.
 
+config TI_DAVINCI_MDIO
+   tristate TI DaVinci MDIO Support
+   depends on ARM  ( ARCH_DAVINCI || ARCH_OMAP3 )
+   select PHYLIB
+   help
+ This driver supports TI's DaVinci MDIO module.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_mdio.  This is recommended.
+
 config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3e8f150..d38a7ab 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_PHYLIB) += phy/
 
 obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
+obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
 
 obj-$(CONFIG_E1000) += e1000/
 obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
new file mode 100644
index 000..7615040
--- /dev/null
+++ b/drivers/net/davinci_mdio.c
@@ -0,0 +1,475 @@
+/*
+ * DaVinci MDIO Module driver
+ *
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ * Shamelessly ripped out of davinci_emac.c, original copyrights follow:
+ *
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * ---
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ * ---
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/phy.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/davinci_emac.h
+
+/*
+ * This timeout definition is a worst-case ultra defensive measure against
+ * unexpected controller lock ups.  Ideally, we should never ever hit this
+ * scenario in practice.
+ */
+#define MDIO_TIMEOUT   100 /* msecs */
+
+#define PHY_REG_MASK   0x1f
+#define PHY_ID_MASK0x1f
+
+#define DEF_OUT_FREQ   220 /* 2.2 MHz */
+
+struct davinci_mdio_regs {
+   u32 version;
+   u32 control;
+#define CONTROL_IDLE   BIT(31)
+#define CONTROL_ENABLE BIT(30)
+#define CONTROL_MAX_DIV(0xff)
+
+   u32 alive;
+   u32 link;
+   u32 linkintraw;
+   u32 linkintmasked;
+   u32 __reserved_0[2];
+   u32 userintraw;
+   u32 userintmasked;
+   u32 userintmaskset;
+   u32 userintmaskclr;
+   u32 __reserved_1[20];
+
+   struct {
+   u32 access;
+#define USERACCESS_GO  BIT(31)
+#define USERACCESS_WRITE   BIT(30)
+#define USERACCESS_ACK BIT(29)
+#define USERACCESS_READ(0)
+#define USERACCESS_DATA(0x)
+
+   u32 physel;
+   }   user[0];
+};
+
+struct mdio_platform_data default_pdata = {
+   .bus_freq = DEF_OUT_FREQ,
+};
+
+struct davinci_mdio_data {
+   struct mdio_platform_data pdata;
+   struct davinci_mdio_regs __iomem *regs;
+   spinlock_t  lock;
+   struct clk  *clk;
+   struct device   *dev;
+   struct mii_bus  *bus;

[PATCH v4 03/10] omap: add mdio platform devices

This patch adds mdio platform devices on SoCs that have the necessary
hardware.  Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock.  Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-am3517evm.c |   27 ++-
 1 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 4d0f585..5dd1b73 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -18,6 +18,7 @@
 
 #include linux/kernel.h
 #include linux/init.h
+#include linux/clk.h
 #include linux/platform_device.h
 #include linux/gpio.h
 #include linux/i2c/pca953x.h
@@ -41,6 +42,27 @@
 #define AM35XX_EVM_PHY_MASK(0xF)
 #define AM35XX_EVM_MDIO_FREQUENCY  (100)
 
+static struct mdio_platform_data am3517_evm_mdio_pdata = {
+   .bus_freq   = AM35XX_EVM_MDIO_FREQUENCY,
+};
+
+static struct resource am3517_mdio_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET,
+   .end= AM35XX_IPSS_EMAC_BASE + AM35XX_EMAC_MDIO_OFFSET +
+ SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device am3517_mdio_device = {
+   .name   = davinci_mdio,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(am3517_mdio_resources),
+   .resource   = am3517_mdio_resources,
+   .dev.platform_data = am3517_evm_mdio_pdata,
+};
+
 static struct emac_platform_data am3517_evm_emac_pdata = {
.phy_mask   = AM35XX_EVM_PHY_MASK,
.mdio_max_freq  = AM35XX_EVM_MDIO_FREQUENCY,
@@ -50,7 +72,7 @@ static struct emac_platform_data am3517_evm_emac_pdata = {
 static struct resource am3517_emac_resources[] = {
{
.start  = AM35XX_IPSS_EMAC_BASE,
-   .end= AM35XX_IPSS_EMAC_BASE + 0x3,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x2,
.flags  = IORESOURCE_MEM,
},
{
@@ -121,6 +143,9 @@ void am3517_evm_ethernet_init(struct emac_platform_data 
*pdata)
pdata-interrupt_disable= am3517_disable_ethernet_int;
am3517_emac_device.dev.platform_data= pdata;
platform_device_register(am3517_emac_device);
+   platform_device_register(am3517_mdio_device);
+   clk_add_alias(NULL, dev_name(am3517_mdio_device.dev),
+ NULL, am3517_emac_device.dev);
 
regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
regval = regval  (~(AM35XX_CPGMACSS_SW_RST));
-- 
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

[PATCH v4 07/10] net: davinci_emac: cleanup unused mdio emac code

This patch removes code that has been rendered useless by the previous patches
in this series.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/davinci_emac.c   |  107 --
 include/linux/davinci_emac.h |3 -
 2 files changed, 0 insertions(+), 110 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 997f599..d4298cb 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -113,7 +113,6 @@ static const char emac_version_string[] = TI DaVinci EMAC 
Linux v6.1;
 #define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
 #define EMAC_DEF_TX_CH (0) /* Default 0th channel */
 #define EMAC_DEF_RX_CH (0) /* Default 0th channel */
-#define EMAC_DEF_MDIO_TICK_MS  (10) /* typically 1 tick=1 ms) */
 #define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
 #define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
 #define EMAC_POLL_WEIGHT   (64) /* Default NAPI poll weight */
@@ -303,25 +302,6 @@ static const char emac_version_string[] = TI DaVinci EMAC 
Linux v6.1;
 #define EMAC_DM644X_INTMIN_INTVL   0x1
 #define EMAC_DM644X_INTMAX_INTVL   (EMAC_DM644X_EWINTCNT_MASK)
 
-/* EMAC MDIO related */
-/* Mask  Control defines */
-#define MDIO_CONTROL_CLKDIV(0xFF)
-#define MDIO_CONTROL_ENABLEBIT(30)
-#define MDIO_USERACCESS_GO BIT(31)
-#define MDIO_USERACCESS_WRITE  BIT(30)
-#define MDIO_USERACCESS_READ   (0)
-#define MDIO_USERACCESS_REGADR (0x1F  21)
-#define MDIO_USERACCESS_PHYADR (0x1F  16)
-#define MDIO_USERACCESS_DATA   (0x)
-#define MDIO_USERPHYSEL_LINKSELBIT(7)
-#define MDIO_VER_MODID (0x  16)
-#define MDIO_VER_REVMAJ(0xFF8)
-#define MDIO_VER_REVMIN(0xFF)
-
-#define MDIO_USERACCESS(inst)  (0x80 + (inst * 8))
-#define MDIO_USERPHYSEL(inst)  (0x84 + (inst * 8))
-#define MDIO_CONTROL   (0x04)
-
 /* EMAC DM646X control module registers */
 #define EMAC_DM646X_CMINTCTRL  0x0C
 #define EMAC_DM646X_CMRXINTEN  0x14
@@ -493,13 +473,6 @@ struct emac_priv {
u32 mac_hash2;
u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
u32 rx_addr_type;
-   /* periodic timer required for MDIO polling */
-   struct timer_list periodic_timer;
-   u32 periodic_ticks;
-   u32 timer_active;
-   u32 phy_mask;
-   /* mii_bus,phy members */
-   struct mii_bus *mii_bus;
const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
@@ -511,7 +484,6 @@ struct emac_priv {
 /* clock frequency for EMAC */
 static struct clk *emac_clk;
 static unsigned long emac_bus_frequency;
-static unsigned long mdio_max_freq;
 
 #define emac_virt_to_phys(addr, priv) \
(((u32 __force)(addr) - (u32 __force)(priv-emac_ctrl_ram)) \
@@ -549,9 +521,6 @@ static char *emac_rxhost_errcodes[16] = {
 #define emac_ctrl_read(reg)  ioread32((priv-ctrl_base + (reg)))
 #define emac_ctrl_write(reg, val) iowrite32(val, (priv-ctrl_base + (reg)))
 
-#define emac_mdio_read(reg)  ioread32(bus-priv + (reg))
-#define emac_mdio_write(reg, val) iowrite32(val, (bus-priv + (reg)))
-
 /**
  * emac_dump_regs: Dump important EMAC registers to debug terminal
  * @priv: The DaVinci EMAC private adapter structure
@@ -657,9 +626,6 @@ static void emac_dump_regs(struct emac_priv *priv)
emac_read(EMAC_RXDMAOVERRUNS));
 }
 
-/*
- *  EMAC MDIO/Phy Functionality
- */
 /**
  * emac_get_drvinfo: Get EMAC driver information
  * @ndev: The DaVinci EMAC network adapter
@@ -2349,79 +2315,6 @@ void emac_poll_controller(struct net_device *ndev)
 }
 #endif
 
-/* PHY/MII bus related */
-
-/* Wait until mdio is ready for next command */
-#define MDIO_WAIT_FOR_USER_ACCESS\
-   while ((emac_mdio_read((MDIO_USERACCESS(0))) \
-   MDIO_USERACCESS_GO) != 0)
-
-static int emac_mii_read(struct mii_bus *bus, int phy_id, int phy_reg)
-{
-   unsigned int phy_data = 0;
-   unsigned int phy_control;
-
-   /* Wait until mdio is ready for next command */
-   MDIO_WAIT_FOR_USER_ACCESS;
-
-   phy_control = (MDIO_USERACCESS_GO |
-  MDIO_USERACCESS_READ |
-  ((phy_reg  21)  MDIO_USERACCESS_REGADR) |
-  ((phy_id  16)  MDIO_USERACCESS_PHYADR) |
-  (phy_data  MDIO_USERACCESS_DATA));
-   emac_mdio_write(MDIO_USERACCESS(0), phy_control);
-
-   /* Wait until mdio is ready for next command */
-   MDIO_WAIT_FOR_USER_ACCESS;
-
-   return emac_mdio_read(MDIO_USERACCESS(0))  MDIO_USERACCESS_DATA;
-
-}
-
-static

[PATCH v4 09/10] net: davinci_emac: switch to new cpdma layer

This patch hooks up the emac driver with the newly separated cpdma driver.

Key differences introduced here:

 - The old buffer list scheme is no longer required

 - The original code maintained mac address per rx channel, even if only one
   rx channel was being used.  With this change, mac address is maintained
   device wide.  If support for multiple rx channels is added in future, this
   will need to be reworked a bit.

 - The new CPDMA code handles short packets better than before.  The
   earlier code was adjusting the length up, without ensuring that the tail
   end of the padding was cleared - a possible security issue.  This has been
   fixed to use skb_padto().

Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/davinci_emac.c |  249 +---
 1 files changed, 164 insertions(+), 85 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index d4298cb..67dbcfb 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -63,6 +63,8 @@
 #include asm/irq.h
 #include asm/page.h
 
+#include davinci_cpdma.h
+
 static int debug_level;
 module_param(debug_level, int, 0);
 MODULE_PARM_DESC(debug_level, DaVinci EMAC debug level (NETIF_MSG bits));
@@ -113,6 +115,7 @@ static const char emac_version_string[] = TI DaVinci EMAC 
Linux v6.1;
 #define EMAC_DEF_MAX_FRAME_SIZE(1500 + 14 + 4 + 4)
 #define EMAC_DEF_TX_CH (0) /* Default 0th channel */
 #define EMAC_DEF_RX_CH (0) /* Default 0th channel */
+#define EMAC_DEF_RX_NUM_DESC   (128)
 #define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
 #define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
 #define EMAC_POLL_WEIGHT   (64) /* Default NAPI poll weight */
@@ -460,6 +463,9 @@ struct emac_priv {
u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
+   struct cpdma_ctlr *dma;
+   struct cpdma_chan *txchan;
+   struct cpdma_chan *rxchan;
u32 link; /* 1=link on, 0=link off */
u32 speed; /* 0=Auto Neg, 1=No PHY, 10,100, 1000 - mbps */
u32 duplex; /* Link duplex: 0=Half, 1=Full */
@@ -624,6 +630,8 @@ static void emac_dump_regs(struct emac_priv *priv)
emac_read(EMAC_RXMOFOVERRUNS));
dev_info(emac_dev, EMAC: rx_dma_overruns:%d\n,
emac_read(EMAC_RXDMAOVERRUNS));
+
+   cpdma_ctlr_dump(priv-dma);
 }
 
 /**
@@ -1151,6 +1159,70 @@ static irqreturn_t emac_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static struct sk_buff *emac_rx_alloc(struct emac_priv *priv)
+{
+   struct sk_buff *skb = dev_alloc_skb(priv-rx_buf_size);
+   if (WARN_ON(!skb))
+   return NULL;
+   skb-dev = priv-ndev;
+   skb_reserve(skb, NET_IP_ALIGN);
+   return skb;
+}
+
+static void emac_rx_handler(void *token, int len, int status)
+{
+   struct sk_buff  *skb = token;
+   struct net_device   *ndev = skb-dev;
+   struct emac_priv*priv = netdev_priv(ndev);
+   struct device   *emac_dev = ndev-dev;
+   int ret;
+
+   /* free and bail if we are shutting down */
+   if (unlikely(!netif_running(ndev))) {
+   dev_kfree_skb_any(skb);
+   return;
+   }
+
+   /* recycle on recieve error */
+   if (status  0) {
+   ndev-stats.rx_errors++;
+   goto recycle;
+   }
+
+   /* feed received packet up the stack */
+   skb_put(skb, len);
+   skb-protocol = eth_type_trans(skb, ndev);
+   netif_receive_skb(skb);
+   ndev-stats.rx_bytes += len;
+   ndev-stats.rx_packets++;
+
+   /* alloc a new packet for receive */
+   skb = emac_rx_alloc(priv);
+   if (!skb) {
+   if (netif_msg_rx_err(priv)  net_ratelimit())
+   dev_err(emac_dev, failed rx buffer alloc\n);
+   return;
+   }
+
+recycle:
+   ret = cpdma_chan_submit(priv-rxchan, skb, skb-data,
+   skb_tailroom(skb), GFP_KERNEL);
+   if (WARN_ON(ret  0))
+   dev_kfree_skb_any(skb);
+}
+
+static void emac_tx_handler(void *token, int len, int status)
+{
+   struct sk_buff  *skb = token;
+   struct net_device   *ndev = skb-dev;
+
+   if (unlikely(netif_queue_stopped(ndev)))
+   netif_start_queue(ndev);
+   ndev-stats.tx_packets++;
+   ndev-stats.tx_bytes += len;
+   dev_kfree_skb_any(skb);
+}
+
 /** EMAC on-chip buffer descriptor memory
  *
  * WARNING: Please note that the on chip memory is used for both TX and RX
@@ -1532,42 +1604,36 @@ static int emac_dev_xmit(struct sk_buff *skb, struct 
net_device *ndev)
 {
struct device *emac_dev = ndev-dev;
int

[PATCH v4 00/10] split out emac cpdma and mdio for reuse

Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
These hardware modules are not restricted to EMAC device alone.  For example,
CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
internally.  This patch series separates out EMAC's MDIO and CPDMA
functionality, allowing these individual pieces to be reused across TI
hardware.  

This patch series has been broadly organized as follows:

MDIO:
  - Add new functionality
  netdev: separate out davinci mdio controller code
  - Hookup new functionality
  davinci: add mdio platform devices
  omap: add mdio platform devices
  netdev: switch davinci emac to new mdio driver
  - Cleanup left over cruft
  davinci: cleanup unused davinci mdio arch code
  omap: cleanup unused davinci mdio arch code
  netdev: cleanup unused davinci mdio emac code

CPDMA:
  - Add new functionality
 netdev: separate out davinci cpdma controller code
  - Hookup new functionality
 netdev: switch davinci emac to new cpdma layer
  - Cleanup left over cruft
 netdev: cleanup unused davinci emac cpdma code

This series has been tested on dm365 and tnetv107x (with additional cpsw
patches) hardware.  Although am3517 (omap) board support code has been updated
as needed, emac does not work on this platform.

Changes from v1:
  1. Fixed memory leak in cpdma_chan_create() failure case
  2. Included new omap patches for am3517, avoids build breakage

Changes from v2:
  1. Updated series to include mityomapl138 board
  2. Minor white-space fixes

Changes from v3 (rolled in post cpdma/mdio refactoring fixes series):
  1. allow forced 100/full mode instead of phy auto-detect
  2. specify phy_id on boards that had a phy_mask defined earlier
  3. requeue cpdma descriptors when EOQ at submit
  4. use calculated mdio bus access times instead of hardcoded delays
  5. work around emac soft-reset impact on mdio controller state
  6. extend register dumps to include cpdma registers
  7. updated sign offs and acks


Cyril Chemparathy (10):
  net: davinci_emac: separate out davinci mdio
  davinci: add mdio platform devices
  omap: add mdio platform devices
  net: davinci_emac: switch to new mdio
  davinci: cleanup mdio arch code and switch to phy_id
  omap: cleanup unused davinci mdio arch code
  net: davinci_emac: cleanup unused mdio emac code
  net: davinci_emac: separate out cpdma code
  net: davinci_emac: switch to new cpdma layer
  net: davinci_emac: cleanup unused cpdma code

 arch/arm/mach-davinci/board-da830-evm.c |7 +-
 arch/arm/mach-davinci/board-da850-evm.c |7 +-
 arch/arm/mach-davinci/board-dm365-evm.c |7 +-
 arch/arm/mach-davinci/board-dm644x-evm.c|8 +-
 arch/arm/mach-davinci/board-dm646x-evm.c|7 +-
 arch/arm/mach-davinci/board-mityomapl138.c  |8 +-
 arch/arm/mach-davinci/board-neuros-osd2.c   |7 +-
 arch/arm/mach-davinci/board-sffsdr.c|7 +-
 arch/arm/mach-davinci/devices-da8xx.c   |   31 +-
 arch/arm/mach-davinci/dm365.c   |   23 +-
 arch/arm/mach-davinci/dm644x.c  |   23 +-
 arch/arm/mach-davinci/dm646x.c  |   22 +-
 arch/arm/mach-davinci/include/mach/dm365.h  |2 +-
 arch/arm/mach-davinci/include/mach/dm644x.h |2 +-
 arch/arm/mach-davinci/include/mach/dm646x.h |2 +-
 arch/arm/mach-omap2/board-am3517evm.c   |   31 +-
 drivers/net/Kconfig |   21 +
 drivers/net/Makefile|2 +
 drivers/net/davinci_cpdma.c |  965 +++
 drivers/net/davinci_cpdma.h |  108 +++
 drivers/net/davinci_emac.c  | 1338 ---
 drivers/net/davinci_mdio.c  |  475 ++
 include/linux/davinci_emac.h|   16 +-
 23 files changed, 1894 insertions(+), 1225 deletions(-)
 create mode 100644 drivers/net/davinci_cpdma.c
 create mode 100644 drivers/net/davinci_cpdma.h
 create mode 100644 drivers/net/davinci_mdio.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

[PATCH v4 10/10] net: davinci_emac: cleanup unused cpdma code

Having switched over to the newly introduced cpdma layer, this patch now
removes a whole bunch of code that is now unused.  This patch has been
maintained separate strictly for reasons of readability.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/davinci_emac.c |  930 
 1 files changed, 0 insertions(+), 930 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 67dbcfb..2a628d1 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -127,7 +127,6 @@ static const char emac_version_string[] = TI DaVinci EMAC 
Linux v6.1;
 /* EMAC register related defines */
 #define EMAC_ALL_MULTI_REG_VALUE   (0x)
 #define EMAC_NUM_MULTICAST_BITS(64)
-#define EMAC_TEARDOWN_VALUE(0xFFFC)
 #define EMAC_TX_CONTROL_TX_ENABLE_VAL  (0x1)
 #define EMAC_RX_CONTROL_RX_ENABLE_VAL  (0x1)
 #define EMAC_MAC_HOST_ERR_INTMASK_VAL  (0x2)
@@ -214,24 +213,10 @@ static const char emac_version_string[] = TI DaVinci 
EMAC Linux v6.1;
 #define EMAC_DEF_MAX_MULTICAST_ADDRESSES (64) /* Max mcast addr's */
 
 /* EMAC Peripheral Device Register Memory Layout structure */
-#define EMAC_TXIDVER   0x0
-#define EMAC_TXCONTROL 0x4
-#define EMAC_TXTEARDOWN0x8
-#define EMAC_RXIDVER   0x10
-#define EMAC_RXCONTROL 0x14
-#define EMAC_RXTEARDOWN0x18
-#define EMAC_TXINTSTATRAW  0x80
-#define EMAC_TXINTSTATMASKED   0x84
-#define EMAC_TXINTMASKSET  0x88
-#define EMAC_TXINTMASKCLEAR0x8C
 #define EMAC_MACINVECTOR   0x90
 
 #define EMAC_DM646X_MACEOIVECTOR   0x94
 
-#define EMAC_RXINTSTATRAW  0xA0
-#define EMAC_RXINTSTATMASKED   0xA4
-#define EMAC_RXINTMASKSET  0xA8
-#define EMAC_RXINTMASKCLEAR0xAC
 #define EMAC_MACINTSTATRAW 0xB0
 #define EMAC_MACINTSTATMASKED  0xB4
 #define EMAC_MACINTMASKSET 0xB8
@@ -258,12 +243,6 @@ static const char emac_version_string[] = TI DaVinci EMAC 
Linux v6.1;
 #define EMAC_MACADDRHI 0x504
 #define EMAC_MACINDEX  0x508
 
-/* EMAC HDP and Completion registors */
-#define EMAC_TXHDP(ch) (0x600 + (ch * 4))
-#define EMAC_RXHDP(ch) (0x620 + (ch * 4))
-#define EMAC_TXCP(ch)  (0x640 + (ch * 4))
-#define EMAC_RXCP(ch)  (0x660 + (ch * 4))
-
 /* EMAC statistics registers */
 #define EMAC_RXGOODFRAMES  0x200
 #define EMAC_RXBCASTFRAMES 0x204
@@ -328,120 +307,6 @@ static const char emac_version_string[] = TI DaVinci 
EMAC Linux v6.1;
 /* EMAC Stats Clear Mask */
 #define EMAC_STATS_CLR_MASK(0x)
 
-/** net_buf_obj: EMAC network bufferdata structure
- *
- * EMAC network buffer data structure
- */
-struct emac_netbufobj {
-   void *buf_token;
-   char *data_ptr;
-   int length;
-};
-
-/** net_pkt_obj: EMAC network packet data structure
- *
- * EMAC network packet data structure - supports buffer list (for future)
- */
-struct emac_netpktobj {
-   void *pkt_token; /* data token may hold tx/rx chan id */
-   struct emac_netbufobj *buf_list; /* array of network buffer objects */
-   int num_bufs;
-   int pkt_length;
-};
-
-/** emac_tx_bd: EMAC TX Buffer descriptor data structure
- *
- * EMAC TX Buffer descriptor data structure
- */
-struct emac_tx_bd {
-   int h_next;
-   int buff_ptr;
-   int off_b_len;
-   int mode; /* SOP, EOP, ownership, EOQ, teardown,Qstarv, length */
-   struct emac_tx_bd __iomem *next;
-   void *buf_token;
-};
-
-/** emac_txch: EMAC TX Channel data structure
- *
- * EMAC TX Channel data structure
- */
-struct emac_txch {
-   /* Config related */
-   u32 num_bd;
-   u32 service_max;
-
-   /* CPPI specific */
-   u32 alloc_size;
-   void __iomem *bd_mem;
-   struct emac_tx_bd __iomem *bd_pool_head;
-   struct emac_tx_bd __iomem *active_queue_head;
-   struct emac_tx_bd __iomem *active_queue_tail;
-   struct emac_tx_bd __iomem *last_hw_bdprocessed;
-   u32 queue_active;
-   u32 teardown_pending;
-   u32 *tx_complete;
-
-   /** statistics */
-   u32 proc_count; /* TX: # of times emac_tx_bdproc is called */
-   u32 mis_queued_packets;
-   u32 queue_reinit;
-   u32 end_of_queue_add;
-   u32 out_of_tx_bd;
-   u32 no_active_pkts; /* IRQ when there were no packets to process */
-   u32 active_queue_count;
-};
-
-/** emac_rx_bd: EMAC RX Buffer descriptor data structure
- *
- * EMAC RX Buffer descriptor data structure
- */
-struct emac_rx_bd {
-   int h_next;
-   int buff_ptr;
-   int off_b_len;
-   int mode;
-   struct emac_rx_bd __iomem *next;
-   void *data_ptr;
-   void *buf_token;
-};
-
-/** emac_rxch: EMAC RX Channel data structure
- *
- * EMAC RX Channel data structure
- */
-struct

[PATCH v4 04/10] net: davinci_emac: switch to new mdio

This patch switches the emac implementation over to the newly separated
MDIO driver.

With this, the mdio bus frequency defaults to a safe 2.2MHz.  Boards may
optionally specify a bus frequency via platform data.

The phy identification scheme has been modified to use a phy bus id instead
of a mask.  This largely serves to eliminate the phy search code in emac
init.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/Kconfig  |1 +
 drivers/net/davinci_emac.c   |   88 ++---
 include/linux/davinci_emac.h |9 
 3 files changed, 40 insertions(+), 58 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c5c86e0..911e7f1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -951,6 +951,7 @@ config NET_NETX
 config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM  ( ARCH_DAVINCI || ARCH_OMAP3 )
+   select TI_DAVINCI_MDIO
select PHYLIB
help
  This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 7fbd052..997f599 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -500,6 +500,7 @@ struct emac_priv {
u32 phy_mask;
/* mii_bus,phy members */
struct mii_bus *mii_bus;
+   const char *phy_id;
struct phy_device *phydev;
spinlock_t lock;
/*platform specific members*/
@@ -686,7 +687,7 @@ static int emac_get_settings(struct net_device *ndev,
 struct ethtool_cmd *ecmd)
 {
struct emac_priv *priv = netdev_priv(ndev);
-   if (priv-phy_mask)
+   if (priv-phydev)
return phy_ethtool_gset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -704,7 +705,7 @@ static int emac_get_settings(struct net_device *ndev,
 static int emac_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
 {
struct emac_priv *priv = netdev_priv(ndev);
-   if (priv-phy_mask)
+   if (priv-phydev)
return phy_ethtool_sset(priv-phydev, ecmd);
else
return -EOPNOTSUPP;
@@ -841,7 +842,7 @@ static void emac_update_phystatus(struct emac_priv *priv)
mac_control = emac_read(EMAC_MACCONTROL);
cur_duplex = (mac_control  EMAC_MACCONTROL_FULLDUPLEXEN) ?
DUPLEX_FULL : DUPLEX_HALF;
-   if (priv-phy_mask)
+   if (priv-phydev)
new_duplex = priv-phydev-duplex;
else
new_duplex = DUPLEX_FULL;
@@ -2485,6 +2486,11 @@ static int emac_devioctl(struct net_device *ndev, struct 
ifreq *ifrq, int cmd)
return -EOPNOTSUPP;
 }
 
+static int match_first_device(struct device *dev, void *data)
+{
+   return 1;
+}
+
 /**
  * emac_dev_open: EMAC device open
  * @ndev: The DaVinci EMAC network adapter
@@ -2499,7 +2505,6 @@ static int emac_dev_open(struct net_device *ndev)
 {
struct device *emac_dev = ndev-dev;
u32 rc, cnt, ch;
-   int phy_addr;
struct resource *res;
int q, m;
int i = 0;
@@ -2560,28 +2565,26 @@ static int emac_dev_open(struct net_device *ndev)
emac_set_coalesce(ndev, coal);
}
 
-   /* find the first phy */
priv-phydev = NULL;
-   if (priv-phy_mask) {
-   emac_mii_reset(priv-mii_bus);
-   for (phy_addr = 0; phy_addr  PHY_MAX_ADDR; phy_addr++) {
-   if (priv-mii_bus-phy_map[phy_addr]) {
-   priv-phydev = priv-mii_bus-phy_map[phy_addr];
-   break;
-   }
-   }
+   /* use the first phy on the bus if pdata did not give us a phy id */
+   if (!priv-phy_id) {
+   struct device *phy;
 
-   if (!priv-phydev) {
-   printk(KERN_ERR %s: no PHY found\n, ndev-name);
-   return -1;
-   }
+   phy = bus_find_device(mdio_bus_type, NULL, NULL,
+ match_first_device);
+   if (phy)
+   priv-phy_id = dev_name(phy);
+   }
 
-   priv-phydev = phy_connect(ndev, dev_name(priv-phydev-dev),
-   emac_adjust_link, 0, PHY_INTERFACE_MODE_MII);
+   if (priv-phy_id  *priv-phy_id) {
+   priv-phydev = phy_connect(ndev, priv-phy_id,
+  emac_adjust_link, 0,
+  PHY_INTERFACE_MODE_MII);
 
if (IS_ERR(priv-phydev)) {
-   printk(KERN_ERR %s: Could not attach to PHY\n,
-   ndev-name);
+   dev_err(emac_dev, could not

[PATCH v4 05/10] davinci: cleanup mdio arch code and switch to phy_id

This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.

In addition, the earlier phy_mask definitions have been replaced with
corresponding phy_id definitions.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 arch/arm/mach-davinci/board-da830-evm.c |7 ++-
 arch/arm/mach-davinci/board-da850-evm.c |7 ++-
 arch/arm/mach-davinci/board-dm365-evm.c |7 ++-
 arch/arm/mach-davinci/board-dm644x-evm.c|8 ++--
 arch/arm/mach-davinci/board-dm646x-evm.c|7 ++-
 arch/arm/mach-davinci/board-mityomapl138.c  |8 ++--
 arch/arm/mach-davinci/board-neuros-osd2.c   |7 ++-
 arch/arm/mach-davinci/board-sffsdr.c|7 ++-
 arch/arm/mach-davinci/devices-da8xx.c   |2 --
 arch/arm/mach-davinci/dm365.c   |1 -
 arch/arm/mach-davinci/dm644x.c  |1 -
 arch/arm/mach-davinci/dm646x.c  |1 -
 arch/arm/mach-davinci/include/mach/dm365.h  |1 -
 arch/arm/mach-davinci/include/mach/dm644x.h |1 -
 arch/arm/mach-davinci/include/mach/dm646x.h |1 -
 15 files changed, 16 insertions(+), 50 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da830-evm.c 
b/arch/arm/mach-davinci/board-da830-evm.c
index ef1ab0b..1bb89d3 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -31,9 +31,7 @@
 #include mach/usb.h
 #include mach/aemif.h
 
-#define DA830_EVM_PHY_MASK 0x0
-#define DA830_EVM_MDIO_FREQUENCY   220 /* PHY bus frequency */
-
+#define DA830_EVM_PHY_ID   
 /*
  * USB1 VBUS is controlled by GPIO1[15], over-current is reported on GPIO2[4].
  */
@@ -558,9 +556,8 @@ static __init void da830_evm_init(void)
 
da830_evm_usb_init();
 
-   soc_info-emac_pdata-phy_mask = DA830_EVM_PHY_MASK;
-   soc_info-emac_pdata-mdio_max_freq = DA830_EVM_MDIO_FREQUENCY;
soc_info-emac_pdata-rmii_en = 1;
+   soc_info-emac_pdata-phy_id = DA830_EVM_PHY_ID;
 
ret = davinci_cfg_reg_list(da830_cpgmac_pins);
if (ret)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index ac2297c..5e435b0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,9 +38,7 @@
 #include mach/mux.h
 #include mach/aemif.h
 
-#define DA850_EVM_PHY_MASK 0x1
-#define DA850_EVM_MDIO_FREQUENCY   220 /* PHY bus frequency */
-
+#define DA850_EVM_PHY_ID   0:00
 #define DA850_LCD_PWR_PIN  GPIO_TO_PIN(2, 8)
 #define DA850_LCD_BL_PIN   GPIO_TO_PIN(2, 15)
 
@@ -678,8 +676,7 @@ static int __init da850_evm_config_emac(void)
/* Enable/Disable MII MDIO clock */
gpio_direction_output(DA850_MII_MDIO_CLKEN_PIN, rmii_en);
 
-   soc_info-emac_pdata-phy_mask = DA850_EVM_PHY_MASK;
-   soc_info-emac_pdata-mdio_max_freq = DA850_EVM_MDIO_FREQUENCY;
+   soc_info-emac_pdata-phy_id = DA850_EVM_PHY_ID;
 
ret = da8xx_register_emac();
if (ret)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index bdea2da..a06b84c 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -54,9 +54,7 @@ static inline int have_tvp7002(void)
return 0;
 }
 
-#define DM365_EVM_PHY_MASK (0x2)
-#define DM365_EVM_MDIO_FREQUENCY   (220) /* PHY bus frequency */
-
+#define DM365_EVM_PHY_ID   0:01
 /*
  * A MAX-II CPLD is used for various board control functions.
  */
@@ -535,8 +533,7 @@ fail:
 
/* ... and ENET ... */
dm365evm_emac_configure();
-   soc_info-emac_pdata-phy_mask = DM365_EVM_PHY_MASK;
-   soc_info-emac_pdata-mdio_max_freq = DM365_EVM_MDIO_FREQUENCY;
+   soc_info-emac_pdata-phy_id = DM365_EVM_PHY_ID;
resets = ~BIT(3);
 
/* ... and AIC33 */
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 65bb940..44a2f0a 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -39,9 +39,7 @@
 #include mach/usb.h
 #include mach/aemif.h
 
-#define DM644X_EVM_PHY_MASK(0x2)
-#define DM644X_EVM_MDIO_FREQUENCY  (220) /* PHY bus frequency */
-
+#define DM644X_EVM_PHY_ID  0:01
 #define LXT971_PHY_ID  (0x001378e2)
 #define LXT971_PHY_MASK(0xfff0)
 
@@ -707,9 +705,7 @@ static __init void davinci_evm_init(void)
davinci_serial_init(uart_config);
dm644x_init_asp(dm644x_evm_snd_data);
 
-   soc_info-emac_pdata-phy_mask = DM644X_EVM_PHY_MASK;
-   soc_info-emac_pdata-mdio_max_freq = DM644X_EVM_MDIO_FREQUENCY;
-
+

[PATCH v4 02/10] davinci: add mdio platform devices

This patch adds mdio platform devices on SoCs that have the necessary
hardware.  Clock lookup entries (aliases) have also been added, so that the
MDIO and EMAC drivers can independently enable/disable a shared underlying
clock.  Further, the EMAC MMR region has been split down into separate MDIO
and EMAC regions.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 arch/arm/mach-davinci/devices-da8xx.c   |   29 +-
 arch/arm/mach-davinci/dm365.c   |   22 +++-
 arch/arm/mach-davinci/dm644x.c  |   22 +++-
 arch/arm/mach-davinci/dm646x.c  |   21 ++-
 arch/arm/mach-davinci/include/mach/dm365.h  |1 +
 arch/arm/mach-davinci/include/mach/dm644x.h |1 +
 arch/arm/mach-davinci/include/mach/dm646x.h |1 +
 7 files changed, 92 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index caeb7f4..9039221 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -352,7 +352,7 @@ int __init da8xx_register_watchdog(void)
 static struct resource da8xx_emac_resources[] = {
{
.start  = DA8XX_EMAC_CPPI_PORT_BASE,
-   .end= DA8XX_EMAC_CPPI_PORT_BASE + 0x5000 - 1,
+   .end= DA8XX_EMAC_CPPI_PORT_BASE + SZ_16K - 1,
.flags  = IORESOURCE_MEM,
},
{
@@ -396,9 +396,34 @@ static struct platform_device da8xx_emac_device = {
.resource   = da8xx_emac_resources,
 };
 
+static struct resource da8xx_mdio_resources[] = {
+   {
+   .start  = DA8XX_EMAC_MDIO_BASE,
+   .end= DA8XX_EMAC_MDIO_BASE + SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device da8xx_mdio_device = {
+   .name   = davinci_mdio,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(da8xx_mdio_resources),
+   .resource   = da8xx_mdio_resources,
+};
+
 int __init da8xx_register_emac(void)
 {
-   return platform_device_register(da8xx_emac_device);
+   int ret;
+
+   ret = platform_device_register(da8xx_mdio_device);
+   if (ret  0)
+   return ret;
+   ret = platform_device_register(da8xx_emac_device);
+   if (ret  0)
+   return ret;
+   ret = clk_add_alias(NULL, dev_name(da8xx_mdio_device.dev),
+   NULL, da8xx_emac_device.dev);
+   return ret;
 }
 
 static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6b6f4c6..71f0f9d 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -699,7 +699,7 @@ static struct emac_platform_data dm365_emac_pdata = {
 static struct resource dm365_emac_resources[] = {
{
.start  = DM365_EMAC_BASE,
-   .end= DM365_EMAC_BASE + 0x47ff,
+   .end= DM365_EMAC_BASE + SZ_16K - 1,
.flags  = IORESOURCE_MEM,
},
{
@@ -734,6 +734,21 @@ static struct platform_device dm365_emac_device = {
.resource   = dm365_emac_resources,
 };
 
+static struct resource dm365_mdio_resources[] = {
+   {
+   .start  = DM365_EMAC_MDIO_BASE,
+   .end= DM365_EMAC_MDIO_BASE + SZ_4K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm365_mdio_device = {
+   .name   = davinci_mdio,
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(dm365_mdio_resources),
+   .resource   = dm365_mdio_resources,
+};
+
 static u8 dm365_default_priorities[DAVINCI_N_AINTC_IRQ] = {
[IRQ_VDINT0]= 2,
[IRQ_VDINT1]= 6,
@@ -1220,7 +1235,12 @@ static int __init dm365_init_devices(void)
 
davinci_cfg_reg(DM365_INT_EDMA_CC);
platform_device_register(dm365_edma_device);
+
+   platform_device_register(dm365_mdio_device);
platform_device_register(dm365_emac_device);
+   clk_add_alias(NULL, dev_name(dm365_mdio_device.dev),
+ NULL, dm365_emac_device.dev);
+
/* Add isif clock alias */
clk_add_alias(master, dm365_isif_dev.name, vpss_master, NULL);
platform_device_register(dm365_vpss_device);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 40fec31..c103b2c 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -330,7 +330,7 @@ static struct emac_platform_data dm644x_emac_pdata = {
 static struct resource dm644x_emac_resources[] = {
{
.start  = DM644X_EMAC_BASE,
-   .end= DM644X_EMAC_BASE + 0x47ff,
+   .end=

[PATCH v4 06/10] omap: cleanup unused davinci mdio arch code

This patch removes davinci architecture code that has now been rendered
useless by the previous patches in the MDIO separation series.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Acked-by: David S. Miller da...@davemloft.net
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-am3517evm.c |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 5dd1b73..5225df6 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -39,7 +39,6 @@
 
 #include mux.h
 
-#define AM35XX_EVM_PHY_MASK(0xF)
 #define AM35XX_EVM_MDIO_FREQUENCY  (100)
 
 static struct mdio_platform_data am3517_evm_mdio_pdata = {
@@ -64,8 +63,6 @@ static struct platform_device am3517_mdio_device = {
 };
 
 static struct emac_platform_data am3517_evm_emac_pdata = {
-   .phy_mask   = AM35XX_EVM_PHY_MASK,
-   .mdio_max_freq  = AM35XX_EVM_MDIO_FREQUENCY,
.rmii_en= 1,
 };
 
@@ -135,7 +132,6 @@ void am3517_evm_ethernet_init(struct emac_platform_data 
*pdata)
pdata-ctrl_reg_offset  = AM35XX_EMAC_CNTRL_OFFSET;
pdata-ctrl_mod_reg_offset  = AM35XX_EMAC_CNTRL_MOD_OFFSET;
pdata-ctrl_ram_offset  = AM35XX_EMAC_CNTRL_RAM_OFFSET;
-   pdata-mdio_reg_offset  = AM35XX_EMAC_MDIO_OFFSET;
pdata-ctrl_ram_size= AM35XX_EMAC_CNTRL_RAM_SIZE;
pdata-version  = EMAC_VERSION_2;
pdata-hw_ram_addr  = AM35XX_EMAC_HW_RAM_ADDR;
-- 
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

[PATCH v4 08/10] net: davinci_emac: separate out cpdma code

In addition to being embedded into the EMAC controller, the CPDMA hardware
block is used in TI's CPSW switch controller.  Fortunately, the programming
interface to this hardware block remains pretty nicely consistent across these
devices.

This patch adds a new CPDMA services layer, which can then be reused across
EMAC and CPSW drivers.

Signed-off-by: Cyril Chemparathy cy...@ti.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Caglar Akyuz caglarak...@gmail.com
---
 drivers/net/Kconfig |   10 +
 drivers/net/Makefile|1 +
 drivers/net/davinci_cpdma.c |  965 +++
 drivers/net/davinci_cpdma.h |  108 +
 4 files changed, 1084 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/davinci_cpdma.c
 create mode 100644 drivers/net/davinci_cpdma.h

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 911e7f1..775fd87 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -952,6 +952,7 @@ config TI_DAVINCI_EMAC
tristate TI DaVinci EMAC Support
depends on ARM  ( ARCH_DAVINCI || ARCH_OMAP3 )
select TI_DAVINCI_MDIO
+   select TI_DAVINCI_CPDMA
select PHYLIB
help
  This driver supports TI's DaVinci Ethernet .
@@ -969,6 +970,15 @@ config TI_DAVINCI_MDIO
  To compile this driver as a module, choose M here: the module
  will be called davinci_mdio.  This is recommended.
 
+config TI_DAVINCI_CPDMA
+   tristate TI DaVinci CPDMA Support
+   depends on ARM  ( ARCH_DAVINCI || ARCH_OMAP3 )
+   help
+ This driver supports TI's DaVinci CPDMA dma engine.
+
+ To compile this driver as a module, choose M here: the module
+ will be called davinci_cpdma.  This is recommended.
+
 config DM9000
tristate DM9000 support
depends on ARM || BLACKFIN || MIPS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d38a7ab..65da885 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PHYLIB) += phy/
 
 obj-$(CONFIG_TI_DAVINCI_EMAC) += davinci_emac.o
 obj-$(CONFIG_TI_DAVINCI_MDIO) += davinci_mdio.o
+obj-$(CONFIG_TI_DAVINCI_CPDMA) += davinci_cpdma.o
 
 obj-$(CONFIG_E1000) += e1000/
 obj-$(CONFIG_E1000E) += e1000e/
diff --git a/drivers/net/davinci_cpdma.c b/drivers/net/davinci_cpdma.c
new file mode 100644
index 000..e92b2b6
--- /dev/null
+++ b/drivers/net/davinci_cpdma.c
@@ -0,0 +1,965 @@
+/*
+ * Texas Instruments CPDMA Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include linux/kernel.h
+#include linux/spinlock.h
+#include linux/device.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/dma-mapping.h
+#include linux/io.h
+
+#include davinci_cpdma.h
+
+/* DMA Registers */
+#define CPDMA_TXIDVER  0x00
+#define CPDMA_TXCONTROL0x04
+#define CPDMA_TXTEARDOWN   0x08
+#define CPDMA_RXIDVER  0x10
+#define CPDMA_RXCONTROL0x14
+#define CPDMA_SOFTRESET0x1c
+#define CPDMA_RXTEARDOWN   0x18
+#define CPDMA_TXINTSTATRAW 0x80
+#define CPDMA_TXINTSTATMASKED  0x84
+#define CPDMA_TXINTMASKSET 0x88
+#define CPDMA_TXINTMASKCLEAR   0x8c
+#define CPDMA_MACINVECTOR  0x90
+#define CPDMA_MACEOIVECTOR 0x94
+#define CPDMA_RXINTSTATRAW 0xa0
+#define CPDMA_RXINTSTATMASKED  0xa4
+#define CPDMA_RXINTMASKSET 0xa8
+#define CPDMA_RXINTMASKCLEAR   0xac
+#define CPDMA_DMAINTSTATRAW0xb0
+#define CPDMA_DMAINTSTATMASKED 0xb4
+#define CPDMA_DMAINTMASKSET0xb8
+#define CPDMA_DMAINTMASKCLEAR  0xbc
+#define CPDMA_DMAINT_HOSTERR   BIT(1)
+
+/* the following exist only if has_ext_regs is set */
+#define CPDMA_DMACONTROL   0x20
+#define CPDMA_DMASTATUS0x24
+#define CPDMA_RXBUFFOFS0x28
+#define CPDMA_EM_CONTROL   0x2c
+
+/* Descriptor mode bits */
+#define CPDMA_DESC_SOP BIT(31)
+#define CPDMA_DESC_EOP BIT(30)
+#define CPDMA_DESC_OWNER   BIT(29)
+#define CPDMA_DESC_EOQ BIT(28)
+#define CPDMA_DESC_TD_COMPLETE BIT(27)
+#define CPDMA_DESC_PASS_CRCBIT(26)
+
+#define CPDMA_TEARDOWN_VALUE   0xfffc
+
+struct cpdma_desc {
+   /* hardware fields */
+   u32 hw_next;
+   u32 hw_buffer;
+   u32 hw_len;
+   u32 hw_mode;
+   /* software fields */
+   void*sw_token;
+   u32 sw_buffer;
+   u32 sw_len;
+};
+
+struct

Re: OMAP3 DSP MMU fault + off mode issue

venki kaps venkiece2...@gmail.com writes:

 On Tue, Sep 14, 2010 at 8:54 PM, venki kaps venkiece2...@gmail.com wrote:
 On Tue, Sep 14, 2010 at 1:28 AM, venki kaps venkiece2...@gmail.com wrote:
 Dear all,

 I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 
 2.6.32).

 The issue is describing as below mentioned way,
        1). The Device is getting DSP MMU Fault when playing MP4 video clip.

 The system is not hitting off mode in the below scenario,
        2). System boot -play mp4 clip -DSP MMU Fault - allow off
 mode --- Never hits off mode

 But surprisingly the system is hitting off mode in the below scenario,
       3). System boot -allow off mode -play mp4 clip -DSP MMU
 Fault - allow off mode --- perfectly works


  - Could you please describe the root cause about the above issues 1  2?
  - How could solve the above issues?

 I have found the issue with UART3.
 In System configuration register (SYSC),-
             IDLEMODE  - Smart idle --- working scenario  --
 system hits off mode.
             IDLEMODE  - No idle --- Non working scenario
 -- system never hits off mode.

 Could you please explain why UART3 is not able to hit smart idle after
 DSP MMU fault ( System boot -play mp4 clip -DSP MMU Fault - allow
 off --- Never hits off mode).,

 My problem is resolved.GPtimer7 was not reset during the MMU FAULT
 occurrence before the first power cycle.
 So this pending interrupt is preventing the system sleep entry.
 Now it works fine after resetting Gptimer7 in pm suspend path.

Sounds like a patch is needed for DSPBridge who manages that timer.

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

Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs

Hi Wim,

Varadarajan, Charulatha ch...@ti.com writes:

 Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
 for enabling/disabling the clocks, sysconfig settings instead of using
 clock FW APIs.

 Signed-off-by: Charulatha V ch...@ti.com

With your ack, I'll be glad to merge this via the OMAP tree since it
depends on the rest of the series for the OMAP platform specific
changes.

Kevin


 ---
  drivers/watchdog/omap_wdt.c |   42 +++---
  1 files changed, 7 insertions(+), 35 deletions(-)

 diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
 index 76b58ab..dbbc580 100644
 --- a/drivers/watchdog/omap_wdt.c
 +++ b/drivers/watchdog/omap_wdt.c
 @@ -38,11 +38,11 @@
  #include linux/err.h
  #include linux/platform_device.h
  #include linux/moduleparam.h
 -#include linux/clk.h
  #include linux/bitops.h
  #include linux/io.h
  #include linux/uaccess.h
  #include linux/slab.h
 +#include linux/pm_runtime.h
  #include mach/hardware.h
  #include plat/prcm.h
  
 @@ -61,8 +61,6 @@ struct omap_wdt_dev {
   void __iomem*base;  /* physical */
   struct device   *dev;
   int omap_wdt_users;
 - struct clk  *ick;
 - struct clk  *fck;
   struct resource *mem;
   struct miscdevice omap_wdt_miscdev;
  };
 @@ -146,8 +144,7 @@ static int omap_wdt_open(struct inode *inode, struct file 
 *file)
   if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
   return -EBUSY;
  
 - clk_enable(wdev-ick);/* Enable the interface clock */
 - clk_enable(wdev-fck);/* Enable the functional clock */
 + pm_runtime_get_sync(wdev-dev);
  
   /* initialize prescaler */
   while (__raw_readl(base + OMAP_WATCHDOG_WPS)  0x01)
 @@ -177,8 +174,7 @@ static int omap_wdt_release(struct inode *inode, struct 
 file *file)
  
   omap_wdt_disable(wdev);
  
 - clk_disable(wdev-ick);
 - clk_disable(wdev-fck);
 + pm_runtime_put_sync(wdev-dev);
  #else
   printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
  #endif
 @@ -292,19 +288,7 @@ static int __devinit omap_wdt_probe(struct 
 platform_device *pdev)
  
   wdev-omap_wdt_users = 0;
   wdev-mem = mem;
 -
 - wdev-ick = clk_get(pdev-dev, ick);
 - if (IS_ERR(wdev-ick)) {
 - ret = PTR_ERR(wdev-ick);
 - wdev-ick = NULL;
 - goto err_clk;
 - }
 - wdev-fck = clk_get(pdev-dev, fck);
 - if (IS_ERR(wdev-fck)) {
 - ret = PTR_ERR(wdev-fck);
 - wdev-fck = NULL;
 - goto err_clk;
 - }
 + wdev-dev = pdev-dev;
  
   wdev-base = ioremap(res-start, resource_size(res));
   if (!wdev-base) {
 @@ -314,8 +298,8 @@ static int __devinit omap_wdt_probe(struct 
 platform_device *pdev)
  
   platform_set_drvdata(pdev, wdev);
  
 - clk_enable(wdev-ick);
 - clk_enable(wdev-fck);
 + pm_runtime_enable(wdev-dev);
 + pm_runtime_get_sync(wdev-dev);
  
   omap_wdt_disable(wdev);
   omap_wdt_adjust_timeout(timer_margin);
 @@ -333,11 +317,7 @@ static int __devinit omap_wdt_probe(struct 
 platform_device *pdev)
   __raw_readl(wdev-base + OMAP_WATCHDOG_REV)  0xFF,
   timer_margin);
  
 - /* autogate OCP interface clock */
 - __raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
 -
 - clk_disable(wdev-ick);
 - clk_disable(wdev-fck);
 + pm_runtime_put_sync(wdev-dev);
  
   omap_wdt_dev = pdev;
  
 @@ -349,12 +329,6 @@ err_misc:
  
  err_ioremap:
   wdev-base = NULL;
 -
 -err_clk:
 - if (wdev-ick)
 - clk_put(wdev-ick);
 - if (wdev-fck)
 - clk_put(wdev-fck);
   kfree(wdev);
  
  err_kzalloc:
 @@ -386,8 +360,6 @@ static int __devexit omap_wdt_remove(struct 
 platform_device *pdev)
   release_mem_region(res-start, resource_size(res));
   platform_set_drvdata(pdev, NULL);
  
 - clk_put(wdev-ick);
 - clk_put(wdev-fck);
   iounmap(wdev-base);
  
   kfree(wdev);
--
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] omap mmc: extended to pass host capabilities from board file

2010-09-15 Thread Sukumar Ghorai

  wires variable is renamed, extended and this single variable to be used to
  pass the platform capabilities, e.g DDR mode. Also removed the hardcoded
  value was using as bus-width.

Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
 arch/arm/mach-omap2/board-2430sdp.c  |3 ++-
 arch/arm/mach-omap2/board-3430sdp.c  |5 +++--
 arch/arm/mach-omap2/board-4430sdp.c  |4 ++--
 arch/arm/mach-omap2/board-cm-t35.c   |5 +++--
 arch/arm/mach-omap2/board-devkit8000.c   |3 ++-
 arch/arm/mach-omap2/board-igep0020.c |5 +++--
 arch/arm/mach-omap2/board-ldp.c  |3 ++-
 arch/arm/mach-omap2/board-n8x0.c |2 +-
 arch/arm/mach-omap2/board-omap3beagle.c  |3 ++-
 arch/arm/mach-omap2/board-omap3evm.c |3 ++-
 arch/arm/mach-omap2/board-omap3pandora.c |7 ---
 arch/arm/mach-omap2/board-omap3stalker.c |3 ++-
 arch/arm/mach-omap2/board-omap3touchbook.c   |3 ++-
 arch/arm/mach-omap2/board-omap4panda.c   |2 +-
 arch/arm/mach-omap2/board-overo.c|5 +++--
 arch/arm/mach-omap2/board-rx51-peripherals.c |5 +++--
 arch/arm/mach-omap2/board-zoom-peripherals.c |5 +++--
 arch/arm/mach-omap2/devices.c|   16 +---
 arch/arm/mach-omap2/hsmmc.c  |   16 ++--
 arch/arm/mach-omap2/hsmmc.h  |3 ++-
 arch/arm/plat-omap/include/plat/mmc.h|7 +++
 drivers/mmc/host/omap.c  |2 +-
 drivers/mmc/host/omap_hsmmc.c|   18 ++
 23 files changed, 67 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 8538e41..fc178a0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -19,6 +19,7 @@
 #include linux/mtd/mtd.h
 #include linux/mtd/partitions.h
 #include linux/mtd/physmap.h
+#include linux/mmc/host.h
 #include linux/delay.h
 #include linux/i2c/twl.h
 #include linux/err.h
@@ -190,7 +191,7 @@ static int __init omap2430_i2c_init(void)
 static struct omap2_hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
-   .wires  = 4,
+   .caps   = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.ext_clock  = 1,
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 67b95b5..3eb9839 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -24,6 +24,7 @@
 #include linux/regulator/machine.h
 #include linux/io.h
 #include linux/gpio.h
+#include linux/mmc/host.h
 
 #include mach/hardware.h
 #include asm/mach-types.h
@@ -353,12 +354,12 @@ static struct omap2_hsmmc_info mmc[] = {
/* 8 bits (default) requires S6.3 == ON,
 * so the SIM card isn't used; else 4 bits.
 */
-   .wires  = 8,
+   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 4,
},
{
.mmc= 2,
-   .wires  = 8,
+   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= 7,
},
{}  /* Terminator */
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..e379bef 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -193,12 +193,12 @@ static struct omap_musb_board_data musb_board_data = {
 static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
-   .wires  = 8,
+   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_wp= -EINVAL,
},
{
.mmc= 2,
-   .wires  = 8,
+   .caps   =  MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable   = true,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index e10bc10..b72009a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -31,6 +31,7 @@
 #include linux/i2c/at24.h
 #include linux/i2c/twl.h
 #include linux/regulator/machine.h
+#include linux/mmc/host.h
 
 #include linux/spi/spi.h
 #include linux/spi/tdo24m.h
@@ -579,14 +580,14 @@ static struct twl4030_keypad_data cm_t35_kp_data = {
 static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
-   .wires  = 4,
+   .caps   = MMC_CAP_4_BIT_DATA,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
 
},
{

Re: [PATCH v4 00/10] split out emac cpdma and mdio for reuse

Cyril Chemparathy cy...@ti.com writes:

 Davinci's EMAC device has an in-built MDIO controller and a CPDMA engine.
 These hardware modules are not restricted to EMAC device alone.  For example,
 CPSW3G (3-port gigabit ethernet switch) hardware uses these very same modules
 internally.  This patch series separates out EMAC's MDIO and CPDMA
 functionality, allowing these individual pieces to be reused across TI
 hardware.  

[...]

 Changes from v3 (rolled in post cpdma/mdio refactoring fixes series):
   1. allow forced 100/full mode instead of phy auto-detect
   2. specify phy_id on boards that had a phy_mask defined earlier
   3. requeue cpdma descriptors when EOQ at submit
   4. use calculated mdio bus access times instead of hardcoded delays
   5. work around emac soft-reset impact on mdio controller state
   6. extend register dumps to include cpdma registers
   7. updated sign offs and acks

Thanks Cyril for one more spin with these updates.  Queuing this one for
2.6.37 in davinci-next.

davinci git is now updated with this series (may take a bit to propagate
to kernel.org mirrors though)

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

RE: OMAP3 DSP MMU fault + off mode issue

2010-09-15 Thread Ramirez Luna, Omar

venki kaps wrote:
...
 
 My problem is resolved.GPtimer7 was not reset during the MMU FAULT
 occurrence before the first power cycle. So this pending interrupt is
 preventing the system sleep entry. 
 Now it works fine after resetting Gptimer7 in pm suspend path.
 

That's doesn't sound right, why the problem is not occurring after the first 
suspend-resume cycle.

DSP is in charge of clearing the overflow interrupt and if it is doing it after 
the first transition to Core OFF, why wouldn't be doing it for the first one.

Moreover from the logs sent internally (since it is the same issue and oddly 
the same resolution), the trace log dump printed is generated in the dsp after 
clearing the interrupts, so the problem could be the gptimer is configured to 
autoreload instead of oneshoot or the dsp write is not posted to clear the 
interrupt (which might be valid issues), but also they could happen after the 
first transition to OFF.

I'm sorry if I didn't ask you for logs but I was seeing this issue internally 
(and assumed you'll be in the same team of people :)), and given that more 
information was posted there than here..., but still, if available send the 
changes you have made.

Regards,

Omar

--
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/15] change default_llseek action

2010-09-15 Thread Valdis . Kletnieks

On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:

 This changes *all* instances of struct file_operations in
 the kernel to have a .llseek operation and then changes
 the default to no_llseek, which returns -ESPIPE, which
 is what we had decided some time ago in a discussion
 with Christoph Hellwig.

I don't suppose there's any clean way to throw a build error or a
printk_on_once() or something if we encounter an unconverted 'struct
file_operations', is there? I have this creeping fear that this patch will go
upstream during the merge window - as will 12 new staging/ drivers from authors
who didn't get the memo yet.

Other than the missed converting a new usage issue, it looks OK to me.




pgpxEkcNJDXEM.pgp
Description: PGP signature

Re: OMAP3 DSP MMU fault + off mode issue

2010-09-15 Thread venki kaps

Venkii,
On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 venki kaps venkiece2...@gmail.com writes:

 On Tue, Sep 14, 2010 at 8:54 PM, venki kaps venkiece2...@gmail.com wrote:
 On Tue, Sep 14, 2010 at 1:28 AM, venki kaps venkiece2...@gmail.com wrote:
 Dear all,

 I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 
 2.6.32).

 The issue is describing as below mentioned way,
        1). The Device is getting DSP MMU Fault when playing MP4 video clip.

 The system is not hitting off mode in the below scenario,
        2). System boot -play mp4 clip -DSP MMU Fault - allow off
 mode --- Never hits off mode

 But surprisingly the system is hitting off mode in the below scenario,
       3). System boot -allow off mode -play mp4 clip -DSP MMU
 Fault - allow off mode --- perfectly works


  - Could you please describe the root cause about the above issues 1  2?
  - How could solve the above issues?

 I have found the issue with UART3.
 In System configuration register (SYSC),-
             IDLEMODE  - Smart idle --- working scenario  --
 system hits off mode.
             IDLEMODE  - No idle --- Non working scenario
 -- system never hits off mode.

 Could you please explain why UART3 is not able to hit smart idle after
 DSP MMU fault ( System boot -play mp4 clip -DSP MMU Fault - allow
 off --- Never hits off mode).,

 My problem is resolved.GPtimer7 was not reset during the MMU FAULT
 occurrence before the first power cycle.
 So this pending interrupt is preventing the system sleep entry.
 Now it works fine after resetting Gptimer7 in pm suspend path.

 Sounds like a patch is needed for DSPBridge who manages that timer.

Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
https://patchwork.kernel.org/patch/91577/
From the above patch, please see the below comment
/*
 * Send a GP Timer interrupt to DSP
 * The DSP expects a GP timer interrupt after an
 * MMU-Fault Request GPTimer
 */

The above changes allow for DSP task information to be printed
by the MPU dspbridge when DSP MMU fault ocurrs.

This above changes will be required during development.
In my scenario, it is not required so i have just commented.

Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
===
--- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
2010-08-24 18:19:19.0 +0900
+++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c2010-09-16
00:28:52.0 +0900
@@ -285,7 +285,8 @@
 * The DSP expects a GP timer interrupt after an
 * MMU-Fault Request GPTimer
 */
-   if (timer) {
+   if (0) {
omap_dm_timer_enable(timer);
/* Enable overflow interrupt */
omap_dm_timer_set_int_enable(timer,


 Kevin

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

Re: [PATCH] tracing, perf: add more power related events

2010-09-15 Thread Jean Pihet

On Thu, Sep 9, 2010 at 9:54 AM, Ingo Molnar mi...@elte.hu wrote:
 I think the ACPI tracepoints can be added on top of the proposed
 patch. Is that ok?

 Yeah - and the OMAP thing can be split up too if the OMAP folks prefer
 it that way, but we still want to _see_ all the patches in this thread
 together so that we have a critical mass of people interested in all
 this ...

Any chance to get the patch merged in?
What is needed wrt to ACPI support?


 Thanks,

        Ingo

Thanks,
Jean
--
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: OMAP3 DSP MMU fault + off mode issue

2010-09-15 Thread venki kaps

Venkii,
On Wed, Sep 15, 2010 at 9:12 PM, venki kaps venkiece2...@gmail.com wrote:
 Venkii,
 On Wed, Sep 15, 2010 at 8:02 PM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 venki kaps venkiece2...@gmail.com writes:

 On Tue, Sep 14, 2010 at 8:54 PM, venki kaps venkiece2...@gmail.com wrote:
 On Tue, Sep 14, 2010 at 1:28 AM, venki kaps venkiece2...@gmail.com wrote:
 Dear all,

 I have been facing an issue with OMAP3 PM with DSP MMU Fault (Kernel 
 2.6.32).

 The issue is describing as below mentioned way,
        1). The Device is getting DSP MMU Fault when playing MP4 video 
 clip.

 The system is not hitting off mode in the below scenario,
        2). System boot -play mp4 clip -DSP MMU Fault - allow off
 mode --- Never hits off mode

 But surprisingly the system is hitting off mode in the below scenario,
       3). System boot -allow off mode -play mp4 clip -DSP MMU
 Fault - allow off mode --- perfectly works


  - Could you please describe the root cause about the above issues 1  2?
  - How could solve the above issues?

 I have found the issue with UART3.
 In System configuration register (SYSC),-
             IDLEMODE  - Smart idle --- working scenario  --
 system hits off mode.
             IDLEMODE  - No idle --- Non working scenario
 -- system never hits off mode.

 Could you please explain why UART3 is not able to hit smart idle after
 DSP MMU fault ( System boot -play mp4 clip -DSP MMU Fault - allow
 off --- Never hits off mode).,

 My problem is resolved.GPtimer7 was not reset during the MMU FAULT
 occurrence before the first power cycle.
 So this pending interrupt is preventing the system sleep entry.
 Now it works fine after resetting Gptimer7 in pm suspend path.

 Sounds like a patch is needed for DSPBridge who manages that timer.

 Patchwork DSPBRIDGE: MMU-Fault debugging enhancements,
 https://patchwork.kernel.org/patch/91577/
 From the above patch, please see the below comment
 /*
  * Send a GP Timer interrupt to DSP
  * The DSP expects a GP timer interrupt after an
  * MMU-Fault Request GPTimer
  */

 The above changes allow for DSP task information to be printed
 by the MPU dspbridge when DSP MMU fault ocurrs.

 This above changes will be required during development.
 In my scenario, it is not required so i have just commented.

 Index: android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c
 ===
 --- android-2.6.32.9.orig/drivers/dsp/bridge/wmd/ue_deh.c
 2010-08-24 18:19:19.0 +0900
 +++ android-2.6.32.9/drivers/dsp/bridge/wmd/ue_deh.c    2010-09-16
 00:28:52.0 +0900
 @@ -285,7 +285,8 @@
                         * The DSP expects a GP timer interrupt after an
                         * MMU-Fault Request GPTimer
                         */
 -                       if (timer) {
 +                       if (0) {
                                omap_dm_timer_enable(timer);
                                /* Enable overflow interrupt */
                                omap_dm_timer_set_int_enable(timer,


In latest kernels (Eg, linux-2.6.36-rc3),The MMU-Fault debugging
enhancements code is moved under CONFIG_TIDSPBRIDGE_BACKTRACE.

 Kevin


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

Re: [PATCH 00/15] change default_llseek action

2010-09-15 Thread Luis R. Rodriguez

On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
 Hi Arnd,

 On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann a...@arndb.de wrote:

 Stephen, please add
 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek

 Added from today.

 Thanks for adding your subsystem tree as a participant of linux-next.  As
 you may know, this is not a judgment of your code.  The purpose of
 linux-next is for integration testing and to lower the impact of
 conflicts between subsystems in the next merge window.

 You will need to ensure that the patches/commits in your tree/series have
 been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,

I should note this should say the code should be GPL-compatible, it
doesn't need to be GPLv2 (or later). Furthermore the contributors of
the subsystem respect the individual licenses of the files through the
Developers Certificate of Origin, which tells the developers what the
meaning of Signed-off-by means.

  Luis
--
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 v5 3/7] wireless: wl12xx: add platform data passing support

2010-09-15 Thread Michał Mirosław

W dniu 15 września 2010 10:25 użytkownik Russell King - ARM Linux
li...@arm.linux.org.uk napisał:
 On Mon, Sep 06, 2010 at 09:42:41PM +0200, Michał Mirosław wrote:
 W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
 li...@arm.linux.org.uk napisał:
  On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
  2010/9/1 Ohad Ben-Cohen o...@wizery.com:
   Add a simple mechanism to pass platform data to the
   SDIO instances of wl12xx.
 [cut patch]
  Why do you need all that copying? Isn't the data constant?
  The first copy is to allow platforms to have their data marked with
  __initdata.  The second copy probably isn't necessary, but avoids
  problems where the driver may decide to modify the platform data.
 Sorry for pushing at this, but why would you mark data that's meant to
 be used after init phase as __initdata?
 Because you may have many instances of the data (due to multiple platform
 support), and only need one of them at run-time.

Ah. That makes sense.

Thanks,
Michał Mirosław
--
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] omap: Update omap3_defconfig to work with SMP_ON_UP

* Shilimkar, Santosh santosh.shilim...@ti.com [100914 23:03]:
  
  Sounds like you're having these problems anyways and they
  are not related to the defconfigs?
  
 Well the issues are because of defconfig but mostly fixable.
 Will hold on my comments till I test the new defconfig on OMAP4.

OK
 
  Considering Linus' earlier comments on the defconfigs, I don't
  see any reasonds not to merge this patch. If TI wants to fix up
  some other things, there's still about two weeks before -rc6.
 
 Sure. I am just saying let's attempt to fix the remaining issues
 and if it doesn't happen in next week, anyway this patch will
 get merged.

OK let's plan on doing that.
  
- LOCAL_TIMERS hangs on omap4, disable it for now.
  
   This is expected on omap4 ES1.0 and hence not enabled
   in the omap_4430sdp_defconfig.
  
  Maybe add a check for ES1.0 there to the init then?
  
 Yes but its ARM generic code and I don't want to pollute it
 with omap checks.. Will see if some other trick can fix this.

Maybe in smp_twd.c return from twd_timer_setup early if twd_base
is NULL?

Regards,

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

Re: [PATCH v5 0/7] native wl1271 support on ZOOM

* John W. Linville linvi...@tuxdriver.com [100915 06:21]:
 On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote:
  On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen o...@wizery.com wrote:
   On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen o...@wizery.com wrote:
   This patchset adds wl1271 support on ZOOM2/3 boards.
  
   Tony, John, let me please suggest merging this through the wireless tree.
  
   wl1271 is a moving target - it keeps changing in the wireless tree and
   merging this patchset there will allow wl1271 developers to have
   everything in a single tree (and prevent merge conflicts in
   linux-next).
  
  Thanks Ohad, that's what I was about to suggest as well. :)
 
 OK, that is fine with me if the omap folks agree?

Yes sounds good to me, I think there's still at least some platform_data
conversation going on though.

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

Re: [PATCH 00/15] change default_llseek action

2010-09-15 Thread Arnd Bergmann

On Wednesday 15 September 2010, valdis.kletni...@vt.edu wrote:
   Show Details
   On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
 
  This changes all instances of struct file_operations in
  the kernel to have a .llseek operation and then changes
  the default to no_llseek, which returns -ESPIPE, which
  is what we had decided some time ago in a discussion
  with Christoph Hellwig.
 
 I don't suppose there's any clean way to throw a build error or a
 printk_on_once() or something if we encounter an unconverted 'struct
 file_operations', is there? I have this creeping fear that this patch will go
 upstream during the merge window - as will 12 new staging/ drivers from 
 authors
 who didn't get the memo yet.
 
 Other than the missed converting a new usage issue, it looks OK to me.

One advantage of the scripted approach is that I can run the script
repeatedly, and send a patch after -rc1 fixing up all the new file
operations.

Moreover, any new drivers are by definition not regressions and staging
drivers are expected to have issues. IIRC the most common llseek operation
is 'noop_llseek', which usually means it should have been 'no_llseek' to
start with, but since this has been in a released kernel, some random
user application might expect a seek on that file to succeed without
error.

Arnd
--
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 v5 3/7] wireless: wl12xx: add platform data passing support

* Vitaly Wool vitalyw...@gmail.com [100915 01:18]:
 2010/9/15 Ohad Ben-Cohen o...@wizery.com:
  Sorry for pushing at this, but why would you mark data that's meant to
  be used after init phase as __initdata?
 
  I can remove the first copying as well if Russell is ok with it.
 
 I personally think it's not worth it. This copying basically happens
 only once and this point is s irrelevant. My position therefore
 is: let's get the current implementation in, and if Michal is
 uncomfortable with that, he can come up with the patch. Let's
 concentrate on the real problems.

This becomes an issue when compiling in support for multiple
boards.. All the data that's not in use for the booted board
should be __initdata.

Regards,

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

Re: [PATCH v5 0/7] native wl1271 support on ZOOM

2010-09-15 Thread Ohad Ben-Cohen

On Wed, Sep 15, 2010 at 6:34 PM, Tony Lindgren t...@atomide.com wrote:
 * John W. Linville linvi...@tuxdriver.com [100915 06:21]:
 On Wed, Sep 15, 2010 at 01:08:18PM +0200, Vitaly Wool wrote:
  On Wed, Sep 15, 2010 at 11:21 AM, Ohad Ben-Cohen o...@wizery.com wrote:
   On Wed, Sep 1, 2010 at 11:26 PM, Ohad Ben-Cohen o...@wizery.com wrote:
   This patchset adds wl1271 support on ZOOM2/3 boards.
  
   Tony, John, let me please suggest merging this through the wireless tree.
  
   wl1271 is a moving target - it keeps changing in the wireless tree and
   merging this patchset there will allow wl1271 developers to have
   everything in a single tree (and prevent merge conflicts in
   linux-next).
 
  Thanks Ohad, that's what I was about to suggest as well. :)

 OK, that is fine with me if the omap folks agree?

 Yes sounds good to me

Great, I will rebase to wireless-testing an resubmit.

 I think there's still at least some platform_data
 conversation going on though.

Last issue was resolved today with Russell's (and yours) latest answer.

Thanks,
Ohad.


 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

[PATCH] overo twl4030: fix twl4030 IRQ (used for usb otg detection)

2010-09-15 Thread Anti Sullin

I was not getting OTG USB vbus/id pin change interrupts on Gumstix Overo
and the reason was a mis-configured irq. I added some more checks to avoid
having a non-bootable kernel on boards with bootloaders that have wrong pinmux.
The changes of twl4030 should be tested on other boards too.

---
Gumstix Overo has TPS65950 (TWL4030) IRQ1 connected to GPIO112.

This patch fixes the TWL4030 IRQ mapping. The TWL4030 IRQ is used to signal USB 
OTG
connection events. If this does not work, the USB OTG and peripheral modes
do not work.

GPIO112 mux is wrong in bootloader, too. In case the board uses an older
bootloader, we'll try to re-mux it in kernel (requires CONFIG_OMAP_MUX).

TWL4030 IRQ1 requires pull-up to be activated on GPIO112. If it is not
(bootloader did not do it and kernel has CONFIG_OMAP_MUX disabled)
the kernel would have a stuck interrupt. To avoid freeze, spurious interrupt
detection is added to TWL4030.

Signed-off-by: Anti Sullin anti.sul...@artecdesign.ee
---
diff -pur linux-2.6.34/arch/arm/mach-omap2/board-overo.c 
linux-2.6.34-ok/arch/arm/mach-omap2/board-overo.c
--- linux-2.6.34/arch/arm/mach-omap2/board-overo.c  2010-05-17 
00:17:36.0 +0300
+++ linux-2.6.34-ok/arch/arm/mach-omap2/board-overo.c   2010-09-14 
19:49:00.0 +0300
@@ -52,6 +52,7 @@
 
 #define OVERO_GPIO_BT_XGATE15
 #define OVERO_GPIO_W2W_NRESET  16
+#define OVERO_GPIO_TPS65950_IRQ112
 #define OVERO_GPIO_PENDOWN 114
 #define OVERO_GPIO_BT_NRESET   164
 #define OVERO_GPIO_USBH_CPEN   168
@@ -353,7 +354,7 @@ static struct i2c_board_info __initdata 
{
I2C_BOARD_INFO(tps65950, 0x48),
.flags = I2C_CLIENT_WAKE,
-   .irq = INT_34XX_SYS_NIRQ,
+   .irq = OMAP_GPIO_IRQ(OVERO_GPIO_TPS65950_IRQ),
.platform_data = overo_twldata,
},
 };
@@ -422,6 +423,21 @@ static struct omap_musb_board_data musb_
 static void __init overo_init(void)
 {
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+
+   /* Mux GPIO112 to pull-up input. In case bad bootloader is used,
+* override mux settings manually here.
+* Requires CONFIG_OMAP_MUX! */
+   omap_mux_set_gpio(OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP,
+   OVERO_GPIO_TPS65950_IRQ);
+
+   if ((gpio_request(OVERO_GPIO_TPS65950_IRQ, TPS65950_IRQ) == 0) 
+   (gpio_direction_input(OVERO_GPIO_TPS65950_IRQ) == 0)) {
+   gpio_export(OVERO_GPIO_TPS65950_IRQ, 0);
+   } else {
+   printk(KERN_ERR could not obtain gpio for TPS65950 IRQ\n);
+   return;
+   }
+
overo_i2c_init();
platform_add_devices(overo_devices, ARRAY_SIZE(overo_devices));
omap_serial_init();
diff -pur linux-2.6.34/drivers/mfd/twl4030-irq.c 
linux-2.6.34-ok/drivers/mfd/twl4030-irq.c
--- linux-2.6.34/drivers/mfd/twl4030-irq.c  2010-05-17 00:17:36.0 
+0300
+++ linux-2.6.34-ok/drivers/mfd/twl4030-irq.c   2010-09-14 19:50:25.0 
+0300
@@ -312,6 +312,14 @@ static int twl4030_irq_thread(void *data
continue;
}
 
+   /* Check for spurious interrupts */
+   if (!pih_isr) {
+   printk(KERN_ERR Spurious TWL4030 interrupt
+detected.  Terminating %s.\n,
+   __func__);
+   break;
+   }
+
/* these handlers deal with the relevant SIH irq status */
local_irq_disable();
for (module_irq = twl4030_irq_base;
@@ -832,7 +840,7 @@ int twl4030_init_irq(int irq_num, unsign
 
init_completion(irq_event);
 
-   status = request_irq(irq_num, handle_twl4030_pih, IRQF_DISABLED,
+   status = request_irq(irq_num, handle_twl4030_pih, IRQF_TRIGGER_LOW | 
IRQF_DISABLED,
TWL4030-PIH, irq_event);
if (status  0) {
pr_err(twl4030: could not claim irq%d: %d\n, irq_num, status);


--
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] nand/omap2: fix compile error with DMA Config

* Cliff Brake cbr...@bec-systems.com [100910 14:46]:
 With CONFIG_MTD_NAND_OMAP_PREFETCH_DMA, there is a compile
 error that this patch fixes.

This should go via linux-mtd, can you please repost?

Regards,

Tony
 
 Signed-off-by: Cliff Brake cbr...@bec-systems.com
 ---
  drivers/mtd/nand/omap2.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
 index 133d515..513e0a7 100644
 --- a/drivers/mtd/nand/omap2.c
 +++ b/drivers/mtd/nand/omap2.c
 @@ -413,7 +413,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
 *mtd, void *addr,
   prefetch_status = gpmc_read_status(GPMC_PREFETCH_COUNT);
   } while (prefetch_status);
   /* disable and stop the PFPW engine */
 - gpmc_prefetch_reset();
 + gpmc_prefetch_reset(info-gpmc_cs);
  
   dma_unmap_single(info-pdev-dev, dma_addr, len, dir);
   return 0;
 -- 
 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

[PATCH] OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts


When the clockdomain layer initializes, place all clockdomains into
software-supervised mode, and clear all wakeup and sleep dependencies
immediately, rather than waiting for the PM code to do this later.
This fixes a major bug where critical sleep dependencies added by the
hwmod code are cleared during late PM init.

As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
longer needed, so remove them.

Kevin Hilman khil...@deeprootsystems.com did all the really hard work on
this, identifying the problem and finding the bug.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/clockdomain.c |  110 +
 arch/arm/mach-omap2/pm34xx.c  |3 -
 2 files changed, 15 insertions(+), 98 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 5d80cb8..6fb61b1 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -258,97 +258,6 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain 
*clkdm, int enable)
 
 }
 
-/**
- * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
- * @clkdm: clockdomain to initialize wkdep usecounts
- *
- * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
- * If a wakeup dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0.  Software should clear all
- * software wakeup dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0.  No return value.
- */
-static void _init_wkdep_usecount(struct clockdomain *clkdm)
-{
-   u32 v;
-   struct clkdm_dep *cd;
-
-   if (!clkdm-wkdep_srcs)
-   return;
-
-   for (cd = clkdm-wkdep_srcs; cd-clkdm_name; cd++) {
-   if (!omap_chip_is(cd-omap_chip))
-   continue;
-
-   if (!cd-clkdm  cd-clkdm_name)
-   cd-clkdm = _clkdm_lookup(cd-clkdm_name);
-
-   if (!cd-clkdm) {
-   WARN(!cd-clkdm, clockdomain: %s: wkdep clkdm %s not 
-found\n, clkdm-name, cd-clkdm_name);
-   continue;
-   }
-
-   v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
-   PM_WKDEP,
-   (1  cd-clkdm-dep_bit));
-
-   if (v)
-   pr_debug(clockdomain: %s: wakeup dependency already 
-set to wake up when %s wakes\n,
-clkdm-name, cd-clkdm-name);
-
-   atomic_set(cd-wkdep_usecount, (v) ? 1 : 0);
-   }
-}
-
-/**
- * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
- * @clkdm: clockdomain to initialize sleepdep usecounts
- *
- * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
- * If a sleep dependency is present in the hardware, the usecount will be
- * set to 1; otherwise, it will be set to 0.  Software should clear all
- * software sleep dependencies prior to calling this function if it wishes
- * to ensure that all usecounts start at 0.  No return value.
- */
-static void _init_sleepdep_usecount(struct clockdomain *clkdm)
-{
-   u32 v;
-   struct clkdm_dep *cd;
-
-   if (!cpu_is_omap34xx())
-   return;
-
-   if (!clkdm-sleepdep_srcs)
-   return;
-
-   for (cd = clkdm-sleepdep_srcs; cd-clkdm_name; cd++) {
-   if (!omap_chip_is(cd-omap_chip))
-   continue;
-
-   if (!cd-clkdm  cd-clkdm_name)
-   cd-clkdm = _clkdm_lookup(cd-clkdm_name);
-
-   if (!cd-clkdm) {
-   WARN(!cd-clkdm, clockdomain: %s: sleepdep clkdm %s 
-not found\n, clkdm-name, cd-clkdm_name);
-   continue;
-   }
-
-   v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
-   OMAP3430_CM_SLEEPDEP,
-   (1  cd-clkdm-dep_bit));
-
-   if (v)
-   pr_debug(clockdomain: %s: sleep dependency already 
-set to prevent from idling until %s 
-idles\n, clkdm-name, cd-clkdm-name);
-
-   atomic_set(cd-sleepdep_usecount, (v) ? 1 : 0);
-   }
-};
-
 /* Public functions */
 
 /**
@@ -379,12 +288,17 @@ void clkdm_init(struct clockdomain **clkdms,
_autodep_lookup(autodep);
 
/*
-* Ensure that the *dep_usecount registers reflect the current
-* state of the PRCM.
+* Put all clockdomains into software-supervised mode; PM code
+* should later enable hardware-supervised mode as appropriate
 */
list_for_each_entry(clkdm,

Re: Using C++ style inheritance for board files

* Elvis Dowson elvis.dow...@mac.com [100914 12:58]:
 
 For example, I have a platform that is based on board-overo.c. Instead copy 
 pasting and creating a new board-overo-variant.c, if the core structures were 
 defined as classes, I could potentially inherit from the base overo board 
 definition, and add my own specific modifications. 

Uhh, let's leave c++ out of this..

You can already easily share most of the code among boards
by having multiple MACHINE entries in the board-*.c file.
See board-n8x0.c for example.

Then you can spend some effort to create common platform
device init code, see gpmc-*.c and hsmmc.c for examples.

Regards,

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

Re: [PATCH v5 5/6] OMAP2PLUS: WDT: use omap_device_build for device registration

* Varadarajan, Charulatha ch...@ti.com [100914 22:18]:
 Use omap_device_build API instead of platform_device_register for
 watchdog timer device registration.
 
 For OMAP2PLUS chips, the device specific data defined in centralized
 hwmod database will be used.

snip

  static void omap_init_wdt(void)
  {
 - if (cpu_is_omap16xx())
 - wdt_resources[0].start = 0xfffeb000;
 - else if (cpu_is_omap2420())
 - wdt_resources[0].start = 0x48022000; /* WDT2 */
 - else if (cpu_is_omap2430())
 - wdt_resources[0].start = 0x49016000; /* WDT2 */
 - else if (cpu_is_omap343x())
 - wdt_resources[0].start = 0x48314000; /* WDT2 */
 - else if (cpu_is_omap44xx())
 - wdt_resources[0].start = 0x4a314000;
 - else
 - return;
 -
 - wdt_resources[0].end = wdt_resources[0].start + 0x4f;
 -
 - (void) platform_device_register(omap_wdt_device);
 + if (cpu_class_is_omap2())
 + omap2_init_wdt();
 + else if (cpu_is_omap16xx())
 + (void) platform_device_register(omap1_wdt_device);
 + return;
  }
  #else
  static inline void omap_init_wdt(void) {}

Please just split this into separate omap_init_wdt functions
under mach-omap1 and mach-omap2. Then set them up with
subsys_initcall and make sure you return early from the
subsys_initcall if the platform is not the right one.

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

Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs

* Kevin Hilman khil...@deeprootsystems.com [100915 07:37]:
 Hi Wim,
 
 Varadarajan, Charulatha ch...@ti.com writes:
 
  Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
  for enabling/disabling the clocks, sysconfig settings instead of using
  clock FW APIs.
 
  Signed-off-by: Charulatha V ch...@ti.com
 
 With your ack, I'll be glad to merge this via the OMAP tree since it
 depends on the rest of the series for the OMAP platform specific
 changes.

Just checking.. The pm_runtime functions are implemented as
clk_enable/disable functions for omap1, right?

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

Re: [PATCH v4 0/2] OMAP: DSS2: Framework to handle omap version specific DSS features

* arc...@ti.com arc...@ti.com [100915 07:00]:
 From: Archit Taneja arc...@ti.com
 
 This is a simple approach to prevent scattered cpu_is_omap checks
 in DSS2 by bringing all omap version specific DSS features/values to one
 single place, initialize them and expose a set of functions to DSS2 driver
 files which return the value/existance of a feature.

Glad to hear. We should absolutely not use cpu_is_omap checks
anywhere in the drivers. The drivers should be arch independent.
Basically any driver using those is broken from Linux point of view.

The current mess is:

$ grep -r cpu_is_omap drivers/ | wc -l
139

The right way to replace those is to pass feature flags from
the platform_data.

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

RE: [PATCH] omap: Update omap3_defconfig to work with SMP_ON_UP

2010-09-15 Thread Shilimkar, Santosh

 -Original Message-
 From: Tony Lindgren [mailto:t...@atomide.com]
 Sent: Wednesday, September 15, 2010 9:41 PM
 To: Shilimkar, Santosh
 Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; linux-
 o...@vger.kernel.org; bryan...@canonical.com
 Subject: Re: [PATCH] omap: Update omap3_defconfig to work with SMP_ON_UP
 
 * Shilimkar, Santosh santosh.shilim...@ti.com [100914 23:03]:
  
   Sounds like you're having these problems anyways and they
   are not related to the defconfigs?
  
  Well the issues are because of defconfig but mostly fixable.
  Will hold on my comments till I test the new defconfig on OMAP4.
 
 OK
 
   Considering Linus' earlier comments on the defconfigs, I don't
   see any reasonds not to merge this patch. If TI wants to fix up
   some other things, there's still about two weeks before -rc6.
  
  Sure. I am just saying let's attempt to fix the remaining issues
  and if it doesn't happen in next week, anyway this patch will
  get merged.
 
 OK let's plan on doing that.
 
Here is the patch which fixes most of the omap4 issues with common
Omap3_defconfig. 

To enable local Timers for es1.0, I made some progress but looks like 
it needs more changes in generic code. Will have a look at it tomorrow.

The patch is on top of the patches being discussed here. It's boot-tested 
with single image on OMAP3 and OMAP4 SMP.

From 26c908cd9baf3cc0b22f04f29cbeb26e08ad05e8 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 15 Sep 2010 22:40:19 +0530
Subject: [PATCH] omap: Update and rename common defconfig for omap2plus devices

This patch addresses below things:
- Renaming existing omap3_defconfig which has OMAP2, OMAP3 and OMAP4 builds
  enabled to more appropriate name 'omap2plus_defconfig'
- L1 cache shift is suppose to be 5 on OMAP4 where as it is 6 on previous
  OMAPs. Keeping it to 5 is safer option for OMAP4 and previous OMAPs. For
  OMAP3 only build the shift would be still 6
- Enable needed Errata's for OMAP4 to work with DMA based device drivers
CONFIG_PL310_ERRATA_588369=y
CONFIG_ARM_ERRATA_720789=y
- Enable the Micrel ethernet controller
CONFIG_KS8851=y
CONFIG_KS8851_MLL=y

With above three changes, OMAP4 ethernet, mmc etc works reliably.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../{omap3_defconfig = omap2plus_defconfig}   |3 +++
 arch/arm/mach-omap2/Kconfig|4 +++-
 2 files changed, 6 insertions(+), 1 deletions(-)
 rename arch/arm/configs/{omap3_defconfig = omap2plus_defconfig} (99%)

diff --git a/arch/arm/configs/omap3_defconfig 
b/arch/arm/configs/omap2plus_defconfig
similarity index 99%
rename from arch/arm/configs/omap3_defconfig
rename to arch/arm/configs/omap2plus_defconfig
index 833a9bc..3d27dd0 100644
--- a/arch/arm/configs/omap3_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -53,6 +53,7 @@ CONFIG_MACH_SBC3530=y
 CONFIG_MACH_OMAP_3630SDP=y
 CONFIG_MACH_OMAP_4430SDP=y
 CONFIG_ARM_THUMBEE=y
+CONFIG_ARM_L1_CACHE_SHIFT=5
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
@@ -139,6 +140,8 @@ CONFIG_SMSC_PHY=y
 CONFIG_NET_ETHERNET=y
 CONFIG_SMC91X=y
 CONFIG_SMSC911X=y
+CONFIG_KS8851=y
+CONFIG_KS8851_MLL=y
 CONFIG_LIBERTAS=y
 CONFIG_LIBERTAS_USB=y
 CONFIG_LIBERTAS_SDIO=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b48bacf..bb85f24 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -35,7 +35,7 @@ config ARCH_OMAP3
default y
select CPU_V7
select USB_ARCH_HAS_EHCI
-   select ARM_L1_CACHE_SHIFT_6
+   select ARM_L1_CACHE_SHIFT_6 if !ARCH_OMAP4
 
 config ARCH_OMAP4
bool TI OMAP4
@@ -43,6 +43,8 @@ config ARCH_OMAP4
depends on ARCH_OMAP2PLUS
select CPU_V7
select ARM_GIC
+   select PL310_ERRATA_588369
+   select ARM_ERRATA_720789
 
 comment OMAP Core Type
depends on ARCH_OMAP2
-- 
1.6.0.4



0001-omap-Update-and-rename-common-defconfig-for-omap2pl.patch
Description: 0001-omap-Update-and-rename-common-defconfig-for-omap2pl.patch

Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived

Hi all,

Here's some important info regarding posted patches and the
upcoming merge window.


UPCOMING MERGE WINDOW

Just to remind everybody, we want to have our omap patches reviewed
and queued into for-next by -rc6. That is less than two weeks from
today.

If you have a larger set of patches, please set them up into a git
branch after review for pulling. Please remember that anything
touching arch/arm/*omap*/ must be also reviewed on the linux-arm-kernel
list, so Cc that list too so I don't have to repost the patches before
applying. Basically see the instructions here (server currently down?):

http://www.elinux.org/OMAP_patch_merging_process


POSTED PATCHES AND PATCHWORK

To cope with the patch overload, I added all the patchwork
patches into archived-v2.6.35 bundle when v2.6.35 got tagged:

http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.35/?archive=both

However, at that point the patchwork instance on kernel.org was buggy,
and I could not mark them all archived.

Anyways, I've marked them all archived now. This means they do not
appear as new patches any longer, and patchwork.kernel.org is
usable again for tracking what's already queued up.

I plan on archiving everything when a new major release comes out,
maybe even after some -rc releases if necessary.

So the current list of patches we're working with for the upcoming
merge window is:

http://patchwork.kernel.org/project/linux-omap/list/

Please everybody, check if your patch got archived, and if so,
repost as needed against v2.6.36-rc4.

In general, if something got archived, please don't consider it
rejected. It just means that you have to repost, fix and complain
until the patch is ready and integrated :) The standard Linux way
you know.

Regards,

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

Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs

2010-09-15 Thread Wim Van Sebroeck

Hi All,

 Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
 for enabling/disabling the clocks, sysconfig settings instead of using
 clock FW APIs.
 
 Signed-off-by: Charulatha V ch...@ti.com

This is all omap specific code. So if Kevin and Tony are fine with the code 
then tou gave my ACK also.

Kind regards,
WIm.

--
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: Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived

2010-09-15 Thread Gadiyar, Anand

On Thu, Sep 16, 2010 at 12:01 AM, Tony Lindgren t...@atomide.com wrote:
 Hi all,

 Here's some important info regarding posted patches and the
 upcoming merge window.


 UPCOMING MERGE WINDOW

 Just to remind everybody, we want to have our omap patches reviewed
 and queued into for-next by -rc6. That is less than two weeks from
 today.

 If you have a larger set of patches, please set them up into a git
 branch after review for pulling. Please remember that anything
 touching arch/arm/*omap*/ must be also reviewed on the linux-arm-kernel
 list, so Cc that list too so I don't have to repost the patches before
 applying. Basically see the instructions here (server currently down?):

 http://www.elinux.org/OMAP_patch_merging_process


 POSTED PATCHES AND PATCHWORK

 To cope with the patch overload, I added all the patchwork
 patches into archived-v2.6.35 bundle when v2.6.35 got tagged:

 http://patchwork.kernel.org/bundle/tmlind/archived-v2.6.35/?archive=both

 However, at that point the patchwork instance on kernel.org was buggy,
 and I could not mark them all archived.

 Anyways, I've marked them all archived now. This means they do not
 appear as new patches any longer, and patchwork.kernel.org is
 usable again for tracking what's already queued up.

 I plan on archiving everything when a new major release comes out,
 maybe even after some -rc releases if necessary.

 So the current list of patches we're working with for the upcoming
 merge window is:

 http://patchwork.kernel.org/project/linux-omap/list/

 Please everybody, check if your patch got archived, and if so,
 repost as needed against v2.6.36-rc4.

 In general, if something got archived, please don't consider it
 rejected. It just means that you have to repost, fix and complain
 until the patch is ready and integrated :) The standard Linux way
 you know.


Tony,

I posted this patch [1] a while ago fixing a bunch of compile warnings
that show up with omap3_defconfig and omap_4430sdp_defconfig builds. I
can't seem to locate it in patchworks; not sure how that happened.

Any chance you can pick this up (before more folks on LAKML start
yelling about no-one caring for build warnings...)? Would you like me
to post this again?

- Anand

[1] http://marc.info/?l=linux-omapm=128212353619711w=2
--
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] omap3: Prevent SDRC deadlock when L3 is changing frequency

Hi Jon,

I regret the delay:

On Wed, 21 Jul 2010, Jon Hunter wrote:

From: Jon Hunter jon-hun...@ti.com

When changing the L3 clock frequency, the CPU is executing from internal RAM
and the SDRC clock is disabled. During this time accesses made to external
DDR are stalled. If the ARM subsystem attempts to access the DDR while the
SDRC clock is disabled this will stall the CPU until the access to the SDRC
timeouts. A timeout on the SDRC should never occur. Once a timeout occurs all
the following accesses will be aborted and the DDR is no longer accessible.

Although the code being executed in the internal RAM does not directly access
the DDR, it was found that the branch prediction logic in the CPU may cause
the CPU to prefetch code from a DDR location while the SDRC clock is disabled.
This was causing an SDRC timeout which resulted in a system hang.

This patch fixes this problem by ensuring the branch prediction logic is
disabled while changing the L3 clock frequency. The branch prediction logic
is disabled by clearing the Z-bit in the ARM AUX CTRL register.

Disabling the branch prediction logic does not have any noticable impact
on the execution time of this code section. The hardware observability
signals were used to monitor the sdrc idle time with and without this
patch when operating at different CPU frequencies (150MHz, 500MHz and
600MHz) and the total sdrc idle time when changing frequenct was in
the range of 9-11us. This was measured on an omap3430 SDP running the
omapzoom p-android-omap-2.6.29 branch.

This change has been commited to both TI's android 2.6.29 and 2.6.32 kernels.
The commits can be viewed here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940

This patch has been rebased on the latest linux-omap tree and tested on
Kevin Hilman's pm branch.

Signed-off-by: Jon Hunter jon-hun...@ti.com

Really nice changelog. I wish every patch had a description this good.
Patch looks really good, too. Queued for 2.6.37.

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

Re: Upcoming merge window, marked all the patchwork patches before v2.6.35 as archived

* Gadiyar, Anand gadi...@ti.com [100915 11:36]:
 
 I posted this patch [1] a while ago fixing a bunch of compile warnings
 that show up with omap3_defconfig and omap_4430sdp_defconfig builds. I
 can't seem to locate it in patchworks; not sure how that happened.
 
 Any chance you can pick this up (before more folks on LAKML start
 yelling about no-one caring for build warnings...)? Would you like me
 to post this again?
 
 - Anand
 
 [1] http://marc.info/?l=linux-omapm=128212353619711w=2

Thanks, adding that with Felipe's ack. For some reason I could not
find this in patchwork at all, I guess it must have been pretty broken
at some point.

Anyways, for the other patches, please just repost so we'll
have all the pending patches in one queue in patchwork.

Regards,

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

RE: [PATCH 6/7] omap4: Workaround for CMD line reset.

2010-09-15 Thread Madhusudhan



 -Original Message-
 From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com]
 Sent: Tuesday, September 14, 2010 11:49 AM
 To: Chikkature Rajashekar, Madhusudhan; 'kishore kadiyala'
 Cc: linux-omap@vger.kernel.org; t...@atomide.com;
 khil...@deeprootsystems.com
 Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
 
 Madhu,
  -Original Message-
  From: Chikkature Rajashekar, Madhusudhan
  Sent: Tuesday, September 14, 2010 9:28 PM
  To: 'kishore kadiyala'; Shilimkar, Santosh
  Cc: linux-omap@vger.kernel.org; t...@atomide.com;
  khil...@deeprootsystems.com
  Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
 
 
 
   -Original Message-
   From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
   Sent: Tuesday, September 14, 2010 10:47 AM
   To: Madhusudhan Chikkature; Santosh Shilimkar
   Cc: linux-omap@vger.kernel.org; t...@atomide.com;
   khil...@deeprootsystems.com
   Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset.
  
   Hi Madhu,
  
   On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar
   santosh.shilim...@ti.com wrote:
From: Madhusudhan Chikkature madhu...@ti.com
   
Add a delay after CMD line reset to accomdate the reset to complete.
The SYSCTL seems to reflect SRC immediately which might not really
be indicating the complete of reset. This is observed only with
 ES2.0
silicon
   
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |    8 
 1 files changed, 8 insertions(+), 0 deletions(-)
   
diff --git a/drivers/mmc/host/omap_hsmmc.c
   b/drivers/mmc/host/omap_hsmmc.c
index 4a8776f..1c359f0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -986,6 +986,14 @@ static inline void
   omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host,
               (i++  limit))
               cpu_relax();
   
+       /*
+        * On OMAP4 ES2 the SRC is zero in the first loop itself
   strangely
+        * vs on ES1 it takes some time.
+        * Could be a an issue on ES2 to indicate reset complete
 even
   before
+        * it is complete.
+        */
+       udelay(500);
  
   Since the above work around is applicable only for OMAP4 ES2 ,
   shouldn't this udelay be avoided for other OMAP versions
  
  I did not post this to Linux omap at all. What patch are you talking
  about?
 
 I have posted this patch on Tony and Kevin's request keeping the original
 author. This is needed to get MMC working on ES2.0 samples.
 
 Do you have fresh version of this patch?
 
Yes. There is a TRM update lately that explains the procedure for CMD line
reset changes in ES2. I will post that patch.

Regards,
Madhu

 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 v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs

Tony Lindgren t...@atomide.com writes:

 * Kevin Hilman khil...@deeprootsystems.com [100915 07:37]:
 Hi Wim,
 
 Varadarajan, Charulatha ch...@ti.com writes:
 
  Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
  for enabling/disabling the clocks, sysconfig settings instead of using
  clock FW APIs.
 
  Signed-off-by: Charulatha V ch...@ti.com
 
 With your ack, I'll be glad to merge this via the OMAP tree since it
 depends on the rest of the series for the OMAP platform specific
 changes.

 Just checking.. The pm_runtime functions are implemented as
 clk_enable/disable functions for omap1, right?

Yes.

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

Re: [PATCH] OMAP clockdomain: initialize clockdomain registers when the clockdomain layer starts

Paul Walmsley p...@pwsan.com writes:

 When the clockdomain layer initializes, place all clockdomains into
 software-supervised mode, and clear all wakeup and sleep dependencies
 immediately, rather than waiting for the PM code to do this later.
 This fixes a major bug where critical sleep dependencies added by the
 hwmod code are cleared during late PM init.

 As a side benefit, the _init_{wk,sleep}dep_usecount() functions are no
 longer needed, so remove them.

 Kevin Hilman khil...@deeprootsystems.com did all the really hard work on
 this, identifying the problem and finding the bug.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@deeprootsystems.com

Thanks Paul. 

I'll queue this in pm-next for 2.6.37 along with the other changes that
depend on it.

Kevin


 ---
  arch/arm/mach-omap2/clockdomain.c |  110 
 +
  arch/arm/mach-omap2/pm34xx.c  |3 -
  2 files changed, 15 insertions(+), 98 deletions(-)

 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 5d80cb8..6fb61b1 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -258,97 +258,6 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain 
 *clkdm, int enable)
  
  }
  
 -/**
 - * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
 - * @clkdm: clockdomain to initialize wkdep usecounts
 - *
 - * Initialize the wakeup dependency usecount variables for clockdomain 
 @clkdm.
 - * If a wakeup dependency is present in the hardware, the usecount will be
 - * set to 1; otherwise, it will be set to 0.  Software should clear all
 - * software wakeup dependencies prior to calling this function if it wishes
 - * to ensure that all usecounts start at 0.  No return value.
 - */
 -static void _init_wkdep_usecount(struct clockdomain *clkdm)
 -{
 - u32 v;
 - struct clkdm_dep *cd;
 -
 - if (!clkdm-wkdep_srcs)
 - return;
 -
 - for (cd = clkdm-wkdep_srcs; cd-clkdm_name; cd++) {
 - if (!omap_chip_is(cd-omap_chip))
 - continue;
 -
 - if (!cd-clkdm  cd-clkdm_name)
 - cd-clkdm = _clkdm_lookup(cd-clkdm_name);
 -
 - if (!cd-clkdm) {
 - WARN(!cd-clkdm, clockdomain: %s: wkdep clkdm %s not 
 -  found\n, clkdm-name, cd-clkdm_name);
 - continue;
 - }
 -
 - v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
 - PM_WKDEP,
 - (1  cd-clkdm-dep_bit));
 -
 - if (v)
 - pr_debug(clockdomain: %s: wakeup dependency already 
 -  set to wake up when %s wakes\n,
 -  clkdm-name, cd-clkdm-name);
 -
 - atomic_set(cd-wkdep_usecount, (v) ? 1 : 0);
 - }
 -}
 -
 -/**
 - * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
 - * @clkdm: clockdomain to initialize sleepdep usecounts
 - *
 - * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
 - * If a sleep dependency is present in the hardware, the usecount will be
 - * set to 1; otherwise, it will be set to 0.  Software should clear all
 - * software sleep dependencies prior to calling this function if it wishes
 - * to ensure that all usecounts start at 0.  No return value.
 - */
 -static void _init_sleepdep_usecount(struct clockdomain *clkdm)
 -{
 - u32 v;
 - struct clkdm_dep *cd;
 -
 - if (!cpu_is_omap34xx())
 - return;
 -
 - if (!clkdm-sleepdep_srcs)
 - return;
 -
 - for (cd = clkdm-sleepdep_srcs; cd-clkdm_name; cd++) {
 - if (!omap_chip_is(cd-omap_chip))
 - continue;
 -
 - if (!cd-clkdm  cd-clkdm_name)
 - cd-clkdm = _clkdm_lookup(cd-clkdm_name);
 -
 - if (!cd-clkdm) {
 - WARN(!cd-clkdm, clockdomain: %s: sleepdep clkdm %s 
 -  not found\n, clkdm-name, cd-clkdm_name);
 - continue;
 - }
 -
 - v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
 - OMAP3430_CM_SLEEPDEP,
 - (1  cd-clkdm-dep_bit));
 -
 - if (v)
 - pr_debug(clockdomain: %s: sleep dependency already 
 -  set to prevent from idling until %s 
 -  idles\n, clkdm-name, cd-clkdm-name);
 -
 - atomic_set(cd-sleepdep_usecount, (v) ? 1 : 0);
 - }
 -};
 -
  /* Public functions */
  
  /**
 @@ -379,12 +288,17 @@ void clkdm_init(struct clockdomain **clkdms,
   _autodep_lookup(autodep);
  
   /*
 -  * Ensure that the *dep_usecount registers reflect the current
 -  * state of the PRCM.
 +  * Put all

Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way

2010-09-15 Thread Grant Likely

On Fri, Sep 10, 2010 at 03:15:35PM -0700, Kevin Hilman wrote:
 Grant Likely grant.lik...@secretlab.ca writes:
 
  On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote:
  Grant Likely grant.lik...@secretlab.ca writes:
  
   On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com wrote:
   This patch series implements McSPI Module in HWMOD FW way
   and use the runtime PM layer.
  
   Hi Charulatha,
  
   I'll go through and review the patches, but I'm unfamiliar with HWMOD.
   Is there a description of HWMOD that you can point me at?
  
  Hi Grant,
  
  If you want to skip my rambling, the source for omap_hwmod is in mainline:
  
 arch/arm/mach-omap2/omap_hwmod.c
 arch/arm/plat-omap/include/plat/omap_hwmod.h
  
  omap_hwmod is short for OMAP hardware module.  It is essentially a
  central way of describing each IP block in an OMAP SoC, and the way they
  are connected together to make an SoC.  An omap_hwmod for a given IP
  block contains base address, IRQs, DMA channels etc. (as would a device
  tree node) but also includes information on any master/slave interfaces
  to model how IP blocks are connected on the SoC and many other details.
 
  Hi Kevin,
 
  This seems to be a common issue for more than just OMAP SoCs, and I've
  seen a number of approaches to solving it; both internal to the kernel
  (AMBA bus, HWMOD, ad-hoc pdata, etc) and via external data (FDT, SFI).
  It doesn't seem like there is a lot of cross-pollination going on
  either.
 
  I'm thinking about scheduling a discussion in the embedded
  microconference at Plumbers to talk about the encoding and handling of
  SoC and machine interconnection data.  There should be enough examples
  now that we can agree on some common infrastructure for handling these
  kinds of things without inventing new infrastructure from scratch for
  each SoC family.  What do you think?
 
 The discussion is certainly worthwhile, and I would love to participate.
 As with everything, the devil is in the details.  And I'm afraid that
 while at a high-level, describing one SoC or another might look similar,
 when it gets down to the details, there will be *tons* of things that
 are unique to each SoC.
 
 For example, if you look into the omap_hwmod code and data structures,
 you will see that most of the stuff described in there is extremly OMAP
 specific (mostly clock/power related), and only ever visible to OMAP
 specific code.
 
 The question to me is what is the end goal of having a common
 infrastructure to model SoC-unique features that are only touched by
 SoC-specific code?  And who would maintain such an infrastructure?

You're right, there is no point generalizing stuff that is truly SoC
specific.  I'm interested in identifying the bits and techniques that
are useful to other SoCs and architectures.

I'm happy to maintain any infrastructure if need be.

 Personally, I would rather keep focus on infrastructure efforts that
 would actually be common across SoCs (common kernel binaries, etc.) and
 visible to drivers (PM frameworks like CPUidle, runtime PM, etc.)  All
 the gory SoC specifics should be hidden by the SoC-specific
 implementations of these frameworks, and maintained by folks who really
 understand the SoC.

Yes, I agree.

 So, all that that I question the need for a common
 framework to define SoC internals.

Well for an example, we've talked a lot about the platform_bus_type.
Associativity between devices (parent/child) is a core part of the
Linux device model, and it is a common problem to know what the device
topology is for handing init and PM ordering.  I'd like to know what
topology you need to describe for the OMAP SoCs.  Does the Linux
driver model topology provide any of the information you need, or does
OMAP HWMOD implement its own topology infrastructure?  What is missing
from the driver model that requires a lookaside to HWMOD to obtain the
SoC topology?

I'm certainly not arguing that all SoC specific infrastructure needs
to be generalized.  Rather I want to find common features and
techniques that can be used by SoC specific code.

 That being said, I'm totally in favor of the direction that the FDT is
 going in, and very much support the ways it will unify much of the
 hardware description.  However, I think it has limits.

Of course it does; it's only a data structure!  :-D  It can encode
data about the hardware; but it cannot describe operating system
behaviour.

 And at least for
 OMAP, I envision using the device tree to describe connections at the
 board level, but continuing to use omap_hwmod to describe the SoC
 itself.

At the very least, the structure of the SoC probably needs to be
reflected in the device tree.  A lot of the time nodes for internal
SoC devices end up becoming 'handles' to describe attachments to
external hardware.  ie. i2c device nodes hanging off an SoC i2c
controller, or interrupt connections.  Since those nodes have to be
there anyway, it is useful (and less confusing) to have them

Re: [PATCH v5 4/6] OMAP4: hwmod data: Add watchdog timer


Hi Charu,

On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:

From: Benoit Coussonb-cous...@ti.com

Add watchdog timer hwmod data for OMAP4 chip

Signed-off-by: Benoit Coussonb-cous...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
---
This patch is extracted from the below patch sent by Benoit
OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0
https://patchwork.kernel.org/patch/99052/

  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   68 
  1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..06851f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,72 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
  };

+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_SOFTRESET),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+   .name = wd_timer,
+   .sysc =omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+   { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+   {
+   .pa_start   = 0x4a314000,
+   .pa_end = 0x4a31407f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -  wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+   .master =omap44xx_l4_wkup_hwmod,
+   .slave  =omap44xx_wd_timer2_hwmod,
+   .clk= l4_wkup_clk_mux_ck,
+   .addr   = omap44xx_wd_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+   omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+   .name   = wd_timer2,
+   .class  =omap44xx_wd_timer_hwmod_class,
+   .mpu_irqs   = omap44xx_wd_timer2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+   .main_clk   = wd_timer2_fck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_wd_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
  static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
omap44xx_dmm_hwmod,
@@ -472,6 +538,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {

/* mpu class */
omap44xx_mpu_hwmod,
+   /* wd_timer class */
+   omap44xx_wd_timer2_hwmod,
NULL,
  };


What about the wd_timer3? It is in the audio backend, and I'm not sure 
who will use it, but it does exist.


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

Re: [PATCH v5 1/6] OMAP3: hwmod data: Add watchdog timer


On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:

Add watchdog timer hwmod data for OMAP3 chip

Signed-off-by: Charulatha Vch...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   61 
  arch/arm/mach-omap2/prcm-common.h  |4 ++
  2 files changed, 65 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..a9812a8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -36,6 +36,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
  static struct omap_hwmod omap3xxx_l3_main_hwmod;
  static struct omap_hwmod omap3xxx_l4_core_hwmod;
  static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod;

  /* L3 -  L4_CORE interface */
  static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +198,65 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
  };

+/* WDTIMER2- L4_WKUP interface */


Minor point, but the name convention is wd_timerX. It is valid for all 
other comments in this file.



+static struct omap_hwmod_addr_space omap3xxx_wd_timer2_addrs[] = {
+   {
+   .pa_start   = 0x48314000,
+   .pa_end = 0x4831407f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_wkup__wd_timer2 = {
+   .master =omap3xxx_l4_wkup_hwmod,
+   .slave  =omap3xxx_wd_timer2_hwmod,
+   .clk= wdt2_ick,
+   .addr   = omap3xxx_wd_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_wd_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* WDTIMER common */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_wd_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_wd_timer_hwmod_class = {
+   .name = wd_timer,
+   .sysc =omap3xxx_wd_timer_sysc,
+};
+
+/* WDTIMER2 */
+static struct omap_hwmod_ocp_if *omap3xxx_wd_timer2_slaves[] = {
+   omap3xxx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap3xxx_wd_timer2_hwmod = {
+   .name   = wd_timer2,
+   .class  =omap3xxx_wd_timer_hwmod_class,
+   .main_clk   = wdt2_fck,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id = 1,
+   .module_bit = OMAP3430_EN_WDT2_SHIFT,
+   .module_offs = WKUP_MOD,
+   .idlest_reg_id = 1,
+   .idlest_idle_bit = OMAP3430_EN_WDT2_SHIFT,
+   },
+   },
+   .slaves = omap3xxx_wd_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_wd_timer2_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+};
+
  static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -204,6 +264,7 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l4_wkup_hwmod,
omap3xxx_mpu_hwmod,
omap3xxx_iva_hwmod,
+   omap3xxx_wd_timer2_hwmod,
NULL,
  };

diff --git a/arch/arm/mach-omap2/prcm-common.h 
b/arch/arm/mach-omap2/prcm-common.h
index 995b7ed..e190c64 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -237,6 +237,8 @@
  #define OMAP24XX_ST_USB_MASK  (1  0)

  /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP24XX_EN_WDT2_SHIFT 3
+#define OMAP24XX_EN_WDT2_MASK  (1  3)
  #define OMAP24XX_EN_GPIOS_SHIFT   2
  #define OMAP24XX_EN_GPIOS_MASK(1  2)
  #define OMAP24XX_EN_GPT1_SHIFT0
@@ -344,6 +346,8 @@
  #define OMAP3430_ST_D2D_MASK  (1  3)

  /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */
+#define OMAP3430_EN_WDT2_SHIFT 5
+#define OMAP3430_EN_WDT2_MASK  (1  5)
  #define OMAP3430_EN_GPIO1_MASK(1  3)
  #define OMAP3430_EN_GPIO1_SHIFT   3
  #define OMAP3430_EN_GPT12_MASK(1  1)


That part is not related to the subject of this patch. You should 
probably put that in another patch.


Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in

RE: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR stall in SDRC after a Warm-reset

Teerth, Vishwa,

On Tue, 25 May 2010, Reddy, Teerth wrote:

  -Original Message-
  From: Paul Walmsley [mailto:p...@pwsan.com]
  Sent: Wednesday, May 19, 2010 6:03 AM
  To: Reddy, Teerth
  Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
  Subject: Re: [PATCHV4] OMAP3: SDRC : Errata 1.176 Fix - Accesses to DDR
  stall in SDRC after a Warm-reset
  
  On Fri, 23 Apr 2010, Reddy, Teerth wrote:
  
   From: Teerth Reddy tee...@ti.com
  
   This patch has the workaround for errata 1.176.

What's the current status of this patch?  Still waiting for an updated 
version.


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

Re: [PATCH v5 4/6] OMAP4: hwmod data: Add watchdog timer


On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:

From: Benoit Coussonb-cous...@ti.com

Add watchdog timer hwmod data for OMAP4 chip

Signed-off-by: Benoit Coussonb-cous...@ti.com
Signed-off-by: Charulatha Vch...@ti.com
---
This patch is extracted from the below patch sent by Benoit
OMAP4: hwmod: Add partial hwmod support for OMAP4430 ES1.0
https://patchwork.kernel.org/patch/99052/


Since that one, I sent a newer version:
OMAP4: hwmod: Add initial data for OMAP4430 ES1  ES2
https://patchwork.kernel.org/patch/117347/

In fact the patch that really contains all the data is not there, 
probably because of its size :-(


Benoit



  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   68 
  1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index e20b0ee..06851f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -452,6 +452,72 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
  };

+/*
+ * 'wd_timer' class
+ * 32-bit watchdog upward counter that generates a pulse on the reset pin on
+ * overflow condition
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_wd_timer_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_SOFTRESET),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields=omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_wd_timer_hwmod_class = {
+   .name = wd_timer,
+   .sysc =omap44xx_wd_timer_sysc,
+};
+
+/* wd_timer2 */
+static struct omap_hwmod omap44xx_wd_timer2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_wd_timer2_irqs[] = {
+   { .irq = 80 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_wd_timer2_addrs[] = {
+   {
+   .pa_start   = 0x4a314000,
+   .pa_end = 0x4a31407f,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* l4_wkup -  wd_timer2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_wkup__wd_timer2 = {
+   .master =omap44xx_l4_wkup_hwmod,
+   .slave  =omap44xx_wd_timer2_hwmod,
+   .clk= l4_wkup_clk_mux_ck,
+   .addr   = omap44xx_wd_timer2_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* wd_timer2 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_wd_timer2_slaves[] = {
+   omap44xx_l4_wkup__wd_timer2,
+};
+
+static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
+   .name   = wd_timer2,
+   .class  =omap44xx_wd_timer_hwmod_class,
+   .mpu_irqs   = omap44xx_wd_timer2_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_wd_timer2_irqs),
+   .main_clk   = wd_timer2_fck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_WKUP_WDT2_CLKCTRL,
+   },
+   },
+   .slaves = omap44xx_wd_timer2_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap44xx_wd_timer2_slaves),
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
  static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
omap44xx_dmm_hwmod,
@@ -472,6 +538,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {

/* mpu class */
omap44xx_mpu_hwmod,
+   /* wd_timer class */
+   omap44xx_wd_timer2_hwmod,
NULL,
  };



--
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] overo twl4030: fix twl4030 IRQ (used for usb otg detection)

2010-09-15 Thread Steve Sakoman

On Wed, Sep 15, 2010 at 9:29 AM, Anti Sullin anti.sul...@artecdesign.ee wrote:
 I was not getting OTG USB vbus/id pin change interrupts on Gumstix Overo
 and the reason was a mis-configured irq. I added some more checks to avoid
 having a non-bootable kernel on boards with bootloaders that have wrong 
 pinmux.
 The changes of twl4030 should be tested on other boards too.

 ---
 Gumstix Overo has TPS65950 (TWL4030) IRQ1 connected to GPIO112.

I don't think that this change should be made.

From what I understand from my discussions with Gumstix, early
versions of the Overo COM used GPIO112 as indicated above.

However all fab revisions =2516 use GPIO0, so the code is correct for
current and future versions of Overo COMs (as is the bootloader
pinmuxing).

In fact, future versions of Overo will use GPIO112 for a revision ID.

Not an ideal situation, but I think we should leave things as they are
since it matches current and future production.

People with older boards will certainly need to use this patch to get
vbus/id interrupts.

Steve
--
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] omap3: Prevent SDRC deadlock when L3 is changing frequency

Jon,

one other brief note:

On Wed, 21 Jul 2010, Jon Hunter wrote:

 diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
 index de99ba2..e87e730 100644
 --- a/arch/arm/mach-omap2/sram34xx.S
 +++ b/arch/arm/mach-omap2/sram34xx.S
 @@ -129,8 +129,11 @@ ENTRY(omap3_sram_configure_core_dpll)
   ldr r4, [sp, #80]
   str r4, omap_sdrc_mr_1_val
  skip_cs1_params:
 + mrc p15, 0, r8, c1, c0, 0   @ read aux ctrl register
 + bic r10, r8, #0x800 @ clear Z-bit, disable branch prediction
 + mcr p15, 0, r10, c1, c0, 0  @ write aux ctrl register

Please be careful with the whitespace between the opcode and the 
arguments - I will fix this in the current patch but it seems best to keep 
this consistent.


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

Re: [PATCH v5 6/6] OMAP: WDT: Use PM runtime APIs instead of clk FW APIs


On 9/15/2010 7:26 AM, Varadarajan, Charulatha wrote:

Call runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks, sysconfig settings instead of using
clock FW APIs.

Signed-off-by: Charulatha Vch...@ti.com
---
  drivers/watchdog/omap_wdt.c |   42 +++---
  1 files changed, 7 insertions(+), 35 deletions(-)

diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 76b58ab..dbbc580 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -38,11 +38,11 @@
  #includelinux/err.h
  #includelinux/platform_device.h
  #includelinux/moduleparam.h
-#includelinux/clk.h
  #includelinux/bitops.h
  #includelinux/io.h
  #includelinux/uaccess.h
  #includelinux/slab.h
+#includelinux/pm_runtime.h
  #includemach/hardware.h
  #includeplat/prcm.h


Why do you have to access the PRCM from the driver?

Benoit



@@ -61,8 +61,6 @@ struct omap_wdt_dev {
void __iomem*base;  /* physical */
struct device   *dev;
int omap_wdt_users;
-   struct clk  *ick;
-   struct clk  *fck;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
  };
@@ -146,8 +144,7 @@ static int omap_wdt_open(struct inode *inode, struct file 
*file)
if (test_and_set_bit(1, (unsigned long *)(wdev-omap_wdt_users)))
return -EBUSY;

-   clk_enable(wdev-ick);/* Enable the interface clock */
-   clk_enable(wdev-fck);/* Enable the functional clock */
+   pm_runtime_get_sync(wdev-dev);

/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS)  0x01)
@@ -177,8 +174,7 @@ static int omap_wdt_release(struct inode *inode, struct 
file *file)

omap_wdt_disable(wdev);

-   clk_disable(wdev-ick);
-   clk_disable(wdev-fck);
+   pm_runtime_put_sync(wdev-dev);
  #else
printk(KERN_CRIT omap_wdt: Unexpected close, not stopping!\n);
  #endif
@@ -292,19 +288,7 @@ static int __devinit omap_wdt_probe(struct platform_device 
*pdev)

wdev-omap_wdt_users = 0;
wdev-mem = mem;
-
-   wdev-ick = clk_get(pdev-dev, ick);
-   if (IS_ERR(wdev-ick)) {
-   ret = PTR_ERR(wdev-ick);
-   wdev-ick = NULL;
-   goto err_clk;
-   }
-   wdev-fck = clk_get(pdev-dev, fck);
-   if (IS_ERR(wdev-fck)) {
-   ret = PTR_ERR(wdev-fck);
-   wdev-fck = NULL;
-   goto err_clk;
-   }
+   wdev-dev =pdev-dev;

wdev-base = ioremap(res-start, resource_size(res));
if (!wdev-base) {
@@ -314,8 +298,8 @@ static int __devinit omap_wdt_probe(struct platform_device 
*pdev)

platform_set_drvdata(pdev, wdev);

-   clk_enable(wdev-ick);
-   clk_enable(wdev-fck);
+   pm_runtime_enable(wdev-dev);
+   pm_runtime_get_sync(wdev-dev);

omap_wdt_disable(wdev);
omap_wdt_adjust_timeout(timer_margin);
@@ -333,11 +317,7 @@ static int __devinit omap_wdt_probe(struct platform_device 
*pdev)
__raw_readl(wdev-base + OMAP_WATCHDOG_REV)  0xFF,
timer_margin);

-   /* autogate OCP interface clock */
-   __raw_writel(0x01, wdev-base + OMAP_WATCHDOG_SYS_CONFIG);
-
-   clk_disable(wdev-ick);
-   clk_disable(wdev-fck);
+   pm_runtime_put_sync(wdev-dev);

omap_wdt_dev = pdev;

@@ -349,12 +329,6 @@ err_misc:

  err_ioremap:
wdev-base = NULL;
-
-err_clk:
-   if (wdev-ick)
-   clk_put(wdev-ick);
-   if (wdev-fck)
-   clk_put(wdev-fck);
kfree(wdev);

  err_kzalloc:
@@ -386,8 +360,6 @@ static int __devexit omap_wdt_remove(struct platform_device 
*pdev)
release_mem_region(res-start, resource_size(res));
platform_set_drvdata(pdev, NULL);

-   clk_put(wdev-ick);
-   clk_put(wdev-fck);
iounmap(wdev-base);

kfree(wdev);


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

RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS

Pramod, Teerth,

On Thu, 1 Jul 2010, Paul Walmsley wrote:

 Pramod, Teerth,
 
 On Mon, 7 Jun 2010, Gurav , Pramod wrote:
 
  Can you please push these patches if you don't you are OK with them?
 
 As we discussed in Bangalore, these patches need some changes:
 
 1. The delay needs to be precisely characterized in terms of what the 
 hardware actually needs.  It should not be necessary to add any extra 
 timing slop, due to unknown sources, in the code.  Unknown sources of 
 delay can cause problems if, for example, a customer changes some board 
 characteristics (such as sys_clk frequency, or DPLL multipliers/dividers) 
 that the delay depends on.
 
 Also, my understanding is that RX-51 shipped without unknown timing 
 factors in this code.  Please work with the hardware people to precisely 
 characterize the delay, assuming that it does not match what is documented 
 in the TRM.
 
 2. Please split out the individual components of the delay calculation to 
 the code that handles those clocks.  For example, HSDIVIDER change delay 
 should be calculated by code that handles the HSDIVIDER.  DPLL relock 
 delay should be calculated by code in the dpll*.c files.  etc.

Any updates on these patches?


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

[PATCH 0/4] OMAP OPP layer for 2.6.37

This series introduces a layer to manage Operating Performance Points (OPPs)
for OMAP SoCs.

Special thanks to Nishanth for doing the bulk of the work on this
series and to Thara for doing significant review, testing and updates.

Kevin Hilman (1):
  OMAP3: remove OPP interfaces from OMAP PM layer

Nishanth Menon (2):
  OMAP: introduce OPP layer for device-specific OPPs
  OMAP3: OPP: add OPP table data and initialization

Paul Walmsley (1):
  OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code

 Documentation/arm/OMAP/omap_pm|   83 +
 arch/arm/mach-omap2/Makefile  |2 +
 arch/arm/mach-omap2/io.c  |3 +-
 arch/arm/mach-omap2/opp3xxx_data.c|  126 +++
 arch/arm/mach-omap2/pm.c  |6 +
 arch/arm/mach-omap2/pm.h  |1 +
 arch/arm/plat-omap/Makefile   |6 +
 arch/arm/plat-omap/include/plat/omap-pm.h |   31 +--
 arch/arm/plat-omap/include/plat/opp.h |  145 
 arch/arm/plat-omap/include/plat/opp_twl_tps.h |   21 ++
 arch/arm/plat-omap/omap-pm-noop.c |   11 +-
 arch/arm/plat-omap/opp.c  |  461 +
 arch/arm/plat-omap/opp_twl_tps.c  |   41 +++
 13 files changed, 904 insertions(+), 33 deletions(-)
 create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
 create mode 100644 arch/arm/plat-omap/include/plat/opp.h
 create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h
 create mode 100644 arch/arm/plat-omap/opp.c
 create mode 100644 arch/arm/plat-omap/opp_twl_tps.c

-- 
1.7.2.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 2/4] OMAP: OPP: twl/tps: Introduce TWL/TPS-specific code

From: Paul Walmsley p...@pwsan.com

The OPP layer code should be independent of the PMIC,
introduce the TWL/TPS-specific code out to its own file.

Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Romit Dasgupta ro...@ti.com
Signed-off-by: Phil Carmody ext-phil.2.carm...@nokia.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/plat-omap/Makefile   |1 +
 arch/arm/plat-omap/include/plat/opp_twl_tps.h |   21 +
 arch/arm/plat-omap/opp_twl_tps.c  |   41 +
 3 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/opp_twl_tps.h
 create mode 100644 arch/arm/plat-omap/opp_twl_tps.c

diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index c718a0a..a88879c 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
 # OPP support in (OMAP3+ only at the moment)
 ifdef CONFIG_PM
 obj-$(CONFIG_ARCH_OMAP3) += opp.o
+obj-$(CONFIG_TWL4030_CORE) += opp_twl_tps.o
 endif
 
 # omap_device support (OMAP2+ only at the moment)
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h 
b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
new file mode 100644
index 000..8784e5f
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -0,0 +1,21 @@
+/*
+ * opp_twl_tps.h - TWL/TPS-specific headers for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ *
+ * 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.
+ *
+ * XXX This code belongs as part of some other TWL/TPS code.
+ */
+#ifndef _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+#define _ARCH_ARM_PLAT_OMAP_OPP_TWL_TPS_H
+
+#include linux/kernel.h
+
+unsigned long omap_twl_vsel_to_uv(const u8 vsel);
+u8 omap_twl_uv_to_vsel(unsigned long uV);
+
+#endif
diff --git a/arch/arm/plat-omap/opp_twl_tps.c b/arch/arm/plat-omap/opp_twl_tps.c
new file mode 100644
index 000..112f106
--- /dev/null
+++ b/arch/arm/plat-omap/opp_twl_tps.c
@@ -0,0 +1,41 @@
+/*
+ * opp_twl_tps.c - TWL/TPS-specific functions for the OPP code
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX This code should be part of some other TWL/TPS code.
+ */
+
+#include plat/opp_twl_tps.h
+
+/**
+ * omap_twl_vsel_to_vdc - convert TWL/TPS VSEL value to microvolts DC
+ * @vsel: TWL/TPS VSEL value to convert
+ *
+ * Returns the microvolts DC that the TWL/TPS family of PMICs should
+ * generate when programmed with @vsel.
+ */
+unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+   return (((vsel * 125) + 6000)) * 100;
+}
+
+/**
+ * omap_twl_uv_to_vsel - convert microvolts DC to TWL/TPS VSEL value
+ * @uv: microvolts DC to convert
+ *
+ * Returns the VSEL value necessary for the TWL/TPS family of PMICs to
+ * generate an output voltage equal to or greater than @uv microvolts DC.
+ */
+u8 omap_twl_uv_to_vsel(unsigned long uv)
+{
+   /* Round up to higher voltage */
+   return DIV_ROUND_UP(uv - 60, 12500);
+}
-- 
1.7.2.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 3/4] OMAP3: remove OPP interfaces from OMAP PM layer

With new OPP layer, OPP users will access OPP API directly instead of
using OMAP PM layer, so remove all notions of OPPs from the OMAP PM
layer.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/io.c  |3 +-
 arch/arm/plat-omap/include/plat/omap-pm.h |   31 +---
 arch/arm/plat-omap/omap-pm-noop.c |   11 +-
 3 files changed, 12 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index b9ea70b..c09bf10 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,8 +323,7 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
*sdrc_cs0,
omap2430_hwmod_init();
else if (cpu_is_omap34xx())
omap3xxx_hwmod_init();
-   /* The OPP tables have to be registered before a clk init */
-   omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
+   omap_pm_if_early_init();
 
if (cpu_is_omap2420())
omap2420_clk_init();
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h 
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 728fbb9..c5b533d 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -19,24 +19,7 @@
 #include linux/clk.h
 
 #include powerdomain.h
-
-/**
- * struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
- * @rate: target clock rate
- * @opp_id: OPP ID
- * @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
- *
- * Operating performance point data.  Can vary by OMAP chip and board.
- */
-struct omap_opp {
-   unsigned long rate;
-   u8 opp_id;
-   u16 min_vdd;
-};
-
-extern struct omap_opp *mpu_opps;
-extern struct omap_opp *dsp_opps;
-extern struct omap_opp *l3_opps;
+#include plat/opp.h
 
 /*
  * agent_id values for use with omap_pm_set_min_bus_tput():
@@ -59,9 +42,11 @@ extern struct omap_opp *l3_opps;
  * framework starts.  The _if_ is to avoid name collisions with the
  * PM idle-loop code.
  */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table);
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_early_init() 0
+#else
+int __init omap_pm_if_early_init(void);
+#endif
 
 /**
  * omap_pm_if_init - OMAP PM init code called after clock fw init
@@ -69,7 +54,11 @@ int __init omap_pm_if_early_init(struct omap_opp 
*mpu_opp_table,
  * The main initialization code.  OPP tables are passed in here.  The
  * _if_ is to avoid name collisions with the PM idle-loop code.
  */
+#ifdef CONFIG_OMAP_PM_NONE
+#define omap_pm_if_init() 0
+#else
 int __init omap_pm_if_init(void);
+#endif
 
 /**
  * omap_pm_if_exit - OMAP PM exit code
diff --git a/arch/arm/plat-omap/omap-pm-noop.c 
b/arch/arm/plat-omap/omap-pm-noop.c
index e129ce8..ca75abb 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -26,10 +26,6 @@
 
 #include plat/powerdomain.h
 
-struct omap_opp *dsp_opps;
-struct omap_opp *mpu_opps;
-struct omap_opp *l3_opps;
-
 /*
  * Device-driver-originated constraints (via board-*.c files)
  */
@@ -308,13 +304,8 @@ int omap_pm_get_dev_context_loss_count(struct device *dev)
 
 
 /* Should be called before clk framework init */
-int __init omap_pm_if_early_init(struct omap_opp *mpu_opp_table,
-struct omap_opp *dsp_opp_table,
-struct omap_opp *l3_opp_table)
+int __init omap_pm_if_early_init(void)
 {
-   mpu_opps = mpu_opp_table;
-   dsp_opps = dsp_opp_table;
-   l3_opps = l3_opp_table;
return 0;
 }
 
-- 
1.7.2.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 4/4] OMAP3: OPP: add OPP table data and initialization

From: Nishanth Menon n...@ti.com

Add OPP data for OMAP34xx and OMAP36xx and initialization functions
to populate OPP tables based on current SoC.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/Makefile   |2 +
 arch/arm/mach-omap2/opp3xxx_data.c |  126 
 arch/arm/mach-omap2/pm.c   |6 ++
 arch/arm/mach-omap2/pm.h   |1 +
 4 files changed, 135 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..33acca9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -57,6 +57,8 @@ obj-$(CONFIG_PM_DEBUG)+= pm-debug.o
 AFLAGS_sleep24xx.o :=-Wa,-march=armv6
 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
 
+obj-$(CONFIG_ARCH_OMAP3)   += opp3xxx_data.o
+
 endif
 
 # PRCM
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
b/arch/arm/mach-omap2/opp3xxx_data.c
new file mode 100644
index 000..df0bfa0
--- /dev/null
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -0,0 +1,126 @@
+/*
+ * OMAP3 resource init/change_level/validate_level functions
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ *  Eduardo Valentin
+ *
+ * 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 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.
+ * History:
+ *
+ */
+
+#include linux/module.h
+#include linux/err.h
+
+#include plat/opp.h
+#include plat/cpu.h
+
+static struct omap_opp_def __initdata omap34xx_opp_def_list[] = {
+   /* MPU OPP1 */
+   OMAP_OPP_DEF(mpu, true, 12500, 975000),
+   /* MPU OPP2 */
+   OMAP_OPP_DEF(mpu, true, 25000, 1075000),
+   /* MPU OPP3 */
+   OMAP_OPP_DEF(mpu, true, 5, 120),
+   /* MPU OPP4 */
+   OMAP_OPP_DEF(mpu, true, 55000, 127),
+   /* MPU OPP5 */
+   OMAP_OPP_DEF(mpu, true, 6, 135),
+
+   /*
+* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
+* almost the same than the one at 83MHz thus providing very little
+* gain for the power point of view. In term of energy it will even
+* increase the consumption due to the very negative performance
+* impact that frequency will do to the MPU and the whole system in
+* general.
+*/
+   OMAP_OPP_DEF(l3_main, false, 4150, 975000),
+   /* L3 OPP2 */
+   OMAP_OPP_DEF(l3_main, true, 8300, 105),
+   /* L3 OPP3 */
+   OMAP_OPP_DEF(l3_main, true, 16600, 115),
+
+
+   /* DSP OPP1 */
+   OMAP_OPP_DEF(iva, true, 9000, 975000),
+   /* DSP OPP2 */
+   OMAP_OPP_DEF(iva, true, 18000, 1075000),
+   /* DSP OPP3 */
+   OMAP_OPP_DEF(iva, true, 36000, 120),
+   /* DSP OPP4 */
+   OMAP_OPP_DEF(iva, true, 4, 127),
+   /* DSP OPP5 */
+   OMAP_OPP_DEF(iva, true, 43000, 135),
+};
+static u32 omap34xx_opp_def_size = ARRAY_SIZE(omap34xx_opp_def_list);
+
+static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
+   /* MPU OPP1 - OPP50 */
+   OMAP_OPP_DEF(mpu, true,  3, 93),
+   /* MPU OPP2 - OPP100 */
+   OMAP_OPP_DEF(mpu, true,  6, 110),
+   /* MPU OPP3 - OPP-Turbo */
+   OMAP_OPP_DEF(mpu, false, 8, 126),
+   /* MPU OPP4 - OPP-SB */
+   OMAP_OPP_DEF(mpu, false, 10, 135),
+
+   /* L3 OPP1 - OPP50 */
+   OMAP_OPP_DEF(l3_main, true, 1, 93),
+   /* L3 OPP2 - OPP100, OPP-Turbo, OPP-SB */
+   OMAP_OPP_DEF(l3_main, true, 2, 1137500),
+
+   /* DSP OPP1 - OPP50 */
+   OMAP_OPP_DEF(iva, true,  26000, 93),
+   /* DSP OPP2 - OPP100 */
+   OMAP_OPP_DEF(iva, true,  52000, 110),
+   /* DSP OPP3 - OPP-Turbo */
+   OMAP_OPP_DEF(iva, false, 66000, 126),
+   /* DSP OPP4 - OPP-SB */
+   OMAP_OPP_DEF(iva, false, 8, 135),
+};
+static u32 omap36xx_opp_def_size = ARRAY_SIZE(omap36xx_opp_def_list);
+
+/* Temp variable to allow multiple calls */
+static u8 __initdata omap3_table_init;
+
+int __init omap3_pm_init_opp_table(void)
+{
+   struct omap_opp_def *opp_def, *omap3_opp_def_list;
+   u32 omap3_opp_def_size;
+   int i, r;
+
+   /*
+* Allow multiple calls, but initialize only if not already initalized
+* even if the previous call failed,

[PATCH 1/4] OMAP: introduce OPP layer for device-specific OPPs

From: Nishanth Menon n...@ti.com

OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain.  These
are called Operating Performance Points or OPPs. The actual
definitions of OMAP Operating Points varies over silicon within the
same family of devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise nature
of device the kernel boots up on. It is interesting to remember that
each IP which belongs to a voltage domain may define their own set of
OPPs on top of this.

This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is used for OMAP3.

Note: OPP is a concept that can be used in all OMAPs, it is hence
introduced under plat-omap

Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling
Romit Dasgupta for using enums instead of opp pointers
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.

Discussions and comments from:
http://marc.info/?l=linux-omapm=126033945313269w=2
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
http://marc.info/?l=linux-omapm=126025973426007w=2
incorporated.

Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Phil Carmody ext-phil.2.carm...@nokia.com
Cc: Roberto Granados Dorado x0095...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: Eduardo Valentin eduardo.valen...@nokia.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 Documentation/arm/OMAP/omap_pm|   83 ++
 arch/arm/plat-omap/Makefile   |5 +
 arch/arm/plat-omap/include/plat/opp.h |  145 +++
 arch/arm/plat-omap/opp.c  |  461 +
 4 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/opp.h
 create mode 100644 arch/arm/plat-omap/opp.c

diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm
index 5389440..6527cdf 100644
--- a/Documentation/arm/OMAP/omap_pm
+++ b/Documentation/arm/OMAP/omap_pm
@@ -127,3 +127,86 @@ implementation needs:
 10. (*pdata-cpu_set_freq)(unsigned long f)
 
 11. (*pdata-cpu_get_freq)(void)
+
+OMAP OPP Layer
+==
+OMAP SOCs have a standard set of tuples consisting of frequency and
+voltage pairs that the device will support per voltage domain. This
+is called Operating Performance Point or OPP. The actual definitions
+of OMAP OPP varies over silicon within the same family of devices.
+For a specific domain, you can have a set of {frequency, voltage}
+pairs. As the kernel boots and more information is available, a set
+of these are activated based on the precise nature of device the kernel
+boots up on. It is interesting to remember that each IP which belongs
+to a voltage domain may define their own set of OPPs on top of this.
+
+OPP layer of its own depends on silicon specific implementation and
+board specific data to finalize on the final set of OPPs available
+in a system
+
+Initial list initialization:
+---
+The normal initialization sequence is for boardxyz_init_irq to call
+omap2_init_common_hw (for omap2+) and which in turn does the default
+setup required.
+
+Silicon specific initialization: First the OPP layer needs to be told
+to initialize the tables for OMAP3, there are two options here:
+a) If the desire is to use the default tables defined for that silicon,
+the board file does not need to call any initialization function, the
+defaults are setup as part of initialization flow when
+omap2_init_common_hw is called.
+
+b) board files would like to customize the default definition. In this
+case, board file needs to call explicitly prior to table operations.
+the sequence is:
+boardxyz_init_irq()
+{
+   ... do things ..
+   omap3_pm_init_opp_table()
+   .. customizations and other things ..
+   omap2_init_common_hw()
+}
+1. omap3_pm_init_opp_table - this in turn calls opp_init_list for all
+OPP types. This is the generic silicon operating points, however, the
+system may have additional features or customizations required. This
+flexibility is provided by the following apis:
+
+Query functions:
+
+Search for OPPs for various cases:
+2. opp_find_freq_exact - exact search function
+3. opp_find_freq_floor -

Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way