RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Mohammed, Afzal]

Hi Jon,

On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote:

> > +   pdev = omap_device_build(name, -1, oh, pdata,
> > +   sizeof(*pdata), NULL, 0, 0);
> > +   if (IS_ERR(pdev)) {
> > +   WARN(1, "Can't build omap_device for %s:%s.\n",
> > +   name, oh->name);
> > +   return PTR_ERR(pdev);
> > +   }
> > +
> > +   gpmc_l3_clk = clk_get(NULL, oh->main_clk);
> > +   if (IS_ERR(gpmc_l3_clk)) {
> > +   pr_err("Could not get GPMC clock\n");
> > +   return PTR_ERR(gpmc_l3_clk);
> > +   }
> 
> My preference would be to store gpmc_l3_clk in the pdata and pass to
> probe via the pdata. The aim would be to remove the global gpmc_l3_clk
> altogether.

For timing calculation by platform outside of driver, we need clk rate

> Also we should attempt to get the clk before calling omap_device_build
> which is registering the driver.

omap_device_build registers only device, but I agree that clk should
be obtained before it as driver can get probed at that point

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

Re: [PATCH 5/5] Input: ads7846: set proper debounce time in driver level

[Tony Lindgren]

* Zumeng Chen  [120611 07:05]:
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.
> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen 
> Signed-off-by: Syed Mohammed Khasim 
> Signed-off-by: Tony Lindgren 

Please remove my Signed-off-by, where does that come from?

Tony


>  drivers/input/touchscreen/ads7846.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c 
> b/drivers/input/touchscreen/ads7846.c
> index f02028e..a82a5fb 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -61,6 +61,7 @@
>  
>  /* this driver doesn't aim at the peak continuous sample rate */
>  #define  SAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after 
> */)
> +#define  DEBOUNCE_TIME   310 /* About 10 ms */
>  
>  struct ts_event {
>   /*
> @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct 
> spi_device *spi, struct ads784
>   }
>  
>   ts->gpio_pendown = pdata->gpio_pendown;
> + gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
>  
>   } else {
>   dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> -- 
> 1.7.5.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

RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

[Mohammed, Afzal]

Hi Jon,

On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote:
 
> What boards have been tested with this change?

Beagle board, after applying all 5 series of patches, without all
patch series it can't be tested for beagle board as it depended on
bootloader, not this API

> > +   u16 bus_turnaround;
> > +   u16 cycle2cycle_delay;
> > +
> > +   u16 wait_monitoring;
> > +   u16 clk_activation;
> > +
> > /* The following are only on OMAP3430 */
> > u16 wr_access;  /* WRACCESSTIME */
> > u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
> 
> In general, I agree with this, but if we apply this today, it seems that
> we *may* be clearing these fields if they have been configured by the
> bootloader and hence this could introduce a regression (potentially).
> 
> So we ever need to test boards that this change impacts or at least
> verify that this change would not impact these boards because these
> fields have not been configured.

Yes, it is the exactly the reason this patch has been splitted out
of gpmc driver conversion series. To find out whether enhancing
existing API cause any regression and if so, then it can be easily
root caused and would not be confused with driver conversion.

This was the only change required w.r.t old interface, need to make
sure that this won't causes breakage on any of the boards (the boards
which were unknowingly depending on bootloader for these settings).
I have only beagle board & omap3evm (both would not get affected
by this change with existing code) and others can't be validated.
Once this is in lo tree or mainline, this change can be validated
for different boards.


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

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

[Mohammed, Afzal]

Hi Jon,

On Tue, Jun 12, 2012 at 00:06:30, Hunter, Jon wrote:

> I agree with getting rid of the first instance at the beginning of
> _set_async_mode, but why get rid of the above one? Are you assuming that
> by default it is in async mode? Could be nice to keep it to be explicit.

Second one is achieved below

> > @@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct 
> > omap_onenand_platform_data *cfg,
> > u32 reg;
> > bool clk_dep = false;
> >  
> > +   /* Ensure sync read and sync write are disabled */
> > +   reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> > +   reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> > +   writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> > +
> 
> Should we only set these after we have checked the flags and depending
> on which flags are set?

Even for sync mode, setting async mode initially is required

> > @@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct 
> > omap_onenand_platform_data *_onenand_data)
> > gpmc_onenand_resource.end = gpmc_onenand_resource.start +
> > ONENAND_IO_SIZE - 1;
> >  
> > +   omap2_onenand_set_async_mode(gpmc_onenand_data->cs);
> > +
> 
> What about putting this in the gpmc_onenand_setup() function before the
> call to _set_sync_mode? Seems nice to have these together.

Intention of this patch is to setup GPMC async mode before driver starts
its job so that reconfiguring GPMC needs to be to be done only once (this
helps in avoiding issues when it has to work with gpmc driver).

With the existing code, set_async was done as part of set_sync, hence
requiring GPMC to be configured twice after driver takes control, with
your suggestion too, GPMC would have to be configured twice.

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

Re: RFC: changing DMA slave configuration API

[Vinod Koul]

On Mon, 2012-06-11 at 09:24 +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:
> > I think it is a good idea. And I would like to extend it even a little
> > bit. Do we have any users of peripheral to peripheral slave dma?
> > IIRC  that is not the case, or does anyone know of existence or plans
> > for such a h/w?
> > 
> > If not, lets junk the src/dst fields and keep burst, length, addr fields
> > which point to the peripheral values.
> > 
> > Alternatively if we need both, then we can't have union and Russell's
> > idea seems good one :)
> 
> We don't need the union whatever way that goes.
Based on comment we need to support both.

> 
> The question over whether we have the src/dst fields is whether we want
> to support a different configuration for DMA_DEV_TO_MEM/DMA_MEM_TO_DEV
> without having to reconfigure the channel each time its direction is
> switched.
The biggest issue here is the design of the API. IMO the slave_config
should be passed along with respective prepare API for slave and not
thru separate slave config. That will remove the unnecessary limitation
and allow the same channel to be used for tx for one transfer and rx for
subsequent etc.

In the .device_prep_slave_sg() we should add the struct slave_config as
an argument. Obviously the slave_config will have _one_ pair of members
(not both src/dstn fields then).

For DMA_DEV_TO_DEV, anyway we need a new API, which can have both src
and dstn slave_config

Thoughts..?


-- 
~Vinod

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

Re: RFC: changing DMA slave configuration API

[Vinod Koul]

On Mon, 2012-06-11 at 17:33 +0800, Dong Aisheng wrote:
> > I think it is a good idea. And I would like to extend it even a
> little
> > bit. Do we have any users of peripheral to peripheral slave dma?
> Yes, IMX sdma does support such kind of transfer.
> The driver still does not support it currently.
> 
> > IIRC  that is not the case, or does anyone know of existence or
> plans
> > for such a h/w?
> > 
> i.MX5 and i.MX6. 

Thanks for confirming, lets keep both.

-- 
~Vinod

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

RE: [PATCH 1/3] ARM: OMAP2+: nand: unify init functions

[Mohammed, Afzal]

Hi Jon,

On Mon, Jun 11, 2012 at 21:13:45, Hunter, Jon wrote:

> Which boards have been tested with this change?

Beagle board

> Reviewed-by: Jon Hunter 

Thanks

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

Re: [PATCH v5 12/14] ARM: OMAP2+: gpmc: cs reconfigure helper

[Jon Hunter]

On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
> Helper for reconfiguring CS, peripheral that necessitated
> it was OneNAND.

Why? I think you need to add more about why this was needed.

Jon

> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   32 
> 
>  arch/arm/plat-omap/include/plat/gpmc.h |2 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 281bd23..d493a4c 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1429,6 +1429,38 @@ struct platform_device *gpmc_create_device(struct 
> gpmc_peripheral *p)
>   return pdev;
>  }
>  
> +static int gpmc_match_device(char *name, int id)
> +{
> + int i;
> + struct gpmc_peripheral *g_per = gpmc_peripheral;
> +
> + for (i = 0; i < gpmc_num_peripheral; i++, g_per++)
> + if (!strcmp(g_per->name, name) && g_per->id == id)
> + return i;
> +
> + return -ENOENT;
> +}
> +
> +int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c)
> +{
> + int i;
> +
> + i = gpmc_match_device(name, id);
> + if (IS_ERR_VALUE(i)) {
> + dev_err(gpmc_dev, "no device %s.%d to configure\n", name, id);
> + return i;
> + }
> +
> + if (IS_ERR_VALUE(gpmc_setup_cs_config_timing(gpmc_peripheral + i, c))) {
> + dev_err(gpmc_dev, "error: configure device %s.%d\n", name, id);
> + return i;
> + }
> +
> + return gpmc_setup_waitpin(gpmc_peripheral + i);
> +
> +}
> +EXPORT_SYMBOL_GPL(gpmc_cs_reconfigure);
> +
>  static __devinit int gpmc_probe(struct platform_device *pdev)
>  {
>   u32 l;
> diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
> b/arch/arm/plat-omap/include/plat/gpmc.h
> index e1b130c..32017a1 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc.h
> @@ -247,6 +247,8 @@ extern int gpmc_cs_configure(int cs, int cmd, int wval);
>  extern int gpmc_nand_read(int cs, int cmd);
>  extern int gpmc_nand_write(int cs, int cmd, int wval);
>  
> +extern int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c);
> +
>  int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size);
>  int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code);
>  
--
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 10/14] ARM: OMAP2+: gpmc: waitpin helper

[Jon Hunter]

On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
> Helper for configuring waitpin. There are two parts to it;
> configuring at CS level and the other at device level.
> A device embedding multiple CS has been provided the
> capability to use same waitpin (different waitpins has not
> been supported as presently there are no GPMC peripherals
> doing so)
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |  122 
> 
>  arch/arm/plat-omap/include/plat/gpmc.h |9 +++
>  2 files changed, 131 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 5a6f708..9073a8a 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -75,6 +75,8 @@
>  #define  GPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
>  #define  GPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
>  
> +#define  GPMC_CONFIG_WAITPIN_POLARITY_SHIFT  0x8
> +
>  #define GPMC_CS0_OFFSET  0x60
>  #define GPMC_CS_SIZE 0x30
>  
> @@ -93,6 +95,19 @@
>   */
>  #define  GPMC_NR_IRQ 2
>  
> +enum {
> + GPMC_WAITPIN_IDX0,
> + GPMC_WAITPIN_IDX1,
> + GPMC_WAITPIN_IDX2,
> + GPMC_WAITPIN_IDX3,
> + GPMC_NR_WAITPIN
> +};

Max number of wait pins is 3 for omap4/5. I know that we discussed this
in the past, but are you not supporting these devices are the moment? I
know that you have not done the hwmod for these, but still I was hoping
that you would take these into account.

> +
> +enum {
> + LOW,
> + HIGH
> +};

To be honest, I don't see the point in either of the above enums when
you have the definitions at the bottom. Seems that one set of
definitions should be enough.

