Re: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3

[Ramirez Luna, Omar]

On Tue, Nov 9, 2010 at 5:38 PM, Kevin Hilman
 wrote:
>> ---
>>  arch/arm/mach-omap2/devices.c              |  100 
>> ---
>>  arch/arm/mach-omap2/mailbox.c              |    1 +
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 +++
>
> please separate out the addition of hwmod_data into it's own patch that
> comes before this.  As mentioned by Charu, all the hwmod data could be
> added early in the series, before this conversion is done.

Yes, this was changed in v2 [1], thanks for your comments, they will
be addressed in the next version.

Regards,

Omar

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

Re: [PATCH 3/5] omap: mailbox: add omap_device latency information

[Ramirez Luna, Omar]

On Tue, Nov 9, 2010 at 5:48 PM, Kevin Hilman
 wrote:
>>  #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
>> +static struct omap_device_pm_latency mbox_latencies[] = {
>> +     [0] = {
>> +             .activate_func = omap_device_enable_clocks,
>> +             .activate_lat = 5, /* FIXME random value */
>> +             .deactivate_func = omap_device_enable_clocks,
>> +             .deactivate_lat = 5, /* FIXME random value */
>> +     },
>> +};
>
> hmm, I'm hoping you're not expecting this to merge when using random values.

This was changed on the second iteration of the patch [1], and is
still a WIP as some more comments have been made. I'll keep your
current comments though.

Regards,

Omar

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

Re: [PATCH 3/5] omap: mailbox: add omap_device latency information

[Felipe Contreras]

On Wed, Nov 10, 2010 at 1:48 AM, Kevin Hilman
 wrote:
>>  #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
>> +static struct omap_device_pm_latency mbox_latencies[] = {
>> +     [0] = {
>> +             .activate_func = omap_device_enable_clocks,
>> +             .activate_lat = 5, /* FIXME random value */
>> +             .deactivate_func = omap_device_enable_clocks,
>> +             .deactivate_lat = 5, /* FIXME random value */
>> +     },
>> +};
>
> hmm, I'm hoping you're not expecting this to merge when using random values.

No, I was hoping you would comment in the RFC I sent clearly
mentioning this was an experiment 6 months ago:
http://thread.gmane.org/gmane.linux.ports.arm.omap/36745

AFAICR this was one of the first patches for hwmod, so there was not
much reference. I did see more proper ways to set those latencies
after sending that patch (automatic calculation IIRC), but I didn't
manage to work on that code again. There are more important things to
do, like getting the only user of the mailbox to actually work.

>> --- a/arch/arm/mach-omap2/mailbox.c
>> +++ b/arch/arm/mach-omap2/mailbox.c
>> @@ -53,6 +53,7 @@
>>  #define OMAP4_MBOX_NR_REGS           (OMAP4_MBOX_REG_SIZE / sizeof(u32))
>>
>>  static void __iomem *mbox_base;
>> +static struct platform_device *mbox_pdev;

>> +     mbox_pdev = pdev;
>
> please don't use a global for this.  What if a future SoC has more than
> one mailbox?
>
> How about adding a field to struct omap_mbox?

If you see above, there can be only one (mbox_base is already global).
So support for multiple mailboxes would be the subject of a separate
patch.

Cheers.

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

Re: [PATCH v2] OMAP4: Extend clock database.

[Kevin Hilman]

Thara Gopinath  writes:

> This patch extends the OMAP4 clock data to include
> various x2 clock nodes as the clock framework
> skips a *2 whie calculating the dpll locked frequency.
>
> The clock databse extensions are autogenerated using
> the scripts maintained by Benoit Cousson.
>
> Signed-off-by: Benoit Cousson 
> Signed-off-by: Thara Gopinath 

The subject could be a bit more descriptive here, something like:

OMAP4: clock: add various DPLL x2 clock nodes

or something similar.

Thanks,

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

Re: [PATCH 3/5] omap: mailbox: add omap_device latency information

[Kevin Hilman]

Omar Ramirez Luna  writes:

> From: Felipe Contreras 
>
> So that we can enable the main clock.

-ENO_DESCRIPTIVE_CHANGELOG

omap_device_enable/disable do more than just manage the clocks

> Signed-off-by: Felipe Contreras 
> Signed-off-by: Omar Ramirez Luna 
> ---
>  arch/arm/mach-omap2/devices.c |   19 +--
>  arch/arm/mach-omap2/mailbox.c |   21 +
>  arch/arm/plat-omap/include/plat/mailbox.h |6 ++
>  3 files changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index d977572..337fd7a 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mux.h"
>  #include "control.h"
> @@ -141,10 +142,20 @@ static inline void omap_init_camera(void)
>  #endif
>  
>  #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
> +static struct omap_device_pm_latency mbox_latencies[] = {
> + [0] = {
> + .activate_func = omap_device_enable_clocks,
> + .activate_lat = 5, /* FIXME random value */
> + .deactivate_func = omap_device_enable_clocks,
> + .deactivate_lat = 5, /* FIXME random value */
> + },
> +};

hmm, I'm hoping you're not expecting this to merge when using random values.

