Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Jassi Brar]

On 1 May 2012 02:47, Jon Hunter  wrote:
> From: Jon Hunter 
>
> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
> to add some basic helpers to retrieve a DMA controller device_node and the
> DMA request/channel information.
>
> Aim of DMA helpers
> - The purpose of device-tree (as far as I understand), is to describe the
>  capabilites of the hardware. Thinking about DMA controllers purely from the
>  context of the hardware to begin with, we can describe a device in terms of
>  a DMA controller as follows ...
>        1. Number of DMA controllers
>        2. Number of channels (maybe physical or logical)
>        3. Mapping of DMA requests signals to DMA controller
>        4. Number of DMA interrupts
>        5. Mapping of DMA interrupts to channels
> - With the above in mind the aim of the DT DMA helper functions is to extract
>  the above information from the DT and provide to the appropriate driver.
>  However, due to the vast number of DMA controllers and not all are using a
>  common driver (such as DMA Engine) it has been seen that this is not a
>  trivial task.
>
Sorry for being slow, but so far I thought DT is only to provide _h/w_
specific info
to the _controller_ drivers. It was not supposed to provide any info
pertaining to
some API (dmaengine in this case).

And I believe this is one of few situations where we are better off
not generalizing
the interface - pass controller specific info in the controller
driver's specified format.
Generalizing only seems to complicate things here, when we anyway have machine
specific dtb, which could always have clients requesting and the
controllers given
dma's info in controller driver's specific format.

Perhaps I am overlooking the need to generalize. If you think so, please help me
understand by pointing out some use case for it.

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

Re: [PATCH 2/2] ARM: OMAP4: DSS hwmods: Add OCPIF_SWSUP_IDLE to all DSS L3 slave interfaces

[Paul Walmsley]

Hi Archit,

On Fri, 13 Apr 2012, Archit Taneja wrote:

> On Friday 13 April 2012 02:13 PM, Cousson, Benoit wrote:
> > On 4/13/2012 10:01 AM, Archit Taneja wrote:
> > > The clock for all DSS L3 slave interfaces had been recently changed to
> > > "dss_fck" from "l3_div_ck". "dss_fck" is an optional clock in DSS
> > > clock domain
> > > which can't autoidle when enabled.
> > > 
> > > Add OCPIF_SWSUP_IDLE flag to all the L3 slave interfaces used by DSS
> > > hwmods so
> > > that clock is explicitly enabled and disabled by software. Without this,
> > > "dss_fck" would be left as enabled and the OMAP4 device won't idle
> > > even when
> > > DSS is not in use.
> > 
> > Yeah, that was done on purpose with Tomi knowning well that limitation.
> > 
> > The issue was mainly due to the lack of proper parent / child
> > relationship between the DSS (the whole subsystem) and the DSS children
> > at that time.
> > 
> > I think that Tomi posted a series to fix that for 3.4. So if we ensure
> > that every DSS IPs are children of the DSS, then pm_runtime will always
> > ensure that the DSS will be enabled each time a submodule is used.
> > 
> > So the right fix is to put back the proper iclk (l3_div) to the DSS
> > instead of the dss_fck.
> 
> Ok, I get it now. Tomi's patch series ensured the parent-child 
> dependency, but they didn't switch the iclks back to l3_div, I guess 
> that should be a part of the series too.

Just checking on this one.  Does this patch need to be updated ?


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

Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver

[Santosh Shilimkar]

On Friday 04 May 2012 05:33 AM, Greg KH wrote:
> On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote:
>> On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
>>  wrote:
>>> Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
>>
>> Hi Santosh,
>>
>> Can you send Greg a patch that adds proper dependencies to the Kconfig?
>> I was going to simply add an ARM dependency, but perhaps you want to
>> restrict it further to a subset of OMAP platforms?
>>
Thanks Paul for reporting the issue.

>> At the moment it is causing build failures in other architectures.
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/6243036/
> 
> I think there's a config option for readl/writel, but yes, ARM would
> probably be fine as well.
> 
Just send a patch [1] to Greg. EMIF driver build is restricted to
ARCH_OMAP2PLUS for now and can be extended later if any other
non OMAP architecture start using it.

Regards
Santosh

[1] https://lkml.org/lkml/2012/5/4/22
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
> 
> * Hiremath, Vaibhav  [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > > 
> > > On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
> > > 
> > > > From: Afzal Mohammed 
> > > > 
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > > 
> > > > Signed-off-by: Afzal Mohammed 
> > > > Signed-off-by: Vaibhav Hiremath 
> > > > Reviewed-by: Kevin Hilman 
> > > 
> > > I realize people may not necessarily like this, but I think that the 
> > > AM33xx EVM needs its own board file.  This is because it really has 
> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> 
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
> 
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>  

But still we do have ARCH_OMAP2, ARCH_OMAP3 and ARCH_OMAP4? And that's where, 
we have issues for adding new devices like AM33xx and TI81xx.

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

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Fri, May 04, 2012 at 01:07:32, Tony Lindgren wrote:
> * Hiremath, Vaibhav  [120503 09:45]:
> > 
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
> 
> Well are there components that could be used as is with that?
> If not, then it probably does not make sense.
> 

I am also in favor of not following cpu_is_omap34xx() for am33xx, but what 
about ARCH_OMAP?
I don't see that you are in agreement in creating ARCH_OMAPAM33XX. 
Does it make sense to say that, for am33xx, cpu_is_omap34xx() is false, but 
still it is under ARCH_OMAP3?


> BTW, you should post your patches on top of the clean-up patches
> Santosh posted as that already leaves out some cpu_is_omap
> checks. That's the "ARM: OMAP2+: Misc cleanup" thread.
> 

Ok. I will do that.

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

Re: [PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices

[Archit Taneja]

Hi,

On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:

Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.

Signed-off-by: Tomi Valkeinen
---
  arch/arm/mach-omap2/display.c |   88 ++---
  1 file changed, 74 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 07232fd..46d2a98 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, 
unsigned long tput)
return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
  }

+static struct platform_device *create_dss_pdev(const char *pdev_name,
+   int pdev_id, const char *oh_name, void *pdata, int pdata_len,
+   struct platform_device *parent)


This function looks quite generic, it's like omap_device_build() but 
with a parent associated. omap_device_build() seems to be a special case 
of this function with parent passed as null. Won't this

function be needed by other devices too?

Maybe we could modify omap_device_build_ss() to take a parent argument, 
and make a function called omap_device_build_parent(), where both 
omap_device_build() and omap_device_build_parent() call 
omap_device_build_ss()?


Archit


+{
+   struct platform_device *pdev;
+   struct omap_device *od;
+   struct omap_hwmod *ohs[1];
+   struct omap_hwmod *oh;
+   int r;
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh) {
+   pr_err("Could not look up %s\n", oh_name);
+   r = -ENODEV;
+   goto err;
+   }
+
+   pdev = platform_device_alloc(pdev_name, pdev_id);
+   if (!pdev) {
+   pr_err("Could not create pdev for %s\n", pdev_name);
+   r = -ENOMEM;
+   goto err;
+   }
+
+   if (parent != NULL)
+   pdev->dev.parent =&parent->dev;
+
+   if (pdev->id != -1)
+   dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
+   else
+   dev_set_name(&pdev->dev, "%s", pdev->name);
+
+   ohs[0] = oh;
+   od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
+   if (!od) {
+   pr_err("Could not alloc omap_device for %s\n", pdev_name);
+   r = -ENOMEM;
+   goto err;
+   }
+
+   r = platform_device_add_data(pdev, pdata, pdata_len);
+   if (r) {
+   pr_err("Could not set pdata for %s\n", pdev_name);
+   goto err;
+   }
+
+   r = omap_device_register(pdev);
+   if (r) {
+   pr_err("Could not register omap_device for %s\n", pdev_name);
+   goto err;
+   }
+
+   return pdev;
+
+err:
+   return ERR_PTR(r);
+}
+
  int __init omap_display_init(struct omap_dss_board_info *board_data)
  {
int r = 0;
-   struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
+   struct platform_device *dss_pdev;

/* create omapdss device */

@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}

-   for (i = 0; i<  oh_count; i++) {
-   oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
-   if (!oh) {
-   pr_err("Could not look up %s\n",
-   curr_dss_hwmod[i].oh_name);
-   return -ENODEV;
-   }
+   dss_pdev = NULL;

-   pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
-   curr_dss_hwmod[i].id, oh,
+   for (i = 0; i<  oh_count; i++) {
+   pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+   curr_dss_hwmod[i].id,
+   curr_dss_hwmod[i].oh_name,
NULL, 0,
-   NULL, 0, 0);
+   dss_pdev);
+
+   if (IS_ERR(pdev)) {
+   pr_err("Could not build omap_device for %s\n",
+   curr_dss_hwmod[i].oh_name);
+
+   return PTR_ERR(pdev);
+   }

-   if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
-   curr_dss_hwmod[i].oh_name))
-   return -ENODEV;
+   if (i == 0)
+   dss_pdev = pdev;
}

return 0;


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

Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

[Igor Grinberg]

Hi Russ,

On 05/03/12 22:08, Russ Dill wrote:
> On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj  wrote:
>> On Wed, May 2, 2012 at 2:17 PM, Russ Dill  wrote:
>>> On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj  
>>> wrote:
 On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
  wrote:
> From: Keshava Munegowda 
>
> It is observed that the echi ports of 3430 sdp board
> are not working due to the random timing of programming
> the associated GPIOs of the ULPI PHYs of the EHCI for reset.
> If the PHYs are reset at during usbhs core driver, host ports will
> not work because EHCI driver is loaded after the resetting PHYs.
> The PHYs should be in reset state while initializing the EHCI
> controller.
> The code which does the GPIO pins associated with the PHYs
> are programmed to reset is moved from the USB host core driver
> to EHCI driver.

 I tested on beagle xm where gpio nreset is requested from
 board file.
 (Basic enumertaion after gpio nreset seems to work fine,
 Hub and smsc lan chip get detected afetr boot up)

>>>
>>> What base did you test this on top of? my xM is failing USB-wise when
>>> I apply this on v3.3.3 (with the UART mux fix patch) and where it is
>>> applied within master (3.4-rc4, again, with the UART mux fix patch).
>>> Additionally, reverting this patch from 3.4-rc5 causes rc5 to work
>>> properly.
>>>
>>
>> Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch
>>
>> Logs as in here [1].
>>
>> --
>> Thanks,
>> Govindraj.R
>>
>> [1]:
>> http://pastebin.pandaboard.org/index.php/view/20343533
> 
> I've tracked down the difference. I'm loading my uEnv.txt and uImage
> in u-boot from the network which means initializing USB. You are
> loading straight from MMC. If I switch to loading straight from MMC
> everything works.
> 
> Can everyone do a 'usb start' in u-boot before booting and re-test?
> I'm pretty sure this is a regression, but the bug could be a strange
> u-boot/kernel interaction.

Probably, kernel code does not reinitialize EHCI correctly if it was already 
enabled?
Can you try the below sequence:
usb start
usb stop
boot Linux
?

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

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Fri, May 04, 2012 at 02:47:34, Hilman, Kevin wrote:
> "Hiremath, Vaibhav"  writes:
> 
> > On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> >> Hi,
> >> 
> >> * Hiremath, Vaibhav  [120502 02:37]:
> >> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> >> > > Hi
> >> > > 
> >> > > On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
> >> > > 
> >> > > > From: Afzal Mohammed 
> >> > > > 
> >> > > > This patch adds minimal support for AM335X EVM.
> >> > > > The approach taken here is to add AM335X EVM support
> >> > > > to AM3517EVM, considering the fact that with device tree
> >> > > > developement we will get rid of board-*.c.
> >> > > > 
> >> > > > Signed-off-by: Afzal Mohammed 
> >> > > > Signed-off-by: Vaibhav Hiremath 
> >> > > > Reviewed-by: Kevin Hilman 
> >> > > 
> >> > > I realize people may not necessarily like this, but I think that the 
> >> > > AM33xx EVM needs its own board file.  This is because it really has 
> >> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> >> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> >> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> >> 
> >> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> >> except core with omap3. And the SOC is independent of the core selected,
> >> there is no dependency between SoC and the core.
> >> 
> >> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> >> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> >> compile with different flags either.
> >>  
> >
> > What about cpu_is_omap34xx() true for am33xx? Should we follow it?
> 
> Please, no.
> 
> I've already demonstrated that that is not necessary and only leads to
> confusion and maintenance headaches.
> 

That's what I was expecting...

Probably last question where I have confusion,

Tony, seems to be against adding new ARCH_OMAPAM33XX, but which _ARCH_ we need 
to follow for AM33XX?
I have to choose between ARCH_OMAP3 or ARCH_OMAP4 and what should I choose 
here?

Does it make sense to follow ARCH_OMAPx but not follow cpu_is_omapxxx()?
OR
Should we create ARCH_AM, assuming that all AM devices have similar 
memory map layout, interrupt mapping, etc...
OR
Should I just add SOC_OMAPAM33XX, wherever required?


Also, there are lot of thing wrapped under ARCH_OMAP3 || ARCH_OMAP4 option, 
which is required for AM33XX, how should we handle this?

For example,

"arch/arm/plat-omap/include/plat/clock.h"
struct dpll_data {
#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)

#endif
};

"arch/arm/mach-omap2/clock.c"

#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)

const struct clkops clkops_omap3_noncore_dpll_ops = {
};
const struct clkops clkops_omap3_core_dpll_ops = {
}



--
To unsubscribe from this list: send the line "unsubscribe 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 08/25] OMAPDSS: clean up the omapdss platform data mess

[Archit Taneja]

Hi,

On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:

The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
   wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
   dss hwmods do not need the platform data. This should also work better
   for DT, as we can create omapdss device programmatically in generic omap
   boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
   that the dss hwmod drivers can call.

Signed-off-by: Tomi Valkeinen
---
  arch/arm/mach-omap2/display.c   |   39 +++
  drivers/video/omap2/dss/core.c  |   35 +++
  drivers/video/omap2/dss/dispc.c |   21 ++---
  drivers/video/omap2/dss/dsi.c   |   17 +++--
  drivers/video/omap2/dss/dss.h   |3 +++
  drivers/video/omap2/dss/hdmi.c  |2 --
  include/video/omapdss.h |5 -
  7 files changed, 62 insertions(+), 60 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 60cded4..07232fd 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
-   struct omap_display_platform_data pdata;
const struct omap_dss_hwmod_data *curr_dss_hwmod;

-   memset(&pdata, 0, sizeof(pdata));
+   /* create omapdss device */
+
+   board_data->dsi_enable_pads = omap_dsi_enable_pads;
+   board_data->dsi_disable_pads = omap_dsi_disable_pads;
+   board_data->get_context_loss_count = omap_pm_get_dev_context_loss_count;
+   board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
+
+   omap_display_device.dev.platform_data = board_data;
+
+   r = platform_device_register(&omap_display_device);
+   if (r<  0) {
+   pr_err("Unable to register omapdss device\n");
+   return r;
+   }


After this patch, the "omapdss" platform device is registered before the 
other dss platform devices. This would change the sequence of probes of 
these devices. Was this intentional?


Archit


+
+   /* create devices for dss hwmods */

if (cpu_is_omap24xx()) {
curr_dss_hwmod = omap2_dss_hwmod_data;
@@ -207,16 +221,6 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}

-   if (board_data->dsi_enable_pads == NULL)
-   board_data->dsi_enable_pads = omap_dsi_enable_pads;
-   if (board_data->dsi_disable_pads == NULL)
-   board_data->dsi_disable_pads = omap_dsi_disable_pads;
-
-   pdata.board_data = board_data;
-   pdata.board_data->get_context_loss_count =
-   omap_pm_get_dev_context_loss_count;
-   pdata.board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;
-
for (i = 0; i<  oh_count; i++) {
oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
if (!oh) {
@@ -226,21 +230,16 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
}

pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
-   curr_dss_hwmod[i].id, oh,&pdata,
-   sizeof(struct omap_display_platform_data),
+   curr_dss_hwmod[i].id, oh,
+   NULL, 0,
NULL, 0, 0);

if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
curr_dss_hwmod[i].oh_name))
return -ENODEV;
}
-   omap_display_device.dev.platform_data = board_data;

-   r = platform_device_register(&omap_display_device);
-   if (r<  0)
-   printk(KERN_ERR "Unable to register OMAP-Display device\n");
-
-   return r;
+   return 0;
  }

  static void dispc_disable_outputs(void)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 64cb8aa..b37b6f4 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -87,6 +87,41 @@ struct regulator *dss_get_vdds_sdi(void)
return reg;
  }

+int dss_get_ctx_loss_count(struct device *dev)
+{
+   struct omap_dss_board_info *board_data = core.pdev->dev.platform_data;
+   int cnt;
+
+   if (!board_data->get_context_loss_count)
+   return -ENOENT;
+
+   cnt = board_data->get_context_loss_count(dev);
+
+   WARN_ONCE(cnt<  0, "get_context_loss_count failed: %d\n", cnt);
+
+ 

Re: [PATCH 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.

[NeilBrown]

On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
 wrote:

> Why not simply managing the pending bit for level irqs ?
> 

Hi Thomas,
 thanks again for the patch.  I finally made time to test it and it works as
expected.  I've included it below with a change-log entry and tested-by:
in case that helps.

Thanks,
NeilBrown


From: Thomas Gleixner 
Date: Wed, 25 Apr 2012 12:54:54 +0200
Subject: [PATCH] IRQ: allow check_wakeup_irqs to notice level-triggered 
interrupts.

Level triggered interrupts do not cause IRQS_PENDING to be set when
they fire-while-disabled as the 'pending' state is always present in
the level - they automatically refire where re-enabled.

However the IRQS_PENDING flag is also used to abort a suspend cycle -
if any 'is_wakeup_set' interrupt is PENDING, check_wakeup_irqs() will
cause suspend to abort. Without IRQS_PENDING, suspend won't abort.

Consequently, level-triggered interrupts that fire during the 'noirq'
phase of suspend do not currently abort suspend.

So set IRQS_PENDING even for level triggered interrupts, and make sure
to clear the flag in check_irq_resend.

Also: in check_wakeup_irqs, ignore 'is_wakeup' interrupts that were
already disabled before suspend_device_irqs() disabled them further.

Tested-by: NeilBrown 

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6080f6b..741f836 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -379,8 +379,10 @@ handle_level_irq(unsigned int irq, struct irq_desc *desc)
 * If its disabled or no action available
 * keep it masked and get out of here
 */
-   if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data)))
+   if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
+   desc->istate |= IRQS_PENDING;
goto out_unlock;
+   }
 
handle_irq_event(desc);
 
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..b858ce3 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -103,7 +103,8 @@ int check_wakeup_irqs(void)
int irq;
 
for_each_irq_desc(irq, desc) {
-   if (irqd_is_wakeup_set(&desc->irq_data)) {
+   if (desc->depth == 1 &&
+   irqd_is_wakeup_set(&desc->irq_data)) {
if (desc->istate & IRQS_PENDING)
return -EBUSY;
continue;
diff --git a/kernel/irq/resend.c b/kernel/irq/resend.c
index 14dd576..6454db7 100644
--- a/kernel/irq/resend.c
+++ b/kernel/irq/resend.c
@@ -58,10 +58,13 @@ void check_irq_resend(struct irq_desc *desc, unsigned int 
irq)
/*
 * We do not resend level type interrupts. Level type
 * interrupts are resent by hardware when they are still
-* active.
+* active. Clear the pending bit so suspend/resume does not
+* get confused.
 */
-   if (irq_settings_is_level(desc))
+   if (irq_settings_is_level(desc)) {
+   desc->istate &= ~IRQS_PENDING;
return;
+   }
if (desc->istate & IRQS_REPLAY)
return;
if (desc->istate & IRQS_PENDING) {


signature.asc
Description: PGP signature

Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

[J, KEERTHY]

On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY  wrote:
> On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman  wrote:
>> Mark Brown  writes:
>>
>>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
 Mark Brown  writes:
>>>
 > But presumably these things should integrate somehow - for example,
 > should devfreq and cpufreq be providing inputs into what AVS is doing,
 > and if so how?
>>>
 The way it is currently designed, cpufreq/devfreq/regulator layers don't
 need to know about AVS.
>>>
>>> Yes, and that was a part of my concern, but see below.
>>>
 The higher-level layers only know about the "nominal" voltage.  AVS
 hardware does automatic, adaptive, micro-adjustments around that nominal
 voltage, and these micro-adjustments are managed by the AVS hardware
 sending commands to the PMIC.  (specifically, on OMAP, the AVS sensors
 provide inputs to the voltage processor (VP) which provide inputs to the
 voltage controller (VC) which sends commands to the PMIC[1].)
>>>
>>> Right, that's what I'd understood it to be.
>>>
 The driver proposed here is primarily for initializing the various
 parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
 adjustments are done in hardware by VC/VP.
>>>
>>> It's not just a driver, though - it's also creating this power/avs
>>> thing, though now I look at the code rather than just its shape there's
>>> not actually an abstraction being added here, it's mostly just straight
>>> code motion of the arch/arm code that's there already.  The changelog
>>> and the shape of the code make it sound like this is intended to be
>>> somewhat generic when really it's providing some OMAP specific tuning
>>> for the device which is much less of a concern.
>>>
>>> I guess for now it's probably OK to just clarify in the documentation
>>> and say that whoever adds the second driver has to work on making this
>>> generic :)
>>
>> Agreed.
>>
>> In a different thread (which I can't seem to find now) we discussed this
>> as well, so it just sounds like the changelog should clarify this a bit
>> better.
>
> Kevin/Mark,
>
> Thanks for the feedback. I will add more documentation
> to clarify this aspect. Please let me know if there are any more
> things to be taken care of in this patch set.

Hello Kevin,

A gentle ping on this series. Any comments on this?

>
>>
>> Kevin
>>
>>> This does also sound rather like it's in a similar area to the current
>>> management work which Durgadoss R (CCed) was working on, though with a
>>> slightly different application and in the OMAP case it's pretty much all
>>> hidden in the external processor.
>>
>
>
>
> --
> Regards and Thanks,
> Keerthy



-- 
Regards and 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:34 Thu 03 May , Stephen Warren wrote:
> On 05/03/2012 09:27 AM, Tony Lindgren wrote:
> > Hi,
> > 
> > * Jean-Christophe PLAGNIOL-VILLARD  [120503 00:16]:
> >>
> >>I really like it
> >>
> >>I was working on something simillar
> >>
> >>but can we split the group management so we can use it on other
> >>bindings
> > 
> > Hmm I'm not sure I follow on the group management splitting, can you specify
> > what you have in mind here?
> > 
> > If you mean moving more things into pinctrl fwk, then yeah I'd assume that
> > will happen eventually and drivers like this will end up becoming more 
> > minimal.
> 
> Jean-Christophe, forgive me if I'm putting words in your mouth, but I
> assume the following is what you mean:
> 
> There are two pieces of data required by the pinctrl subsystem:
> 
> a) The set of pins, functions, and groups that exist.
> 
> b) The specific function to select for each pin/group on a given board.
> 
> Item (a) can be represented in the pinctrl driver (e.g. as in the Tegra
> driver), or can be represented in device tree in order to avoid large
> tables in the driver.
> 
> Item (b) has to be represented in device tree, since the whole point is
> that it's board-specific.
> 
> For all DT bindings I've seen that choose to represent (a) in the DT
> rather than in the driver, the DT represents (b) directly, and (a) is
> implicitly extracted/created based on (a).
> 
> When I was first thinking about DT bindings for pinctrl, I had hoped
> that even if (a) was represented in DT, the DT nodes/properties for (a)
> and (b) would be entirely separate, so that the binding for (b) could be
> completely common across all SoCs, even though the binding for (a) would
> perhaps be different across SoCs (if it existed at all).
> 
> So, perhaps Jean-Christophe is talking about splitting up (a) and (b) in
> device tree?
> 
> Or perhaps Jean-Christophe only refers to the code that creates the
> group and function definitions from (b), and not the actual DT binding
> itself?
yes you are right Stephen
I was thinking of both but the second could be a first step

today we tend all to represent the group of pin in DT

for TI, IM, MXC, at91, ST and others

the way to represend the groups are exactly the same

a group is a node with a set on pin

uart {
 pincfg..
}

and the group is uart

so we do need to have a common way to handle it in c

the code propose by Tony is really what I'm working on to acheive this

In my mind in the driver we do not have to care how to list
register/unregister the group. We just need to be able to do this

pinctrl_register_group(...)

or 

pinctrl_unregistewr_group(...)

On at91 we have this type of controller

one pin can have multiple function and each function can be on different pin
and we need to program and represent each of them one by one

And each pin have different parameter

so I was thinking to do like on gpio

uart {
pin = < &pioA 12 {pararms} >

}

and use macro as basicaly we are just this

and this can be applied to tegra too as you will just refer the pin in this hw
pin block

Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe 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 07/10] arm: omap4430sdp: Add support for omap4iss camera

[Aguirre, Sergio]

Hi Sakari,

On Thu, May 3, 2012 at 7:03 AM, Aguirre, Sergio  wrote:
> Hi Sakari,
>
> Thanks for reviewing.
>
> On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus  wrote:
>>
>> Hi Sergio,
>>
>> Thanks for the patches!!
>>
>> On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
>> ...
>>> +static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
>>> +{
>>> +     struct device *dev = subdev->v4l2_dev->dev;
>>> +     int ret;
>>> +
>>> +     if (on) {
>>> +             if (!regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>>> +                     ret = regulator_enable(sdp4430_cam2pwr_reg);
>>> +                     if (ret) {
>>> +                             dev_err(dev,
>>> +                                     "Error in enabling sensor power 
>>> regulator 'cam2pwr'\n");
>>> +                             return ret;
>>> +                     }
>>> +
>>> +                     msleep(50);
>>> +             }
>>> +
>>> +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 1);
>>> +             msleep(10);
>>> +             ret = clk_enable(sdp4430_cam1_aux_clk); /* Enable XCLK */
>>> +             if (ret) {
>>> +                     dev_err(dev,
>>> +                             "Error in clk_enable() in %s(%d)\n",
>>> +                             __func__, on);
>>> +                     gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>>> +                     return ret;
>>> +             }
>>> +             msleep(10);
>>> +     } else {
>>> +             clk_disable(sdp4430_cam1_aux_clk);
>>> +             msleep(1);
>>> +             gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_B, 0);
>>> +             if (regulator_is_enabled(sdp4430_cam2pwr_reg)) {
>>> +                     ret = regulator_disable(sdp4430_cam2pwr_reg);
>>> +                     if (ret) {
>>> +                             dev_err(dev,
>>> +                                     "Error in disabling sensor power 
>>> regulator 'cam2pwr'\n");
>>> +                             return ret;
>>> +                     }
>>> +             }
>>> +     }
>>> +
>>> +     return 0;
>>> +}
>>
>> Isn't this something that should be part of the sensor driver? There's
>> nothing in the above code that would be board specific, except the names of
>> the clocks, regulators and GPIOs. The sensor driver could hold the names
>> instead; this would be also compatible with the device tree.
>
> Agreed. I see what you mean...
>
> I'll take care of that.

Can you please check out these patches?

1. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/cb6c10d58053180364461e6bc8d30d1ec87e6e22
2. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/6732e0db25c6647b34ef8f01c244a49a1fd6b45d
3. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/d61c4e3142dc9cae972f9128fe73d986838c0ca1
4. 
http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera/commit/e83f36001c7f7cbe184ad094d9b0c95c39e5028f

I want to see if I got your point properly...

Regards,
Sergio

>
>>
>> It should be possible to have s_power() callback NULL, too.
>>
>>> +static int sdp4430_ov_cam2_power(struct v4l2_subdev *subdev, int on)
>>> +{
>>> +     struct device *dev = subdev->v4l2_dev->dev;
>>> +     int ret;
>>> +
>>> +     if (on) {
>>> +             u8 gpoctl = 0;
>>> +
>>> +             ret = regulator_enable(sdp4430_cam2pwr_reg);
>>> +             if (ret) {
>>> +                     dev_err(dev,
>>> +                             "Error in enabling sensor power regulator 
>>> 'cam2pwr'\n");
>>> +                     return ret;
>>> +             }
>>> +
>>> +             msleep(50);
>>> +
>>> +             if (twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, &gpoctl,
>>> +                                 TWL6040_REG_GPOCTL))
>>> +                     return -ENODEV;
>>> +             if (twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE,
>>> +                                  gpoctl | TWL6040_GPO3,
>>> +                                  TWL6040_REG_GPOCTL))
>>> +                     return -ENODEV;
>>
>> The above piece of code looks quite interesting. What does it do?
>
> Well, this is because the camera adapter board in 4430SDP has 3
> sensors actually:
>
> - 1 Sony IMX060 12.1 MP sensor
> - 2 OmniVision OV5650 sensors
>
> And there's 3 wideband analog switches, like this:
>
> http://www.analog.com/static/imported-files/data_sheets/ADG936_936R.pdf
>
> That basically select either IMX060 or OV5650 for CSI2A input.
>
> So, this commands are because the TWL6040 chip has a GPO pin to toggle
> this, instead
> of an OMAP GPIO (Don't ask me why :) )
>
> Anyways... I see your point, maybe this should be explained better
> through a comment.
>
> Regards,
> Sergio
>>
>> Kind regards,
>>
>> --
>> Sakari Ailus
>> e-mail: sakari.ai...@iki.fi     jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] ARM: OMAP: Add platform devices for ASoC HDMI drivers

[Ricardo Neri]

Hi Tony,

This is me again; asking if you had any chance to look at these patches.

Thanks!

Ricardo
On 04/25/2012 06:29 PM, Ricardo Neri wrote:

Hi Tony,

I was wondering if you've had the time to take a look at these patches.

Thanks!

Ricardo
On 04/17/2012 07:40 PM, Ricardo Neri wrote:

This set of patches is intended to add the platform devices for the ASoC
HDMI drivers when not using device tree. For this, I took an approach
similar
to DMIC and McPDM by creating a dedicated functions to create the
devices.

I included the device for the CPU DAI driver, omap-hdmi-audio-dai, and
the
device for the machine driver, omap-hdmi-audio, in devices.c to
reflect the
fact that any OMAP4 (and OMAP5 in the future) has HDMI IP. I put the
device
for the codec in the board file to reflect the fact that not
necessarily all
the boards with OMAP4/5 have the HDMI output wired.

Best regards

Ricardo

Ricardo Neri (3):
ARM: OMAP: devices: Register platform devices for HDMI audio
ARM: OMAP4: board-4430sdp: Register platform device for HDMI audio
codec
ARM: OMAP4: board-omap4panda: Register platform device for HDMI audio
codec

arch/arm/mach-omap2/board-4430sdp.c | 6 ++
arch/arm/mach-omap2/board-omap4panda.c | 6 ++
arch/arm/mach-omap2/devices.c | 31 +++
3 files changed, 43 insertions(+), 0 deletions(-)





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

[PATCH v2 00/14] OMAPDSS: HDMI: Prepare for DSS dev driver audio support and OMAP5

[Ricardo Neri]

Hi,

This set of patches is intended to prepare the HDMI driver to implement the DSS
device driver interface for audio proposed here:
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67804.html

In preparation for that, it removes the current ASoC HDMI codec driver and
decouples HDMI audio build configuration from ASoC. Instead, a config option
may be selected by the parties interested in the HDMI audio functionality. While
the ASoC HDMI codec is removed, HDMI audio functionality restored in the last
patch of the series in the form of DSS audio support.

Also, this set prepares the HDMI driver for the introduction of the OMAP5 HDMI
audio functionality by further abstracting the portions of code that are
generic to all HDMI implementations (e.g, N/CTS params calculation). Also, an
IP-dependent audio configuration function is introduced as an HDMI IP operation;
this function takes IP-independent parameters and applies them as required by
the IP.

For the specific case of OMAP4, the configuration of the IEC-60958 channel
status word is expanded to provide more flexibility. Also, some duplicated
IEC-60958 definitions are removed to, instead, reuse the definitions provided
by ALSA. Please note that this patches depend on the following patch adding
CEA-861 definitions:
  http://www.spinics.net/lists/linux-omap/msg68246.html.
Without such patch, the patches in this series will not compile.

The changes for OMAP4 configuration expand the current support to cover more
audio sample rates: 32, 44.1, 48, 88.2, 176.4 and 192 kHz. Audio sample world
length of 16 through 24 bits as well as up to 8 audio channels.

These changes are based on the 3.4-rc5 kernel.

Validation was performed using Onkyo TX-SR508 and Yamaha RX-V367 AV receivers.

These are the changes with respect to v1:
*The DSS dev driver audio operations are, at the moment, protected using a
 hardirq-safe spinlock. Except for the audio_start/stop functions, it was
 concluded that a mutex could be used in the future is needed.
*In audio configuration, instead of parsing the IEC-60958 channel status word,
 and setting bits individually, the word is passed directly to the IP. This
 saves code, makes it more readable and fully configurable by the user.
*Split HDMI video_enable, audio_enable and audio_start into two separate
 functions to enable/disable and start/stop. Also, update their return values.
*Audio channels are remapped to match the order preferred by ALSA's 
speaker-test.
*Remove OMAP4 HDMI IP configuration regarding High Bitrate audio and I2S
 word select polarity, as this is not supported according to updated TI's
 documentation.
*Rename the lock of the HDMI panel.
*Remove unneeded header files.
*Rephrase the description of several patches.

BR,

Ricardo

Axel Castaneda Gonzalez (1):
  OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop

Ricardo Neri (13):
  OMAPDSS: HDMI: Split audio_enable into audio_enable/disable
  OMAPDSS: HDMI: Split video_enable into video_enable/disable
  OMAPDSS: HDMI: Remove ASoC codec
  OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958
enums
  OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
  OMAPDSS: HDMI: Decouple HDMI audio from ASoC
  OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
  OMAPDSS: HDMI: Relocate N/CTS calculation
  OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS
calculation
  OMAPDSS: HDMI: Add an audio configuration function
  OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
  OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
  OMAPDSS: HDMI: Implement DSS driver interface for audio

 drivers/video/omap2/dss/Kconfig   |4 +
 drivers/video/omap2/dss/dss.h |8 +
 drivers/video/omap2/dss/dss_features.c|8 +-
 drivers/video/omap2/dss/hdmi.c|  355 +++--
 drivers/video/omap2/dss/hdmi_panel.c  |  141 ++--
 drivers/video/omap2/dss/ti_hdmi.h |   32 ++-
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |  316 +++--
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |  104 +-
 8 files changed, 537 insertions(+), 431 deletions(-)

-- 
1.7.5.4

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

[PATCH v2 06/14] OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop

[Ricardo Neri]

From: Axel Castaneda Gonzalez 

Decouple the enable/disable operation of the HDMI audio wrapper from
audio start/stop. Otherwise, an audio FIFO underflow may occur. The
audio wrapper enablement must be done after configuration and
before audio playback is started.

Signed-off-by: Axel Castaneda Gonzalez 
Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/dss_features.c|2 ++
 drivers/video/omap2/dss/ti_hdmi.h |6 ++
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   19 ++-
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index c677095..8005128 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -571,6 +571,8 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
.audio_enable   =   ti_hdmi_4xxx_wp_audio_enable,
.audio_disable  =   ti_hdmi_4xxx_wp_audio_disable,
+   .audio_start=   ti_hdmi_4xxx_audio_start,
+   .audio_stop =   ti_hdmi_4xxx_audio_stop,
 #endif
 
 };
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 4c84a9c..8afdd0b 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -113,6 +113,10 @@ struct ti_hdmi_ip_ops {
int (*audio_enable)(struct hdmi_ip_data *ip_data);
 
void (*audio_disable)(struct hdmi_ip_data *ip_data);
+
+   int (*audio_start)(struct hdmi_ip_data *ip_data);
+
+   void (*audio_stop)(struct hdmi_ip_data *ip_data);
 #endif
 
 };
@@ -190,5 +194,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s);
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
 int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data);