>  struct gpmc_client_irq   {
>   unsignedirq;
>   u32 bitmask;
> @@ -140,6 +155,8 @@ struct gpmc_peripheral {
>   struct platform_device  *pdev;
>  };
>  
> +static unsigned gpmc_waitpin_map;
> +
>  static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
>  static struct irq_chip gpmc_irq_chip;
>  static unsigned gpmc_irq_start;
> @@ -1162,6 +1179,62 @@ static void gpmc_print_cs_timings(int cs)
>   gpmc_get_one_timing(cs, GPMC_CS_CONFIG6, 7, 7));
>  }
>  
> +static int gpmc_setup_cs_waitpin(struct gpmc_peripheral *g_per, unsigned cs,
> + unsigned conf)
> +{
> + unsigned idx;
> + bool polarity = 0;
> + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> +
> + switch (conf & GPMC_WAITPIN_MASK) {
> + case GPMC_WAITPIN_0:
> + idx =  GPMC_WAITPIN_IDX0;

For example, here you could have ...

idx = GPMC_WAITPIN_0 - 1;
> + break;
> + case GPMC_WAITPIN_1:
> + idx =  GPMC_WAITPIN_IDX1;
> + break;
> + case GPMC_WAITPIN_2:
> + idx =  GPMC_WAITPIN_IDX2;
> + break;
> + case GPMC_WAITPIN_3:
> + idx =  GPMC_WAITPIN_IDX3;
> + break;
> + /* no waitpin */
> + case 0:
> + return 0;
> + break;
> + default:
> + dev_err(gpmc_dev, "multiple waitpins selected on CS:%u\n", cs);
> + return -EINVAL;
> + break;
> + }
> +
> + polarity = !!(conf & GPMC_WAITPIN_ACTIVE_HIGH);
> +
> + if (g_per->have_waitpin) {
> + if (g_per->waitpin != idx ||
> + g_per->waitpin_polarity != polarity) {
> + dev_err(gpmc_dev, "error: conflict: waitpin %u with 
> polarity %d on device %s.%d\n",
> + g_per->waitpin, g_per->waitpin_polarity,
> + g_per->name, g_per->id);
> + return -EBUSY;
> + }
> + } else {
> + g_per->have_waitpin = true;
> + g_per->waitpin = idx;
> + g_per->waitpin_polarity = polarity;
> + }
> +
> + l |= conf & GPMC_CONFIG1_WAIT_WRITE_MON;
> + l |= conf & GPMC_CONFIG1_WAIT_READ_MON;
> + l &= ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
> + l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
> +
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
> +
> + return 0;
> +}
> +
>  static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
>  {
>   return bitmask;
> @@ -1185,6 +1258,55 @@ static __devinit int gpmc_setup_cs_irq(struct 
> gpmc_cs_data *cs,
>   return n;
>  }
>  
> +static inline int gpmc_waitpin_is_reserved(unsigned waitpin)
> +{
> + return gpmc_waitpin_map & (0x1 << waitpin);
> +}
> +
> +static inline void gpmc_reserve_waitpin(unsigned waitpin)
> +{
> + gpmc_waitpin_map &= ~(0x1 << waitpin);
> + gpmc_waitpin_map |= (0x1 << waitpin);
> +}
> +
> +static int gpmc_waitpin_request(unsigned waitpin)
> +{
> + if (!(waitpin < GPMC_NR_WAITPIN))
> + return -ENODEV;
> +
> + if (gpmc_waitpin_is_reserved(waitpin))
> + return -EBUSY;
> + else
> + gpmc_re

Re: [PATCH v5 09/14] ARM: OMAP2+: gpmc: holler if no configuration

[Jon Hunter]

On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
> Some of the GPMC peripherals depend on bootloader to do the
> configuration. This facility is deprecated, notify user
> about the present GPMC settings & inform that that relying
> on bootloader for GPMC setting is deprecated.

Nit, "holler" is slang. Just say WARN.

Jon

> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |  104 
> 
>  1 file changed, 104 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 65052f8..5a6f708 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -1058,6 +1058,110 @@ static void gpmc_cs_set_register_timings(int cs, 
> const struct gpmc_timings *t)
>   }
>  }
>  
> +static void gpmc_print_cs_config(int cs)
> +{
> + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> +
> + dev_warn(gpmc_dev, "GPMC CS%d depends on bootloader for config\n", cs);
> + dev_warn(gpmc_dev, "Please update it in Kernel ASAP to prevent losing 
> support for this peripheral\n");
> + dev_warn(gpmc_dev, "Bootloader dependency for GPMC configuration is 
> deprecated\n");
> +
> + dev_warn(gpmc_dev, "muxadddata: %s\n",
> + l & GPMC_CONFIG1_MUXADDDATA ? "yes" : "no");
> + dev_warn(gpmc_dev, "writetypesync: %s\n",
> + l & GPMC_CONFIG1_WRITETYPE_SYNC ? "yes" : "no");
> + dev_warn(gpmc_dev, "writemultiple: %s\n",
> + l & GPMC_CONFIG1_WRITEMULTIPLE_SUPP ? "yes" : "no");
> + dev_warn(gpmc_dev, "readtypesync: %s\n",
> + l & GPMC_CONFIG1_READTYPE_SYNC ? "yes" : "no");
> + dev_warn(gpmc_dev, "readmultiple: %s\n",
> + l & GPMC_CONFIG1_READMULTIPLE_SUPP ? "yes" : "no");
> + dev_warn(gpmc_dev, "wrapburst: %s\n",
> + l & GPMC_CONFIG1_WRAPBURST_SUPP ? "yes" : "no");
> + dev_warn(gpmc_dev, "devicetype: %s\n",
> + l & GPMC_CONFIG1_DEVICETYPE_NAND ? "nand" : "nor");
> + dev_warn(gpmc_dev, "devicesize: %d\n",
> + l & GPMC_CONFIG1_DEVICESIZE_16 ? 16 : 8);
> + dev_warn(gpmc_dev, "pagelength: %d\n",
> + l & GPMC_CONFIG1_PAGE_LEN(~0) ?
> + (l & GPMC_CONFIG1_PAGE_LEN_16 ? 16 : 8) : 4);
> +}
> +static inline unsigned gpmc_get_one_timing(int cs, int reg, int start, int 
> end)
> +{
> + u32 l = gpmc_cs_read_reg(cs, reg);
> + unsigned mask;
> +
> + mask = (1 << (end - start + 1)) - 1;
> + l &= (mask << start);
> + return l >>= start;
> +}
> +
> +static void gpmc_print_cs_timings(int cs)
> +{
> + dev_warn(gpmc_dev, "GPMC CS%d depends on bootloader for timing\n", cs);
> + dev_warn(gpmc_dev, "Please update it in Kernel ASAP to prevent losing 
> support for this peripheral\n");
> + dev_warn(gpmc_dev, "Bootloader dependency for GPMC configuration is 
> deprecated\n");
> +
> + dev_warn(gpmc_dev, "fclk period: %lups\n", gpmc_get_fclk_period());
> + dev_warn(gpmc_dev, "sync_clk: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 0, 1));
> + dev_warn(gpmc_dev, "wait_monitoring: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 18, 19));
> + dev_warn(gpmc_dev, "clk_activation: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 25, 26));
> + dev_warn(gpmc_dev, "cs_on: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 0, 3));
> + dev_warn(gpmc_dev, "cs_rd_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 8, 12));
> + dev_warn(gpmc_dev, "cs_wr_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 16, 20));
> + dev_warn(gpmc_dev, "adv_on: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 0, 3));
> + dev_warn(gpmc_dev, "adv_rd_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 8, 12));
> + dev_warn(gpmc_dev, "adv_wr_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 16, 20));
> + dev_warn(gpmc_dev, "oe_on: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 0, 3));
> + dev_warn(gpmc_dev, "oe_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 8, 12));
> + dev_warn(gpmc_dev, "we_on: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 16, 19));
> + dev_warn(gpmc_dev, "we_off: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 24, 28));
> + dev_warn(gpmc_dev, "rd_cycle: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 0, 4));
> + dev_warn(gpmc_dev, "wr_cycle: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 8, 12));
> + dev_warn(gpmc_dev, "acess: %u\n",
> + gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 16, 20));
> + dev_warn(gpmc_dev, "page_burst_access: %u\n",
> +   

Re: [PATCH v5 08/14] ARM: OMAP2+: gpmc: bool type timing helper

[Jon Hunter]

On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
> Some of the timing configuration like extra delay
> has bool type configurations. Provide a helper so
> that these too can be configured in Kernel.
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   55 
> 
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index e60076e3..65052f8 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -68,6 +68,13 @@
>  #define GPMC_ECC_CTRL_ECCREG80x008
>  #define GPMC_ECC_CTRL_ECCREG90x009
>  
> +#define  GPMC_CONFIG2_CSEXTRADELAY   BIT(7)
> +#define  GPMC_CONFIG3_ADVEXTRADELAY  BIT(7)
> +#define  GPMC_CONFIG4_OEEXTRADELAY   BIT(7)
> +#define  GPMC_CONFIG4_WEEXTRADELAY   BIT(23)
> +#define  GPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
> +#define  GPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
> +
>  #define GPMC_CS0_OFFSET  0x60
>  #define GPMC_CS_SIZE 0x30
>  
> @@ -960,6 +967,54 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned 
> conf)
>   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
>  }
>  
> +static void gpmc_cs_misc_timings(int cs, const struct gpmc_misc_timings *p)
> +{
> + u32 l;
> +
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> + if (p->time_para_granularity)
> + l |= GPMC_CONFIG1_TIME_PARA_GRAN;
> + else
> + l &= ~GPMC_CONFIG1_TIME_PARA_GRAN;
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
> +
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
> + if (p->cs_extra_delay)
> + l |= GPMC_CONFIG2_CSEXTRADELAY;
> + else
> + l &= ~GPMC_CONFIG2_CSEXTRADELAY;
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, l);
> +
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
> + if (p->adv_extra_delay)
> + l |= GPMC_CONFIG3_ADVEXTRADELAY;
> + else
> + l &= ~GPMC_CONFIG3_ADVEXTRADELAY;
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, l);
> +
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
> + if (p->oe_extra_delay)
> + l |= GPMC_CONFIG4_OEEXTRADELAY;gpmc_cs_misc_timings
> + else
> + l &= ~GPMC_CONFIG4_OEEXTRADELAY;
> + if (p->we_extra_delay)
> + l |= GPMC_CONFIG4_WEEXTRADELAY;
> + else
> + l &= ~GPMC_CONFIG4_WEEXTRADELAY;
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, l);
> +
> + l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG6);
> + if (p->cycle2cyclesamecsen)
> + l |= GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
> + else
> + l &= ~GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
> + if (p->cycle2cyclediffcsen)
> + l |= GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
> + else
> + l &= ~GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
> + gpmc_cs_write_reg(cs, GPMC_CS_CONFIG6, l);
> +}

How about adding a sub-function like ...

static inline
void _gpmc_cs_misc_timings(int cs, int reg, int flag, int bit)
{
if (flag)
gpmc_set_one_timing(cs, reg, bit, bit, 1);
else
gpmc_set_one_timing(cs, reg, bit, bit, 0);
}

Or maybe make it into a generic set/clear bit function. Should reduce
overall lines of code.

Cheers
Jon
--
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 06/14] ARM: OMAP2+: gpmc: CS configuration helper

[Jon Hunter]

On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> Helper for configuring given CS based on flags.
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   33 
> 
>  arch/arm/plat-omap/include/plat/gpmc.h |5 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 652b245..4e19010 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -927,6 +927,39 @@ static __devinit int gpmc_setup_cs_mem(struct 
> gpmc_cs_data *cs,
>   return 1;
>  }
>  
> +static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
> +{
> + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);

Why is it necessary to read the register first? I thought you wanted to
get away from relying on bootloader settings?

> + l &= ~(GPMC_CONFIG1_MUXADDDATA |
> + GPMC_CONFIG1_WRITETYPE_SYNC |
> + GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
> + GPMC_CONFIG1_READTYPE_SYNC |
> + GPMC_CONFIG1_READMULTIPLE_SUPP |
> + GPMC_CONFIG1_WRAPBURST_SUPP |
> + GPMC_CONFIG1_DEVICETYPE(~0) |
> + GPMC_CONFIG1_DEVICESIZE(~0) |
> + GPMC_CONFIG1_PAGE_LEN(~0));
> +
> + l |= conf & GPMC_CONFIG1_DEVICETYPE_NAND;
> + l |= conf & GPMC_CONFIG1_DEVICESIZE_16;

I can see that it works to use the above definitions as masks because of
the possible values that can be programmed into these fields. However,
from a read-ability standpoint this is unclear and requires people to
review the documentation to understand what you are doing here.
Furthermore, if any new device-types or sizes were added in the future
this could lead to bugs. Hence, it would be better to define a mask for
these fields.

Now you may say what happens if someone pass a bad device-type or
device-size that would equate to a reserved value being programmed. Well
if someone passes a bad value we don't know what they intended to
program and that raises the question should we be checking the conf
value of bad device types, size, and page lengths here?

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

Re: [PATCH 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules

[Cousson, Benoit]

On 6/11/2012 7:26 PM, Paul Walmsley wrote:

On Mon, 11 Jun 2012, Benoit Cousson wrote:


The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.

Replace them with the proper wkup, l4_ao and l4_cfg.


This does not match either the publicly avaiable documentation and the
internal NDA hardware specifications[1].


That's almost true, until I realized that the clock domain modules list 
contain this information (clock.py/clock_domain['l4_wkup']['modules']).
Now, I'm wondering as well why this is not documented better. I'll check 
that tomorrow.



Nor does it make sense from a logical perspective.


I do think it does.


To take an example from your patch:


@@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info omap44xx_prm_resets[] 
= {
  static struct omap_hwmod omap44xx_prm_hwmod = {
.name   = "prm",
.class  = &omap44xx_prcm_hwmod_class,
-   .clkdm_name = "prm_clkdm",
+   .clkdm_name = "l4_wkup_clkdm",
.mpu_irqs   = omap44xx_prm_irqs,
.rst_lines  = omap44xx_prm_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_prm_resets),
  };


There is no possible way that the PRM can exist in the L4_WKUP
clockdomain.  The L4_WKUP clockdomain must be able to go inactive for the
chip to enter idle, as we just discussed[1].  But the PRM is the
entity that supervises chip wakeup from off-mode, so for off-mode
to work, there's no way that the PRM can be clock-gated.


OK, so let's replace PRM by GPT1, without the part that is not 
applicable in that case:


"There is no possible way that the GPT1 can exist in the L4_WKUP 
clockdomain. The L4_WKUP clockdomain must be able to go inactive for the

chip to enter idle, as we just discussed[1] ... so for off-mode
to work, there's no way that the GPT1 can be clock-gated."

Don't you think that this sentence looks wrong now?
Why can the GPT1 run during OFF mode and not the PRM?

The wkup domain is far from being a standard domain. The 32k is always 
running even in OFF mode. So for the same reason, that domain can go to 
inactive without gating the 32k. This is clearly not a standard domain 
but that does not make it a bad one either.


All the IPs that belongs to the l4_wkup are all active during OFF mode, 
so is the PRM. The point discussed in [1] clearly show that the domain 
inactive state in the case of the wakeup is just used for the OCP clock. 
The functional 32k is still active during OFF mode.



Frustrating :-(


You should not, I'm happy we were able to figured out where these PRCM 
IPs are located after all these years :-)



Fix as well the wrong OCP port used by the cm_core_aon. It uses the
l4_cfg interconnect and not the l4_wkup.

Re-order the entries by address value.


If you split this part off into a separate patch, I'll take it.


You should take both since this patch is perfectly valid as explained 
previously.


cm_clkdm does not exist either whereas l4_aon / l4_cfg does. And 
honestly considering that the core_cm_aon is inside a domain names 
l4_aon does not seems stupid at all.


The more or less accurate definition of the PRCM clock domain since ever 
is that a domain is mostly a group of IPs and the related clocks that 
does belong to the same interconnect. So it makes sense that the cm_core 
(CM2), cm_core_aon (CM1) and prm does belong to the domain that contains 
its respective interconnect.


Regards,
Benoit



- Paul

1. Cousson, Benoît.  _Re: [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K
sync timer_.  linux-omap@vger.kernel.org mailing list.  Available from
http://www.spinics.net/lists/arm-kernel/msg177128.html (among others).




--
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 05/14] ARM: OMAP2+: gpmc: resource creation helpers

[Jon Hunter]

On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> Helpers for propulating given resource structure
> with memory & interrupt information.
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   45 
> 
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index a91f40f..652b245 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -905,6 +905,51 @@ static void __devinit gpmc_mem_init(void)
>   }
>  }
>  
> +static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs,
> + struct resource *res)
> +{
> + unsigned long start;
> + int ret;
> +
> + ret = gpmc_cs_request(cs->cs, cs->mem_size, &start);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(gpmc_dev, "error: gpmc request on CS: %d\n", cs->cs);
> + return ret;
> + }
> +
> + res->start = start + cs->mem_offset;
> + res->end = res->start + cs->mem_size - 1;
> + res->flags = IORESOURCE_MEM;
> +
> + dev_info(gpmc_dev, "memory 0x%x-0x%x on CS %d\n", res->start,
> + res->end, cs->cs);
> +
> + return 1;
> +}

Nit-pick, CodingStyle chapter 16 states that 0 should be used for
success when returning from a function.

> +
> +static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
> +{
> + return bitmask;
> +}

I have to ask what is the value in this helper function? ;-)

Jon
--
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 04/14] ARM: OMAP2+: gpmc: minimal driver support

[Jon Hunter]

On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> Create a minimal driver out of gpmc code.
> Responsibilities handled by earlier gpmc
> initialization is now achieved in probe.
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |  170 
> 
>  1 file changed, 123 insertions(+), 47 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 6dbddb9..a91f40f 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -31,6 +32,8 @@
>  
>  #include 
>  
> +#define  DRIVER_NAME "omap-gpmc"
> +
>  /* GPMC register offsets */
>  #define GPMC_REVISION0x00
>  #define GPMC_SYSCONFIG   0x10
> @@ -115,6 +118,21 @@ struct omap3_gpmc_regs {
>   struct gpmc_cs_config cs_context[GPMC_CS_NUM];
>  };
>  
> +struct gpmc_peripheral {
> + char*name;
> + int id;
> + void*pdata;
> + unsignedpdata_size;
> + struct resource *per_res;
> + unsignedper_res_cnt;
> + struct resource *gpmc_res;
> + unsignedgpmc_res_cnt;
> + boolhave_waitpin;
> + boolwaitpin_polarity;
> + unsignedwaitpin;
> + struct platform_device  *pdev;
> +};
> +
>  static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
>  static struct irq_chip gpmc_irq_chip;
>  static unsigned gpmc_irq_start;
> @@ -124,6 +142,10 @@ static struct resource   gpmc_cs_mem[GPMC_CS_NUM];
>  static DEFINE_SPINLOCK(gpmc_mem_lock);
>  static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
>  static int gpmc_ecc_used = -EINVAL;  /* cs using ecc engine */
> +static struct device *gpmc_dev;
> +static u32 gpmc_revision;
> +static int gpmc_irq;
> +static resource_size_t phys_base, mem_size;
>  
>  static void __iomem *gpmc_base;
>  
> @@ -433,6 +455,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long 
> base, unsigned long size)
>   return r;
>  }
>  
> +static int gpmc_cs_delete_mem(int cs)
> +{
> + struct resource *res = &gpmc_cs_mem[cs];
> + int r;
> +
> + spin_lock(&gpmc_mem_lock);
> + r = release_resource(&gpmc_cs_mem[cs]);
> + res->start = res->end = 0;
> + spin_unlock(&gpmc_mem_lock);
> +
> + return r;
> +}
> +
>  int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
>  {
>   struct resource *res = &gpmc_cs_mem[cs];
> @@ -769,7 +804,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
>  
>  static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
>  
> -static int gpmc_setup_irq(int gpmc_irq)
> +static int gpmc_setup_irq(void)
>  {
>   int i;
>   u32 regval;
> @@ -813,7 +848,37 @@ static int gpmc_setup_irq(int gpmc_irq)
>   return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
>  }
>  
> -static void __init gpmc_mem_init(void)
> +static __exit int gpmc_free_irq(void)
> +{
> + int i;
> +
> + if (gpmc_irq)
> + free_irq(gpmc_irq, NULL);
> +
> + for (i = 0; i < GPMC_NR_IRQ; i++) {
> + irq_set_handler(gpmc_client_irq[i].irq, NULL);
> + irq_set_chip(gpmc_client_irq[i].irq, &no_irq_chip);
> + irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
> + }
> +
> + irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
> +
> + return 0;
> +}
> +
> +static void __devexit gpmc_mem_exit(void)
> +{
> + int cs;
> +
> + for (cs = 0; cs < GPMC_CS_NUM; cs++) {
> + if (!gpmc_cs_mem_enabled(cs))
> + continue;
> + gpmc_cs_delete_mem(cs);
> + }
> +
> +}
> +
> +static void __devinit gpmc_mem_init(void)
>  {
>   int cs;
>   unsigned long boot_rom_space = 0;
> @@ -840,64 +905,75 @@ static void __init gpmc_mem_init(void)
>   }
>  }
>  
> -static int __init gpmc_init(void)
> +static __devinit int gpmc_probe(struct platform_device *pdev)
>  {
>   u32 l;
> - int ret = -EINVAL;
> - int gpmc_irq;
> - char *ck = NULL;
> -
> - if (cpu_is_omap24xx()) {
> - ck = "core_l3_ck";
> - if (cpu_is_omap2420())
> - l = OMAP2420_GPMC_BASE;
> - else
> - l = OMAP34XX_GPMC_BASE;
> - gpmc_irq = INT_34XX_GPMC_IRQ;
> - } else if (cpu_is_omap34xx()) {
> - ck = "gpmc_fck";
> - l = OMAP34XX_GPMC_BASE;
> - gpmc_irq = INT_34XX_GPMC_IRQ;
> - } else if (cpu_is_omap44xx()) {
> - ck = "gpmc_ck";
> - l = OMAP44XX_GPMC_BASE;
> - gpmc_irq = OMAP44XX_IRQ_GPMC;
> - }
> + struct resource *res;
>  
> - if (WARN_ON(!ck))
> - return ret;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (re

Re: RFC: changing DMA slave configuration API

[David Brown]

On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:

> I think it is a good idea. And I would like to extend it even a little
> bit. Do we have any users of peripheral to peripheral slave dma?
> IIRC  that is not the case, or does anyone know of existence or plans
> for such a h/w?

We have hardware that supports this, and I suspect it will become more
common in our future chips.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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 03/14] ARM: OMAP2+: gpmc: driver migration helper

[Jon Hunter]

Hi Afzal,

On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> A driver is being created out of GPMC code. This is being
> attempted to acheive by not breaking existing interface,
> necessitating requirement of GPMC peripherals being able
> to work with as well as without the help of driver. To not
> break existing, initcall is required as in old interface
> GPMC is configured at arch initcall and GPMC should be
> ready to handle old interface by that time
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index b471c2f..6dbddb9 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -902,7 +902,7 @@ postcore_initcall(gpmc_init);
>  __init int omap_gpmc_init(struct gpmc_pdata *pdata)
>  {
>   struct omap_hwmod *oh;
> - struct platform_device *pdev;
> + static struct platform_device *pdev;
>   char *name = "omap-gpmc";
>   char *oh_name = "gpmc";
>  
> @@ -912,6 +912,12 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
>   return -ENODEV;
>   }
>  
> + if (pdev != NULL) {
> + clk_put(gpmc_l3_clk);
> + omap_device_delete(pdev->archdata.od);
> + platform_device_unregister(pdev);
> + }
> +

I am not sure if I am missing something, but it appears that pdev will
always be NULL here as it is a local uninitialised variable.

>   pdev = omap_device_build(name, -1, oh, pdata,
>   sizeof(*pdata), NULL, 0, 0);
>   if (IS_ERR(pdev)) {
> @@ -929,6 +935,17 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
>   return 0;
>  }
>  
> +static int __init gpmc_pre_init(void)
> +{
> + static struct gpmc_device_pdata *gpmc_device_data[1];
> + struct gpmc_pdata gpmc_data = {
> + .device_pdata   = gpmc_device_data,
> + };
> +
> + return omap_gpmc_init(&gpmc_data);
> +}
> +postcore_initcall(gpmc_pre_init);
> +

Not sure I see the point in the above function. Why not declare the
gpmc_device_data struct as static in the file and access it directly
instead of passing it in omap_gpmc_init(). The postcore_init can then
call omap_gpmc_init() directly.

Shouldn't the post_initcall be added in patch #4, when the driver is
created?

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

Re: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks

[Cousson, Benoit]

On 6/11/2012 6:59 PM, Paul Walmsley wrote:

On Mon, 11 Jun 2012, Cousson, Benoit wrote:


In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4
:-(.

I've just realized that you introduced that for 3.5, but this is wrong.
We should not start adding some fake clock domains just because the fmwk
is not smart enough to allow a NULL clock domain.



...


In a period of data size reduction, adding some fake information does
not seems to be the right approach. Don't you think so?


No, I do not.

These clockdomains are clearly documented in both the OMAP4 TRM[1]
and the NDA OMAP4 PRCM functional specifications.


Sorry for the confusion; I was just referring to the prm_clkdm and cm_clkdm.


I continue to be baffled as to why you assert that they are fake, given
how clearly they are documented.


In that case the clock domains are valid, but that does not change the 
fact that they are useless, at least for the moment.
The PRCM is already taking care of managing properly the domains based 
on module activity. Adding that to the clocks nodes is not wrong, but 
does add an information that is a duplication of what the HW is already 
doing.
That's why we should populate that information only if this is needed, 
like it was the case for the DPLL, but it should remain optional.


Regards,
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 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Jon Hunter]

Hi Afzal,

On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> Create API for platforms to adapt gpmc to HWMOD
> 
> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |   31 +++
>  arch/arm/plat-omap/include/plat/gpmc.h |2 ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 517953f..b471c2f 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -898,6 +899,36 @@ static int __init gpmc_init(void)
>  }
>  postcore_initcall(gpmc_init);
>  
> +__init int omap_gpmc_init(struct gpmc_pdata *pdata)
> +{
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> + char *name = "omap-gpmc";
> + char *oh_name = "gpmc";
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name);
> + return -ENODEV;
> + }
> +
> + pdev = omap_device_build(name, -1, oh, pdata,
> + sizeof(*pdata), NULL, 0, 0);
> + if (IS_ERR(pdev)) {
> + WARN(1, "Can't build omap_device for %s:%s.\n",
> + name, oh->name);
> + return PTR_ERR(pdev);
> + }
> +
> + gpmc_l3_clk = clk_get(NULL, oh->main_clk);
> + if (IS_ERR(gpmc_l3_clk)) {
> + pr_err("Could not get GPMC clock\n");
> + return PTR_ERR(gpmc_l3_clk);
> + }

My preference would be to store gpmc_l3_clk in the pdata and pass to
probe via the pdata. The aim would be to remove the global gpmc_l3_clk
altogether.

Also we should attempt to get the clk before calling omap_device_build
which is registering the driver.

Cheers
Jon
--
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 01/10] ARM: PMU: Add runtime PM Support

[Jon Hunter]

Hi Will,

On 06/11/2012 12:39 PM, Will Deacon wrote:
> On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
>> Hi Will,
> 
> Hi Jon,
> 
>> Here is an updated version. I was going to send out a V3, but I wanted
>> to wait to see if others had more comments first.
> 
> This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!)
> and noticed that only the cycle counter seems to tick -- the event counters
> always return 0 deltas (that is, they don't increment). Booting the same SD
> card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the
> event counters function correctly there.

Thanks for the feedback. Being somewhat new to PMU, I was mainly using
PERF to test and verify that with "perf top" I was seeing interrupts.
How do I check what the event counters are returning? Any perf tests I
could use?

By the way, as a quick test you could modify the code in omap_init_pmu()
to call omap4430_init_pmu() for all omap4 devices as follows ...

if (cpu_is_omap44xx())
return omap4430_init_pmu();

I was hoping for 4460/70 we would not need to keep the debugss and other
domains on and hence, I called the above function omap4430_init_pmu().
However this function works for all omap4 devices, it just turns on more
power domains.

> It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these
> patches but I don't have any OMAP3 hardware to check if we get any regressions
> on older platforms. Do your patches only deal with OMAP4?

It *should* work for all omap2+. So far I have tested an omap3 beagle
but I have not tested an omap2 device. Again the extent of my testing
was to run "perf top" and verify interrupts we being generated. I
realise that this may not be sufficient and so if you have a more
exhaustive test you recommend let me know.

Cheers
Jon

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

Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

[Jon Hunter]

Hi Afzal,

On 06/11/2012 09:02 AM, Afzal Mohammed wrote:
> Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
> clkactivationtime in gpmc_cs_set_timings(). This is done so
> that boards can configure these parameters of gpmc in Kernel
> instead of relying on bootloader.

What boards have been tested with this change?

Tony is going to want to know what we have tested with such changes to
avoid any regressions.

> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc.c |6 ++
>  arch/arm/plat-omap/include/plat/gpmc.h |6 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 578fd4c..517953f 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct 
> gpmc_timings *t)
>  
>   GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
>  
> + GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
> + GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
> +
> + GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
> + GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
> +
>   if (cpu_is_omap34xx()) {
>   GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
>   GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
> diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
> b/arch/arm/plat-omap/include/plat/gpmc.h
> index 2e6e259..802fb22 100644
> --- a/arch/arm/plat-omap/include/plat/gpmc.h
> +++ b/arch/arm/plat-omap/include/plat/gpmc.h
> @@ -128,6 +128,12 @@ struct gpmc_timings {
>   u16 rd_cycle;   /* Total read cycle time */
>   u16 wr_cycle;   /* Total write cycle time */
>  
> + u16 bus_turnaround;
> + u16 cycle2cycle_delay;
> +
> + u16 wait_monitoring;
> + u16 clk_activation;
> +
>   /* The following are only on OMAP3430 */
>   u16 wr_access;  /* WRACCESSTIME */
>   u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */

In general, I agree with this, but if we apply this today, it seems that
we *may* be clearing these fields if they have been configured by the
bootloader and hence this could introduce a regression (potentially).

So we ever need to test boards that this change impacts or at least
verify that this change would not impact these boards because these
fields have not been configured.

Cheers
Jon
--
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/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

[Jon Hunter]

Hi Afzal,

On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
> Reorganize gpmc-onenand initialization so that changes
> required for gpmc driver migration can be made smooth.
> 
> Ensuring sync read/write are disabled in onenand cannot be
> expect to work properly unless GPMC is setup, this has been
> removed. 

So I think I see what you are saying, but the above is not 100% clear. I
think that what you are saying is that omap2_onenand_set_async_mode() is
attempting to configure the onenand registers before configuring the
gpmc interface and hence this is not correct.

> Two instances of doing the same has been clubbed
> into one as onenand driver always calls indirectly
> "omap2_onenand_set_sync_mode", and has placed such that
> configuring onenand for async read/write would happen once
> GPMC is setup for async mode (which happens even for sync
> mode, before configuring to sync mode).

It may be clearer to say that _set_sync_mode is always called during
onenand setup and this will call _set_async_mode. So instead of calling
_set_async_mode from _set_sync_mode, just call it directly during the
gpmc_onenand_init().

> Signed-off-by: Afzal Mohammed 
> ---
>  arch/arm/mach-omap2/gpmc-onenand.c |   24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
> b/arch/arm/mach-omap2/gpmc-onenand.c
> index 71d7c07..fd4c48d 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
>   .resource   = &gpmc_onenand_resource,
>  };
>  
> -static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
> +static int omap2_onenand_set_async_mode(int cs)
>  {
>   struct gpmc_timings t;
> - u32 reg;
>   int err;
>  
>   const int t_cer = 15;
> @@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void 
> __iomem *onenand_base)
>   const int t_wpl = 40;
>   const int t_wph = 30;
>  
> - /* Ensure sync read and sync write are disabled */
> - reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> - reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> - writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> -
>   memset(&t, 0, sizeof(t));
>   t.sync_clk = 0;
>   t.cs_on = 0;
> @@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void 
> __iomem *onenand_base)
>   if (err)
>   return err;
>  
> - /* Ensure sync read and sync write are disabled */
> - reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> - reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> - writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);

I agree with getting rid of the first instance at the beginning of
_set_async_mode, but why get rid of the above one? Are you assuming that
by default it is in async mode? Could be nice to keep it to be explicit.

>   return 0;
>  }
> @@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct 
> omap_onenand_platform_data *cfg,
>   u32 reg;
>   bool clk_dep = false;
>  
> + /* Ensure sync read and sync write are disabled */
> + reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> + reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
> + writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
> +

Should we only set these after we have checked the flags and depending
on which flags are set?

>   if (cfg->flags & ONENAND_SYNC_READ) {
>   sync_read = 1;
>   } else if (cfg->flags & ONENAND_SYNC_READWRITE) {
>   sync_read = 1;
>   sync_write = 1;
>   } else
> - return omap2_onenand_set_async_mode(cs, onenand_base);
> + return 0;
>  
>   if (!freq) {
>   /* Very first call freq is not known */
> - err = omap2_onenand_set_async_mode(cs, onenand_base);
> - if (err)
> - return err;
>   freq = omap2_onenand_get_freq(cfg, onenand_base, &clk_dep);
>   first_time = 1;
>   }
> @@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct 
> omap_onenand_platform_data *_onenand_data)
>   gpmc_onenand_resource.end = gpmc_onenand_resource.start +
>   ONENAND_IO_SIZE - 1;
>  
> + omap2_onenand_set_async_mode(gpmc_onenand_data->cs);
> +

What about putting this in the gpmc_onenand_setup() function before the
call to _set_sync_mode? Seems nice to have these together.

Cheers
Jon
--
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 01/10] ARM: PMU: Add runtime PM Support

[Will Deacon]

On Fri, Jun 08, 2012 at 04:24:32PM +0100, Jon Hunter wrote:
> Hi Will,

Hi Jon,

> Here is an updated version. I was going to send out a V3, but I wanted
> to wait to see if others had more comments first.

This looks better to me, so I took it for a spin on my 4460 (thanks Nicolas!)
and noticed that only the cycle counter seems to tick -- the event counters
always return 0 deltas (that is, they don't increment). Booting the same SD
card on a 4430 (same MLO, u-boot, kernel and filesystem) I see that the
event counters function correctly there.

It also seems that we can remove the dependency on CONFIG_OMAP3_EMU with these
patches but I don't have any OMAP3 hardware to check if we get any regressions
on older platforms. Do your patches only deal with OMAP4?

Cheers,

Will
--
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: [PATCHv10 00/11] I2C fixes

[Shubhrajyoti]

On Monday 11 June 2012 09:30 PM, Wolfram Sang wrote:
>> Agree,
>> > These are only fixes can it be considered for rc3?
> "Baking in linux-next" and "considering rc3" don't match; baking needs
> time, rc3 is soon. I've put the patches now into my -next branch for
> more exposure.
Thanks.
>  I am still uncertain if they should be in 3.5 already;
> there seem to be worhty fixes in there, but they do depend on stuff
> which don't really qualify as bugfixes...


--
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] Revert "ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common"

[Paul Walmsley]

On Mon, 11 Jun 2012, Benoit Cousson wrote:

> Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
> Remove the common definition that does not make sense anymore
> since it is not common for OMAP2+ platforms.
> 
> Please note that these clock domains are probably non existant
> on OMAP 2 & 3 and thus should be removed in all the
> clockdomain files.

For the archives:

http://marc.info/?l=linux-omap&m=133943578712129&w=2


- 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 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules

[Paul Walmsley]

On Mon, 11 Jun 2012, Benoit Cousson wrote:

> The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
> the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
> The clkdm entry are not the correct ones and does not exist in the system.
> 
> Replace them with the proper wkup, l4_ao and l4_cfg.

This does not match either the publicly avaiable documentation and the 
internal NDA hardware specifications[1].

Nor does it make sense from a logical perspective.  To take an example 
from your patch:

> @@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info 
> omap44xx_prm_resets[] = {
>  static struct omap_hwmod omap44xx_prm_hwmod = {
>   .name   = "prm",
>   .class  = &omap44xx_prcm_hwmod_class,
> - .clkdm_name = "prm_clkdm",
> + .clkdm_name = "l4_wkup_clkdm",
>   .mpu_irqs   = omap44xx_prm_irqs,
>   .rst_lines  = omap44xx_prm_resets,
>   .rst_lines_cnt  = ARRAY_SIZE(omap44xx_prm_resets),
>  };

There is no possible way that the PRM can exist in the L4_WKUP 
clockdomain.  The L4_WKUP clockdomain must be able to go inactive for the 
chip to enter idle, as we just discussed[1].  But the PRM is the 
entity that supervises chip wakeup from off-mode, so for off-mode 
to work, there's no way that the PRM can be clock-gated.

Frustrating :-(

> Fix as well the wrong OCP port used by the cm_core_aon. It uses the
> l4_cfg interconnect and not the l4_wkup.
> 
> Re-order the entries by address value.

If you split this part off into a separate patch, I'll take it.


- Paul

1. Cousson, Benoît.  _Re: [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K 
   sync timer_.  linux-omap@vger.kernel.org mailing list.  Available from 
   http://www.spinics.net/lists/arm-kernel/msg177128.html (among others).

Re: [PATCH 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data

[Vaibhav Hiremath]

On 6/11/2012 9:40 PM, Paul Walmsley wrote:
> Hi Vaibhav,
> 
> On Mon, 11 Jun 2012, Vaibhav Hiremath wrote:
> 
>> I think this is not required, since Tony has already accepted the patch
>> which has this implementation (available on linux-omap/master).
>> Please refer to the commit,
>>
>> commit 08f3098928c991560408e8c71d4af8b1a3ff2d67
>> Author: Afzal Mohammed 
>> Date:   Fri May 11 00:38:49 2012 +0530
>>
>> ARM: OMAP2+: am33xx: Add AM335XEVM machine support
> 
> Thanks, that's what I need.  Looks like our series needs to be based on 
> this commit, rather than mainline.
> 

Yes, its already done. As you know I maintain this branch which always
follows mainline and also integrates all the changes discussed on the list -

https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging

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

Re: Broken builds

[Tomi Valkeinen]

On Mon, 2012-06-11 at 17:09 +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote:

> > Tomi, please have your patches sitting in linux next for at least a
> > week before they get merged. That usually shakes down bugs like these
> > before the merge window.
> 
> Note that tested simple bug fixes _should_ be upstreamed faster than
> that where possible - such as this one.
> 
> I'm waiting for this to hit mainline before doing any further work on
> OMAP.  That basically means I've been totally ignoring OMAP because of
> this issue for the last week.

Okay. Perhaps I should have sent the patch directly to Linus, instead of
sending a pull request to fbdev maintainer. There's always a possibility
of delays with intermediate trees.

Then again, I don't see that it's such a big problem that I'd want to
skip the normal route for patches. Sure the bug is annoying, but one can
easily avoid the bug by just enabling CONFIG_DEBUG_FS and
CONFIG_OMAP2_DSS_DEBUG_SUPPORT.

I've now improved my testing process, and I hope things will go smoother
during the next merge window. Sorry about the mess.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: Broken builds

[Tomi Valkeinen]

On Mon, 2012-06-11 at 17:06 +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote:
> > Hi,
> > 
> > On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux  [120603 11:05]:
> > > > Looks like the DSS stuff has broken OMAP builds again during this
> > > > merge window:
> > > > 
> > > > drivers/video/omap2/dss/core.c:197: error: static declaration of 
> > > > 'dss_debugfs_create_file' follows non-static declaration
> > > > drivers/video/omap2/dss/dss.h:166: error: previous declaration of 
> > > > 'dss_debugfs_create_file' was here
> > > > 
> > > > Both the OMAP3 and OMAP4 builds break with these two errors.
> > > 
> > > Here's a patch for Tomi to fix this one.
> > 
> > I have a patch for this in my for-rc branch. It just missed the main
> > merge. I'll send this and a few other fixes today for the next rc.
> > 
> > Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled.
> > That's why I didn't notice it until too late.
> 
> So... where are we with this?  Apparantly not much further forward;
> it seems to be in linux-next but still not in mainline, and mainline
> continues to be broken.

The fixes have been pulled into fbdev tree, but it missed the -rc2.
Fbdev maintainer said "I merged this some days ago. Sorry that I didn't
realize that rc2 would be released early and hence didn't manage to get
it in."

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks

[Paul Walmsley]

On Mon, 11 Jun 2012, Cousson, Benoit wrote:

> In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 
> :-(.
> 
> I've just realized that you introduced that for 3.5, but this is wrong. 
> We should not start adding some fake clock domains just because the fmwk 
> is not smart enough to allow a NULL clock domain.
> 

...

> In a period of data size reduction, adding some fake information does 
> not seems to be the right approach. Don't you think so?

No, I do not.

These clockdomains are clearly documented in both the OMAP4 TRM[1]
and the NDA OMAP4 PRCM functional specifications.

I continue to be baffled as to why you assert that they are fake, given 
how clearly they are documented.


- Paul

1. See for example sections 3.6.6.1 "Overview", Figure 3-58 "CD_L4_PER 
Overview", Figure 3-59 "CD_L3_INIT Overview", Figure 3-62 "CD_EMU 
Overview", Figure 3-63 "CD_DSS Overview", Figure 3-74 "CD_L4_ALWON_CORE 
Overview" in the OMAP4 TRM Rev. AA (SWPU231AA).

--
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/2] Revert "ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common"

[Benoit Cousson]

This reverts commit 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c.

Conflicts:

arch/arm/mach-omap2/Makefile

Neither prm_clkdm nor cm_clkdm does exist on OMAP4.
Remove the common definition that does not make sense anymore
since it is not common for OMAP2+ platforms.

Please note that these clock domains are probably non existant
on OMAP 2 & 3 and thus should be removed in all the
clockdomain files.

Signed-off-by: Benoit Cousson 
---
 arch/arm/mach-omap2/Makefile |1 -
 arch/arm/mach-omap2/clockdomain44xx.c|6 -
 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |   10 +
 arch/arm/mach-omap2/clockdomains44xx_data.c  |2 -
 arch/arm/mach-omap2/clockdomains_common_data.c   |   24 --
 5 files changed, 10 insertions(+), 33 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..bc7d239 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -116,7 +116,6 @@ obj-$(CONFIG_ARCH_OMAP4)+= 
powerdomains44xx_data.o
 
 # PRCM clockdomain control
 clockdomain-common += clockdomain.o
-clockdomain-common += clockdomains_common_data.o
 obj-$(CONFIG_ARCH_OMAP2)   += $(clockdomain-common)
 obj-$(CONFIG_ARCH_OMAP2)   += clockdomain2xxx_3xxx.o
 obj-$(CONFIG_ARCH_OMAP2)   += clockdomains2xxx_3xxx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c 
b/arch/arm/mach-omap2/clockdomain44xx.c
index 4f04dd1..935c7f0 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -51,9 +51,6 @@ static int omap4_clkdm_clear_all_wkup_sleep_deps(struct 
clockdomain *clkdm)
struct clkdm_dep *cd;
u32 mask = 0;
 
-   if (!clkdm->prcm_partition)
-   return 0;
-
for (cd = clkdm->wkdep_srcs; cd && cd->clkdm_name; cd++) {
if (!cd->clkdm)
continue; /* only happens if data is erroneous */
@@ -106,9 +103,6 @@ static int omap4_clkdm_clk_disable(struct clockdomain 
*clkdm)
 {
bool hwsup = false;
 
-   if (!clkdm->prcm_partition)
-   return 0;
-
hwsup = omap4_cminst_is_clkdm_in_hwsup(clkdm->prcm_partition,
clkdm->cm_inst, clkdm->clkdm_offs);
 
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c 
b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 839145e..0a6a048 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -89,3 +89,13 @@ struct clockdomain wkup_common_clkdm = {
.pwrdm  = { .name = "wkup_pwrdm" },
.dep_bit= OMAP_EN_WKUP_SHIFT,
 };
+
+struct clockdomain prm_common_clkdm = {
+   .name   = "prm_clkdm",
+   .pwrdm  = { .name = "wkup_pwrdm" },
+};
+
+struct clockdomain cm_common_clkdm = {
+   .name   = "cm_clkdm",
+   .pwrdm  = { .name = "core_pwrdm" },
+};
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c 
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index c534258..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -430,8 +430,6 @@ static struct clockdomain *clockdomains_omap44xx[] 
__initdata = {
&l4_wkup_44xx_clkdm,
&emu_sys_44xx_clkdm,
&l3_dma_44xx_clkdm,
-   &prm_common_clkdm,
-   &cm_common_clkdm,
NULL
 };
 
diff --git a/arch/arm/mach-omap2/clockdomains_common_data.c 
b/arch/arm/mach-omap2/clockdomains_common_data.c
deleted file mode 100644
index 615b1f0..000
--- a/arch/arm/mach-omap2/clockdomains_common_data.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * OMAP2+-common clockdomain data
- *
- * Copyright (C) 2008-2012 Texas Instruments, Inc.
- * Copyright (C) 2008-2010 Nokia Corporation
- *
- * Paul Walmsley, Jouni Högander
- */
-
-#include 
-#include 
-
-#include "clockdomain.h"
-
-/* These are implicit clockdomains - they are never defined as such in TRM */
-struct clockdomain prm_common_clkdm = {
-   .name   = "prm_clkdm",
-   .pwrdm  = { .name = "wkup_pwrdm" },
-};
-
-struct clockdomain cm_common_clkdm = {
-   .name   = "cm_clkdm",
-   .pwrdm  = { .name = "core_pwrdm" },
-};
-- 
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 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules

[Benoit Cousson]

The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding
the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM.
The clkdm entry are not the correct ones and does not exist in the system.

Replace them with the proper wkup, l4_ao and l4_cfg.

Fix as well the wrong OCP port used by the cm_core_aon. It uses the
l4_cfg interconnect and not the l4_wkup.

Re-order the entries by address value.

Signed-off-by: Benoit Cousson 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   52 ++--
 1 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 950454a..03fc705 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2529,27 +2529,6 @@ static struct omap_hwmod_class omap44xx_prcm_hwmod_class 
= {
.name   = "prcm",
 };
 
-/* prcm_mpu */
-static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
-   .name   = "prcm_mpu",
-   .class  = &omap44xx_prcm_hwmod_class,
-   .clkdm_name = "l4_wkup_clkdm",
-};
-
-/* cm_core_aon */
-static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
-   .name   = "cm_core_aon",
-   .class  = &omap44xx_prcm_hwmod_class,
-   .clkdm_name = "cm_clkdm",
-};
-
-/* cm_core */
-static struct omap_hwmod omap44xx_cm_core_hwmod = {
-   .name   = "cm_core",
-   .class  = &omap44xx_prcm_hwmod_class,
-   .clkdm_name = "cm_clkdm",
-};
-
 /* prm */
 static struct omap_hwmod_irq_info omap44xx_prm_irqs[] = {
{ .irq = 11 + OMAP44XX_IRQ_GIC_START },
@@ -2564,12 +2543,33 @@ static struct omap_hwmod_rst_info omap44xx_prm_resets[] 
= {
 static struct omap_hwmod omap44xx_prm_hwmod = {
.name   = "prm",
.class  = &omap44xx_prcm_hwmod_class,
-   .clkdm_name = "prm_clkdm",
+   .clkdm_name = "l4_wkup_clkdm",
.mpu_irqs   = omap44xx_prm_irqs,
.rst_lines  = omap44xx_prm_resets,
.rst_lines_cnt  = ARRAY_SIZE(omap44xx_prm_resets),
 };
 
+/* cm_core */
+static struct omap_hwmod omap44xx_cm_core_hwmod = {
+   .name   = "cm_core",
+   .class  = &omap44xx_prcm_hwmod_class,
+   .clkdm_name = "l4_cfg_clkdm",
+};
+
+/* cm_core_aon */
+static struct omap_hwmod omap44xx_cm_core_aon_hwmod = {
+   .name   = "cm_core_aon",
+   .class  = &omap44xx_prcm_hwmod_class,
+   .clkdm_name = "l4_ao_clkdm",
+};
+
+/* prcm_mpu */
+static struct omap_hwmod omap44xx_prcm_mpu_hwmod = {
+   .name   = "prcm_mpu",
+   .class  = &omap44xx_prcm_hwmod_class,
+   .clkdm_name = "l4_wkup_clkdm",
+};
+
 /*
  * 'scrm' class
  * system clock and reset manager
@@ -5305,10 +5305,10 @@ static struct omap_hwmod_addr_space 
omap44xx_cm_core_aon_addrs[] = {
 };
 
 /* l4_wkup -> cm_core_aon */
-static struct omap_hwmod_ocp_if omap44xx_l4_wkup__cm_core_aon = {
-   .master = &omap44xx_l4_wkup_hwmod,
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__cm_core_aon = {
+   .master = &omap44xx_l4_cfg_hwmod,
.slave  = &omap44xx_cm_core_aon_hwmod,
-   .clk= "l4_wkup_clk_mux_ck",
+   .clk= "l4_div_ck",
.addr   = omap44xx_cm_core_aon_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
@@ -6101,7 +6101,7 @@ static struct omap_hwmod_ocp_if *omap44xx_hwmod_ocp_ifs[] 
__initdata = {
&omap44xx_l3_main_2__ocmc_ram,
&omap44xx_l4_cfg__ocp2scp_usb_phy,
&omap44xx_mpu_private__prcm_mpu,
-   &omap44xx_l4_wkup__cm_core_aon,
+   &omap44xx_l4_cfg__cm_core_aon,
&omap44xx_l4_cfg__cm_core,
&omap44xx_l4_wkup__prm,
&omap44xx_l4_wkup__scrm,
-- 
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 0/2] ARM: OMAP2+: Fix errors in PRCM hwmods + wrong clkdm

[Benoit Cousson]

Hi Paul,

Here is the serie to fix wrong clkdm for the PRCM hwmods.

I did revert as well the patch to make the cm_clkdm and prm_clkdm
common since it does not exist on OMAP4.
I do not thinks it exists in OMAP2 and 3 either, and thus that series should
probably be extended with the total removal of these fake clkdm.
I'd like to get your feedback first on this one to go further for OMAP2 & 3.

This series is based on 3.5-rc2 and should target -rc3.

Regards,
Benoit


Benoit Cousson (2):
  ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
  Revert "ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common"

 arch/arm/mach-omap2/Makefile |1 -
 arch/arm/mach-omap2/clockdomain44xx.c|6 ---
 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |   10 
 arch/arm/mach-omap2/clockdomains44xx_data.c  |2 -
 arch/arm/mach-omap2/clockdomains_common_data.c   |   24 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |   52 +++---
 6 files changed, 36 insertions(+), 59 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.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

Re: [PATCHv2 11/12] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks

[Cousson, Benoit]

Hi Paul,

On 6/11/2012 2:46 AM, Paul Walmsley wrote:

Until the OMAP4 code is converted to disable the use of the clock
framework-based clockdomain enable/disable sequence, any clock used as
a hwmod main_clk must have a clockdomain associated with it.


But why? The clock domain information is already present in every hwmod 
nodes for OMAP4.



This
patch populates some clock structure clockdomain names to resolve the
following warnings during kernel init:

omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck.
omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
omap_hwmod: ddrphy_ck: missing clockdomain for ddrphy_ck.

Signed-off-by: Paul Walmsley 
Cc: Rajendra Nayak 
Cc: Benoît Cousson 
---
  arch/arm/mach-omap2/clock44xx_data.c |5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index 2172f66..e2b701e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -84,6 +84,7 @@ static struct clk slimbus_clk = {

  static struct clk sys_32k_ck = {
.name   = "sys_32k_ck",
+   .clkdm_name = "prm_clkdm",


In fact, neither prm_clkdm not cm_clkdm are valid clock domain on OMAP4 :-(.

I've just realized that you introduced that for 3.5, but this is wrong. 
We should not start adding some fake clock domains just because the fmwk 
is not smart enough to allow a NULL clock domain.


The clkdomain should be optional, at least for clock nodes.
There is no need to enforce the presence of the clock domain in the 
structure. We should remove the warning and test the clkdm attribute 
before de-referencing it inside the clock core code.


This is the only proper fix for that issue for my point of view.

In a period of data size reduction, adding some fake information does 
not seems to be the right approach.

Don't you think so?

Regards,
Benoit


PS: I think we should revert 6ba5a69ee92c29c2ffc814dad6ac61c4cd49090c 
(ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common) and fix the 
OMAP4 hwmod data.

--
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 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)

[Paul Walmsley]

On Mon, 11 Jun 2012, Cousson, Benoit wrote:

> On 6/11/2012 10:04 AM, Paul Walmsley wrote:
> 
> > But if the IP blocks are reset later, and the bootloader or previous OS
> > gets some register settings wrong, there's a greater risk of system
> > instability or unpredictable behavior during the boot process.
> 
> Mmm, I'm not convince by that. If we delay the PM init at the very last 
> time, at least after the modules are properly reset and init, I do not 
> think we will have more issues than today.

My intent was not to convince, but to explain.

Certainly back in the OMAP3 days there were bootloaders that got SDRAM and 
GPMC timings wrong.  No way did I want to be chasing down kernel "bugs" 
based on those.

Anyway, once people finish fixing the drivers, then we should be able to 
switch to late hwmod reset.


- 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 2/6] ARM: OMAP AM33xx: voltagedomain: Add voltage domain data

[Paul Walmsley]

Hi Vaibhav,

On Mon, 11 Jun 2012, Vaibhav Hiremath wrote:

> I think this is not required, since Tony has already accepted the patch
> which has this implementation (available on linux-omap/master).
> Please refer to the commit,
> 
> commit 08f3098928c991560408e8c71d4af8b1a3ff2d67
> Author: Afzal Mohammed 
> Date:   Fri May 11 00:38:49 2012 +0530
> 
> ARM: OMAP2+: am33xx: Add AM335XEVM machine support

Thanks, that's what I need.  Looks like our series needs to be based on 
this commit, rather than mainline.


- 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: Broken builds

[Russell King - ARM Linux]

On Wed, Jun 06, 2012 at 12:58:00AM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen  [120605 06:24]:
> > Hi,
> > 
> > On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux  [120603 11:05]:
> > > > Looks like the DSS stuff has broken OMAP builds again during this
> > > > merge window:
> > > > 
> > > > drivers/video/omap2/dss/core.c:197: error: static declaration of 
> > > > 'dss_debugfs_create_file' follows non-static declaration
> > > > drivers/video/omap2/dss/dss.h:166: error: previous declaration of 
> > > > 'dss_debugfs_create_file' was here
> > > > 
> > > > Both the OMAP3 and OMAP4 builds break with these two errors.
> > > 
> > > Here's a patch for Tomi to fix this one.
> > 
> > I have a patch for this in my for-rc branch. It just missed the main
> > merge. I'll send this and a few other fixes today for the next rc.
> > 
> > Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled.
> > That's why I didn't notice it until too late.
> 
> Tomi, please have your patches sitting in linux next for at least a
> week before they get merged. That usually shakes down bugs like these
> before the merge window.

Note that tested simple bug fixes _should_ be upstreamed faster than
that where possible - such as this one.

I'm waiting for this to hit mainline before doing any further work on
OMAP.  That basically means I've been totally ignoring OMAP because of
this issue for the last week.
--
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: Broken builds

[Russell King - ARM Linux]

On Tue, Jun 05, 2012 at 04:20:00PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux  [120603 11:05]:
> > > Looks like the DSS stuff has broken OMAP builds again during this
> > > merge window:
> > > 
> > > drivers/video/omap2/dss/core.c:197: error: static declaration of 
> > > 'dss_debugfs_create_file' follows non-static declaration
> > > drivers/video/omap2/dss/dss.h:166: error: previous declaration of 
> > > 'dss_debugfs_create_file' was here
> > > 
> > > Both the OMAP3 and OMAP4 builds break with these two errors.
> > 
> > Here's a patch for Tomi to fix this one.
> 
> I have a patch for this in my for-rc branch. It just missed the main
> merge. I'll send this and a few other fixes today for the next rc.
> 
> Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled.
> That's why I didn't notice it until too late.

So... where are we with this?  Apparantly not much further forward;
it seems to be in linux-next but still not in mainline, and mainline
continues to be broken.
--
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: [PATCHv10 00/11] I2C fixes

[Wolfram Sang]

On Sun, Jun 10, 2012 at 11:10:47AM +0530, Shubhrajyoti Datta wrote:
> On Fri, Jun 1, 2012 at 4:29 AM, Kevin Hilman  wrote:
> > Shubhrajyoti D  writes:
> >
> >> The patch series does the following
> >>
> >> - Warn fixes if CONFIG_PM_RUNTIME is not selected.
> >> - In case of i2c remove register access was done without any
> >>  get_sync fix the same.
> >> - Folds a patch from Tasslehoff to prevent any merge conflicts.
> >> - Prevents the XDUF flag to be set if the underflow condition is not met.
> >> - As per discussion in [1] .Adds a patch to rename the 1p153 errata and
> >>  use the unique id instead as the section number in the recent errata
> >>  docs has changed.
> >>
> >> v9:
> >> Fix the comments from Wolfram Sang
> >>
> >> v10:
> >> Add a patch from Neil to the series.
> >> Fix kevin comments
> >> update the patches with comments.
> >
> > Shubhrajyoti, thanks for the updates.
> >
> > Wolfgang, with these updates and testing a bit better described, I'm OK
> > with you merging it.  Merging it now will give it plenty of time to
> > bake in linux-next and get more test exposure.
> 
> Agree,
> These are only fixes can it be considered for rc3?

"Baking in linux-next" and "considering rc3" don't match; baking needs
time, rc3 is soon. I've put the patches now into my -next branch for
more exposure. I am still uncertain if they should be in 3.5 already;
there seem to be worhty fixes in there, but they do depend on stuff
which don't really qualify as bugfixes...

Thanks,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature

Re: [PATCH] omap2+: add drm device

[Rob Clark]

On Wed, May 23, 2012 at 3:08 PM, Andy Gross  wrote:
> Register OMAP DRM/KMS platform device.  DMM is split into a
> separate device using hwmod.
>
> Signed-off-by: Andy Gross 

Signed-off-by: Rob Clark 

> ---
>  arch/arm/mach-omap2/Makefile           |    4 ++
>  arch/arm/mach-omap2/drm.c              |   61 
> 
>  drivers/staging/omapdrm/omap_drv.h     |    2 +-
>  drivers/staging/omapdrm/omap_priv.h    |   55 
>  include/linux/platform_data/omap_drm.h |   52 +++
>  5 files changed, 118 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/drm.c
>  delete mode 100644 drivers/staging/omapdrm/omap_priv.h
>  create mode 100644 include/linux/platform_data/omap_drm.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 49f92bc..c301ab7 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
>  obj-y                                  += dsp.o
>  endif
>
> +ifneq ($(CONFIG_DRM_OMAP),)
> +obj-y                                  += drm.o
> +endif
> +
>  # Specific board support
>  obj-$(CONFIG_MACH_OMAP_GENERIC)                += board-generic.o
>  obj-$(CONFIG_MACH_OMAP_H4)             += board-h4.o
> diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> new file mode 100644
> index 000..72e0f01b
> --- /dev/null
> +++ b/arch/arm/mach-omap2/drm.c
> @@ -0,0 +1,61 @@
> +/*
> + * DRM/KMS device registration for TI OMAP platforms
> + *
> + * Copyright (C) 2012 Texas Instruments
> + * Author: Rob Clark 
> + *
> + * 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 .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
> +
> +static struct platform_device omap_drm_device = {
> +       .dev = {
> +               .coherent_dma_mask = DMA_BIT_MASK(32),
> +       },
> +       .name = "omapdrm",
> +       .id = 0,
> +};
> +
> +static int __init omap_init_drm(void)
> +{
> +       struct omap_hwmod *oh = NULL;
> +       struct platform_device *pdev;
> +
> +       /* lookup and populate the DMM information, if present - OMAP4+ */
> +       oh = omap_hwmod_lookup("dmm");
> +
> +       if (oh) {
> +               pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> +                                       false);
> +               WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> +                       oh->name);
> +       }
> +
> +       return platform_device_register(&omap_drm_device);
> +
> +}
> +
> +arch_initcall(omap_init_drm);
> +
> +#endif
> diff --git a/drivers/staging/omapdrm/omap_drv.h 
> b/drivers/staging/omapdrm/omap_drv.h
> index b7e0f07..96296e0 100644
> --- a/drivers/staging/omapdrm/omap_drv.h
> +++ b/drivers/staging/omapdrm/omap_drv.h
> @@ -25,8 +25,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "omap_drm.h"
> -#include "omap_priv.h"
>
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug 
> */
> diff --git a/drivers/staging/omapdrm/omap_priv.h 
> b/drivers/staging/omapdrm/omap_priv.h
> deleted file mode 100644
> index ef64414..000
> --- a/drivers/staging/omapdrm/omap_priv.h
> +++ /dev/null
> @@ -1,55 +0,0 @@
> -/*
> - * include/drm/omap_priv.h
> - *
> - * Copyright (C) 2011 Texas Instruments
> - * Author: Rob Clark 
> - *
> - * 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 .
> - */
> -
> -#ifndef __OMAP_PRIV_H__
> -#define __OMAP_PRIV_H__
> -
> -/* Non-userspace facing APIs
> - */
> -
> -/* optional platform data to configure the default configuration of which
> - * pipes/overlays/CRTCs are used.. if this is not pro

Re: [PATCH 1/3] ARM: OMAP2+: nand: unify init functions

[Jon Hunter]

Hi Afzal,

On 06/11/2012 09:01 AM, Afzal Mohammed wrote:
> Helper function for updating nand platform data has been
> added the capability to take timing structure arguement.
> Usage of omap_nand_flash_init() has been replaced by modifed
> one, omap_nand_flash_init was doing things similar to
> board_nand_init except that NAND CS# were being acquired
> based on bootloader setting. As CS# is hardwired for a given
> board, acquiring gpmc CS# has been removed, and updated with
> the value on board.
> 
> NAND CS# used in beagle board was found to be CS0.
> Thomas Weber  reported
> that value of devkit8000 to be CS0. Overo board was found
> to be using CS0 based on u-boot, while google grep says
> omap3touchbook too has CS0.

[1] also confirms the omap3-touchbook uses CS0.

> Signed-off-by: Afzal Mohammed 

Which boards have been tested with this change?

Otherwise, looks good.

Reviewed-by: Jon Hunter 

Cheers
Jon

[1] http://www.alwaysinnovating.com/wiki/index.php/Booting
--
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

[PATCHv6 7/7] ARM: OMAP4: PM: put all domains to OSWR during suspend

[Tero Kristo]

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/pm44xx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1e845e8..eb3e073 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -105,7 +105,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, 
void *unused)
pwrst->pwrdm = pwrdm;
pwrst->next_state = pwrdm_get_achievable_func_pwrst(
pwrdm,
-   PWRDM_FUNC_PWRST_CSWR);
+   PWRDM_FUNC_PWRST_OSWR);
list_add(&pwrst->node, &pwrst_list);
 
return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
-- 
1.7.4.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

[PATCHv6 5/7] ARM: OMAP4: pwrdm: add support for reading prev logic and mem states

[Tero Kristo]

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.

If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/powerdomain44xx.c |   59 +
 1 files changed, 59 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain44xx.c 
b/arch/arm/mach-omap2/powerdomain44xx.c
index 030d10c..ab93f08 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -151,6 +151,34 @@ static int omap4_pwrdm_read_logic_retst(struct powerdomain 
*pwrdm)
return v;
 }
 
+/**
+ * omap4_pwrdm_read_prev_logic_pwrst - read the previous logic powerstate
+ * @pwrdm: struct powerdomain * to read the state for
+ *
+ * Reads the previous logic powerstate for a powerdomain. This function
+ * must determine the previous logic powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next retention logic state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether the logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+   int state;
+
+   state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+   if (state == PWRDM_POWER_OFF)
+   return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+   if (state != PWRDM_POWER_RET)
+   return PWRDM_LOGIC_MEM_PWRST_RET;
+
+   return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
 static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
 {
u32 m, v;
@@ -179,6 +207,35 @@ static int omap4_pwrdm_read_mem_retst(struct powerdomain 
*pwrdm, u8 bank)
return v;
 }
 
+/**
+ * omap4_pwrdm_read_prev_mem_pwrst - reads the previous memory powerstate
+ * @pwrdm: struct powerdomain * to read mem powerstate for
+ * @bank: memory bank index
+ *
+ * Reads the previous memory powerstate for a powerdomain. This function
+ * must determine the previous memory powerstate by first checking the
+ * previous powerstate for the domain. If that was OFF, then logic has
+ * been lost. If previous state was RETENTION, the function reads the
+ * setting for the next memory retention state to see the actual value.
+ * In every other case, the logic is retained. Returns either
+ * PWRDM_LOGIC_MEM_PWRST_OFF or PWRDM_LOGIC_MEM_PWRST_RET depending
+ * whether logic was retained or not.
+ */
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
+{
+   int state;
+
+   state = omap4_pwrdm_read_prev_pwrst(pwrdm);
+
+   if (state == PWRDM_POWER_OFF)
+   return PWRDM_LOGIC_MEM_PWRST_OFF;
+
+   if (state != PWRDM_POWER_RET)
+   return PWRDM_LOGIC_MEM_PWRST_RET;
+
+   return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
 static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
 {
u32 c = 0;
@@ -220,9 +277,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst  = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+   .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst   = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst   = omap4_pwrdm_read_mem_retst,
+   .pwrdm_read_prev_mem_pwrst  = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition  = omap4_pwrdm_wait_transition,
-- 
1.7.4.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

[PATCHv6 6/7] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

From: Rajendra Nayak 

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak 
Signed-off-by: Tero Kristo 
[Jean Pihet : ported on top of the functional power
states]
Reviewed-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/pm44xx.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 3a484b1..1e845e8 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -97,19 +97,15 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, 
void *unused)
if (!strncmp(pwrdm->name, "cpu", 3))
return 0;
 
-   /*
-* FIXME: Remove this check when core retention is supported
-* Only MPUSS power domain is added in the list.
-*/
-   if (strcmp(pwrdm->name, "mpu_pwrdm"))
-   return 0;
 
pwrst = kmalloc(sizeof(struct power_state), GFP_ATOMIC);
if (!pwrst)
return -ENOMEM;
 
pwrst->pwrdm = pwrdm;
-   pwrst->next_state = PWRDM_FUNC_PWRST_CSWR;
+   pwrst->next_state = pwrdm_get_achievable_func_pwrst(
+   pwrdm,
+   PWRDM_FUNC_PWRST_CSWR);
list_add(&pwrst->node, &pwrst_list);
 
return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
-- 
1.7.4.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

[PATCHv6 2/7] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.

[Tero Kristo]

From: Santosh Shilimkar 

On OMAP4+ devices, GIC register context is lost when MPUSS hits
the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code
gets executed and one of the steps in it is to restore the
saved context of the GIC. The ROM Code GIC distributor restoration
is split in two parts: CPU specific register done by each CPU and
common register done by only one CPU.

Below is the abstract flow.

...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.

[..]

- CPU0 executes "GIC Restoration:"

[...]

- CPU0 swicthes to non-secure mode and jumps to OS resume code.

[...]

- CPU0 is online in OS
- CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
- CPU0 wakes up CPU1 with clock-domain force wakeup method.
- CPU0 continues it's execution.
[..]

- CPU1 wakes up and start executing ROM code.

[..]

- CPU1 executes "GIC Restoration:"

[..]

- CPU1 swicthes to non-secure mode and jumps to OS resume code.

[...]

- CPU1 is online in OS and start executing.
[...]   -

GIC Restoration: /* Common routine for HS and GP devices */
{
   if (GICD != 1)  { /* This will be true in OSWR state */
   if (GIC_SAR_BACKUP_STATE == SAVED)
   - CPU restores GIC distributor
   else
   - reconfigure GIC distributor to boot values.

   GICD.Enable secure = 1
   }

   if (GIC_SAR_BACKUP_STATE == SAVED)
   - CPU restore its GIC CPU interface registers if saved.
   else
   - reconfigure its GIC CPU interface registers to boot
   values.
}
...

So as mentioned in the flow, GICD != 1 condition decides how
the GIC registers are handled in ROM code wakeup path from
OSWR. As evident from the flow, ROM code relies on the entire
GICD register value and not specific register bits.

The assumption was valid till CortexA9 r1pX version since there
was only one banked bit to control secure and non-secure GICD.
Secure view which ROM code sees:
   bit 0 == Enable Non-secure
Non-secure view which HLOS sees:
   bit 0 == Enable secure

But GICD register has changed between CortexA9 r1pX and r2pX.
On r2pX GICD register is composed of 2 bits.
Secure view which ROM code sees:
   bit 1 == Enable Non-secure
   bit 0 == Enable secure
Non-secure view which HLOS sees:
   bit 0 == Enable Non-secure

Hence on OMAP4460(r2pX) devices, if you go through the
above flow again during CPU1 wakeup, GICD == 3 and hence
ROM code fails to understand the real wakeup power state
and reconfigures GIC distributor to boot values. This is
nasty since you loose the entire interrupt controller
context in a live system.

The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to
check "GICD.Enable secure != 1" for GIC restoration in OSWR wakeup path.

Since ROM code can't be fixed on OMAP4460 devices, a work around
needs to be implemented. As evident from the flow, as long as
CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue
won't happen. Below is the flow with the work-around.

...
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.

[..]

- CPU0 executes "GIC Restoration:"

[..]

- CPU0 swicthes to non-secure mode and jumps to OS resume code.

[..]

- CPU0 is online in OS.
- CPU0 does GICD.Enable Non-secure = 0
- CPU0 wakes up CPU1 with clock domain force wakeup method.
- CPU0 waits for GICD.Enable Non-secure = 1
- CPU0 coninues it's execution.
[..]

- CPU1 wakes up and start executing ROM code.

[..]

- CPU1 executes "GIC Restoration:"

[..]

- CPU1 swicthes to non-secure mode and jumps to OS resume code.

[..]

- CPU1 is online in OS
- CPU1 does GICD.Enable Non-secure = 1
- CPU1 start executing
[...]
...

With this procedure, the GIC configuration done between the
CPU0 wakeup and CPU1 wakeup will not be lost but during this
short windows, the CPU0 will not receive interrupts.

The BUG is applicable to only OMAP4460(r2pX) devices.
OMAP4470 (also r2pX) is not affected by this bug because
ROM code has been fixed.

Signed-off-by: Santosh Shilimkar 
Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/common.h  |2 +
 arch/arm/mach-omap2/omap-headsmp.S|   38 +
 arch/arm/mach-omap2/omap-mpuss-lowpower.c |9 ++-
 arch/arm/mach-omap2/omap-smp.c|   28 -
 arch/arm/mach-omap2/omap4-common.c|8 +-
 arch/arm/mach-omap2/pm.h  |2 +
 6 files changed, 84 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index be9dfd1..a793ab3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -

[PATCHv6 4/7] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Tero Kristo]

From: Rajendra Nayak 

OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.

Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.

Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.

omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.

Signed-off-by: Rajendra Nayak 
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
 rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
 prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
 and clear, merged patches]
Signed-off-by: Paul Walmsley 
[t-kri...@ti.com: added support for arch specific hwmod ops, and changed
 the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/omap_hwmod.c |   70 --
 arch/arm/plat-omap/include/plat/omap_hwmod.h |8 ++-
 2 files changed, 72 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7b1..742e507 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -170,6 +170,13 @@
 /* omap_hwmod_list contains all registered struct omap_hwmods */
 static LIST_HEAD(omap_hwmod_list);
 
+struct hwmod_ops {
+   void(*hwmod_update_context_lost)(struct omap_hwmod *oh);
+   int (*hwmod_get_context_lost)(struct omap_hwmod *oh);
+};
+
+static struct hwmod_ops *arch_hwmod;
+
 /* mpu_oh: used to add/remove MPU initiator from sleepdep list */
 static struct omap_hwmod *mpu_oh;
 
@@ -1773,6 +1780,51 @@ static void _reconfigure_io_chain(void)
 }
 
 /**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+   u32 r;
+
+   if (oh->prcm.omap4.context_offs == USHRT_MAX)
+   return;
+
+   r = omap4_prminst_read_inst_reg(oh->clkdm->pwrdm.ptr->prcm_partition,
+   oh->clkdm->pwrdm.ptr->prcm_offs,
+   oh->prcm.omap4.context_offs);
+
+   if (!r)
+   return;
+
+   oh->prcm.omap4.context_lost_counter++;
+
+   omap4_prminst_write_inst_reg(r, oh->clkdm->pwrdm.ptr->prcm_partition,
+oh->clkdm->pwrdm.ptr->prcm_offs,
+oh->prcm.omap4.context_offs);
+}
+
+/**
+ * _omap4_get_context_lost - get context loss counter for a hwmod
+ *
+ * Returns the in-memory context loss counter for a hwmod.
+ */
+static int _omap4_get_context_lost(struct omap_hwmod *oh)
+{
+   return oh->prcm.omap4.context_lost_counter;
+}
+
+static struct hwmod_ops omap4_hwmod_ops = {
+   .hwmod_update_context_lost  = _omap4_update_context_lost,
+   .hwmod_get_context_lost = _omap4_get_context_lost,
+};
+
+/**
  * _enable - enable an omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -1853,6 +1905,9 @@ static int _enable(struct omap_hwmod *oh)
_enable_clocks(oh);
_enable_module(oh);
 
+   if (arch_hwmod && arch_hwmod->hwmod_update_context_lost)
+   arch_hwmod->hwmod_update_context_lost(oh);
+
r = _wait_target_ready(oh);
if (!r) {
/*
@@ -2711,6 +2766,9 @@ int __init omap_hwmod_setup_one(const char *oh_name)
  */
 static int __init omap_hwmod_setup_all(void)
 {
+   if (cpu_is_omap44xx())
+   arch_hwmod = &omap4_hwmod_ops;
+
_ensure_mpu_hwmod_is_setup(NULL);
 
omap_hwmod_for_each(_init, NULL);
@@ -3364,17 +3422,21 @@ ohsps_unlock:
  * omap_hwmod_get_context_loss_count - get lost context count
  * @oh: struct omap_hwmod *
  *
- * Query the powerdomain of of @oh to get the context loss
- * count for this device.
+ * Returns the context loss count of associated @oh
+ * upon success, or zero if no context loss data is available.
  *
- * Returns the context loss count of the powerdomain assocated with @oh
- * upon success, or zero if no powerdomain exists for @oh.
+ * On OMAP4, this queries the per-hwmod context loss register,
+ * assuming one exists.  If not, or on OMAP2/3, this queries the
+ * enclosing powerdomain context loss count.
  */
 int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
 {
struct powerdomain *pwrdm;
int ret = 0;
 
+   if (arch_hwmod && arch_hwmod->hwmod_get_context_lost)
+   return arch_hwmod->hw

[PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status

[Tero Kristo]

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
 1 files changed, 1 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 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+   .context_offs = USHRT_MAX,
},
},
 };
-- 
1.7.4.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

[PATCHv6 1/7] ARM: OMAP4: PM: add errata support

[Tero Kristo]

Added similar PM errata flag support as omap3 has. This should be used
in similar manner, set the flags during init time, and check the flag
values during runtime.

Signed-off-by: Tero Kristo 
---
 arch/arm/mach-omap2/pm.h |7 +++
 arch/arm/mach-omap2/pm44xx.c |1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..46ab9d9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -88,6 +88,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
 static inline void enable_omap3630_toggle_l2_on_restore(void) { }
 #endif /* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */
 
+#if defined(CONFIG_ARCH_OMAP4)
+extern u16 pm44xx_errata;
+#define IS_PM44XX_ERRATUM(id)  (pm44xx_errata & (id))
+#else
+#define IS_PM44XX_ERRATUM(id)  0
+#endif
+
 #ifdef CONFIG_OMAP_SMARTREFLEX
 extern int omap_devinit_smartreflex(void);
 extern void omap_enable_smartreflex_on_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index c234733..3a484b1 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
 };
 
 static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
 
 #ifdef CONFIG_SUSPEND
 static int omap4_pm_suspend(void)
-- 
1.7.4.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

[PATCHv6 0/7] ARM: OMAP4: core retention support

[Tero Kristo]

Hi,

Changes compared to previous version:

- moved basic omap4 pm errata support from dev-off set to this one
- changed ordering of patches a bit (core ret enabled at last patch)
- dropped DSP reset hack patch from set, as it is no longer needed
- added arch specific hwmod_ops support, needed for proper functioning
  of the context loss support
- context offset register invalidity is now marked with USHRT_MAX
  instead of a separate flag
- patches rebased on top of Jean Pihet's functional power state code
- patches rebased on top of 3.5-rc2
- dropped debug option for enabling OSWR mode for suspend, this is now
  enabled by default

Tested with omap4 panda board + omap3 beagle (just to verify nothing
gets broken.)

Fully functioning branch available here:
tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.5-rc2-omap4-ret-v6

Branch contains also hwmod fixes from Paul Walmsley, functional power
state code from Jean Pihet, IO chain set and a few other needed misc
fixes to make suspend to core retention + wakeup to work properly.

-Tero

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

[PATCH 6/9] ARM: OMAP2+: gpmc-smsc911x: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for smsc911x. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |   66 +++
 arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |   11 ++--
 2 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c 
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index b6c77be..93a534e 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -99,3 +99,69 @@ free1:
 
pr_err("Could not initialize smsc911x device\n");
 }
+
+struct gpmc_device_pdata *
+__init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+   int ret;
+   struct gpmc_device_pdata *gpmc_pdev;
+   struct gpmc_cs_data *gpmc_cs;
+
+   gpmc_pdev = kzalloc(sizeof(*gpmc_pdev), GFP_KERNEL);
+   if (gpmc_pdev == NULL)
+   return gpmc_pdev;
+
+   gpmc_cs = kzalloc(sizeof(*gpmc_cs), GFP_KERNEL);
+   if (gpmc_pdev == NULL) {
+   kfree(gpmc_pdev);
+   return NULL;
+   }
+
+   gpmc_pdev->cs_data = gpmc_cs;
+   gpmc_pdev->num_cs = 1;
+   gpmc_pdev->name = "smsc911x";
+   gpmc_pdev->id = gpmc_cfg->id;
+   gpmc_pdev->pdata = &gpmc_smsc911x_config;
+   gpmc_pdev->pdata_size = sizeof(gpmc_smsc911x_config);
+
+   gpmc_cs->cs = gpmc_cfg->cs;
+   gpmc_cs->mem_size = 0x100;
+
+   gpmc_pdev->per_res = gpmc_smsc911x_resources + 1;
+   gpmc_pdev->per_res_cnt = 1;
+
+   if (gpio_request_one(gpmc_cfg->gpio_irq, GPIOF_IN, "smsc911x irq")) {
+   pr_err("Failed to request IRQ GPIO%d\n", gpmc_cfg->gpio_irq);
+   goto free1;
+   }
+
+   gpmc_smsc911x_resources[1].start = gpio_to_irq(gpmc_cfg->gpio_irq);
+
+   if (gpio_is_valid(gpmc_cfg->gpio_reset)) {
+   ret = gpio_request_one(gpmc_cfg->gpio_reset,
+  GPIOF_OUT_INIT_HIGH, "smsc911x reset");
+   if (ret) {
+   pr_err("Failed to request reset GPIO%d\n",
+  gpmc_cfg->gpio_reset);
+   goto free2;
+   }
+
+   gpio_set_value(gpmc_cfg->gpio_reset, 0);
+   msleep(100);
+   gpio_set_value(gpmc_cfg->gpio_reset, 1);
+   }
+
+   gpmc_smsc911x_config.flags = gpmc_cfg->flags ? : SMSC911X_USE_16BIT;
+
+   return gpmc_pdev;
+
+free2:
+   gpio_free(gpmc_cfg->gpio_irq);
+free1:
+   kfree(gpmc_cs);
+   kfree(gpmc_pdev);
+
+   pr_err("Could not initialize smsc911x device\n");
+
+   return NULL;
+}
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h 
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index ea6c9c8..50af49e 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -22,14 +22,17 @@ struct omap_smsc911x_platform_data {
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-
 extern void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d);
-
+extern struct gpmc_device_pdata *
+gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg);
 #else
-
 static inline void gpmc_smsc911x_init(struct omap_smsc911x_platform_data *d)
 {
 }
-
+static inline struct gpmc_device_pdata *
+gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
+{
+   return NULL;
+}
 #endif
 #endif
-- 
1.7.10.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

[PATCH 9/9] ARM: OMAP2+: board omap3beagle: use gpmc driver

[Afzal Mohammed]

gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/board-omap3beagle.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5aa8f28..0fe70ed 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -77,6 +77,12 @@ enum {
 
 static u8 omap3_beagle_version;
 
+static struct gpmc_device_pdata *gpmc_device_data[2];
+
+static struct gpmc_pdata gpmc_data = {
+   .device_pdata = gpmc_device_data,
+};
+
 /*
  * Board-specific configuration
  * Defaults to BeagleBoard-xMC
@@ -499,6 +505,8 @@ static void __init beagle_opp_init(void)
 
 static void __init omap3_beagle_init(void)
 {
+   struct omap_nand_platform_data *nand_data;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
 
@@ -524,9 +532,13 @@ static void __init omap3_beagle_init(void)
 
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
-   board_nand_init(omap3beagle_nand_partitions,
+   nand_data = board_nand_update(omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions), NAND_CS,
-   NAND_BUSWIDTH_16, NULL);
+   NAND_BUSWIDTH_16, nand_default_timings);
+   *gpmc_device_data = gpmc_nand_update(nand_data);
+   if (!*gpmc_device_data)
+   pr_err("error: unable to initilaize gpmc nand\n");
+   omap_gpmc_init(&gpmc_data);
 
/* Ensure msecure is mux'd to be able to set the RTC. */
omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
-- 
1.7.10.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

[PATCH 8/9] ARM: OMAP2+: board omap3evm: use gpmc driver

[Afzal Mohammed]

gpmc code has been converted to driver. Modify the board
code to provide gpmc driver with required information

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/board-omap3evm.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..aa9429d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -43,6 +43,7 @@
 
 #include 
 #include 
+#include 
 #include "common.h"
 #include 
 #include 
@@ -102,6 +103,12 @@ static void __init omap3_evm_get_revision(void)
}
 }
 
+static struct gpmc_device_pdata *gpmc_device_data[2];
+
+static struct gpmc_pdata gpmc_data = {
+   .device_pdata = gpmc_device_data,
+};
+
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
 #include 
 
@@ -122,7 +129,9 @@ static inline void __init omap3evm_init_smsc911x(void)
smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
}
 
-   gpmc_smsc911x_init(&smsc911x_cfg);
+   *gpmc_device_data = gpmc_smsc911x_update(&smsc911x_cfg);
+   if (!*gpmc_device_data)
+   pr_err("error: unable to initilaize gpmc smsc911x\n");
 }
 
 #else
@@ -658,6 +667,7 @@ static void __init omap3_evm_init(void)
usbhs_init(&usbhs_bdata);
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
+   omap_gpmc_init(&gpmc_data);
omap3_evm_display_init();
omap3_evm_wl12xx_init();
 }
-- 
1.7.10.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

[PATCH 7/9] ARM: OMAP2+: gpmc-smsc911x: runtime time calculation

[Afzal Mohammed]

OMAP Peripherals using SMSC911X driver were not configured
in Kernel. Here timing has been calculated so that it is
runtime configurable. As different SMSC devices like 9115,
9220, 9221 can be used with smsc911x driver, option has been
given for the boards to provide timing as per the part used,
if it is not provided, default one used is that of 9220.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-smsc911x.c |   53 +++
 arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |   14 ++
 2 files changed, 67 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c 
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 93a534e..4bfe721 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -100,6 +100,53 @@ free1:
pr_err("Could not initialize smsc911x device\n");
 }
 
+static void gpmc_smsc911x_timing(struct gpmc_time_ctrl *time_ctrl,
+   struct smsc911x_timing *timing)
+{
+   struct gpmc_timings t;
+   /* SMSC 9220 timings */
+   unsigned tcycle_r = 165;
+   unsigned tcsl_r = 32;
+   unsigned tcsh_r = 133;
+   unsigned tcsdv_r = 30;
+   unsigned tdoff_r = 9;
+   unsigned tcycle_w = 165;
+   unsigned tcsl_w = 32;
+   unsigned tcsh_w = 133;
+   unsigned tdsu_w = 7;
+
+   /* take timings from board, else use default */
+   if (timing) {
+   tcycle_r = timing->tcycle_r;
+   tcsl_r = timing->tcsl_r;
+   tcsh_r = timing->tcsh_r;
+   tcsdv_r = timing->tcsdv_r;
+   tdoff_r = tdoff_r;
+   tcycle_w = timing->tcycle_r;
+   tcsl_w = timing->tcsl_w;
+   tcsh_w = timing->tcsh_w;
+   tdsu_w = timing->tdsu_w;
+   }
+
+   memset(&t, sizeof(t), 0);
+
+   t.cs_on = 0;
+   t.oe_on = 0;
+   t.access = tcsdv_r;
+   t.oe_off = max_t(unsigned, t.access + gpmc_ticks_to_ns(1), tcsl_r);
+   t.cs_rd_off = t.oe_off;
+   t.rd_cycle = tcsl_r + max(tcsh_r, tdoff_r);
+   t.rd_cycle = max_t(unsigned, tcycle_r, t.rd_cycle);
+
+   t.we_on = 0;
+   t.we_off = max(tcsl_w, tdsu_w);
+   t.cs_wr_off = t.we_off;
+   t.wr_cycle = max_t(unsigned, t.we_off + gpmc_ticks_to_ns(1), tcycle_w);
+
+   time_ctrl->type = has_period;
+   time_ctrl->timings = t;
+}
+
 struct gpmc_device_pdata *
 __init gpmc_smsc911x_update(struct omap_smsc911x_platform_data *gpmc_cfg)
 {
@@ -127,6 +174,12 @@ __init gpmc_smsc911x_update(struct 
omap_smsc911x_platform_data *gpmc_cfg)
gpmc_cs->cs = gpmc_cfg->cs;
gpmc_cs->mem_size = 0x100;
 
+   gpmc_cs->have_config = true;
+   gpmc_cs->config = GPMC_CONFIG1_DEVICESIZE_16 |
+   GPMC_CONFIG1_DEVICETYPE_NOR;
+
+   gpmc_smsc911x_timing(&gpmc_cs->time_ctrl, gpmc_cfg->timing);
+
gpmc_pdev->per_res = gpmc_smsc911x_resources + 1;
gpmc_pdev->per_res_cnt = 1;
 
diff --git a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h 
b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
index 50af49e..8be3343 100644
--- a/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
+++ b/arch/arm/plat-omap/include/plat/gpmc-smsc911x.h
@@ -13,12 +13,26 @@
 
 #ifndef __ASM_ARCH_OMAP_GPMC_SMSC911X_H__
 
+/* timing in ns */
+struct smsc911x_timing {
+   unsigned tcycle_r;
+   unsigned tcsl_r;
+   unsigned tcsh_r;
+   unsigned tcsdv_r;
+   unsigned tdoff_r;
+   unsigned tcycle_w;
+   unsigned tcsl_w;
+   unsigned tcsh_w;
+   unsigned tdsu_w;
+};
+
 struct omap_smsc911x_platform_data {
int id;
int cs;
int gpio_irq;
int gpio_reset;
u32 flags;
+   struct smsc911x_timing *timing;
 };
 
 #if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
-- 
1.7.10.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

[PATCH 5/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for smc91x. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-smc91x.c |   69 +
 arch/arm/plat-omap/include/plat/gpmc-smc91x.h |   12 +++--
 2 files changed, 66 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c 
b/arch/arm/mach-omap2/gpmc-smc91x.c
index ba10c24..06f7e73 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -48,6 +48,19 @@ static struct platform_device gpmc_smc91x_device = {
.resource   = gpmc_smc91x_resources,
 };
 
+static struct gpmc_cs_data gpmc_smc91x_cs_data;
+
+static struct gpmc_device_pdata gpmc_smc91x_data = {
+   .name   = "smc91x",
+   .id = -1,
+   .pdata  = &gpmc_smc91x_info,
+   .pdata_size = sizeof(gpmc_smc91x_info),
+   .per_res= gpmc_smc91x_resources + 1,
+   .per_res_cnt= 1,
+   .cs_data= &gpmc_smc91x_cs_data,
+   .num_cs = 1,
+};
+
 /*
  * Set the gpmc timings for smc91c96. The timings are taken
  * from the data sheet available at:
@@ -100,9 +113,18 @@ static int smc91c96_gpmc_retime(void)
l |= GPMC_CONFIG1_WAIT_READ_MON;
if (gpmc_cfg->flags & GPMC_WRITE_MON)
l |= GPMC_CONFIG1_WAIT_WRITE_MON;
-   if (gpmc_cfg->wait_pin)
-   l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg->wait_pin);
-   gpmc_cs_write_reg(gpmc_cfg->cs, GPMC_CS_CONFIG1, l);
+
+   /* gpmc driver interface */
+   if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+   gpmc_smc91x_cs_data.have_config = true;
+   /* waitpin macro, not waitpin number */
+   gpmc_smc91x_cs_data.config |= l |
+   (gpmc_cfg->wait_pin & GPMC_WAITPIN_MASK);
+   } else {
+   if (gpmc_cfg->wait_pin)
+   l |= GPMC_CONFIG1_WAIT_PIN_SEL(gpmc_cfg->wait_pin);
+   gpmc_cs_write_reg(gpmc_cfg->cs, GPMC_CS_CONFIG1, l);
+   }
 
/*
 * FIXME: Calculate the address and data bus muxed timings.
@@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
return 0;
 
-   return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
+   /* gpmc driver interface */
+   if (gpmc_smc91x_cs_data.mem_size == 0x10) {
+   gpmc_smc91x_cs_data.time_ctrl.type = has_period;
+   gpmc_smc91x_cs_data.time_ctrl.timings = t;
+   return 0;
+   } else
+   return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
 }
 
 /*
@@ -132,13 +160,17 @@ void __init gpmc_smc91x_init(struct 
omap_smc91x_platform_data *board_data)
if (gpmc_cfg->flags & GPMC_TIMINGS_SMC91C96)
gpmc_cfg->retime = smc91c96_gpmc_retime;
 
-   if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
-   printk(KERN_ERR "Failed to request GPMC mem for smc91x\n");
-   return;
+   /* old interface */
+   if (gpmc_smc91x_cs_data.mem_size != 0x10) {
+   if (gpmc_cs_request(gpmc_cfg->cs, SZ_16M, &cs_mem_base) < 0) {
+   pr_err("error: gpmc_cs_request on smc91x\n");
+   return;
+   }
+
+   gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
+   gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
}
 
-   gpmc_smc91x_resources[0].start = cs_mem_base + 0x300;
-   gpmc_smc91x_resources[0].end = cs_mem_base + 0x30f;
gpmc_smc91x_resources[1].flags |= (gpmc_cfg->flags & IRQF_TRIGGER_MASK);
 
if (gpmc_cfg->retime) {
@@ -170,6 +202,10 @@ void __init gpmc_smc91x_init(struct 
omap_smc91x_platform_data *board_data)
gpio_set_value(gpmc_cfg->gpio_reset, 0);
}
 
+   /* gpmc driver interface */
+   if (gpmc_smc91x_cs_data.mem_size == 0x10)
+   return;
+
if (platform_device_register(&gpmc_smc91x_device) < 0) {
printk(KERN_ERR "Unable to register smc91x device\n");
gpio_free(gpmc_cfg->gpio_reset);
@@ -184,7 +220,20 @@ free3:
 free2:
gpio_free(gpmc_cfg->gpio_irq);
 free1:
-   gpmc_cs_free(gpmc_cfg->cs);
+   if (gpmc_smc91x_cs_data.mem_size != 0x10)
+   gpmc_cs_free(gpmc_cfg->cs);
 
printk(KERN_ERR "Could not initialize smc91x\n");
 }
