- 02 7月, 2015 1 次提交
-
-
由 Tomi Valkeinen 提交于
After the commit 736e60dd ("OMAPDSS: componentize omapdss") the dss core device will wait until all the subdevices have been successfully probed. However, we don't have a working driver for RFBI, so if RFBI device exists, omapdss will never get probed. All the .dtsi files set RFBI as disabled, except am4372.dtsi. This causes omapdss probe to not finish on AM4 devices. This patch makes omapdss driver skip adding rfbi device as a subcomponent, solving the issue. This should be reverted when we have a working RFBI driver. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: NFelipe Balbi <balbi@ti.com>
-
- 22 6月, 2015 1 次提交
-
-
由 Tomi Valkeinen 提交于
-
- 18 6月, 2015 1 次提交
-
-
由 Stephen Boyd 提交于
This code is no longer used now that mach-msm has been removed. Delete it. Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Brown <davidb@codeaurora.org> Cc: Bryan Huntsman <bryanh@codeaurora.org> Cc: Daniel Walker <dwalker@fifo99.com> Signed-off-by: NStephen Boyd <sboyd@codeaurora.org> Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 17 6月, 2015 19 次提交
-
-
由 Tomi Valkeinen 提交于
At the moment when HDMI video output is stopped, we just clear the enable bit and return. While it's unclear if this can cause any issues, I think it's still better to wait for FRAMEDONE interrupt after clearing the enable bit so that we're sure the HDMI IP has finished. As we don't have any ready-made irq handling for HDMI, and this only needs to be done when disabling the HDMI output, this patch implements a simple loop with sleep, polling the FRAMEDONE bit. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Error handling in hdmi_power_on_full() is not correct, and could leave resources unfreed. Fix this by arranging the error labels correctly. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Improve the DISPC debug print for scaling. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The current driver does both x and y decimation on OMAP3 DSS. Testing shows that x decimation rarely works, leading to underflows. The exact reason for this is unclear, as the underflows seem to happen even with low pixel clock rates, and I would presume that if the DSS can manage a display with 140MHz pixel clock, it could manage x decimation with factor 2 with a low pixel clock (~30MHz). So it is possible that there is a problem somewhere else, in memory management, or DSS DMA, or similar. I have not found anything that would help this. So, to fix the downscaling scaling, this patch removes x decimation for OMAP3. This will limit some of the more demanding downscaling scenarios, but one could argue that using DSS to downscale such a large amount is insane in the first place, as the produced image is rather bad quality. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The DISPC's scaling code seems to presume that decimation always succeeds, and so we always do find a suitable downscaling setup. However, this is not the case, and the algorithm can fail. When that happens, the code just proceeds with wrong results, causing issues later. Add the necessary checks to bail out if the scaling algorithm failed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The DISPC driver uses 64 bit arithmetic to calculate the required clock rate for scaling. The code does not seem to work correctly, and instead calculates with 32 bit numbers, giving wrong result. Fix the code by typecasting values to u64 first, so that the calculations do happen in 64 bits. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the line, after the last pixel, whereas on OMAP4+ it is. The driver currently works for OMAP4+, but does not handle OMAP2/3 correctly, which leads to tilted image when row_inc is used. This patch adds a flag to DISPC driver so that the pixel_inc is added when required. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After studying this, I found that sometimes the driver uses three-tap scaling with downscaling factor smaller than x0.5. This causes issues, as x0.5 is the limit for three-tap scaling. The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for five-tap scaling, which allows scaling down to x0.25. This patch adds checks for both horizontal and vertical scaling. For horizontal the HW always uses 5 taps, so the limit is x0.25. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
After calculating the required decimation for scaling, the dispc driver checks once more if the resulting configuration is valid by calling check_horiz_timing_omap3(). Earlier calls to this function have correctly used in_width and in_height as parameters, but the last call uses width and height. This causes the driver to possibly reject scaling that would work. This patch fixes the parameters. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
DISPC needs even input buffer width for YUV modes. The DISPC driver doesn't check this at the moment (although omapdrm does), but worse, when DISPC driver does x predecimation the result may be uneven. This causes sometimes sync losts, underflows, or just visual errors. This patch makes DISPC driver return an error if the user gives uneven input width for a YUV buffer. It also makes the input width even in case of predecimation. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Errata i631 description: "When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when fetching Chroma sampling." Workaround: "If YUV4:2:0-1D burst is required: Set DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3" The description is somewhat confusing, but testing has shown that DSS fetches extra rows from memory when using NV12 format in 1D mode. If the memory after the framebuffer is inaccessible, this leads to OCP errors. The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only need to handle the ROTATION part. The issue exist on all OMAP4 and OMAP5 based DSS IPs. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
-
由 Tomi Valkeinen 提交于
Now that we are using components in omapdss, there's no need for separate handling of dss and dispc driver init. Thus we can move the dss and dispc init and unit func pointers to the lists we use for the other dss submodules. We can now also handle errors returned by the registration functions properly: if registering a driver fails, we can stop processing and return the error. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
omapdss kernel module contains drivers for multiple devices, one for each DSS submodule. The probing we have at the moment is a mess, and doesn't give us proper deferred probing nor ensure that all the devices are probed before omapfb/omapdrm start using omapdss. This patch solves the mess by using the component system for DSS submodules. The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi, venc) are the same: probe & remove functions are changed to bind & unbind, and new probe & remove functions are added which call component_add/del. The dss_core driver (dss.c) acts as a component master. Adding and matching the components is simple: all dss device's child devices are added as components. However, we do have some dependencies between the drivers. The order in which they should be probed is reflected by the list in core.c (dss_output_drv_reg_funcs). The drivers are registered in that order, which causes the components to be added in that order, which makes the components to be bound in that order. This feels a bit fragile, and we probably should improve the code to manage binds in random order. However, for now, this works fine. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
We have a list of function pointers to dss submodule uninit functions. It makes sense to do the uninit in the reverse order to init, but that is not currently the case. This patch reorders the uninit calls to be the reverse of init order. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
The following patches will add component handling to omapdss, improving the handling of deferred probing. However, at the moment we're using quite a lot of __inits and __exits in the driver, which prevent normal dynamic probing and removal. This patch removes most of the uses of __init and __exit, so that we can register drivers after module init, and so that we can unregister drivers even if the module is built-in. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
The return value of dss_init_ports() is not handled at all, causing crashes later if the call failed. This patch adds the error handling, and we also move the call to a slightly earlier place to make bailing out easier. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
Refactor dss probe function by extracting the setup for video plls into a separate function. The call to this function is also moved to a slightly earlier phase, so that in error case we can bail out more easily. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Tomi Valkeinen 提交于
We have a flag, 'dss_initialized', which tells omapfb and omapdrm if omapdss is available. At the moment it can be set even if the dss submodules are not all ready, in case something gets deferred. Move the flag to dss_core driver so that it'll signal the availability of the dss drivers move accurately. For now, it'll signal that dss_core is ready, which is not quite correct but still better than previously. The following patches will add component system to omapdss, and after those patches 'dss_initialized' will signal that all the submodules are ready. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
- 16 6月, 2015 4 次提交
-
-
由 Vladimir Murzin 提交于
fb_videomode_from_videomode() may fail, but of_get_fb_videomode() silently covers this fact. Instead, trow the error code to the caller. Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Luis R. Rodriguez 提交于
This driver uses the same area for MTRR as for the ioremap_wc(), if anything it just uses a smaller size in case MTRR reservation fails. ioremap_wc() API is already used to take advantage of architecture write-combining when available. Convert the driver from using the x86 specific MTRR code to the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add() will avoid MTRR if write-combining is available. There are a few motivations for this: a) Take advantage of PAT when available b) Help bury MTRR code away, MTRR is architecture specific and on x86 its replaced by PAT c) Help with the goal of eventually using _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit de33c442 titled "x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()") The conversion done is expressed by the following Coccinelle SmPL patch, it additionally required manual intervention to address all the #ifdery and removal of redundant things which arch_phys_wc_add() already addresses such as verbose message about when MTRR fails and doing nothing when we didn't get an MTRR. @ mtrr_found @ expression index, base, size; @@ -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1); +index = arch_phys_wc_add(base, size); @ mtrr_rm depends on mtrr_found @ expression mtrr_found.index, mtrr_found.base, mtrr_found.size; @@ -mtrr_del(index, base, size); +arch_phys_wc_del(index); @ mtrr_rm_zero_arg depends on mtrr_found @ expression mtrr_found.index; @@ -mtrr_del(index, 0, 0); +arch_phys_wc_del(index); @ mtrr_rm_fb_info depends on mtrr_found @ struct fb_info *info; expression mtrr_found.index; @@ -mtrr_del(index, info->fix.smem_start, info->fix.smem_len); +arch_phys_wc_del(index); @ ioremap_replace_nocache depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap_nocache(base, size); +info->screen_base = ioremap_wc(base, size); @ ioremap_replace_default depends on mtrr_found @ struct fb_info *info; expression base, size; @@ -info->screen_base = ioremap(base, size); +info->screen_base = ioremap_wc(base, size); Generated-by: Coccinelle SmPL Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Luis R. Rodriguez 提交于
The MTRR added was never being deleted, in order to store the MTRR cookie we need to make use of the private info->par so we create a struct for this. This driver was already using the extra space typically used for info->par for the info->pseudo_palette which typically used stuffed on driver's own private structs (the respective info->par), so we just move the pseudo_palette into the private struct as well. Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Luis R. Rodriguez 提交于
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB, the other MTRR types were implemented and supported here but with no real good reason. The ioremap() APIs are architecture agnostic and at least on x86 PAT is a new design that extends MTRRs and can replace it in a much cleaner way, where so long as the proper ioremap_wc() or variant API is used the right thing will be done behind the scenes. This is the only driver left using the other MTRR types -- and since there is no good reason for it now rip them out. Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 12 6月, 2015 3 次提交
-
-
由 Krzysztof Kozlowski 提交于
The platform_device_id is not modified by the driver and core uses it as const. Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Krzysztof Kozlowski 提交于
The platform_device_id is not modified by the driver and core uses it as const. Signed-off-by: NKrzysztof Kozlowski <k.kozlowski.k@gmail.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Kees Cook 提交于
Since kobject_init_and_add takes a format string, make sure that the passed in name cannot be accidentally parsed. Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 05 6月, 2015 1 次提交
-
-
由 Tomi Valkeinen 提交于
Merge arch/ changes for TI's DRA7 SoC Display Subsystem.
-
- 04 6月, 2015 9 次提交
-
-
由 Tomi Valkeinen 提交于
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: devicetree@vger.kernel.org Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
DRA72 EVM has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: devicetree@vger.kernel.org Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
DRA7xxx contains a very similar DSS to OMAP5. The main differences are: * no DSI or RFBI support. * 1 or 2 dedicated video PLLs. * need to do additional configuration to the DRA7 CONTROL module. DRA72xx has only one video PLL, and DRA74xx has two. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: devicetree@vger.kernel.org Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Add platform code to detect DRA7 DSS. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Simplify the DSS detection logic by creating a list of the omapdss compat strings, instead of checking each separately with an 'if'. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
Set DSS core hwmod as the parent for all the DSS submodules. This ensures that the parent hwmods are enabled before any DSS submodules are accessed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tomi Valkeinen 提交于
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NPaul Walmsley <paul@pwsan.com>
-
由 Tomi Valkeinen 提交于
We need set-rate-parent flags for the display's clock path so that the DSS driver can change the clock rate of the PLL. This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock node, which is only a gate clock, allowing the setting of the clock rate to propagate to the PLL. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: devicetree@vger.kernel.org Acked-by: NTero Kristo <t-kristo@ti.com>
-
由 Tomi Valkeinen 提交于
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That clock is an odd one, as it is not supposed to be any kind of core clock for DSS, and we don't even support HDCP, but the clock is still needed even for the HWMOD framework to be able to reset the DSS IP. As there's no support for multiple core clocks in the HWMOD framework, we don't have any obvious place to enable this clock when DSS IP is being enabled. Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5 does not have any such clock configuration bit. This suggests that on OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the possibility to gate it. So, as we don't have any clean way to enable and disable the clock based on the need, this patch enables the clock at boot time, making it work similarly to OMAP5. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTero Kristo <t-kristo@ti.com> Acked-by: NMichael Turquette <mturquette@linaro.org>
-
- 03 6月, 2015 1 次提交
-
-
由 Misael Lopez Cruz 提交于
DM_INH = 1 (stereo downmix prohibited) and CA = 0x00 (Channel Allocation: FR, FL) is an invalid combination according to the HDMI Compliance Test 7.31 "Audio InfoFrame". Signed-off-by: NMisael Lopez Cruz <misael.lopez@ti.com> Signed-off-by: NJyri Sarha <jsarha@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NMark Brown <broonie@kernel.org>
-