+int ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data);
+void ti_hdmi_4xxx_audio_stop(struct hdmi_ip_data *ip_data);
 #endif
 #endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 985caf9..12c21d3 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1256,22 +1256,31 @@ int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
 
 int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data)
 {
-   REG_FLD_MOD(hdmi_av_base(ip_data),
-   HDMI_CORE_AV_AUD_MODE, true, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
HDMI_WP_AUDIO_CTRL, true, 31, 31);
+   return 0;
+}
+
+void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data)
+{
+   REG_FLD_MOD(hdmi_wp_base(ip_data),
+   HDMI_WP_AUDIO_CTRL, false, 31, 31);
+}
+
+int ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data)
+{
+   REG_FLD_MOD(hdmi_av_base(ip_data),
+   HDMI_CORE_AV_AUD_MODE, true, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
HDMI_WP_AUDIO_CTRL, true, 30, 30);
return 0;
 }
 
-void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data)
+void ti_hdmi_4xxx_audio_stop(struct hdmi_ip_data *ip_data)
 {
REG_FLD_MOD(hdmi_av_base(ip_data),
HDMI_CORE_AV_AUD_MODE, false, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
-   HDMI_WP_AUDIO_CTRL, false, 31, 31);
-   REG_FLD_MOD(hdmi_wp_base(ip_data),
HDMI_WP_AUDIO_CTRL, false, 30, 30);
 }
 #endif
-- 
1.7.5.4

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

[PATCH v2 04/14] OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums

[Ricardo Neri]

Instead of having its own definitions for CEA-861 and IEC-60958, the HDMI
driver should use those provided by ALSA. This patch removes the definitions
that are already provided by ALSA.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   34 ++--
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |   81 +
 2 files changed, 20 insertions(+), 95 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index aa18163..ac73309 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -29,6 +29,10 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
+   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#include 
+#endif
 
 #include "ti_hdmi_4xxx_ip.h"
 #include "dss.h"
@@ -1147,9 +1151,8 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
 }
 
 void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
-   struct hdmi_core_infoframe_audio *info_aud)
+   struct snd_cea_861_aud_if *info_aud)
 {
-   u8 val;
u8 sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
 
@@ -1163,24 +1166,23 @@ void hdmi_core_audio_infoframe_config(struct 
hdmi_ip_data *ip_data,
hdmi_write_reg(av_base, HDMI_CORE_AV_AUDIO_LEN, 0x0a);
sum += 0x84 + 0x001 + 0x00a;
 
-   val = (info_aud->db1_coding_type << 4)
-   | (info_aud->db1_channel_count - 1);
-   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(0), val);
-   sum += val;
+   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(0),
+  info_aud->db1_ct_cc);
+   sum += info_aud->db1_ct_cc;
 
-   val = (info_aud->db2_sample_freq << 2) | info_aud->db2_sample_size;
-   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(1), val);
-   sum += val;
+   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(1),
+  info_aud->db2_sf_ss);
+   sum += info_aud->db2_sf_ss;
 
-   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(2), 0x00);
+   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(2), info_aud->db3);
+   sum += info_aud->db3;
 
-   val = info_aud->db4_channel_alloc;
-   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(3), val);
-   sum += val;
+   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(3), info_aud->db4_ca);
+   sum += info_aud->db4_ca;
 
-   val = (info_aud->db5_downmix_inh << 7) | (info_aud->db5_lsv << 3);
-   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(4), val);
-   sum += val;
+   hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(4),
+  info_aud->db5_dminh_lsv);
+   sum += info_aud->db5_dminh_lsv;
 
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(5), 0x00);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(6), 0x00);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a5f28af..26b91ff 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -279,35 +279,6 @@ enum hdmi_core_infoframe {
HDMI_INFOFRAME_AVI_DB5PR_8 = 7,
HDMI_INFOFRAME_AVI_DB5PR_9 = 8,
HDMI_INFOFRAME_AVI_DB5PR_10 = 9,
-   HDMI_INFOFRAME_AUDIO_DB1CT_FROM_STREAM = 0,
-   HDMI_INFOFRAME_AUDIO_DB1CT_IEC60958 = 1,
-   HDMI_INFOFRAME_AUDIO_DB1CT_AC3 = 2,
-   HDMI_INFOFRAME_AUDIO_DB1CT_MPEG1 = 3,
-   HDMI_INFOFRAME_AUDIO_DB1CT_MP3 = 4,
-   HDMI_INFOFRAME_AUDIO_DB1CT_MPEG2_MULTICH = 5,
-   HDMI_INFOFRAME_AUDIO_DB1CT_AAC = 6,
-   HDMI_INFOFRAME_AUDIO_DB1CT_DTS = 7,
-   HDMI_INFOFRAME_AUDIO_DB1CT_ATRAC = 8,
-   HDMI_INFOFRAME_AUDIO_DB1CT_ONEBIT = 9,
-   HDMI_INFOFRAME_AUDIO_DB1CT_DOLBY_DIGITAL_PLUS = 10,
-   HDMI_INFOFRAME_AUDIO_DB1CT_DTS_HD = 11,
-   HDMI_INFOFRAME_AUDIO_DB1CT_MAT = 12,
-   HDMI_INFOFRAME_AUDIO_DB1CT_DST = 13,
-   HDMI_INFOFRAME_AUDIO_DB1CT_WMA_PRO = 14,
-   HDMI_INFOFRAME_AUDIO_DB2SF_FROM_STREAM = 0,
-   HDMI_INFOFRAME_AUDIO_DB2SF_32000 = 1,
-   HDMI_INFOFRAME_AUDIO_DB2SF_44100 = 2,
-   HDMI_INFOFRAME_AUDIO_DB2SF_48000 = 3,
-   HDMI_INFOFRAME_AUDIO_DB2SF_88200 = 4,
-   HDMI_INFOFRAME_AUDIO_DB2SF_96000 = 5,
-   HDMI_INFOFRAME_AUDIO_DB2SF_176400 = 6,
-   HDMI_INFOFRAME_AUDIO_DB2SF_192000 = 7,
-   HDMI_INFOFRAME_AUDIO_DB2SS_FROM_STREAM = 0,
-   HDMI_INFOFRAME_AUDIO_DB2SS_16BIT = 1,
-   HDMI_INFOFRAME_AUDIO_DB2SS_20BIT = 2,
-   HDMI_INFOFRAME_AUDIO_DB2SS_24BIT = 3,
-   HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PERMITTED = 0,
-   HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PROHIBITED = 1
 };
 
 enum hdmi_packing_mode {
@@ -317,17 +288,6 @@ enum hdmi_packing_mode {
HDMI_PACK_ALREADYPACKED = 7
 };
 
-enum hdmi_core_audio_sample_freq {
-   HDMI_AUDIO_FS_32000 = 0x3,
-   HDMI_AUDIO_FS_44100 = 0x0,
-   HDMI_AUDIO_FS_48000 = 0x2,
-   HDMI_AUD

[PATCH v2 07/14] OMAPDSS: HDMI: Decouple HDMI audio from ASoC

[Ricardo Neri]

Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/Kconfig   |4 
 drivers/video/omap2/dss/dss_features.c|3 +--
 drivers/video/omap2/dss/ti_hdmi.h |6 ++
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |6 ++
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |3 +--
 5 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 7be7c06..b492001 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -68,6 +68,10 @@ config OMAP4_DSS_HDMI
  HDMI Interface. This adds the High Definition Multimedia Interface.
  See http://www.hdmi.org/ for HDMI specification.
 
+config OMAP4_DSS_HDMI_AUDIO
+   bool
+   depends on OMAP4_DSS_HDMI
+
 config OMAP2_DSS_SDI
bool "SDI support"
depends on ARCH_OMAP3
diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 8005128..508cc4a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -567,8 +567,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core  =   ti_hdmi_4xxx_core_dump,
.dump_pll   =   ti_hdmi_4xxx_pll_dump,
.dump_phy   =   ti_hdmi_4xxx_phy_dump,
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
.audio_enable   =   ti_hdmi_4xxx_wp_audio_enable,
.audio_disable  =   ti_hdmi_4xxx_wp_audio_disable,
.audio_start=   ti_hdmi_4xxx_audio_start,
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 8afdd0b..6aedb89 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,8 +108,7 @@ struct ti_hdmi_ip_ops {
 
void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
int (*audio_enable)(struct hdmi_ip_data *ip_data);
 
void (*audio_disable)(struct hdmi_ip_data *ip_data);
@@ -190,8 +189,7 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s);
 void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
 void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
 void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data);
 int ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 12c21d3..cbda730 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -29,8 +29,7 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 #include 
 #endif
 
@@ -1026,8 +1025,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s)
DUMPPHY(HDMI_TXPHY_PAD_CFG_CTRL);
 }
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt)
 {
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 40b724c..5d6e37a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -440,8 +440,7 @@ struct hdmi_core_audio_config {
boolen_spdif;
 };
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
u32 sample_freq, u32 *n, u32 *cts);
 void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
-- 
1.7.5.4

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

[PATCH v2 10/14] OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation

[Ricardo Neri]

Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.

Also, reorganize the logic for the calculation when using deep color.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/hdmi.c |   88 +--
 1 files changed, 74 insertions(+), 14 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 2a810b7..aee0acf 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -577,6 +577,7 @@ static void hdmi_put_clocks(void)
 int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
 {
u32 deep_color;
+   bool deep_color_correct = false;
u32 pclk = hdmi.ip_data.cfg.timings.pixel_clock;
 
if (n == NULL || cts == NULL)
@@ -585,29 +586,88 @@ int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
/* TODO: When implemented, query deep color mode here. */
deep_color = 100;
 
+   /*
+* When using deep color, the default N value (as in the HDMI
+* specification) yields to an non-integer CTS. Hence, we
+* modify it while keeping the restrictions described in
+* section 7.2.1 of the HDMI 1.4a specification.
+*/
switch (sample_freq) {
case 32000:
-   if ((deep_color == 125) && ((pclk == 54054) ||
-   (pclk == 74250)))
-   *n = 8192;
-   else
-   *n = 4096;
+   case 48000:
+   case 96000:
+   case 192000:
+   if (deep_color == 125)
+   if (pclk == 27027 || pclk == 74250)
+   deep_color_correct = true;
+   if (deep_color == 150)
+   if (pclk == 27027)
+   deep_color_correct = true;
break;
case 44100:
-   *n = 6272;
-   break;
-   case 48000:
-   if ((deep_color == 125) && ((pclk == 54054) ||
-   (pclk == 74250)))
-   *n = 8192;
-   else
-   *n = 6144;
+   case 88200:
+   case 176400:
+   if (deep_color == 125)
+   if (pclk == 27027)
+   deep_color_correct = true;
break;
default:
-   *n = 0;
return -EINVAL;
}
 
+   if (deep_color_correct) {
+   switch (sample_freq) {
+   case 32000:
+   *n = 8192;
+   break;
+   case 44100:
+   *n = 12544;
+   break;
+   case 48000:
+   *n = 8192;
+   break;
+   case 88200:
+   *n = 25088;
+   break;
+   case 96000:
+   *n = 16384;
+   break;
+   case 176400:
+   *n = 50176;
+   break;
+   case 192000:
+   *n = 32768;
+   break;
+   default:
+   return -EINVAL;
+   }
+   } else {
+   switch (sample_freq) {
+   case 32000:
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   *n = 6144;
+   break;
+   case 88200:
+   *n = 12544;
+   break;
+   case 96000:
+   *n = 12288;
+   break;
+   case 176400:
+   *n = 25088;
+   break;
+   case 192000:
+   *n = 24576;
+   break;
+   default:
+   return -EINVAL;
+   }
+   }
/* Calculate CTS. See HDMI 1.3a or 1.4a specifications */
*cts = pclk * (*n / 128) * deep_color / (sample_freq / 10);
 
-- 
1.7.5.4

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

[PATCH v2 11/14] OMAPDSS: HDMI: Add an audio configuration function

[Ricardo Neri]

The generic HDMI driver does not need to know about the specific
settings of a given IP. Hence, it just passes the audio configuration
and the IP library parses such configuration and sets the IP
accordingly. This patch introduces an IP-specific audio configuration
function.

Also, this patch implements the audio config function for OMAP4. The
DMA, format and core config functions are no longer exposed to the
generic HDMI driver as they are IP-specific.

The audio configuration function caters for 16-bit through 24-bit
audio samples with sample rates from 32kHz and up to 192kHz as well
as up to 8 audio channels.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/dss_features.c|1 +
 drivers/video/omap2/dss/ti_hdmi.h |5 +
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |  189 -
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |   10 --
 4 files changed, 191 insertions(+), 14 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 508cc4a..bff51a0 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -572,6 +572,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.audio_disable  =   ti_hdmi_4xxx_wp_audio_disable,
.audio_start=   ti_hdmi_4xxx_audio_start,
.audio_stop =   ti_hdmi_4xxx_audio_stop,
+   .audio_config   =   ti_hdmi_4xxx_audio_config,
 #endif
 
 };
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 852a803..e734cb4 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -116,6 +116,9 @@ struct ti_hdmi_ip_ops {
int (*audio_start)(struct hdmi_ip_data *ip_data);
 
void (*audio_stop)(struct hdmi_ip_data *ip_data);
+
+   int (*audio_config)(struct hdmi_ip_data *ip_data,
+   struct omap_dss_audio *audio);
 #endif
 
 };
@@ -195,5 +198,7 @@ int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data 
*ip_data);
 void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data);
 int ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_audio_stop(struct hdmi_ip_data *ip_data);
+int ti_hdmi_4xxx_audio_config(struct hdmi_ip_data *ip_data,
+   struct omap_dss_audio *audio);
 #endif
 #endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 5612534..74d9420 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -31,10 +31,12 @@
 #include 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 #include 
+#include 
 #endif
 
 #include "ti_hdmi_4xxx_ip.h"
 #include "dss.h"
+#include "dss_features.h"
 
 static inline void hdmi_write_reg(void __iomem *base_addr,
const u16 idx, u32 val)
@@ -1026,7 +1028,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s)
 }
 
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt)
 {
u32 r;
@@ -1045,7 +1047,7 @@ void hdmi_wp_audio_config_format(struct hdmi_ip_data 
*ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG, r);
 }
 
-void hdmi_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
struct hdmi_audio_dma *aud_dma)
 {
u32 r;
@@ -1063,7 +1065,7 @@ void hdmi_wp_audio_config_dma(struct hdmi_ip_data 
*ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CTRL, r);
 }
 
-void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_core_audio_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_audio_config *cfg)
 {
u32 r;
@@ -1154,7 +1156,7 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_MODE, r);
 }
 
-void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
+static void ti_hdmi_4xxx_core_audio_infoframe_cfg(struct hdmi_ip_data *ip_data,
struct snd_cea_861_aud_if *info_aud)
 {
u8 sum = 0, checksum = 0;
@@ -1204,6 +1206,185 @@ void hdmi_core_audio_infoframe_config(struct 
hdmi_ip_data *ip_data,
 */
 }
 
+int ti_hdmi_4xxx_audio_config(struct hdmi_ip_data *ip_data,
+   struct omap_dss_audio *audio)
+{
+   struct hdmi_audio_format audio_format;
+   struct hdmi_audio_dma audio_dma;
+   struct hdmi_core_audio_config core;
+   int err, n, cts, channel_count;
+   unsigned int fs_nr;
+   bool word_length_16b = false;
+
+   if (!audio || !audio->iec || !audio->cea || !ip_data)
+   r

[PATCH v2 12/14] OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order

[Ricardo Neri]

As of today, the only know user of the DSS HDMI audio support is
ASoC. Hence, it makes sense to remap the speaker order to match
the ALSA speaker order. In the future, a dynamic mapping mechanism
may be implemented.

Remapping is needed as the HDMI speaker order is FL/FR/LFE/C/RL/RR/
RLC-FLC/RRC-FLC while the ALSA order is FL/FR/RL/RR/C/LFE/SL/SR.
Refer to CEA-861 Section 6.6.2 for further details.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 74d9420..4dcdbbb 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1154,6 +1154,14 @@ static void ti_hdmi_4xxx_core_audio_config(struct 
hdmi_ip_data *ip_data,
r = FLD_MOD(r, cfg->en_parallel_aud_input, 2, 2);
r = FLD_MOD(r, cfg->en_spdif, 1, 1);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_MODE, r);
+
+   /* Audio channel mappings */
+   /* TODO: Make channel mapping dynamic. For now, map channels
+* in the ALSA order: FL/FR/RL/RR/C/LFE/SL/SR. Remapping is needed as
+* HDMI speaker order is different. See CEA-861 Section 6.6.2.
+*/
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_IN_MAP, 0x78);
+   REG_FLD_MOD(av_base, HDMI_CORE_AV_SWAP_I2S, 1, 5, 5);
 }
 
 static void ti_hdmi_4xxx_core_audio_infoframe_cfg(struct hdmi_ip_data *ip_data,
-- 
1.7.5.4

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

[PATCH v2 05/14] OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings

[Ricardo Neri]

According to the most up-to-date documentation from Texas Instruments,
the configuration of High Bitrate Audio is not possible. Also, it is
not possible to set polarity of the I2S Word Select signal. This patch
removes the invalid settings.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |3 ---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |5 -
 2 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ac73309..985caf9 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1121,11 +1121,8 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
cfg->freq_sample, 3, 0);
 
r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_IN_CTRL);
-   r = FLD_MOD(r, cfg->i2s_cfg.en_high_bitrate_aud, 7, 7);
r = FLD_MOD(r, cfg->i2s_cfg.sck_edge_mode, 6, 6);
-   r = FLD_MOD(r, cfg->i2s_cfg.cbit_order, 5, 5);
r = FLD_MOD(r, cfg->i2s_cfg.vbit, 4, 4);
-   r = FLD_MOD(r, cfg->i2s_cfg.ws_polarity, 3, 3);
r = FLD_MOD(r, cfg->i2s_cfg.justification, 2, 2);
r = FLD_MOD(r, cfg->i2s_cfg.direction, 1, 1);
r = FLD_MOD(r, cfg->i2s_cfg.shift, 0, 0);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 26b91ff..40b724c 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -342,8 +342,6 @@ enum hdmi_audio_blk_strt_end_sig {
 };
 
 enum hdmi_audio_i2s_config {
-   HDMI_AUDIO_I2S_WS_POLARITY_LOW_IS_LEFT = 0,
-   HDMI_AUDIO_I2S_WS_POLARIT_YLOW_IS_RIGHT = 1,
HDMI_AUDIO_I2S_MSB_SHIFTED_FIRST = 0,
HDMI_AUDIO_I2S_LSB_SHIFTED_FIRST = 1,
HDMI_AUDIO_I2S_SCK_EDGE_FALLING = 0,
@@ -418,11 +416,8 @@ struct hdmi_core_audio_i2s_config {
u8 word_length;
u8 in_length_bits;
u8 justification;
-   u8 en_high_bitrate_aud;
u8 sck_edge_mode;
-   u8 cbit_order;
u8 vbit;
-   u8 ws_polarity;
u8 direction;
u8 shift;
u8 active_sds;
-- 
1.7.5.4

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

[PATCH v2 13/14] OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex

[Ricardo Neri]

As the hdmi_lock mutex is inside the hdmi struct, rename to simply
"lock". This is only a change in the name. There are not changes
in functionality.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/hdmi_panel.c |   41 +
 1 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi_panel.c 
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..5e215d6 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -30,7 +30,8 @@
 #include "dss.h"
 
 static struct {
-   struct mutex hdmi_lock;
+   /* This protects the panel ops, mainly when accessing the HDMI IP. */
+   struct mutex lock;
 } hdmi;
 
 
@@ -59,7 +60,7 @@ static int hdmi_panel_enable(struct omap_dss_device *dssdev)
int r = 0;
DSSDBG("ENTER hdmi_panel_enable\n");
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
r = -EINVAL;
@@ -75,28 +76,28 @@ static int hdmi_panel_enable(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
 err:
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 
return r;
 }
 
 static void hdmi_panel_disable(struct omap_dss_device *dssdev)
 {
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
omapdss_hdmi_display_disable(dssdev);
 
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
 
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 }
 
 static int hdmi_panel_suspend(struct omap_dss_device *dssdev)
 {
int r = 0;
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) {
r = -EINVAL;
@@ -108,7 +109,7 @@ static int hdmi_panel_suspend(struct omap_dss_device 
*dssdev)
omapdss_hdmi_display_disable(dssdev);
 
 err:
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 
return r;
 }
@@ -117,7 +118,7 @@ static int hdmi_panel_resume(struct omap_dss_device *dssdev)
 {
int r = 0;
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state != OMAP_DSS_DISPLAY_SUSPENDED) {
r = -EINVAL;
@@ -133,7 +134,7 @@ static int hdmi_panel_resume(struct omap_dss_device *dssdev)
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
 err:
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 
return r;
 }
@@ -141,11 +142,11 @@ err:
 static void hdmi_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
 {
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
*timings = dssdev->panel.timings;
 
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 }
 
 static void hdmi_set_timings(struct omap_dss_device *dssdev,
@@ -153,12 +154,12 @@ static void hdmi_set_timings(struct omap_dss_device 
*dssdev,
 {
DSSDBG("hdmi_set_timings\n");
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
dssdev->panel.timings = *timings;
omapdss_hdmi_display_set_timing(dssdev);
 
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 }
 
 static int hdmi_check_timings(struct omap_dss_device *dssdev,
@@ -168,11 +169,11 @@ static int hdmi_check_timings(struct omap_dss_device 
*dssdev,
 
DSSDBG("hdmi_check_timings\n");
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
r = omapdss_hdmi_display_check_timing(dssdev, timings);
 
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
return r;
 }
 
@@ -180,7 +181,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, 
u8 *buf, int len)
 {
int r;
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) {
r = omapdss_hdmi_display_enable(dssdev);
@@ -194,7 +195,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev, 
u8 *buf, int len)
dssdev->state == OMAP_DSS_DISPLAY_SUSPENDED)
omapdss_hdmi_display_disable(dssdev);
 err:
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock);
 
return r;
 }
@@ -203,7 +204,7 @@ static bool hdmi_detect(struct omap_dss_device *dssdev)
 {
int r;
 
-   mutex_lock(&hdmi.hdmi_lock);
+   mutex_lock(&hdmi.lock);
 
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) {
r = omapdss_hdmi_display_enable(dssdev);
@@ -217,7 +218,7 @@ static bool hdmi_detect(struct omap_dss_device *dssdev)
dssdev->state == OMAP_DSS_DISPLAY_SUSPENDED)
omapdss_hdmi_display_disable(dssdev);
 err:
-   mutex_unlock(&hdmi.hdmi_lock);
+   mutex_unlock(&hdmi.lock)

[PATCH v2 03/14] OMAPDSS: HDMI: Remove ASoC codec

[Ricardo Neri]

Remove the ASoC OMAP HDMI audio codec. The goal of removing the codec
is to, in subsequent patches, give way to the implementation of the HDMI
audio support using the DSS device driver audio interface. This
approach will expose the HDMI audio functionality to any interested entity.

In a separate patch, ASoC will use this new approach to expose HDMI audio
to ALSA.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/hdmi.c|  236 -
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |5 -
 2 files changed, 0 insertions(+), 241 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 159aa66..11d6ca8 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,12 +33,6 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-#include 
-#include 
-#include "ti_hdmi_4xxx_ip.h"
-#endif
 
 #include "ti_hdmi.h"
 #include "dss.h"
@@ -558,220 +552,6 @@ void omapdss_hdmi_display_disable(struct omap_dss_device 
*dssdev)
mutex_unlock(&hdmi.lock);
 }
 
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
-   defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-
-static int hdmi_audio_trigger(struct snd_pcm_substream *substream, int cmd,
-   struct snd_soc_dai *dai)
-{
-   struct snd_soc_pcm_runtime *rtd = substream->private_data;
-   struct snd_soc_codec *codec = rtd->codec;
-   struct platform_device *pdev = to_platform_device(codec->dev);
-   struct hdmi_ip_data *ip_data = snd_soc_codec_get_drvdata(codec);
-   int err = 0;
-
-   if (!(ip_data->ops) && !(ip_data->ops->audio_enable)) {
-   dev_err(&pdev->dev, "Cannot enable/disable audio\n");
-   return -ENODEV;
-   }
-
-   switch (cmd) {
-   case SNDRV_PCM_TRIGGER_START:
-   case SNDRV_PCM_TRIGGER_RESUME:
-   case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
-   ip_data->ops->audio_enable(ip_data);
-   break;
-   case SNDRV_PCM_TRIGGER_STOP:
-   case SNDRV_PCM_TRIGGER_SUSPEND:
-   case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
-   ip_data->ops->audio_disable(ip_data);
-   break;
-   default:
-   err = -EINVAL;
-   }
-   return err;
-}
-
-static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
-   struct snd_pcm_hw_params *params,
-   struct snd_soc_dai *dai)
-{
-   struct snd_soc_pcm_runtime *rtd = substream->private_data;
-   struct snd_soc_codec *codec = rtd->codec;
-   struct hdmi_ip_data *ip_data = snd_soc_codec_get_drvdata(codec);
-   struct hdmi_audio_format audio_format;
-   struct hdmi_audio_dma audio_dma;
-   struct hdmi_core_audio_config core_cfg;
-   struct hdmi_core_infoframe_audio aud_if_cfg;
-   int err, n, cts;
-   enum hdmi_core_audio_sample_freq sample_freq;
-
-   switch (params_format(params)) {
-   case SNDRV_PCM_FORMAT_S16_LE:
-   core_cfg.i2s_cfg.word_max_length =
-   HDMI_AUDIO_I2S_MAX_WORD_20BITS;
-   core_cfg.i2s_cfg.word_length = HDMI_AUDIO_I2S_CHST_WORD_16_BITS;
-   core_cfg.i2s_cfg.in_length_bits =
-   HDMI_AUDIO_I2S_INPUT_LENGTH_16;
-   core_cfg.i2s_cfg.justification = HDMI_AUDIO_JUSTIFY_LEFT;
-   audio_format.samples_per_word = HDMI_AUDIO_ONEWORD_TWOSAMPLES;
-   audio_format.sample_size = HDMI_AUDIO_SAMPLE_16BITS;
-   audio_format.justification = HDMI_AUDIO_JUSTIFY_LEFT;
-   audio_dma.transfer_size = 0x10;
-   break;
-   case SNDRV_PCM_FORMAT_S24_LE:
-   core_cfg.i2s_cfg.word_max_length =
-   HDMI_AUDIO_I2S_MAX_WORD_24BITS;
-   core_cfg.i2s_cfg.word_length = HDMI_AUDIO_I2S_CHST_WORD_24_BITS;
-   core_cfg.i2s_cfg.in_length_bits =
-   HDMI_AUDIO_I2S_INPUT_LENGTH_24;
-   audio_format.samples_per_word = HDMI_AUDIO_ONEWORD_ONESAMPLE;
-   audio_format.sample_size = HDMI_AUDIO_SAMPLE_24BITS;
-   audio_format.justification = HDMI_AUDIO_JUSTIFY_RIGHT;
-   core_cfg.i2s_cfg.justification = HDMI_AUDIO_JUSTIFY_RIGHT;
-   audio_dma.transfer_size = 0x20;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   switch (params_rate(params)) {
-   case 32000:
-   sample_freq = HDMI_AUDIO_FS_32000;
-   break;
-   case 44100:
-   sample_freq = HDMI_AUDIO_FS_44100;
-   break;
-   case 48000:
-   sample_freq = HDMI_AUDIO_FS_48000;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   err = hdmi_config_audio_acr(ip_data, params_rate(params), &n, &cts);
-   if (err < 0)

[PATCH v2 14/14] OMAPDSS: HDMI: Implement DSS driver interface for audio

[Ricardo Neri]

Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.

At the moment, a hardirq-safe spinlock is used to protect the audio
functions. This is because such functions might be called while
holding a lock (this especially true for audio_start/stop). For the
rest of the audio functions, a mutex could be used in the future as
the enablement of resources might take too much time.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/dss.h|8 +++
 drivers/video/omap2/dss/hdmi.c   |   42 ++
 drivers/video/omap2/dss/hdmi_panel.c |  100 ++
 3 files changed, 150 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d4b3dff..ec4aa14 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -514,6 +514,14 @@ int omapdss_hdmi_read_edid(u8 *buf, int len);
 bool omapdss_hdmi_detect(void);
 int hdmi_panel_init(void);
 void hdmi_panel_exit(void);
+#ifdef CONFIG_OMAP4_DSS_HDMI_AUDIO
+int hdmi_audio_enable(void);
+void hdmi_audio_disable(void);
+int hdmi_audio_start(void);
+void hdmi_audio_stop(void);
+bool hdmi_mode_has_audio(void);
+int hdmi_audio_config(struct omap_dss_audio *audio);
+#endif
 
 /* RFBI */
 #ifdef CONFIG_OMAP2_DSS_RFBI
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index aee0acf..388301e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -673,6 +673,48 @@ int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
 
return 0;
 }
+
+int hdmi_audio_enable(void)
+{
+   DSSDBG("audio_enable\n");
+
+   return hdmi.ip_data.ops->audio_enable(&hdmi.ip_data);
+}
+
+void hdmi_audio_disable(void)
+{
+   DSSDBG("audio_disable\n");
+
+   hdmi.ip_data.ops->audio_disable(&hdmi.ip_data);
+}
+
+int hdmi_audio_start(void)
+{
+   DSSDBG("audio_start\n");
+
+   return hdmi.ip_data.ops->audio_start(&hdmi.ip_data);
+}
+
+void hdmi_audio_stop(void)
+{
+   DSSDBG("audio_stop\n");
+
+   hdmi.ip_data.ops->audio_stop(&hdmi.ip_data);
+}
+
+bool hdmi_mode_has_audio(void)
+{
+   if (hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)
+   return true;
+   else
+   return false;
+}
+
+int hdmi_audio_config(struct omap_dss_audio *audio)
+{
+   return hdmi.ip_data.ops->audio_config(&hdmi.ip_data, audio);
+}
+
 #endif
 
 /* HDMI HW IP initialisation */
diff --git a/drivers/video/omap2/dss/hdmi_panel.c 
b/drivers/video/omap2/dss/hdmi_panel.c
index 5e215d6..8c17daa 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -32,6 +32,10 @@
 static struct {
/* This protects the panel ops, mainly when accessing the HDMI IP. */
struct mutex lock;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+   /* This protects the audio ops, specifically. */
+   spinlock_t audio_lock;
+#endif
 } hdmi;
 
 
@@ -223,6 +227,90 @@ err:
return r;
 }
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static int hdmi_panel_audio_enable(struct omap_dss_device *dssdev)
+{
+   unsigned long flags;
+   int r;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   r = hdmi_audio_enable();
+
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+   return r;
+}
+
+static void hdmi_panel_audio_disable(struct omap_dss_device *dssdev)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   hdmi_audio_disable();
+
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+}
+
+static int hdmi_panel_audio_start(struct omap_dss_device *dssdev)
+{
+   unsigned long flags;
+   int r;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   r = hdmi_audio_start();
+
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+   return r;
+}
+
+static void hdmi_panel_audio_stop(struct omap_dss_device *dssdev)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   hdmi_audio_stop();
+
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+}
+
+static bool hdmi_panel_audio_supported(struct omap_dss_device *dssdev)
+{
+   unsigned long flags;
+   bool r = false;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+   goto err;
+
+   if (!hdmi_mode_has_audio())
+   goto err;
+
+   r = true;
+err:
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+   return r;
+}
+
+static int hdmi_panel_audio_config(struct omap_dss_device *dssdev,
+   struct omap_dss_audio *audio)
+{
+   unsigned long flags;
+   int r;
+
+   spin_lock_irqsave(&hdmi.audio_lock, flags);
+
+   r = hdmi_audio_config(audio);
+
+   spin_unlock_irqrestore(&hdmi.audio_lock, flags);
+   return r;
+}
+
+#endif
+