+
+struct gpmc_device_pdata *
+__init gpmc_smc91x_update(struct omap_smc91x_platform_data *board_data)
+{
+   gpmc_smc91x_cs_data.cs  = gpmc_cfg->cs;
+   gpmc_smc91x_cs_data.mem_offset  = 0x300;
+   gpmc_smc91x_cs_data.m

[PATCH 4/9] ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for tusb6010. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/usb-tusb6010.c |  113 +++-
 arch/arm/plat-omap/include/plat/gpmc.h |8 +++
 2 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-tusb6010.c 
b/arch/arm/mach-omap2/usb-tusb6010.c
index db84a46..0e17337 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -22,9 +22,26 @@
 
 #include "mux.h"
 
+#defineCS_ASYNC_IDX0
+#defineCS_SYNC_IDX 1
+#defineCS_NUM  2
+
 static u8  async_cs, sync_cs;
 static unsignedrefclk_psec;
 
+static struct resource tusb_resource = {
+   .name   = "mc",
+   .flags  = IORESOURCE_IRQ,
+};
+
+static struct gpmc_cs_data gpmc_tusb_cs_data[CS_NUM];
+
+static struct gpmc_device_pdata gpmc_tusb_data = {
+   .name   = "musb-tusb",
+   .id = -1,
+   .per_res= &tusb_resource,
+   .per_res_cnt= 1,
+};
 
 /* t2_ps, when quantized to fclk units, must happen no earlier than
  * the clock after after t1_NS.
@@ -106,7 +123,14 @@ static int tusb_set_async_mode(unsigned sysclk_ps, 
unsigned fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
 
-   return gpmc_cs_set_timings(async_cs, &t);
+   /* gpmc driver interface */
+   if (gpmc_tusb_data.pdata != NULL) {
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.type = has_period;
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.timings = t;
+   return 0;
+   /* old interface */
+   } else
+   return gpmc_cs_set_timings(async_cs, &t);
 }
 
 static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
@@ -174,7 +198,16 @@ static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned 
fclk_ps)
tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
 
-   return gpmc_cs_set_timings(sync_cs, &t);
+   t.clk_activation = gpmc_ticks_to_ns(1);
+
+   /* gpmc driver interface */
+   if (gpmc_tusb_data.pdata != NULL) {
+   gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.type = has_period;
+   gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.timings = t;
+   return 0;
+   /* old interface */
+   } else
+   return gpmc_cs_set_timings(sync_cs, &t);
 }
 
 extern unsigned long gpmc_get_fclk_period(void);
@@ -348,3 +381,79 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data 
*data,
}
return 0;
 }
+
+struct gpmc_device_pdata *
+__init gpmc_tusb6010_update(struct musb_hdrc_platform_data *data,
+   unsigned ps_refclk, unsigned waitpin,
+   unsigned async, unsigned sync,
+   unsigned irq, unsigned dmachan)
+{
+   int ret;
+
+   if (!data) {
+   pr_err("error: %s: data: NULL\n", __func__);
+   return NULL;
+   }
+
+   gpmc_tusb_data.pdata = data;
+   gpmc_tusb_data.pdata_size = sizeof(*data);
+
+   /* ASYNC region, primarily for PIO */
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].cs = async;
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].mem_size = 0x1000;
+
+   async_cs = async;
+
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].have_config = true;
+   gpmc_tusb_cs_data[CS_ASYNC_IDX].config = waitpin |
+   GPMC_CONFIG1_DEVICESIZE_16 | GPMC_CONFIG1_WAIT_READ_MON |
+   GPMC_CONFIG1_WAIT_WRITE_MON | GPMC_CONFIG1_READTYPE_ASYNC |
+   GPMC_CONFIG1_WRITETYPE_ASYNC | GPMC_CONFIG1_DEVICETYPE_NOR |
+   GPMC_CONFIG1_MUXADDDATA | GPMC_CONFIG1_PAGE_LEN_16;
+
+   /* SYNC region, primarily for DMA */
+   gpmc_tusb_cs_data[CS_SYNC_IDX].cs = sync;
+   gpmc_tusb_cs_data[CS_SYNC_IDX].mem_size = 0x1000;
+
+   sync_cs = sync;
+
+   gpmc_tusb_cs_data[CS_SYNC_IDX].have_config = true;
+   gpmc_tusb_cs_data[CS_SYNC_IDX].config = waitpin |
+   GPMC_CONFIG1_DEVICESIZE_16 | GPMC_CONFIG1_WAIT_READ_MON |
+   GPMC_CONFIG1_WAIT_WRITE_MON | GPMC_CONFIG1_READTYPE_SYNC |
+   GPMC_CONFIG1_WRITETYPE_SYNC | GPMC_CONFIG1_DEVICETYPE_NOR |
+   GPMC_CONFIG1_MUXADDDATA | GPMC_CONFIG1_READMULTIPLE_SUPP |
+   GPMC_CONFIG1_WRITEMULTIPLE_SUPP | GPMC_CONFIG1_PAGE_LEN_16;
+
+   /* IRQ */
+   ret = gpio_request_one(irq, GPIOF_IN, "TUSB6010 irq");
+   if (ret < 0) {
+   pr_err("error: %s: gpio_request_one: %d\n", __func__, ret);
+   return NULL;
+  

[PATCH 3/9] ARM: OMAP2+: flash: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for various flash
devices. As gpmc driver is now present, populate details
needed for the driver to configure gpmc, gpmc driver would
configure based on this information. Old interface has been
left as is so that platforms can continue configuring gpmc
using old interface too. This is done so that driver
conversion can be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/board-flash.c |  126 +
 arch/arm/mach-omap2/board-flash.h |   29 +
 2 files changed, 155 insertions(+)

diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index 0ee820b..f3be964 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -53,6 +53,15 @@ static struct platform_device board_nor_device = {
.resource   = &board_nor_resource,
 };
 
+static struct gpmc_cs_data gpmc_nor_cs_data;
+
+static struct gpmc_device_pdata gpmc_nor_data = {
+   .name   = "physmap-flash",
+   .id = 0,
+   .cs_data= &gpmc_nor_cs_data,
+   .num_cs = 1,
+};
+
 static void
 __init board_nor_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
 {
@@ -81,6 +90,25 @@ __init board_nor_init(struct mtd_partition *nor_parts, u8 
nr_parts, u8 cs)
pr_err("Unable to register NOR device\n");
 }
 
+static __init struct gpmc_device_pdata *
+gpmc_nor_update(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
+{
+   board_nor_data.parts= nor_parts;
+   board_nor_data.nr_parts = nr_parts;
+
+   gpmc_nor_cs_data.cs = cs;
+
+   if (omap_rev() >= OMAP3430_REV_ES1_0)
+   gpmc_nor_cs_data.mem_size = FLASH_SIZE_SDPV2;
+   else
+   gpmc_nor_cs_data.mem_size = FLASH_SIZE_SDPV1;
+
+   gpmc_nor_data.pdata = &board_nor_data;
+   gpmc_nor_data.pdata_size = sizeof(board_nor_data);
+
+   return &gpmc_nor_data;
+}
+
 #if defined(CONFIG_MTD_ONENAND_OMAP2) || \
defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
 static struct omap_onenand_platform_data board_onenand_data = {
@@ -97,6 +125,16 @@ __init board_onenand_init(struct mtd_partition 
*onenand_parts,
 
gpmc_onenand_init(&board_onenand_data);
 }
+
+struct omap_onenand_platform_data * __init
+board_onenand_update(struct mtd_partition *onenand_parts, u8 nr_parts, u8 cs)
+{
+   board_onenand_data.cs   = cs;
+   board_onenand_data.parts= onenand_parts;
+   board_onenand_data.nr_parts = nr_parts;
+
+   return &board_onenand_data;
+}
 #else
 void
 __init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8 cs)
@@ -148,6 +186,19 @@ __init board_nand_init(struct mtd_partition *nand_parts, 
u8 nr_parts, u8 cs,
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
gpmc_nand_init(&board_nand_data);
 }
+
+struct omap_nand_platform_data *
+__init board_nand_update(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+   int nand_type, struct gpmc_timings *gpmc_t)
+{
+   board_nand_data.cs  = cs;
+   board_nand_data.parts   = nand_parts;
+   board_nand_data.nr_parts= nr_parts;
+   board_nand_data.devsize = nand_type;
+   board_nand_data.gpmc_t  = gpmc_t;
+
+   return &board_nand_data;
+}
 #endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
 
 /**
@@ -246,3 +297,78 @@ void __init board_flash_init(struct flash_partitions 
partition_info[],
partition_info[2].nr_parts, nandcs,
nand_type, nand_default_timings);
 }
+
+struct gpmc_device_pdata __init **board_flash_update(
+   struct flash_partitions partition_info[],
+   char chip_sel_board[][GPMC_CS_NUM],
+   int nand_type,
+   struct gpmc_device_pdata **gpmc_data)
+{
+   u8  cs = 0;
+   u8  norcs = GPMC_CS_NUM + 1;
+   u8  nandcs = GPMC_CS_NUM + 1;
+   u8  onenandcs = GPMC_CS_NUM + 1;
+   u8  idx;
+   unsigned char   *config_sel = NULL;
+
+   if (gpmc_data == NULL) {
+   pr_err("%s: NULL arguement passed\n", __func__);
+   return NULL;
+   }
+
+   idx = get_gpmc0_type();
+   if (idx >= MAX_SUPPORTED_GPMC_CONFIG) {
+   pr_err("%s: Invalid chip select: %d\n", __func__, cs);
+   return gpmc_data;
+   }
+   config_sel = (unsigned char *)(chip_sel_board[idx]);
+
+   while (cs < GPMC_CS_NUM) {
+   switch (config_sel[cs]) {
+   case PDC_NOR:
+   if (norcs > GPMC_CS_NUM)
+   norcs = cs;
+   break;
+   case PDC_NAND:
+   if (nandcs > GPMC_CS_NUM)
+ 

[PATCH 2/9] ARM: OMAP2+: gpmc-onenand: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for onenand. As
gpmc driver is now present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-onenand.c|  117 +
 arch/arm/plat-omap/include/plat/onenand.h |8 +-
 2 files changed, 109 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index fd4c48d..0601284 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -27,6 +27,20 @@
 
 static struct omap_onenand_platform_data *gpmc_onenand_data;
 
+static struct gpmc_cs_data gpmc_onenand_cs_info = {
+   .mem_size   = ONENAND_IO_SIZE,
+   .have_config= true,
+   .config = GPMC_CONFIG1_DEVICESIZE_16 | GPMC_CONFIG1_MUXADDDATA |
+   GPMC_CONFIG1_DEVICETYPE_NOR,
+};
+
+static struct gpmc_device_pdata gpmc_onenand_info = {
+   .name   = "omap2-onenand",
+   .id = -1,
+   .cs_data= &gpmc_onenand_cs_info,
+   .num_cs = 1,
+};
+
 static struct resource gpmc_onenand_resource = {
.flags  = IORESOURCE_MEM,
 };
@@ -80,15 +94,22 @@ static int omap2_onenand_set_async_mode(int cs)
t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
t.wr_cycle  = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
 
-   /* Configure GPMC for asynchronous read */
-   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
- GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_MUXADDDATA);
-
-   err = gpmc_cs_set_timings(cs, &t);
-   if (err)
-   return err;
-
+   /* gpmc driver interface being used */
+   if (gpmc_onenand_info.pdata != NULL) {
+   gpmc_onenand_cs_info.time_ctrl.type = has_period;
+   gpmc_onenand_cs_info.time_ctrl.timings = t;
+   return 0;
+   /* older interface */
+   } else {
+   /* Configure GPMC for asynchronous read */
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE_16 |
+ GPMC_CONFIG1_MUXADDDATA);
+
+   err = gpmc_cs_set_timings(cs, &t);
+   if (err)
+   return err;
+   }
 
return 0;
 }
@@ -180,6 +201,9 @@ static int omap2_onenand_set_sync_mode(struct 
omap_onenand_platform_data *cfg,
int cs = cfg->cs, freq = *freq_ptr;
u32 reg;
bool clk_dep = false;
+   struct gpmc_cs_data cs_info;
+
+   memset(&cs_info, 0, sizeof(cs_info));
 
/* Ensure sync read and sync write are disabled */
reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
@@ -275,7 +299,16 @@ static int omap2_onenand_set_sync_mode(struct 
omap_onenand_platform_data *cfg,
set_onenand_cfg(onenand_base, latency,
sync_read, sync_write, hf, vhf);
 
-   if (div == 1) {
+   /* gpmc driver interface */
+   if (gpmc_onenand_info.pdata != NULL) {
+   if (div == 1) {
+   cs_info.time_ctrl.bool_timings.cs_extra_delay = true;
+   cs_info.time_ctrl.bool_timings.adv_extra_delay = true;
+   cs_info.time_ctrl.bool_timings.oe_extra_delay = true;
+   cs_info.time_ctrl.bool_timings.we_extra_delay = true;
+   }
+   /* old interface */
+   } else if (div == 1) {
reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
reg |= (1 << 7);
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, reg);
@@ -347,8 +380,39 @@ static int omap2_onenand_set_sync_mode(struct 
omap_onenand_platform_data *cfg,
}
}
 
-   /* Configure GPMC for synchronous read */
-   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+   /* gpmc driver interface */
+   if (gpmc_onenand_info.pdata != NULL) {
+   cs_info.have_config = true;
+   cs_info.config = GPMC_CONFIG1_DEVICESIZE_16 |
+   GPMC_CONFIG1_MUXADDDATA |
+   GPMC_CONFIG1_DEVICETYPE_NOR |
+   GPMC_CONFIG1_WRAPBURST_SUPP |
+   GPMC_CONFIG1_READMULTIPLE_SUPP |
+   GPMC_CONFIG1_PAGE_LEN_16;
+
+   if (!cpu_is_omap34xx())
+   cs_info.config |= GPMC_WAITPIN_0 |
+   GPMC_CONFIG1_WAIT_READ_MON;
+   if (sync_read)
+   cs_info.config |=
+   

[PATCH 1/9] ARM: OMAP2+: gpmc-nand: Adapt to use gpmc driver

[Afzal Mohammed]

Currently gpmc is configured in platform for nand. As now
gpmc driver is present, populate details needed for the
driver to configure gpmc, gpmc driver would configure based
on this information. Old interface has been left as is so
that platforms can continue configuring gpmc using old
interface too. This is done so that driver conversion can
be done gradually without breaking any.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-nand.c|   41 
 arch/arm/plat-omap/include/plat/nand.h |7 ++
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 045596a..13248d7 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,6 +21,20 @@
 #include 
 #include 
 
+static struct gpmc_cs_data gpmc_nand_cs_info = {
+   .have_config= true,
+   .config = GPMC_CONFIG1_DEVICETYPE_NAND,
+   .irq_config = GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT,
+};
+
+static struct gpmc_device_pdata gpmc_nand_info = {
+   .name   = "omap2-nand",
+   .id = 0,
+   .cs_data= &gpmc_nand_cs_info,
+   .num_cs = 1,
+   .is_nand= true,
+};
+
 static struct resource gpmc_nand_resource[] = {
{
.flags  = IORESOURCE_MEM,
@@ -76,6 +90,13 @@ static int omap2_nand_gpmc_retime(struct 
omap_nand_platform_data *gpmc_nand_data
t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->cs_wr_off);
t.wr_cycle  = gpmc_round_ns_to_ticks(gpmc_nand_data->gpmc_t->wr_cycle);
 
+   /* gpmc driver interface being used */
+   if (gpmc_nand_info.pdata != NULL) {
+   gpmc_nand_cs_info.time_ctrl.type = has_period;
+   gpmc_nand_cs_info.time_ctrl.timings = t;
+   return 0;
+   }
+
/* Configure GPMC */
if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 1);
@@ -139,3 +160,23 @@ out_free_cs:
 
return err;
 }
+
+struct gpmc_device_pdata *
+__init gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data)
+{
+   gpmc_nand_info.pdata = gpmc_nand_data;
+   gpmc_nand_info.pdata_size = sizeof(*gpmc_nand_data);
+
+   gpmc_nand_cs_info.cs = gpmc_nand_data->cs;
+   gpmc_nand_cs_info.mem_size = NAND_IO_SIZE;
+
+   if (gpmc_nand_data->devsize == NAND_BUSWIDTH_16)
+   gpmc_nand_cs_info.config |= GPMC_CONFIG1_DEVICESIZE_16;
+   if (gpmc_nand_data->dev_ready)
+   gpmc_nand_cs_info.config |= GPMC_CONFIG1_WAIT_READ_MON |
+   GPMC_CONFIG1_WAIT_WRITE_MON;
+
+   omap2_nand_gpmc_retime(gpmc_nand_data);
+
+   return &gpmc_nand_info;
+}
diff --git a/arch/arm/plat-omap/include/plat/nand.h 
b/arch/arm/plat-omap/include/plat/nand.h
index 290cef5..27700e1 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -36,9 +36,16 @@ struct omap_nand_platform_data {
 
 #if defined(CONFIG_MTD_NAND_OMAP2) || defined(CONFIG_MTD_NAND_OMAP2_MODULE)
 extern int gpmc_nand_init(struct omap_nand_platform_data *d);
+struct gpmc_device_pdata *
+gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data);
 #else
 static inline int gpmc_nand_init(struct omap_nand_platform_data *d)
 {
return 0;
 }
+static inline struct gpmc_device_pdata *
+gpmc_nand_update(struct omap_nand_platform_data *gpmc_nand_data)
+{
+   return NULL;
+};
 #endif
-- 
1.7.10.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

[PATCH 0/9] Adapt GPMC peripherals, platforms to driver

[Afzal Mohammed]

Hi,

This series provides new interface for GPMC peripherals that use
helper functions for initialization and configures omap3evm &
beagleboard GPMC in Kernel. Existing interface would continue to
serve its purpose as before.

New interface for smsc911x has been provided the runtime timing
calculation capability. This had to be tested on different boards.
omap3evm has been converted to use this new smsc911x runtime
calculation capability, thus is being configured in Kernel.

beagleboard nand has been modified to use new interface in addition to
making use of runtime calculation, and is being configured in Kernel

This series is based on 3.5-rc1, and is dependent on [1,2,3,4] and has
been tested on omap3evm (smsc911x) rev G & C and beagle board(nand)

Also using private patches, nand & onenand was tested on omap3evm,
rev G & C respectively (as support for these were not in mainline)

omap3evm & beagleboard are the two boards that could be tested here.
Within a couple of days, series for converting other boards (but
which can't be tested) would be posted (unless there are strong
objections to the way these patch series are going) along with
updation of feature-removal-schedule.txt regarding deprecation of
GPMC bootloader dependency (feature-removal-schedule.txt patch would
make sense only with the modification of remaining boards to work
gpmc driver)

Regards
Afzal

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html
[4] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69897.html

Afzal Mohammed (9):
  ARM: OMAP2+: gpmc-nand: Adapt to use gpmc driver
  ARM: OMAP2+: gpmc-onenand: Adapt to use gpmc driver
  ARM: OMAP2+: flash: Adapt to use gpmc driver
  ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver
  ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
  ARM: OMAP2+: gpmc-smsc911x: Adapt to use gpmc driver
  ARM: OMAP2+: gpmc-smsc911x: runtime time calculation
  ARM: OMAP2+: board omap3evm: use gpmc driver
  ARM: OMAP2+: board omap3beagle: use gpmc driver

 arch/arm/mach-omap2/board-flash.c   |  126 +++
 arch/arm/mach-omap2/board-flash.h   |   29 ++
 arch/arm/mach-omap2/board-omap3beagle.c |   16 ++-
 arch/arm/mach-omap2/board-omap3evm.c|   12 ++-
 arch/arm/mach-omap2/gpmc-nand.c |   41 
 arch/arm/mach-omap2/gpmc-onenand.c  |  117 ++---
 arch/arm/mach-omap2/gpmc-smc91x.c   |   69 +++--
 arch/arm/mach-omap2/gpmc-smsc911x.c |  119 +
 arch/arm/mach-omap2/usb-tusb6010.c  |  113 +++-
 arch/arm/plat-omap/include/plat/gpmc-smc91x.h   |   12 ++-
 arch/arm/plat-omap/include/plat/gpmc-smsc911x.h |   25 -
 arch/arm/plat-omap/include/plat/gpmc.h  |8 ++
 arch/arm/plat-omap/include/plat/nand.h  |7 ++
 arch/arm/plat-omap/include/plat/onenand.h   |8 +-
 14 files changed, 662 insertions(+), 40 deletions(-)

-- 
1.7.10.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] omap2+: add drm device

[Tomi Valkeinen]

On Mon, 2012-06-11 at 09:51 -0500, Gross, Andy wrote:
> Tomi,
> 
> 
> So at this point, are you OK with deferring a split of the DMM until
> it necessary to do so (if ever)?  I'd like to get this patch in so
> that people have a working omapdrm device when they enable the config
> options.

Yes, I'm ok with it.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> A typo fix for this cosmetic change and mute a failed message from
> a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.
> 
> Signed-off-by: Zumeng Chen 
> ---
>  drivers/mfd/omap-usb-host.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 7e96bb2..9aaaf3c 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct 
> platform_device *pdev)
>   goto err_usbtll_p2_fck;
>   }
>  
> +#ifndef CONFIG_MACH_OMAP3EVM
> + /* for OMAP3 , the clk set parent fails */
>   if (is_ehci_phy_mode(pdata->port_mode[0])) {
> - /* for OMAP3 , the clk set paretn fails */
>   ret = clk_set_parent(omap->utmi_p1_fck,
>   omap->xclk60mhsp1_ck);
>   if (ret != 0)

This begs the question, why is port_mode[0] set to ehci phy mode if this
is failing? Something does not seem right here but this does not look
like the right fix.

Cheers
Jon
--
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] omap2+: add drm device

[Gross, Andy]

Tomi,

So at this point, are you OK with deferring a split of the DMM until it
necessary to do so (if ever)?  I'd like to get this patch in so that people
have a working omapdrm device when they enable the config options.

Regards,

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

Re: [PATCH 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> Signed-off-by: Vaibhav Hiremath 
> Tested-by: Zumeng Chen 

I think that you need to have something in the changelog above, even if
this is a trivial change.

> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   39 
> ++
>  1 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 639bd07..fef911d 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -24,6 +24,10 @@
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -43,6 +47,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "common.h"
>  #include 
>  #include 
> @@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] 
> = {
>   REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
>  };
>  
> +static struct mtd_partition omap3evm_nand_partitions[] = {
> + /* All the partition sizes are listed in terms of NAND block size */
> + {
> + .name   = "xloader-nand",

Is this the only non-volatile memory on the EVM? If so, you can probably
drop the "-nand" part from the name. Also, if you look at other board
files to be consistent in naming they use "X-Loader".

> + .offset = 0,
> + .size   = 4*(SZ_128K),
> + .mask_flags = MTD_WRITEABLE
> + },
> + {
> + .name   = "uboot-nand",

"U-Boot"

> + .offset = MTDPART_OFS_APPEND,
> + .size   = 14*(SZ_128K),
> + .mask_flags = MTD_WRITEABLE
> + },
> + {
> + .name   = "params-nand",

"U-Boot Env"

> + .offset = MTDPART_OFS_APPEND,
> + .size   = 2*(SZ_128K)
> + },
> + {
> + .name   = "linux-nand",

"Kernel"

> + .offset = MTDPART_OFS_APPEND,
> + .size   = 40*(SZ_128K)
> + },
> + {
> + .name   = "jffs2-nand",

"File System"
> + .size   = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND,
> + },
> +};
> +
>  static void __init omap3_evm_init(void)
>  {
>   struct omap_board_mux *obm;
> @@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
>   }
>   usb_musb_init(&musb_board_data);
>   usbhs_init(&usbhs_bdata);
> + omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
> +  ARRAY_SIZE(omap3evm_nand_partitions));
> +
>   omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
>   omap3evm_init_smsc911x();
>   omap3_evm_display_init();

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

Re: [PATCH 0/5] OMAP3530evm misc fixes for linux-omap

[Jon Hunter]

On 06/11/2012 09:00 AM, Zumeng Chen wrote:
> These patches fix misc problems when reflash ti-omap3530evm for
> master branch on Linux-omap. Currently they have been tested on
> 3530evm but were not ack'ed.
> 
> Most of them are the leftovers from the great original developers
> with my the latest updates for adapting to the current kernel, so
> I add you directly into SOB(If not proper, please let me know).

I don't see any references to the original patches in the changelogs. If
you have references you may wish to add them for historical purposes.

Cheers
Jon
--
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 v5 14/14] ARM: OMAP2+: gpmc: writeprotect helper

[Afzal Mohammed]

GPMC has a writeprotect pin that can be connected to
peripherals. If any CS wants to enable writeprotect,
writeprotect will be enabled, once CS configurations
are finished.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 98b52c3..eec011a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -159,6 +159,7 @@ struct gpmc_peripheral {
 static struct gpmc_peripheral gpmc_peripheral[GPMC_CS_NUM];
 static unsigned gpmc_num_peripheral;
 static unsigned gpmc_waitpin_map;
+static bool gpmc_writeprotect;
 
 static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
 static struct irq_chip gpmc_irq_chip;
@@ -976,6 +977,9 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
else if (conf & GPMC_CONFIG1_PAGE_LEN_16)
l |= GPMC_CONFIG1_PAGE_LEN_16;
 
+   if (conf & GPMC_CONFIG_WRITEPROTECT)
+   gpmc_writeprotect = true;
+
conf &= (GPMC_CONFIG1_MUXADDDATA |
GPMC_CONFIG1_WRITETYPE_SYNC |
GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
@@ -1462,6 +1466,19 @@ int gpmc_cs_reconfigure(char *name, int id, struct 
gpmc_cs_data *c)
 }
 EXPORT_SYMBOL_GPL(gpmc_cs_reconfigure);
 
+static inline void gpmc_setup_writeprotect(void)
+{
+   u32 l;
+
+   l = gpmc_read_reg(GPMC_CONFIG);
+   if (gpmc_writeprotect == true) {
+   l &= ~GPMC_CONFIG_WRITEPROTECT;
+   dev_info(gpmc_dev, "write protect enabled\n");
+   } else
+   l |= GPMC_CONFIG_WRITEPROTECT;
+   gpmc_write_reg(GPMC_CONFIG, l);
+}
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
@@ -1521,6 +1538,8 @@ static __devinit int gpmc_probe(struct platform_device 
*pdev)
dev_err(gpmc_dev, "device creation on %s failed\n",
g_per->name);
 
+   gpmc_setup_writeprotect();
+
return 0;
 }
 
