summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/dss/dpi.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* video: move fbdev to drivers/video/fbdevTomi Valkeinen2014-04-171-774/+0
| | | | | | | | | | | | | | | | | | | | The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch '3.15/dss-dt' into 3.15/fbdevTomi Valkeinen2014-03-201-1/+48
|\ | | | | | | Merge OMAP DSS DT support
| * OMAPDSS: Add DT support to DSSTomi Valkeinen2014-03-191-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add DT support for DSS. Contrary to the non-DT version, the DSS in DT mode contains DPI and SDI outputs, which better reflects the hardware. The non-DT code will be removed after all boards have been converted to DT, so there's no need to change the non-DT code to act the same way. The code for DPI and SDI needs to be refined later to make it possible to add multiple DPI ports. For now, handling just a single DPI port is enough for all the boards. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: fix fck field typesTomi Valkeinen2014-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | 'fck' field in dpi and sdi clock calculation struct is 'unsigned long long', even though it should be 'unsigned long'. This hasn't caused any issues so far. Fix the field's type. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: convert pixel clock to common videomode styleTomi Valkeinen2014-03-051-13/+12
|/ | | | | | | | | | | | | omapdss has its own video-timings struct, but we want to move the common videomode. The first step is to change the omapdss's pixelclock unit from kHz to Hz. Also, omapdss uses "pixel_clock" field name, whereas the common videomode uses "pixelclock" field name. This patch changes the field name also, as that makes it easy to spot any non-converted pixel_clock uses. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
*-. Merge branches '3.14/fbdev', '3.14/dss-misc' and '3.14/dss-fclk' into for-nextTomi Valkeinen2014-01-201-9/+9
|\ \ | | | | | | | | | Merge fbdev topic branches
| | * OMAPDSS: pass pck to dss fck clock calcTomi Valkeinen2013-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need the required pixel clock rate when calculating the dss fclk on SoCs that have a dedicated DSS PLL. This patch changes the code to pass the pck to the calc functions. The pck rate is taken into use in the next patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: remove struct dss_clock_infoTomi Valkeinen2013-11-181-7/+6
| |/ |/| | | | | | | | | | | | | Remove struct dss_clock_info, as it is not usable in a case where DSS fclk comes from a dedicated PLL. Instead, just use the fclk rate in place of dss_clock_info, as that is all that's needed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: don't print errors on -EPROBE_DEFERTomi Valkeinen2014-01-131-1/+2
|/ | | | | | | | | | | Nowadays it's normal to get -EPROBE_DEFER from, e.g., regulator_get. As -EPROBE_DEFER is not really an error, and the driver will be probed fine a bit later, printing an error message will just confuse the user. This patch changes omapdss to print an error for regulator_gets only if the error code is something else than -EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: rename omap_dss_device's 'device' field to 'dst'Tomi Valkeinen2013-08-301-2/+2
| | | | | | | | | | | | | | | | | In the old panel device model we had omap_dss_output entities, representing the encoders in the DSS block. This entity had "device" field, which pointed to the panel that was using the omap_dss_output. With the new panel device model, the omap_dss_output is integrated into omap_dss_device, which now represents a "display entity". Thus the "device" field, now in omap_dss_device, points to the next entity in the display entity-chain. This patch renames the "device" field to "dst", which much better tells what the field points to. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: DPI: remove code related to old panel modelTomi Valkeinen2013-08-291-98/+9
| | | | | | | | | | Now that the old panel drivers have been removed, we can remove the old-model API and related code from the DSS encoder drivers. This patch removes the code from the DPI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: DPI: change regulator handlingTomi Valkeinen2013-08-291-7/+3
| | | | | | | | | | | | Regulator handling for DPI and SDI is currently handled in the core.c, using the 'virtual' omapdss platform device. Nowadays we have proper devices for both DPI and SDI, and so we can handle the regulators inside the respective drivers. This patch moves the regulator handling for DPI into dpi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* Merge tag 'fbdev-3.11-2' of git://gitorious.org/linux-omap-dss2/linux into ↵Jean-Christophe PLAGNIOL-VILLARD2013-06-281-2/+2
|\ | | | | | | | | | | | | | | | | fbdev/for-next Various fbdev changes for 3.11 * xilinxfb updates * Small cleanups and fixes to multiple drivers
| * OMAPDSS: DPI: Fix wrong pixel clock limitTomi Valkeinen2013-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | DPI is supposed to skip odd dividers in the clock path when the pixel clock is higher than 100MHz. The code, however, defines the pixel clock limit as 1MHz. This causes the driver to skip valid clock dividers, possibly making the pixel clock to be further away from the requested one than necessary. Fix the clock limit to 100MHz. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: NeilBrown <neilb@suse.de>
* | OMAPDSS: DPI: Add opsTomi Valkeinen2013-06-171-0/+70
| | | | | | | | | | | | | | | | | | | | Add "ops" style method for using DPI functionality. Ops style calls will allow us to have arbitrarily long display pipelines, where each entity can call ops in the previous display entity. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: public omapdss_register_output()Tomi Valkeinen2013-06-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to allow multiple display block in a video pipeline, we need to give the drivers way to register themselves. For now we have the omapdss_register_display() which is used to register panels, and dss_register_output() which is used to register DSS encoders. This patch makes dss_register_output() public (with the name of omapdss_register_output), which can be used to register also external encoders. The distinction between register_output and register_display is that a "display" is an entity at the end of the videopipeline, and "output" is something inside the pipeline. The registration and naming will be made saner in the future, but the current names and functions are kept to minimize changes during the dss device model transition. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: add THIS_MODULE owner to DSS outputsTomi Valkeinen2013-06-171-0/+1
| | | | | | | | | | | | | | Setup the owner field for DSS output's omap_dss_device so that module refcounting works. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: combine omap_dss_output into omap_dss_deviceTomi Valkeinen2013-06-171-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have omap_dss_device, which represents an external display device, sometimes an external encoder, sometimes a panel. Then we have omap_dss_output, which represents DSS's output encoder. In the future with new display device model, we construct a video pipeline from the display blocks. To accomplish this, all the blocks need to be presented by the same entity. Thus, this patch combines omap_dss_output into omap_dss_device. Some of the fields in omap_dss_output are already found in omap_dss_device, but some are not. This means we'll have DSS output specific fields in omap_dss_device, which is not very nice. However, it is easier to just keep those output specific fields there for now, and after transition to new display device model is made, they can be cleaned up easier than could be done now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: remove omap_dss_start/stop_device()Tomi Valkeinen2013-06-171-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The omap_dss_start_device() and omap_dss_stop_device(), called by the DSS output drivers, are old relics. They originally did something totally else, but nowadays they increase the module ref count for panels that are enabled. This model is quite broken: the panel modules may be used even before they are enabled. For example, configuring the panel requires calls to functions located in the panel modules. In the following patches we try to improve the ref count management for the modules and display devices. The first step, however, is to remove the omap_dss_start/stop_device() totally. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DPI: fix regulators for DTTomi Valkeinen2013-06-171-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some platforms DPI requires a regulator to be enabled to power up the output pins. This regulator is, for some reason, currently attached to the virtual omapdss device, instead of the DPI device. This does not work for DT, as the regulator mappings need to be described in the DT data, and the virtual omapdss device is not present there. Fix the issue by acquiring the regulator in the DPI device. To retain compatibility with the current board files, the old method of getting the regulator is kept. The old method can be removed when the board files have been changed to pass the regulator to DPI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DPI: cleanup pll & regulator initTomi Valkeinen2013-06-171-42/+47
| | | | | | | | | | | | | | Split regulator and DSI PLL init code to their own functions for clarity. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: only probe pdata if there's oneTomi Valkeinen2013-06-171-4/+8
|/ | | | | | | | | omapdss output drivers always read the platform data. This crashes when there's no platform data when using DT. Add a check to read the platform data only if it exists. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Add error handling for dpi_probe_pdataTomi Valkeinen2013-05-021-7/+15
| | | | | | | | Add proper error handling for dpi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the DPI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: use platform_driver_register()Tomi Valkeinen2013-05-021-7/+8
| | | | | | | Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: widen the pck search when using dss fckTomi Valkeinen2013-04-111-2/+2
| | | | | | | | | | | | | | | | | When not using DSI PLL to generate the pixel clock, but DSS FCK, the possible pixel clock rates are rather limited. DSS FCK is currently used on OMAP2 and OMAP3. When using Beagleboard with a monitor that supports high resolutions, the clock rates do not match (at least for me) for the monitor's pixel clocks within the current threshold in the code, which is +/- 1MHz. This patch widens the search up to +/- 15MHz. The search is done in steps, i.e. it first tries to find a rather exact clock, than a bit less exact, etc. so this should not change the cases where a clock was already found. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: use new clock calculation codeTomi Valkeinen2013-04-031-40/+172
| | | | | | Use the new clock calculation code in the DPI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: fix dpi_get_dsidev() for omap5Tomi Valkeinen2013-04-031-8/+22
| | | | | | | | | | | | On OMAP5 the DISPC channels and DSI PLLs are not connected the same way. LCD2 on OMAP5 cannot use any DSI PLL as a source clock, but LCD3 can use DSI2's PLL. This patch fixes dpi_get_dsidev() by adding separate case for OMAP5 to handle the difference. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: add output->dispc_channelTomi Valkeinen2013-04-031-6/+32
| | | | | | | | | | | | | | | | | | The DISPC channel used for each output is currently passed in panel platform data from the board files. To simplify this, and to make the panel drivers less dependent on OMAP, this patch changes omapdss to resolve the channel independently. The channel is resolved based on the OMAP version and, in case of DSI, the DSI module id. This resolved channel is stored into a new field in output, dispc_channel. The few places where dssdev->channel was used are changed to use output->recommended_channel. After this patch, dssdev->channel is obsolete. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: add output->nameTomi Valkeinen2013-04-031-0/+1
| | | | | | | | Add name field to omapdss's outputs so that in the following patches panels refer to the output by their name. The name also helps debugging. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: DPI: remove omap_dss_device usesTomi Valkeinen2013-04-031-20/+15
| | | | | | | | | | | | | The role of struct omap_dss_device will change in the future. The exact details of that are still a bit unclear. However, the less uses of omap_dss_device we have, the easier the change is in the future. This patch removes uses of omap_dss_device from dpi.c, where it can be done neatly, by, for example, passing some lower level parameter in function parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* OMAPDSS: fix TV-out issue with DSI PLLTomi Valkeinen2012-12-131-0/+16
| | | | | | | | | | | | | | | | | | | Commit 0e8276ef75f5c7811b038d1d23b2b42c16efc5ac (OMAPDSS: DPI: always use DSI PLL if available) made dpi.c use DSI PLL for its clock. This works fine, for DPI, but has a nasty side effect on OMAP3: On OMAP3 the same clock is used for DISPC fclk and LCD output. Thus, after the above patch, DSI PLL is used for DISPC and LCD output. If TV-out is used, the TV-out needs DISPC. And if DPI is turned off, the DSI PLL is also turned off, disabling DISPC. For this to work, we'd need proper DSS internal clock handling, with refcounts, which is a non-trivial project. This patch fixes the issue for now by disabling the use of DSI PLL for DPI on OMAP3. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: use dispc's check_timingsTomi Valkeinen2012-12-071-1/+1
| | | | | | | | dpi.c uses dss_mgr_check_timings() to verify video timings, but that function is in the compat layer. Change dpi.c to use the dispc's check instead. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: manage output-dssdev connection in output driversTomi Valkeinen2012-12-071-0/+9
| | | | | | | | | | | | | We currently attach an output to a dssdev in the initialization code for dssdevices in display.c. This works, but doesn't quite make sense: an output entity represents (surprisingly) an output of DSS, which is managed by an output driver. The output driver also handles adding new dssdev's for that particular output. It makes more sense to make the output-dssdev connection in the output driver. This is also in line with common display framework. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: fix crash with dpi_verify_dsi_pll()Tomi Valkeinen2012-11-271-1/+1
| | | | | | | | | | | | | If the DSI support has not been compiled in or the SoC doesn't have DSI hardware, dpi_get_dsidev() returns NULL. This NULL is passed to dpi_verify_dsi_pll() causing a crash. The bug was added with commit 0e8276ef75f5c7811b038d1d23b2b42c16efc5ac (OMAPDSS: DPI: always use DSI PLL if available). Fix this by checking if dsidev is NULL before calling dpi_verify_dsi_pll(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: always use DSI PLL if availableTomi Valkeinen2012-11-051-27/+37
| | | | | | | | | | We currently get the decision whether to use PRCM or DSI PLL clock for DPI from the board file. This is not a good way to handle it, and it won't work with device tree. This patch changes DPI to always use DSI PLL if it's available. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: verify if DSI PLL is operationalTomi Valkeinen2012-11-051-0/+27
| | | | | | | | | | | The SoCs that have DSI module should have a working DSI PLL. However, some rare boards have not connected the powers to the DSI PLL. This patch adds a function that tries to power up the DSI PLL, and reports if that doesn't succeed. DPI uses this function to fall back to PRCM clocks if DSI PLL doesn't work. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pllTomi Valkeinen2012-11-051-6/+6
| | | | | | | Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we can just check if dpi.dsidev != NULL. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hide dss_select_dispc_clk_source()Tomi Valkeinen2012-11-051-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | dss.c currently exposes functions to configure the dispc source clock and lcd source clock. There are configured separately from the output drivers. However, there is no safe way for the output drivers to handle dispc clock, as it's shared between the outputs. Thus, if, say, the DSI driver sets up DSI PLL and configures both the dispc and lcd clock sources to that DSI PLL, the resulting dispc clock could be too low for, say, HDMI. Thus the output drivers should really only be concerned about the lcd clock, which is what the output drivers actually use. There's lot to do to clean up the dss clock handling, but this patch takes one step forward and removes the use of dss_select_dispc_clk_source() from the output drivers. After this patch, the output drivers only configure the lcd source clock. On omap4+ the dispc src clock is never changed from the default PRCM source. On omap3, where the dispc and lcd clocks are actually the same, setting the lcd clock source sets the dispc clock source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: export dss_get_def_display_name()Tomi Valkeinen2012-10-291-1/+1
| | | | | | | | Export dss_get_def_display_name() with the name of omapdss_get_def_display_name() so that omapfb can use it after the next patch which moves default display handling to omapfb. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add missing include for string.hTomi Valkeinen2012-09-281-0/+1
| | | | | | | | | | | | | Both dpi.c and sdi.c use strcmp(), but do not include string.h. With some Kconfig options string.h is included implicitly, but with some other the compilation fails: drivers/video/omap2/dss/dpi.c:407:5: error: implicit declaration of function 'strcmp' Include string.h in both dpi.c and sdi.c Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja2012-09-261-9/+16
| | | | | | | | | | | With addition of output entities, a device connects to an output, and an output connects to overlay manager. Replace the dssdev->manager references with dssdev->output->manager to access the manager correctly. When enabling the DPI output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: outputs: Create and register output instancesArchit Taneja2012-09-261-0/+24
| | | | | | | | | | | | | | | | | Add output structs to output driver's private data. Register output instances by having an init function in the probes of the platform device drivers for different outputs. The *_init_output for each output registers the output and fill up the output's plaform device, type and id fields. The *_uninit_output functions unregister the output. In the probe of each interface driver, the output entities are initialized before the *_probe_pdata() functions intentionally. This is done to ensure that the output entity is prepared before the panels connected to the output are registered. We need the output entities to be ready because OMAPDSS will try to make connections between overlays, managers, outputs and devices during the panel's probe. Signed-off-by: Archit Taneja <archit@ti.com>
* Merge OMAP5 DSS changes to omapdssTomi Valkeinen2012-09-251-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This series adds basic OMAP5 DSS functionality, mainly related to DSS core, DPI and DSI. * omap5-dss: OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5 OMAPDSS: DSI: Add code to disable PHY DCC OMAPDSS: DSI: Add new linebuffer size for OMAP5 OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSEL OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCO OMAPDSS: Add support for DPI source selection OMAPDSS: move dss feats to the end of dss.c OMAPDSS: Add basic omap5 features to dss and dispc OMAPDSS: DSI: improve DSI clock calcs for DISPC
| * OMAPDSS: Add support for DPI source selectionTomi Valkeinen2012-09-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We can select the video source for DPI output as follows: OMAP2/3: always LCD1 OMAP4: LCD2 or DIGIT OMAP5: LCD1/LCD2/LCD3/DIGIT This patch adds support to select the source, and makes dpi.c call the function to set the source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Anders <x0132446@ti.com>
* | OMAPDSS: alloc dssdevs dynamicallyTomi Valkeinen2012-09-181-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently create omap_dss_devices statically in board files, and use those devices directly in the omapdss driver. This model prevents us from having the platform data (which the dssdevs in board files practically are) as read-only, and it's also different than what we will use with device tree. This patch changes the model to be in line with DT model: we allocate the dssdevs dynamically, and initialize them according to the data in the board file's dssdev (basically we memcopy the dssdev fields). The allocation and registration is done in the following steps in the output drivers: - Use dss_alloc_and_init_device to allocate and initialize the device. The function uses kalloc and device_initialize to accomplish this. - Call dss_copy_device_pdata to copy the data from the board file's dssdev - Use dss_add_device to register the device. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: register only one display device per outputTomi Valkeinen2012-09-181-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have boards with multiple panel devices connected to the same physical output, of which only one panel can be enabled at one time. Examples of these are Overo, where you can use different daughter boards that have different LCDs, and 3430SDP which has an LCD and a DVI output and a physical switch to select the active display. These are supported by omapdss so that we add all the possible display devices at probe, but the displays are inactive until somebody enables one. At this point the panel driver starts using the DSS, thus reserving the physcal resource and excluding the other panels. This is problematic: - Panel drivers can't allocate their resources properly at probe(), because the resources can be shared with other panels. Thus they can be only reserved at enable time. - Managing this in omapdss is confusing. It's not natural to have child devices, which may not even exist (for example, a daughterboard that is not connected). Only some boards have multiple displays per output, and of those, only very few have possibility of switching the display during runtime. Because of the above points: - We don't want to make omapdss and all the panel drivers more complex just because some boards have complex setups. - Only few boards support runtime switching, and afaik even then it's not required. So we don't need to support runtime switching. Thus we'll change to a model where we will have only one display device per output and this cannot be (currently) changed at runtime. We'll still have the possibility to select the display from multiple options during boot with the default display option. This patch accomplishes the above by changing how the output drivers register the display device. Instead of registering all the devices given from the board file, we'll only register one. If the default display option is set, the output driver selects that display from its displays. If the default display is not set, or the default display is not one of the output's displays, the output driver selects the first display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: omap_dss_register_device() doesn't take display indexTomi Valkeinen2012-09-181-1/+1
|/ | | | | | | | | | | | | | | | We used to have all the displays of the board in one list, and we made a "displayX" directory in the sysfs, where X was the index of the display in the list. This doesn't work anymore with device tree, as there's no single list to get the number from, and it doesn't work very well even with non-DT as we need to do some tricks to get the index nowadays. This patch changes omap_dss_register_device() so that it doesn't take disp_num as a parameter anymore, but uses a private increasing counter for the display number. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: fix set_timingsTomi Valkeinen2012-09-071-14/+0
| | | | | | | | | | | | | | set_timings function of DSS's output drivers are not consistent. Some of them disable the output, set the timings, and re-enable the output. Some set the timings on the fly, while the output is enabled. And some just store the given timings, so that they will be taken into use next time the output is enabled. We require the DISPC output to be disabled when changing the timings, and so we can change all the output drivers' set_timings to just store the given timings. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove unnecessary includesTomi Valkeinen2012-09-071-1/+0
| | | | | | Remove unnecessary includes from omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Remove cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-221-5/+7
| | | | | | | | | | | | | | The OMAP3 checks have been removed and replaced by a dss feature FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches "OMAP: DSS2: enable VDDS_DSI when using DPI" (8a2cfea8cc) by Tomi Valkeinen <tomi.valkeinen@nokia.com> and "ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c" (4041071571) by Russell King <rmk+kernel@arm.linux.org.uk> had introduced these checks. As it is evident from these patches a dependency exists for some DSS pins on VDDS_DSI which is better shown by dss feature FEAT_DPI_USES_VDDS_DSI. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 14:27:19 +0100