[PATCH v2 09/14] OMAPDSS: HDMI: Relocate N/CTS calculation

[Ricardo Neri]

The N and CTS parameters are relevant to all HDMI implementations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.

Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color functionality is
implemented in the driver.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/hdmi.c|   42 +
 drivers/video/omap2/dss/ti_hdmi.h |1 +
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   57 -
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |2 -
 4 files changed, 43 insertions(+), 59 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 11d6ca8..2a810b7 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -573,6 +573,48 @@ static void hdmi_put_clocks(void)
clk_put(hdmi.sys_clk);
 }
 
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
+{
+   u32 deep_color;
+   u32 pclk = hdmi.ip_data.cfg.timings.pixel_clock;
+
+   if (n == NULL || cts == NULL)
+   return -EINVAL;
+
+   /* TODO: When implemented, query deep color mode here. */
+   deep_color = 100;
+
+   switch (sample_freq) {
+   case 32000:
+   if ((deep_color == 125) && ((pclk == 54054) ||
+   (pclk == 74250)))
+   *n = 8192;
+   else
+   *n = 4096;
+   break;
+   case 44100:
+   *n = 6272;
+   break;
+   case 48000:
+   if ((deep_color == 125) && ((pclk == 54054) ||
+   (pclk == 74250)))
+   *n = 8192;
+   else
+   *n = 6144;
+   break;
+   default:
+   *n = 0;
+   return -EINVAL;
+   }
+
+   /* Calculate CTS. See HDMI 1.3a or 1.4a specifications */
+   *cts = pclk * (*n / 128) * deep_color / (sample_freq / 10);
+
+   return 0;
+}
+#endif
+
 /* HDMI HW IP initialisation */
 static int omapdss_hdmihw_probe(struct platform_device *pdev)
 {
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 6aedb89..852a803 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -190,6 +190,7 @@ void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s);
 void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
 void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
 #if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts);
 int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data);
 int ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 9c3dfd4..5612534 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1204,63 +1204,6 @@ void hdmi_core_audio_infoframe_config(struct 
hdmi_ip_data *ip_data,
 */
 }
 
-int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
-   u32 sample_freq, u32 *n, u32 *cts)
-{
-   u32 r;
-   u32 deep_color = 0;
-   u32 pclk = ip_data->cfg.timings.pixel_clock;
-
-   if (n == NULL || cts == NULL)
-   return -EINVAL;
-   /*
-* Obtain current deep color configuration. This needed
-* to calculate the TMDS clock based on the pixel clock.
-*/
-   r = REG_GET(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, 1, 0);
-   switch (r) {
-   case 1: /* No deep color selected */
-   deep_color = 100;
-   break;
-   case 2: /* 10-bit deep color selected */
-   deep_color = 125;
-   break;
-   case 3: /* 12-bit deep color selected */
-   deep_color = 150;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   switch (sample_freq) {
-   case 32000:
-   if ((deep_color == 125) && ((pclk == 54054)
-   || (pclk == 74250)))
-   *n = 8192;
-   else
-   *n = 4096;
-   break;
-   case 44100:
-   *n = 6272;
-   break;
-   case 48000:
-   if ((deep_color == 125) && ((pclk == 54054)
-   || (pclk == 74250)))
-   *n = 8192;
-   else
-   *n = 6144;
-   break;
-   default:
-   *n = 0;
-   return -EINVAL;
-   }
-
-   /* Calculate CTS. See HDMI 1.3a or 1.4a spec

[PATCH v2 08/14] OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio

[Ricardo Neri]

Utilize a snd_aes_iec958 struct to write the parameters of the IEC-60958
channel status word into the HDMI IP registers. Hence, the user of the
driver has full control of what parameters are written in the word.

Also, some of the parameters of the I2S structure have been removed
as they are actually IEC-60958 parameters.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   29 +++--
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |4 +---
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index cbda730..9c3dfd4 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1114,10 +1114,25 @@ void hdmi_core_audio_config(struct hdmi_ip_data 
*ip_data,
REG_FLD_MOD(av_base, HDMI_CORE_AV_SPDIF_CTRL,
cfg->fs_override, 1, 1);
 
-   /* I2S parameters */
-   REG_FLD_MOD(av_base, HDMI_CORE_AV_I2S_CHST4,
-   cfg->freq_sample, 3, 0);
-
+   /*
+* Set IEC-60958-3 channel status word. It is passed to the IP
+* just as it is received. The user of the driver is responsible
+* for its contents.
+*/
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST0,
+  cfg->iec60958_cfg->status[0]);
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST1,
+  cfg->iec60958_cfg->status[1]);
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST2,
+  cfg->iec60958_cfg->status[2]);
+   /* yes, this is correct: status[3] goes to CHST4 register */
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST4,
+  cfg->iec60958_cfg->status[3]);
+   /* yes, this is correct: status[4] goes to CHST5 register */
+   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST5,
+  cfg->iec60958_cfg->status[4]);
+
+   /* set I2S parameters */
r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_IN_CTRL);
r = FLD_MOD(r, cfg->i2s_cfg.sck_edge_mode, 6, 6);
r = FLD_MOD(r, cfg->i2s_cfg.vbit, 4, 4);
@@ -1126,12 +1141,6 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
r = FLD_MOD(r, cfg->i2s_cfg.shift, 0, 0);
hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_IN_CTRL, r);
 
-   r = hdmi_read_reg(av_base, HDMI_CORE_AV_I2S_CHST5);
-   r = FLD_MOD(r, cfg->freq_sample, 7, 4);
-   r = FLD_MOD(r, cfg->i2s_cfg.word_length, 3, 1);
-   r = FLD_MOD(r, cfg->i2s_cfg.word_max_length, 0, 0);
-   hdmi_write_reg(av_base, HDMI_CORE_AV_I2S_CHST5, r);
-
REG_FLD_MOD(av_base, HDMI_CORE_AV_I2S_IN_LEN,
cfg->i2s_cfg.in_length_bits, 3, 0);
 
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 5d6e37a..4fd4f35 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -412,8 +412,6 @@ struct hdmi_audio_dma {
 };
 
 struct hdmi_core_audio_i2s_config {
-   u8 word_max_length;
-   u8 word_length;
u8 in_length_bits;
u8 justification;
u8 sck_edge_mode;
@@ -425,7 +423,7 @@ struct hdmi_core_audio_i2s_config {
 
 struct hdmi_core_audio_config {
struct hdmi_core_audio_i2s_config   i2s_cfg;
-   u32 freq_sample;
+   struct snd_aes_iec958   *iec60958_cfg;
boolfs_override;
u32 n;
u32 cts;
-- 
1.7.5.4

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

[PATCH v2 01/14] OMAPDSS: HDMI: Split audio_enable into audio_enable/disable

[Ricardo Neri]

To improve readability, split the audio_enable HDMI IP operation
into two separate functions for enabling and disabling audio.
The audio_enable function is also modified to return an error value.

While there, update these operations for the OMAP4 IP accordingly.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/dss_features.c|1 +
 drivers/video/omap2/dss/hdmi.c|4 ++--
 drivers/video/omap2/dss/ti_hdmi.h |7 +--
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   19 +++
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index ce14aa6..52fbc72 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -569,6 +569,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
 #if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
.audio_enable   =   ti_hdmi_4xxx_wp_audio_enable,
+   .audio_disable  =   ti_hdmi_4xxx_wp_audio_disable,
 #endif
 
 };
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c4b4f69..9a8b32c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -576,12 +576,12 @@ static int hdmi_audio_trigger(struct snd_pcm_substream 
*substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
-   ip_data->ops->audio_enable(ip_data, true);
+   ip_data->ops->audio_enable(ip_data);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
-   ip_data->ops->audio_enable(ip_data, false);
+   ip_data->ops->audio_disable(ip_data);
break;
default:
err = -EINVAL;
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 1f58b84..88fdc1c 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,7 +108,9 @@ struct ti_hdmi_ip_ops {
 
 #if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-   void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
+   int (*audio_enable)(struct hdmi_ip_data *ip_data);
+
+   void (*audio_disable)(struct hdmi_ip_data *ip_data);
 #endif
 
 };
@@ -183,6 +185,7 @@ void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, 
struct seq_file *s);
 void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
 #if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
+int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data);
+void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data);
 #endif
 #endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index bfe6fe6..b25b519 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1249,13 +1249,24 @@ int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
return 0;
 }
 
-void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable)
+int ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data)
 {
REG_FLD_MOD(hdmi_av_base(ip_data),
-   HDMI_CORE_AV_AUD_MODE, enable, 0, 0);
+   HDMI_CORE_AV_AUD_MODE, true, 0, 0);
REG_FLD_MOD(hdmi_wp_base(ip_data),
-   HDMI_WP_AUDIO_CTRL, enable, 31, 31);
+   HDMI_WP_AUDIO_CTRL, true, 31, 31);
REG_FLD_MOD(hdmi_wp_base(ip_data),
-   HDMI_WP_AUDIO_CTRL, enable, 30, 30);
+   HDMI_WP_AUDIO_CTRL, true, 30, 30);
+   return 0;
+}
+
+void ti_hdmi_4xxx_wp_audio_disable(struct hdmi_ip_data *ip_data)
+{
+   REG_FLD_MOD(hdmi_av_base(ip_data),
+   HDMI_CORE_AV_AUD_MODE, false, 0, 0);
+   REG_FLD_MOD(hdmi_wp_base(ip_data),
+   HDMI_WP_AUDIO_CTRL, false, 31, 31);
+   REG_FLD_MOD(hdmi_wp_base(ip_data),
+   HDMI_WP_AUDIO_CTRL, false, 30, 30);
 }
 #endif
-- 
1.7.5.4

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

[PATCH v2 02/14] OMAPDSS: HDMI: Split video_enable into video_enable/disable

[Ricardo Neri]

To improve readability, split the video_enable HDMI IP operation
into two separate functions for enabling and disabling video.
The video_enable function is also modified to return an error value.

While there, update these operations for the OMAP4 IP accordingly.

Signed-off-by: Ricardo Neri 
---
 drivers/video/omap2/dss/dss_features.c|1 +
 drivers/video/omap2/dss/hdmi.c|   11 +++
 drivers/video/omap2/dss/ti_hdmi.h |7 +--
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |   10 --
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 52fbc72..c677095 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -562,6 +562,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.pll_enable =   ti_hdmi_4xxx_pll_enable,
.pll_disable=   ti_hdmi_4xxx_pll_disable,
.video_enable   =   ti_hdmi_4xxx_wp_video_start,
+   .video_disable  =   ti_hdmi_4xxx_wp_video_stop,
.dump_wrapper   =   ti_hdmi_4xxx_wp_dump,
.dump_core  =   ti_hdmi_4xxx_core_dump,
.dump_pll   =   ti_hdmi_4xxx_pll_dump,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 9a8b32c..159aa66 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -344,7 +344,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
 
hdmi_compute_pll(dssdev, phy, &hdmi.ip_data.pll_data);
 
-   hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 0);
+   hdmi.ip_data.ops->video_disable(&hdmi.ip_data);
 
/* config the PLL and PHY hdmi_set_pll_pwrfirst */
r = hdmi.ip_data.ops->pll_enable(&hdmi.ip_data);
@@ -379,7 +379,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_set_digit_size(dssdev->panel.timings.x_res,
dssdev->panel.timings.y_res);
 
-   hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 1);
+   r = hdmi.ip_data.ops->video_enable(&hdmi.ip_data);
+   if (r)
+   goto err_vid_enable;
 
r = dss_mgr_enable(dssdev->manager);
if (r)
@@ -388,7 +390,8 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
return 0;
 
 err_mgr_enable:
-   hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 0);
+   hdmi.ip_data.ops->video_disable(&hdmi.ip_data);
+err_vid_enable:
hdmi.ip_data.ops->phy_disable(&hdmi.ip_data);
hdmi.ip_data.ops->pll_disable(&hdmi.ip_data);
 err:
@@ -400,7 +403,7 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
 {
dss_mgr_disable(dssdev->manager);
 
-   hdmi.ip_data.ops->video_enable(&hdmi.ip_data, 0);
+   hdmi.ip_data.ops->video_disable(&hdmi.ip_data);
hdmi.ip_data.ops->phy_disable(&hdmi.ip_data);
hdmi.ip_data.ops->pll_disable(&hdmi.ip_data);
hdmi_runtime_put();
diff --git a/drivers/video/omap2/dss/ti_hdmi.h 
b/drivers/video/omap2/dss/ti_hdmi.h
index 88fdc1c..4c84a9c 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -96,7 +96,9 @@ struct ti_hdmi_ip_ops {
 
void (*pll_disable)(struct hdmi_ip_data *ip_data);
 
-   void (*video_enable)(struct hdmi_ip_data *ip_data, bool start);
+   int (*video_enable)(struct hdmi_ip_data *ip_data);
+
+   void (*video_disable)(struct hdmi_ip_data *ip_data);
 
void (*dump_wrapper)(struct hdmi_ip_data *ip_data, struct seq_file *s);
 
@@ -175,7 +177,8 @@ int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
 int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data, u8 *edid, int len);
 bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data);
-void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start);
+int ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data);
+void ti_hdmi_4xxx_wp_video_stop(struct hdmi_ip_data *ip_data);
 int ti_hdmi_4xxx_pll_enable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_pll_disable(struct hdmi_ip_data *ip_data);
 void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index b25b519..aa18163 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -699,9 +699,15 @@ static void hdmi_wp_init(struct omap_video_timings 
*timings,
 
 }
 
-void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
+int ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data)
 {
-   REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
+   REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, true, 31, 31);
+   return 0;
+}
+
+void ti_hdmi_4xxx_wp_video_stop(struct hdmi_ip_data *ip_data)
+{
+  

[PATCH v2] Provide interface for audio support in DSS

[Ricardo Neri]

Hi,

This patch is proposed as a result of a previous discussion related to
include audio support in the DSS device driver
(http://www.spinics.net/lists/linux-omap/msg64748.html)

At the moment, this is intended to cover display technologies with audio based
on CEA-861 and IEC-60958, such as HDMI and DisplayPort. However, provisions are
made to make it extensible (see below).

These are the changes with respect to v1:

* The audio_enable and audio_start functions were split into enable/disable
  and  start/stop respectively to improve readability.
* Comments were added on whether the DSS audio functions may sleep.
* In order to make the audio configuration parameters extensible, a
  struct omap_dss_audio is defined. This helps to easily add more config
  parameters in the future if/when required (e.g., speaker order configuration).
 
BR,

Ricardo


Ricardo Neri (1):
  OMAPDSS: Provide an interface for audio support in DSS

 Documentation/arm/OMAP/DSS |   38 ++
 include/video/omapdss.h|   25 +
 2 files changed, 63 insertions(+), 0 deletions(-)

-- 
1.7.5.4

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

[PATCH v2] OMAPDSS: Provide an interface for audio support in DSS

[Ricardo Neri]

There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.

The audio_enable function is intended to prepare the relevant
IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
some IP, enabling companion chips, etc). It is intended to be called before
audio_start. The audio_disable function performs the reverse operation and is
intended to be called after audio_stop.

While a given DSS device driver may support audio, it is possible that for
certain configurations audio is not supported (e.g., an HDMI display using a
VESA video timing). The audio_supported function is intended to query whether
the current configuration of the display supports audio.

The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any
specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
is to contain all the required parameters for audio configuration. At the
moment, such structure contains pointers to IEC-60958 channel status word and
CEA-861 audio infoframe structures. This should be enough to support HDMI and
DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
structure may be extended in the future if required.

The audio_enable/disable, audio_config and audio_supported functions could be
implemented as functions that may sleep. Hence, they should not be called
while holding a spinlock or a readlock.

The audio_start/audio_stop function is intended to effectively start/stop audio
playback after the configuration has taken place. These functions are designed
to be used in an atomic context. Hence, audio_start should return quickly and be
called only after all the needed resources for audio playback (audio FIFOs,
DMA channels, companion chips, etc) have been enabled to begin data transfers.
audio_stop is designed to only stop the audio transfers. The resources used
for playback are released using audio_disable.

Signed-off-by: Ricardo Neri 
---
 Documentation/arm/OMAP/DSS |   38 ++
 include/video/omapdss.h|   25 +
 2 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b..32ca5d9 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -47,6 +47,44 @@ flexible way to enable non-common multi-display 
configuration. In addition to
 modelling the hardware overlays, omapdss supports virtual overlays and overlay
 managers. These can be used when updating a display with CPU or system DMA.
 
+omapdss driver support for audio
+
+There exist several display technologies and standards that support audio as
+well. Hence, it is relevant to update the DSS device driver to provide an audio
+interface that may be used by an audio driver or any other driver interested in
+the functionality.
+
+The audio_enable function is intended to prepare the relevant
+IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
+some IP, enabling companion chips, etc). It is intended to be called before
+audio_start. The audio_disable function performs the reverse operation and is
+intended to be called after audio_stop.
+
+While a given DSS device driver may support audio, it is possible that for
+certain configurations audio is not supported (e.g., an HDMI display using a
+VESA video timing). The audio_supported function is intended to query whether
+the current configuration of the display supports audio.
+
+The audio_config function is intended to configure all the relevant audio
+parameters of the display. In order to make the function independent of any
+specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
+is to contain all the required parameters for audio configuration. At the
+moment, such structure contains pointers to IEC-60958 channel status word
+and CEA-861 audio infoframe structures. This should be enough to support
+HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
+
+The audio_enable/disable, audio_config and audio_supported functions could be
+implemented as functions that may sleep. Hence, they should not be called
+while holding a spinlock or a readlock.
+
+The audio_start/audio_stop function is intended to effectively start/stop audio
+playback after the configuration has taken place. These functions are designed
+to be used in an atomic context. Hence, audio_start should return quickly and 
be
+called only after all the needed resources for audio playback (audio FIFOs,
+DMA channels, companion chips, etc) have been enabled to begin data transfers.
+audio_stop is designed to only stop the audio transfers. The resources used
+for playback are released using a

Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver

[Greg KH]

On Thu, May 03, 2012 at 06:38:23PM -0400, Paul Gortmaker wrote:
> On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
>  wrote:
> > Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs
> 
> Hi Santosh,
> 
> Can you send Greg a patch that adds proper dependencies to the Kconfig?
> I was going to simply add an ARM dependency, but perhaps you want to
> restrict it further to a subset of OMAP platforms?
> 
> At the moment it is causing build failures in other architectures.
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/6243036/

I think there's a config option for readl/writel, but yes, ARM would
probably be fine as well.

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 1/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Thu, May 03, 2012 at 04:26:12PM -0600, Stephen Warren wrote:
> On 04/30/2012 03:17 PM, Jon Hunter wrote:
> > +Example:
> > +
> > +   sdma: dmaengine@4800 {
> > +   compatible = "ti,omap4-sdma"
> > +   reg = <0x4800 0x1000>;
> > +   interrupts = <4>;
> > +   #dma-cells = <2>;
> > +   #dma-channels = <32>;
> > +   #dma-requests = <127>;
> > +   };
> > +
> > +
> > +* DMA client
> > +
> > +Client drivers should specify the DMA property using a phandle to the 
> > controller
> > +followed by the number of DMA request/channel and the transfer type of the
> 
> What exactly is "request/channel"? Is it a request ID, a channel ID,
> both packed into a single integer (which bits are used for each field),
> etc.?

Agreed - because with this definition, applied to the PL08x found on
Versatile platforms, it will be impossible to describe the DMA bindings
due to intervening MUX hardware.

> > +channel (eg. device-to-memory, memory-to-device, memory-to-memory, etc). 
> > Drivers
> > +should use the DMA Engine enum dma_transfer_direction (eg. DMA_DEV_TO_MEM,
> > +DMA_MEM_TO_DEV, etc) for specifying the transfer type.
> 
> The binding document should stand alone; you shouldn't need to go look
> up values in any particular OS/driver's source code. In other words,
> this should explicitly enumerate the values for DMA_DEV_TO_MEM etc.
> here. That said, I'm not sure it's appropriate to mandate that every DMA
> controller's DMA specifier actually include this information in DT (a
> controller might only support DEV_TO_MEM for example, and hence not need
> this information in DT at all).
> 
> The DMA client's binding should specify how many entries it needs in the
> dma property and what they mean, e.g. it should know that dma property
> index 0 is the TX DMA specifier, and index 1 is the RX specifier.

(Mostly to Jon)

Also bear in mind that as far as DMA engine is concerned, every channel
is _potentially_ bidirectional without it having to be released and
reacquired.  We have some drivers setup to behave like that too.  So
stuffing stuff like the transfer type into the selection adds
restrictions.

On platforms where the DMA transfer type does matter (such as OMAP),
that's normally because one DMA request signal is associated with a
particular DMA direction.  That makes it a property of the DMA request
signal, not of the requested channel.
--
To unsubscribe from this list: send the line "unsubscribe 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 17/18][V3] ARM: OMAP3/4: consolidate cpuidle Makefile

[Daniel Lezcano]

On 05/03/2012 10:34 PM, Kevin Hilman wrote:

Daniel Lezcano  writes:


Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.

Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet


This patch breaks compilation for the !CONFIG_PM case:

arch/arm/mach-omap2/built-in.o: In function `__omap3_enter_idle':
/work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle34xx.c:121: undefined 
reference to `omap_sram_idle'

Since you moved this stuff out of a CONFIG_PM conditional part of the
Makefile, it broke because pm34xx.c is still compiled conditionally on
CONFIG_PM.

When changing Makefile/Kconfig dependencies like this, please
be sure to at least compile test with the various options
enabled/disabled.

For now, I've dropped this patch from the series.  Feel free to
update/retest/resend since the idea is fine.


Ok, I will update it with the various options.

  -- Daniel

--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe 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 18/18][V3] ARM: OMAP3: cpuidle - set global variables static

[Daniel Lezcano]

On 05/03/2012 10:26 PM, Kevin Hilman wrote:

Daniel Lezcano  writes:


and check the powerdomain lookup is successful.

Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
  arch/arm/mach-omap2/cpuidle34xx.c |5 -
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d28596..116a0d8 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -73,7 +73,7 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
},
  };

-struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
+static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;

  static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
struct clockdomain *clkdm)
@@ -252,6 +252,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 *its own code.
 */

+   if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
+   return -ENODEV;
+


Why check here?  cam_pd is actually used just above this code.

Also, this is in the fast path.  This should just be checked once at
init time instead of every idle path.

For those reasons, I've dropped this part of the patch (updated patch
below.)


Hmm, weird this part should have been in the init function, I likely 
missed a big fuzz I think when porting the patchset to the latest kernel 
version. Thanks for fixing it.



If desired, you can send an additional patch that adds this error
checking at init time and then refuses to register the driver if any of
the pwrdms don't exist.


Yes, I will do it.

  -- Daniel

--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe 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] ARM: OMAP2+: watchdog: fix !PM boot crash, disarm timer after hwmod reset

[Paul Walmsley]

Hi Kevin,

On Thu, 3 May 2012, Kevin Hilman wrote:

> On 04/20/2012 01:59 PM, Paul Walmsley wrote:
> 
> [...]
> 
> > This looks great, looks like it will finally fix this longstanding bug.  I
> > think Santosh hit it too a long time ago, so I suspect he will be happy
> > too.
> > 
> > One comment: I think that omap2_wd_timer_reset() needs to be updated in
> > light of commit 3c55c1baffa5f719eb2ae9729088bc867f972f53 ("ARM: OMAP2+:
> > hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for
> > reset status"").  I did this here.  It's passed basic build testing but
> > haven't tried booting it yet.  Care to take a look and see if you have any
> > comments?  It's also available in the 'hwmod_devel_a_3.5' branch of
> > git://git.pwsan.com/linux-2.6
> 
> I just noticed a compile warning with your updated version:
> 
> /work/kernel/omap/pm/arch/arm/mach-omap2/wd_timer.c: In function
> 'omap2_wd_timer_reset':
> /work/kernel/omap/pm/arch/arm/mach-omap2/wd_timer.c:78:6: warning: unused
> variable 'v' [-Wunused-variable]
> 
> The diff below on top of your patch fixes it.