>  static inline void omap_init_mbox(void)
>  {
>   struct omap_hwmod *oh;
>   struct omap_device *od;
> + struct omap_mbox_platform_data pdata;
>  
>   oh = omap_hwmod_lookup("mailbox");
>   if (!oh) {
> @@ -152,10 +163,14 @@ static inline void omap_init_mbox(void)
>   return;
>   }
>  
> + pdata.device_enable = omap_device_enable;
> + pdata.device_disable = omap_device_idle;

If the driver want's to use the hooks, just use the runtime PM API.
More on this below.

>   od = omap_device_build("omap-mailbox", -1, oh,
> - NULL, 0,
> - NULL, 0,
> + &pdata, sizeof(pdata),
> + mbox_latencies, ARRAY_SIZE(mbox_latencies),
>   0);
> +
>   if (!od) {
>   pr_err("%s: could not build device\n", __func__);
>   return;
> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
> index 1ddb82d..61f2149 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -53,6 +53,7 @@
>  #define OMAP4_MBOX_NR_REGS   (OMAP4_MBOX_REG_SIZE / sizeof(u32))
>  
>  static void __iomem *mbox_base;
> +static struct platform_device *mbox_pdev;
>
>  struct omap_mbox2_fifo {
>   unsigned long msg;
> @@ -71,8 +72,6 @@ struct omap_mbox2_priv {
>   unsigned long irqdisable;
>  };
>  
> -static struct clk *mbox_ick_handle;
> -
>  static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
> omap_mbox_type_t irq);
>  
> @@ -91,14 +90,10 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
>  {
>   u32 l;
>   unsigned long timeout;
> + struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
>  
> - mbox_ick_handle = clk_get(NULL, "mailboxes_ick");
> - if (IS_ERR(mbox_ick_handle)) {
> - printk(KERN_ERR "Could not get mailboxes_ick: %ld\n",
> - PTR_ERR(mbox_ick_handle));
> - return PTR_ERR(mbox_ick_handle);
> - }
> - clk_enable(mbox_ick_handle);
> + if (pdata->device_enable)
> + pdata->device_enable(mbox_pdev);

pm_runtime_get_sync(dev)

>   if (cpu_is_omap44xx()) {
>   mbox_write_reg(OMAP4_SOFTRESET, MAILBOX_SYSCONFIG);
> @@ -144,9 +139,9 @@ static int omap2_mbox_startup(struct omap_mbox *mbox)
>  
>  static void omap2_mbox_shutdown(struct omap_mbox *mbox)
>  {
> - clk_disable(mbox_ick_handle);
> - clk_put(mbox_ick_handle);
> - mbox_ick_handle = NULL;
> + struct omap_mbox_platform_data *pdata = mbox_pdev->dev.platform_data;
> + if (pdata->device_disable)
> + pdata->device_disable(mbox_pdev);

pm_runtime_put(dev)

>  }
>  
>  /* Mailbox FIFO handle functions */
> @@ -428,6 +423,8 @@ static int __devinit omap2_mbox_probe(struct 
> platform_device *pdev)
>   if (!mbox_base)
>   return -ENOMEM;
>  
> + mbox_pdev = pdev;

please don't use a global for this.  What if a future SoC has more than
one mailbox?

How about adding a field to struct omap_mbox?

>   ret = omap_mbox_register(&pdev->dev, list);
>   if (ret) {
>   iounmap(mbox_base);
> diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
> b/arch/arm/plat-omap/include/plat/mailbox.h
> index 9976565..59443b1 100644
> --- a/arch/arm/plat-omap/include/plat/mailbox.h
> +++ b/arch/arm/plat-omap/include/plat/mailbox.h
> @@ -11,6 +11,7 @@
>  
>  typedef u32 mbox_msg_t;
>  struct omap_mbox;
> +struct platform_device;
>  
>  typedef int __bit

Re: [PATCH 1/5] omap: mailbox: initial hwmod support for omap3

[Kevin Hilman]

Omar Ramirez Luna  writes:

> From: Felipe Contreras 
>
> HWMOD support for omap3.

-ENO_DESCRIPTIVE_CHANGELOG

Please describe in more detail what is happening here, starting with a
better subject:

   omap: mailbox: build device using omap_device/omap_hwmod

and the changelog should describe that what is being changed is that 
there is no longer a need for static platform_device and resources since
all of this data is contained in the omap_hwmod for the mailbox.


> Signed-off-by: Felipe Contreras 
> Signed-off-by: Omar Ramirez Luna 
> ---
>  arch/arm/mach-omap2/devices.c  |  100 ---
>  arch/arm/mach-omap2/mailbox.c  |1 +
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 +++

please separate out the addition of hwmod_data into it's own patch that
comes before this.  As mentioned by Charu, all the hwmod data could be
added early in the series, before this conversion is done.

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

Re: [PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Convert DMA library into DMA platform driver and make use
> of platform data provided by HWMOD data base for OMAP2PLUS onwards.
> For OMAP1 processors, the DMA driver in mach-omap uses resource
> structures for getting platform data.
>
> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/mach-omap1/Makefile   |2 +-
>  arch/arm/mach-omap1/dma.c  |  180 ++-
>  arch/arm/mach-omap2/Makefile   |2 +-
>  arch/arm/mach-omap2/dma.c  |  209 +-
>  arch/arm/mach-omap2/include/mach/dma.h |3 +
>  arch/arm/plat-omap/dma.c   |  321 
> +++-
>  arch/arm/plat-omap/include/plat/dma.h  |   50 --
>  7 files changed, 538 insertions(+), 229 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> index 9a304d8..b7dfc54 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -3,7 +3,7 @@
>  #
>  
>  # Common support
> -obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
> +obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
>  obj-y += clock.o clock_data.o opp_data.o
>  
>  obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index e756069..38a7294 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -35,6 +35,81 @@
>  #include 
>  
>  #define OMAP1_DMA_BASE   (0xfffed800)
> +#define OMAP1_LOGICAL_DMA_CH_COUNT   17
> +
> +static u32 errata;
> +static u32 enable_1510_mode;
> +
> +enum {
> + GCR1 = 0,   GSCR,   GRST,   HW_ID,
> + PCH2_ID,PCH0_ID,PCH1_ID,PCHG_ID,
> + PCHD_ID,CAPS_0_U,   CAPS_0_L,   CAPS_1_U,
> + CAPS_1_L,   CAPS_2, CAPS_3, CAPS_4,
> + PCH2_SR,PCH0_SR,PCH1_SR,PCHD_SR,
> +
> + CH_COMMON_START,
> +
> + /* Common Registers */
> + CSDP1,  CCR1,   CICR1,  CSR1,
> + CEN1,   CFN1,   CSFI1,  CSEI1,
> + CPC,CSAC1,  CDAC1,  CDEI1,
> + CDFI1,  CLNK_CTRL1,
> +
> + /* Channel specific register offsets */
> + CSSA_L, CSSA_U, CDSA_L, CDSA_U,
> + COLOR_L,COLOR_U,CCR1_2, LCH_CTRL,
> +
> + CH_COMMON_END,
> +};

These reg_map enums are added here, then promptly moved in the following
patch.  Please just put them in the right place earlier in the series.
Also, at this point, similar versions also still exist in
plat-omap/dma.c

This may be a good technique for inflating the number of lines changed
in the git history, but it is not review friendly.

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

Re: [PATCH v3 04/13] OMAP2420: DMA: hwmod: add system DMA

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Add OMAP2420 DMA hwmod structures.

s/structures/data/

Also, as pointed out in many other hwmod reviews, when adding hwmod
data, subject should be something like: 

  OMAP2420: hwmod_data: add system DMA

Kevin


> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c |   85 
> 
>  1 files changed, 85 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index a1a3dd6..3a51392 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -38,6 +38,7 @@ static struct omap_hwmod omap2420_iva_hwmod;
>  static struct omap_hwmod omap2420_l3_main_hwmod;
>  static struct omap_hwmod omap2420_l4_core_hwmod;
>  static struct omap_hwmod omap2420_wd_timer2_hwmod;
> +static struct omap_hwmod omap2420_dma_system_hwmod;
>  
>  /* L3 -> L4_CORE interface */
>  static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
> @@ -557,6 +558,89 @@ static struct omap_hwmod omap2420_i2c2_hwmod = {
>   .flags  = HWMOD_16BIT_REG,
>  };
>  
> +/* system dma */
> +static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
> + .rev_offs   = 0x,
> + .sysc_offs  = 0x002c,
> + .syss_offs  = 0x0028,
> + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> +SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
> +SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
> + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
> + .sysc_fields= &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap2420_dma_hwmod_class = {
> + .name = "dma",
> + .sysc = &omap2420_dma_sysc,
> +};
> +
> +/* dma attributes */
> +static struct omap_dma_dev_attr dma_dev_attr = {
> + .dev_caps  = DMA_LINKED_LCH | GLOBAL_PRIORITY |
> + IS_CSSA_32 | IS_CDSA_32,
> + .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
> +};
> +
> +static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
> + { .name = "0", .irq = INT_24XX_SDMA_IRQ0 },
> + { .name = "1", .irq = INT_24XX_SDMA_IRQ1 },
> + { .name = "2", .irq = INT_24XX_SDMA_IRQ2 },
> + { .name = "3", .irq = INT_24XX_SDMA_IRQ3 },
> +};
> +
> +static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
> + {
> + .pa_start   = 0x48056000,
> + .pa_end = 0x4a0560ff,
> + .flags  = ADDR_TYPE_RT
> + },
> +};
> +
> +/* dma_system -> L3 */
> +static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
> + .master = &omap2420_dma_system_hwmod,
> + .slave  = &omap2420_l3_main_hwmod,
> + .clk= "l3_div_ck",
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* dma_system master ports */
> +static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
> + &omap2420_dma_system__l3,
> +};
> +
> +/* l4_cfg -> dma_system */
> +static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
> + .master = &omap2420_l4_core_hwmod,
> + .slave  = &omap2420_dma_system_hwmod,
> + .clk= "l4_div_ck",
> + .addr   = omap2420_dma_system_addrs,
> + .addr_cnt   = ARRAY_SIZE(omap2420_dma_system_addrs),
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +/* dma_system slave ports */
> +static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
> + &omap2420_l4_core__dma_system,
> +};
> +
> +static struct omap_hwmod omap2420_dma_system_hwmod = {
> + .name   = "dma",
> + .class  = &omap2420_dma_hwmod_class,
> + .mpu_irqs   = omap2420_dma_system_irqs,
> + .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_dma_system_irqs),
> + .main_clk   = "l3_div_ck",
> + .slaves = omap2420_dma_system_slaves,
> + .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
> + .masters= omap2420_dma_system_masters,
> + .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
> + .dev_attr   = &dma_dev_attr,
> + .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
> + .flags  = HWMOD_NO_IDLEST,
> +};
> +
>  static __initdata struct omap_hwmod *omap2420_hwmods[] = {
>   &omap2420_l3_main_hwmod,
>   &omap2420_l4_core_hwmod,
> @@ -569,6 +653,7 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
>   &omap2420_uart3_hwmod,
>   &omap2420_i2c1_hwmod,
>   &omap2420_i2c2_hwmod,
> + &omap2420_dma_system_hwmod,
>   NULL,
>  };
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.ker

Re: [PATCH v3 00/13] OMAP: DMA: hwmod and DMA as platform device

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> This patch series converts DMA library into platform device and hwmod 
> adaptation is done for omap2+ processors.
>
> It also replaces cpu_*is* checks by moving omap1 and omap2+ processor 
> code into repsective mach-omapx directories. The common code in plat-omap
> will use device attributes for differentiating omap1 and omap2 code.

This summary, and the various changelogs need to be updated to be more
descriptive, particularily in the usage of the words 'device' and
'driver'.

The changelog terminology used is confusing, and sometimes wrong.  What
is actually being done is splitting up the current DMA library into 3
parts: a common platform_driver (plat-omap/dma.c), OMAP1 device code
(mach-omap1/dma.c) and OMAP2+ device code (mach-omap2/dma.c)

> Build Report:
> omap1:  Success for omap_h2_1610_defconfig
> omap2+: Success for omap2plus_defconfig
>
> Test Report:
> omap2+:(multiboot defconfig boots on all the omap2+ boards listed below):
> OMAP4BLAZE: http://pastebin.com/HVnim30G
> OMAP3630ZOOM3: http://pastebin.com/JJwrtP4F
> OMAP243SDP: http://pastebin.com/mz7cVQL3
>
> omap1 : Not tested 
>
> Test cases executed:
> 1. All applicable TI DMA tests which are located at:
> http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=dma/test_code;h=0d00de3c0fe6933b405c62da63f694883f3e4b8f;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253
>
> 2. Use case tests :  TI MMC tests are executed with differenct types of
> files systems such as DOS, ext2, ext3 etc on omap4 blaze and omap3630 zoom3. 
> More information can be found at:
> http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=tree;f=mmc/test_code;h=d0bc1984eef46ac45719efb02b5c1f4193422a1b;hb=2c50a5a58dea0ffc2d31b827935aeef9b9d11253
>
> Dependencies:
> This patch series has dependency on omap_device patch:
> https://patchwork.kernel.org/patch/282212/

Thanks for the thorough build and test report.   Very nice.

Kevin

> This patch series applies on:
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> Branch: master
> commit a83d12a47c9a8c78a184910150797045d69a1570
> Merge: f9f47f5 c1fb8df
> Author: Tony Lindgren 
> Date:   Fri Oct 22 11:21:08 2010 -0700
>
> Linux-omap rebuilt: Updated to v2.6.36, add 24xx uart fix
>
> Changelist summary:
> v3:
> Review comments fixed:
> http://www.listware.net/201008/linux-omap/89002-patch-v2-0011-omap-dma-hwmod-and-dma-as-platform-driver.html
>  - created and tested on latest linux-omap master branch(2.6.36 kernel)
>
> v2:
> The review comments which are fixed can be found at:
> http://www.spinics.net/lists/linux-omap/msg34291.html
> http://www.spinics.net/lists/linux-omap/msg34292.html
> http://www.spinics.net/lists/linux-omap/msg34078.html
> http://www.spinics.net/lists/linux-omap/msg34083.html
>
> v1:
> These changes are based on comments received during internal discussions 
> which has changes(compared to previous version) such as:
>  - Code optimization
>  - Patches are rearranged in more meaningful way so that git bisect works at 
> any
>intermediate patch in the series.
>  - Build tested for all omap's(OMAP1 and OMAP2PLUS)
>  - Boot tested for OMAP3 and OMAP4(appreciate if some one tests on OMAP1/2)
>  - Applicalbe tests are executed on OMAP3 and OMAP4 boards
>  - Rebased and added descriptor autoloading feature(only for omap3630 and 
> omap4)
>
>
> Benoit Cousson (1):
>   OMAP4: DMA: hwmod: add system DMA
>
> G, Manjunath Kondaiah (12):
>   OMAP: DMA: Replace read/write macros with functions
>   OMAP: DMA: Introduce errata handling feature
>   OMAP: DMA: Introduce DMA device attributes
>   OMAP2420: DMA: hwmod: add system DMA
>   OMAP2430: DMA: hwmod: add system DMA
>   OMAP3: DMA: hwmod: add system DMA
>   OMAP1: DMA: Introduce DMA driver as platform device
>   OMAP2+: DMA: hwmod: Device registration
>   OMAP: DMA: Convert DMA library into DMA platform Driver
>   OMAP: DMA: Use DMA device attributes
>   sDMA: descriptor autoloading feature
>   OMAP: PM: DMA: Enable runtime pm
>
>  arch/arm/mach-omap1/Makefile   |2 +-
>  arch/arm/mach-omap1/dma.c  |  665 ++
>  arch/arm/mach-omap1/include/mach/dma.h |   51 +
>  arch/arm/mach-omap2/Makefile   |2 +-
>  arch/arm/mach-omap2/dma.c  | 1579 
>  arch/arm/mach-omap2/include/mach/dma.h |   86 ++
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c |   85 ++
>  arch/arm/mach-omap2/omap_hwmod_2430_data.c |   85 ++
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   93 ++
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   99 ++
>  arch/arm/plat-omap/dma.c   | 1850 
> 
>  arch/arm/plat-omap/include/plat/dma.h  |  387 ---
>  12 files changed, 3207 insertions(+), 1777 deletions(-)
>  create mode 100644 arch/arm/mach-omap1/dma.c
>  create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
>  create mode 100644 arch/arm/mach-omap2/dma.c
>  create mode 100644 arch/a

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Greg KH]

On Wed, Nov 10, 2010 at 12:39:47AM +0200, Felipe Contreras wrote:
> On Wed, Nov 10, 2010 at 12:10 AM, Greg KH  wrote:
> > On Tue, Nov 09, 2010 at 11:53:29PM +0200, Felipe Contreras wrote:
> >> You mean after this pull, or should Omar re-send this pull request?
> >
> > I'm not pulling _anything_ at the moment for this driver.
> >
> > I want to see patches, not a pull request please, as these need to be
> > reviewed very closely.
> 
> It's a revert from a non-working state to a working state, there's not
> much to review there. So if Omar sends the patches with my and his
> s-o-b, would you apply the patches?

Was my previous email about not taking anything unless it went through
Omar not specific enough?

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

Re: [PATCH v3 13/13] OMAP: PM: DMA: Enable runtime pm

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Enable runtime pm and use pm_runtime_get and pm_runtime_put
> for OMAP DMA driver.
>
> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/plat-omap/dma.c |   13 +
>  1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 41b14b0..feac7ee 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -367,6 +368,8 @@ int omap_request_dma(int dev_id, const char *dev_name,
>   chan = dma_chan + free_ch;
>   chan->dev_id = dev_id;
>  
> + pm_runtime_get(&pd->dev);

The _get() call is asynchronous.  So if the device was actually
idled/disabled, immediately after this call it may still be
idle/disabled.   When using the asynchronous versions of the API, the
device should not be touched until the driver's ->runtime_resume()
callback is called.

>   if (d->dev_caps & IS_WORD_16)
>   p->clear_lch_regs(free_ch);
>   else
> @@ -452,6 +455,7 @@ void omap_free_dma(int lch)
>   omap_clear_dma(lch);
>   p->clear_dma_sglist_mode(lch);
>   }
> + pm_runtime_put(&pd->dev);
>   spin_lock_irqsave(&dma_chan_lock, flags);
>   dma_chan[lch].dev_id = -1;
>   dma_chan[lch].next_lch = -1;
> @@ -819,6 +823,11 @@ static int __devinit omap_system_dma_probe(struct 
> platform_device *pdev)
>   dma_chan_count  = d->chan_count;
>   dma_chan= d->chan;
>  
> + /* Enable run time PM */

comment is redundant

> + pm_runtime_enable(&pd->dev);
> +
> + /* Accessing hw registers, get clock */

comment is wrong, driver doesn't know anything about clocks.
Just drop comment as it doesn't tell you anything that the following
'get' doesn't.

> + pm_runtime_get(&pd->dev);

see above Re: async calls.

>   for (ch = 0; ch < dma_chan_count; ch++) {
>   unsigned long flags;
>   omap_clear_dma(ch);
> @@ -846,6 +855,10 @@ static int __devinit omap_system_dma_probe(struct 
> platform_device *pdev)
>   dma_chan[0].dev_id = 0;
>   dma_chan[1].dev_id = 1;
>   }
> +
> + if (!omap_dma_reserve_channels)
> + pm_runtime_put(&pd->dev);
> +

So if the reserve channels feature is used, PM is essentially disabled
for sDMA.  You should add a warning here to that effect as well.