@@ -1531,6 +1550,7 @@ static __exit int gpmc_remove(struct platform_device 
*pdev)
for (; gpmc_num_peripheral; g_per++, gpmc_num_peripheral--)
platform_device_unregister(g_per->pdev);
 
+   gpmc_writeprotect = false;
gpmc_waitpin_map = 0;
gpmc_free_irq();
gpmc_mem_exit();
-- 
1.7.10.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

[PATCH v5 13/14] ARM: OMAP2+: gpmc: update nand register info

[Afzal Mohammed]

GPMC has dedicated NAND handling blocks and have a few
registers exclusively meant for NAND operations. These
registers can be handled by OMAP NAND driver as it is
meant for handling NAND on GPMC. Update OMAP NAND
platform data with GPMC-NAND register details so that
OMAP NAND driver can handle by itself instead of
relying on GPMC exported symbols.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |9 -
 arch/arm/plat-omap/include/plat/gpmc.h |1 +
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index d493a4c..98b52c3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1500,12 +1501,18 @@ static __devinit int gpmc_probe(struct platform_device 
*pdev)
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
 
/* Traverse NULL terminated array of peripheral pointers and setup */
-   for (gdq = gp->device_pdata, g_per = gpmc_peripheral; *gdq; gdq++)
+   for (gdq = gp->device_pdata, g_per = gpmc_peripheral; *gdq; gdq++) {
+   if ((*gdq)->is_nand) {
+   struct omap_nand_platform_data *p = (*gdq)->pdata;
+
+   gpmc_update_nand_reg(&p->reg, p->cs);
+   }
if (IS_ERR_VALUE(gpmc_setup_device(g_per, *gdq)))
dev_err(gpmc_dev, "gpmc setup on %s failed\n",
(*gdq)->name);
else
g_per++;
+   }
gpmc_num_peripheral = g_per - gpmc_peripheral;
 
for (l = 0, g_per = gpmc_peripheral;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 32017a1..32d7f3d 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -195,6 +195,7 @@ struct gpmc_device_pdata {
unsignedper_res_cnt;
struct gpmc_cs_data *cs_data;
unsignednum_cs;
+   boolis_nand;
 };
 
 struct gpmc_pdata {
-- 
1.7.10.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

[PATCH v5 12/14] ARM: OMAP2+: gpmc: cs reconfigure helper

[Afzal Mohammed]

Helper for reconfiguring CS, peripheral that necessitated
it was OneNAND.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   32 
 arch/arm/plat-omap/include/plat/gpmc.h |2 ++
 2 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 281bd23..d493a4c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1429,6 +1429,38 @@ struct platform_device *gpmc_create_device(struct 
gpmc_peripheral *p)
return pdev;
 }
 
+static int gpmc_match_device(char *name, int id)
+{
+   int i;
+   struct gpmc_peripheral *g_per = gpmc_peripheral;
+
+   for (i = 0; i < gpmc_num_peripheral; i++, g_per++)
+   if (!strcmp(g_per->name, name) && g_per->id == id)
+   return i;
+
+   return -ENOENT;
+}
+
+int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c)
+{
+   int i;
+
+   i = gpmc_match_device(name, id);
+   if (IS_ERR_VALUE(i)) {
+   dev_err(gpmc_dev, "no device %s.%d to configure\n", name, id);
+   return i;
+   }
+
+   if (IS_ERR_VALUE(gpmc_setup_cs_config_timing(gpmc_peripheral + i, c))) {
+   dev_err(gpmc_dev, "error: configure device %s.%d\n", name, id);
+   return i;
+   }
+
+   return gpmc_setup_waitpin(gpmc_peripheral + i);
+
+}
+EXPORT_SYMBOL_GPL(gpmc_cs_reconfigure);
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index e1b130c..32017a1 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -247,6 +247,8 @@ extern int gpmc_cs_configure(int cs, int cmd, int wval);
 extern int gpmc_nand_read(int cs, int cmd);
 extern int gpmc_nand_write(int cs, int cmd, int wval);
 
+extern int gpmc_cs_reconfigure(char *name, int id, struct gpmc_cs_data *c);
+
 int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size);
 int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code);
 
-- 
1.7.10.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

[PATCH v5 11/14] ARM: OMAP2+: gpmc: handle connected peripherals

[Afzal Mohammed]

Platform will provide driver with configuration details for
each CS like configuration, timing, interrupts. Setup GPMC
based on it. Platform data also provides platform data &
resources used for connected peripheral (eg. gpio irq).
GPMC driver tunnels those information to respective driver.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |  146 
 1 file changed, 146 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 9073a8a..281bd23 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -155,6 +155,8 @@ struct gpmc_peripheral {
struct platform_device  *pdev;
 };
 
+static struct gpmc_peripheral gpmc_peripheral[GPMC_CS_NUM];
+static unsigned gpmc_num_peripheral;
 static unsigned gpmc_waitpin_map;
 
 static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
@@ -1235,6 +1237,39 @@ static int gpmc_setup_cs_waitpin(struct gpmc_peripheral 
*g_per, unsigned cs,
return 0;
 }
 
+static int gpmc_setup_cs_config_timing(struct gpmc_peripheral *g_per,
+   struct gpmc_cs_data *cs)
+{
+   int ret;
+
+   /* some boards rely on bootloader for configuration */
+   if (cs->have_config) {
+   gpmc_setup_cs_config(cs->cs, cs->config);
+   ret = gpmc_setup_cs_waitpin(g_per, cs->cs, cs->config);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(gpmc_dev, "error: waitpin on CS %d\n", cs->cs);
+   return ret;
+   }
+   } else
+   gpmc_print_cs_config(cs->cs);
+
+   /* some boards rely on bootloader for timing */
+   if (cs->time_ctrl.type == has_period) {
+   ret = gpmc_cs_set_timings(cs->cs, &cs->time_ctrl.timings);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(gpmc_dev, "error: timing on CS: %d\n", cs->cs);
+   return ret;
+   }
+   gpmc_cs_misc_timings(cs->cs, &cs->time_ctrl.bool_timings);
+   } else if (cs->time_ctrl.type == has_clock) {
+   gpmc_cs_set_register_timings(cs->cs, &cs->time_ctrl.timings);
+   gpmc_cs_misc_timings(cs->cs, &cs->time_ctrl.bool_timings);
+   } else
+   gpmc_print_cs_timings(cs->cs);
+
+   return 0;
+}
+
 static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
 {
return bitmask;
@@ -1307,10 +1342,100 @@ static int gpmc_setup_waitpin(struct gpmc_peripheral 
*g_per)
return 0;
 }
 
+static __devinit int gpmc_setup_cs(struct gpmc_peripheral *g_per,
+   struct gpmc_cs_data *cs, struct resource *res)
+{
+   int num, ret;
+
+   num = gpmc_setup_cs_mem(cs, res);
+   if (IS_ERR_VALUE(num))
+   return num;
+
+   ret = gpmc_setup_cs_config_timing(g_per, cs);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+
+   num += gpmc_setup_cs_irq(cs, res + num);
+
+   return num;
+}
+
+static __devinit int gpmc_setup_device(struct gpmc_peripheral *g_per,
+   struct gpmc_device_pdata *gdp)
+{
+   int i, n, ret;
+   struct gpmc_cs_data *cs;
+
+   for (i = 0, n = gdp->num_cs, cs = gdp->cs_data;
+   i < gdp->num_cs; i++, cs++)
+   n += hweight32(cs->irq_config);
+
+   g_per->gpmc_res = devm_kzalloc(gpmc_dev, sizeof(*g_per->gpmc_res) * n,
+   GFP_KERNEL);
+   if (g_per->gpmc_res == NULL) {
+   dev_err(gpmc_dev, "error: memory allocation\n");
+   return -ENOMEM;
+   }
+
+   for (i = 0, cs = gdp->cs_data, g_per->gpmc_res_cnt = 0;
+   i < gdp->num_cs; cs++, i++) {
+   ret = gpmc_setup_cs(g_per, cs,
+   g_per->gpmc_res + g_per->gpmc_res_cnt);
+   if (IS_ERR_VALUE(ret) ||
+   IS_ERR_VALUE(gpmc_setup_waitpin(g_per))) {
+   dev_err(gpmc_dev, "error: setup for %s\n", gdp->name);
+   devm_kfree(gpmc_dev, g_per->gpmc_res);
+   g_per->gpmc_res = NULL;
+   g_per->gpmc_res_cnt = 0;
+   return -EINVAL;
+   } else
+   g_per->gpmc_res_cnt += ret;
+   }
+
+   g_per->name = gdp->name;
+   g_per->id = gdp->id;
+   g_per->pdata = gdp->pdata;
+   g_per->pdata_size = gdp->pdata_size;
+   g_per->per_res = gdp->per_res;
+   g_per->per_res_cnt = gdp->per_res_cnt;
+
+   return 0;
+}
+
+static __devinit
+struct platform_device *gpmc_create_device(struct gpmc_peripheral *p)
+{
+   int num = p->per_res_cnt + p->gpmc_res_cnt;
+   struct resource *res;
+   struct platform_device *pdev;
+
+   res = devm_kzalloc(gpmc_dev, sizeof(struct resource) * num,
+  

[PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper

[Afzal Mohammed]

Helper for configuring waitpin. There are two parts to it;
configuring at CS level and the other at device level.
A device embedding multiple CS has been provided the
capability to use same waitpin (different waitpins has not
been supported as presently there are no GPMC peripherals
doing so)

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |  122 
 arch/arm/plat-omap/include/plat/gpmc.h |9 +++
 2 files changed, 131 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5a6f708..9073a8a 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -75,6 +75,8 @@
 #defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
 #defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
 
+#defineGPMC_CONFIG_WAITPIN_POLARITY_SHIFT  0x8
+
 #define GPMC_CS0_OFFSET0x60
 #define GPMC_CS_SIZE   0x30
 
@@ -93,6 +95,19 @@
  */
 #defineGPMC_NR_IRQ 2
 
+enum {
+   GPMC_WAITPIN_IDX0,
+   GPMC_WAITPIN_IDX1,
+   GPMC_WAITPIN_IDX2,
+   GPMC_WAITPIN_IDX3,
+   GPMC_NR_WAITPIN
+};
+
+enum {
+   LOW,
+   HIGH
+};
+
 struct gpmc_client_irq {
unsignedirq;
u32 bitmask;
@@ -140,6 +155,8 @@ struct gpmc_peripheral {
struct platform_device  *pdev;
 };
 
+static unsigned gpmc_waitpin_map;
+
 static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
 static struct irq_chip gpmc_irq_chip;
 static unsigned gpmc_irq_start;
@@ -1162,6 +1179,62 @@ static void gpmc_print_cs_timings(int cs)
gpmc_get_one_timing(cs, GPMC_CS_CONFIG6, 7, 7));
 }
 
+static int gpmc_setup_cs_waitpin(struct gpmc_peripheral *g_per, unsigned cs,
+   unsigned conf)
+{
+   unsigned idx;
+   bool polarity = 0;
+   u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+   switch (conf & GPMC_WAITPIN_MASK) {
+   case GPMC_WAITPIN_0:
+   idx =  GPMC_WAITPIN_IDX0;
+   break;
+   case GPMC_WAITPIN_1:
+   idx =  GPMC_WAITPIN_IDX1;
+   break;
+   case GPMC_WAITPIN_2:
+   idx =  GPMC_WAITPIN_IDX2;
+   break;
+   case GPMC_WAITPIN_3:
+   idx =  GPMC_WAITPIN_IDX3;
+   break;
+   /* no waitpin */
+   case 0:
+   return 0;
+   break;
+   default:
+   dev_err(gpmc_dev, "multiple waitpins selected on CS:%u\n", cs);
+   return -EINVAL;
+   break;
+   }
+
+   polarity = !!(conf & GPMC_WAITPIN_ACTIVE_HIGH);
+
+   if (g_per->have_waitpin) {
+   if (g_per->waitpin != idx ||
+   g_per->waitpin_polarity != polarity) {
+   dev_err(gpmc_dev, "error: conflict: waitpin %u with 
polarity %d on device %s.%d\n",
+   g_per->waitpin, g_per->waitpin_polarity,
+   g_per->name, g_per->id);
+   return -EBUSY;
+   }
+   } else {
+   g_per->have_waitpin = true;
+   g_per->waitpin = idx;
+   g_per->waitpin_polarity = polarity;
+   }
+
+   l |= conf & GPMC_CONFIG1_WAIT_WRITE_MON;
+   l |= conf & GPMC_CONFIG1_WAIT_READ_MON;
+   l &= ~GPMC_CONFIG1_WAIT_PIN_SEL_MASK;
+   l |= GPMC_CONFIG1_WAIT_PIN_SEL(idx);
+
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+
+   return 0;
+}
+
 static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
 {
return bitmask;
@@ -1185,6 +1258,55 @@ static __devinit int gpmc_setup_cs_irq(struct 
gpmc_cs_data *cs,
return n;
 }
 
+static inline int gpmc_waitpin_is_reserved(unsigned waitpin)
+{
+   return gpmc_waitpin_map & (0x1 << waitpin);
+}
+
+static inline void gpmc_reserve_waitpin(unsigned waitpin)
+{
+   gpmc_waitpin_map &= ~(0x1 << waitpin);
+   gpmc_waitpin_map |= (0x1 << waitpin);
+}
+
+static int gpmc_waitpin_request(unsigned waitpin)
+{
+   if (!(waitpin < GPMC_NR_WAITPIN))
+   return -ENODEV;
+
+   if (gpmc_waitpin_is_reserved(waitpin))
+   return -EBUSY;
+   else
+   gpmc_reserve_waitpin(waitpin);
+
+   return 0;
+}
+
+static int gpmc_setup_waitpin(struct gpmc_peripheral *g_per)
+{
+   int ret;
+   u32 l, shift;
+
+   if (!g_per->have_waitpin)
+   return 0;
+
+   ret = gpmc_waitpin_request(g_per->waitpin);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(gpmc_dev, "waitpin %u reserved\n", g_per->waitpin);
+   return ret;
+   }
+
+   l = gpmc_read_reg(GPMC_CONFIG);
+   shift = g_per->waitpin + GPMC_CONFIG_WAITPIN_POLARITY_SHIFT;
+   if (g_per->waitpin_polarity == HIGH)
+   l |= 1 << shift;
+   else
+   l &= ~(1 << shift);
+   gpmc_write_reg(GPMC_CONFIG, l);
+

[PATCH v5 09/14] ARM: OMAP2+: gpmc: holler if no configuration

[Afzal Mohammed]

Some of the GPMC peripherals depend on bootloader to do the
configuration. This facility is deprecated, notify user
about the present GPMC settings & inform that that relying
on bootloader for GPMC setting is deprecated.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |  104 
 1 file changed, 104 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 65052f8..5a6f708 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1058,6 +1058,110 @@ static void gpmc_cs_set_register_timings(int cs, const 
struct gpmc_timings *t)
}
 }
 
+static void gpmc_print_cs_config(int cs)
+{
+   u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+   dev_warn(gpmc_dev, "GPMC CS%d depends on bootloader for config\n", cs);
+   dev_warn(gpmc_dev, "Please update it in Kernel ASAP to prevent losing 
support for this peripheral\n");
+   dev_warn(gpmc_dev, "Bootloader dependency for GPMC configuration is 
deprecated\n");
+
+   dev_warn(gpmc_dev, "muxadddata: %s\n",
+   l & GPMC_CONFIG1_MUXADDDATA ? "yes" : "no");
+   dev_warn(gpmc_dev, "writetypesync: %s\n",
+   l & GPMC_CONFIG1_WRITETYPE_SYNC ? "yes" : "no");
+   dev_warn(gpmc_dev, "writemultiple: %s\n",
+   l & GPMC_CONFIG1_WRITEMULTIPLE_SUPP ? "yes" : "no");
+   dev_warn(gpmc_dev, "readtypesync: %s\n",
+   l & GPMC_CONFIG1_READTYPE_SYNC ? "yes" : "no");
+   dev_warn(gpmc_dev, "readmultiple: %s\n",
+   l & GPMC_CONFIG1_READMULTIPLE_SUPP ? "yes" : "no");
+   dev_warn(gpmc_dev, "wrapburst: %s\n",
+   l & GPMC_CONFIG1_WRAPBURST_SUPP ? "yes" : "no");
+   dev_warn(gpmc_dev, "devicetype: %s\n",
+   l & GPMC_CONFIG1_DEVICETYPE_NAND ? "nand" : "nor");
+   dev_warn(gpmc_dev, "devicesize: %d\n",
+   l & GPMC_CONFIG1_DEVICESIZE_16 ? 16 : 8);
+   dev_warn(gpmc_dev, "pagelength: %d\n",
+   l & GPMC_CONFIG1_PAGE_LEN(~0) ?
+   (l & GPMC_CONFIG1_PAGE_LEN_16 ? 16 : 8) : 4);
+}
+static inline unsigned gpmc_get_one_timing(int cs, int reg, int start, int end)
+{
+   u32 l = gpmc_cs_read_reg(cs, reg);
+   unsigned mask;
+
+   mask = (1 << (end - start + 1)) - 1;
+   l &= (mask << start);
+   return l >>= start;
+}
+
+static void gpmc_print_cs_timings(int cs)
+{
+   dev_warn(gpmc_dev, "GPMC CS%d depends on bootloader for timing\n", cs);
+   dev_warn(gpmc_dev, "Please update it in Kernel ASAP to prevent losing 
support for this peripheral\n");
+   dev_warn(gpmc_dev, "Bootloader dependency for GPMC configuration is 
deprecated\n");
+
+   dev_warn(gpmc_dev, "fclk period: %lups\n", gpmc_get_fclk_period());
+   dev_warn(gpmc_dev, "sync_clk: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 0, 1));
+   dev_warn(gpmc_dev, "wait_monitoring: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 18, 19));
+   dev_warn(gpmc_dev, "clk_activation: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG1, 25, 26));
+   dev_warn(gpmc_dev, "cs_on: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 0, 3));
+   dev_warn(gpmc_dev, "cs_rd_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 8, 12));
+   dev_warn(gpmc_dev, "cs_wr_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG2, 16, 20));
+   dev_warn(gpmc_dev, "adv_on: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 0, 3));
+   dev_warn(gpmc_dev, "adv_rd_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 8, 12));
+   dev_warn(gpmc_dev, "adv_wr_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG3, 16, 20));
+   dev_warn(gpmc_dev, "oe_on: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 0, 3));
+   dev_warn(gpmc_dev, "oe_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 8, 12));
+   dev_warn(gpmc_dev, "we_on: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 16, 19));
+   dev_warn(gpmc_dev, "we_off: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG4, 24, 28));
+   dev_warn(gpmc_dev, "rd_cycle: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 0, 4));
+   dev_warn(gpmc_dev, "wr_cycle: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 8, 12));
+   dev_warn(gpmc_dev, "acess: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 16, 20));
+   dev_warn(gpmc_dev, "page_burst_access: %u\n",
+   gpmc_get_one_timing(cs, GPMC_CS_CONFIG5, 24, 27));
+   dev_warn(gpmc_dev, "bus_turnaround: %u\n",
+   gpmc_get_one_timing(cs, GPMC_C

[PATCH v5 08/14] ARM: OMAP2+: gpmc: bool type timing helper

[Afzal Mohammed]

Some of the timing configuration like extra delay
has bool type configurations. Provide a helper so
that these too can be configured in Kernel.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   55 
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e60076e3..65052f8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -68,6 +68,13 @@
 #define GPMC_ECC_CTRL_ECCREG8  0x008
 #define GPMC_ECC_CTRL_ECCREG9  0x009
 
+#defineGPMC_CONFIG2_CSEXTRADELAY   BIT(7)
+#defineGPMC_CONFIG3_ADVEXTRADELAY  BIT(7)
+#defineGPMC_CONFIG4_OEEXTRADELAY   BIT(7)
+#defineGPMC_CONFIG4_WEEXTRADELAY   BIT(23)
+#defineGPMC_CONFIG6_CYCLE2CYCLEDIFFCSENBIT(6)
+#defineGPMC_CONFIG6_CYCLE2CYCLESAMECSENBIT(7)
+
 #define GPMC_CS0_OFFSET0x60
 #define GPMC_CS_SIZE   0x30
 
@@ -960,6 +967,54 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned 
conf)
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
 }
 
+static void gpmc_cs_misc_timings(int cs, const struct gpmc_misc_timings *p)
+{
+   u32 l;
+
+   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+   if (p->time_para_granularity)
+   l |= GPMC_CONFIG1_TIME_PARA_GRAN;
+   else
+   l &= ~GPMC_CONFIG1_TIME_PARA_GRAN;
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+
+   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
+   if (p->cs_extra_delay)
+   l |= GPMC_CONFIG2_CSEXTRADELAY;
+   else
+   l &= ~GPMC_CONFIG2_CSEXTRADELAY;
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG2, l);
+
+   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG3);
+   if (p->adv_extra_delay)
+   l |= GPMC_CONFIG3_ADVEXTRADELAY;
+   else
+   l &= ~GPMC_CONFIG3_ADVEXTRADELAY;
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG3, l);
+
+   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG4);
+   if (p->oe_extra_delay)
+   l |= GPMC_CONFIG4_OEEXTRADELAY;
+   else
+   l &= ~GPMC_CONFIG4_OEEXTRADELAY;
+   if (p->we_extra_delay)
+   l |= GPMC_CONFIG4_WEEXTRADELAY;
+   else
+   l &= ~GPMC_CONFIG4_WEEXTRADELAY;
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG4, l);
+
+   l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG6);
+   if (p->cycle2cyclesamecsen)
+   l |= GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+   else
+   l &= ~GPMC_CONFIG6_CYCLE2CYCLESAMECSEN;
+   if (p->cycle2cyclediffcsen)
+   l |= GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
+   else
+   l &= ~GPMC_CONFIG6_CYCLE2CYCLEDIFFCSEN;
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG6, l);
+}
+
 static inline void gpmc_set_one_timing(int cs, int reg, int start,
int end, u32 val)
 {
-- 
1.7.10.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

[PATCH v5 07/14] ARM: OMAP2+: gpmc: time setting (register#) helper

[Afzal Mohammed]

Helper for setting GPMC timing by taking input as register values.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4e19010..e60076e3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -960,6 +960,49 @@ static void gpmc_setup_cs_config(unsigned cs, unsigned 
conf)
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
 }
 
+static inline void gpmc_set_one_timing(int cs, int reg, int start,
+   int end, u32 val)
+{
+   u32 l;
+   unsigned mask;
+
+   mask = (1 << (end - start + 1)) - 1;
+   l = gpmc_cs_read_reg(cs, reg);
+   l &= ~(mask << start);
+   l |= val << start;
+   gpmc_cs_write_reg(cs, reg, l);
+}
+
+static void gpmc_cs_set_register_timings(int cs, const struct gpmc_timings *t)
+{
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 0, 1, t->sync_clk);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 18, 19, t->wait_monitoring);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG1, 25, 26, t->clk_activation);
+
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 0, 3, t->cs_on);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 8, 12, t->cs_rd_off);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG2, 16, 20, t->cs_wr_off);
+
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 0, 3, t->adv_on);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 8, 12, t->adv_rd_off);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG3, 16, 20, t->adv_wr_off);
+
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 0, 3, t->oe_on);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 8, 12, t->oe_off);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 16, 19, t->we_on);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG4, 24, 28, t->we_off);
+
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG5, 24, 27, t->page_burst_access);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 0, 3, t->bus_turnaround);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 8, 11, t->cycle2cycle_delay);
+
+   if (gpmc_revision >= 4) {
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 16, 19,
+   t->wr_data_mux_bus);
+   gpmc_set_one_timing(cs, GPMC_CS_CONFIG6, 24, 28, t->wr_access);
+   }
+}
+
 static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
 {
return bitmask;
-- 
1.7.10.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

[PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

[Afzal Mohammed]

Helper for configuring given CS based on flags.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   33 
 arch/arm/plat-omap/include/plat/gpmc.h |5 +
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 652b245..4e19010 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -927,6 +927,39 @@ static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data 
*cs,
return 1;
 }
 
+static void gpmc_setup_cs_config(unsigned cs, unsigned conf)
+{
+   u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+   l &= ~(GPMC_CONFIG1_MUXADDDATA |
+   GPMC_CONFIG1_WRITETYPE_SYNC |
+   GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
+   GPMC_CONFIG1_READTYPE_SYNC |
+   GPMC_CONFIG1_READMULTIPLE_SUPP |
+   GPMC_CONFIG1_WRAPBURST_SUPP |
+   GPMC_CONFIG1_DEVICETYPE(~0) |
+   GPMC_CONFIG1_DEVICESIZE(~0) |
+   GPMC_CONFIG1_PAGE_LEN(~0));
+
+   l |= conf & GPMC_CONFIG1_DEVICETYPE_NAND;
+   l |= conf & GPMC_CONFIG1_DEVICESIZE_16;
+
+   if (conf & GPMC_CONFIG1_PAGE_LEN_8)
+   l |= GPMC_CONFIG1_PAGE_LEN_8;
+   else if (conf & GPMC_CONFIG1_PAGE_LEN_16)
+   l |= GPMC_CONFIG1_PAGE_LEN_16;
+
+   conf &= (GPMC_CONFIG1_MUXADDDATA |
+   GPMC_CONFIG1_WRITETYPE_SYNC |
+   GPMC_CONFIG1_WRITEMULTIPLE_SUPP |
+   GPMC_CONFIG1_READTYPE_SYNC |
+   GPMC_CONFIG1_READMULTIPLE_SUPP |
+   GPMC_CONFIG1_WRAPBURST_SUPP);
+   l |= conf;
+
+   gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, l);
+}
+
 static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
 {
return bitmask;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 698fa33..ff3f32c 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -57,14 +57,19 @@
 #define GPMC_CONFIG1_WRITETYPE_SYNC (1 << 27)
 #define GPMC_CONFIG1_CLKACTIVATIONTIME(val) ((val & 3) << 25)
 #define GPMC_CONFIG1_PAGE_LEN(val)  ((val & 3) << 23)
+#defineGPMC_CONFIG1_PAGE_LEN_4 GPMC_CONFIG1_PAGE_LEN(0)
+#defineGPMC_CONFIG1_PAGE_LEN_8 GPMC_CONFIG1_PAGE_LEN(1)
+#defineGPMC_CONFIG1_PAGE_LEN_16GPMC_CONFIG1_PAGE_LEN(2)
 #define GPMC_CONFIG1_WAIT_READ_MON  (1 << 22)
 #define GPMC_CONFIG1_WAIT_WRITE_MON (1 << 21)
 #define GPMC_CONFIG1_WAIT_MON_IIME(val) ((val & 3) << 18)
 #define GPMC_CONFIG1_WAIT_PIN_SEL(val)  ((val & 3) << 16)
 #define GPMC_CONFIG1_DEVICESIZE(val)((val & 3) << 12)
+#defineGPMC_CONFIG1_DEVICESIZE_8   GPMC_CONFIG1_DEVICESIZE(0)
 #define GPMC_CONFIG1_DEVICESIZE_16  GPMC_CONFIG1_DEVICESIZE(1)
 #define GPMC_CONFIG1_DEVICETYPE(val)((val & 3) << 10)
 #define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0)
+#defineGPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2)
 #define GPMC_CONFIG1_MUXADDDATA (1 << 9)
 #define GPMC_CONFIG1_TIME_PARA_GRAN (1 << 4)
 #define GPMC_CONFIG1_FCLK_DIV(val)  (val & 3)
-- 
1.7.10.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

[PATCH v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers

[Afzal Mohammed]

Helpers for propulating given resource structure
with memory & interrupt information.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   45 
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a91f40f..652b245 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -905,6 +905,51 @@ static void __devinit gpmc_mem_init(void)
}
 }
 