Thanks, just rolled this into the patch and added some credit.


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

Re: [PATCH v5 0/7] Add TI EMIF SDRAM controller driver

[Paul Gortmaker]

On Fri, Apr 27, 2012 at 8:24 AM, Santosh Shilimkar
 wrote:
> Add a driver for the EMIF SDRAM controller used in Texas Instrument SoCs

Hi Santosh,

Can you send Greg a patch that adds proper dependencies to the Kconfig?
I was going to simply add an ARM dependency, but perhaps you want to
restrict it further to a subset of OMAP platforms?

At the moment it is causing build failures in other architectures.

http://kisskb.ellerman.id.au/kisskb/buildresult/6243036/

Thanks,
Paul.
--
>
> EMIF is an SDRAM controller that supports, based on its revision,
> one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> for LPDDR2.
>
> The driver supports the following features:
> - Calculates the DDR AC timing parameters to be set in EMIF
>  registers using data from the device data-sheets and based
>  on the DDR frequency. If data from data-sheets is not available
>  default timing values from the JEDEC spec are used. These
>  will be safe, but not necessarily optimal
> - API for changing timings during DVFS or at boot-up
> - Temperature alert configuration and handling of temperature
>  alerts, if any for LPDDR2 devices
>  * temperature alert is based on periodic polling of MR4 mode
>    register in DDR devices automatically performed by hardware
>  * timings are de-rated and brought back to nominal when
>    temperature raises and falls respectively
> - Cache of calculated register values to avoid re-calculating
>  them
>
> The driver will need some minor updates when it is eventually
> integrated with Dynamic Voltage and Frequency Scaling (DVFS).
> This can not be done now as DVFS support is not available in
> the mainline yet.
>
> Discussions with Santosh Shilimkar 
> were immensely helpful in shaping up the interfaces. Vibhore Vardhan
>  did the initial code snippet for thermal
> handling.
>
> Testing:
> - The driver is tested on OMAP4430 SDP.
> - The driver in a slightly adapted form is also tested on OMAP5.
> - Since mainline kernel doesn't have DVFS support yet,
>  testing was done using a test module.
> - Temperature alert handling was tested with simulated interrupts
>  and faked temperature values as testing all cases in real-life
>  scenarios is difficult.
> - Tested the driver as a module
>
> Cc: Greg KH 
>
> v5:
> - Moved the EMIF driver to drivers/memory as per discussion thread [2]
>
> v4:
> - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
> - Removed un-necessary "#ifndef __ASSEMBLY__'
> - Minor formatting fix
>
> v2:
> - Fixed a bug found in the implementation of errata i728
>  workaround
> - Fixed the value of frequency printed in debugfs
> - Dropped the hwmod patch as Paul has already posted a
>  a hwmod series [1] that adds hwmod for EMIF
> - Converted instances of __init to __init_or_module
>
> Regards
> Santosh
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855
> [2] https://lkml.org/lkml/2012/4/12/173
>
>
> Aneesh V (7):
>  ddr: add LPDDR2 data from JESD209-2
>  memory: emif: add register definitions for EMIF
>  memory: emif: add basic infrastructure for EMIF driver
>  memory: emif: handle frequency and voltage change events
>  memory: emif: add interrupt and temperature handling
>  memory: emif: add one-time settings
>  memory: emif: add debugfs entries for emif
>
>  Documentation/memory-devices/ti-emif.txt |   57 +
>  drivers/Kconfig                          |    4 +
>  drivers/Makefile                         |    3 +
>  drivers/memory/Kconfig                   |   22 +
>  drivers/memory/Makefile                  |    5 +
>  drivers/memory/emif.c                    | 1670 
> ++
>  drivers/memory/emif.h                    |  589 +++
>  include/linux/platform_data/emif_plat.h  |  128 +++
>  include/memory/jedec_ddr.h               |  175 
>  lib/Kconfig                              |    8 +
>  lib/Makefile                             |    2 +
>  lib/jedec_ddr_data.c                     |  135 +++
>  12 files changed, 2798 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/memory-devices/ti-emif.txt
>  create mode 100644 drivers/memory/Kconfig
>  create mode 100644 drivers/memory/Makefile
>  create mode 100644 drivers/memory/emif.c
>  create mode 100644 drivers/memory/emif.h
>  create mode 100644 include/linux/platform_data/emif_plat.h
>  create mode 100644 include/memory/jedec_ddr.h
>  create mode 100644 lib/jedec_ddr_data.c
>
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe 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] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf

[Stephen Warren]

On 05/03/2012 09:27 AM, Tony Lindgren wrote:
> Hi,
> 
> * Jean-Christophe PLAGNIOL-VILLARD  [120503 00:16]:
>>
>>  I really like it
>>
>>  I was working on something simillar
>>
>>  but can we split the group management so we can use it on other
>>  bindings
> 
> Hmm I'm not sure I follow on the group management splitting, can you specify
> what you have in mind here?
> 
> If you mean moving more things into pinctrl fwk, then yeah I'd assume that
> will happen eventually and drivers like this will end up becoming more 
> minimal.

Jean-Christophe, forgive me if I'm putting words in your mouth, but I
assume the following is what you mean:

There are two pieces of data required by the pinctrl subsystem:

a) The set of pins, functions, and groups that exist.

b) The specific function to select for each pin/group on a given board.

Item (a) can be represented in the pinctrl driver (e.g. as in the Tegra
driver), or can be represented in device tree in order to avoid large
tables in the driver.

Item (b) has to be represented in device tree, since the whole point is
that it's board-specific.

For all DT bindings I've seen that choose to represent (a) in the DT
rather than in the driver, the DT represents (b) directly, and (a) is
implicitly extracted/created based on (a).

When I was first thinking about DT bindings for pinctrl, I had hoped
that even if (a) was represented in DT, the DT nodes/properties for (a)
and (b) would be entirely separate, so that the binding for (b) could be
completely common across all SoCs, even though the binding for (a) would
perhaps be different across SoCs (if it existed at all).

So, perhaps Jean-Christophe is talking about splitting up (a) and (b) in
device tree?

Or perhaps Jean-Christophe only refers to the code that creates the
group and function definitions from (b), and not the actual DT binding
itself?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Stephen Warren]

On 04/30/2012 03:17 PM, Jon Hunter wrote:
> From: Jon Hunter 
> 
> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
> to add some basic helpers to retrieve a DMA controller device_node and the
> DMA request/channel information.

I'll reply to the binding documentation first; perhaps that'll set the
scene for my questions better.

> +++ b/Documentation/devicetree/bindings/dma/dma.txt
> +* Generic DMA Controller and DMA request bindings
> +
> +Generic binding to provide a way for a driver using DMA Engine to retrieve 
> the
> +DMA request or channel information that goes from a hardware device to a DMA
> +controller.
> +
> +
> +* DMA controller
> +
> +Required property:
> +- #dma-cells: Number elements to describe DMA channel information. Must 
> be
> +  2 with current implementation but in future we could allow
> +   more than 2 to describe interrupt mapping as well.

That makes sense.

> +- #dma-channels: Number of DMA channels supported by the controller.
> +- #dma-requests: Number of DMA requests signals supported by the 
> controller.

I don't see why those properties would be mandatory in device tree. They
don't appear to be involved in parsing a DMA client's DMA specifier.
Shouldn't this information be provided at run-time by the DMA controller
driver. If it supports different HW models with different capabilities,
then it certainly could represent those values in DT, but I don't think
this should be required.

> +Example:
> +
> + sdma: dmaengine@4800 {
> + compatible = "ti,omap4-sdma"
> + reg = <0x4800 0x1000>;
> + interrupts = <4>;
> + #dma-cells = <2>;
> + #dma-channels = <32>;
> + #dma-requests = <127>;
> + };
> +
> +
> +* DMA client
> +
> +Client drivers should specify the DMA property using a phandle to the 
> controller
> +followed by the number of DMA request/channel and the transfer type of the

What exactly is "request/channel"? Is it a request ID, a channel ID,
both packed into a single integer (which bits are used for each field),
etc.?

If this is up to the individual controller binding, then I think the
description should just specify that there is a phandle followed by a
DMA specifier, and the DMA specifier contains #dma-cells from the
phandle node. See other similar bindings for suitable wording.

> +channel (eg. device-to-memory, memory-to-device, memory-to-memory, etc). 
> Drivers
> +should use the DMA Engine enum dma_transfer_direction (eg. DMA_DEV_TO_MEM,
> +DMA_MEM_TO_DEV, etc) for specifying the transfer type.

The binding document should stand alone; you shouldn't need to go look
up values in any particular OS/driver's source code. In other words,
this should explicitly enumerate the values for DMA_DEV_TO_MEM etc.
here. That said, I'm not sure it's appropriate to mandate that every DMA
controller's DMA specifier actually include this information in DT (a
controller might only support DEV_TO_MEM for example, and hence not need
this information in DT at all).

The DMA client's binding should specify how many entries it needs in the
dma property and what they mean, e.g. it should know that dma property
index 0 is the TX DMA specifier, and index 1 is the RX specifier.

> +Required property:
> +- dma: List of phandle + dma-request/channel + transfer-type,
> +  one group per request "line".
> +
> +Example:
> +
> + i2c1: i2c@1 {
> + ...
> + dma = <&sdma 2 1 &sdma 3 2>;

Should that be "dmas" (plural) to be consistency with interrupts, gpios,
...?


Back to pieces of your patch description:

> v3: - avoid passing an xlate function and instead pass DMA engine parameters
> - define number of dma channels and requests in dma-controller node

Perhaps I lack context of previous discussion, but that seems the wrong
direction, and doesn't allow DMA controllers to define the format of
their DMA specifiers.

I'd expect the process to work just like other DT bindings:

* Client calls dma_request(index)
* OF DMA core gets property, does the following until it hits index:
** Get phandle
** Get provider node for phandle
** Parses #dma-cells from provider node
** If at appropriate index:
*** call xlate/get function to convert the DMA specifier to something
that could be passed to e.g. dma_request_channel.
*** else skip that many cells and loop

Now, the structure returned from the xlate function could encompass
filter_fn and filter_param if required.

In fact, I'd expect that all xlate return something like:

struct of_dma_filter_param {
struct device_node *node;
dma_filter_fn filter_fn;
void *filter_param;
};

and the following filter function to always be used for the DT case:

bool of_dma_filter_func(...)
{
struct of_dma_filter_param *p = ...;

/* First, only match the controller of the DT node that parsed this
   filter data */
if (p->node != xxx->node)
return false;

/

Re: [PATCH 4/7] ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.

[Kevin Hilman]

Santosh Shilimkar  writes:

> cpu_class_is_omap2() contains all OMAP2+ devices. So update the DMA code
> cpu checks accordingly so that there is no need to patch
> the file for any future OMAP2+ devices.
>
> In long run, all these attributes should come from hwmod dev_attr based
> on DMA IP version.
>
> Signed-off-by: Santosh Shilimkar 
> ---
>  arch/arm/mach-omap2/dma.c |2 +-
>  arch/arm/plat-omap/dma.c  |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
> index b19d849..2750bb9 100644
> --- a/arch/arm/mach-omap2/dma.c
> +++ b/arch/arm/mach-omap2/dma.c
> @@ -227,7 +227,7 @@ static int __init omap2_system_dma_init_dev(struct 
> omap_hwmod *oh, void *unused)
>  
>   dma_stride  = OMAP2_DMA_STRIDE;
>   dma_common_ch_start = CSDP;
> - if (cpu_is_omap3630() || cpu_is_omap44xx())
> + if (omap_rev() >= OMAP3630_REV_ES1_0)

It's not obvious (at least to me) that this is equivalent.

For example, this will now be true on the TI81xx devices.

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] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Kevin Hilman]

Ben Hutchings  writes:

> On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote:
>> On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
>> [...]
>> > > 
>> > > So, if I understood this correctly, it's effectively like blocking a low 
>> > > power
>> > > state transition (here wfi execution) when EMAC is active?
>> > 
>> > Assuming "it" is my patch, correct.
>> > 
>> 
>> Recently I was thinking about how to get certain drivers to disallow some or 
>> all
>> low power states and to me this also seems to fall in a similar category.
>> 
>> One of the suggestions that I got was to check if the 'wakeup' entry 
>> associated with
>> the device under sysfs could be leveraged for this. The PM code could 
>> maintain
>> a whitelist (or blacklist) of devices and it decides the low power state to 
>> enter
>> based on the 'wakeup' entries associated with these devices. In this 
>> particular case,
>> maybe the driver could simply set this entry to non-wakeup capable when 
>> necessary and
>> then let the PM code take care of skipping the wfi execution.
>> 
>> Thoughts/brickbats welcome :)
>
> You can maybe (ab)use the pm_qos mechanism for this.

I thought of using this too, but it doesn't actually solve the problem:

Using PM QoS, you can avoid hitting the deeper idle states by setting a
very low wakeup latency.  However, on ARM platforms, even the shallowest
idle states use the WFI instruction, and the EMAC would still not be
able to wake the system from WFI.  A possibility would be define the
shallowest idle state to be one that doesn't call WFI and just does
cpu_relax().  However, that would only work for CPUidle since PM QoS
constraints are only checked by CPUidle.  So, a non-CPUidle kernel would
still have this bug. :(

Ultimately, this is just broken HW.  This network HW was bolted onto an
existing SoC without consideration for wakeup capabilities.  The result
is that any use of this device with networking has to completely disable
SoC power management.

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

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Kevin Hilman]

"Hiremath, Vaibhav"  writes:

> On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
>> Hi,
>> 
>> * Hiremath, Vaibhav  [120502 02:37]:
>> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
>> > > Hi
>> > > 
>> > > On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
>> > > 
>> > > > From: Afzal Mohammed 
>> > > > 
>> > > > This patch adds minimal support for AM335X EVM.
>> > > > The approach taken here is to add AM335X EVM support
>> > > > to AM3517EVM, considering the fact that with device tree
>> > > > developement we will get rid of board-*.c.
>> > > > 
>> > > > Signed-off-by: Afzal Mohammed 
>> > > > Signed-off-by: Vaibhav Hiremath 
>> > > > Reviewed-by: Kevin Hilman 
>> > > 
>> > > I realize people may not necessarily like this, but I think that the 
>> > > AM33xx EVM needs its own board file.  This is because it really has 
>> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
>> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
>> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
>> 
>> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
>> except core with omap3. And the SOC is independent of the core selected,
>> there is no dependency between SoC and the core.
>> 
>> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
>> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
>> compile with different flags either.
>>  
>
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?

Please, no.

I've already demonstrated that that is not necessary and only leads to
confusion and maintenance headaches.

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

Re: [PATCH 00/18][V3] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups

[Kevin Hilman]

Hi Daniel,

Daniel Lezcano  writes:

> This patchset makes some cleanup on these cpuidle drivers
> and consolidate the code across both architecture.

I think I said it before, but it's worth repeating: Very nice cleanup!
Thanks for your persistence.

I've now been through this version and I think it's ready for v3.5.  I
had a few very minor comments on some specific patches but made the
changes myself.  Please comment on those patches if you think my changes
are OK or not.  Also, I had to drop the Makefile change due to compile
problems.

With those changes made, and Reviewed-by and Tested-by tags added from
Santosh, I've created a branch[1] and will queue it for v3.5.  Any
additional patches can be sent against this branch.

> Tested on OMAP3 (igepV2).
> Partially tested on OMAP4 (pandaboard), without offlining the cpu1.

I've also tested on OMAP3430/n900, OMAP3530/Overo and OMAP4430/Pandabord
with CPU1 offlined so the deeper C-states are hit.  Combined with the
review and testing from Jean and Santosh (thanks!), I think this is
ready to go.

Thanks again for this great cleanup and consolidation,

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
for_3.5/cleanup/omap-cpuidle

--
To unsubscribe from this list: send the line "unsubscribe 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 17/18][V3] ARM: OMAP3/4: consolidate cpuidle Makefile

[Kevin Hilman]

Daniel Lezcano  writes:

> Define a CPU_IDLE section in the makefile, declare the functions in
> the header files conforming to the kernel coding rules and remove the
> 'define's in the C files.
>
> Signed-off-by: Daniel Lezcano 
> Reviewed-by: Jean Pihet 

This patch breaks compilation for the !CONFIG_PM case:

   arch/arm/mach-omap2/built-in.o: In function `__omap3_enter_idle':
   /work/kernel/omap/pm/arch/arm/mach-omap2/cpuidle34xx.c:121: undefined 
reference to `omap_sram_idle'

Since you moved this stuff out of a CONFIG_PM conditional part of the
Makefile, it broke because pm34xx.c is still compiled conditionally on
CONFIG_PM.

When changing Makefile/Kconfig dependencies like this, please
be sure to at least compile test with the various options
enabled/disabled.

For now, I've dropped this patch from the series.  Feel free to
update/retest/resend since the idea is fine.

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 11/18][V3] ARM: OMAP3: cpuidle - remove the 'valid' field

[Daniel Lezcano]

On 05/03/2012 10:19 PM, Kevin Hilman wrote:

Daniel Lezcano  writes:


With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.

I don't think this changelog is valid anymore as you're not doing
anything to decrease the number of states.

I updated the changelog locally to this:

ARM: OMAP3: cpuidle - remove the 'valid' field

With the previous changes all the states are valid, except the last
state which is now handled at runtime by next_valid_state() based on
the errata flags.

Any problems with that?


No problem :)

Thanks for fixing the Changelog.

-- Daniel

--
   Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  Facebook |
  Twitter |
  Blog


--
To unsubscribe from this list: send the line "unsubscribe 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] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Ben Hutchings]

On Thu, 2012-05-03 at 19:25 +, Bedia, Vaibhav wrote:
> On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
> [...]
> > > 
> > > So, if I understood this correctly, it's effectively like blocking a low 
> > > power
> > > state transition (here wfi execution) when EMAC is active?
> > 
> > Assuming "it" is my patch, correct.
> > 
> 
> Recently I was thinking about how to get certain drivers to disallow some or 
> all
> low power states and to me this also seems to fall in a similar category.
> 
> One of the suggestions that I got was to check if the 'wakeup' entry 
> associated with
> the device under sysfs could be leveraged for this. The PM code could maintain
> a whitelist (or blacklist) of devices and it decides the low power state to 
> enter
> based on the 'wakeup' entries associated with these devices. In this 
> particular case,
> maybe the driver could simply set this entry to non-wakeup capable when 
> necessary and
> then let the PM code take care of skipping the wfi execution.
> 
> Thoughts/brickbats welcome :)

You can maybe (ab)use the pm_qos mechanism for this.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe 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 18/18][V3] ARM: OMAP3: cpuidle - set global variables static

[Kevin Hilman]

Daniel Lezcano  writes:

> and check the powerdomain lookup is successful.
>
> Signed-off-by: Daniel Lezcano 
> Reviewed-by: Jean Pihet 
> ---
>  arch/arm/mach-omap2/cpuidle34xx.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
> b/arch/arm/mach-omap2/cpuidle34xx.c
> index 0d28596..116a0d8 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -73,7 +73,7 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
>   },
>  };
>  
> -struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
> +static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
>  
>  static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
>   struct clockdomain *clkdm)
> @@ -252,6 +252,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
>*its own code.
>*/
>  
> + if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
> + return -ENODEV;
> +

Why check here?  cam_pd is actually used just above this code.

Also, this is in the fast path.  This should just be checked once at
init time instead of every idle path.

For those reasons, I've dropped this part of the patch (updated patch
below.)

If desired, you can send an additional patch that adds this error
checking at init time and then refuses to register the driver if any of
the pwrdms don't exist.

Kevin


>From 7870c78d0343ab39050bec01d88cdb19245fdaa9 Mon Sep 17 00:00:00 2001
From: Daniel Lezcano 
Date: Tue, 24 Apr 2012 16:05:39 +0200
Subject: [PATCH] ARM: OMAP3: cpuidle - set global variables static

struct powerdomain varialbes are all file local, make them static.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Jean Pihet 
Reviewed-by: Santosh Shilimkar 
Tested-by: Santosh Shilimkar 
Tested-by: Kevin Hilman 
[khil...@ti.com: update changelog, drop error check in fast path]
Signed-off-by: Kevin Hilman 
---
 arch/arm/mach-omap2/cpuidle34xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d28596..9429c65 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -73,7 +73,7 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
},
 };
 
-struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
+static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
 
 static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
struct clockdomain *clkdm)
-- 
1.7.9.2

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

Re: [PATCH 11/18][V3] ARM: OMAP3: cpuidle - remove the 'valid' field

[Kevin Hilman]

Daniel Lezcano  writes:

> With the previous changes all the states are valid, except
> the last state which can be handled by decreasing the number
> of states.

I don't think this changelog is valid anymore as you're not doing
anything to decrease the number of states.

I updated the changelog locally to this:

ARM: OMAP3: cpuidle - remove the 'valid' field

With the previous changes all the states are valid, except the last
state which is now handled at runtime by next_valid_state() based on
the errata flags.

Any problems with that?

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

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

* Hiremath, Vaibhav  [120503 09:45]:
> 
> What about cpu_is_omap34xx() true for am33xx? Should we follow it?

Well are there components that could be used as is with that?
If not, then it probably does not make sense.

BTW, you should post your patches on top of the clean-up patches
Santosh posted as that already leaves out some cpu_is_omap
checks. That's the "ARM: OMAP2+: Misc cleanup" thread.

Regards,

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

RE: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Bedia, Vaibhav]

On Fri, May 04, 2012 at 00:16:32, Mark A. Greer wrote:
[...]
> > 
> > So, if I understood this correctly, it's effectively like blocking a low 
> > power
> > state transition (here wfi execution) when EMAC is active?
> 
> Assuming "it" is my patch, correct.
> 

Recently I was thinking about how to get certain drivers to disallow some or all
low power states and to me this also seems to fall in a similar category.

One of the suggestions that I got was to check if the 'wakeup' entry associated 
with
the device under sysfs could be leveraged for this. The PM code could maintain
a whitelist (or blacklist) of devices and it decides the low power state to 
enter
based on the 'wakeup' entries associated with these devices. In this particular 
case,
maybe the driver could simply set this entry to non-wakeup capable when 
necessary and
then let the PM code take care of skipping the wfi execution.

Thoughts/brickbats welcome :)

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

Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue

[Russ Dill]

On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj  wrote:
> On Wed, May 2, 2012 at 2:17 PM, Russ Dill  wrote:
>> On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj  
>> wrote:
>>> On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
>>>  wrote:
 From: Keshava Munegowda 

 It is observed that the echi ports of 3430 sdp board
 are not working due to the random timing of programming
 the associated GPIOs of the ULPI PHYs of the EHCI for reset.
 If the PHYs are reset at during usbhs core driver, host ports will
 not work because EHCI driver is loaded after the resetting PHYs.
 The PHYs should be in reset state while initializing the EHCI
 controller.
 The code which does the GPIO pins associated with the PHYs
 are programmed to reset is moved from the USB host core driver
 to EHCI driver.
>>>
>>> I tested on beagle xm where gpio nreset is requested from
>>> board file.
>>> (Basic enumertaion after gpio nreset seems to work fine,
>>> Hub and smsc lan chip get detected afetr boot up)
>>>
>>
>> What base did you test this on top of? my xM is failing USB-wise when
>> I apply this on v3.3.3 (with the UART mux fix patch) and where it is
>> applied within master (3.4-rc4, again, with the UART mux fix patch).
>> Additionally, reverting this patch from 3.4-rc5 causes rc5 to work
>> properly.
>>
>
> Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch
>
> Logs as in here [1].
>
> --
> Thanks,
> Govindraj.R
>
> [1]:
> http://pastebin.pandaboard.org/index.php/view/20343533

I've tracked down the difference. I'm loading my uEnv.txt and uImage
in u-boot from the network which means initializing USB. You are
loading straight from MMC. If I switch to loading straight from MMC
everything works.

Can everyone do a 'usb start' in u-boot before booting and re-test?
I'm pretty sure this is a regression, but the bug could be a strange
u-boot/kernel interaction.
--
To unsubscribe from this list: send the line "unsubscribe 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] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Mark A. Greer]

On Thu, May 03, 2012 at 06:21:27PM +, Bedia, Vaibhav wrote:
> On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
> > On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
> > > On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > > > From: "Mark A. Greer" 
> > > > 
> > > > The davinci EMAC driver has been incorporated into the am35x
> > > > family of SoC's which is OMAP-based.  The incorporation is
> > > > incomplete in that the EMAC cannot unblock the [ARM] core if
> > > > its blocked on a 'wfi' instruction.  This is an issue with
> > > > the cpu_idle code because it has the core execute a 'wfi'
> > > > instruction.
> > > > 
> > > > To work around this issue, add platform data callbacks which
> > > > are called at the beginning of the open routine and at the
> > > > end of the stop routine of the davinci_emac driver.  The
> > > > callbacks allow the platform code to issue disable_hlt() and
> > > > enable_hlt() calls appropriately.  Calling disable_hlt()
> > > > prevents cpu_idle from issuing the 'wfi' instruction.
> > > > 
> > > > It is not sufficient to simply call disable_hlt() when
> > > > there is an EMAC present because it could be present but
> > > > not actually used in which case, we do want the 'wfi' to
> > > > be executed.
> > > > 
> > > 
> > > Are you trying to say that if ARM executes _just_ wfi and _absolutely
> > > nothing else_ is done in the OMAP PM code, EMAC stops working?
> > 
> > No, I'm saying the EMAC can't wake the core from the wfi so if nothing
> > else happens in the system, its effectively hung.  If something else
> > does happen in the system (e.g., a timer expires), the the system is
> > extremely slow because because its only waking up when a timer (or
> > something else wakes it up--but not net traffic).  This is very apparent
> > when using an nfs-mounted rootfs. It doesn't hang but its extremely
> > slow because occasionally something else wakes up the core but it
> > spends most of its time stuck in the wfi when it should be handling
> > net/nfs traffic.
> > 
> 
> So, if I understood this correctly, it's effectively like blocking a low power
> state transition (here wfi execution) when EMAC is active?

Assuming "it" is my patch, correct.

Mark
--
To unsubscribe from this list: send the line "unsubscribe 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] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Bedia, Vaibhav]

On Thu, May 03, 2012 at 21:39:18, Mark A. Greer wrote:
> On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
> > On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > > From: "Mark A. Greer" 
> > > 
> > > The davinci EMAC driver has been incorporated into the am35x
> > > family of SoC's which is OMAP-based.  The incorporation is
> > > incomplete in that the EMAC cannot unblock the [ARM] core if
> > > its blocked on a 'wfi' instruction.  This is an issue with
> > > the cpu_idle code because it has the core execute a 'wfi'
> > > instruction.
> > > 
> > > To work around this issue, add platform data callbacks which
> > > are called at the beginning of the open routine and at the
> > > end of the stop routine of the davinci_emac driver.  The
> > > callbacks allow the platform code to issue disable_hlt() and
> > > enable_hlt() calls appropriately.  Calling disable_hlt()
> > > prevents cpu_idle from issuing the 'wfi' instruction.
> > > 
> > > It is not sufficient to simply call disable_hlt() when
> > > there is an EMAC present because it could be present but
> > > not actually used in which case, we do want the 'wfi' to
> > > be executed.
> > > 
> > 
> > Are you trying to say that if ARM executes _just_ wfi and _absolutely
> > nothing else_ is done in the OMAP PM code, EMAC stops working?
> 
> No, I'm saying the EMAC can't wake the core from the wfi so if nothing
> else happens in the system, its effectively hung.  If something else
> does happen in the system (e.g., a timer expires), the the system is
> extremely slow because because its only waking up when a timer (or
> something else wakes it up--but not net traffic).  This is very apparent
> when using an nfs-mounted rootfs. It doesn't hang but its extremely
> slow because occasionally something else wakes up the core but it
> spends most of its time stuck in the wfi when it should be handling
> net/nfs traffic.
> 

So, if I understood this correctly, it's effectively like blocking a low power
state transition (here wfi execution) when EMAC is active?

--
To unsubscribe from this list: send the line "unsubscribe 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-V6 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime

[Jon Hunter]

Hi Vaibhav,

On 05/03/2012 12:07 AM, Hiremath, Vaibhav wrote:
> On Thu, May 03, 2012 at 01:26:18, Hunter, Jon wrote:
>> Hi Vaibhav,
>>
>> On 05/02/2012 08:56 AM, Vaibhav Hiremath wrote:
>>> Current OMAP code supports couple of clocksource options based
>>> on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
>>> and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
>>>
>>> This patch series cleans up the existing 32k-sync timer implementation,
>>> movind SoC init code to respective files (mach-omap1/timer32k.c and
>>> mach-omap2/timer.c) and uses kernel parameter to override the default
>>> clocksource of "counter_32k", also in order to support some OMAP based
>>> derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP,
>>> adds hwmod lookup for omap2+ devices, and if lookup fails then
>>> fall back to gp-timer.
>>>
>>> if(use_gptimer_clksrc == true)
>>> gptimer clocksource init;
>>> else if (counter_32 init == false)
>>> /* Fallback to gptimer */
>>> gptimer clocksource init(;
>>>
>>> With this, we should be able to support multi-omap boot
>>> including devices with/without 32k-sync timer.
>>>
>>> This patch-series has been boot tested on AM37xEVM platform, it
>>> would be helpful if somebody help me to validate it on OMAP1/2
>>> platforms.
>>>
>>> The patches are also available at (based on linux-omap/master) -
>>> https://github.com/hvaibhav/am335x-linux   32ksync-timer-cleanup
>>
>> I was testing on OMAP4 and I found that the gptimer was always being set by 
>> default. I noticed that currently the HWMOD for counter_32k on OMAP4 is 
>> commented and hence was not being found. Please can you include the 
>> following with your series?
>>
> 
> The 32kcounter hwmod entry is already enabled in linux-omap/master branch.
> 
> Your baseline looks pretty old to me, are you not using linux-omap/master?

Ha! My "old" baseline is the latest mainline kernel ;-)

I guess this is a bit out-dated in terms of omap now. Sorry I missed
that fact your patches were on top of the omap kernel in the changelog.

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

Re: [PATCH] ARM: OMAP2+: watchdog: fix !PM boot crash, disarm timer after hwmod reset