>   return 0;
>  
>  exit_release_region:

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Felipe Contreras]

On Wed, Nov 10, 2010 at 12:10 AM, Greg KH  wrote:
> On Tue, Nov 09, 2010 at 11:53:29PM +0200, Felipe Contreras wrote:
>> You mean after this pull, or should Omar re-send this pull request?
>
> I'm not pulling _anything_ at the moment for this driver.
>
> I want to see patches, not a pull request please, as these need to be
> reviewed very closely.

It's a revert from a non-working state to a working state, there's not
much to review there. So if Omar sends the patches with my and his
s-o-b, would you apply the patches?

Getting these patches in one way or the other seems to be the only way
we can get this driver to work on 2.6.37.

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

Re: [PATCH v3 10/13] OMAP: DMA: Convert DMA library into DMA platform Driver

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Convert DMA library into DMA platform driver and make use
> of platform data provided by HWMOD data base for OMAP2PLUS onwards.
> For OMAP1 processors, the DMA driver in mach-omap uses resource
> structures for getting platform data.
>
> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 

[...]

> diff --git a/arch/arm/mach-omap2/include/mach/dma.h 
> b/arch/arm/mach-omap2/include/mach/dma.h
> index d0a7d5b..d13c5c0 100644
> --- a/arch/arm/mach-omap2/include/mach/dma.h
> +++ b/arch/arm/mach-omap2/include/mach/dma.h
> @@ -29,4 +29,7 @@
>  #ifndef __ASM_ARCH_OMAP2_DMA_H
>  #define __ASM_ARCH_OMAP2_DMA_H
>  
> +/* Should be part of hwmod data base ? */
> +#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT   32  /* REVISIT: Is this 32 
> + 2? */
> +

There are no users of this in this patch, all users are removed.

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