+static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs,
+   struct resource *res)
+{
+   unsigned long start;
+   int ret;
+
+   ret = gpmc_cs_request(cs->cs, cs->mem_size, &start);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(gpmc_dev, "error: gpmc request on CS: %d\n", cs->cs);
+   return ret;
+   }
+
+   res->start = start + cs->mem_offset;
+   res->end = res->start + cs->mem_size - 1;
+   res->flags = IORESOURCE_MEM;
+
+   dev_info(gpmc_dev, "memory 0x%x-0x%x on CS %d\n", res->start,
+   res->end, cs->cs);
+
+   return 1;
+}
+
+static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
+{
+   return bitmask;
+}
+
+static __devinit int gpmc_setup_cs_irq(struct gpmc_cs_data *cs,
+   struct resource *res)
+{
+   int i, n;
+
+   for (i = 0, n = 0; i < GPMC_NR_IRQ; i++)
+   if (gpmc_bit_to_irq(gpmc_client_irq[i].bitmask)
+   & cs->irq_config) {
+   res[n].start = res[n].end = gpmc_client_irq[i].irq;
+   res[n].flags = IORESOURCE_IRQ;
+   dev_info(gpmc_dev, "irq %u on CS %d\n",
+   res[n].start, cs->cs);
+   n++;
+   }
+
+   return n;
+}
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
-- 
1.7.10.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

[PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support

[Afzal Mohammed]

Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |  170 
 1 file changed, 123 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 6dbddb9..a91f40f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@
 
 #include 
 
+#defineDRIVER_NAME "omap-gpmc"
+
 /* GPMC register offsets */
 #define GPMC_REVISION  0x00
 #define GPMC_SYSCONFIG 0x10
@@ -115,6 +118,21 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
 };
 
+struct gpmc_peripheral {
+   char*name;
+   int id;
+   void*pdata;
+   unsignedpdata_size;
+   struct resource *per_res;
+   unsignedper_res_cnt;
+   struct resource *gpmc_res;
+   unsignedgpmc_res_cnt;
+   boolhave_waitpin;
+   boolwaitpin_polarity;
+   unsignedwaitpin;
+   struct platform_device  *pdev;
+};
+
 static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
 static struct irq_chip gpmc_irq_chip;
 static unsigned gpmc_irq_start;
@@ -124,6 +142,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
 static DEFINE_SPINLOCK(gpmc_mem_lock);
 static unsigned int gpmc_cs_map;   /* flag for cs which are initialized */
 static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
+static struct device *gpmc_dev;
+static u32 gpmc_revision;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
 
 static void __iomem *gpmc_base;
 
@@ -433,6 +455,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base, 
unsigned long size)
return r;
 }
 
+static int gpmc_cs_delete_mem(int cs)
+{
+   struct resource *res = &gpmc_cs_mem[cs];
+   int r;
+
+   spin_lock(&gpmc_mem_lock);
+   r = release_resource(&gpmc_cs_mem[cs]);
+   res->start = res->end = 0;
+   spin_unlock(&gpmc_mem_lock);
+
+   return r;
+}
+
 int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
 {
struct resource *res = &gpmc_cs_mem[cs];
@@ -769,7 +804,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
 
 static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
 
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
 {
int i;
u32 regval;
@@ -813,7 +848,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
 }
 
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+   int i;
+
+   if (gpmc_irq)
+   free_irq(gpmc_irq, NULL);
+
+   for (i = 0; i < GPMC_NR_IRQ; i++) {
+   irq_set_handler(gpmc_client_irq[i].irq, NULL);
+   irq_set_chip(gpmc_client_irq[i].irq, &no_irq_chip);
+   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+   }
+
+   irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+   return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+   int cs;
+
+   for (cs = 0; cs < GPMC_CS_NUM; cs++) {
+   if (!gpmc_cs_mem_enabled(cs))
+   continue;
+   gpmc_cs_delete_mem(cs);
+   }
+
+}
+
+static void __devinit gpmc_mem_init(void)
 {
int cs;
unsigned long boot_rom_space = 0;
@@ -840,64 +905,75 @@ static void __init gpmc_mem_init(void)
}
 }
 
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
-   int ret = -EINVAL;
-   int gpmc_irq;
-   char *ck = NULL;
-
-   if (cpu_is_omap24xx()) {
-   ck = "core_l3_ck";
-   if (cpu_is_omap2420())
-   l = OMAP2420_GPMC_BASE;
-   else
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = INT_34XX_GPMC_IRQ;
-   } else if (cpu_is_omap34xx()) {
-   ck = "gpmc_fck";
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = INT_34XX_GPMC_IRQ;
-   } else if (cpu_is_omap44xx()) {
-   ck = "gpmc_ck";
-   l = OMAP44XX_GPMC_BASE;
-   gpmc_irq = OMAP44XX_IRQ_GPMC;
-   }
+   struct resource *res;
 
-   if (WARN_ON(!ck))
-   return ret;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (res == NULL)
+   return -ENOENT;
 
-   gpmc_l3_clk = clk_get(NULL, ck);
-   if (IS_ERR(gpmc_l3_clk)) {
-   printk(KERN_ERR "Could not get GPMC clock %s\n", ck);
-   BUG();
-   }
+   phys_base = res-

[PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper

[Afzal Mohammed]

A driver is being created out of GPMC code. This is being
attempted to acheive by not breaking existing interface,
necessitating requirement of GPMC peripherals being able
to work with as well as without the help of driver. To not
break existing, initcall is required as in old interface
GPMC is configured at arch initcall and GPMC should be
ready to handle old interface by that time

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index b471c2f..6dbddb9 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -902,7 +902,7 @@ postcore_initcall(gpmc_init);
 __init int omap_gpmc_init(struct gpmc_pdata *pdata)
 {
struct omap_hwmod *oh;
-   struct platform_device *pdev;
+   static struct platform_device *pdev;
char *name = "omap-gpmc";
char *oh_name = "gpmc";
 
@@ -912,6 +912,12 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
return -ENODEV;
}
 
+   if (pdev != NULL) {
+   clk_put(gpmc_l3_clk);
+   omap_device_delete(pdev->archdata.od);
+   platform_device_unregister(pdev);
+   }
+
pdev = omap_device_build(name, -1, oh, pdata,
sizeof(*pdata), NULL, 0, 0);
if (IS_ERR(pdev)) {
@@ -929,6 +935,17 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
return 0;
 }
 
+static int __init gpmc_pre_init(void)
+{
+   static struct gpmc_device_pdata *gpmc_device_data[1];
+   struct gpmc_pdata gpmc_data = {
+   .device_pdata   = gpmc_device_data,
+   };
+
+   return omap_gpmc_init(&gpmc_data);
+}
+postcore_initcall(gpmc_pre_init);
+
 static irqreturn_t gpmc_handle_irq(int irq, void *dev)
 {
int i;
-- 
1.7.10.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

[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Afzal Mohammed]

Create API for platforms to adapt gpmc to HWMOD

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |   31 +++
 arch/arm/plat-omap/include/plat/gpmc.h |2 ++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 517953f..b471c2f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -27,6 +27,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -898,6 +899,36 @@ static int __init gpmc_init(void)
 }
 postcore_initcall(gpmc_init);
 
+__init int omap_gpmc_init(struct gpmc_pdata *pdata)
+{
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
+   char *name = "omap-gpmc";
+   char *oh_name = "gpmc";
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh) {
+   pr_err("Could not look up %s\n", oh_name);
+   return -ENODEV;
+   }
+
+   pdev = omap_device_build(name, -1, oh, pdata,
+   sizeof(*pdata), NULL, 0, 0);
+   if (IS_ERR(pdev)) {
+   WARN(1, "Can't build omap_device for %s:%s.\n",
+   name, oh->name);
+   return PTR_ERR(pdev);
+   }
+
+   gpmc_l3_clk = clk_get(NULL, oh->main_clk);
+   if (IS_ERR(gpmc_l3_clk)) {
+   pr_err("Could not get GPMC clock\n");
+   return PTR_ERR(gpmc_l3_clk);
+   }
+
+   return 0;
+}
+
 static irqreturn_t gpmc_handle_irq(int irq, void *dev)
 {
int i;
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 21a8cce..698fa33 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -207,6 +207,8 @@ struct gpmc_nand_regs {
 extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
 extern int gpmc_get_client_irq(unsigned irq_config);
 
+extern int omap_gpmc_init(struct gpmc_pdata *pdata);
+
 extern unsigned int gpmc_ns_to_ticks(unsigned int time_ns);
 extern unsigned int gpmc_ps_to_ticks(unsigned int time_ps);
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-- 
1.7.10.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

[PATCH v5 01/14] ARM: OMAP2+: gpmc: platform definitions

[Afzal Mohammed]

gpmc driver platform definitions

Signed-off-by: Afzal Mohammed 
---
 arch/arm/plat-omap/include/plat/gpmc.h |   49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 802fb22..21a8cce 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -139,6 +139,55 @@ struct gpmc_timings {
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
 };
 
+/* bool type time settings */
+struct gpmc_misc_timings {
+   bool cycle2cyclediffcsen;
+   bool cycle2cyclesamecsen;
+   bool we_extra_delay;
+   bool oe_extra_delay;
+   bool adv_extra_delay;
+   bool cs_extra_delay;
+   bool time_para_granularity;
+};
+
+enum {
+   has_none,
+   has_period,
+   has_clock
+};
+
+struct gpmc_time_ctrl {
+   int type;
+   struct gpmc_timings timings;
+   struct gpmc_misc_timings bool_timings;
+};
+
+struct gpmc_cs_data {
+   unsignedcs;
+   unsigned long   mem_size;
+   unsigned long   mem_offset;
+   boolhave_config;
+   unsignedconfig;
+   struct gpmc_time_ctrl   time_ctrl;
+   unsignedirq_config;
+};
+
+struct gpmc_device_pdata {
+   char*name;
+   int id;
+   void*pdata;
+   unsignedpdata_size;
+   struct resource *per_res;
+   unsignedper_res_cnt;
+   struct gpmc_cs_data *cs_data;
+   unsignednum_cs;
+};
+
+struct gpmc_pdata {
+   unsignednum_device;
+   struct gpmc_device_pdata**device_pdata;
+};
+
 struct gpmc_nand_regs {
void __iomem*gpmc_status;
void __iomem*gpmc_nand_command;
-- 
1.7.10.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

[PATCH v5 00/14] GPMC driver conversion

[Afzal Mohammed]

Hi,

This series is based on 3.5-rc1, and is dependent on [1,2,3]

This series has been tested on omap3evm (smsc911x) rev G & C and
beagle board(nand) using patch series which is going to be posted
shortly (this series only creates a driver out of GPMC code)

Also using private patches, nand & onenand was tested on omap3evm,
rev G & C respectively (as support for these were not in mainline)

Many of GPMC peripherals depend on bootloader for configuration.
This is going to be deprecated. feature-removal-schedule.txt will be
updated in one of the upcoming patch series regarding the same.


[PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be
reverted once all GPMC peripherals are migrated to use driver
interface.

GPMC (General Purpose Memory Controller) in brief:
GPMC is an unified memory controller dedicated to interfacing external
memory devices like
 Asynchronous SRAM like memories and application specific integrated circuit 
devices.
 Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash
 Pseudo-SRAM devices

GPMC details can be referred in AM335X Technical Reference Manual
@ http://www.ti.com/lit/pdf/spruh73

Regards
Afzal

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html
[3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69891.html

v5: Make this a purely driver conversion series, i.e. gpmc-mtd
interactions has been made as a separate series, so is adding
hwmod entry for OMAP2/3.
And modifying gpmc peripheral platform initialization has been
separated out of this series, so is migrating boards to use new
driver interface. GPMC driver conversion which was done in a few
patches in v4 has been tranformed to series of small patches.
Also care has been taken care that old interface will not break
with any of these patches, so both interfaces can coexist.
This helps in converting boards one-by-one gradually. Acquiring
CS has been thrown out. And conclusive comments on v4 has been
addressed.
v4: Handle wait pin (except for interrupts), enhance configuration
& timing interface of GPMC to take care of all boards. Dynamic
allocation of interrupt instead of static. Convert remaining
peripherals to work with GPMC driver. Handle acquiring NAND CS#,
adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor
commenst on v3.
v3: Single device structure passed from platform for peripherals using
multiple CS instead of using multiple device structure having a few
redundant data, handle interrupts, GPMC NAND handling by GPMC NAND
driver instead of GPMC driver
v2: Avoid code movement that kept similar code together (for easy review)

Afzal Mohammed (14):
  ARM: OMAP2+: gpmc: platform definitions
  ARM: OMAP2+: gpmc: Adapt to HWMOD
  ARM: OMAP2+: gpmc: driver migration helper
  ARM: OMAP2+: gpmc: minimal driver support
  ARM: OMAP2+: gpmc: resource creation helpers
  ARM: OMAP2+: gpmc: CS configuration helper
  ARM: OMAP2+: gpmc: time setting (register#) helper
  ARM: OMAP2+: gpmc: bool type timing helper
  ARM: OMAP2+: gpmc: holler if no configuration
  ARM: OMAP2+: gpmc: waitpin helper
  ARM: OMAP2+: gpmc: handle connected peripherals
  ARM: OMAP2+: gpmc: cs reconfigure helper
  ARM: OMAP2+: gpmc: update nand register info
  ARM: OMAP2+: gpmc: writeprotect helper

 arch/arm/mach-omap2/gpmc.c |  817 ++--
 arch/arm/plat-omap/include/plat/gpmc.h |   68 +++
 2 files changed, 842 insertions(+), 43 deletions(-)

-- 
1.7.10.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 5/5] Input: ads7846: set proper debounce time in driver level

[Igor Grinberg]

Hi,

This is input subsystem, add Dmitry and linux-input.

On 06/11/12 17:00, Zumeng Chen wrote:
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
> 
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.

What about other non-OMAP platforms?

NULL pointer for board_pdata, only means that the default pdata is used.
Please, see the common-board-devices.c file more closely.

> 
> This patch has been validated on 3530evm.
> 
> Signed-off-by: Zumeng Chen 
> Signed-off-by: Syed Mohammed Khasim 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/input/touchscreen/ads7846.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ads7846.c 
> b/drivers/input/touchscreen/ads7846.c
> index f02028e..a82a5fb 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -61,6 +61,7 @@
>  
>  /* this driver doesn't aim at the peak continuous sample rate */
>  #define  SAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after 
> */)
> +#define  DEBOUNCE_TIME   310 /* About 10 ms */

I think hard coding this value is wrong.
Can't it be derived from the pdata->debounce_* fields?

>  
>  struct ts_event {
>   /*
> @@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct 
> spi_device *spi, struct ads784
>   }
>  
>   ts->gpio_pendown = pdata->gpio_pendown;
> + gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
>  
>   } else {
>   dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");

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

RE: Current state of AM33xx patches

[Hernandez, Carlos]

> -Original Message-
> From: Jason Kridner [mailto:jkrid...@gmail.com]
> Sent: Monday, June 11, 2012 9:51 AM
> To: Daniel Mack; Tony Lindgren; Hilman, Kevin; Paul Walmsley; Hiremath,
> Vaibhav; Hernandez, Carlos; Maupin, Chase
> Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> Kridner, Jason
> Subject: Re: Current state of AM33xx patches
> 
> From: Daniel Mack 
> >Hey,
> >
> >can anybody give me a quick wrap-up about the current state of AM33xx
> >based SoCs in mainline? What are the next steps to get things merged?
> 
> There is a wiki page [1] that is intended to provide a summary, but I'm
> confident it is not up-to-date.  There is also some automated testing, but
> I'm not aware if any of the test results are public and I believe the
> coverage is fairly limited.  Hopefully Carlos can chime in with any
> information about that.
> 

Linux Nightly Test results are available at 
http://arago-project.org/testresults/linux/
Builds are currently failing due to wpa-supplicant recipe. 

The current nightly test plan includes: USB Host tests, PWM, Alsa, SPI, MMC, 
NAND, EDMA, Ethernet, RTC, I2C, PWM, WDT, CPUFREQ,  Timers, Kernel IPC, Math 
library, LMBench and cyclictest. Let us know if you want other areas to be 
included in the nightly test plan.
For a sample test coverage, check build from last week at
http://arago-project.org/testresults/linux/ti-staging/2012-06-05_16-05-17/am335x-evm/test-log.html

Carlos

> [1]
> http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335
> x
> _Status
> 
> 
> >
> >I'm getting involved in a project that is based on a AM3352 and would
> >like to provide help where necessary and wanted.
> 
> Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
> or Chase can reply with info about any particular subsystems that need
> either review or coding.  Conversion to Device Tree is an on-going complex
> area where Vaibhav is contributing.
> 
> >
> >
> >Thanks,
> >Daniel
> 

--
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/3] ARM: OMAP2+: gpmc: handle additional timings

[Afzal Mohammed]

Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc.c |6 ++
 arch/arm/plat-omap/include/plat/gpmc.h |6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 578fd4c..517953f 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -313,6 +313,12 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings 
*t)
 
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
 
+   GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
+   GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
+
+   GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
+   GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
+
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h 
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..802fb22 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -128,6 +128,12 @@ struct gpmc_timings {
u16 rd_cycle;   /* Total read cycle time */
u16 wr_cycle;   /* Total write cycle time */
 
+   u16 bus_turnaround;
+   u16 cycle2cycle_delay;
+
+   u16 wait_monitoring;
+   u16 clk_activation;
+
/* The following are only on OMAP3430 */
u16 wr_access;  /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
-- 
1.7.10.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

[PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

[Afzal Mohammed]

Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.

Ensuring sync read/write are disabled in onenand cannot be
expect to work properly unless GPMC is setup, this has been
removed. Two instances of doing the same has been clubbed
into one as onenand driver always calls indirectly
"omap2_onenand_set_sync_mode", and has placed such that
configuring onenand for async read/write would happen once
GPMC is setup for async mode (which happens even for sync
mode, before configuring to sync mode).

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/gpmc-onenand.c |   24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
b/arch/arm/mach-omap2/gpmc-onenand.c
index 71d7c07..fd4c48d 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -38,10 +38,9 @@ static struct platform_device gpmc_onenand_device = {
.resource   = &gpmc_onenand_resource,
 };
 
-static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
+static int omap2_onenand_set_async_mode(int cs)
 {
struct gpmc_timings t;
-   u32 reg;
int err;
 
const int t_cer = 15;
@@ -55,11 +54,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem 
*onenand_base)
const int t_wpl = 40;
const int t_wph = 30;
 
-   /* Ensure sync read and sync write are disabled */
-   reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
-   reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
-   writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
-
memset(&t, 0, sizeof(t));
t.sync_clk = 0;
t.cs_on = 0;
@@ -95,10 +89,6 @@ static int omap2_onenand_set_async_mode(int cs, void __iomem 
*onenand_base)
if (err)
return err;
 
-   /* Ensure sync read and sync write are disabled */
-   reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
-   reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
-   writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
 
return 0;
 }
@@ -191,19 +181,21 @@ static int omap2_onenand_set_sync_mode(struct 
omap_onenand_platform_data *cfg,
u32 reg;
bool clk_dep = false;
 
+   /* Ensure sync read and sync write are disabled */
+   reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+   reg &= ~ONENAND_SYS_CFG1_SYNC_READ & ~ONENAND_SYS_CFG1_SYNC_WRITE;
+   writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
+
if (cfg->flags & ONENAND_SYNC_READ) {
sync_read = 1;
} else if (cfg->flags & ONENAND_SYNC_READWRITE) {
sync_read = 1;
sync_write = 1;
} else
-   return omap2_onenand_set_async_mode(cs, onenand_base);
+   return 0;
 
if (!freq) {
/* Very first call freq is not known */
-   err = omap2_onenand_set_async_mode(cs, onenand_base);
-   if (err)
-   return err;
freq = omap2_onenand_get_freq(cfg, onenand_base, &clk_dep);
first_time = 1;
}
@@ -421,6 +413,8 @@ void __init gpmc_onenand_init(struct 
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_resource.end = gpmc_onenand_resource.start +
ONENAND_IO_SIZE - 1;
 
+   omap2_onenand_set_async_mode(gpmc_onenand_data->cs);
+
if (platform_device_register(&gpmc_onenand_device) < 0) {
pr_err("%s: Unable to register OneNAND device\n", __func__);
gpmc_cs_free(gpmc_onenand_data->cs);
-- 
1.7.10.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

[PATCH 1/3] ARM: OMAP2+: nand: unify init functions

[Afzal Mohammed]

Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on bootloader setting. As CS# is hardwired for a given
board, acquiring gpmc CS# has been removed, and updated with
the value on board.

NAND CS# used in beagle board was found to be CS0.
Thomas Weber  reported
that value of devkit8000 to be CS0. Overo board was found
to be using CS0 based on u-boot, while google grep says
omap3touchbook too has CS0.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/board-devkit8000.c |8 +++--
 arch/arm/mach-omap2/board-flash.c  |   45 ++-
 arch/arm/mach-omap2/board-flash.h  |6 ++--
 arch/arm/mach-omap2/board-igep0020.c   |2 +-
 arch/arm/mach-omap2/board-ldp.c|4 +--
 arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
 arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
 arch/arm/mach-omap2/board-overo.c  |7 +++--
 arch/arm/mach-omap2/board-zoom.c   |5 +--
 arch/arm/mach-omap2/common-board-devices.c |   46 
 arch/arm/mach-omap2/common-board-devices.h |1 -
 11 files changed, 56 insertions(+), 84 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 6567c1c..6ee429a 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -59,8 +59,11 @@
 
 #include "mux.h"
 #include "hsmmc.h"
+#include "board-flash.h"
 #include "common-board-devices.h"
 
+#defineNAND_CS 0
+
 #define OMAP_DM9000_GPIO_IRQ   25
 #define OMAP3_DEVKIT_TS_GPIO   27
 
@@ -628,8 +631,9 @@ static void __init devkit8000_init(void)
 
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
-   omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
-ARRAY_SIZE(devkit8000_nand_partitions));
+   board_nand_init(devkit8000_nand_partitions,
+   ARRAY_SIZE(devkit8000_nand_partitions), NAND_CS,
+   NAND_BUSWIDTH_16, NULL);
 
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index 70a81f9..0ee820b 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -108,41 +108,41 @@ __init board_onenand_init(struct mtd_partition 
*nor_parts, u8 nr_parts, u8 cs)
defined(CONFIG_MTD_NAND_OMAP2_MODULE)
 
 /* Note that all values in this struct are in nanoseconds */
-static struct gpmc_timings nand_timings = {
+struct gpmc_timings nand_default_timings[1] = {
+   {
+   .sync_clk = 0,
 
-   .sync_clk = 0,
+   .cs_on = 0,
+   .cs_rd_off = 36,
+   .cs_wr_off = 36,
 
-   .cs_on = 0,
-   .cs_rd_off = 36,
-   .cs_wr_off = 36,
+   .adv_on = 6,
+   .adv_rd_off = 24,
+   .adv_wr_off = 36,
 
-   .adv_on = 6,
-   .adv_rd_off = 24,
-   .adv_wr_off = 36,
+   .we_off = 30,
+   .oe_off = 48,
 
-   .we_off = 30,
-   .oe_off = 48,
+   .access = 54,
+   .rd_cycle = 72,
+   .wr_cycle = 72,
 
-   .access = 54,
-   .rd_cycle = 72,
-   .wr_cycle = 72,
-
-   .wr_access = 30,
-   .wr_data_mux_bus = 0,
+   .wr_access = 30,
+   .wr_data_mux_bus = 0,
+   },
 };
 
-static struct omap_nand_platform_data board_nand_data = {
-   .gpmc_t = &nand_timings,
-};
+static struct omap_nand_platform_data board_nand_data;
 
 void
-__init board_nand_init(struct mtd_partition *nand_parts,
-   u8 nr_parts, u8 cs, int nand_type)
+__init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs,
+   int nand_type, struct gpmc_timings *gpmc_t)
 {
board_nand_data.cs  = cs;
board_nand_data.parts   = nand_parts;
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
+   board_nand_data.gpmc_t  = gpmc_t;
 
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
board_nand_data.gpmc_irq = OMAP_GPMC_IRQ_BASE + cs;
@@ -243,5 +243,6 @@ void __init board_flash_init(struct flash_partitions 
partition_info[],
pr_err("NAND: Unable to find configuration in GPMC\n");
else
board_nand_init(partition_info[2].parts,
-   partition_info[2].nr_parts, nandcs, nand_type);
+   partition_info[2].nr_parts, nandcs,
+   nand_type, nand_default_timings);
 }
diff --git a/arch/arm/m

[PATCH 0/3] Prepare for GPMC driver conversion

[Afzal Mohammed]

Hi,

Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.

This series,
1. Unifies NAND platform initialization functions
2. Cleans up OneNAND platform code a little
3. Handles additional timings in Kernel

This series is based on 3.5-rc1 & made on top of
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69501.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69881.html

Regards
Afzal

Afzal Mohammed (3):
  ARM: OMAP2+: nand: unify init functions
  ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
  ARM: OMAP2+: gpmc: handle additional timings

 arch/arm/mach-omap2/board-devkit8000.c |8 +++--
 arch/arm/mach-omap2/board-flash.c  |   45 ++-
 arch/arm/mach-omap2/board-flash.h  |6 ++--
 arch/arm/mach-omap2/board-igep0020.c   |2 +-
 arch/arm/mach-omap2/board-ldp.c|4 +--
 arch/arm/mach-omap2/board-omap3beagle.c|8 +++--
 arch/arm/mach-omap2/board-omap3touchbook.c |8 +++--
 arch/arm/mach-omap2/board-overo.c  |7 +++--
 arch/arm/mach-omap2/board-zoom.c   |5 +--
 arch/arm/mach-omap2/common-board-devices.c |   46 
 arch/arm/mach-omap2/common-board-devices.h |1 -
 arch/arm/mach-omap2/gpmc-onenand.c |   24 ++-
 arch/arm/mach-omap2/gpmc.c |6 
 arch/arm/plat-omap/include/plat/gpmc.h |6 
 14 files changed, 77 insertions(+), 99 deletions(-)

-- 
1.7.10.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: Current state of AM33xx patches

[Vaibhav Hiremath]

On 6/11/2012 2:58 PM, Daniel Mack wrote:
> Hey,
> 
> can anybody give me a quick wrap-up about the current state of AM33xx
> based SoCs in mainline? What are the next steps to get things merged?
> 

Daniel,

We are in the process of submitting all baseport patches to the
upstream, summary would be,

Accepted:
- Machine and low-level init code
- Basic DT required for boot.
- Voltagedomain, Powerdomain, clockdomain implementation

Currently under work (already submitted multiple versions):
- Clock Tree
- HWMOD

I do maintain wiki page which you should refer for any updates:
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status

In order to get latest and greatest kernel to boot, you can use my repo:
https://github.com/hvaibhav/am335x-linux


Also, note that, currently there will be very minimal feature-set
supported in the kernel, so not sure how much can be leveraged for
production use-cases.


> I'm getting involved in a project that is based on a AM3352 and would
> like to provide help where necessary and wanted.
> 

That's great, help is always required and appreciated.

Thanks,
Vaibhav

> 
> Thanks,
> Daniel
> 

--
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 5/5] Input: ads7846: set proper debounce time in driver level

[Zumeng Chen]

If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.

And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.

This patch has been validated on 3530evm.

Signed-off-by: Zumeng Chen 
Signed-off-by: Syed Mohammed Khasim 
Signed-off-by: Tony Lindgren 
---
 drivers/input/touchscreen/ads7846.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/input/touchscreen/ads7846.c 
b/drivers/input/touchscreen/ads7846.c
index f02028e..a82a5fb 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -61,6 +61,7 @@
 
 /* this driver doesn't aim at the peak continuous sample rate */
 #defineSAMPLE_BITS (8 /*cmd*/ + 16 /*sample*/ + 2 /* before, after 
*/)
+#defineDEBOUNCE_TIME   310 /* About 10 ms */
 
 struct ts_event {
/*
@@ -980,6 +981,7 @@ static int __devinit ads7846_setup_pendown(struct 
spi_device *spi, struct ads784
}
 
ts->gpio_pendown = pdata->gpio_pendown;
+   gpio_set_debounce(pdata->gpio_pendown, DEBOUNCE_TIME);
 
} else {
dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
-- 
1.7.5.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 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

[Zumeng Chen]

A typo fix for this cosmetic change and mute a failed message from
a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM.

Signed-off-by: Zumeng Chen 
---
 drivers/mfd/omap-usb-host.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 7e96bb2..9aaaf3c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -698,8 +698,9 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
goto err_usbtll_p2_fck;
}
 
+#ifndef CONFIG_MACH_OMAP3EVM
+   /* for OMAP3 , the clk set parent fails */
if (is_ehci_phy_mode(pdata->port_mode[0])) {
-   /* for OMAP3 , the clk set paretn fails */
ret = clk_set_parent(omap->utmi_p1_fck,
omap->xclk60mhsp1_ck);
if (ret != 0)
@@ -726,6 +727,7 @@ static int __devinit usbhs_omap_probe(struct 
platform_device *pdev)
dev_err(dev, "init_60m_fclk set parent"
"failed error:%d\n", ret);
}
+#endif
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
if (!res) {
-- 
1.7.5.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 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver

[Zumeng Chen]

TWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Zumeng Chen 
---
 arch/arm/mach-omap2/board-omap3evm.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 7e5e18f..3806f0e 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -360,6 +360,15 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
 
platform_device_register(&leds_gpio);
 
+   /* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
+* for starting USB tranceiver
+*/
+   if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
+   u8 val;
+   twl_i2c_read_u8(TWL4030_MODULE_GPIO, &val, REG_GPIODATADIR1);
+   val |= 0x04; /* TWL4030.GPIO2DIR BIT at GPIODATADIR1(0x9B) */
+   twl_i2c_write_u8(TWL4030_MODULE_GPIO, val, REG_GPIODATADIR1);
+   }
return 0;
 }
 
-- 
1.7.5.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 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

[Zumeng Chen]

EHCI PHY requires these regulators:
EVM Rev >=E  --> VAUX2
EVM Rev < E  --> VUSB1V5, VUSB1V8

Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.

But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.

Signed-off-by: Ajay Kumar Gupta 
Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Zumeng Chen 
---
 arch/arm/mach-omap2/board-omap3evm.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index fef911d..7e5e18f 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -466,6 +466,30 @@ struct wl12xx_platform_data omap3evm_wlan_data __initdata 
= {
 };
 #endif
 
+/* VAUX2 for USB */
+static struct regulator_consumer_supply omap3evm_vaux2_supplies[] = {
+   REGULATOR_SUPPLY("VDD_CSIPHY1", "omap3isp"),/* OMAP ISP */
+   REGULATOR_SUPPLY("VDD_CSIPHY2", "omap3isp"),/* OMAP ISP */
+   REGULATOR_SUPPLY("hsusb1", "ehci-omap.0"),
+   {
+   .supply = "vaux2",
+   }
+};
+
+static struct regulator_init_data omap3evm_vaux2 = {
+   .constraints = {
+   .min_uV = 280,
+   .max_uV = 280,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(omap3evm_vaux2_supplies),
+   .consumer_supplies  = omap3evm_vaux2_supplies,
+};
+
 static struct twl4030_platform_data omap3evm_twldata = {
/* platform_data for children goes here */
.keypad = &omap3evm_kp_data,
@@ -659,6 +683,9 @@ static void __init omap3_evm_init(void)
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
omap_hsmmc_init(mmc);
 
+   if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
+   omap3evm_twldata.vaux2 = &omap3evm_vaux2;
+
omap3_evm_i2c_init();
 
omap_display_init(&omap3_evm_dss_data);
-- 
1.7.5.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 1/5] ARM: OMAP3EVM: Add NAND flash definition

[Zumeng Chen]

Signed-off-by: Vaibhav Hiremath 
Tested-by: Zumeng Chen 
---
 arch/arm/mach-omap2/board-omap3evm.c |   39 ++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 639bd07..fef911d 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -24,6 +24,10 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -43,6 +47,7 @@
 
 #include 
 #include 
+#include 
 #include "common.h"
 #include 
 #include 
@@ -607,6 +612,37 @@ static struct regulator_consumer_supply dummy_supplies[] = 
{
REGULATOR_SUPPLY("vdd33a", "smsc911x.0"),
 };
 
+static struct mtd_partition omap3evm_nand_partitions[] = {
+   /* All the partition sizes are listed in terms of NAND block size */
+   {
+   .name   = "xloader-nand",
+   .offset = 0,
+   .size   = 4*(SZ_128K),
+   .mask_flags = MTD_WRITEABLE
+   },
+   {
+   .name   = "uboot-nand",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 14*(SZ_128K),
+   .mask_flags = MTD_WRITEABLE
+   },
+   {
+   .name   = "params-nand",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 2*(SZ_128K)
+   },
+   {
+   .name   = "linux-nand",
+   .offset = MTDPART_OFS_APPEND,
+   .size   = 40*(SZ_128K)
+   },
+   {
+   .name   = "jffs2-nand",
+   .size   = MTDPART_SIZ_FULL,
+   .offset = MTDPART_OFS_APPEND,
+   },
+};
+
 static void __init omap3_evm_init(void)
 {
struct omap_board_mux *obm;
@@ -656,6 +692,9 @@ static void __init omap3_evm_init(void)
}
usb_musb_init(&musb_board_data);
usbhs_init(&usbhs_bdata);
+   omap_nand_flash_init(NAND_BUSWIDTH_16, omap3evm_nand_partitions,
+ARRAY_SIZE(omap3evm_nand_partitions));
+
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
omap3_evm_display_init();
-- 
1.7.5.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 0/5] OMAP3530evm misc fixes for linux-omap

[Zumeng Chen]

These patches fix misc problems when reflash ti-omap3530evm for
master branch on Linux-omap. Currently they have been tested on
3530evm but were not ack'ed.

Most of them are the leftovers from the great original developers
with my the latest updates for adapting to the current kernel, so
I add you directly into SOB(If not proper, please let me know).

The series is based upon the latest linux-omap master branch from
Tony (3.5-rc1).

Zumeng Chen (5):
  ARM: OMAP3EVM: Add NAND flash definition
  ARM: OMAP3EVM: Adding USB internal LDOs board file
  ARM: omap3evm: enable VBUS switch for EHCI tranceiver
  MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set
  Input: ads7846: set proper debounce time in driver level

 arch/arm/mach-omap2/board-omap3evm.c |   75 ++
 drivers/input/touchscreen/ads7846.c  |2 +
 drivers/mfd/omap-usb-host.c  |4 +-
 3 files changed, 80 insertions(+), 1 deletions(-)

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

[PATCH] pinctrl: Add one-register-per-pin type device tree based pinctrl driver

[Tony Lindgren]

Add one-register-per-pin type device tree based pinctrl driver.

Currently this driver only works on omap2+ series of processors,
where there is either an 8 or 16-bit padconf register for each pin.
Support for other similar pinmux controllers can be added.

Signed-off-by: Tony Lindgren 

---

Here's this one updated, I renamed it from pinctrl-simple to pinctrl-single
to limit it to one-register-per-mux type MMIO controllers. The bindings
for mapping bits in random registers started looking a bit too complex for
this patch to solve. Hopefully this should also solve the issues of different
expectations of what simple means :)

---
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
new file mode 100644
index 000..21b183e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-omap2plus.txt
@@ -0,0 +1,12 @@
+Pinctrl driver for omap2plus using pinctrl-single driver
+
+Required properties:
+- compatible:  one of:
+   - "ti,omap2420-padconf"
+   - "ti,omap2430-padconf"
+   - "ti,omap3-padconf"
+   - "ti,omap4-padconf"
+
+All omaps starting with omap2 are using pinctrl-single driver for
+the padconf registers. See pinctrl-single.txt in this directory for
+more information.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
new file mode 100644
index 000..6a6abf9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -0,0 +1,102 @@
+One-register-per-pin type device tree based pinctrl driver
+
+Required properties:
+- compatible :  one of:
+   - "pinctrl-single"
+- reg : offset and length of the register set for the mux registers
+- pinctrl-single,register-width : pinmux register access width
+- pinctrl-single,function-mask : mask of allowed pinmux function bits
+- pinctrl-single,function-off : function off mode for disabled state
+- pinctrl-single,pinconf-mask : mask of allowed pinconf bits
+
+This driver uses the common pinctrl bindings as specified in the
+pinctrl-bindings.txt document in this directory.
+
+The pinctrl register offsets and default values are specified as pairs
+using pinctrl-single,pins. For example, setting uart2_rx pin on omap2plus
+can be done with:
+
+   pinctrl-single,pins = <0xdc 0x118>;
+
+Where 0xdc is the offset from the pinctrl ioremapped area for the
+uart2_rx register, and 0x118 contains the desired default value for
+for the pin setting it to INPUT_PULLUP | MODE0. See the uart example and
+static board pins example below for more information.
+
+If you are concerned about the boot time, set up the static pins in
+the bootloader, and only set up selected pins as device tree entries.
+
+This driver assumes that there is only one register for each pin. If you
+have some pins with more complicated configuration, you can set up a separate
+hardware specific driver for those pins.
+
+Note that this driver tries to avoid understanding pin and function
+names because of the extra bloat they would cause especially in the
+omap2plus case. This driver just sets what is specified for the board
+in the .dts file. Further user space debugging tools can be developed
+to decipher the pin and function names using debugfs.
+
+Example:
+
+/* SoC common file, such as omap4.dtsi */
+
+/* first controller instance for pins in core domain */
+omap4_pmx_core: pinmux@4a100040 {
+   compatible = "ti,omap4-padconf";
+   reg = <0x4a100040 0x0196>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-single,register-width = <16>;
+   pinctrl-single,function-mask = <0x7>;
+   pinctrl-single,function-off = <0x>;
+   pinctrl-single,pinconf-mask = <0xfff8>;
+};
+
+/* second controller instance for pins in wkup domain */
+omap4_pmx_wkup: pinmux@4a31e040 {
+   compatible = "ti,omap4-padconf";
+   reg = <0x4a31e040 0x0038>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-single,register-width = <16>;
+   pinctrl-single,function-mask = <0x7>;
+   pinctrl-single,function-off = <0x>;
+   pinctrl-single,pinconf-mask = <0xfff8>;
+};
+
+
+/* board specific .dts file, such as omap4-sdp.dts */
+
+&omap4_pmx_core {
+
+   /*
+* map all board specific static pins enabled by the pinctrl driver
+* itself during the boot (or just set them up in the bootloader)
+*/
+   pinctrl-names = "default";
+   pinctrl-0 = <&board_pins>;
+
+   board_pins: pinmux_board_pins {
+   pinctrl-single,pins = <
+   0x6c 0xf/* csi21_dx3 OUTPUT | MODE7 */
+   0x6e 0xf/* csi21_dy3 OUTPUT | MODE7 */
+   0x70 0xf/* csi21_dx4 OUTPUT | MODE7 */
+   0x72 0xf/* csi21_dy4 OUTPUT | MODE7 */
+   >;
+   };
+
+   /* map uart2 pins */
+   

Re: Current state of AM33xx patches

[Jason Kridner]

From: Daniel Mack 
>Hey,
>
>can anybody give me a quick wrap-up about the current state of AM33xx
>based SoCs in mainline? What are the next steps to get things merged?

There is a wiki page [1] that is intended to provide a summary, but I'm
confident it is not up-to-date.  There is also some automated testing, but
I'm not aware if any of the test results are public and I believe the
coverage is fairly limited.  Hopefully Carlos can chime in with any
information about that.

[1] 
http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x
_Status 


>
>I'm getting involved in a project that is based on a AM3352 and would
>like to provide help where necessary and wanted.

Your help is really appreciated, so thanks in advance.  Hopefully Vaibhav
or Chase can reply with info about any particular subsystems that need
either review or coding.  Conversion to Device Tree is an on-going complex
area where Vaibhav is contributing.

>
>
>Thanks,
>Daniel


--
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 v2] ARM: OMAP2/3: hwmod data: add gpmc

[Afzal Mohammed]

Add gpmc hwmod and associated interconnect data

HWMOD_INIT_NO_RESET can be removed once kernel is updated to
configure GPMC for all peripherals. Currently many depend on
bootloader, this facility will be removed.
(feature-removal-schedule.txt will get updated in upcoming
gpmc series).

No reset is also required for smooth migration to gpmc driver;
approach being taken is to hold old interface until boards are
converted to use driver interface one-by-one. Till that time,
this flag is a must as old interface rely on bootloader

Signed-off-by: Afzal Mohammed 
---

v2: rebased to 3.5-rc1

 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   43 +++-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   53 
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |1 +
 arch/arm/mach-omap2/prcm-common.h  |2 +
 6 files changed, 134 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a7640d1..b672e48 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -529,6 +529,15 @@ static struct omap_hwmod_addr_space 
omap2420_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6800A000,
+   .pa_end = 0x6800AFFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = &omap2xxx_l4_wkup_hwmod,
.slave  = &omap2xxx_counter_32k_hwmod,
@@ -537,6 +546,14 @@ static struct omap_hwmod_ocp_if 
omap2420_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+   .master = &omap2xxx_l3_main_hwmod,
+   .slave  = &omap2xxx_gpmc_hwmod,
+   .clk= "core_l3_ck",
+   .addr   = omap2420_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -580,6 +597,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] 
__initdata = {
&omap2420_l4_core__msdi1,
&omap2420_l4_core__hdq1w,
&omap2420_l4_wkup__counter_32k,
+   &omap2420_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4d72649..c84d0a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -875,6 +875,15 @@ static struct omap_hwmod_addr_space 
omap2430_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6E00,
+   .pa_end = 0x6E000FFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = &omap2xxx_l4_wkup_hwmod,
.slave  = &omap2xxx_counter_32k_hwmod,
@@ -883,6 +892,14 @@ static struct omap_hwmod_ocp_if 
omap2430_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+   .master = &omap2xxx_l3_main_hwmod,
+   .slave  = &omap2xxx_gpmc_hwmod,
+   .clk= "core_l3_ck",
+   .addr   = omap2430_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -933,6 +950,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] 
__initdata = {
&omap2430_l4_core__mcbsp5,
&omap2430_l4_core__hdq1w,
&omap2430_l4_wkup__counter_32k,
+   &omap2430_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 83eafd9..339fbad 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -176,6 +176,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
 };
 
 /*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_F

[PATCH] ARM: OMAP2+: cpu: Make cpu_class_is_omap2 true for all non-omap1 platforms

[Vaibhav Hiremath]

As omap1 and omap2 will never be compiled together, due to
different compiler flags, so we can simply make
cpu_class_is_omap2() = true, for all non-omap1 platforms.

Signed-off-by: Vaibhav Hiremath 
---
 arch/arm/plat-omap/include/plat/cpu.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 14f050f..6a42558 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -374,8 +374,7 @@ IS_OMAP_TYPE(3430, 0x3430)
 /* Macros to detect if we have OMAP1 or OMAP2 */
 #define cpu_class_is_omap1()   (cpu_is_omap7xx() || cpu_is_omap15xx() || \
cpu_is_omap16xx())
-#define cpu_class_is_omap2()   (cpu_is_omap24xx() || cpu_is_omap34xx() || \
-   cpu_is_omap44xx())
+#define cpu_class_is_omap2()   !cpu_class_is_omap1()
 
 /* Various silicon revisions for omap2 */
 #define OMAP242X_CLASS 0x24200024
-- 
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

Re: [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init

[Cousson, Benoit]

On 6/11/2012 2:46 AM, Paul Walmsley wrote:

Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

It appears that the McPDM on OMAP4 can only receive its functional
clock from an off-chip source.  This source is not guaranteed to be
present on the board, and when present, it is controlled by I2C.  This
would introduce a board dependency to the early hwmod code which it
was not designed to handle.  Also, neither the driver for this
off-chip clock provider nor the I2C code is available early in boot
when the hwmod code is attempting to enable and reset IP blocks.  This
effectively makes it impossible to enable and reset this device during
hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.


And I guess, that's a good reason as well to let the driver managing the 
reset during the probe for such IPs.



This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.

Signed-off-by: Paul Walmsley 
Cc: Péter Ujfalusi 
Cc: Benoît Cousson 
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   12 
  1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 3613054..86fc513 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2091,6 +2091,18 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name   = "mcpdm",
.class  = &omap44xx_mcpdm_hwmod_class,
.clkdm_name = "abe_clkdm",
+   /*
+* It's suspected that the McPDM requires an off-chip main
+* functional clock, controlled via I2C.


Nit: Is it not suspected, it is a fact. The clock tree clearly indicate 
that the mcpdm fclk is generated from the pad_clks.
The IP is a custom link for the Audio IC control / data. using the Audio 
IC as a source clock is standard. Since that IP is done only for that 
purpose, there is no optional clock path from the PRCM like it is the 
case for the McASP / McBSP.



 This IP block is
+* currently reset very early during boot, before I2C is
+* available, so it doesn't seem that we have any choice in
+* the kernel other than to avoid resetting it.  XXX This is
+* really a hardware issue workaround: every IP block should
+* be able to source its main functional clock from either
+* on-chip or off-chip sources.  McPDM seems to be the only
+* current exception.


I do not think this is the right place to put some complaint about the 
HW :-).

I guess we should just describe the facts.


+*/
+   .flags  = HWMOD_EXT_OPT_MAIN_CLK,


Could you please update the hints for this IP in the autogen scripts?
I added a comment attribute to add a custom comment on top of the flags 
entry.

The latest branch is "omap5430_for_3.6".

Thanks,
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: RFC: changing DMA slave configuration API

[Dong Aisheng]

On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote:
> On Sun, 2012-06-10 at 12:22 +0100, Russell King - ARM Linux wrote:
> > On Sun, Jun 10, 2012 at 07:19:47PM +0800, Barry Song wrote:
> > > 2012/6/10 Russell King - ARM Linux :
> > > > Dan, Vinod,
> > > >
> > > > There's a change I would like to do to the DMA slave configuration.
> > > > It's currently a pain to have the source and destination parameters in
> > > > the dma_slave_config structure as separate elements; it means when you
> > > > want to extract them, you end up with code in DMA engine drivers like:
> > > >
> > > > +   if (dir == DMA_DEV_TO_MEM) {
> > > > +   dev_addr = c->src_addr;
> > > > +   dev_width = c->src_addr_width;
> > > > +   burst = c->src_maxburst;
> > > > +   } else if (dir == DMA_MEM_TO_DEV) {
> > > > +   dev_addr = c->dst_addr;
> > > > +   dev_width = c->dst_addr_width;
> > > > +   burst = c->dst_maxburst;
> > > > +   }
> > > >
> > > > If we redefine the structure as below, this all becomes more simple:
> > > >
> > > > +   if (dir == DMA_DEV_TO_MEM)
> > > > +   cfg = &c->dev_src;
> > > > +   else if (dir == DMA_MEM_TO_DEV)
> > > > +   cfg = &c->dev_dst;
> > > 
> > > it seems that might mean an union in your dma_slave_cfg, but not
> > > co-exitense of both?
> > 
> > No, I want both so it's possible to select between the two when preparing
> > a DMA slave transfer.
> > 
> > > struct dma_slave_cfg {
> > > +   union {
> > >   struct dma_dev_cfg dev_src;
> > >   struct dma_dev_cfg dev_dst;
> > >}
> > >bool device_fc;
> > > };
> > 
> > If you do that, the union becomes pointless, and you might as well have:
> > 
> > struct dma_slave_cfg {
> > struct dma_dev_cfg dev;
> > bool device_fc;
> > };
> > 
> > instead.
> Hi Russell,
> 
> I think it is a good idea. And I would like to extend it even a little
> bit. Do we have any users of peripheral to peripheral slave dma?
Yes, IMX sdma does support such kind of transfer.
The driver still does not support it currently.

> IIRC  that is not the case, or does anyone know of existence or plans
> for such a h/w?
> 
i.MX5 and i.MX6.

> If not, lets junk the src/dst fields and keep burst, length, addr fields
> which point to the peripheral values.
> 
> Alternatively if we need both, then we can't have union and Russell's
> idea seems good one :)
> 
Russell's idea seems reasonable and we may want to support peripheral to
peripheral in the future.

Regards
Dong Aisheng

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

Re: [PATCHv2 04/12] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes

[Cousson, Benoit]

On 6/11/2012 2:46 AM, Paul Walmsley wrote:

The 32k sync timer IP block target idle modes are incorrect in the
hwmod data are incorrect.


Nit: Is there too many "incorrect" in this sentence?


The IP block does not support any
smart-idle modes.  Update the data to reflect the correct modes.

This problem was initially identified and a diff fragment posted to
the lists by Benoît Cousson .


Thanks for taking care of that patch.

Benoit



Signed-off-by: Paul Walmsley 
Cc: Benoît Cousson 
Cc: Tero Kristo 
---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 484..6b0aedc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -393,8 +393,7 @@ static struct omap_hwmod_class_sysconfig 
omap44xx_counter_sysc = {
.rev_offs   = 0x,
.sysc_offs  = 0x0004,
.sysc_flags = SYSC_HAS_SIDLEMODE,
-   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-  SIDLE_SMART_WKUP),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO),
.sysc_fields= &omap_hwmod_sysc_type1,
  };






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

Current state of AM33xx patches

[Daniel Mack]

Hey,

can anybody give me a quick wrap-up about the current state of AM33xx
based SoCs in mainline? What are the next steps to get things merged?

I'm getting involved in a project that is based on a AM3352 and would
like to provide help where necessary and wanted.


Thanks,
Daniel
--
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