summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-05-02OMAPFB: defer probe if no displaysTomi Valkeinen
omapfb requires the panel drivers to have been probed when omapfb is initialized. omapfb does not support insertion of new panels after its probe. This causes a problem in case omapdss or the panel probes have been deferred due to EPROBE_DEFER error, as omapfb won't find any displays. As a quick fix, this patch changes the omapfb probe so that if omapfb does not find any displays, it'll return EPROBE_DEFER. This is not perfect, as with a board with no displays, omapfb will get deferred forever. Also, if the board has multiple displays, but only some of them have been probed, omapfb will start and leave the unprobed displays out. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPFB: use module_platform_driver()Tomi Valkeinen
Instead of using platform_driver_probe(), use module_platform_driver() so that we can support deferred probing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: Makefile: move omapfb after panelsTomi Valkeinen
omapfb requires the panels to have been probed before omapfb's probe. We currently manage that by having omapfb in late initcall level. However, a much simpler way is to just change the makefile so that omapfb is after the panel drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DPI: fix compilation if DSI not compiled inTomi Valkeinen
Commit 100c826235793345efe06b3558cc9d36166b1e26 (OMAPDSS: DPI: use new clock calculation code) breaks dpi.c compilation if DSI is not enabled in the kernel configuration. Fix compilation by adding dummy inline functions for the ones that dpi.c references. The functions will never be called, as dpi.c knows that there is no DSI device available. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-15OMAPDSS: Merge omapdss topic branchesTomi Valkeinen
2013-04-11drm/omap: add statics to a few structsTomi Valkeinen
Some static structs are not marked as static. Add it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-11drm/omap: Fix and improve crtc and overlay manager correlationArchit Taneja
The omapdrm driver currently takes a config/module arg to figure out the number of crtcs it needs to create. We could create as many crtcs as there are overlay managers in the DSS hardware, but we don't do that because each crtc eats up one DSS overlay, and that reduces the number of planes we can attach to a single crtc. Since the number of crtcs may be lesser than the number of hardware overlay managers, we need to figure out which overlay managers to use for our crtcs. The current approach is to use pipe2chan(), which returns a higher numbered manager for the crtc. The problem with this approach is that it assumes that the overlay managers we choose will connect to the encoders the platform's panels are going to use, this isn't true, an overlay manager connects only to a few outputs/encoders, and choosing any overlay manager for our crtc might lead to a situation where the encoder cannot connect to any of the crtcs we have chosen. For example, an omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot connect to the hdmi encoder at all. The only manager that could have connected to hdmi was the TV overlay manager. Therefore, there is a need to choose our overlay managers keeping in mind the panels we have on that platform. The new approach iterates through all the available panels, creates encoders and connectors for them, and then tries to get a suitable overlay manager to create a crtc which can connect to the encoders. We use the dispc_channel field in omap_dss_output to retrieve the desired overlay manager's channel number, we then check whether the manager had already been assigned to a crtc or not. If it was already assigned to a crtc, we assume that out of all the encoders which intend use this crtc, only one will run at a time. If the overlay manager wan't assigned to a crtc till then, we create a new crtc and link it with the overlay manager. This approach just looks for the best dispc_channel for each encoder. On DSS HW, some encoders can connect to multiple overlay managers. Since we don't try looking for alternate overlay managers, there is a greater possibility that 2 or more encoders end up asking for the same crtc, causing only one encoder to run at a time. Also, this approach isn't the most optimal one, it can do either good or bad depending on the sequence in which the panels/outputs are parsed. The optimal way would be some sort of back tracking approach, where we improve the set of managers we use as we iterate through the list of panels/encoders. That's something left for later. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-11drm/omap: Take a fb reference in omap_plane_update()Archit Taneja
When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and passes control to the update_plane op defined by the drm driver. In omapdrm, we have a worker thread which queues framebuffers objects received from update_plane and displays them at the appropriate time. It is possible that the framebuffer is destoryed by userspace between the time of calling the ioctl and apply-worker being scheduled. If this happens, the apply-worker holds a pointer to a framebuffer which is already destroyed. Take an extra refernece/unreference of the fb in omap_plane_update() to prevent this from happening. A reference is taken of the fb passed to update_plane(), the previous framebuffer (held by plane->fb) is unreferenced. This will prevent drm from destroying the framebuffer till the time it's unreferenced by the apply-worker. This is in addition to the exisitng reference/unreference in update_pin(), which is taken for the scanout of the plane's current framebuffer, and an unreference the previous framebuffer. Signed-off-by: Archit Taneja <archit@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-11drm/omap: Make fixed resolution panels workArchit Taneja
The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops or not, and that leads to a crash. The following things are done to make fixed panels work: - The omap_connector's detect function is modified such that it considers panel types which are generally fixed panels as always connected(provided the panel driver doesn't have a detect op). Hence, the connector corresponding to these panels is always in a 'connected' state. - If a panel driver doesn't have a check_timings op, assume that it supports the mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function) - The function omap_encoder_update shouldn't really do anything for fixed resolution panels, make sure that it calls set_timings only if the panel driver has one. Signed-off-by: Archit Taneja <archit@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-11drm/omap: fix modeset_init if a panel doesn't satisfy omapdrm requirementsArchit Taneja
modeset_init iterates through all the registered omapdss devices and has some initial checks to see if the panel has a driver and the required driver ops for it to be usable by omapdrm. The function bails out from modeset_init if a panel doesn't meet the requirements, and stops the registration of the future panels and encoders which come after it, that isn't the correct thing to do, we should go through the rest of the panels. Replace the 'return's with 'continue's. Signed-off-by: Archit Taneja <archit@ti.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-11OMAPDSS: DPI: widen the pck search when using dss fckTomi Valkeinen
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>
2013-04-11OMAPDSS: fix dss_fck clock rate roundingTomi Valkeinen
DSS func clock is calculated with prate / div * m. However, the current omapdss code calculates it with prate * m / div, which yields a slightly different result when there's a remainder. For example, 432000000 / 14 * 2 = 61714284, but 432000000 * 2 / 14 = 61714285. In addition to that, the clock framework wants the clock rate given with clk_set_rate to be higher than the actual (truncated) end result. So, if prate is 432000000, and div is 14, the real result is 30857142.8571... We need to call clk_set_rate with 30857143, which gives us a clock of 30857142. That's why we need to use DIV_ROUND_UP() when calling clk_set_rate. This patch fixes the clock calculation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10omapdss: use devm_clk_get()Archit Taneja
Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi and venc. This reduces code and simplifies error handling. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10OMAPDSS: nec-nl8048 panel: Use dev_pm_opsLars-Peter Clausen
Use dev_pm_ops instead of the deprecated legacy suspend/resume callbacks. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5Archit Taneja
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve more power savings when DISPC is configured in Smart Standby mode. This mechanism leads to underflows when multiple DISPC pipes are enabled. There is a register field which can let us revert to the older mechanism of asserting Mstandby. Configure this field to prevent underflows. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffersArchit Taneja
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This is needed because the stride for the UV plane(using a 16 bit Tiler container) is double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or 180 degree views. The ROW_INC register is meant for the Y plane, and the HW will calculate the row increment needed for the UV plane by using double the stride value based on whether this bit is set or not. Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180 degrees. The stride value is the same for 90 and 270 degree Tiler views, hence the bit shouldn't be set. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10omapdss: Features: Fix some parameter rangesArchit Taneja
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the DSI PLL Fint range, this was previously just copied from the OMAP4 param range struct. Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10omapdss: DISPC: add max pixel clock limits for LCD and TV managersArchit Taneja
Each version of OMAP has a limitation on the maximum pixel clock frequency supported by an overlay manager. This limit isn't checked by omapdss. Add dispc feats for lcd and tv managers and check whether the target timings can be supported or not. The pixel clock limitations are actually more complex. They depend on which OPP OMAP is in, and they also depend on which encoder is the manager connected to. The OPP dependence is ignored as DSS forces the PM framework to be on OPP100 when DSS is enabled, and the encoder dependencies are ignored by DISPC for now. These limits should come from the encoder driver. The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10OMAPDSS: DSI: Use devm_clk_get()Sachin Kamat
Using devm_clk_get cleans up some code. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-10drivers: video: omap2: dss: Use PTR_RET functionAlexandru Gheorghiu
Use PTR_RET function instead of IS_ERR and PTR_ERR. Patch found using coccinelle. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: VENC: remove platform_enable/disable callsArchit Taneja
The platform_enable/disable callbacks in board files for VENC omap_dss_device instances don't do anything. Hence, we can remove these callbacks from the VENC driver. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: n8x0 panel: remove use of platform_enable/disableArchit Taneja
The n8x0 panel driver now manages the gpios required to configure the panel. This was previously done in panel_n8x0_data's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_n8x0_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the uses of platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: n8x0 panel: handle gpio data in panel driverArchit Taneja
The n8x0 panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. A platform data struct called panel_n8x0_data already exists to hold gpio numbers and other platform data. However, the gpio requests are expected to be done in the board file and not the panel driver. Request all the gpios in the panel driver so that the board files which use the the panel don't need to do it. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: picodlp panel: remove platform_enable/disable callbacksArchit Taneja
The picodlp panel driver now manages the gpios required to configure the panel. This was previously done in omap_dss_device's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_generic_dpi_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: picodlp panel: handle gpio data in panel driverArchit Taneja
The picodlp panel driver leaves gpio requests to the platform's board file. These should happen in the panel driver itself. A platform data struct called picodlp_panel_data already exists to hold gpio numbers and other platform data. Request all the gpios in the panel driver so that the board files which use the the panel don't need to do it. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: tpo-td043: remove platform_enable/disable callbacksArchit Taneja
The tpo-td043 panel driver now manages the gpios required to configure the panel. This was previously done in omap_dss_device's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_tpo_td043_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: tpo-td043 panel: handle gpios in panel driverArchit Taneja
The tpo-td043mtea1 panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. Create a platform data struct for the panel, this contains the reset gpio number used by the panel driver, this struct will be passed to the panel driver as platform data. The driver will request and configure the reset gpio rather than leaving it to platform callbacks in board files. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: nec-nl8048 panel: remove platform_enable/disable callbacksArchit Taneja
The nec-nl8048 panel driver now manages the gpios required to configure the panel. This was previously done in omap_dss_device's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_nec_nl8048_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: nec-nl8048 panel: handle gpios in panel driverArchit Taneja
The nec-nl8048hl11-01 panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. Create a platform data struct for the panel, this contains the gpio numbers used by the panel driver, this struct will be passed to the panel driver as platform data. The driver will request and configure these gpios rather than leaving it to platform callbacks in board files. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: acx565akm panel: handle gpios in panel driverArchit Taneja
The acx565akm panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. Create a platform data struct for the panel, this contains the reset gpio number used by the panel driver, this struct will be passed to the panel driver as platform data. The driver will request and configure the reset gpio rather than leaving it to platform callbacks in board files. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: sharp-ls panel: remove platform_enable/disable callbacksArchit Taneja
The sharp-ls panel driver now manages the gpios required to configure the panel. This was previously done in omap_dss_device's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_sharp_ls037v7dw01_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: LS037V7DW01: handle gpios in panel driverTomi Valkeinen
Move the GPIO handling from board file's platform callbacks to the panel driver, which gets the gpios via platform data. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: generic dpi panel: remove uses of platform_enable/disable opsArchit Taneja
The generic dpi panel driver now sets the gpios required to configure the panel. This was previously done in platform_enable/disable callbacks in board files. All the board files using generic dpi panel now correctly pass the gpio related information as platform data, which is needed by the panel driver to configure the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: lb035q02 panel: remove platform_enable/disable callbacksArchit Taneja
The lgphilips panel driver now manages the gpios required to configure the panel. This was previously done in omap_dss_device's platform_enable/disable callbacks defined in board files using this panel. All the board files using this panel now pass the gpio information as platform data via the panel_generic_dpi_data struct, which is needed by the panel driver to configure the gpios connected to the panel. Hence, the platform_enable/disable ops can be safely removed now. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: lb035q02: handle gpios in panel driverArchit Taneja
The lgphilips panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. Use the platform data as defined for generic dpi panels to pass gpio information to the lgphilips driver. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: generic dpi panel: handle gpios in panel driverTomi Valkeinen
The generic dpi panel driver leaves gpio configurations to the platform_enable and disable calls in the platform's board file. These should happen in the panel driver itself. Add a generic way of passing gpio information to the generic dpi panel driver via it's platform_data. This information includes the number of gpios used by the panel, the gpio number and logic level (active high/low) for each gpio. This gpio data will be used by the driver to request and configure the gpios required by the panel. This will help in removing the need for the panel drivers to have platform related callbacks. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: panel acx565akm: remove omap_dss_device maximum backlight level usageArchit Taneja
The omap_dss_device structs's max_backlight_level is used to pass maximum backlight level for the platform. However, no board file using this panel populates this field. Therefore, we remove it's usage from the panel driver. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: picodlp: use devm_kzalloc for allocating driver dataArchit Taneja
Use devm_kzalloc instead of kzalloc to allocate driver data for the picodlp panel driver. This simplifies the driver's probe and remove functions. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: lb035q02: use devm_kzalloc for allocating driver dataArchit Taneja
Use devm_kzalloc instead of kzalloc to allocate driver data for the lg phillips panel driver. This simplifies the driver's probe and remove functions. Cc: Steve Sakoman <steve@sakoman.com> Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: Generic DPI Panel: use devm_kzalloc for allocating driver dataArchit Taneja
Use devm_kzalloc instead of kzalloc to allocate driver data for the generic dpi panel driver. This simplifies the driver's probe and remove functions. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: n8x0: remove platform backlight callsTomi Valkeinen
The n8x0 panel contains support to call platform backlight functions. These are not used by any board, and can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: NEC-nl8048hl11: remove platform backlight supportArchit Taneja
NEC-nl8048hl11 driver contains support to call platform backlight functions. These are not used by any board, and can be removed. Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: ls037v7dw01: remove platform backlight callsTomi Valkeinen
Sharp ls037v7dw01 driver contains support to call platform backlight functions. These are not used by any board, and can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: acx565akm: remove platform backlight callsTomi Valkeinen
acx565akm has support to call set_backlight/get_backlight in platform code. They are not used by any board, and thus can be removed from the driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
2013-04-03OMAPDSS: remove unused old clock calculation codeTomi Valkeinen
Now that the old clock calculation code is no longer used, we can remove it from the driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: DSI: use new clock calculation codeTomi Valkeinen
Use the new clock calculation code in the DSI driver. The new code does not need DSI video mode parameters from the panel driver, like the old code does. Instead the new code is given the normal video timings, and a few DSI parameters, which are used to create DSI video timings. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: DPI: use new clock calculation codeTomi Valkeinen
Use the new clock calculation code in the DPI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: SDI: use new clock calculation codeTomi Valkeinen
Use the new clock calculation code in the SDI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: DSI: add new clock calculation codeTomi Valkeinen
Add new way to iterate over DSI PLL and HSDIV clock divisors. dsi_pll_calc() and dss_hsdiv_calc() provide a generic way to go over all the divisors, within given clock range. The functions will call a callback function for each divider set, making the function reusable for all use cases. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-03OMAPDSS: DSS: add new clock calculation codeTomi Valkeinen
Add new way to iterate over DSS clock divisors. dss_div_calc() provides a generic way to go over all the divisors, within given clock range. dss_div_calc() will call a callback function for each divider set, making the function reusable for all use cases. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>