Re: [PATCH v3 08/13] OMAP1: DMA: Introduce DMA driver as platform device

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Register OMAP1 DMA driver as platform device and add support
> for registering through platform device layer using resource
> structures.
>
> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/mach-omap1/dma.c  |  182 
> 
>  arch/arm/mach-omap1/include/mach/dma.h |   29 +
>  2 files changed, 211 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-omap1/dma.c
>  create mode 100644 arch/arm/mach-omap1/include/mach/dma.h
>
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> new file mode 100644
> index 000..e756069
> --- /dev/null
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -0,0 +1,182 @@
> +/*
> + * dma.c - OMAP1/OMAP7xx-specific DMA code
> + *
> + * Copyright (C) 2003 - 2008 Nokia Corporation
> + * Author: Juha Yrjölä 
> + * DMA channel linking for 1610 by Samuel Ortiz 
> + * Graphics DMA and LCD DMA graphics tranformations
> + * by Imre Deak 
> + * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
> + * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, 
> Inc.
> + *
> + * Copyright (C) 2010 Texas Instruments, Inc.
> + * Converted DMA library into platform driver
> + *   - G, Manjunath Kondaiah 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 

no pm_runtime API usage in this patch.Please add only when needed.

> +#include 
> +#include 
> +#include 
> +#include 

why is sched.h needed?

> +#include 

ditto

> +#include 
> +#include 
> +#include 
> +#include 

When creating a new file like this, it's important to only include
headers that are actually used/needed.

> +#include 
> +#include 
> +
> +#define OMAP1_DMA_BASE   (0xfffed800)
> +
> +static struct resource res[] __initdata = {
> + [0] = {
> + .start  = OMAP1_DMA_BASE,
> + .end= OMAP1_DMA_BASE + SZ_2K - 1,
> + .flags  = IORESOURCE_MEM,
> + },
> + [1] = {
> + .name   = "0",
> + .start  = INT_DMA_CH0_6,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [2] = {
> + .name   = "1",
> + .start  = INT_DMA_CH1_7,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [3] = {
> + .name   = "2",
> + .start  = INT_DMA_CH2_8,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [4] = {
> + .name   = "3",
> + .start  = INT_DMA_CH3,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [5] = {
> + .name   = "4",
> + .start  = INT_DMA_CH4,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [6] = {
> + .name   = "5",
> + .start  = INT_DMA_CH5,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [7] = {
> + .name   = "6",
> + .start  = INT_DMA_LCD,
> + .flags  = IORESOURCE_IRQ,
> + },
> + /* irq's for omap16xx and omap7xx */
> + [8] = {
> + .name   = "7",
> + .start  = 53 + IH2_BASE,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [9] = {
> + .name   = "8",
> + .start  = 54 + IH2_BASE,
> + .flags  = IORESOURCE_IRQ,
> + },
> + [10] = {
> + .name  = "9",
> + .start = 55 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [11] = {
> + .name  = "10",
> + .start = 56 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [12] = {
> + .name  = "11",
> + .start = 57 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [13] = {
> + .name  = "12",
> + .start = 58 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [14] = {
> + .name  = "13",
> + .start = 59 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [15] = {
> + .name  = "14",
> + .start = 60 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [16] = {
> + .name  = "15",
> + .start = 61 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> + [17] = {
> + .name  = "16",
> + .start = 62 + IH2_BASE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static int __init omap1_system_dma_init(void)
> +{
> + struct omap_system_dma_plat_info*p;
> + struct platform_device  *pdev;
> + int ret;
> +
> + pdev = platform_device_alloc("omap_dma_system", 0);
> + if (!pdev) {
> + pr_err("%s: Unable to device alloc for dma\

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Felipe Contreras]

On Tue, Nov 9, 2010 at 8:32 PM, Tony Lindgren  wrote:
> * Guzman Lugo, Fernando  [101109 09:43]:
>> On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren  wrote:
>> > * Guzman Lugo, Fernando  [101109 08:36]:
>> >>
>> >> tidspbridge iommu change are working fine all the patches and few fixes 
>> >> after
>> >> that are alredy sent. what breaks tidspbridge, is the unmerged
>> >> dependencies in linux omap tree, specifically the iommu module patches
>> >> and the SG patch.
>> >
>> > Care to post a series of the missing patches listed above?
>>
>> Here are the missing patches:
>>
>> Fernando Guzman Lugo (4):
>>   iovmm: no gap checking for fixed address
>>   iovmm: add superpages support to fixed da address
>>   iovmm: replace __iounmap with omap_iounmap
>>   iommu: create new api to set valid da range
>
> Yeah this is stuff for Hiroshi to look at and queue for
> 2.6.28. No way we can merge these now.

Right, and he hasn't ack'ed them yet. So there's a chance they don't
get into 2.6.38 either.

>> and
>>   scatterlist: define SG chain for arm architecture
>
> And this we need to test carefully it's not something we
> can just merge.
>
> Has this been tested to work with omap MMC drivers?
>
> I'm not at all convinced the drivers can deal with
> chained SG lists.. This may not show up with light
> testing, the SG lists can be very small in most cases.
>
> So this would have to be tested to make sure the
> the chained SG list handled properly. The same goes
> for other omap drivers that may be using SG.

And the change doesn't affect OMAP only, it's for all ARM platforms.

The proposal from Russell was to do it only on OMAP, but I haven't
seen a patch that does that yet. Hopefully this would go into 2.6.38,
but again, it might not.

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

Re: [PATCH v3 02/13] OMAP: DMA: Introduce errata handling feature

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> Implement errata handling to use flags instead of cpu_is_*
> and cpu_class_* in the code.
>
> The errata flags are initialized at init time and during runtime
> we are using the errata variable (via the IS_DMA_ERRATA macro)
> to execute the required errata workaround.
>
> Reused errata handling patch from Peter Ujfalusi 
> https://patchwork.kernel.org/patch/231191/

When starting from someone else's work, would be very helpful to
reviewers (and original authors) if you summarized what you
changed/fixed/updated etc.

> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Peter Ujfalusi 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/plat-omap/dma.c  |  134 ++--
>  arch/arm/plat-omap/include/plat/dma.h |   11 +++
>  2 files changed, 103 insertions(+), 42 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
> index 77241e2..0ff82d0 100644
> --- a/arch/arm/plat-omap/dma.c
> +++ b/arch/arm/plat-omap/dma.c
> @@ -195,6 +195,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
>  #define OMAP_FUNC_MUX_ARM_BASE   (0xfffe1000 + 0xec)
>  
>  static int enable_1510_mode;
> +static u32 errata;
>  
>  static struct omap_dma_global_context_registers {
>   u32 dma_irqenable_l0;
> @@ -1216,12 +1217,8 @@ void omap_start_dma(int lch)
>  
>   cur_lch = next_lch;
>   } while (next_lch != -1);
> - } else if (cpu_is_omap242x() ||
> - (cpu_is_omap243x() &&  omap_type() <= OMAP2430_REV_ES1_0)) {
> -
> - /* Errata: Need to write lch even if not using chaining */
> + } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
>   dma_write(lch, CLNK_CTRL2, lch);
> - }
>  
>   omap_enable_channel_irq(lch);
>  
> @@ -1231,17 +1228,8 @@ void omap_start_dma(int lch)
>   dma_write(l, CCR1, lch);
>   } else {
>   l = dma_read(CCR2, lch);
> - /*
> -  * Errata: Inter Frame DMA buffering issue (All OMAP2420 and
> -  * OMAP2430ES1.0): DMA will wrongly buffer elements if packing
> -  * and bursting is enabled. This might result in data gets
> -  * stalled in FIFO at the end of the block.
> -  * Workaround: DMA channels must have BUFFERING_DISABLED bit
> -  * set to guarantee no data will stay in the DMA FIFO in case
> -  * inter frame buffering occurs.
> -  */
> - if (cpu_is_omap2420() || (cpu_is_omap2430() &&
> - (omap_type() == OMAP2430_REV_ES1_0)))
> +
> + if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
>   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
>  
>   l |= OMAP_DMA_CCR_EN;
> @@ -1253,14 +1241,14 @@ EXPORT_SYMBOL(omap_start_dma);
>  
>  void omap_stop_dma(int lch)
>  {
> - u32 l;
> + u32 l = 0;
>  
>   /* Disable all interrupts on the channel */
>   if (cpu_class_is_omap1())
>   dma_write(0, CICR1, lch);
>  
> - /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
> - if (cpu_is_omap34xx() && (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
> + if (IS_DMA_ERRATA(DMA_ERRATA_i541) &&
> + (l & OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
>   int i = 0;
>   u32 sys_cf;
>  
> @@ -1367,11 +1355,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
>   else
>   offset = dma_read(CSAC2, lch);
>  
> - /*
> -  * omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
> -  * read before the DMA controller finished disabling the channel.
> -  */
> - if (!cpu_is_omap15xx() && offset == 0) {
> + if (IS_DMA_ERRATA(DMA_ERRATA_3_3) && offset == 0) {
>   if (cpu_class_is_omap1())
>   offset = dma_read(CSAC1, lch);
>   else
> @@ -1966,7 +1950,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
>  {
>   int *channels;
>   u32 l, i;
> - u32 sys_cf;
> + u32 sys_cf = 0;
>  
>   /* Check for input params */
>   if (unlikely((chain_id < 0 || chain_id >= dma_lch_count))) {
> @@ -1981,15 +1965,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
>   }
>   channels = dma_linked_lch[chain_id].linked_dmach_q;
>  
> - /*
> -  * DMA Errata:
> -  * Special programming model needed to disable DMA before end of block
> -  */
> - sys_cf = dma_read(OCP_SYSCONFIG, 0);
> - l = sys_cf;
> - /* Middle mode reg set no Standby */
> - l &= ~((1 << 12)|(1 << 13));
> - dma_write(l, OCP_SYSCONFIG, 0);
> + if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
> + sys_cf = dma_read(OCP_SYSCONFIG, 0);
> + l = sys_cf;
> + /* Middle mode reg set no Standby */
> + l &= ~((1 << 12)|(1 << 13));
> + dma_write(l, OCP_SYSCONFIG, 0);
> + }
>  
>   for (i = 0; i < dma_linked_lch[chain_i

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Greg KH]

On Tue, Nov 09, 2010 at 11:53:29PM +0200, Felipe Contreras wrote:
> On Tue, Nov 9, 2010 at 7:58 PM, Greg KH  wrote:
> > If it is easy to revert and push later, then the "revert just this
> > piece" should be done now.
> >
> > Seriously, I'm getting very confused here, and am very annoyed by the
> > whole thing.
> 
> With good reason.
> 
> > Here's what I don't like:
> >  - the original driver didn't even seem to work properly
> 
> It _was_ working properly, when it was a separate branch, but the
> merge to staging wasn't done correctly, so it has never worked there.

Well, blame the people who sent it to me then :)

> >  - people sent me patches they never tested and broke things even worse
> 
> Part of the blame goes to TI. Even if you have the hardware, it's not
> straightforward to test this. I have struggled to improve the
> situation on user-space with the gst-dsp and dsp-tools projects, which
> btw have not received support from TI, but apparently they were not
> used to test this (neither was the "official" solution from TI which
> is much harder to set up).
> 
> >  - some people have no respect for the omap maintainers and what they
> >    think about things, or even basic knowledge of the kernel
> >    development cycle.
> 
> I don't think this is the case. The opinion of the OMAP maintainers is
> valuable in order to cleanup the mess that is this driver. But _first_
> it has to work. Most people are not developers, they just want to use
> this driver.
> 
> >  - I do not have this hardware so I can't test anything.
> >
> > So, from now on, I'm not taking ANYONES patches for this driver unless
> > it gets an ack from the driver maintainer, Omar Luna.
> >
> > Actually, no, I'm not going to take any patch unless it _comes from_
> > Omar.  Omar, please work to queue up patches and test them, and then
> > send them to me for merging.
> >
> > Any questions?
> 
> You mean after this pull, or should Omar re-send this pull request?

I'm not pulling _anything_ at the moment for this driver.

I want to see patches, not a pull request please, as these need to be
reviewed very closely.

thanks,

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Felipe Contreras]

On Tue, Nov 9, 2010 at 6:29 PM, Arnd Bergmann  wrote:
> On Tuesday 09 November 2010, Felipe Contreras wrote:
>> Felipe Contreras (14):
>>       Revert "staging: tidspbridge - update Kconfig to select IOMMU module"
>>       Revert "staging: tidspbridge - remove dmm custom module"
>>       Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
>> funtions"
>>       Revert "staging: tidspbridge - remove reserved memory clean up"
>>       Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
>> struct"
>>       Revert "staging: tidspbridge - move all iommu related code to a new 
>> file"
>>       Revert "staging: tidspbridge - remove hw directory"
>>       Revert "staging: tidspbridge - fix mmufault support"
>>       Revert "staging: tidspbridge - remove custom mmu code from 
>> tiomap3430.c"
>>       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a 
>> proper name"
>>       Revert "staging: tidspbridge - move shared memory iommu maps to 
>> tiomap3430.c"
>>       Revert "staging: tidspbridge: replace iommu custom for opensource 
>> implementation"
>
> That adds quite a lot of crap back in that was removed by Fernando earlier:
>
>  44 files changed, 3733 insertions(+), 847 deletions(-)
>
> It may have been premature to merge the patches as you say, but now that
> they are in, I'd vote for giving Fernando a chance to fix up any damage
> that was done in the process rather than just reverting all the useful
> changes.

The changes from Fernando require changes in other trees: arm, omap.
These cannot get into 2.6.37, and I have my doubts they would get into
2.6.38, as I haven't seen those ack'ed yet.

Moreover, I have applied all the patches Fernando has sent, and I
still haven't seen this driver working with the new iommu code.

So, sure, these patches are good, we (Nokia), requested them years
ago, but right now there's no way to get this driver working with them
on 2.6.37. I would rather have a working driver for once on a vanilla
kernel. It is really tiring to point people to different places to get
working code depending on which week they ask.

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Felipe Contreras]

On Tue, Nov 9, 2010 at 7:58 PM, Greg KH  wrote:
> If it is easy to revert and push later, then the "revert just this
> piece" should be done now.
>
> Seriously, I'm getting very confused here, and am very annoyed by the
> whole thing.

With good reason.

> Here's what I don't like:
>  - the original driver didn't even seem to work properly

It _was_ working properly, when it was a separate branch, but the
merge to staging wasn't done correctly, so it has never worked there.

>  - people sent me patches they never tested and broke things even worse

Part of the blame goes to TI. Even if you have the hardware, it's not
straightforward to test this. I have struggled to improve the
situation on user-space with the gst-dsp and dsp-tools projects, which
btw have not received support from TI, but apparently they were not
used to test this (neither was the "official" solution from TI which
is much harder to set up).

>  - some people have no respect for the omap maintainers and what they
>    think about things, or even basic knowledge of the kernel
>    development cycle.

I don't think this is the case. The opinion of the OMAP maintainers is
valuable in order to cleanup the mess that is this driver. But _first_
it has to work. Most people are not developers, they just want to use
this driver.

>  - I do not have this hardware so I can't test anything.
>
> So, from now on, I'm not taking ANYONES patches for this driver unless
> it gets an ack from the driver maintainer, Omar Luna.
>
> Actually, no, I'm not going to take any patch unless it _comes from_
> Omar.  Omar, please work to queue up patches and test them, and then
> send them to me for merging.
>
> Any questions?

You mean after this pull, or should Omar re-send this pull request?

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

Re: [PATCH v3 03/13] OMAP: DMA: Introduce DMA device attributes

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> This patch introduces OMAP DMA device attributes for using the same in
> DMA platform driver for all OMAP's and HWMOD database(OMAP2PLUS onwards)
>
> Signed-off-by: G, Manjunath Kondaiah 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Cc: Santosh Shilimkar 
> ---
>  arch/arm/plat-omap/include/plat/dma.h |   20 
>  1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/dma.h 
> b/arch/arm/plat-omap/include/plat/dma.h
> index 5e28d26..9757b22 100644
> --- a/arch/arm/plat-omap/include/plat/dma.h
> +++ b/arch/arm/plat-omap/include/plat/dma.h
> @@ -296,6 +296,22 @@
>  #define DMA_ERRATA_i88   (1 << 4)
>  #define DMA_ERRATA_3_3   (1 << 5)
>  
> +/* Attributes for OMAP DMA Contrllers */
> +#define ENABLE_1510_MODE (1 << 0x0)
> +#define DMA_LINKED_LCH   (1 << 0x1)
> +#define GLOBAL_PRIORITY  (1 << 0x2)
> +#define RESERVE_CHANNEL  (1 << 0x3)
> +#define SRC_PORT (1 << 0x4)
> +#define DST_PORT (1 << 0x5)
> +#define IS_CSSA_32   (1 << 0x6)
> +#define IS_CDSA_32   (1 << 0x7)
> +#define SRC_INDEX(1 << 0x8)
> +#define DST_INDEX(1 << 0x9)
> +#define IS_BURST_ONLY4   (1 << 0xA)
> +#define CLEAR_CSR_ON_READ(1 << 0xB)
> +#define IS_WORD_16   (1 << 0xC)
> +#define IS_RW_PRIORITY   (1 << 0xD)

Please use BIT() for these.

>  enum omap_dma_burst_mode {
>   OMAP_DMA_DATA_BURST_DIS = 0,
>   OMAP_DMA_DATA_BURST_4,
> @@ -361,6 +377,10 @@ struct omap_dma_channel_params {
>  #endif
>  };
>  
> +struct omap_dma_dev_attr {
> + u32 dev_caps;
> + u16 lch_count;
> +};
>  
>  extern void omap_set_dma_priority(int lch, int dst_port, int priority);
>  extern int omap_request_dma(int dev_id, const char *dev_name,

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

Re: [PATCH v3 01/13] OMAP: DMA: Replace read/write macros with functions

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> The low level read/write macros are replaced with static inline functions
> and register offsets are handled through static register offset tables
> mapped through enumeration constants.
>
> The objective of this patch is to prepare for omap dma driver cleanup
> and dma hwmod implementation. The code optimization and moving machine
> specific code to respective mach-omapx dma file will be handled in the
> rest of this patch series.

[...]

> -#define dma_write(val, reg)  \
> -({   \
> - if (cpu_class_is_omap1())   \
> - __raw_writew((u16)(val), omap_dma_base + OMAP1_DMA_##reg); \
> - else\
> - __raw_writel((val), omap_dma_base + OMAP_DMA4_##reg);   \
> -})
> +static inline void dma_write(u32 val, int reg, int lch)
> +{
> + if (cpu_class_is_omap1()) {

Reminder: any use of cpu_is_* checks outside of init code will be NAK'd.

cpu_is_* check do not belong at runtime, especially in a crucial path
like this.  

> + if (reg > OMAP1_CH_COMMON_START)
> + __raw_writew(val, dma_base +
> + (reg_map_omap1[reg] + 0x40 * lch));
> + else
> + __raw_writew(val, dma_base + reg_map_omap1[reg]);
> + } else {
> + if (reg > OMAP2_CH_COMMON_START)
> + __raw_writel(val, dma_base +
> + (reg_map_omap2[reg] + 0x60 * lch));
> + else
> + __raw_writel(val, dma_base + reg_map_omap2[reg]);
> + }
> +}

The register base offset, register array and the stride (offset between
instances: 0x40 or 0x60) are detectable at init time, and there's no
reason to have conditional code for them.  IOW, they should be init time
constants.  Doing so would greatly simply these functions.  In fact the
CH_COMMON_START could also be an init time constant as well.  So, given
the following init_time constants: dma_ch_common_start, dma_stride,
reg_map, the above would be reduced to something actually worth
inlining, for example (not actually tested):

static inline void dma_write(u32 val, int reg, int lch)
{
u8 stride = (reg > dma_ch_common_start) ? dma_stride : 0;

__raw_writel(val, dma_base + (reg_map[reg] + stride * lch));
}

Same applies to dma_read().

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Felipe Contreras]

On Tue, Nov 9, 2010 at 7:52 PM, Guzman Lugo, Fernando
 wrote:
> On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren  wrote:
>> * Guzman Lugo, Fernando  [101109 08:36]:
>>>
>>> tidspbridge iommu change are working fine all the patches and few fixes 
>>> after
>>> that are alredy sent. what breaks tidspbridge, is the unmerged
>>> dependencies in linux omap tree, specifically the iommu module patches
>>> and the SG patch.
>>
>> Care to post a series of the missing patches listed above?
>
> Here are the missing patches:
>
> Fernando Guzman Lugo (4):
>  iovmm: no gap checking for fixed address
>  iovmm: add superpages support to fixed da address
>  iovmm: replace __iounmap with omap_iounmap
>  iommu: create new api to set valid da range
>
> and
>  scatterlist: define SG chain for arm architecture

Those are not the only patches needed, you would also need:
 omap: iommu: make iva2 iommu selectable
 staging: tidspbridge: enable iva2 iommu

And the one that actually uses the new API for the da range which
hasn't even been submitted to the mailing list.

Personally, I haven't seen the new iommu code working correctly.

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

Re: [PATCH v2] OMAP: hwmod: Update the sysc_cache in case module context is lost

[Kevin Hilman]

Rajendra Nayak  writes:

> Do not skip the sysc programming in the hmwod framework based
> on the cached value alone, since at times the module might have lost
> context (due to the Powerdomain in which the module belongs
> transitions to either Open Switch RET or OFF).
>
> Identifying if a module has lost context requires atleast one
> register read, and since a register read has more latency than
> a write, it makes sense to do a blind write always.
>
> Signed-off-by: Rajendra Nayak 
> Cc: Paul Walmsley 
> Cc: Benoit Cousson 
> Cc: Santosh Shilimkar 
> Cc: Kevin Hilman 

Acked-by: Kevin Hilman 

> ---
>  arch/arm/mach-omap2/omap_hwmod.c |7 +++
>  1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 5a30658..aadd6dc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -209,10 +209,9 @@ static void _write_sysconfig(u32 v, struct omap_hwmod 
> *oh)
>  
>   /* XXX ensure module interface clock is up */
>  
> - if (oh->_sysc_cache != v) {
> - oh->_sysc_cache = v;
> - omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
> - }
> + /* Module might have lost context, always update cache and register */
> + oh->_sysc_cache = v;
> + omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
>  }
>  
>  /**
--
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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Ramirez Luna, Omar]

Hi,

> Seriously, I'm getting very confused here, and am very annoyed by the
> whole thing.
>
> Here's what I don't like:
>  - the original driver didn't even seem to work properly
>  - people sent me patches they never tested and broke things even worse
>  - some people have no respect for the omap maintainers and what they
>    think about things, or even basic knowledge of the kernel
>    development cycle.
>  - I do not have this hardware so I can't test anything.
>
> So, from now on, I'm not taking ANYONES patches for this driver unless
> it gets an ack from the driver maintainer, Omar Luna.
>
> Actually, no, I'm not going to take any patch unless it _comes from_
> Omar.  Omar, please work to queue up patches and test them, and then
> send them to me for merging.
>
> Any questions?
>
> If anyone doesn't like this because they feel that the current driver is
> broken, well, I can easily solve that by just deleting the whole thing
> from the tree right now.  Would that be a better idea?

I'm fine to queue the patches.

For now, yes, the driver is/has-been broken, and everybody has been
trying for the last two cycles to fix some dependencies (and
unfortunately we do it at the last minute or even after it can't be
done anymore, *sometimes*)... I have been kindly educated by both LO
and staging tree maintainers that it is just a bad practice to hurry
things up and not comply with the development standards.

If 2.6.36 or .37 tidspbridge is needed I'll keep each branch with
their dependent patches in d.o-z (TI's git server), if anybody
(Felipe) wants to keep their own branches I'm fine with that I can
sync with them privately to hear any concerns or something else.

I'll create the branches and sent an announce to both lists.

All dependencies need to be acked long before 2.6.38-rc1 and it is the
responsibility of the senders to track their acceptance.

Thanks for your suggestions and bearing with this situation, I'll
follow them and solve your dislikes about it (the hardware part it
might not be possible :/).

BTW, the testing environment for tidspbridge will be gst-dsp, any
stress testsuites will be run in addition, I'll detail more of it in
the upcoming mail.

Regards,

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Tony Lindgren]

* Guzman Lugo, Fernando  [101109 09:43]:
> On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren  wrote:
> > * Guzman Lugo, Fernando  [101109 08:36]:
> >>
> >> tidspbridge iommu change are working fine all the patches and few fixes 
> >> after
> >> that are alredy sent. what breaks tidspbridge, is the unmerged
> >> dependencies in linux omap tree, specifically the iommu module patches
> >> and the SG patch.
> >
> > Care to post a series of the missing patches listed above?
> 
> Here are the missing patches:
> 
> Fernando Guzman Lugo (4):
>   iovmm: no gap checking for fixed address
>   iovmm: add superpages support to fixed da address
>   iovmm: replace __iounmap with omap_iounmap
>   iommu: create new api to set valid da range

Yeah this is stuff for Hiroshi to look at and queue for
2.6.28. No way we can merge these now.
 
> and
>   scatterlist: define SG chain for arm architecture

And this we need to test carefully it's not something we
can just merge.

Has this been tested to work with omap MMC drivers?

I'm not at all convinced the drivers can deal with
chained SG lists.. This may not show up with light
testing, the SG lists can be very small in most cases.

So this would have to be tested to make sure the
the chained SG list handled properly. The same goes
for other omap drivers that may be using SG.

Regards,

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Greg KH]

On Tue, Nov 09, 2010 at 11:49:30AM -0600, Guzman Lugo, Fernando wrote:
> On Tue, Nov 9, 2010 at 11:25 AM, Greg KH  wrote:
> > On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote:
> >> On Tue, Nov 9, 2010 at 10:55 AM, Greg KH  wrote:
> >> > On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote:
> >> >> On Tuesday 09 November 2010, Felipe Contreras wrote:
> >> >> > Felipe Contreras (14):
> >> >> >       Revert "staging: tidspbridge - update Kconfig to select IOMMU 
> >> >> > module"
> >> >> >       Revert "staging: tidspbridge - remove dmm custom module"
> >> >> >       Revert "staging: tidspbridge - deprecate 
> >> >> > reserve/unreserve_memory funtions"
> >> >> >       Revert "staging: tidspbridge - remove reserved memory clean up"
> >> >> >       Revert "staging: tidspbridge: remove dw_dmmu_base from 
> >> >> > cfg_hostres struct"
> >> >> >       Revert "staging: tidspbridge - move all iommu related code to a 
> >> >> > new file"
> >> >> >       Revert "staging: tidspbridge - remove hw directory"
> >> >> >       Revert "staging: tidspbridge - fix mmufault support"
> >> >> >       Revert "staging: tidspbridge - remove custom mmu code from 
> >> >> > tiomap3430.c"
> >> >> >       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap 
> >> >> > to a proper name"
> >> >> >       Revert "staging: tidspbridge - move shared memory iommu maps to 
> >> >> > tiomap3430.c"
> >> >> >       Revert "staging: tidspbridge: replace iommu custom for 
> >> >> > opensource implementation"
> >> >>
> >> >> That adds quite a lot of crap back in that was removed by Fernando 
> >> >> earlier:
> >> >>
> >> >>  44 files changed, 3733 insertions(+), 847 deletions(-)
> >> >>
> >> >> It may have been premature to merge the patches as you say, but now that
> >> >> they are in, I'd vote for giving Fernando a chance to fix up any damage
> >> >> that was done in the process rather than just reverting all the useful
> >> >> changes.
> >> >
> >> > In looking at this further, I agree.
> >> >
> >> > Felipe, are all of these really needing to be reverted?  How about
> >> > picking out the functional changes that need to be resolved instead of
> >> > just rolling back everything that has been done here.  Surely not all of
> >> > these are wrong, right?
> >>
> >> Patches are _NOT_ wrong, missing dependencies break the bridge.
> >> Without that dependencies the first patch of the set won't work and
> >> all other patches have dependency on the first one, so all of them
> >> need to be reverted.
> >
> > How about hand-reverting only the wrong patch, so the other work isn't
> > lost?  I'd much prefer that.
> 
> Unfortunately any of the iommu migration patches will work correctly
> without the dependencies on iommu module patches. There are some
> patches which cleanup the code, but thanks to the iommu migrations the
> files can disappear complete other wise I need to check and only clean
> what is not needed and leave what the old custom implementation is
> using, which will need a lot of rework in the patches. According with
> Felipe Contreras it is very easy reverting and pushing after.

If it is easy to revert and push later, then the "revert just this
piece" should be done now.

Seriously, I'm getting very confused here, and am very annoyed by the
whole thing.

Here's what I don't like:
  - the original driver didn't even seem to work properly
  - people sent me patches they never tested and broke things even worse
  - some people have no respect for the omap maintainers and what they
think about things, or even basic knowledge of the kernel
development cycle.
  - I do not have this hardware so I can't test anything.

So, from now on, I'm not taking ANYONES patches for this driver unless
it gets an ack from the driver maintainer, Omar Luna.

Actually, no, I'm not going to take any patch unless it _comes from_
Omar.  Omar, please work to queue up patches and test them, and then
send them to me for merging.

Any questions?

If anyone doesn't like this because they feel that the current driver is
broken, well, I can easily solve that by just deleting the whole thing
from the tree right now.  Would that be a better idea?

Ugh, what a mess...

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Guzman Lugo, Fernando]

On Tue, Nov 9, 2010 at 11:35 AM, Tony Lindgren  wrote:
> * Guzman Lugo, Fernando  [101109 08:36]:
>>
>> tidspbridge iommu change are working fine all the patches and few fixes after
>> that are alredy sent. what breaks tidspbridge, is the unmerged
>> dependencies in linux omap tree, specifically the iommu module patches
>> and the SG patch.
>
> Care to post a series of the missing patches listed above?

Here are the missing patches:

Fernando Guzman Lugo (4):
  iovmm: no gap checking for fixed address
  iovmm: add superpages support to fixed da address
  iovmm: replace __iounmap with omap_iounmap
  iommu: create new api to set valid da range

and
  scatterlist: define SG chain for arm architecture


Regards,
Fernando.



>
> That way we can at least start merging those into linux-omap for
> testing while waiting for the next merge window.
>
> Tony
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Guzman Lugo, Fernando]

On Tue, Nov 9, 2010 at 11:25 AM, Greg KH  wrote:
> On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote:
>> On Tue, Nov 9, 2010 at 10:55 AM, Greg KH  wrote:
>> > On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote:
>> >> On Tuesday 09 November 2010, Felipe Contreras wrote:
>> >> > Felipe Contreras (14):
>> >> >       Revert "staging: tidspbridge - update Kconfig to select IOMMU 
>> >> > module"
>> >> >       Revert "staging: tidspbridge - remove dmm custom module"
>> >> >       Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
>> >> > funtions"
>> >> >       Revert "staging: tidspbridge - remove reserved memory clean up"
>> >> >       Revert "staging: tidspbridge: remove dw_dmmu_base from 
>> >> > cfg_hostres struct"
>> >> >       Revert "staging: tidspbridge - move all iommu related code to a 
>> >> > new file"
>> >> >       Revert "staging: tidspbridge - remove hw directory"
>> >> >       Revert "staging: tidspbridge - fix mmufault support"
>> >> >       Revert "staging: tidspbridge - remove custom mmu code from 
>> >> > tiomap3430.c"
>> >> >       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to 
>> >> > a proper name"
>> >> >       Revert "staging: tidspbridge - move shared memory iommu maps to 
>> >> > tiomap3430.c"
>> >> >       Revert "staging: tidspbridge: replace iommu custom for opensource 
>> >> > implementation"
>> >>
>> >> That adds quite a lot of crap back in that was removed by Fernando 
>> >> earlier:
>> >>
>> >>  44 files changed, 3733 insertions(+), 847 deletions(-)
>> >>
>> >> It may have been premature to merge the patches as you say, but now that
>> >> they are in, I'd vote for giving Fernando a chance to fix up any damage
>> >> that was done in the process rather than just reverting all the useful
>> >> changes.
>> >
>> > In looking at this further, I agree.
>> >
>> > Felipe, are all of these really needing to be reverted?  How about
>> > picking out the functional changes that need to be resolved instead of
>> > just rolling back everything that has been done here.  Surely not all of
>> > these are wrong, right?
>>
>> Patches are _NOT_ wrong, missing dependencies break the bridge.
>> Without that dependencies the first patch of the set won't work and
>> all other patches have dependency on the first one, so all of them
>> need to be reverted.
>
> How about hand-reverting only the wrong patch, so the other work isn't
> lost?  I'd much prefer that.

Unfortunately any of the iommu migration patches will work correctly
without the dependencies on iommu module patches. There are some
patches which cleanup the code, but thanks to the iommu migrations the
files can disappear complete other wise I need to check and only clean
what is not needed and leave what the old custom implementation is
using, which will need a lot of rework in the patches. According with
Felipe Contreras it is very easy reverting and pushing after. I don't
like the idea of reverting all iommu patches, however looks the
easiest solution. Unless the dependencies patches can be merged the
would be the best solution.

Regards,
Fernando.

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

Re: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's

[Kevin Hilman]

Ben Dooks  writes:

> On Thu, Oct 07, 2010 at 10:37:03AM -0700, Kevin Hilman wrote:
>> Ben Dooks  writes:
>> 
>> [...]
>> 
>> > As such, I should really go and read up all about this new runtime-pm
>> > and hwmod stuff before further commentign on the changes.
>> 
>> ping
>> 
>> >From the drivers perspective, you don't neet to know anything about
>> omap_hwmod.  You can think of this change as simply using the runtime PM
>> API instead of the clock API for enabling and idling the device.
>> 
>> With your ack (on this patch only) we'd like to merge this along with
>> the rest of the series for 2.6.37.
>
> Acked-by: Ben Dooks 
>
> please post via your tree.

Thanks Ben,

Will queue up for 2.6.38.

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Tony Lindgren]

* Guzman Lugo, Fernando  [101109 08:36]:
> 
> tidspbridge iommu change are working fine all the patches and few fixes after
> that are alredy sent. what breaks tidspbridge, is the unmerged
> dependencies in linux omap tree, specifically the iommu module patches
> and the SG patch.

Care to post a series of the missing patches listed above?

That way we can at least start merging those into linux-omap for
testing while waiting for the next merge window.

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

Re: [PATCH] OMAP3: I2C: hwmod: Fix PRCM module offset

[Kevin Hilman]

"G, Manjunath Kondaiah"  writes:

> The commit '311225e6' is missing '.module_offs' in prcm
> structure in omap3 hwmod data base which results in accessing
> wrong register for I2Cx IDLEST bit monitoring.
>
> Added module offsets for accessing register CM_IDLEST1_CORE.
>
> Patch tested on Zoom3 using omap2plus_defconfig

Thanks, will fold this into original series.

Kevin

> Signed-off-by: G, Manjunath Kondaiah 
> Signed-off-by: Charulatha V 
> Cc: Kevin Hilman 
> Cc: Paul Walmsley 
> Cc: Rajendra Nayak 
> Cc: Benoit Cousson 
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index d0d8030..22831e9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -642,6 +642,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
>   .main_clk   = "i2c1_fck",
>   .prcm   = {
>   .omap2 = {
> + .module_offs = CORE_MOD,
>   .prcm_reg_id = 1,
>   .module_bit = OMAP3430_EN_I2C1_SHIFT,
>   .idlest_reg_id = 1,
> @@ -683,6 +684,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
>   .main_clk   = "i2c2_fck",
>   .prcm   = {
>   .omap2 = {
> + .module_offs = CORE_MOD,
>   .prcm_reg_id = 1,
>   .module_bit = OMAP3430_EN_I2C2_SHIFT,
>   .idlest_reg_id = 1,
> @@ -724,6 +726,7 @@ static struct omap_hwmod omap3xxx_i2c3_hwmod = {
>   .main_clk   = "i2c3_fck",
>   .prcm   = {
>   .omap2 = {
> + .module_offs = CORE_MOD,
>   .prcm_reg_id = 1,
>   .module_bit = OMAP3430_EN_I2C3_SHIFT,
>   .idlest_reg_id = 1,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Greg KH]

On Tue, Nov 09, 2010 at 11:04:18AM -0600, Guzman Lugo, Fernando wrote:
> On Tue, Nov 9, 2010 at 10:55 AM, Greg KH  wrote:
> > On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 09 November 2010, Felipe Contreras wrote:
> >> > Felipe Contreras (14):
> >> >       Revert "staging: tidspbridge - update Kconfig to select IOMMU 
> >> > module"
> >> >       Revert "staging: tidspbridge - remove dmm custom module"
> >> >       Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
> >> > funtions"
> >> >       Revert "staging: tidspbridge - remove reserved memory clean up"
> >> >       Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
> >> > struct"
> >> >       Revert "staging: tidspbridge - move all iommu related code to a 
> >> > new file"
> >> >       Revert "staging: tidspbridge - remove hw directory"
> >> >       Revert "staging: tidspbridge - fix mmufault support"
> >> >       Revert "staging: tidspbridge - remove custom mmu code from 
> >> > tiomap3430.c"
> >> >       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to 
> >> > a proper name"
> >> >       Revert "staging: tidspbridge - move shared memory iommu maps to 
> >> > tiomap3430.c"
> >> >       Revert "staging: tidspbridge: replace iommu custom for opensource 
> >> > implementation"
> >>
> >> That adds quite a lot of crap back in that was removed by Fernando earlier:
> >>
> >>  44 files changed, 3733 insertions(+), 847 deletions(-)
> >>
> >> It may have been premature to merge the patches as you say, but now that
> >> they are in, I'd vote for giving Fernando a chance to fix up any damage
> >> that was done in the process rather than just reverting all the useful
> >> changes.
> >
> > In looking at this further, I agree.
> >
> > Felipe, are all of these really needing to be reverted?  How about
> > picking out the functional changes that need to be resolved instead of
> > just rolling back everything that has been done here.  Surely not all of
> > these are wrong, right?
> 
> Patches are _NOT_ wrong, missing dependencies break the bridge.
> Without that dependencies the first patch of the set won't work and
> all other patches have dependency on the first one, so all of them
> need to be reverted.

How about hand-reverting only the wrong patch, so the other work isn't
lost?  I'd much prefer that.

thanks,

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

[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers

[Bryan Wu]

Still keep sharp_ls_panel driver, because it contains blacklight control driver.

Signed-off-by: Bryan Wu 
---
 drivers/video/omap2/displays/Kconfig   |   18 --
 drivers/video/omap2/displays/Makefile  |3 -
 drivers/video/omap2/displays/panel-generic.c   |  174 
 .../video/omap2/displays/panel-sharp-lq043t1dg01.c |  165 ---
 .../video/omap2/displays/panel-toppoly-tdo35s.c|  164 --
 5 files changed, 0 insertions(+), 524 deletions(-)
 delete mode 100644 drivers/video/omap2/displays/panel-generic.c
 delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
 delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c

diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index cb3e339..9c09afd 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -9,12 +9,6 @@ config PANEL_GENERIC_DPI
  Supports LCD Panel used in TI SDP3430 and EVM boards,
  OMAP3517 EVM boards and CM-T35.
 
-config PANEL_GENERIC
-tristate "Generic Panel"
-help
- Generic panel driver.
- Used for DVI output for Beagle and OMAP3 SDP.
-
 config PANEL_SHARP_LS037V7DW01
 tristate "Sharp LS037V7DW01 LCD Panel"
 depends on OMAP2_DSS
@@ -22,24 +16,12 @@ config PANEL_SHARP_LS037V7DW01
 help
   LCD Panel used in TI's SDP3430 and EVM boards
 
-config PANEL_SHARP_LQ043T1DG01
-tristate "Sharp LQ043T1DG01 LCD Panel"
-depends on OMAP2_DSS
-help
-  LCD Panel used in TI's OMAP3517 EVM boards
-
 config PANEL_TAAL
 tristate "Taal DSI Panel"
 depends on OMAP2_DSS_DSI
 help
   Taal DSI command mode panel from TPO.
 
-config PANEL_TOPPOLY_TDO35S
-tristate "Toppoly TDO35S LCD Panel support"
-depends on OMAP2_DSS
-help
-  LCD Panel used in CM-T35
-
 config PANEL_TPO_TD043MTEA1
 tristate "TPO TD043MTEA1 LCD Panel"
 depends on OMAP2_DSS && SPI
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index 022058c..3bebe4d 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,9 +1,6 @@
 obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
-obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
 
 obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
-obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
 obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-generic.c 
b/drivers/video/omap2/displays/panel-generic.c
deleted file mode 100644
index 395a68d..000
--- a/drivers/video/omap2/displays/panel-generic.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Generic panel support
- *
- * Copyright (C) 2008 Nokia Corporation
- * Author: Tomi Valkeinen 
- *
- * 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 
-
-static struct omap_video_timings generic_panel_timings = {
-   /* 640 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
-   .x_res  = 640,
-   .y_res  = 480,
-   .pixel_clock= 23500,
-   .hfp= 48,
-   .hsw= 32,
-   .hbp= 80,
-   .vfp= 3,
-   .vsw= 4,
-   .vbp= 7,
-};
-
-static int generic_panel_power_on(struct omap_dss_device *dssdev)
-{
-   int r;
-
-   if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
-   return 0;
-
-   r = omapdss_dpi_display_enable(dssdev);
-   if (r)
-   goto err0;
-
-   if (dssdev->platform_enable) {
-   r = dssdev->platform_enable(dssdev);
-   if (r)
-   goto err1;
-   }
-
-   return 0;
-err1:
-   omapdss_dpi_display_disable(dssdev);
-err0:
-   return r;
-}
-
-static void generic_panel_power_off(struct omap_dss_device *dssdev)
-{
-   if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
-   return;
-
-   if (dssdev->platform_disable)
-   dssdev->platform_disable(dssdev);
-
-   omapdss_dpi_display_disable(dssdev);
-}
-
-static int generi

[PATCH 2/3] OMAP: use generic DPI panel driver in board files

[Bryan Wu]

Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight
control driver code which will be moved out later. Then we can use generic DPI
driver for sharp_ls_panel.

Signed-off-by: Bryan Wu 
---
 arch/arm/mach-omap2/board-3430sdp.c  |   13 +
 arch/arm/mach-omap2/board-am3517evm.c|   25 +
 arch/arm/mach-omap2/board-cm-t35.c   |   25 +
 arch/arm/mach-omap2/board-devkit8000.c   |   28 ++--
 arch/arm/mach-omap2/board-igep0020.c |   13 +
 arch/arm/mach-omap2/board-omap3beagle.c  |   13 +
 arch/arm/mach-omap2/board-omap3evm.c |   13 +
 arch/arm/mach-omap2/board-omap3stalker.c |   25 +
 8 files changed, 105 insertions(+), 50 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 4e3742c..4bafdd7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -270,13 +271,17 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable   = sdp3430_panel_disable_lcd,
 };
 
+static struct panel_generic_dpi_data dvi_panel = {
+   .name   = "generic",
+   .platform_enable= sdp3430_panel_enable_dvi,
+   .platform_disable   = sdp3430_panel_disable_dvi,
+};
+
 static struct omap_dss_device sdp3430_dvi_device = {
.name   = "dvi",
-   .driver_name= "generic_panel",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .driver_name= "generic_dpi_panel",
+   .data   = &dvi_panel,
.phy.dpi.data_lines = 24,
-   .platform_enable= sdp3430_panel_enable_dvi,
-   .platform_disable   = sdp3430_panel_disable_dvi,
 };
 
 static struct omap_dss_device sdp3430_tv_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 0739950..3534a23 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 #include "control.h"
@@ -303,13 +304,17 @@ static void am3517_evm_panel_disable_lcd(struct 
omap_dss_device *dssdev)
lcd_enabled = 0;
 }
 
+static struct panel_generic_dpi_data lcd_panel = {
+   .name   = "sharp_lq",
+   .platform_enable= am3517_evm_panel_enable_lcd,
+   .platform_disable   = am3517_evm_panel_disable_lcd,
+};
+
 static struct omap_dss_device am3517_evm_lcd_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
.name   = "lcd",
-   .driver_name= "sharp_lq_panel",
+   .driver_name= "generic_dpi_panel",
+   .data   = &lcd_panel,
.phy.dpi.data_lines = 16,
-   .platform_enable= am3517_evm_panel_enable_lcd,
-   .platform_disable   = am3517_evm_panel_disable_lcd,
 };
 
 static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
@@ -346,13 +351,17 @@ static void am3517_evm_panel_disable_dvi(struct 
omap_dss_device *dssdev)
dvi_enabled = 0;
 }
 
+static struct panel_generic_dpi_data dvi_panel = {
+   .name   = "generic",
+   .platform_enable= am3517_evm_panel_enable_dvi,
+   .platform_disable   = am3517_evm_panel_disable_dvi,
+};
+
 static struct omap_dss_device am3517_evm_dvi_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
.name   = "dvi",
-   .driver_name= "generic_panel",
+   .driver_name= "generic_dpi_panel",
+   .data   = &dvi_panel,
.phy.dpi.data_lines = 24,
-   .platform_enable= am3517_evm_panel_enable_dvi,
-   .platform_disable   = am3517_evm_panel_disable_dvi,
 };
 
 static struct omap_dss_device *am3517_evm_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 63f764e..1a69d32 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -351,22 +352,30 @@ static void cm_t35_panel_disable_tv(struct 
omap_dss_device *dssdev)
 {
 }
 
+static struct panel_generic_dpi_data lcd_panel = {
+   .name   = "toppoly_tdo35s",
+   .platform_enable= cm_t35_panel_enable_lcd,
+   .platform_disable   = cm_t35_panel_disable_lcd,
+};
+
 static struct omap_dss_device cm_t35_lcd_device = {
.name   = "lcd",
-   .driver_name= "toppoly_tdo35s_panel",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .driver_name= "generic_dpi_panel",
+   .data   

[PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver

[Bryan Wu]

Generic DPI panel driver includes the driver and 4 similar panel 
configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.

With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.

Signed-off-by: Bryan Wu 
---
 .../arm/plat-omap/include/plat/panel-generic-dpi.h |   37 +++
 drivers/video/omap2/displays/Kconfig   |8 +
 drivers/video/omap2/displays/Makefile  |1 +
 drivers/video/omap2/displays/panel-generic-dpi.c   |  309 
 4 files changed, 355 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
 create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c

diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h 
b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
new file mode 100644
index 000..7906197
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
@@ -0,0 +1,37 @@
+/*
+ * Header for generic DPI panel driver
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu 
+ *
+ * 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 __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+#define __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H
+
+#include "display.h"
+
+/**
+ * struct panel_generic_dpi_data - panel driver configuration data
+ * @name: panel name
+ * @platform_enable: platform specific panel enable function
+ * @platform_disable: platform specific panel disable function
+ */
+struct panel_generic_dpi_data {
+   const char *name;
+   int (*platform_enable)(struct omap_dss_device *dssdev);
+   void (*platform_disable)(struct omap_dss_device *dssdev);
+};
+
+#endif /* __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H */
diff --git a/drivers/video/omap2/displays/Kconfig 
b/drivers/video/omap2/displays/Kconfig
index 12327bb..cb3e339 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -1,6 +1,14 @@
 menu "OMAP2/3 Display Device Drivers"
 depends on OMAP2_DSS
 
+config PANEL_GENERIC_DPI
+tristate "Generic DPI Panel"
+help
+ Generic DPI panel driver.
+ Supports DVI output for Beagle and OMAP3 SDP.
+ Supports LCD Panel used in TI SDP3430 and EVM boards,
+ OMAP3517 EVM boards and CM-T35.
+
 config PANEL_GENERIC
 tristate "Generic Panel"
 help
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index aa38609..022058c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
 obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
 obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c 
b/drivers/video/omap2/displays/panel-generic-dpi.c
new file mode 100644
index 000..7ddd631
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -0,0 +1,309 @@
+/*
+ * Generic DPI Panels support
+ *
+ * Copyright (C) 2010 Canonical Ltd.
+ * Author: Bryan Wu 
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen 
+ *
+ * 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 
+
+struct panel_config {
+   struct omap_video_timings timings;
+
+   int acbi;   /* ac-bias pin transitions per interrupt */
+   /* Unit: line clocks */
+   int acb;/* ac-bias pin frequency */
+
+   enum omap_panel_config config;
+
+   /*
+* Used to match device to panel configuration
+* when use generic panel driver
+*/
+

[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #5)

[Bryan Wu]

There are 4 duplicated DPI panel drivers in DSS2 display driver. They are
similar and a generic DPI panel driver can support all them with specific
panel configuration. And new DPI panel driver can be easily supported
by adding panel configurations into generic panel DPI driver.

This patchset introduces a generic panel DPI driver, remove 3 panel drivers and 
enable
generic panel DPI driver in board files. And it is based on 2.6.37-rc1.

Building with omap2plus_defconfig is successful.

Keep sharp_ls_panel, since it contains blacklight control code which will be
moved out later.

Bryan Wu (3):
  OMAP: DSS2: Add generic DPI panel display driver
  OMAP: use generic DPI panel driver in board files
  OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers

 arch/arm/mach-omap2/board-3430sdp.c|   13 +-
 arch/arm/mach-omap2/board-am3517evm.c  |   25 +-
 arch/arm/mach-omap2/board-cm-t35.c |   25 +-
 arch/arm/mach-omap2/board-devkit8000.c |   28 ++-
 arch/arm/mach-omap2/board-igep0020.c   |   13 +-
 arch/arm/mach-omap2/board-omap3beagle.c|   13 +-
 arch/arm/mach-omap2/board-omap3evm.c   |   13 +-
 arch/arm/mach-omap2/board-omap3stalker.c   |   25 +-
 .../arm/plat-omap/include/plat/panel-generic-dpi.h |   37 +++
 drivers/video/omap2/displays/Kconfig   |   22 +-
 drivers/video/omap2/displays/Makefile  |4 +-
 drivers/video/omap2/displays/panel-generic-dpi.c   |  309 
 drivers/video/omap2/displays/panel-generic.c   |  174 ---
 .../video/omap2/displays/panel-sharp-lq043t1dg01.c |  165 ---
 .../video/omap2/displays/panel-toppoly-tdo35s.c|  164 ---
 15 files changed, 458 insertions(+), 572 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
 create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
 delete mode 100644 drivers/video/omap2/displays/panel-generic.c
 delete mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
 delete mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Guzman Lugo, Fernando]

On Tue, Nov 9, 2010 at 10:55 AM, Greg KH  wrote:
> On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote:
>> On Tuesday 09 November 2010, Felipe Contreras wrote:
>> > Felipe Contreras (14):
>> >       Revert "staging: tidspbridge - update Kconfig to select IOMMU module"
>> >       Revert "staging: tidspbridge - remove dmm custom module"
>> >       Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
>> > funtions"
>> >       Revert "staging: tidspbridge - remove reserved memory clean up"
>> >       Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
>> > struct"
>> >       Revert "staging: tidspbridge - move all iommu related code to a new 
>> > file"
>> >       Revert "staging: tidspbridge - remove hw directory"
>> >       Revert "staging: tidspbridge - fix mmufault support"
>> >       Revert "staging: tidspbridge - remove custom mmu code from 
>> > tiomap3430.c"
>> >       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a 
>> > proper name"
>> >       Revert "staging: tidspbridge - move shared memory iommu maps to 
>> > tiomap3430.c"
>> >       Revert "staging: tidspbridge: replace iommu custom for opensource 
>> > implementation"
>>
>> That adds quite a lot of crap back in that was removed by Fernando earlier:
>>
>>  44 files changed, 3733 insertions(+), 847 deletions(-)
>>
>> It may have been premature to merge the patches as you say, but now that
>> they are in, I'd vote for giving Fernando a chance to fix up any damage
>> that was done in the process rather than just reverting all the useful
>> changes.
>
> In looking at this further, I agree.
>
> Felipe, are all of these really needing to be reverted?  How about
> picking out the functional changes that need to be resolved instead of
> just rolling back everything that has been done here.  Surely not all of
> these are wrong, right?

Patches are _NOT_ wrong, missing dependencies break the bridge.
Without that dependencies the first patch of the set won't work and
all other patches have dependency on the first one, so all of them
need to be reverted.

Regards,
Fernando.

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Greg KH]

On Tue, Nov 09, 2010 at 05:29:17PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 November 2010, Felipe Contreras wrote:
> > Felipe Contreras (14):
> >   Revert "staging: tidspbridge - update Kconfig to select IOMMU module"
> >   Revert "staging: tidspbridge - remove dmm custom module"
> >   Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
> > funtions"
> >   Revert "staging: tidspbridge - remove reserved memory clean up"
> >   Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
> > struct"
> >   Revert "staging: tidspbridge - move all iommu related code to a new 
> > file"
> >   Revert "staging: tidspbridge - remove hw directory"
> >   Revert "staging: tidspbridge - fix mmufault support"
> >   Revert "staging: tidspbridge - remove custom mmu code from 
> > tiomap3430.c"
> >   Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a 
> > proper name"
> >   Revert "staging: tidspbridge - move shared memory iommu maps to 
> > tiomap3430.c"
> >   Revert "staging: tidspbridge: replace iommu custom for opensource 
> > implementation"
> 
> That adds quite a lot of crap back in that was removed by Fernando earlier:
> 
>  44 files changed, 3733 insertions(+), 847 deletions(-)
> 
> It may have been premature to merge the patches as you say, but now that
> they are in, I'd vote for giving Fernando a chance to fix up any damage
> that was done in the process rather than just reverting all the useful
> changes.

In looking at this further, I agree.

Felipe, are all of these really needing to be reverted?  How about
picking out the functional changes that need to be resolved instead of
just rolling back everything that has been done here.  Surely not all of
these are wrong, right?

thanks,

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

Re: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Guzman Lugo, Fernando]

On Tue, Nov 9, 2010 at 10:29 AM, Arnd Bergmann  wrote:
> On Tuesday 09 November 2010, Felipe Contreras wrote:
>> Felipe Contreras (14):
>>       Revert "staging: tidspbridge - update Kconfig to select IOMMU module"
>>       Revert "staging: tidspbridge - remove dmm custom module"
>>       Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
>> funtions"
>>       Revert "staging: tidspbridge - remove reserved memory clean up"
>>       Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
>> struct"
>>       Revert "staging: tidspbridge - move all iommu related code to a new 
>> file"
>>       Revert "staging: tidspbridge - remove hw directory"
>>       Revert "staging: tidspbridge - fix mmufault support"
>>       Revert "staging: tidspbridge - remove custom mmu code from 
>> tiomap3430.c"
>>       Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a 
>> proper name"
>>       Revert "staging: tidspbridge - move shared memory iommu maps to 
>> tiomap3430.c"
>>       Revert "staging: tidspbridge: replace iommu custom for opensource 
>> implementation"
>
> That adds quite a lot of crap back in that was removed by Fernando earlier:
>
>  44 files changed, 3733 insertions(+), 847 deletions(-)
>
> It may have been premature to merge the patches as you say, but now that
> they are in, I'd vote for giving Fernando a chance to fix up any damage
> that was done in the process rather than just reverting all the useful
> changes.
>
>        Arnd

tidspbridge iommu change are working fine all the patches and few fixes after
that are alredy sent. what breaks tidspbridge, is the unmerged
dependencies in linux omap
tree, specifically the iommu module patches and the SG patch. if the
dependencies are merged tidspbridge work perfectly I don't need to fix
anything. As the dependencies are not merge yet it is ok to revert and
once push once all the dependencies are merge. I am not familiar with
that so I don't know how much time can it take.

Regards,
Fernando.

>
--
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: [GIT PULL] fixes for tidspbridge 2.6.37-rc1

[Arnd Bergmann]

On Tuesday 09 November 2010, Felipe Contreras wrote:
> Felipe Contreras (14):
>   Revert "staging: tidspbridge - update Kconfig to select IOMMU module"
>   Revert "staging: tidspbridge - remove dmm custom module"
>   Revert "staging: tidspbridge - deprecate reserve/unreserve_memory 
> funtions"
>   Revert "staging: tidspbridge - remove reserved memory clean up"
>   Revert "staging: tidspbridge: remove dw_dmmu_base from cfg_hostres 
> struct"
>   Revert "staging: tidspbridge - move all iommu related code to a new 
> file"
>   Revert "staging: tidspbridge - remove hw directory"
>   Revert "staging: tidspbridge - fix mmufault support"
>   Revert "staging: tidspbridge - remove custom mmu code from tiomap3430.c"
>   Revert "staging: tidspbridge - rename bridge_brd_mem_map/unmap to a 
> proper name"
>   Revert "staging: tidspbridge - move shared memory iommu maps to 
> tiomap3430.c"
>   Revert "staging: tidspbridge: replace iommu custom for opensource 
> implementation"

That adds quite a lot of crap back in that was removed by Fernando earlier:

 44 files changed, 3733 insertions(+), 847 deletions(-)

It may have been premature to merge the patches as you say, but now that
they are in, I'd vote for giving Fernando a chance to fix up any damage
that was done in the process rather than just reverting all the useful
changes.

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

[Patch v5] OMAP: AM3517/05: Add craneboard support

[srinath]

From: Srinath 

Craneboard is a hardware development platform based on the
Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a
low cost reference design.

This patch adds basic board file. Detailed support will follow in
subsequent patches.

  [1] http://www.ti.com/arm
  [2] http://www.mistralsolutions.com/products/craneboard.php

Signed-off-by: Srinath 
---
 arch/arm/mach-omap2/Kconfig  |5 ++
 arch/arm/mach-omap2/Makefile |2 +
 arch/arm/mach-omap2/board-am3517crane.c  |   69 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 77 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-am3517crane.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ab784bf..3688515 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -174,6 +174,11 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
 
+config MACH_CRANEBOARD
+   bool "AM3517/05 CRANE board"
+   depends on ARCH_OMAP3
+   select OMAP_PACKAGE_CBB
+
 config MACH_OMAP3_PANDORA
bool "OMAP3 Pandora"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b0810b9..d43bd33 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -174,6 +174,8 @@ obj-$(CONFIG_MACH_OMAP4_PANDA)  += 
board-omap4panda.o \
 
 obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
 
+obj-$(CONFIG_MACH_CRANEBOARD)  += board-am3517crane.o
+
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o \
   hsmmc.o
 # Platform specific device init code
diff --git a/arch/arm/mach-omap2/board-am3517crane.c 
b/arch/arm/mach-omap2/board-am3517crane.c
new file mode 100644
index 000..13ead33
--- /dev/null
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -0,0 +1,69 @@
+/*
+ * Support for AM3517/05 Craneboard
+ * http://www.mistralsolutions.com/products/craneboard.php
+ *
+ * Copyright (C) 2010 Mistral Solutions Pvt Ltd. 
+ * Author: R.Srinath 
+ *
+ * Based on mach-omap2/board-am3517evm.c
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as  published by the
+ * Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "mux.h"
+
+/* Board initialization */
+static struct omap_board_config_kernel am3517_crane_config[] __initdata = {
+};
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+   { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define board_mux  NULL
+#endif
+
+static void __init am3517_crane_init_irq(void)
+{
+   omap_board_config = am3517_crane_config;
+   omap_board_config_size = ARRAY_SIZE(am3517_crane_config);
+
+   omap2_init_common_hw(NULL, NULL);
+   omap_init_irq();
+   omap_gpio_init();
+}
+
+static void __init am3517_crane_init(void)
+{
+   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+   omap_serial_init();
+}
+
+MACHINE_START(CRANEBOARD, "AM3517/05 CRANEBOARD")
+   .boot_params= 0x8100,
+   .map_io = omap3_map_io,
+   .reserve= omap_reserve,
+   .init_irq   = am3517_crane_init_irq,
+   .init_machine   = am3517_crane_init,
+   .timer  = &omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 9036e37..229fbf2 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -145,6 +145,7 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* omap3 based boards using UART3 */
DEBUG_LL_OMAP3(3, cm_t35);
DEBUG_LL_OMAP3(3, cm_t3517);
+   DEBUG_LL_OMAP3(3, craneboard);
DEBUG_LL_OMAP3(3, igep0020);
DEBUG_LL_OMAP3(3, igep0030);
DEBUG_LL_OMAP3(3, nokia_rx51);
-- 
1.7.1.226.g770c5

--
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] hwmon: twl4030: Driver for twl4030 madc module

[J, KEERTHY]

Hello Anand,

-Original Message-
From: Gadiyar, Anand 
Sent: Tuesday, November 09, 2010 7:10 PM
To: J, KEERTHY; lm-sens...@lm-sensors.org; guenter.ro...@ericsson.com; 
sa...@linux.intel.com; kh...@linux-fr.org
Cc: mikko.k.yli...@nokia.com; Balbi, Felipe; amit.kuche...@canonical.com; 
linux-omap@vger.kernel.org; Krishnamoorthy, Balaji T
Subject: RE: [PATCH V2] hwmon: twl4030: Driver for twl4030 madc module

> Introducing a driver for MADC on TWL4030 powerIC. MADC stands for
monitoring
> ADC. This driver monitors the real time conversion of analog signals
like
> battery temperature, battery type, battery level etc. User can also ask
for
> the conversion on a particular channel using the sysfs nodes.
>
> Signed-off-by: Keerthy 

...


> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index a56f6ad..fef75f2 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC
>  help
>Support for the A/D converter on MC13783 PMIC.
>
> +config SENSORS_TWL4030_MADC
> + tristate

You need to provide some label text here, otherwise this option
will not show up in the kernel configuration tools, and hence
cannot be turned on or off from there.

Ok. I get it. I will add a label.

- Anand

Thanks,
Keerthy
--
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] hwmon: twl4030: Driver for twl4030 madc module

[Anand Gadiyar]

> Introducing a driver for MADC on TWL4030 powerIC. MADC stands for
monitoring
> ADC. This driver monitors the real time conversion of analog signals
like
> battery temperature, battery type, battery level etc. User can also ask
for
> the conversion on a particular channel using the sysfs nodes.
>
> Signed-off-by: Keerthy 

...


> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index a56f6ad..fef75f2 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC
>  help
>Support for the A/D converter on MC13783 PMIC.
>
> +config SENSORS_TWL4030_MADC
> + tristate

You need to provide some label text here, otherwise this option
will not show up in the kernel configuration tools, and hence
cannot be turned on or off from there.

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

Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver

[Tomi Valkeinen]

Hi,

On Mon, 2010-11-08 at 22:44 +0100, ext Bryan Wu wrote:
> Generic DPI panel driver includes the driver and 4 similar panel 
> configurations. It
> will match the panel name which is passed from platform data and setup the
> right configurations.
> 
> With generic DPI panel driver, we can remove those 4 duplicated panel display
> drivers. In the future, it is simple for us just add new panel configuration
> date in panel-generic-dpi.c to support new display panel.
> 
> Signed-off-by: Bryan Wu 
> ---
>  .../arm/plat-omap/include/plat/panel-generic-dpi.h |   31 ++
>  drivers/video/omap2/displays/Kconfig   |8 +
>  drivers/video/omap2/displays/Makefile  |1 +
>  drivers/video/omap2/displays/panel-generic-dpi.c   |  314 
> 
>  4 files changed, 354 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/plat-omap/include/plat/panel-generic-dpi.h
>  create mode 100644 drivers/video/omap2/displays/panel-generic-dpi.c
> 
> diff --git a/arch/arm/plat-omap/include/plat/panel-generic-dpi.h 
> b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
> new file mode 100644
> index 000..da50756
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/panel-generic-dpi.h
> @@ -0,0 +1,31 @@
> +/*
> + * Header for generic DPI panel driver
> + *
> + * Copyright (C) 2010 Canonical Ltd.
> + * Author: Bryan Wu 
> + *
> + * 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 __ARCH_ARM_PLAT_OMAP_GENERIC_DPI_PANEL_H
> +#define __ARCH_ARM_PLAT_OMAP_GENERIC_DPI_PANEL_H

Should be __ARCH_ARM_PLAT_OMAP_PANEL_GENERIC_DPI_H

> +
> +/**
> + * struct panel_data - panel driver configuration
> + * @name: panel name
> + */
> +struct generic_dpi_panel_data {

I think the struct name should be panel_generic_dpi_data.

> + const char *name;
> +};

Please add here also the fields platform_enable/disable and use them
instead of the ones in dssdev.

 Tomi


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

Re: [PATCH 1/3] OMAP: use generic panel data in board files

[Tomi Valkeinen]

On Mon, 2010-11-08 at 20:43 +0100, ext Bryan Wu wrote:
> On Mon, Nov 8, 2010 at 7:26 AM, Tomi Valkeinen  
> wrote:
> > Hi,
> >
> > On Fri, 2010-11-05 at 20:43 +0100, ext Bryan Wu wrote:

> >>  static struct omap_dss_device sdp3430_dvi_device = {
> >> .name   = "dvi",
> >> -   .driver_name= "generic_panel",
> >> -   .type   = OMAP_DISPLAY_TYPE_DPI,
> >> -   .phy.dpi.data_lines = 24,
> >
> > Why do you remove type and datalines configuration? You do this for the
> > other panels also.
> >
> 
> I found this is common in all the generic dpi panel, but the value
> depends on the specific panel. I move this to the panel configuration
> data and will set this value in panel-dpi driver. Do you think need I
> keep them here? Actually I found all of them are 24 for generic one.
> 16 or 18 for others.

Both type and .phy.dpi.data_lines tell about the connection to the
panel, not about the panel itself. Thus I think it's more consistent to
have them defined in the board file.

Also, it's really up to the board HW design how many lines are connected
from OMAP to the panel. You could connect only 16, for example, so it's
something that has to be defined in the board file.

 Tomi


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

Re: DSS2 Query: Use of FIFO preload values

[Tomi Valkeinen]

On Tue, 2010-11-09 at 05:20 +0100, ext Taneja, Archit wrote:
> Hi,
> 
> I was going through the DSS2 code and was unable to find a place
> where we set the 11th bit in DISPC_GFX_ATTRIBUTES or the 19th bit
> in DISPC_VIDn_ATTRIBUTES.
> 
> Setting these bits ensures that the DISPC FIFO's fill up to the
> high threshold value specified by us instead of the preload values.
> 
> Is this done on purpose or it got missed out?

A bit both. The TRM is quite unclear about fifo threshold and preload
configuration, and I've never understood how to configure them for
different interfaces. The current setup is mostly configured in such a
way that things seem to work =).

And if I recall right, even if the bits say that preload values are
used, changing the threshold values still broke things. So, as I said, I
never quite understood how they work.

 Tomi


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

[PATCH V2] hwmon: twl4030: Driver for twl4030 madc module

[Keerthy]

Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring
ADC. This driver monitors the real time conversion of analog signals like
battery temperature, battery type, battery level etc. User can also ask for
the conversion on a particular channel using the sysfs nodes.

Signed-off-by: Keerthy 
---

Several people have contributed to this driver on the linux-omap list.

V2:

Error path correction in probe function.
Return checks added.
the_madc pointer could not be removed. The external drivers will not be knowing
device information of the madc.
Added another function which takes the channel number alone and returns
the channel reading if the caller wants TWL4030_MADC_SW2 method for ADC 
conversion.
IOCTL function is removed.
Work struct is completely removed since request_threaded_irq is used.

 drivers/hwmon/Kconfig|6 +
 drivers/hwmon/Makefile   |1 +
 drivers/hwmon/twl4030-madc.c |  573 ++
 include/linux/i2c/twl4030-madc.h |  118 
 4 files changed, 698 insertions(+), 0 deletions(-)
 create mode 100644 drivers/hwmon/twl4030-madc.c
 create mode 100644 include/linux/i2c/twl4030-madc.h

V1:

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

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a56f6ad..fef75f2 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1171,6 +1171,12 @@ config SENSORS_MC13783_ADC
 help
   Support for the A/D converter on MC13783 PMIC.
 
+config SENSORS_TWL4030_MADC
+   tristate
+   depends on TWL4030_CORE
+   help
+ This driver provides support for TWL4030-MADC.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 2479b3d..a54af22 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_SENSORS_THMC50)+= thmc50.o
 obj-$(CONFIG_SENSORS_TMP102)   += tmp102.o
 obj-$(CONFIG_SENSORS_TMP401)   += tmp401.o
 obj-$(CONFIG_SENSORS_TMP421)   += tmp421.o
+obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc.o
 obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
 obj-$(CONFIG_SENSORS_VIA686A)  += via686a.o
 obj-$(CONFIG_SENSORS_VT1211)   += vt1211.o
diff --git a/drivers/hwmon/twl4030-madc.c b/drivers/hwmon/twl4030-madc.c
new file mode 100644
index 000..42f7d4a
--- /dev/null
+++ b/drivers/hwmon/twl4030-madc.c
@@ -0,0 +1,573 @@
+/*
+ *
+ * TWL4030 MADC module driver-This driver monitors the real time
+ * conversion of analog signals like battery temperature,
+ * battery type, battery level etc. User can also ask for the conversion on a
+ * particular channel using the sysfs nodes.
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * J Keerthy 
+ *
+ * Based on twl4030-madc.c
+ * Copyright (C) 2008 Nokia Corporation
+ * Mikko Ylinen 
+ *
+ * Amit Kucheria 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct twl4030_madc_data {
+   struct device *hwmon_dev;
+   struct mutex lock;
+   struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   int imr;
+   int isr;
+};
+
+static struct twl4030_madc_data *the_madc;
+
+static ssize_t madc_read(struct device *dev,
+struct device_attribute *devattr, char *buf)
+{
+   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+   struct twl4030_madc_request req;
+   int status;
+   long val;
+
+   req.channels = (1 << attr->index);
+   req.method = TWL4030_MADC_SW2;
+   req.func_cb = NULL;
+
+   val = twl4030_madc_conversion(&req);
+   if (likely(val >= 0))
+   val = req.rbuf[attr->index];
+   else
+   return val;
+   status = sprintf(buf, "%ld\n", val);
+   return status;
+}
+
+static
+const struct twl4030_madc_conversion_method twl4030_conversion_methods[] = {
+   [TWL4030_MADC_RT] = {
+.sel = TWL4030_MADC_RTSELECT_LSB,
+.avg = TWL4030_MADC_RTAVERAGE_LSB,
+.rbase = TWL4030_MADC_RTCH0_LSB,
+},
+   [TWL4030_MADC_SW1] = {
+

Re: [PATCH] arm: fix compilation warning during compilation

[Marco Stornelli]

2010/11/8 Gadiyar, Anand :
> 2010/11/8 Marco Stornelli :
>> 2010/11/8 Uwe Kleine-König :
>>> Hello,
>>>
>>> On Sat, Nov 06, 2010 at 10:06:35AM +0100, Marco Stornelli wrote:
 From: Marco Stornelli 

 During compilation of 2.6.36 for Beagle board, there a are a couple of 
 warnings. This patch fix them.
>>> Please break lines for commit logs at around 76 chars and mention the
>>> exact compiler warning being fixed.
>>>
>>
>> My compiler version is gcc 4.4.1. Two warning: variable gpio_mux may
>> be used not initialized (false positive, I agree); second: compiler
>> fix the void lack in the inline function with an int. Obviously there
>> is a lack of return type that it must be void.
>>
>
> Marco,
>
> Both of these are fixed in 2.6.37-rc1.
>
> Commits afc28bc0ec and ca828760f9 respectively.
>
> - Anand
>

Very good. Thanks.

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