Re: [RFC PATCH 00/20] HWMOD Adaptation for DSS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/23/2010 5:57 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamy<svadivu@xxxxxx>

Patch Base:
===========
url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
branch "pm-wip/hwmods-omap4"
Commit id: f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726
Description:  Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base
----------------------------------------------------------------------------

RFC focus on the proposed design of the HWMOD adaptation to the current DSS
driver.  DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each
corresponding to the HWMOD class in the HWMOD database.

No Hardcoding of silicon data:
HWMOD database abstracts the SOC data like base addr, irq numbers and are
implemented in this patch series.

Continue to have custom bus for display panels:
"omapdss" driver continues to be a platform driver that registers the custom
bus.  It also continues to register the display panels(omap_dss_device) on the
board to the panel drivers (omap_dss_driver)
For Eg:  primary lcd device would be registered with lcd panel driver.
lcd panel driver if it is on a parallel interface would use library functions
exported from dpi.o.  if it is on a dsi interface would use library functions
exported from dsi platform driver(dsi.o).

Clocks:
Handling of clocks in DSS only is one of the design approach, that does not
change the existing implementation.  If each of the DSS HW IPs had to handle
their own clocks, then corresponding clock changes are requested in the HWMOD
database as well which is not the present scenario.
For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart
for the dss main clocks.  Currently VENC driver needs to be aware of this and has to
use clk_get/put, clk_enable/disable, since VENC HWMOD is not aware of 54MCLK.


Current dss driver:
-------------------
1.  Omapdss platform driver
         - initialises necessary Ips dss, dispc.
         - also initialises Ips like sdi, dsi, venc, rfbi
         - creates a custom bus and registers the display devices/drivers
         connected on the board to the custom bus.

2.  Suspend/resume of omapdss
         - in turn sends suspend/resume calls for each of the display devices
         registered to it.

Proposed change:
----------------
Platform driver for each DSS HW IP in addition to the software "omapdss"
driver.

Omapdss platform driver
         - initialises necessary software libraries like dpi, sdi.
         - continues to have a custom bus and registers the display devices
         and drivers connected on the board to the custom bus.
         - continues to handle suspend/resume of the display devices registered
         to the custom bus.

DSS platform driver
         - initialises DSS IP alone
	- Handles the clocks related to the DSS and other DSSHW IPs like RFBI,
	DSI, VENC, DISPC.  Previously this was a part of "omapdss" driver in core.c
	- Continues to handle the DSS IRQs.
	- No suspend/resume hooks.

DISPC platform driver
         - initialises DSS IP alone
	- Gets the required clock from DSS platform driver.
	- No suspend/resume hooks.
	- Continues to provide DISPC library functions.

DSI platform driver
         - initialises DSI IP alone
	- Gets the required clock from DSS platform driver.
	- No suspend/resume hooks.
	- Continues to provide DISPC library functions.

RFBI, VENC platform drivers
         - initialises DSI,VENC IPs
	- Gets the required clock from DSS platform driver.
	- No suspend/resume hooks.
	- Continues to provide DISPC library functions.

The patches are tested on OMAP3430 and 3630.

The below points are yet to be done, still the RFC is put out to start the
discussion on the design approach taken.

Yet to be implemented:
1) All the platform driver registration except DSS, are within the file core.c.
Registeration of these driver would go out of order when seperated to its own file.
Will test the implementation and send in the next version for review.
2) Usage of regulators by different drivers needs to implemented.
For Eg: Regulator used by VENC is moved to venc driver.  But vdda_dac would be
needed by DPI and DSI as well.  Need to verify if a patch like this would work.
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
	REGULATOR_SUPPLY("vdds_dsi", "omapdss"),
+	REGULATOR_SUPPLY("vdds_dsi", "dss_dsi1"),

You can add any consumer you want for a given regulator supply as soon as you have a valid dev or dev_name.

};
3) SYSCONFIG of each of the dss HW IP has to be removed from the driver.
HWMOD framework is supposed to take care of it.  This change would be done in
the next version of the patch series.
4) OMAP2 HWMOD database is yet to be generated.
5) Number of DSS HW IPs in a silicon are hardcoded in devices.c.
It is not evident from HWMOD database.  Need to find a cleaner way to register for OMAP2,3,4.

What does that mean exactly? Could you elaborate?

6) Module support for omapdss driver as per current DSS2 design.

What about the usage of clock framework, or the management of DSS features, we already discussed?
What about OMAP4?

Benoit



Senthilvadivu Guruswamy (20):
   DSS HWMOD database generation for OMAP3
   Move DSS driver register from board to mach_omap2
   Build omap_device for each DSS HW IP
   Create platform_driver for each DSS HW IP
   Move dss platform driver to dss.c
   DSS driver name change in clock database
   Move clock functions from core driver to dss driver
   Replace clk_enable/disable APIs with HWMOD APIs
   Move dss_init to dsshw_probe
   Move rfbi init to rfbi probe
   Move dispc init to dispc probe
   Move venc init to venc probe
   Move dsi init to dsi probe
   Pass platform_device argument to rfbi,dispc
   Use platform device to get DSS base addr
   Get DISPC base addr with platform device
   Get VENC base addr from platform device
   Get DSI base addr with platform device
   Get RFBI baseaddr with platform device
   Get DSS IRQ with platform device

  arch/arm/mach-omap2/board-3430sdp.c        |   25 +-
  arch/arm/mach-omap2/clock3xxx_data.c       |   14 +-
  arch/arm/mach-omap2/devices.c              |   78 ++++
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  346 ++++++++++++++++
  arch/arm/plat-omap/include/plat/display.h  |   14 +
  drivers/video/omap2/dss/core.c             |  585 +++++++---------------------
  drivers/video/omap2/dss/dispc.c            |    7 +-
  drivers/video/omap2/dss/dsi.c              |    5 +-
  drivers/video/omap2/dss/dss.c              |  450 +++++++++++++++++++++-
  drivers/video/omap2/dss/dss.h              |   20 +-
  drivers/video/omap2/dss/rfbi.c             |    7 +-
  drivers/video/omap2/dss/venc.c             |   24 +-
  12 files changed, 1085 insertions(+), 490 deletions(-)


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

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux