13 Commits

Author SHA1 Message Date
Tomi Valkeinen
ecc8b37089 OMAPDSS: Add panel dev pointer to dssdev
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.

After we've finished the removal of the dss bus, we see the following
changes:

- struct omap_dss_device won't be a real Linux device anymore, but more
  like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
  entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
  platform/i2c/spi/etc devices/drivers, whichever fits the control
  mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
  fill the required fields, and register the omap_dss_device to
  omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
  dev pointer to the actual device that manages the omap_dss_device.

The model described above resembles the model that has been discussed
with CDF (common display framework).

For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.

For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.

Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17 14:00:50 +03:00
Tomi Valkeinen
bca3913034 OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
If the I2C adapter needed by the TFP410 device is not available yet,
return EPROBE_DEFER so that the device will get probed again.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02 12:25:44 +03:00
Archit Taneja
a0d8dde9cb OMAPDSS: panels: keep platform data of all panels in a single header
Structs for platform data of omapdss panels are found in headers in the
'include/video/' path. Board files populate these structs with platform
specific values, and the panel driver uses these to configure the panel.

Currently, each panel has it's own header in the above path. Move all the
omapdss panel platform data structs to a single header omap-panel-data.h.
This is useful because:

- All other omapdss panel drivers will be modified to use platform data. This
  would lead to a lot of panel headers usable only by omapdss. A lot of these
  platform data structs are trivial, and don't really need a separate header.
- Platform data would be eventually removed, and platform information would be
  passed via device tree. Therefore, omapdss panel platform data structs are
  temporary, and will be easier to remove if they are all in the same header.
- All board files will have to include the same header to configure a panel's
  platform data, that makes the board files more consistent.

Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03 15:17:45 +03:00
Tomi Valkeinen
998c336d4c OMAPDSS: remove omap_dss_device's suspend/resume
The panel drivers contain enable, disable, suspend and resume calls.
The suspend and resume are effectively identical to disable and enable.

This patch removes panel suspend and enable code from omapdss and the
panel drivers, and replaces their use with enable and disable.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-10-24 08:46:23 +03:00
Tomi Valkeinen
a6df3fd963 OMAPDSS: TFP410: use devm_gpio_request_one
Use devm_ version instead of the regular gpio_request_one to simplify
the error handling.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-09-07 20:02:09 +03:00
Archit Taneja
c6b393d4bc OMAPDSS: DPI: Maintain copy of number of data lines in driver data
The DPI driver currently relies on the omap_dss_device struct to configure the
number of data lines as specified by the panel. This makes the DPI interface
driver dependent on the omap_dss_device struct.

Make the DPI driver data maintain it's own data lines field. A panel driver
is expected to call omapdss_dpi_set_data_lines() before enabling the interface.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-16 18:00:55 +05:30
Archit Taneja
bdcae3cc39 OMAPDSS: DPI displays: Take care of panel timings in the driver itself
The timings maintained in omap_dss_device(dssdev->panel.timings) should be
maintained by the panel driver itself. It's the panel drivers responsibility
to update it if a new set of timings is to be configured. The DPI interface
driver shouldn't be responsible of updating the panel timings, it's responsible
of maintianing it's own copy of timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja
c499144c3b OMAPDSS: DPI: Maintain our own timings field in driver data
The DPI driver currently relies on the timings in omap_dss_device struct to
configure the DISPC accordingly. This makes the DPI interface driver dependent
on the omap_dss_device struct.

Make the DPI driver data maintain it's own timings field. The panel driver is
expected to call dpi_set_timings()(renamed to omapdss_dpi_set_timings) to set
these timings before the panel is enabled.

In the set_timings() op, we still ensure that the omap_dss_device timings
(dssdev->panel.timings) are configured. This will later be configured only by
the DPI panel drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-08-13 15:44:39 +05:30
Archit Taneja
a8d5e41cef OMAPDSS: Add some new fields to omap_video_timings
Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:

- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock

Out of these parameters, Hsync and Vsync logic levels are a part of the timings
in the Xorg modeline configuration. So it makes sense to move the to
omap_video_timings. The rest aren't a part of modeline, but it still makes
sense to move these since they are related to panel timings.

These fields stored in omap_panel_config in dssdev are configured for LCD
panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers.

Add the above fields in omap_video_timings. Represent their state via new enums.

Add these parameters to the omap_video_timings instances in the panel drivers.
Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in
omap_panel_config for now. The struct will be removed later.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:15:49 +03:00
Archit Taneja
5ae9eaa6db OMAPDSS: Remove passive matrix LCD support (part 2)
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.

We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.

Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-06-29 10:10:03 +03:00
Russ Dill
af461d64e1 OMAPDSS: TFP410: use gpio_set_value_cansleep
The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.

Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 15:09:29 +03:00
Tomi Valkeinen
958f2717b8 OMAPDSS: TFP410: pdata rewrite
To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:50 +03:00
Tomi Valkeinen
dac8eb5f1d OMAPDSS: TFP410: rename dvi files to tfp410
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 <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:51:05 +03:00