[Kevin Hilman]

Hi Paul,

On 04/20/2012 01:59 PM, Paul Walmsley wrote:

[...]


This looks great, looks like it will finally fix this longstanding bug.  I
think Santosh hit it too a long time ago, so I suspect he will be happy
too.

One comment: I think that omap2_wd_timer_reset() needs to be updated in
light of commit 3c55c1baffa5f719eb2ae9729088bc867f972f53 ("ARM: OMAP2+:
hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for
reset status"").  I did this here.  It's passed basic build testing but
haven't tried booting it yet.  Care to take a look and see if you have any
comments?  It's also available in the 'hwmod_devel_a_3.5' branch of
git://git.pwsan.com/linux-2.6


I just noticed a compile warning with your updated version:

/work/kernel/omap/pm/arch/arm/mach-omap2/wd_timer.c: In function 
'omap2_wd_timer_reset':
/work/kernel/omap/pm/arch/arm/mach-omap2/wd_timer.c:78:6: warning: 
unused variable 'v' [-Wunused-variable]


The diff below on top of your patch fixes it.

Kevin


diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c
index fcbb663..b2f1c67 100644
--- a/arch/arm/mach-omap2/wd_timer.c
+++ b/arch/arm/mach-omap2/wd_timer.c
@@ -75,7 +75,6 @@ int omap2_wd_timer_disable(struct omap_hwmod *oh)
  */
 int omap2_wd_timer_reset(struct omap_hwmod *oh)
 {
-   u32 v;
int c = 0;

/* Write to the SOFTRESET bit */

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

RE: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Hiremath, Vaibhav]

On Thu, May 03, 2012 at 21:27:18, Tony Lindgren wrote:
> Hi,
> 
> * Hiremath, Vaibhav  [120502 02:37]:
> > On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > > Hi
> > > 
> > > On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
> > > 
> > > > From: Afzal Mohammed 
> > > > 
> > > > This patch adds minimal support for AM335X EVM.
> > > > The approach taken here is to add AM335X EVM support
> > > > to AM3517EVM, considering the fact that with device tree
> > > > developement we will get rid of board-*.c.
> > > > 
> > > > Signed-off-by: Afzal Mohammed 
> > > > Signed-off-by: Vaibhav Hiremath 
> > > > Reviewed-by: Kevin Hilman 
> > > 
> > > I realize people may not necessarily like this, but I think that the 
> > > AM33xx EVM needs its own board file.  This is because it really has 
> > > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.
> 
> I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
> except core with omap3. And the SOC is independent of the core selected,
> there is no dependency between SoC and the core.
> 
> Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
> CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
> compile with different flags either.
>  

What about cpu_is_omap34xx() true for am33xx? Should we follow it?


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

Re: [PATCH v2 06/16] block: treat DMPG and SWAPIN requests as special

[S, Venkatraman]

On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer  wrote:
> Venkatraman S  writes:
>
>> From: Ilan Smith 
>>
>> When exp_swapin and exp_dmpg are set, treat read requests
>> marked with DMPG and SWAPIN as high priority and move to
>> the front of the queue.
>>
> [...]
>> +     if (bio_swapin(bio) && blk_queue_exp_swapin(q)) {
>> +             spin_lock_irq(q->queue_lock);
>> +             where = ELEVATOR_INSERT_FLUSH;
>> +             goto get_rq;
>> +     }
>> +
>> +     if (bio_dmpg(bio) && blk_queue_exp_dmpg(q)) {
>> +             spin_lock_irq(q->queue_lock);
>> +             where = ELEVATOR_INSERT_FLUSH;
>> +             goto get_rq;
>
> Is ELEVATOR_INSERT_FRONT not good enough?  It seems wrong to use _FLUSH,
> here.  If the semantics of ELEVATOR_INSERT_FLUSH are really what is
> required, then perhaps we need to have another think about the naming of
> these flags.
>
Actually - yes, ELEVATOR_INSERT_FRONT would do as well. In the
previous version of MMC stack,
we needed the _FLUSH to trigger the write operation that was to be
preempted, to check that
it actually works.


> Cheers,
> Jeff
>
> --
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR

[Tero Kristo]

> > @@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
> >
> >pwrdm_for_each(pwrdms_setup, (void *)d);
> >
> > -   (void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
> > -  &enable_off_mode, &pm_dbg_option_fops);
> > +   if (cpu_is_omap34xx())
> > +   (void) debugfs_create_file("enable_off_mode",
> > +   S_IRUGO | S_IWUSR, d, &enable_off_mode,
> > +   &pm_dbg_option_fops);
> Is the enable_off_mode entry needed on other OMAP platorms (OMAP<3)?

Actually I am not sure, I've never used OMAP2. It looks like at least
the kernel does not support off-mode for OMAP2, but according to TRM it
might be possible to support it on HW.

-Tero

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

Re: [PATCH] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Mark A. Greer]

On Thu, May 03, 2012 at 10:44:44AM +, Bedia, Vaibhav wrote:
> On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
> > From: "Mark A. Greer" 
> > 
> > The davinci EMAC driver has been incorporated into the am35x
> > family of SoC's which is OMAP-based.  The incorporation is
> > incomplete in that the EMAC cannot unblock the [ARM] core if
> > its blocked on a 'wfi' instruction.  This is an issue with
> > the cpu_idle code because it has the core execute a 'wfi'
> > instruction.
> > 
> > To work around this issue, add platform data callbacks which
> > are called at the beginning of the open routine and at the
> > end of the stop routine of the davinci_emac driver.  The
> > callbacks allow the platform code to issue disable_hlt() and
> > enable_hlt() calls appropriately.  Calling disable_hlt()
> > prevents cpu_idle from issuing the 'wfi' instruction.
> > 
> > It is not sufficient to simply call disable_hlt() when
> > there is an EMAC present because it could be present but
> > not actually used in which case, we do want the 'wfi' to
> > be executed.
> > 
> 
> Are you trying to say that if ARM executes _just_ wfi and _absolutely
> nothing else_ is done in the OMAP PM code, EMAC stops working?

No, I'm saying the EMAC can't wake the core from the wfi so if nothing
else happens in the system, its effectively hung.  If something else
does happen in the system (e.g., a timer expires), the the system is
extremely slow because because its only waking up when a timer (or
something else wakes it up--but not net traffic).  This is very apparent
when using an nfs-mounted rootfs. It doesn't hang but its extremely
slow because occasionally something else wakes up the core but it
spends most of its time stuck in the wfi when it should be handling
net/nfs traffic.

> However, if this is indeed the case, then probably a better solution would be
> to invoke disable_hlt() from the board file when EMAC support is compiled in.

Kevin addressed this one.  Thanks Kevin.

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

Re: [PATCH-V5 2/3] arm:omap:am33xx: Add AM335XEVM machine support

[Tony Lindgren]

Hi,

* Hiremath, Vaibhav  [120502 02:37]:
> On Wed, May 02, 2012 at 14:53:24, Paul Walmsley wrote:
> > Hi
> > 
> > On Fri, 2 Dec 2011, hvaib...@ti.com wrote:
> > 
> > > From: Afzal Mohammed 
> > > 
> > > This patch adds minimal support for AM335X EVM.
> > > The approach taken here is to add AM335X EVM support
> > > to AM3517EVM, considering the fact that with device tree
> > > developement we will get rid of board-*.c.
> > > 
> > > Signed-off-by: Afzal Mohammed 
> > > Signed-off-by: Vaibhav Hiremath 
> > > Reviewed-by: Kevin Hilman 
> > 
> > I realize people may not necessarily like this, but I think that the 
> > AM33xx EVM needs its own board file.  This is because it really has 
> > nothing to do with the AM3517EVM.  Also, the AM3517EVM depends on 
> > CONFIG_ARCH_OMAP3, but the AM33xx EVM should not: it should depend on 
> > either CONFIG_ARCH_OMAPAM33XX, or CONFIG_ARCH_OMAP4.

I guess adding CONFIG_SOC_AM33XX makes sense if it does not share anything
except core with omap3. And the SOC is independent of the core selected,
there is no dependency between SoC and the core.

Note that we have CONFIG_ARCH_OMAP2PLUS, all the other ones should be just
CONFIG_SOC_XXX. As all omap3 omap4 and am33xx are v7, there's no need to
compile with different flags either.
 
> > So the following modification of this patch opts for the former Kconfig 
> > option, CONFIG_ARCH_OMAPAM33XX.  It also adds a new, minimal board file 
> > for the AM33xx EVM.  

Sorry, no more new board files. Please make it device tree only then.

> > If, on the other hand, people want to use CONFIG_ARCH_OMAP4 instead for 
> > the AM33xx, then we could potentially add the new machine record into 
> > board-omap4panda.c.  Although even then, if political considerations were 
> > set aside, the best technical decision would probably be to create a 
> > separate board file, since the boards don't have much in common.
> > 
> > 
> Paul,
> I completely agree with all of your comments, let Tony comment and conform 
> on this. 
> If you go back to history, that was our initial proposal, to create
> separate Kconfig option for AM33XX.
> 
> Tony,
> 
> Can you please comment on this discussion? This is very important, since 
> lots of patches (accepted or about to accept) are dependent on this. The 
> early we can conclude on this, early I can rework on the patches and 
> resubmit them.

Yes, please do. Also note that if this means sprinkling tons of cpu_is_omapxxx
all over the code, we need to find a cleaner solution.

Regards,

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

Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf

[Tony Lindgren]

Hi,

* Jean-Christophe PLAGNIOL-VILLARD  [120503 00:16]:
> 
>   I really like it
> 
>   I was working on something simillar
> 
>   but can we split the group management so we can use it on other
>   bindings

Hmm I'm not sure I follow on the group management splitting, can you specify
what you have in mind here?

If you mean moving more things into pinctrl fwk, then yeah I'd assume that
will happen eventually and drivers like this will end up becoming more minimal.

Regards,

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

RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain & PRM support for AM33XX device

[Hiremath, Vaibhav]

On Wed, May 02, 2012 at 15:00:28, Paul Walmsley wrote:
> 
> Hello Vaibhav,
> 
> I've reworked these patches somewhat to separate the PRM and CM changes 
> into their own patches.  Also, the omap_hwmod changes have been separated 
> and moved into a different series, as have the clock tree changes.
> 
> So now, pending for 3.5, there are the SCM, voltagedomain, PRM, CM, 
> powerdomain, and clockdomain changes.  Under the (probably incorrect) 
> assumption that Tony will opt to create a CONFIG_ARCH_OMAPAM33XX, you 
> might wish to take a look at the 'am33xx_prcm_devel_3.5' branch of 
> git://git.pwsan.com/linux-2.6.  It is based on four patches, not yet 
> upstream, which create the appropriate board file, Kconfig options, etc.
> 
> Once we're able to reach a conclusion as to which of the CONFIG_ARCH_OMAP* 
> options the AM33xx belongs under, this branch will be updated and 
> reposted, and if everyone is happy with it, proposed for pulling. 
> 

Hi Paul,

I have reviewed the "am33xx_prcm_devel_3.5" branch for AM33xx support,
and below are few comments I have,


1) ARM: add CONFIG_ARCH_OMAP{AM33XX,TI81XX}

Description talks about TI81xx as well, but patch is created only for AM33xx.
Isn't same entry should be created for TI81xx in the patch?

2) ARM: OMAP: AM335x: add Kconfig, Makefile glue for CONFIG_ARCH_OMAPAM33XX

Looks ok to me. (Acked-by: Vaibhav Hiremath )

3) ARM: OMAP: AM33xx: Add AM335XEVM machine support

Looks ok to me.

4) arm:omap:am33xx: Add low level debugging support 

Subject line need to change to match it with our convention.

ARM: OMAP: am33xx: Add low level debugging support

5) ARM: OMAP2+: control: Add AM33XX control reg & sec clkctrl offset

Looks ok to me.

6) ARM: OMAP3+: am33xx: Add voltage domain data

Remove multiple entries for voltagedomain-common.o for AM33xx

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index cc44ea9..3b953c7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -109,7 +109,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX)+= 
$(voltagedomain-common) \
   voltagedomains33xx_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += $(voltagedomain-common) \
   voltagedomains44xx_data.o
-obj-$(CONFIG_ARCH_OMAPAM33XX)  += $(voltagedomain-common)


7) ARM: OMAP3+: am33xx: add PRM support

Remove multiple entries for prcm.o for AM33xx

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3b953c7..ae1399b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -96,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP4)  += prcm.o cm2xxx_3xxx.o 
cminst44xx.o \
   cm44xx.o prcm_mpu44xx.o \
   prminst44xx.o vc44xx_data.o \
   vp44xx_data.o prm44xx.o
-obj-$(CONFIG_ARCH_OMAPAM33XX)  += prcm.o


8) ARM: OMAP3+: cm33xx: Introduce AM33xx CM API's and register level details

Looks ok to me.

9) ARM: OMAP2+: powerdomain: add AM335x support

Remove multiple entries for target powerdomain-common for AM33xx


diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ae1399b..1147352 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -126,7 +126,6 @@ obj-$(CONFIG_SOC_OMAPAM33XX)+= 
$(powerdomain-common) \
 obj-$(CONFIG_ARCH_OMAP4)   += $(powerdomain-common) \
   powerdomain44xx.o \
   powerdomains44xx_data.o
-obj-$(CONFIG_ARCH_OMAPAM33XX)  += $(powerdomain-common)


10) ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations

Looks ok to me.



Paul,

I have also boot tested it on BeagleBone, since we would not catch any
issues from the changes. It is highly impossible to catch just by reviewing 
the patch or checking for build test. So I ported merged clocktree and hwmod
patches to see whether it boots up on BeagleBone, and found that, we need 
further changes here -

===diff for BeagleBone boot==
diff --git a/arch/arm/mach-omap2/board-am335xevm.c 
b/arch/arm/mach-omap2/board-am335xevm.c
index 324752e..69d8aae 100644
--- a/arch/arm/mach-omap2/board-am335xevm.c
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -41,6 +41,7 @@ MACHINE_START(AM335XEVM, "am335xevm")
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
.init_irq   = ti81xx_init_irq,
+   .handle_irq = omap3_intc_handle_irq,
.timer  = &omap3_am33xx_timer,
.init_machine   = am335x_evm_init,
 MACHINE_END

diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..77467b3 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -134,6 +134,9 @@ void __init ti81xx_map_io(void)
 

Re: [PATCH v2 06/16] block: treat DMPG and SWAPIN requests as special

[Jeff Moyer]

Venkatraman S  writes:

> From: Ilan Smith 
>
> When exp_swapin and exp_dmpg are set, treat read requests
> marked with DMPG and SWAPIN as high priority and move to
> the front of the queue.
>
[...]
> + if (bio_swapin(bio) && blk_queue_exp_swapin(q)) {
> + spin_lock_irq(q->queue_lock);
> + where = ELEVATOR_INSERT_FLUSH;
> + goto get_rq;
> + }
> +
> + if (bio_dmpg(bio) && blk_queue_exp_dmpg(q)) {
> + spin_lock_irq(q->queue_lock);
> + where = ELEVATOR_INSERT_FLUSH;
> + goto get_rq;

Is ELEVATOR_INSERT_FRONT not good enough?  It seems wrong to use _FLUSH,
here.  If the semantics of ELEVATOR_INSERT_FLUSH are really what is
required, then perhaps we need to have another think about the naming of
these flags.

Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe 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 01/16] FS: Added demand paging markers to filesystem

[Venkatraman S]

From: Ilan Smith 

Add attribute to identify demand paging requests.
Mark readpages with demand paging attribute.

Signed-off-by: Ilan Smith 
Signed-off-by: Alex Lemberg 
Signed-off-by: Venkatraman S 
---
 fs/mpage.c|2 ++
 include/linux/bio.h   |7 +++
 include/linux/blk_types.h |2 ++
 3 files changed, 11 insertions(+)

diff --git a/fs/mpage.c b/fs/mpage.c
index 0face1c..8b144f5 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping, struct 
list_head *pages,
&last_block_in_bio, &map_bh,
&first_logical_block,
get_block);
+   if (bio)
+   bio->bi_rw |= REQ_RW_DMPG;
}
page_cache_release(page);
}
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 4d94eb8..264e0ef 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -57,6 +57,13 @@
(bio)->bi_rw |= ((unsigned long) (prio) << BIO_PRIO_SHIFT); \
 } while (0)
 
+static inline bool bio_rw_flagged(struct bio *bio, unsigned long flag)
+{
+   return ((bio->bi_rw & flag)  != 0);
+}
+
+#define bio_dmpg(bio)  bio_rw_flagged(bio, REQ_RW_DMPG)
+
 /*
  * various member access, note that bio_data should of course not be used
  * on highmem page vectors
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 4053cbd..87feb80 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -150,6 +150,7 @@ enum rq_flag_bits {
__REQ_FLUSH_SEQ,/* request for flush sequence */
__REQ_IO_STAT,  /* account I/O stat */
__REQ_MIXED_MERGE,  /* merge of different types, fail separately */
+   __REQ_RW_DMPG,
__REQ_NR_BITS,  /* stops here */
 };
 
@@ -191,5 +192,6 @@ enum rq_flag_bits {
 #define REQ_IO_STAT(1 << __REQ_IO_STAT)
 #define REQ_MIXED_MERGE(1 << __REQ_MIXED_MERGE)
 #define REQ_SECURE (1 << __REQ_SECURE)
+#define REQ_RW_DMPG(1 << __REQ_RW_DMPG)
 
 #endif /* __LINUX_BLK_TYPES_H */
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 06/16] block: treat DMPG and SWAPIN requests as special

[Venkatraman S]

From: Ilan Smith 

When exp_swapin and exp_dmpg are set, treat read requests
marked with DMPG and SWAPIN as high priority and move to
the front of the queue.

Signed-off-by: Ilan Smith 
Signed-off-by: Alex Lemberg 
Signed-off-by: Venkatraman S 
---
 block/blk-core.c |   18 ++
 block/elevator.c |   14 +-
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 1f61b74..7a1b98b 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1306,6 +1306,12 @@ void init_request_from_bio(struct request *req, struct 
bio *bio)
if (bio->bi_rw & REQ_RAHEAD)
req->cmd_flags |= REQ_FAILFAST_MASK;
 
+   if (bio_swapin(bio) && blk_queue_exp_swapin(req->q))
+   req->cmd_flags |= REQ_RW_SWAPIN | REQ_NOMERGE;
+
+   if (bio_dmpg(bio) && blk_queue_exp_dmpg(req->q))
+   req->cmd_flags |= REQ_RW_DMPG | REQ_NOMERGE;
+
req->errors = 0;
req->__sector = bio->bi_sector;
req->ioprio = bio_prio(bio);
@@ -1333,6 +1339,18 @@ void blk_queue_bio(struct request_queue *q, struct bio 
*bio)
goto get_rq;
}
 
+   if (bio_swapin(bio) && blk_queue_exp_swapin(q)) {
+   spin_lock_irq(q->queue_lock);
+   where = ELEVATOR_INSERT_FLUSH;
+   goto get_rq;
+   }
+
+   if (bio_dmpg(bio) && blk_queue_exp_dmpg(q)) {
+   spin_lock_irq(q->queue_lock);
+   where = ELEVATOR_INSERT_FLUSH;
+   goto get_rq;
+   }
+
/*
 * Check if we can merge with the plugged list before grabbing
 * any locks.
diff --git a/block/elevator.c b/block/elevator.c
index f016855..76d571b 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -367,7 +367,8 @@ void elv_dispatch_sort(struct request_queue *q, struct 
request *rq)
q->nr_sorted--;
 
boundary = q->end_sector;
-   stop_flags = REQ_SOFTBARRIER | REQ_STARTED;
+   stop_flags = REQ_SOFTBARRIER | REQ_STARTED
+   | REQ_RW_SWAPIN | REQ_RW_DMPG ;
list_for_each_prev(entry, &q->queue_head) {
struct request *pos = list_entry_rq(entry);
 
@@ -585,6 +586,17 @@ void elv_quiesce_end(struct request_queue *q)
 
 void __elv_add_request(struct request_queue *q, struct request *rq, int where)
 {
+   unsigned int hpi_flags = REQ_RW_DMPG | REQ_RW_SWAPIN;
+
+   if (rq->cmd_flags & hpi_flags) {
+   /*
+* Insert swap-in or demand page requests at the front. This
+* causes them to be queued in the reversed order.
+*/
+   where = ELEVATOR_INSERT_FRONT;
+   } else
+
+
trace_block_rq_insert(q, rq);
 
rq->q = q;
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 11/16] mmc: core: Implement foreground request preemption procedure

[Venkatraman S]

When invoked, ongoing command at the host controller should abort
and completion should be invoked.

It's quite possible that the interruption will race with the
successful completion of the command. If so, HPI is invoked
only when the low level driver sets an error flag for the
aborted request.

Signed-off-by: Venkatraman S 
---
 drivers/mmc/core/core.c  |   32 
 include/linux/mmc/core.h |2 ++
 2 files changed, 34 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 3f0e927..e6430f8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -466,6 +466,38 @@ out:
 }
 EXPORT_SYMBOL(mmc_interrupt_hpi);
 
+int mmc_preempt_foreground_request(struct mmc_card *card,
+   struct mmc_request *req)
+{
+   int ret;
+
+   ret = mmc_abort_req(card->host, req);
+   if (ret == -ENOSYS)
+   return ret;
+   /*
+* Whether or not abort was successful, the command is
+* still under the host controller's context.
+* Should wait for the completion to be returned.
+*/
+   wait_for_completion(&req->completion);
+   /*
+* Checkpoint the aborted request.
+* If error is set, the request completed partially,
+* and the ext_csd field "CORRECTLY_PRG_SECTORS_NUM"
+* contains the number of blocks written to the device.
+* If error is not set, the request was completed
+* successfully and there is no need to try it again.
+*/
+   if (req->data && req->data->error) {
+   mmc_interrupt_hpi(card);
+   /* TODO : Take out the CORRECTLY_PRG_SECTORS_NUM
+* from ext_csd and add it to the request */
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mmc_preempt_foreground_request);
+
 /**
  * mmc_wait_for_cmd - start a command and wait for completion
  * @host: MMC host to start command
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index d86144e..e2d55c6 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -144,6 +144,8 @@ extern struct mmc_async_req *mmc_start_req(struct mmc_host 
*,
 extern int mmc_interrupt_hpi(struct mmc_card *);
 extern void mmc_wait_for_req(struct mmc_host *, struct mmc_request *);
 extern int mmc_wait_for_cmd(struct mmc_host *, struct mmc_command *, int);
+extern int mmc_preempt_foreground_request(struct mmc_card *card,
+   struct mmc_request *req);
 extern int mmc_app_cmd(struct mmc_host *, struct mmc_card *);
 extern int mmc_wait_for_app_cmd(struct mmc_host *, struct mmc_card *,
struct mmc_command *, int);
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 10/16] mmc: block: Detect HPI support in card and host controller

[Venkatraman S]

If both the card and host controller support HPI related
operations, set a flag in MMC queue to remember it.

Signed-off-by: Venkatraman S 
---
 drivers/mmc/card/block.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index dabec55..11833e4 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -88,6 +88,7 @@ struct mmc_blk_data {
unsigned intflags;
 #define MMC_BLK_CMD23  (1 << 0)/* Can do SET_BLOCK_COUNT for 
multiblock */
 #define MMC_BLK_REL_WR (1 << 1)/* MMC Reliable write support */
+#define MMC_HPI_SUPPORT(1 << 2)
 
unsigned intusage;
unsigned intread_only;
@@ -1548,12 +1549,15 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct 
mmc_card *card,
md->flags |= MMC_BLK_CMD23;
}
 
-   if (mmc_card_mmc(card) &&
-   md->flags & MMC_BLK_CMD23 &&
+   if (mmc_card_mmc(card)) {
+   if (md->flags & MMC_BLK_CMD23 &&
((card->ext_csd.rel_param & EXT_CSD_WR_REL_PARAM_EN) ||
 card->ext_csd.rel_sectors)) {
-   md->flags |= MMC_BLK_REL_WR;
-   blk_queue_flush(md->queue.queue, REQ_FLUSH | REQ_FUA);
+   md->flags |= MMC_BLK_REL_WR;
+   blk_queue_flush(md->queue.queue, REQ_FLUSH | REQ_FUA);
+   }
+   if (card->host->ops->abort_req && card->ext_csd.hpi_en)
+   md->flags |= MMC_HPI_SUPPORT;
}
 
return md;
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 13/16] mmc: Documentation: Add sysfs ABI for hpi_time_threshold

[Venkatraman S]

hpi_time_threshold can be set to configure elapsed time in ms,
after which an ongoing request will not be preempted.
Explain the hpi_time_threhold parameter for MMC devices.

Signed-off-by: Venkatraman S 
---
 Documentation/ABI/testing/sysfs-devices-mmc |   12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-devices-mmc 
b/Documentation/ABI/testing/sysfs-devices-mmc
index 5a50ab6..133dba5 100644
--- a/Documentation/ABI/testing/sysfs-devices-mmc
+++ b/Documentation/ABI/testing/sysfs-devices-mmc
@@ -19,3 +19,15 @@ Description:
is enabled, this attribute will indicate the size of enhanced
data area. If not, this attribute will be -EINVAL.
Unit KByte. Format decimal.
+
+What:  /sys/devices/.../mmc_host/mmcX/mmcX:/hpi_time_threshold
+Date:  April 2012
+Contact:   Venkatraman S 
+Description:
+   High Priority Interrupt is a new feature defined in eMMC4.4
+   standard. If this feature is enabled, stack needs to decide
+   till what time since the last issued request is considered
+   preemptible. This attribute value (in milliseconds) is
+   used for arriving at the most optimal value for a specific
+   card. Default is zero, which also disables the feature, as
+   the request becomes non-preemptible immediately.
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 14/16] mmc: block: Implement HPI invocation and handling logic.

[Venkatraman S]

Intercept command which require high priority treatment.
If the ongoing command can be preempted according to JEDEC HPI
definition and sufficient window exist to complete an ongoing
request, invoke HPI and abort the current request, and issue
the high priority request.
Otherwise, process the command normally.

Signed-off-by: Venkatraman S 
---
 drivers/mmc/card/block.c |  131 +++---
 drivers/mmc/card/queue.h |1 +
 2 files changed, 124 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 11833e4..3dd662b 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1276,7 +1276,7 @@ static int mmc_blk_cmd_err(struct mmc_blk_data *md, 
struct mmc_card *card,
return ret;
 }
 
-static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
+static int mmc_blk_execute_rw_rq(struct mmc_queue *mq, struct request *rqc)
 {
struct mmc_blk_data *md = mq->data;
struct mmc_card *card = md->queue.card;
@@ -1285,22 +1285,31 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, 
struct request *rqc)
enum mmc_blk_status status;
struct mmc_queue_req *mq_rq;
struct request *req;
-   struct mmc_async_req *areq;
+   struct mmc_async_req *prev_req, *cur_req;
 
if (!rqc && !mq->mqrq_prev->req)
return 0;
 
+   mq->mqrq_interrupted = NULL;
+
do {
if (rqc) {
mmc_blk_rw_rq_prep(mq->mqrq_cur, card, 0, mq);
-   areq = &mq->mqrq_cur->mmc_active;
-   } else
-   areq = NULL;
-   areq = mmc_start_req(card->host, areq, (int *) &status);
-   if (!areq)
+   cur_req = &mq->mqrq_cur->mmc_active;
+   } else {
+   cur_req = NULL;
+   }
+   prev_req = mmc_start_req(card->host, cur_req, (int *) &status);
+   if (!prev_req)
return 0;
 
-   mq_rq = container_of(areq, struct mmc_queue_req, mmc_active);
+   if (cur_req &&
+   cur_req->mrq->cmd->cmd_attr & MMC_CMD_PREEMPTIBLE) {
+   mq->mqrq_interrupted = mq->mqrq_cur;
+   }
+
+   mq_rq = container_of(prev_req,
+   struct mmc_queue_req, mmc_active);
brq = &mq_rq->brq;
req = mq_rq->req;
type = rq_data_dir(req) == READ ? MMC_BLK_READ : MMC_BLK_WRITE;
@@ -1406,6 +1415,112 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, 
struct request *rqc)
return 0;
 }
 
+#define HPI_CHECK  (REQ_RW_SWAPIN | REQ_RW_DMPG)
+
+static bool mmc_can_do_foreground_hpi(struct mmc_queue *mq,
+   struct request *req, unsigned int thpi)
+{
+
+   /*
+* If some time has elapsed since the issuing of previous write
+* command, or if the size of the request was too small, there's
+* no point in preempting it. Check if it's worthwhile to preempt
+*/
+   int time_elapsed = jiffies_to_msecs(jiffies -
+   mq->mqrq_cur->mmc_active.mrq->cmd->started_time);
+
+   if (time_elapsed <= thpi)
+   return true;
+
+   return false;
+}
+
+/*
+ * When a HPI command had been given for a foreground
+ * request, the host controller will finish the request,
+ * the completion request has to be handled differently
+ */
+static struct mmc_async_req *mmc_handle_aborted_request(struct mmc_queue *mq,
+   int hpi_err)
+{
+   struct mmc_async_req *areq;
+   struct mmc_request *mrq;
+   struct mmc_queue_req *mq_rq;
+   struct mmc_blk_data *md = mq->data;
+   struct request *req;
+
+   BUG_ON(!mq->mqrq_interrupted);
+
+   areq = &mq->mqrq_interrupted->mmc_active;
+   mrq = areq->mrq;
+
+   /* Error checking is TBD */
+   mq_rq = container_of(areq, struct mmc_queue_req, mmc_active);
+   req = mq_rq->req;
+   mmc_queue_bounce_post(mq_rq);
+
+   spin_lock_irq(&md->lock);
+   /*
+* TODO. Do the error translation as done in
+* blk_err_check here and propogate
+* the partial transfer status if applicable
+*/
+   __blk_end_request(req, -EIO, 0);
+   spin_unlock_irq(&md->lock);
+   return areq;
+}
+
+static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
+{
+   int ret;
+   struct mmc_blk_data *md = mq->data;
+   struct mmc_card *card = md->queue.card;
+   struct mmc_async_req *areq;
+
+   if (req && md->flags & MMC_HPI_SUPPORT) {
+   if (!((req->cmd_flags & HPI_CHECK) && mq->mqrq_interrupted))
+   goto no_preempt;
+   if (!mmc_can_do_foreground_hpi(mq, req,
+   card->preempt_time_threshold))
+   goto no_preempt;
+
+   pr_debug("Pre-emp

[PATCH v2 12/16] mmc: sysfs: Add sysfs entry for tuning preempt_time_threshold

[Venkatraman S]

When High Priority Interrupt (HPI) is enabled, ongoing requests
might be preempted. It is worthwhile to not preempt some requests
which have progressed in the underlying driver for some time.

The threshold of elapsed time after which HPI is not useful can
be tuned on a per-device basis, using the hpi_time_threshold
sysfs entry.

Signed-off-by: Venkatraman S 
---
 drivers/mmc/core/mmc.c   |   25 +
 include/linux/mmc/card.h |1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 54df5ad..b7dbea1 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -624,6 +624,30 @@ MMC_DEV_ATTR(enhanced_area_offset, "%llu\n",
card->ext_csd.enhanced_area_offset);
 MMC_DEV_ATTR(enhanced_area_size, "%u\n", card->ext_csd.enhanced_area_size);
 
+static ssize_t mmc_hpi_threhold_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct mmc_card *card = mmc_dev_to_card(dev);
+   return sprintf(buf, "%d\n", card->preempt_time_threshold);
+}
+
+static ssize_t mmc_hpi_threshold_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   unsigned long threshold;
+   struct mmc_card *card = mmc_dev_to_card(dev);
+
+   if (kstrtoul(buf, 0, &threshold))
+   return -EINVAL;
+   if (threshold)
+   card->preempt_time_threshold = threshold;
+   return count;
+}
+
+DEVICE_ATTR(hpi_time_threshold, S_IRWXU, mmc_hpi_threhold_show,
+   mmc_hpi_threshold_store);
+
 static struct attribute *mmc_std_attrs[] = {
&dev_attr_cid.attr,
&dev_attr_csd.attr,
@@ -638,6 +662,7 @@ static struct attribute *mmc_std_attrs[] = {
&dev_attr_serial.attr,
&dev_attr_enhanced_area_offset.attr,
&dev_attr_enhanced_area_size.attr,
+   &dev_attr_hpi_time_threshold.attr,
NULL,
 };
 
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 629b823..2a0da29 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -245,6 +245,7 @@ struct mmc_card {
unsigned interase_shift;/* if erase unit is power 2 */
unsigned intpref_erase; /* in sectors */
u8  erased_byte;/* value of erased bytes */
+   unsigned int preempt_time_threshold;/* ms for checking hpi usage */
 
u32 raw_cid[4]; /* raw card CID */
u32 raw_csd[4]; /* raw card CSD */
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 09/16] mmc: core: Add MMC abort interface

[Venkatraman S]

HPI (and possibly other) procedures require that an ongoing
mmc request issued to a controller be aborted in the middle
of a transaction. Define a abort interface function to the
controller so that individual host controllers can safely
abort a request, stop the dma and cleanup their statemachine
etc. The implementation is controller dependant

Signed-off-by: Venkatraman S 
---
 drivers/mmc/core/core.c  |8 
 include/linux/mmc/host.h |1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index b4152ca..3f0e927 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -328,6 +328,14 @@ static void mmc_post_req(struct mmc_host *host, struct 
mmc_request *mrq,
}
 }
 
+static int mmc_abort_req(struct mmc_host *host, struct mmc_request *req)
+{
+   if (host->ops->abort_req)
+   return host->ops->abort_req(host, req);
+
+   return -ENOSYS;
+}
+
 /**
  * mmc_start_req - start a non-blocking request
  * @host: MMC host to start command
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 0707d22..d700703 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -98,6 +98,7 @@ struct mmc_host_ops {
int err);
void(*pre_req)(struct mmc_host *host, struct mmc_request *req,
   bool is_first_req);
+   int (*abort_req)(struct mmc_host *host, struct mmc_request *req);
void(*request)(struct mmc_host *host, struct mmc_request *req);
/*
 * Avoid calling these three functions too often or in a "fast path",
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 08/16] mmc: core: add preemptibility tracking fields to mmc command

[Venkatraman S]

Set a preemptibility command atrribute to MMC commands. This
can be later used by write (multi block), trim etc for
evaluating if a HPI is applicable.

Note the starting time of executing a command so a decision
can be made if it is too late for preemption.

Signed-off-by: Venkatraman S 
---
 drivers/mmc/core/core.c  |5 +
 include/linux/mmc/core.h |4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index c4cd6fb..b4152ca 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -258,6 +258,11 @@ static int __mmc_start_req(struct mmc_host *host, struct 
mmc_request *mrq)
complete(&mrq->completion);
return -ENOMEDIUM;
}
+   if (mmc_is_preemptible_command(mrq->cmd))
+   mrq->cmd->cmd_attr |= MMC_CMD_PREEMPTIBLE;
+   else
+   mrq->cmd->cmd_attr &= ~MMC_CMD_PREEMPTIBLE;
+   mrq->cmd->started_time = jiffies;
mmc_start_request(host, mrq);
return 0;
 }
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 680e256..d86144e 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -76,6 +76,10 @@ struct mmc_command {
  */
 #define mmc_cmd_type(cmd)  ((cmd)->flags & MMC_CMD_MASK)
 
+   unsigned intcmd_attr; /*Runtime attributes of the command */
+#define MMC_CMD_PREEMPTIBLEBIT(0)
+#define MMC_CMD_PREEMPTED  BIT(1)
+   unsigned long   started_time;
unsigned intretries;/* max number of retries */
unsigned interror;  /* command error */
 
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 07/16] mmc: core: helper function for finding preemptible command

[Venkatraman S]

According to table30 in eMMC spec, only some commands
can be preempted by foreground HPI. Provide a helper function
for the HPI procedure to identify if the command is
preemptible.

Signed-off-by: Venkatraman S 
---
 include/linux/mmc/core.h |   13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 1b431c7..680e256 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 
 struct request;
 struct mmc_data;
@@ -192,6 +193,18 @@ static inline void mmc_claim_host(struct mmc_host *host)
__mmc_claim_host(host, NULL);
 }
 
+static inline bool mmc_is_preemptible_command(struct mmc_command *cmd)
+{
+   if ((cmd->opcode == MMC_SWITCH && (cmd->arg == EXT_CSD_BKOPS_START ||
+   cmd->arg == EXT_CSD_SANITIZE_START ||
+   cmd->arg == EXT_CSD_FLUSH_CACHE))
+   || (cmd->opcode == MMC_ERASE)
+   || (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK)
+   || (cmd->opcode == MMC_WRITE_BLOCK))
+   return true;
+   return false;
+}
+
 extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
 
 #endif /* LINUX_MMC_CORE_H */
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 04/16] block: add sysfs attributes for runtime control of dpmg and swapin

[Venkatraman S]

sysfs entries for DPMG and SWAPIN requests so that they can
be set/reset from userspace.

Signed-off-by: Venkatraman S 
---
 block/blk-sysfs.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index cf15001..764de9f 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -213,6 +213,8 @@ queue_store_##name(struct request_queue *q, const char 
*page, size_t count) \
 }
 
 QUEUE_SYSFS_BIT_FNS(nonrot, NONROT, 1);
+QUEUE_SYSFS_BIT_FNS(expedite_dmpg, EXP_DMPG, 0);
+QUEUE_SYSFS_BIT_FNS(expedite_swapin, EXP_SWAPIN, 0);
 QUEUE_SYSFS_BIT_FNS(random, ADD_RANDOM, 0);
 QUEUE_SYSFS_BIT_FNS(iostats, IO_STAT, 0);
 #undef QUEUE_SYSFS_BIT_FNS
@@ -387,6 +389,18 @@ static struct queue_sysfs_entry queue_random_entry = {
.store = queue_store_random,
 };
 
+static struct queue_sysfs_entry queue_dmpg_entry = {
+   .attr = {.name = "expedite_demandpaging", .mode = S_IRUGO | S_IWUSR },
+   .show = queue_show_expedite_dmpg,
+   .store = queue_store_expedite_dmpg,
+};
+
+static struct queue_sysfs_entry queue_swapin_entry = {
+   .attr = {.name = "expedite_swapping", .mode = S_IRUGO | S_IWUSR },
+   .show = queue_show_expedite_swapin,
+   .store = queue_store_expedite_swapin,
+};
+
 static struct attribute *default_attrs[] = {
&queue_requests_entry.attr,
&queue_ra_entry.attr,
@@ -409,6 +423,8 @@ static struct attribute *default_attrs[] = {
&queue_rq_affinity_entry.attr,
&queue_iostats_entry.attr,
&queue_random_entry.attr,
+   &queue_dmpg_entry.attr,
+   &queue_swapin_entry.attr,
NULL,
 };
 
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 05/16] block: Documentation: add sysfs ABI for expedite_dmpg and expedite_swapin

[Venkatraman S]

Add description on the usage of expedite_dmpg and
expedite_swapin.

Signed-off-by: Venkatraman S 
---
 Documentation/ABI/testing/sysfs-block |   12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-block 
b/Documentation/ABI/testing/sysfs-block
index c1eb41c..0fb9fef 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -206,3 +206,15 @@ Description:
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.
+
+What:  /sys/block//queue/expedite_demandpaging
+What:  /sys/block//queue/expedite_swapin
+Date:  April 2012
+Contact:   Venkatraman S 
+Description:
+   For latency improvements, some storage devices could
+   provide a mechanism for servicing demand paging and
+   swapin requests in a high priority manner. Setting
+   these flags to 1 would get the requests marked with
+   REQ_RW_DMPG or REQ_RW_SWAPIN to be moved to the front
+   of elevator queue.
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 03/16] block: add queue attributes to manage dpmg and swapin requests

[Venkatraman S]

Add block queue properties to identify and manage demand paging
and swapin requests differently.

Signed-off-by: Ilan Smith 
Signed-off-by: Alex Lemberg 
Signed-off-by: Venkatraman S 
---
 include/linux/blkdev.h |8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 2aa2466..e9187d4 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -420,6 +420,8 @@ struct request_queue {
 #define QUEUE_FLAG_ADD_RANDOM  16  /* Contributes to random pool */
 #define QUEUE_FLAG_SECDISCARD  17  /* supports SECDISCARD */
 #define QUEUE_FLAG_SAME_FORCE  18  /* force complete on same CPU */
+#define QUEUE_FLAG_EXP_DMPG19  /* Expedite Demand paging requests */
+#define QUEUE_FLAG_EXP_SWAPIN  20  /* Expedit page swapping */
 
 #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) |\
 (1 << QUEUE_FLAG_STACKABLE)|   \
@@ -502,6 +504,12 @@ static inline void queue_flag_clear(unsigned int flag, 
struct request_queue *q)
 #define blk_queue_secdiscard(q)(blk_queue_discard(q) && \
test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags))
 
+#define blk_queue_exp_dmpg(q) \
+   test_bit(QUEUE_FLAG_EXP_DMPG, &(q)->queue_flags)
+
+#define blk_queue_exp_swapin(q) \
+   test_bit(QUEUE_FLAG_EXP_SWAPIN, &(q)->queue_flags)
+
 #define blk_noretry_request(rq) \
((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
 REQ_FAILFAST_DRIVER))
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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 02/16] MM: Added page swapping markers to memory management

[Venkatraman S]

From: Ilan Smith 

Add attribute to identify swapin requests
Mark memory management requests with swapin requests

Signed-off-by: Ilan Smith 
Signed-off-by: Alex Lemberg 
Signed-off-by: Venkatraman S 
---
 include/linux/bio.h   |1 +
 include/linux/blk_types.h |2 ++
 mm/page_io.c  |3 ++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/bio.h b/include/linux/bio.h
index 264e0ef..8494b2f 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -63,6 +63,7 @@ static inline bool bio_rw_flagged(struct bio *bio, unsigned 
long flag)
 }
 
 #define bio_dmpg(bio)  bio_rw_flagged(bio, REQ_RW_DMPG)
+#define bio_swapin(bio)bio_rw_flagged(bio, REQ_RW_SWAPIN)
 
 /*
  * various member access, note that bio_data should of course not be used
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index 87feb80..df2b9ea 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -151,6 +151,7 @@ enum rq_flag_bits {
__REQ_IO_STAT,  /* account I/O stat */
__REQ_MIXED_MERGE,  /* merge of different types, fail separately */
__REQ_RW_DMPG,
+   __REQ_RW_SWAPIN,
__REQ_NR_BITS,  /* stops here */
 };
 
@@ -193,5 +194,6 @@ enum rq_flag_bits {
 #define REQ_MIXED_MERGE(1 << __REQ_MIXED_MERGE)
 #define REQ_SECURE (1 << __REQ_SECURE)
 #define REQ_RW_DMPG(1 << __REQ_RW_DMPG)
+#define REQ_RW_SWAPIN  (1 << __REQ_RW_SWAPIN)
 
 #endif /* __LINUX_BLK_TYPES_H */
diff --git a/mm/page_io.c b/mm/page_io.c
index dc76b4d..a148bea 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -128,8 +128,9 @@ int swap_readpage(struct page *page)
ret = -ENOMEM;
goto out;
}
+   bio->bi_rw |= REQ_RW_SWAPIN;
count_vm_event(PSWPIN);
-   submit_bio(READ, bio);
+   submit_bio(READ | REQ_RW_SWAPIN, bio);
 out:
return ret;
 }
-- 
1.7.10.rc2

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

[PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature

[Venkatraman S]

Standard eMMC (Embedded MultiMedia Card) specification expects to execute
one request at a time. If some requests are more important than others, they
can't be aborted while the flash procedure is in progress.

New versions of the eMMC standard (4.41 and above) specfies a feature 
called High Priority Interrupt (HPI). This enables an ongoing transaction
to be aborted using a special command (HPI command) so that the card is ready
to receive new commands immediately. Then the new request can be submitted
to the card, and optionally the interrupted command can be resumed again.

Some restrictions exist on when and how the command can be used. For example,
only write and write-like commands (ERASE) can be preempted, and the urgent
request must be a read.

In order to support this in software,
a) At the top level, some policy decisions have to be made on what is
worth preempting for.
This implementation uses the demand paging requests and swap
read requests as potential reads worth preempting an ongoing long write.
This is expected to provide improved responsiveness for smarphones
with multitasking capabilities - example would be launch a email application
while a video capture session (which causes long writes) is ongoing.
b) At the block handler, the higher priority request should be queued
  ahead of the pending requests in the elevator
c) At the MMC block and core level, transactions have to executed to 
enforce the rules of the MMC spec and make a reasonable tradeoff if the
ongoing command is really worth preempting. (For example, is it too close
to completing already ?).
The current implementation uses a fixed time logic. If 10ms has
already elapsed since the first request was submitted, then a new high
priority request would not cause a HPI, as it is expected that the first
request would finish soon. Further work is needed to dynamically tune
this value (maybe through sysfs) or automatically determine based on
average write times of previous requests.
d) At the lowest level (MMC host controllers), support interface to 
provide a transition path for ongoing transactions to be aborted and the
controller to be ready to receive next command.

More information about this feature can be found at
Jedec Specification:-
http://www.jedec.org/standards-documents/docs/jesd84-a441
Presentation on eMMC4.41 features:-
http://www.jedec.org/sites/default/files/Victor_Tsai.pdf

Acknowledgements:-  
In no particular order, thanks to Arnd Bergmann and  Saugata Das
from Linaro, Ilan Smith and Alex Lemberg from Sandisk, Luca Porzio from Micron
Technologies, Yejin Moon, Jae Hoon Chung from Samsung and others.


v1 -> v2:-
* Convert threshold for hpi usage to a tuning parameter (sysfs)
* Add Documentation/ABI for all sysfs entries
* Add implementation of abort for OMAP controller
* Rebased to 3.4-rc4 + mmc-next

This patch series depends on a few other related cleanups
in MMC driver. All the patches and the dependent series can be
pulled from 
git://github.com/svenkatr/linux.git my/mmc/3.4/foreground-hpiv2


Ilan Smith (3):
  FS: Added demand paging markers to filesystem
  MM: Added page swapping markers to memory management
  block: treat DMPG and SWAPIN requests as special

Venkatraman S (13):
  block: add queue attributes to manage dpmg and swapin requests
  block: add sysfs attributes for runtime control of dpmg and swapin
  block: Documentation: add sysfs ABI for expedite_dmpg and expedite_swapin
  mmc: core: helper function for finding preemptible command
  mmc: core: add preemptibility tracking fields to mmc command
  mmc: core: Add MMC abort interface
  mmc: block: Detect HPI support in card and host controller
  mmc: core: Implement foreground request preemption procedure
  mmc: sysfs: Add sysfs entry for tuning preempt_time_threshold
  mmc: Documentation: Add sysfs ABI for hpi_time_threshold
  mmc: block: Implement HPI invocation and handling logic.
  mmc: Update preempted request with CORRECTLY_PRG_SECTORS_NUM info
  mmc: omap_hsmmc: Implement abort_req host_ops

 Documentation/ABI/testing/sysfs-block   |   12 ++
 Documentation/ABI/testing/sysfs-devices-mmc |   12 ++
 block/blk-core.c|   18 +++
 block/blk-sysfs.c   |   16 +++
 block/elevator.c|   14 ++-
 drivers/mmc/card/block.c|  143 --
 drivers/mmc/card/queue.h|1 +
 drivers/mmc/core/core.c |   67 ++
 drivers/mmc/core/mmc.c  |   25 
 drivers/mmc/host/omap_hsmmc.c   |   55 -
 fs/mpage.c  |2 +
 include/linux/bio.h |8 ++
 include/linux/blk_types.h   

[PATCH v2 16/16] mmc: omap_hsmmc: Implement abort_req host_ops

[Venkatraman S]

Provide the abort_req implementation for omap_hsmmc host.

When invoked, the host controller should stop the transfer
and end the ongoing request as early as possible.

If the aborted command is a data transfer command, dma setup is
aborted and a STOP command is issued. The transfer state is
marked as an error (except when the command has almost completed
while receiving the abort request, in which case finish the command
normally).

Signed-off-by: Venkatraman S 
---
 drivers/mmc/host/omap_hsmmc.c |   55 ++---
 1 file changed, 51 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d15b149..a4da478 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -177,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+   int abort_in_progress;
unsigned intflags;
struct omap_hsmmc_next  next_data;
 
@@ -982,6 +983,7 @@ static inline void omap_hsmmc_reset_controller_fsm(struct 
omap_hsmmc_host *host,
 static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host, int status)
 {
struct mmc_data *data;
+   int err = 0;
int end_cmd = 0, end_trans = 0;
 
if (!host->req_in_progress) {
@@ -993,6 +995,11 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
return;
}
 
+   if (host->abort_in_progress) {
+   end_trans = 1;
+   end_cmd = 1;
+   }
+
data = host->data;
dev_dbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
 
@@ -1021,7 +1028,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
if ((status & DATA_TIMEOUT) ||
(status & DATA_CRC)) {
if (host->data || host->response_busy) {
-   int err = (status & DATA_TIMEOUT) ?
+   err = (status & DATA_TIMEOUT) ?
-ETIMEDOUT : -EILSEQ;
 
if (host->data)
@@ -1045,10 +1052,13 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
 
OMAP_HSMMC_WRITE(host->base, STAT, status);
 
-   if (end_cmd || ((status & CC) && host->cmd))
+   if ((end_cmd || (status & CC)) && host->cmd)
omap_hsmmc_cmd_done(host, host->cmd);
-   if ((end_trans || (status & TC)) && host->mrq)
+   if ((end_trans || (status & TC)) && host->mrq) {
+   if (data)
+   data->error = err;
omap_hsmmc_xfer_done(host, data);
+   }
 }
 
 /*
@@ -1257,7 +1267,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, 
void *cb_data)
}
 
spin_lock_irqsave(&host->irq_lock, flags);
-   if (host->dma_ch < 0) {
+   if (host->dma_ch < 0 || host->abort_in_progress) {
spin_unlock_irqrestore(&host->irq_lock, flags);
return;
}
@@ -1478,6 +1488,40 @@ static void omap_hsmmc_pre_req(struct mmc_host *mmc, 
struct mmc_request *mrq,
mrq->data->host_cookie = 0;
 }
 
+static int omap_hsmmc_abort_req(struct mmc_host *mmc, struct mmc_request *req)
+{
+   struct omap_hsmmc_host *host = mmc_priv(mmc);
+   unsigned long flags;
+
+   if (!host->req_in_progress) {
+   dev_dbg(mmc_dev(host->mmc), "No request to abort\n");
+   return -EINVAL;
+   }
+   if (req && req != host->mrq) {
+   dev_dbg(mmc_dev(host->mmc), "Non matching abort request\n");
+   return -EINVAL;
+   }
+   spin_lock_irqsave(&host->irq_lock, flags);
+   host->abort_in_progress = 1;
+   omap_hsmmc_disable_irq(host);
+   spin_unlock_irqrestore(&host->irq_lock, flags);
+
+   host->response_busy = 0;
+
+   if (host->data) {
+   struct mmc_data *dat = host->data;
+   omap_hsmmc_dma_cleanup(host, -EIO);
+   dev_dbg(mmc_dev(host->mmc), "Aborting Transfer\n");
+   omap_hsmmc_xfer_done(host, dat);
+   } else if (host->cmd) {
+   dev_dbg(mmc_dev(host->mmc), "Aborting Command\n");
+   omap_hsmmc_cmd_done(host, host->cmd);
+   }
+
+   dev_dbg(mmc_dev(host->mmc), "Request %pK aborted\n", req);
+   return 0;
+
+}
 /*
  * Request function. for read/write operation
  */
@@ -1488,6 +1532,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
struct mmc_request *req)
 
BUG_ON(host->req_in_progress);
BUG_ON(host->dma_ch != -1);
+   host->abort_in_progress = 0;
+
if (host->protect_card) {
if (host->reqs_blocked < 3) {
/*
@@ -1664,6 +1710,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.disable = omap_hsmmc_disa

[PATCH v2 15/16] mmc: Update preempted request with CORRECTLY_PRG_SECTORS_NUM info

[Venkatraman S]

Ongoing request that was preempted during 'programming' state is partially
completed. Number of correctly programmed sectors is available in the
ext_csd field CORRECTLY_PRG_SECTORS_NUM. Read this field to update
the bytes_xfered field of the request

Signed-off-by: Venkatraman S 
---
 drivers/mmc/core/core.c |   26 --
 include/linux/mmc/mmc.h |4 
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e6430f8..354dd7a 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -122,6 +122,23 @@ static inline void mmc_should_fail_request(struct mmc_host 
*host,
 
 #endif /* CONFIG_FAIL_MMC_REQUEST */
 
+static int mmc_get_programmed_sectors(struct mmc_card *card, int *nsectors)
+{
+   int err;
+   u8 ext_csd[512];
+
+   mmc_claim_host(card->host);
+   err = mmc_send_ext_csd(card, ext_csd);
+   mmc_release_host(card->host);
+   if (err)
+   return err;
+   *nsectors = ext_csd[EXT_CSD_C_PRG_SECTORS_NUM0] +
+   (ext_csd[EXT_CSD_C_PRG_SECTORS_NUM1] << 7) +
+   (ext_csd[EXT_CSD_C_PRG_SECTORS_NUM2] << 15) +
+   (ext_csd[EXT_CSD_C_PRG_SECTORS_NUM3] << 23);
+
+   return 0;
+}
 /**
  * mmc_request_done - finish processing an MMC request
  * @host: MMC host which completed request
@@ -470,6 +487,7 @@ int mmc_preempt_foreground_request(struct mmc_card *card,
struct mmc_request *req)
 {
int ret;
+   int nsectors;
 
ret = mmc_abort_req(card->host, req);
if (ret == -ENOSYS)
@@ -490,8 +508,12 @@ int mmc_preempt_foreground_request(struct mmc_card *card,
 */
if (req->data && req->data->error) {
mmc_interrupt_hpi(card);
-   /* TODO : Take out the CORRECTLY_PRG_SECTORS_NUM
-* from ext_csd and add it to the request */
+
+   ret = mmc_get_programmed_sectors(card, &nsectors);
+   if (ret)
+   req->data->bytes_xfered = 0;
+   else
+   req->data->bytes_xfered = nsectors * 512;
}
 
return 0;
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index ec2f195..4a3453f 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -315,6 +315,10 @@ struct _mmc_csd {
 #define EXT_CSD_PWR_CL_200_360 237 /* RO */
 #define EXT_CSD_PWR_CL_DDR_52_195  238 /* RO */
 #define EXT_CSD_PWR_CL_DDR_52_360  239 /* RO */
+#define EXT_CSD_C_PRG_SECTORS_NUM0 242 /* RO */
+#define EXT_CSD_C_PRG_SECTORS_NUM1 243 /* RO */
+#define EXT_CSD_C_PRG_SECTORS_NUM2 244 /* RO */
+#define EXT_CSD_C_PRG_SECTORS_NUM3 245 /* RO */
 #define EXT_CSD_POWER_OFF_LONG_TIME247 /* RO */
 #define EXT_CSD_GENERIC_CMD6_TIME  248 /* RO */
 #define EXT_CSD_CACHE_SIZE 249 /* RO, 4 bytes */
-- 
1.7.10.rc2

--
To unsubscribe from this list: send the line "unsubscribe 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] net: davinci_emac: Add pre_open, post_stop platform callbacks

[Kevin Hilman]

"Bedia, Vaibhav"  writes:

> On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
>> From: "Mark A. Greer" 
>> 
>> The davinci EMAC driver has been incorporated into the am35x
>> family of SoC's which is OMAP-based.  The incorporation is
>> incomplete in that the EMAC cannot unblock the [ARM] core if
>> its blocked on a 'wfi' instruction.  This is an issue with
>> the cpu_idle code because it has the core execute a 'wfi'
>> instruction.
>> 
>> To work around this issue, add platform data callbacks which
>> are called at the beginning of the open routine and at the
>> end of the stop routine of the davinci_emac driver.  The
>> callbacks allow the platform code to issue disable_hlt() and
>> enable_hlt() calls appropriately.  Calling disable_hlt()
>> prevents cpu_idle from issuing the 'wfi' instruction.
>> 
>> It is not sufficient to simply call disable_hlt() when
>> there is an EMAC present because it could be present but
>> not actually used in which case, we do want the 'wfi' to
>> be executed.
>> 
>
> Are you trying to say that if ARM executes _just_ wfi and _absolutely
> nothing else_ is done in the OMAP PM code, EMAC stops working?
>
> However, if this is indeed the case, then probably a better solution would be
> to invoke disable_hlt() from the board file when EMAC support is compiled in.

No.  As Mark stated in the changelog, doing that will prevent any
low-power states states even if the EMAC is not in use.  IMO, it is best
to only prevent WFI when absolutely needed.

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

[PATCH 06/25] OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id

[Tomi Valkeinen]

The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev->id was used
instead of the function. Fix those places to use the function.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b6cf03c..f6ecc3a 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2365,7 +2365,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
 
DSSDBGF();
 
-   r = dsi->enable_pads(dsidev->id, dsi_get_lane_mask(dssdev));
+   r = dsi->enable_pads(dsi_get_dsidev_id(dsidev), 
dsi_get_lane_mask(dssdev));
if (r)
return r;
 
@@ -2475,7 +2475,7 @@ err_cio_pwr:
dsi_cio_disable_lane_override(dsidev);
 err_scp_clk_dom:
dsi_disable_scp_clk(dsidev);
-   dsi->disable_pads(dsidev->id, dsi_get_lane_mask(dssdev));
+   dsi->disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
return r;
 }
 
@@ -2489,7 +2489,7 @@ static void dsi_cio_uninit(struct omap_dss_device *dssdev)
 
dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
dsi_disable_scp_clk(dsidev);
-   dsi->disable_pads(dsidev->id, dsi_get_lane_mask(dssdev));
+   dsi->disable_pads(dsi_get_dsidev_id(dsidev), dsi_get_lane_mask(dssdev));
 }
 
 static void dsi_config_tx_fifo(struct platform_device *dsidev,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 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 03/25] OMAPDSS: TFP410: rename dvi -> tfp410

[Tomi Valkeinen]

The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
panel driver". This patch renames the code to use tfp410 name for the
driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-3430sdp.c  |4 +-
 arch/arm/mach-omap2/board-am3517evm.c|4 +-
 arch/arm/mach-omap2/board-cm-t35.c   |4 +-
 arch/arm/mach-omap2/board-devkit8000.c   |4 +-
 arch/arm/mach-omap2/board-igep0020.c |4 +-
 arch/arm/mach-omap2/board-omap3beagle.c  |4 +-
 arch/arm/mach-omap2/board-omap3evm.c |4 +-
 arch/arm/mach-omap2/board-omap3stalker.c |4 +-
 arch/arm/mach-omap2/board-omap4panda.c   |4 +-
 arch/arm/mach-omap2/board-overo.c|4 +-
 drivers/video/omap2/displays/Kconfig |8 +--
 drivers/video/omap2/displays/Makefile|2 +-
 drivers/video/omap2/displays/panel-dvi.c |   94 +++---
 include/video/omap-panel-dvi.h   |   12 ++--
 14 files changed, 78 insertions(+), 78 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index d827f8b..2a26d62 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -157,14 +157,14 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable   = sdp3430_panel_disable_lcd,
 };
 
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
 };
 
 static struct omap_dss_device sdp3430_dvi_device = {
.name   = "dvi",
.type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "dvi",
+   .driver_name= "tfp410",
.data   = &dvi_panel,
.phy.dpi.data_lines = 24,
 };
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index ce155bf..feecc96 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -207,14 +207,14 @@ static struct omap_dss_device am3517_evm_tv_device = {
.platform_disable   = am3517_evm_panel_disable_tv,
 };
 
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
 };
 
 static struct omap_dss_device am3517_evm_dvi_device = {
.type   = OMAP_DISPLAY_TYPE_DPI,
.name   = "dvi",
-   .driver_name= "dvi",
+   .driver_name= "tfp410",
.data   = &dvi_panel,
.phy.dpi.data_lines = 24,
 };
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 6f79026..9e8efe9 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -241,14 +241,14 @@ static struct omap_dss_device cm_t35_lcd_device = {
.phy.dpi.data_lines = 18,
 };
 
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= CM_T35_DVI_EN_GPIO,
 };
 
 static struct omap_dss_device cm_t35_dvi_device = {
.name   = "dvi",
.type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "dvi",
+   .driver_name= "tfp410",
.data   = &dvi_panel,
.phy.dpi.data_lines = 24,
 };
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 92f79de..5ea88f5 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -141,14 +141,14 @@ static struct omap_dss_device devkit8000_lcd_device = {
.phy.dpi.data_lines = 24,
 };
 
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
 };
 
 static struct omap_dss_device devkit8000_dvi_device = {
.name   = "dvi",
.type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "dvi",
+   .driver_name= "tfp410",
.data   = &dvi_panel,
.phy.dpi.data_lines = 24,
 };
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index c702822..bf87f17 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -444,7 +444,7 @@ static struct twl4030_gpio_platform_data 
igep_twl4030_gpio_pdata = {
.setup  = igep_twl_gpio_setup,
 };
 
-static struct panel_dvi_platform_data dvi_panel = {
+static struct tfp410_platform_data dvi_panel = {
.i2c_bus_num= 3,
.power_down_gpio= IGEP2_GPIO_DVI_PUP,
 };
@@ -452,7 +452,7 @@ static struct panel_dvi_platform_data dvi_panel = {
 static struct omap_dss_device igep2_dvi_device = {
.type   = OMAP_DISPLAY_TYPE_DPI,
.na

[PATCH 25/25] OMAPDSS: separate pdata based initialization

[Tomi Valkeinen]

Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dpi.c  |7 +-
 drivers/video/omap2/dss/dsi.c  |   50 +++-
 drivers/video/omap2/dss/hdmi.c |   46 +---
 drivers/video/omap2/dss/rfbi.c |   45 +---
 drivers/video/omap2/dss/sdi.c  |7 +-
 drivers/video/omap2/dss/venc.c |   45 +---
 6 files changed, 120 insertions(+), 80 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 4f8defe..835e106 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -364,7 +364,7 @@ static int __init dpi_init_display(struct omap_dss_device 
*dssdev)
return 0;
 }
 
-static int __init omap_dpi_probe(struct platform_device *pdev)
+static void __init dpi_probe_pdata(struct platform_device *pdev)
 {
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
int i, r;
@@ -386,6 +386,11 @@ static int __init omap_dpi_probe(struct platform_device 
*pdev)
DSSERR("device %s register failed: %d\n",
dssdev->name, r);
}
+}
+
+static int __init omap_dpi_probe(struct platform_device *pdev)
+{
+   dpi_probe_pdata(pdev);
 
return 0;
 }
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ce964dd..429d918 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4607,6 +4607,34 @@ static void dsi_put_clocks(struct platform_device 
*dsidev)
clk_put(dsi->sys_clk);
 }
 
+static void __init dsi_probe_pdata(struct platform_device *dsidev)
+{
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+   struct omap_dss_board_info *pdata = dsidev->dev.platform_data;
+   int i, r;
+
+   for (i = 0; i < pdata->num_devices; ++i) {
+   struct omap_dss_device *dssdev = pdata->devices[i];
+
+   if (dssdev->type != OMAP_DISPLAY_TYPE_DSI)
+   continue;
+
+   if (dssdev->phy.dsi.module != dsi->module_id)
+   continue;
+
+   r = dsi_init_display(dssdev);
+   if (r) {
+   DSSERR("device %s init failed: %d\n", dssdev->name, r);
+   continue;
+   }
+
+   r = omap_dss_register_device(dssdev, &dsidev->dev);
+   if (r)
+   DSSERR("device %s register failed: %d\n",
+   dssdev->name, r);
+   }
+}
+
 /* DSI1 HW IP initialisation */
 static int __init omap_dsihw_probe(struct platform_device *dsidev)
 {
@@ -4614,7 +4642,6 @@ static int __init omap_dsihw_probe(struct platform_device 
*dsidev)
int r, i;
struct resource *dsi_mem;
struct dsi_data *dsi;
-   struct omap_dss_board_info *pdata = dsidev->dev.platform_data;
 
dsi = devm_kzalloc(&dsidev->dev, sizeof(*dsi), GFP_KERNEL);
if (!dsi)
@@ -4702,26 +4729,7 @@ static int __init omap_dsihw_probe(struct 
platform_device *dsidev)
else
dsi->num_lanes_supported = 3;
 
-   for (i = 0; i < pdata->num_devices; ++i) {
-   struct omap_dss_device *dssdev = pdata->devices[i];
-
-   if (dssdev->type != OMAP_DISPLAY_TYPE_DSI)
-   continue;
-
-   if (dssdev->phy.dsi.module != dsi->module_id)
-   continue;
-
-   r = dsi_init_display(dssdev);
-   if (r) {
-   DSSERR("device %s init failed: %d\n", dssdev->name, r);
-   continue;
-   }
-
-   r = omap_dss_register_device(dssdev, &dsidev->dev);
-   if (r)
-   DSSERR("device %s register failed: %d\n",
-   dssdev->name, r);
-   }
+   dsi_probe_pdata(dsidev);
 
dsi_runtime_put(dsidev);
 
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8b3ac6e..1b06df2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -769,12 +769,36 @@ static void hdmi_put_clocks(void)
clk_put(hdmi.sys_clk);
 }
 
+static void __init hdmi_probe_pdata(struct platform_device *pdev)
+{
+   struct omap_dss_board_info *pdata = pdev->dev.platform_data;
+   int r, i;
+
+   for (i = 0; i < pdata->num_devices; ++i) {
+   struct omap_dss_device *dssdev = pdata->devices[i];
+   struct omap_dss_hdmi_data *priv = dssdev->data;
+
+   if (dssdev->type != OMAP_DISPLAY_TYPE_HDMI)
+   continue;
+
+   r = hdmi_init_display(dssdev);
+   if (r) {
+   DSSERR("device %s init failed: %d\n"

[PATCH 23/25] OMAPDSS: DSI: implement generic DSI pin config

[Tomi Valkeinen]

In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
0,  // pin num for clock lane +
1,  // pin num for clock lane -
2,  // pin num for data1 lane +
3,  // pin num for data1 lane -
...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-4430sdp.c   |   21 ++---
 drivers/video/omap2/displays/panel-taal.c |7 ++
 drivers/video/omap2/dss/dsi.c |  133 +++--
 include/video/omap-panel-nokia-dsi.h  |3 +
 include/video/omapdss.h   |   28 +++---
 5 files changed, 103 insertions(+), 89 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 6cbb16f..b4ad706 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -666,6 +666,10 @@ static struct nokia_dsi_panel_data dsi1_panel = {
.use_ext_te = false,
.ext_te_gpio= 101,
.esd_interval   = 0,
+   .pin_config = {
+   .num_pins   = 6,
+   .pins   = { 0, 1, 2, 3, 4, 5 },
+   },
 };
 
 static struct omap_dss_device sdp4430_lcd_device = {
@@ -674,13 +678,6 @@ static struct omap_dss_device sdp4430_lcd_device = {
.type   = OMAP_DISPLAY_TYPE_DSI,
.data   = &dsi1_panel,
.phy.dsi= {
-   .clk_lane   = 1,
-   .clk_pol= 0,
-   .data1_lane = 2,
-   .data1_pol  = 0,
-   .data2_lane = 3,
-   .data2_pol  = 0,
-
.module = 0,
},
 
@@ -715,6 +712,10 @@ static struct nokia_dsi_panel_data dsi2_panel = {
.use_ext_te = false,
.ext_te_gpio= 103,
.esd_interval   = 0,
+   .pin_config = {
+   .num_pins   = 6,
+   .pins   = { 0, 1, 2, 3, 4, 5 },
+   },
 };
 
 static struct omap_dss_device sdp4430_lcd2_device = {
@@ -723,12 +724,6 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.type   = OMAP_DISPLAY_TYPE_DSI,
.data   = &dsi2_panel,
.phy.dsi= {
-   .clk_lane   = 1,
-   .clk_pol= 0,
-   .data1_lane = 2,
-   .data1_pol  = 0,
-   .data2_lane = 3,
-   .data2_pol  = 0,
 
.module = 1,
},
diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index be9992f..2ce9992 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1051,9 +1051,16 @@ static void __exit taal_remove(struct omap_dss_device 
*dssdev)
 static int taal_power_on(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
u8 id1, id2, id3;
int r;
 
+   r = omapdss_dsi_configure_pins(dssdev, &panel_data->pin_config);
+   if (r) {
+   dev_err(&dssdev->dev, "failed to configure DSI pins\n");
+   goto err0;
+   };
+
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(&dssdev->dev, "failed to enable DSI\n");
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 49b83a4..6cc92a8 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -2011,65 +2011,6 @@ static unsigned dsi_get_line_buf_size(struct 
platform_device *dsidev)
}
 }
 
-static int dsi_parse_lane_config(struct omap_dss_device *dssdev)
-{
-   struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
-   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
-   u8 lanes[DSI_MAX_NR_LANES];
-   u8 polarities[DSI_MAX_NR_LANES];
-   int num_lanes, i;
-
-   static const enum dsi_lane_function functions[] = {
-   DSI_LANE_CLK,
-   DSI_LANE_DATA1,
-   DSI_LANE_DATA2,
-   DSI_LANE_DATA3,
-   DSI_LANE_DATA4,
-   };
-
-   lanes[0] = dssdev->phy.dsi.clk_lane;
- 

[PATCH 24/25] OMAPDSS: DSI: improve DSI module id handling

[Tomi Valkeinen]

We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.

However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.

Instead of using dsidev->id during operation, this patch stores the
value of dsidev->id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dsi.c |   46 +++--
 1 file changed, 21 insertions(+), 25 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6cc92a8..ce964dd 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -256,6 +256,8 @@ struct dsi_data {
struct platform_device *pdev;
void __iomem*base;
 
+   int module_id;
+
int irq;
 
struct clk *dss_clk;
@@ -358,11 +360,6 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
return dsi_pdev_map[module];
 }
 
-static inline int dsi_get_dsidev_id(struct platform_device *dsidev)
-{
-   return dsidev->id;
-}
-
 static inline void dsi_write_reg(struct platform_device *dsidev,
const struct dsi_reg idx, u32 val)
 {
@@ -1181,10 +1178,9 @@ static unsigned long dsi_get_txbyteclkhs(struct 
platform_device *dsidev)
 static unsigned long dsi_fclk_rate(struct platform_device *dsidev)
 {
unsigned long r;
-   int dsi_module = dsi_get_dsidev_id(dsidev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 
-   if (dss_get_dsi_clk_source(dsi_module) == OMAP_DSS_CLK_SRC_FCK) {
+   if (dss_get_dsi_clk_source(dsi->module_id) == OMAP_DSS_CLK_SRC_FCK) {
/* DSI FCLK source is DSS_CLK_FCK */
r = clk_get_rate(dsi->dss_clk);
} else {
@@ -1683,7 +1679,7 @@ static void dsi_dump_dsidev_clocks(struct platform_device 
*dsidev,
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct dsi_clock_info *cinfo = &dsi->current_cinfo;
enum omap_dss_clk_source dispc_clk_src, dsi_clk_src;
-   int dsi_module = dsi_get_dsidev_id(dsidev);
+   int dsi_module = dsi->module_id;
 
dispc_clk_src = dss_get_dispc_clk_source();
dsi_clk_src = dss_get_dsi_clk_source(dsi_module);
@@ -1755,7 +1751,6 @@ static void dsi_dump_dsidev_irqs(struct platform_device 
*dsidev,
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
unsigned long flags;
struct dsi_irq_stats stats;
-   int dsi_module = dsi_get_dsidev_id(dsidev);
 
spin_lock_irqsave(&dsi->irq_stats_lock, flags);
 
@@ -1772,7 +1767,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device 
*dsidev,
 #define PIS(x) \
seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
 
-   seq_printf(s, "-- DSI%d interrupts --\n", dsi_module + 1);
+   seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
PIS(VC0);
PIS(VC1);
PIS(VC2);
@@ -2272,7 +2267,7 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
 
DSSDBGF();
 
-   r = dss_dsi_enable_pads(dsi_get_dsidev_id(dsidev), 
dsi_get_lane_mask(dssdev));
+   r = dss_dsi_enable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
if (r)
return r;
 
@@ -2382,20 +2377,21 @@ err_cio_pwr:
dsi_cio_disable_lane_override(dsidev);
 err_scp_clk_dom:
dsi_disable_scp_clk(dsidev);
-   dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), 
dsi_get_lane_mask(dssdev));
+   dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
return r;
 }
 
 static void dsi_cio_uninit(struct omap_dss_device *dssdev)
 {
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 
/* DDR_CLK_ALWAYS_ON */
REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 0, 13, 13);
 
dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
dsi_disable_scp_clk(dsidev);
-   dss_dsi_disable_pads(dsi_get_dsidev_id(dsidev), 
dsi_get_lane_mask(dssdev));
+   dss_dsi_disable_pads(dsi->module_id, dsi_get_lane_mask(dssdev));
 }
 
 static void dsi_config_tx_fifo(struct platform_device *dsidev,
@@ -4277,7 +4273,7 @@ static int dsi_configure_dispc_clocks(struct 
omap_dss_device *dssdev)
 static int dsi_display_init_dsi(struct omap_dss_device *dssdev)
 {
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
-   int dsi_module = dsi_get_dsidev_id(dsidev);
+   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
int r;
 
r = dsi_pll_init(dsidev, true, true);
@@ -4289,7 +4285,7 @@ static int dsi_display_init_dsi(struct omap_dss_device 
*dssdev)
goto err1;
 
dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fcl

[PATCH 22/25] OMAPDSS: init omap_dss_devices internally

[Tomi Valkeinen]

Now that each output driver creates their own display devices, the
output drivers can also initialize those devices.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/display.c |   40 -
 drivers/video/omap2/dss/dpi.c |8 +++-
 drivers/video/omap2/dss/dsi.c |8 +++-
 drivers/video/omap2/dss/dss.h |   10 --
 drivers/video/omap2/dss/hdmi.c|8 +++-
 drivers/video/omap2/dss/rfbi.c|8 +++-
 drivers/video/omap2/dss/sdi.c |8 +++-
 drivers/video/omap2/dss/venc.c|8 +++-
 8 files changed, 42 insertions(+), 56 deletions(-)

diff --git a/drivers/video/omap2/dss/display.c 
b/drivers/video/omap2/dss/display.c
index e688d10..faf7d91 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -359,46 +359,6 @@ void dss_init_device(struct platform_device *pdev,
int i;
int r;
 
-   switch (dssdev->type) {
-#ifdef CONFIG_OMAP2_DSS_DPI
-   case OMAP_DISPLAY_TYPE_DPI:
-   r = dpi_init_display(dssdev);
-   break;
-#endif
-#ifdef CONFIG_OMAP2_DSS_RFBI
-   case OMAP_DISPLAY_TYPE_DBI:
-   r = rfbi_init_display(dssdev);
-   break;
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
-   case OMAP_DISPLAY_TYPE_VENC:
-   r = venc_init_display(dssdev);
-   break;
-#endif
-#ifdef CONFIG_OMAP2_DSS_SDI
-   case OMAP_DISPLAY_TYPE_SDI:
-   r = sdi_init_display(dssdev);
-   break;
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
-   case OMAP_DISPLAY_TYPE_DSI:
-   r = dsi_init_display(dssdev);
-   break;
-#endif
-   case OMAP_DISPLAY_TYPE_HDMI:
-   r = hdmi_init_display(dssdev);
-   break;
-   default:
-   DSSERR("Support for display '%s' not compiled in.\n",
-   dssdev->name);
-   return;
-   }
-
-   if (r) {
-   DSSERR("failed to init display %s\n", dssdev->name);
-   return;
-   }
-
/* create device sysfs files */
i = 0;
while ((attr = display_sysfs_attrs[i++]) != NULL) {
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 631953b..4f8defe 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -338,7 +338,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
 }
 EXPORT_SYMBOL(dpi_check_timings);
 
-int dpi_init_display(struct omap_dss_device *dssdev)
+static int __init dpi_init_display(struct omap_dss_device *dssdev)
 {
DSSDBG("init_display\n");
 
@@ -375,6 +375,12 @@ static int __init omap_dpi_probe(struct platform_device 
*pdev)
if (dssdev->type != OMAP_DISPLAY_TYPE_DPI)
continue;
 
+   r = dpi_init_display(dssdev);
+   if (r) {
+   DSSERR("device %s init failed: %d\n", dssdev->name, r);
+   continue;
+   }
+
r = omap_dss_register_device(dssdev, &pdev->dev);
if (r)
DSSERR("device %s register failed: %d\n",
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 0ff1e63..49b83a4 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4456,7 +4456,7 @@ int omapdss_dsi_enable_te(struct omap_dss_device *dssdev, 
bool enable)
 }
 EXPORT_SYMBOL(omapdss_dsi_enable_te);
 
-int dsi_init_display(struct omap_dss_device *dssdev)
+static int __init dsi_init_display(struct omap_dss_device *dssdev)
 {
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
@@ -4712,6 +4712,12 @@ static int __init omap_dsihw_probe(struct 
platform_device *dsidev)
if (dssdev->phy.dsi.module != dsi_module)
continue;
 
+   r = dsi_init_display(dssdev);
+   if (r) {
+   DSSERR("device %s init failed: %d\n", dssdev->name, r);
+   continue;
+   }
+
r = omap_dss_register_device(dssdev, &dsidev->dev);
if (r)
DSSERR("device %s register failed: %d\n",
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 828f669..c0a1532 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -270,7 +270,6 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
 /* SDI */
 int sdi_init_platform_driver(void) __init;
 void sdi_uninit_platform_driver(void) __exit;
-int sdi_init_display(struct omap_dss_device *display);
 
 /* DSI */
 #ifdef CONFIG_OMAP2_DSS_DSI
@@ -286,7 +285,6 @@ void dsi_runtime_put(struct platform_device *dsidev);
 
 void dsi_dump_clocks(struct seq_file *s);
 
-int dsi_init_display(struct omap_dss_device *display);
 void dsi_irq_handler(void);
 u8 dsi_get_pixel

[PATCH 21/25] OMAPDSS: interface drivers register their panel devices

[Tomi Valkeinen]

Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.

With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.

To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/display.c  |9 
 drivers/video/omap2/dss/core.c |   46 ++--
 drivers/video/omap2/dss/dpi.c  |   17 +++
 drivers/video/omap2/dss/dsi.c  |   18 
 drivers/video/omap2/dss/dss.h  |5 +
 drivers/video/omap2/dss/hdmi.c |   17 ++-
 drivers/video/omap2/dss/rfbi.c |   16 +-
 drivers/video/omap2/dss/sdi.c  |   17 +++
 drivers/video/omap2/dss/venc.c |   18 +++-
 9 files changed, 126 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 2c05a60..2c51809 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -325,7 +325,7 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
curr_dss_hwmod[i].id,
curr_dss_hwmod[i].oh_name,
-   NULL, 0,
+   board_data, sizeof(*board_data),
dss_pdev);
 
if (IS_ERR(pdev)) {
@@ -341,15 +341,16 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
 
/* Create devices for DPI and SDI */
 
-   pdev = create_simple_dss_pdev("omapdss_dpi", -1, NULL, 0, dss_pdev);
+   pdev = create_simple_dss_pdev("omapdss_dpi", -1,
+   board_data, sizeof(*board_data), dss_pdev);
if (IS_ERR(pdev)) {
pr_err("Could not build platform_device for omapdss_dpi\n");
return PTR_ERR(pdev);
}
 
if (cpu_is_omap34xx()) {
-   pdev = create_simple_dss_pdev("omapdss_sdi", -1, NULL, 0,
-   dss_pdev);
+   pdev = create_simple_dss_pdev("omapdss_sdi", -1,
+   board_data, sizeof(*board_data), dss_pdev);
if (IS_ERR(pdev)) {
pr_err("Could not build platform_device for 
omapdss_sdi\n");
return PTR_ERR(pdev);
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index c3566a0..9915e9d 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -56,9 +56,6 @@ bool dss_debug;
 module_param_named(debug, dss_debug, bool, 0644);
 #endif
 
-static int omap_dss_register_device(struct omap_dss_device *);
-static void omap_dss_unregister_device(struct omap_dss_device *);
-
 /* REGULATORS */
 
 struct regulator *dss_get_vdds_dsi(void)
@@ -209,7 +206,6 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
 {
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
int r;
-   int i;
 
core.pdev = pdev;
 
@@ -229,25 +225,8 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
else if (pdata->default_device)
core.default_display_name = pdata->default_device->name;
 
-   for (i = 0; i < pdata->num_devices; ++i) {
-   struct omap_dss_device *dssdev = pdata->devices[i];
-
-   r = omap_dss_register_device(dssdev);
-   if (r) {
-   DSSERR("device %d %s register failed %d\n", i,
-   dssdev->name ?: "unnamed", r);
-
-   while (--i >= 0)
-   omap_dss_unregister_device(pdata->devices[i]);
-
-   goto err_register;
-   }
-   }
-
return 0;
 
-err_register:
-   dss_uninitialize_debugfs();
 err_debugfs:
 
return r;
@@ -255,17 +234,11 @@ err_debugfs:
 
 static int omap_dss_remove(struct platform_device *pdev)
 {
-   struct omap_dss_board_info *pdata = pdev->dev.platform_data;
-   int i;
-
dss_uninitialize_debugfs();
 
dss_uninit_overlays(pdev);
dss_uninit_overlay_managers(pdev);
 
-   for (i = 0; i < pdata->num_devices; ++i)
-   omap_dss_unregister_device(pdata->devices[i]);
-
re

[PATCH 20/25] OMAPDSS: change default_device handling

[Tomi Valkeinen]

We currently have a two ways to set a "default panel device" for dss, to
which the overlays are connected when the omapdss driver is loaded:

- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata

The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.

This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/core.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 9b84f13..c3566a0 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -43,6 +43,8 @@ static struct {
 
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
+
+   const char *default_display_name;
 } core;
 
 static char *def_disp_name;
@@ -222,6 +224,11 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
if (r)
goto err_debugfs;
 
+   if (def_disp_name)
+   core.default_display_name = def_disp_name;
+   else if (pdata->default_device)
+   core.default_display_name = pdata->default_device->name;
+
for (i = 0; i < pdata->num_devices; ++i) {
struct omap_dss_device *dssdev = pdata->devices[i];
 
@@ -235,9 +242,6 @@ static int __init omap_dss_probe(struct platform_device 
*pdev)
 
goto err_register;
}
-
-   if (def_disp_name && strcmp(def_disp_name, dssdev->name) == 0)
-   pdata->default_device = dssdev;
}
 
return 0;
@@ -360,7 +364,6 @@ static int dss_driver_probe(struct device *dev)
int r;
struct omap_dss_driver *dssdrv = to_dss_driver(dev->driver);
struct omap_dss_device *dssdev = to_dss_device(dev);
-   struct omap_dss_board_info *pdata = core.pdev->dev.platform_data;
bool force;
 
DSSDBG("driver_probe: dev %s/%s, drv %s\n",
@@ -369,7 +372,8 @@ static int dss_driver_probe(struct device *dev)
 
dss_init_device(core.pdev, dssdev);
 
-   force = pdata->default_device == dssdev;
+   force = core.default_display_name &&
+   strcmp(core.default_display_name, dssdev->name) == 0;
dss_recheck_connections(dssdev, force);
 
r = dssdrv->probe(dssdev);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 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 19/25] OMAPFB: add __init & __exit

[Tomi Valkeinen]

Change omapfb to use platform_driver_probe and add __init & __exit.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/omapfb/omapfb-main.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index b00db40..a0967dc 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2307,7 +2307,7 @@ static int omapfb_init_display(struct omapfb2_device 
*fbdev,
return 0;
 }
 
-static int omapfb_probe(struct platform_device *pdev)
+static int __init omapfb_probe(struct platform_device *pdev)
 {
struct omapfb2_device *fbdev = NULL;
int r = 0;
@@ -2448,7 +2448,7 @@ err0:
return r;
 }
 
-static int omapfb_remove(struct platform_device *pdev)
+static int __exit omapfb_remove(struct platform_device *pdev)
 {
struct omapfb2_device *fbdev = platform_get_drvdata(pdev);
 
@@ -2462,8 +2462,7 @@ static int omapfb_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver omapfb_driver = {
-   .probe  = omapfb_probe,
-   .remove = omapfb_remove,
+   .remove = __exit_p(omapfb_remove),
.driver = {
.name   = "omapfb",
.owner  = THIS_MODULE,
@@ -2474,7 +2473,7 @@ static int __init omapfb_init(void)
 {
DBG("omapfb_init\n");
 
-   if (platform_driver_register(&omapfb_driver)) {
+   if (platform_driver_probe(&omapfb_driver, omapfb_probe)) {
printk(KERN_ERR "failed to register omapfb driver\n");
return -ENODEV;
}
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 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 18/25] OMAPDSS: add __init & __exit

[Tomi Valkeinen]

Now that we are using platform_driver_probe() we can add __inits and
__exits all around.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/core.c  |4 ++--
 drivers/video/omap2/dss/dispc.c |   10 +-
 drivers/video/omap2/dss/dpi.c   |   10 +-
 drivers/video/omap2/dss/dsi.c   |   10 +-
 drivers/video/omap2/dss/dss.c   |8 
 drivers/video/omap2/dss/dss.h   |   30 +++---
 drivers/video/omap2/dss/hdmi.c  |   10 +-
 drivers/video/omap2/dss/rfbi.c  |   10 +-
 drivers/video/omap2/dss/sdi.c   |   10 +-
 drivers/video/omap2/dss/venc.c  |   10 +-
 10 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index c54bba0..9b84f13 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -203,7 +203,7 @@ static inline int dss_debugfs_create_file(const char *name,
 #endif /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
 
 /* PLATFORM DEVICE */
-static int omap_dss_probe(struct platform_device *pdev)
+static int __init omap_dss_probe(struct platform_device *pdev)
 {
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
int r;
@@ -483,7 +483,7 @@ static void omap_dss_unregister_device(struct 
omap_dss_device *dssdev)
 }
 
 /* BUS */
-static int omap_dss_bus_register(void)
+static int __init omap_dss_bus_register(void)
 {
int r;
 
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e4b880f..0e6fc04 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3507,7 +3507,7 @@ static void _omap_dispc_initial_config(void)
 }
 
 /* DISPC HW IP initialisation */
-static int omap_dispchw_probe(struct platform_device *pdev)
+static int __init omap_dispchw_probe(struct platform_device *pdev)
 {
u32 rev;
int r = 0;
@@ -3589,7 +3589,7 @@ err_runtime_get:
return r;
 }
 
-static int omap_dispchw_remove(struct platform_device *pdev)
+static int __exit omap_dispchw_remove(struct platform_device *pdev)
 {
pm_runtime_disable(&pdev->dev);
 
@@ -3618,7 +3618,7 @@ static const struct dev_pm_ops dispc_pm_ops = {
 };
 
 static struct platform_driver omap_dispchw_driver = {
-   .remove = omap_dispchw_remove,
+   .remove = __exit_p(omap_dispchw_remove),
.driver = {
.name   = "omapdss_dispc",
.owner  = THIS_MODULE,
@@ -3626,12 +3626,12 @@ static struct platform_driver omap_dispchw_driver = {
},
 };
 
-int dispc_init_platform_driver(void)
+int __init dispc_init_platform_driver(void)
 {
return platform_driver_probe(&omap_dispchw_driver, omap_dispchw_probe);
 }
 
-void dispc_uninit_platform_driver(void)
+void __exit dispc_uninit_platform_driver(void)
 {
platform_driver_unregister(&omap_dispchw_driver);
 }
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5481f7c..f92134c 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -364,30 +364,30 @@ int dpi_init_display(struct omap_dss_device *dssdev)
return 0;
 }
 
-static int omap_dpi_probe(struct platform_device *pdev)
+static int __init omap_dpi_probe(struct platform_device *pdev)
 {
return 0;
 }
 
-static int omap_dpi_remove(struct platform_device *pdev)
+static int __exit omap_dpi_remove(struct platform_device *pdev)
 {
return 0;
 }
 
 static struct platform_driver omap_dpi_driver = {
-   .remove = omap_dpi_remove,
+   .remove = __exit_p(omap_dpi_remove),
.driver = {
.name   = "omapdss_dpi",
.owner  = THIS_MODULE,
},
 };
 
-int dpi_init_platform_driver(void)
+int __init dpi_init_platform_driver(void)
 {
return platform_driver_probe(&omap_dpi_driver, omap_dpi_probe);
 }
 
-void dpi_uninit_platform_driver(void)
+void __exit dpi_uninit_platform_driver(void)
 {
platform_driver_unregister(&omap_dpi_driver);
 }
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index eedec80..f37e7ee 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4610,7 +4610,7 @@ static void dsi_put_clocks(struct platform_device *dsidev)
 }
 
 /* DSI1 HW IP initialisation */
-static int omap_dsihw_probe(struct platform_device *dsidev)
+static int __init omap_dsihw_probe(struct platform_device *dsidev)
 {
u32 rev;
int r, i, dsi_module = dsi_get_dsidev_id(dsidev);
@@ -4723,7 +4723,7 @@ err_runtime_get:
return r;
 }
 
-static int omap_dsihw_remove(struct platform_device *dsidev)
+static int __exit omap_dsihw_remove(struct platform_device *dsidev)
 {
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
 
@@ -4770,7 +4770,7 @@ static const struct dev_pm_ops dsi_pm_ops = {
 };
 
 static struct platform_driver omap_dsihw_driver = {
-   .remove = oma

[PATCH 17/25] OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi

[Tomi Valkeinen]

Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dpi.c  |3 +--
 drivers/video/omap2/dss/dsi.c  |3 +--
 drivers/video/omap2/dss/hdmi.c |3 +--
 drivers/video/omap2/dss/rfbi.c |3 +--
 drivers/video/omap2/dss/sdi.c  |3 +--
 drivers/video/omap2/dss/venc.c |3 +--
 6 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index d7a433b..5481f7c 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -375,7 +375,6 @@ static int omap_dpi_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver omap_dpi_driver = {
-   .probe  = omap_dpi_probe,
.remove = omap_dpi_remove,
.driver = {
.name   = "omapdss_dpi",
@@ -385,7 +384,7 @@ static struct platform_driver omap_dpi_driver = {
 
 int dpi_init_platform_driver(void)
 {
-   return platform_driver_register(&omap_dpi_driver);
+   return platform_driver_probe(&omap_dpi_driver, omap_dpi_probe);
 }
 
 void dpi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b380231..eedec80 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4770,7 +4770,6 @@ static const struct dev_pm_ops dsi_pm_ops = {
 };
 
 static struct platform_driver omap_dsihw_driver = {
-   .probe  = omap_dsihw_probe,
.remove = omap_dsihw_remove,
.driver = {
.name   = "omapdss_dsi",
@@ -4781,7 +4780,7 @@ static struct platform_driver omap_dsihw_driver = {
 
 int dsi_init_platform_driver(void)
 {
-   return platform_driver_register(&omap_dsihw_driver);
+   return platform_driver_probe(&omap_dsihw_driver, omap_dsihw_probe);
 }
 
 void dsi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 614eaed..0e3d099 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -870,7 +870,6 @@ static const struct dev_pm_ops hdmi_pm_ops = {
 };
 
 static struct platform_driver omapdss_hdmihw_driver = {
-   .probe  = omapdss_hdmihw_probe,
.remove = omapdss_hdmihw_remove,
.driver = {
.name   = "omapdss_hdmi",
@@ -881,7 +880,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
 
 int hdmi_init_platform_driver(void)
 {
-   return platform_driver_register(&omapdss_hdmihw_driver);
+   return platform_driver_probe(&omapdss_hdmihw_driver, 
omapdss_hdmihw_probe);
 }
 
 void hdmi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 6f28955..23b4142 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1015,7 +1015,6 @@ static const struct dev_pm_ops rfbi_pm_ops = {
 };
 
 static struct platform_driver omap_rfbihw_driver = {
-   .probe  = omap_rfbihw_probe,
.remove = omap_rfbihw_remove,
.driver = {
.name   = "omapdss_rfbi",
@@ -1026,7 +1025,7 @@ static struct platform_driver omap_rfbihw_driver = {
 
 int rfbi_init_platform_driver(void)
 {
-   return platform_driver_register(&omap_rfbihw_driver);
+   return platform_driver_probe(&omap_rfbihw_driver, omap_rfbihw_probe);
 }
 
 void rfbi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 90a1955..ff9ad37 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -187,7 +187,6 @@ static int omap_sdi_remove(struct platform_device *pdev)
 }
 
 static struct platform_driver omap_sdi_driver = {
-   .probe  = omap_sdi_probe,
.remove = omap_sdi_remove,
.driver = {
.name   = "omapdss_sdi",
@@ -197,7 +196,7 @@ static struct platform_driver omap_sdi_driver = {
 
 int sdi_init_platform_driver(void)
 {
-   return platform_driver_register(&omap_sdi_driver);
+   return platform_driver_probe(&omap_sdi_driver, omap_sdi_probe);
 }
 
 void sdi_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index cb6b571..130263b 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -877,7 +877,6 @@ static const struct dev_pm_ops venc_pm_ops = {
 };
 
 static struct platform_driver omap_venchw_driver = {
-   .probe  = omap_venchw_probe,
.remove = omap_venchw_remove,
.driver = {
.name   = "omapdss_venc",
@@ -891,7 +890,7 @@ int venc_init_platform_driver(void)
if (cpu_is_omap44xx())
return 0;
 
-   return platform_driver_register(&omap_v

[PATCH 15/25] OMAPDSS: handle output-driver reg/unreg more dynamically

[Tomi Valkeinen]

Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/core.c |  111 +---
 drivers/video/omap2/dss/dss.h  |   41 ---
 2 files changed, 59 insertions(+), 93 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 77fbd99..2a0cbae 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -515,10 +515,54 @@ static int omap_dss_bus_register(void)
 }
 
 /* INIT */
+static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+   dpi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+   sdi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+   rfbi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+   venc_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+   dsi_init_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+   hdmi_init_platform_driver,
+#endif
+};
+
+static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+#ifdef CONFIG_OMAP2_DSS_DPI
+   dpi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_SDI
+   sdi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_RFBI
+   rfbi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+   venc_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_DSI
+   dsi_uninit_platform_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+   hdmi_uninit_platform_driver,
+#endif
+};
+
+static bool dss_output_drv_loaded[ARRAY_SIZE(dss_output_drv_reg_funcs)];
 
 static int __init omap_dss_register_drivers(void)
 {
int r;
+   int i;
 
r = platform_driver_probe(&omap_dss_driver, omap_dss_probe);
if (r)
@@ -536,56 +580,18 @@ static int __init omap_dss_register_drivers(void)
goto err_dispc;
}
 
-   r = dpi_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize dpi platform driver\n");
-   goto err_dpi;
-   }
-
-   r = sdi_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize sdi platform driver\n");
-   goto err_sdi;
-   }
-
-   r = rfbi_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize rfbi platform driver\n");
-   goto err_rfbi;
-   }
-
-   r = venc_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize venc platform driver\n");
-   goto err_venc;
-   }
-
-   r = dsi_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize DSI platform driver\n");
-   goto err_dsi;
-   }
-
-   r = hdmi_init_platform_driver();
-   if (r) {
-   DSSERR("Failed to initialize hdmi\n");
-   goto err_hdmi;
+   /*
+* It's ok if the output-driver register fails. It happens, for example,
+* when there is no output-device (e.g. SDI for OMAP4).
+*/
+   for (i = 0; i < ARRAY_SIZE(dss_output_drv_reg_funcs); ++i) {
+   r = dss_output_drv_reg_funcs[i]();
+   if (r == 0)
+   dss_output_drv_loaded[i] = true;
}
 
return 0;
 
-err_hdmi:
-   dsi_uninit_platform_driver();
-err_dsi:
-   venc_uninit_platform_driver();
-err_venc:
-   rfbi_uninit_platform_driver();
-err_rfbi:
-   sdi_uninit_platform_driver();
-err_sdi:
-   dpi_uninit_platform_driver();
-err_dpi:
-   dispc_uninit_platform_driver();
 err_dispc:
dss_uninit_platform_driver();
 err_dss:
@@ -596,12 +602,13 @@ err_dss:
 
 static void __exit omap_dss_unregister_drivers(void)
 {
-   hdmi_uninit_platform_driver();
-   dsi_uninit_platform_driver();
-   venc_uninit_platform_driver();
-   rfbi_uninit_platform_driver();
-   sdi_uninit_platform_driver();
-   dpi_uninit_platform_driver();
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dss_output_drv_unreg_funcs); ++i) {
+   if (dss_output_drv_loaded[i])
+   dss_output_drv_unreg_funcs[i]();
+   }
+
dispc_uninit_platform_driver();
dss_uninit_platform_driver();
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b53b2e6..57853fd 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -263,14 +263,9 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
struct dispc_clock_info *dispc_cinfo);
 
 /* SDI */
-#ifdef CONFIG_OMAP2_DSS_SDI
 int sdi_init_platform_driver(void);
 void sdi_uninit_platform_driver(void);
 int sdi_init_display(struct omap_dss_device *display);
-#else
-static inline int sdi_init_platform_driver(void) { return 0; }
-static inline void sdi_uninit_platform_driver(void) { }
-#endif
 
 /* DSI */
 #

[PATCH 16/25] OMAPDSS: move the creation of debugfs files

[Tomi Valkeinen]

Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/core.c  |   46 +++
 drivers/video/omap2/dss/dispc.c |7 +-
 drivers/video/omap2/dss/dsi.c   |   42 ++-
 drivers/video/omap2/dss/dss.c   |4 +++-
 drivers/video/omap2/dss/dss.h   |   11 +-
 drivers/video/omap2/dss/hdmi.c  |4 +++-
 drivers/video/omap2/dss/rfbi.c  |4 +++-
 drivers/video/omap2/dss/venc.c  |4 +++-
 8 files changed, 48 insertions(+), 74 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 2a0cbae..c54bba0 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -166,34 +166,6 @@ static int dss_initialize_debugfs(void)
debugfs_create_file("clk", S_IRUGO, dss_debugfs_dir,
&dss_debug_dump_clocks, &dss_debug_fops);
 
-#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
-   debugfs_create_file("dispc_irq", S_IRUGO, dss_debugfs_dir,
-   &dispc_dump_irqs, &dss_debug_fops);
-#endif
-
-#if defined(CONFIG_OMAP2_DSS_DSI) && 
defined(CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS)
-   dsi_create_debugfs_files_irq(dss_debugfs_dir, &dss_debug_fops);
-#endif
-
-   debugfs_create_file("dss", S_IRUGO, dss_debugfs_dir,
-   &dss_dump_regs, &dss_debug_fops);
-   debugfs_create_file("dispc", S_IRUGO, dss_debugfs_dir,
-   &dispc_dump_regs, &dss_debug_fops);
-#ifdef CONFIG_OMAP2_DSS_RFBI
-   debugfs_create_file("rfbi", S_IRUGO, dss_debugfs_dir,
-   &rfbi_dump_regs, &dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
-   dsi_create_debugfs_files_reg(dss_debugfs_dir, &dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
-   debugfs_create_file("venc", S_IRUGO, dss_debugfs_dir,
-   &venc_dump_regs, &dss_debug_fops);
-#endif
-#ifdef CONFIG_OMAP4_DSS_HDMI
-   debugfs_create_file("hdmi", S_IRUGO, dss_debugfs_dir,
-   &hdmi_dump_regs, &dss_debug_fops);
-#endif
return 0;
 }
 
@@ -202,6 +174,19 @@ static void dss_uninitialize_debugfs(void)
if (dss_debugfs_dir)
debugfs_remove_recursive(dss_debugfs_dir);
 }
+
+int dss_debugfs_create_file(const char *name, void (*write)(struct seq_file *))
+{
+   struct dentry *d;
+
+   d = debugfs_create_file(name, S_IRUGO, dss_debugfs_dir,
+   write, &dss_debug_fops);
+
+   if (IS_ERR(d))
+   return PTR_ERR(d);
+
+   return 0;
+}
 #else /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
 static inline int dss_initialize_debugfs(void)
 {
@@ -210,6 +195,11 @@ static inline int dss_initialize_debugfs(void)
 static inline void dss_uninitialize_debugfs(void)
 {
 }
+static inline int dss_debugfs_create_file(const char *name,
+   void (*write)(struct seq_file *))
+{
+   return 0;
+}
 #endif /* CONFIG_DEBUG_FS && CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
 
 /* PLATFORM DEVICE */
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 1cccd4c..e4b880f 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2765,7 +2765,7 @@ void dispc_dump_irqs(struct seq_file *s)
 }
 #endif
 
-void dispc_dump_regs(struct seq_file *s)
+static void dispc_dump_regs(struct seq_file *s)
 {
int i, j;
const char *mgr_names[] = {
@@ -3576,6 +3576,11 @@ static int omap_dispchw_probe(struct platform_device 
*pdev)
 
dispc_runtime_put();
 
+   dss_debugfs_create_file("dispc", dispc_dump_regs);
+
+#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
+   dss_debugfs_create_file("dispc_irq", dispc_dump_irqs);
+#endif
return 0;
 
 err_runtime_get:
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c365942..b380231 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1852,22 +1852,6 @@ static void dsi2_dump_irqs(struct seq_file *s)
 
dsi_dump_dsidev_irqs(dsidev, s);
 }
-
-void dsi_create_debugfs_files_irq(struct dentry *debugfs_dir,
-   const struct file_operations *debug_fops)
-{
-   struct platform_device *dsidev;
-
-   dsidev = dsi_get_dsidev_from_id(0);
-   if (dsidev)
-   debugfs_create_file("dsi1_irqs", S_IRUGO, debugfs_dir,
-   &dsi1_dump_irqs, debug_fops);
-
-   dsidev = dsi_get_dsidev_from_id(1);
-   if (dsidev)
-   debugfs_create_file("dsi2_irqs", S_IRUGO, debugfs_dir,
-   &dsi2_dump_irqs, debug_fops);
-}
 #endif
 
 static void dsi_dump_dsidev_regs(struct platform_device *dsidev,
@@ -1968,21 +1952,6 @@ static void dsi2_dump_regs(struct seq_file *s)
dsi_dump_dsidev_regs(dsidev, s);
 }
 
-void dsi_create_debugfs_fi

[PATCH 13/25] OMAPDSS: create DPI & SDI drivers

[Tomi Valkeinen]

We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.

This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/core.c |   18 ++
 drivers/video/omap2/dss/dpi.c  |   23 +--
 drivers/video/omap2/dss/dss.c  |   20 +---
 drivers/video/omap2/dss/dss.h  |   26 --
 drivers/video/omap2/dss/sdi.c  |   25 +++--
 5 files changed, 71 insertions(+), 41 deletions(-)

diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index db45e6a..77fbd99 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -536,6 +536,18 @@ static int __init omap_dss_register_drivers(void)
goto err_dispc;
}
 
+   r = dpi_init_platform_driver();
+   if (r) {
+   DSSERR("Failed to initialize dpi platform driver\n");
+   goto err_dpi;
+   }
+
+   r = sdi_init_platform_driver();
+   if (r) {
+   DSSERR("Failed to initialize sdi platform driver\n");
+   goto err_sdi;
+   }
+
r = rfbi_init_platform_driver();
if (r) {
DSSERR("Failed to initialize rfbi platform driver\n");
@@ -569,6 +581,10 @@ err_dsi:
 err_venc:
rfbi_uninit_platform_driver();
 err_rfbi:
+   sdi_uninit_platform_driver();
+err_sdi:
+   dpi_uninit_platform_driver();
+err_dpi:
dispc_uninit_platform_driver();
 err_dispc:
dss_uninit_platform_driver();
@@ -584,6 +600,8 @@ static void __exit omap_dss_unregister_drivers(void)
dsi_uninit_platform_driver();
venc_uninit_platform_driver();
rfbi_uninit_platform_driver();
+   sdi_uninit_platform_driver();
+   dpi_uninit_platform_driver();
dispc_uninit_platform_driver();
dss_uninit_platform_driver();
 
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cec1166..f4398fd 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -378,12 +378,31 @@ int dpi_init_display(struct omap_dss_device *dssdev)
return 0;
 }
 
-int dpi_init(void)
+static int omap_dpi_probe(struct platform_device *pdev)
 {
return 0;
 }
 
-void dpi_exit(void)
+static int omap_dpi_remove(struct platform_device *pdev)
 {
+   return 0;
 }
 
+static struct platform_driver omap_dpi_driver = {
+   .probe  = omap_dpi_probe,
+   .remove = omap_dpi_remove,
+   .driver = {
+   .name   = "omapdss_dpi",
+   .owner  = THIS_MODULE,
+   },
+};
+
+int dpi_init_platform_driver(void)
+{
+   return platform_driver_register(&omap_dpi_driver);
+}
+
+void dpi_uninit_platform_driver(void)
+{
+   platform_driver_unregister(&omap_dpi_driver);
+}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 2bdc400..17a1927 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -785,18 +785,6 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
 
-   r = dpi_init();
-   if (r) {
-   DSSERR("Failed to initialize DPI\n");
-   goto err_dpi;
-   }
-
-   r = sdi_init();
-   if (r) {
-   DSSERR("Failed to initialize SDI\n");
-   goto err_sdi;
-   }
-
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO "OMAP DSS rev %d.%d\n",
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -804,10 +792,7 @@ static int omap_dsshw_probe(struct platform_device *pdev)
dss_runtime_put();
 
return 0;
-err_sdi:
-   dpi_exit();
-err_dpi:
-   dss_runtime_put();
+
 err_runtime_get:
pm_runtime_disable(&pdev->dev);
dss_put_clocks();
@@ -816,9 +801,6 @@ err_runtime_get:
 
 static int omap_dsshw_remove(struct platform_device *pdev)
 {
-   dpi_exit();
-   sdi_exit();
-
pm_runtime_disable(&pdev->dev);
 
dss_put_clocks();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index bb3079d..4373b15 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -267,17 +267,12 @@ int dss_calc_clock_div(bool is_tft, unsigned long req_pck,
 
 /* SDI */
 #ifdef CONFIG_OMAP2_DSS_SDI
-int sdi_init(void);
-void sdi_exit(void);
+int sdi_init_platform_driver(void);
+void sdi_uninit_platform_driver(void);
 int sdi_init_display(struct omap_dss_

[PATCH 14/25] OMAPDSS: remove uses of dss_runtime_get/put

[Tomi Valkeinen]

Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dispc.c |7 ---
 drivers/video/omap2/dss/dpi.c   |   16 +---
 drivers/video/omap2/dss/dsi.c   |   12 +---
 drivers/video/omap2/dss/dss.c   |7 +--
 drivers/video/omap2/dss/dss.h   |3 ---
 drivers/video/omap2/dss/hdmi.c  |   34 ++
 drivers/video/omap2/dss/rfbi.c  |   12 +---
 drivers/video/omap2/dss/sdi.c   |7 ---
 drivers/video/omap2/dss/venc.c  |   12 +---
 9 files changed, 11 insertions(+), 99 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 68aa566..1cccd4c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3596,19 +3596,12 @@ static int omap_dispchw_remove(struct platform_device 
*pdev)
 static int dispc_runtime_suspend(struct device *dev)
 {
dispc_save_context();
-   dss_runtime_put();
 
return 0;
 }
 
 static int dispc_runtime_resume(struct device *dev)
 {
-   int r;
-
-   r = dss_runtime_get();
-   if (r < 0)
-   return r;
-
dispc_restore_context();
 
return 0;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index f4398fd..d7a433b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -202,10 +202,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device 
*dssdev)
goto err_reg_enable;
}
 
-   r = dss_runtime_get();
-   if (r)
-   goto err_get_dss;
-
r = dispc_runtime_get();
if (r)
goto err_get_dispc;
@@ -244,8 +240,6 @@ err_dsi_pll_init:
 err_get_dsi:
dispc_runtime_put();
 err_get_dispc:
-   dss_runtime_put();
-err_get_dss:
if (cpu_is_omap34xx())
regulator_disable(dpi.vdds_dsi_reg);
 err_reg_enable:
@@ -266,7 +260,6 @@ void omapdss_dpi_display_disable(struct omap_dss_device 
*dssdev)
}
 
dispc_runtime_put();
-   dss_runtime_put();
 
if (cpu_is_omap34xx())
regulator_disable(dpi.vdds_dsi_reg);
@@ -283,21 +276,14 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
DSSDBG("dpi_set_timings\n");
dssdev->panel.timings = *timings;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
-   r = dss_runtime_get();
-   if (r)
-   return;
-
r = dispc_runtime_get();
-   if (r) {
-   dss_runtime_put();
+   if (r)
return;
-   }
 
dpi_set_mode(dssdev);
dispc_mgr_go(dssdev->manager->id);
 
dispc_runtime_put();
-   dss_runtime_put();
}
 }
 EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 45ba9e7..c365942 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4769,7 +4769,6 @@ static int omap_dsihw_remove(struct platform_device 
*dsidev)
 static int dsi_runtime_suspend(struct device *dev)
 {
dispc_runtime_put();
-   dss_runtime_put();
 
return 0;
 }
@@ -4778,20 +4777,11 @@ static int dsi_runtime_resume(struct device *dev)
 {
int r;
 
-   r = dss_runtime_get();
-   if (r)
-   goto err_get_dss;
-
r = dispc_runtime_get();
if (r)
-   goto err_get_dispc;
+   return r;
 
return 0;
-
-err_get_dispc:
-   dss_runtime_put();
-err_get_dss:
-   return r;
 }
 
 static const struct dev_pm_ops dsi_pm_ops = {
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 17a1927..06fb5dc 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -62,6 +62,9 @@ struct dss_reg {
 #define REG_FLD_MOD(idx, val, start, end) \
dss_write_reg(idx, FLD_MOD(dss_read_reg(idx), val, start, end))
 
+static int dss_runtime_get(void);
+static void dss_runtime_put(void);
+
 static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -706,7 +709,7 @@ static void dss_put_clocks(void)
clk_put(dss.dss_clk);
 }
 
-int dss_runtime_get(void)
+static int dss_runtime_get(void)
 {
int r;
 
@@ -717,7 +720,7 @@ int dss_runtime_get(void)
return r < 0 ? r : 0;
 }
 
-void dss_runtime_put(void)
+static void dss_runtime_put(void)
 {
int r;
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 4373b15..b53b2e6 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -228,9 +228,6 @@ int dss_ovl_check(struct omap_overlay *ovl,
 int dss_init_platform_driver(void);
 void 

[PATCH 12/25] OMAPDSS: create DPI & SDI devices

[Tomi Valkeinen]

We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.

This patch modifies arch/arm/mach-omap2/display.c to create platform
devices for DPI and SDI, and later patches will implement driver for
them.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/display.c |   57 +
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 46d2a98..2c05a60 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -243,6 +243,46 @@ err:
return ERR_PTR(r);
 }
 
+static struct platform_device *create_simple_dss_pdev(const char *pdev_name,
+   int pdev_id, void *pdata, int pdata_len,
+   struct platform_device *parent)
+{
+   struct platform_device *pdev;
+   int r;
+
+   pdev = platform_device_alloc(pdev_name, pdev_id);
+   if (!pdev) {
+   pr_err("Could not create pdev for %s\n", pdev_name);
+   r = -ENOMEM;
+   goto err;
+   }
+
+   if (parent != NULL)
+   pdev->dev.parent = &parent->dev;
+
+   if (pdev->id != -1)
+   dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
+   else
+   dev_set_name(&pdev->dev, "%s", pdev->name);
+
+   r = platform_device_add_data(pdev, pdata, pdata_len);
+   if (r) {
+   pr_err("Could not set pdata for %s\n", pdev_name);
+   goto err;
+   }
+
+   r = omap_device_register(pdev);
+   if (r) {
+   pr_err("Could not register omap_device for %s\n", pdev_name);
+   goto err;
+   }
+
+   return pdev;
+
+err:
+   return ERR_PTR(r);
+}
+
 int __init omap_display_init(struct omap_dss_board_info *board_data)
 {
int r = 0;
@@ -299,6 +339,23 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
dss_pdev = pdev;
}
 
+   /* Create devices for DPI and SDI */
+
+   pdev = create_simple_dss_pdev("omapdss_dpi", -1, NULL, 0, dss_pdev);
+   if (IS_ERR(pdev)) {
+   pr_err("Could not build platform_device for omapdss_dpi\n");
+   return PTR_ERR(pdev);
+   }
+
+   if (cpu_is_omap34xx()) {
+   pdev = create_simple_dss_pdev("omapdss_sdi", -1, NULL, 0,
+   dss_pdev);
+   if (IS_ERR(pdev)) {
+   pr_err("Could not build platform_device for 
omapdss_sdi\n");
+   return PTR_ERR(pdev);
+   }
+   }
+
return 0;
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 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 04/25] OMAPDSS: TFP410: rename dvi files to tfp410

[Tomi Valkeinen]

Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-3430sdp.c |2 +-
 arch/arm/mach-omap2/board-am3517evm.c   |2 +-
 arch/arm/mach-omap2/board-cm-t35.c  |2 +-
 arch/arm/mach-omap2/board-devkit8000.c  |2 +-
 arch/arm/mach-omap2/board-igep0020.c|2 +-
 arch/arm/mach-omap2/board-omap3beagle.c |2 +-
 arch/arm/mach-omap2/board-omap3evm.c|2 +-
 arch/arm/mach-omap2/board-omap3stalker.c|2 +-
 arch/arm/mach-omap2/board-omap4panda.c  |2 +-
 arch/arm/mach-omap2/board-overo.c   |2 +-
 drivers/video/omap2/displays/Makefile   |2 +-
 drivers/video/omap2/displays/panel-dvi.c|  381 ---
 drivers/video/omap2/displays/panel-tfp410.c |  381 +++
 include/video/omap-panel-dvi.h  |   35 ---
 include/video/omap-panel-tfp410.h   |   35 +++
 15 files changed, 427 insertions(+), 427 deletions(-)
 delete mode 100644 drivers/video/omap2/displays/panel-dvi.c
 create mode 100644 drivers/video/omap2/displays/panel-tfp410.c
 delete mode 100644 include/video/omap-panel-dvi.h
 create mode 100644 include/video/omap-panel-tfp410.h

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 2a26d62..37abb0d 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index feecc96..99790eb 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "am35xx-emac.h"
 #include "mux.h"
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 9e8efe9..45746cb 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -44,7 +44,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 5ea88f5..b063f0d 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -47,7 +47,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index bf87f17..04816c9 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -32,7 +32,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include "mux.h"
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 1795967..8ede8d2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -42,7 +42,7 @@
 #include 
 #include "common.h"
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 9cb0d08..9919d6c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -46,7 +46,7 @@
 #include "common.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "mux.h"
 #include "sdram-micron-mt46h32m32lf-6.h"
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c 
b/arch/arm/mach-omap2/board-omap3stalker.c
index a9acf96..4396bae 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index e1f19b2..b26cd15 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -42,7 +42,7 @@
 #include "common.h"
 #include 
 #include 
-#include 
+#include 
 
 #include "hsmmc.h"
 #include "control.h"
diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index aa83d46..5527c19 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -46,7 +46,7 @@
 #include "common.h"
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/omap2/displays/Makefile 
b/drivers/video/omap2/displays/Makefile
index 58905ef0..58a5176 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,5 +1,5 @@
 obj-$(CONFIG_PANEL_GENERIC_DPI) += panel-generic-dpi.o
-obj-$(CONFIG_PANEL_TFP410) += panel-dvi.o
+obj-$(CONFIG_PANEL_TFP410) += panel-tfp410.o
 obj-$(CONFIG_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
 obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-l

[PATCH 11/25] OMAPDSS: create custom pdevs for DSS omap_devices

[Tomi Valkeinen]

Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/display.c |   88 ++---
 1 file changed, 74 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 07232fd..46d2a98 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, 
unsigned long tput)
return omap_pm_set_min_bus_tput(dev, OCP_INITIATOR_AGENT, tput);
 }
 
+static struct platform_device *create_dss_pdev(const char *pdev_name,
+   int pdev_id, const char *oh_name, void *pdata, int pdata_len,
+   struct platform_device *parent)
+{
+   struct platform_device *pdev;
+   struct omap_device *od;
+   struct omap_hwmod *ohs[1];
+   struct omap_hwmod *oh;
+   int r;
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh) {
+   pr_err("Could not look up %s\n", oh_name);
+   r = -ENODEV;
+   goto err;
+   }
+
+   pdev = platform_device_alloc(pdev_name, pdev_id);
+   if (!pdev) {
+   pr_err("Could not create pdev for %s\n", pdev_name);
+   r = -ENOMEM;
+   goto err;
+   }
+
+   if (parent != NULL)
+   pdev->dev.parent = &parent->dev;
+
+   if (pdev->id != -1)
+   dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
+   else
+   dev_set_name(&pdev->dev, "%s", pdev->name);
+
+   ohs[0] = oh;
+   od = omap_device_alloc(pdev, ohs, 1, NULL, 0);
+   if (!od) {
+   pr_err("Could not alloc omap_device for %s\n", pdev_name);
+   r = -ENOMEM;
+   goto err;
+   }
+
+   r = platform_device_add_data(pdev, pdata, pdata_len);
+   if (r) {
+   pr_err("Could not set pdata for %s\n", pdev_name);
+   goto err;
+   }
+
+   r = omap_device_register(pdev);
+   if (r) {
+   pr_err("Could not register omap_device for %s\n", pdev_name);
+   goto err;
+   }
+
+   return pdev;
+
+err:
+   return ERR_PTR(r);
+}
+
 int __init omap_display_init(struct omap_dss_board_info *board_data)
 {
int r = 0;
-   struct omap_hwmod *oh;
struct platform_device *pdev;
int i, oh_count;
const struct omap_dss_hwmod_data *curr_dss_hwmod;
+   struct platform_device *dss_pdev;
 
/* create omapdss device */
 
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info 
*board_data)
oh_count = ARRAY_SIZE(omap4_dss_hwmod_data);
}
 
-   for (i = 0; i < oh_count; i++) {
-   oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);
-   if (!oh) {
-   pr_err("Could not look up %s\n",
-   curr_dss_hwmod[i].oh_name);
-   return -ENODEV;
-   }
+   dss_pdev = NULL;
 
-   pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
-   curr_dss_hwmod[i].id, oh,
+   for (i = 0; i < oh_count; i++) {
+   pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,
+   curr_dss_hwmod[i].id,
+   curr_dss_hwmod[i].oh_name,
NULL, 0,
-   NULL, 0, 0);
+   dss_pdev);
+
+   if (IS_ERR(pdev)) {
+   pr_err("Could not build omap_device for %s\n",
+   curr_dss_hwmod[i].oh_name);
+
+   return PTR_ERR(pdev);
+   }
 
-   if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
-   curr_dss_hwmod[i].oh_name))
-   return -ENODEV;
+   if (i == 0)
+   dss_pdev = pdev;
}
 
return 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe 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 09/25] OMAPDSS: remove return from platform_driver_unreg

[Tomi Valkeinen]

For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.

Remove the returns.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dispc.c |2 +-
 drivers/video/omap2/dss/dsi.c   |2 +-
 drivers/video/omap2/dss/dss.c   |2 +-
 drivers/video/omap2/dss/hdmi.c  |2 +-
 drivers/video/omap2/dss/rfbi.c  |2 +-
 drivers/video/omap2/dss/venc.c  |2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 262ed29..2aa1fea 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3636,5 +3636,5 @@ int dispc_init_platform_driver(void)
 
 void dispc_uninit_platform_driver(void)
 {
-   return platform_driver_unregister(&omap_dispchw_driver);
+   platform_driver_unregister(&omap_dispchw_driver);
 }
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index a5a8316..45ba9e7 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4816,5 +4816,5 @@ int dsi_init_platform_driver(void)
 
 void dsi_uninit_platform_driver(void)
 {
-   return platform_driver_unregister(&omap_dsihw_driver);
+   platform_driver_unregister(&omap_dsihw_driver);
 }
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index e731aa4..24f5429 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -873,5 +873,5 @@ int dss_init_platform_driver(void)
 
 void dss_uninit_platform_driver(void)
 {
-   return platform_driver_unregister(&omap_dsshw_driver);
+   platform_driver_unregister(&omap_dsshw_driver);
 }
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 2321b75..35580b1 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -914,5 +914,5 @@ int hdmi_init_platform_driver(void)
 
 void hdmi_uninit_platform_driver(void)
 {
-   return platform_driver_unregister(&omapdss_hdmihw_driver);
+   platform_driver_unregister(&omapdss_hdmihw_driver);
 }
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a81ffcb..39aac0b 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1039,5 +1039,5 @@ int rfbi_init_platform_driver(void)
 
 void rfbi_uninit_platform_driver(void)
 {
-   return platform_driver_unregister(&omap_rfbihw_driver);
+   platform_driver_unregister(&omap_rfbihw_driver);
 }
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 30bbb63..7b0e8ed 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -907,5 +907,5 @@ void venc_uninit_platform_driver(void)
if (cpu_is_omap44xx())
return;
 
-   return platform_driver_unregister(&omap_venchw_driver);
+   platform_driver_unregister(&omap_venchw_driver);
 }
-- 
1.7.9.5

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